講演と出版物

カンファレンスでの講演と講義

正しくプログラミングできる人はいない C++コードデバッグのための実践的でインタラクティブなガイド
Sebastian Theophil

私たちはコードを書くことが好きですがどんなに努力しても間違いをします。私たちのプログラムにはバグが含まれます。私たちは書くつもりでなかったことを書いてしまったり、プログラミング言語のある要素を理解していなかったり、プログラムのシステム環境についての重要な情報がなかったり、あるいはそれを考慮することを忘れたりします。その結果、プログラムは正しく機能しなくなります。それではどうしたらよいでしょう? この講演では、クラッシュするプログラムから始めて、デバッグプロセス全体について説明します。次に何をするべきでしょうか? どのような質問をする必要がありますか? どのような情報が必要ですか? クラッシュの原因を突き止めるにはどうすればよいでしょうか? この問題を解決するのに役立つツールはどれですか?最後に、このバグが二度と起こらないようにするにはどうすればよいでしょうか? 長年にわたりthink-cellにおいて遭遇し、デバッグしてきた実際の例に基づき、もっとも難しいバグについても、それらを再現し、発見し、理解し、修正する方法を学ぶことができます。


Typescripten — emscripten用のタイプセーフなJavaScriptバインディングの生成
Sebastian Theophil

WebAssemblyはC++開発者にとても人気のあるターゲットプラットフォームとなりました。emscriptenのおかげで、アプリケーションの表示・入力デバイスをブラウザのみとする限り、ネイティブなアプリケーションのWebAssemblyへの移行は容易です。しかしemscriptenは、DOM操作APIなどの標準的なJavaScript APIへのタイプセーフなラッパーを提供しません。既存のウェブアプリケーションが提供するその他のJavaScript APIはなおさらです。当社のオープンソースツールである「typescripten」は、このギャップを埋めるため、3つの強力なテクノロジーに基づき構築されています。これはTypeScriptインターフェース定義ファイルとTypeScriptコンパイラAPIを使用して、emscriptenをベースとするタイプセーフなC++ラッパーを作成します。TypeScriptにはすでに、7000以上のJavaScriptライブラリ用のインターフェース定義ファイルがあり、C++から安全に使用することができます。当社は、C++ラッパーの設計を、それらを使用するC++コードが、TypeScriptまたはJavaScriptコードと同等に見えるように設計します。しかし、プロトタイプベースのJavascriptやTypescriptの独特のセマンティクスをC++などの型ベースの言語へと翻訳することは難しいことがよくあります。このフレームワークを設計するときに私たちが直面した課題と、私たちが行った選択について説明します。


Windows、macOS、およびWeb:think-cellでのクロスプラットフォーム開発からの教訓
Sebastian Theophil

12年間think-cellはWindows専用のソフトウェア会社で、当社の約70万行のコードベースは、多くの意図しないプラットフォーム依存関係により蓄積してきました。6年前、当社は当社アプリケーションをMacへ移植することを決定しました。この変更は当社の開発プロセスのすべての部分に影響を与えました。プロジェクト組織、ビルドシステム、当社が今日C++でプログラムする方法などすべてです。Qtやboostなどの一般的に使用されるクロスプラットフォームライブラリは、ビルドする際の優れたツールですが、それらだけでは十分ではありません。ミューテックス、セマフォ、共有メモリなどの多くのコンセプトに関し、実にさまざまなセマンティクスや寿命を持つプラットフォーム固有のオブジェクトに、これらはひとつの共有インターフェースのみを提供します。私たちは、レンダリング、国際化、ファイル入出力、マウスイベントの処理、RPCコール、エラー報告について軽量のプラットフォームに依存しない、同一のセマンティクスを持つC++抽象化を求めました。これらを開発することは難しいことでした。まず私たちはアプリケーションが必要とするセマンティクスを定義しなくてはならず、次にそれらを各プラットフォームに実装しなくてはなりませんでした。これは簡単なプロセスではなかったのですが、結果的に私たちのコードの品質を大きく向上させたと思います。今日までに、私たちは次の課題にとりかかり、一部の機能をウェブアプリケーションへと移行しはじめました。私たちは、もちろん既存のコードベースを再使用することを希望しましたが、それは、ウェブアプリケーションを表現力のあるタイプセーフなC++で書くことを意味します。間違いなくここで役に立つはずです。私たちはemscriptenを使用してウェブアプリケーションを構築しましたが、すべてのTypeScriptインターフェース定義からのタイプセーフなC++バインディングを生成しました。私の講演では、クロスプラットフォーム問題分野に焦点を当てて、私たちが実装したC++ 抽象化の概要を説明します。クロスプラットフォームの問題領域は、いずれかのオペレーティングシステムの制限によって共通のセマンティクスを定義することが難しかった分野です。そしてもちろん、私たちにC++でウェブアプリケーションを書かせたツールもお見せします。


C++ rvalueの寿命における惨事
Arno Schödl

C++11以降私たちはrvalue参照を使っています。rvalueは元々、オブジェクトの移動をより効率的にするために導入されました。rvalue参照が参照するオブジェクトはすぐに範囲から消えると想定されているため、そのリソースは害なく除去する可能性がありました。C++標準ライブラリ、たとえばstd::crefまたはstd::rangesは、rvalue参照の別の要素を利用します。lvalue参照は安全であると考えられるのに対し、rvalueはすぐ範囲から消えるので、現在の関数の範囲を超えて保持することは安全ではないと想定されます。私たちも、この想定は小さなメモリ管理、特に汎用コードに非常に有用であると考えます。
不幸なことに、C++言語自体がこの想定に違反しています。rvalueはconstにバインドしているのです。このことは、何気ない顔をした関数がサイレントにrvalueをlvalue参照に変換することを意味し、rvalueの寿命を隠していることを意味します。一時的な寿命の延長は、バインディングを一時的なものから、一時的な寿命の延長により参照セーフなものにすることを意味します。しかしこれはprvalueがtemporaryの場合のみ機能します。すでにrvalue参照に違反しており、見せかけで生成されたlvalue参照はなおさらです。これらの問題は単に理論的なものではありません。この問題のために当社コード内に見つけにくいメモリ崩壊が起きていました。この講演では、私はこの問題について詳細に説明し、問題を軽減するために当社のライブラリ・オンリーのアプローチを提示します。そして最後に、正常な状態にするための、これまで標準にはなりえなかった提案を行います。


より優れたC++ Range
Arno Schödl

今では、RangeはすっかりC++の標準となり、モダンコードベースの中に入り込む方法を有しています。think-cellでは、自社のRangeライブラリを20年間開発しており、これは標準ライブラリ上に構築されそれと互換性がありますが、多くの点で標準ライブラリを超えています。Rangeアダプタは頻繁に積み重ねられ、さまざまなものの上のtransformの上のフィルタです。このようなスタックを効率的に行うには、イテレータでは十分ではありません。私たちはより効率的であると同時にイテレータに対応し、そのためライブラリユーザーが以前のようにイテレータを使い続けることができるような、新しいコンセプトを使用します。標準ライブラリは、コンテナとビューの間の違いに非常に厳格であり、Rangeアダプタはビューで、適応するデータへの参照を維持しなくてはなりません。代わりに私たちはRangeアダプタ自体にデータを保持することを許可して自己完結させ、同時に遅延評価させます。標準イテレータモデルは、外部反復のみを許可します。しかし内部反復は、外部反復よりもより実装が容易です。多くのアプリケーションにおいて、内部反復は完全に適切であり外部反復よりも効率的です。そのため私たちは、ライブラリユーザーが、どのような反復が使用されているか分からず気にもならない程度まで、内部反復をRangeファミリーに組み込みました。標準アルゴリズムは反復を返し、最後のイテレータを使って、シングルトン状態を示します。返し値をカスタマイズすることにより、コードをより簡潔かつ表現的にすることができます。たとえばこれらの手ごわいイテレータエンドチェックを除去するなどです。これらの機能を組み合わせてテキスト書式設定のための優れたツールを作ります。これらのRangeを使用してフォーマットされる値を表し、概念的に遅延評価された文字列に変えます。これらは今日使用されている通常の文字列と同じように使用可能です。関数の戻り値、標準のアルゴリズムの入力値、他への埋め込み、同じように遅延評価された文字列などとして使用し、最終的に表示のために展開します。適切なインターフェースを選択することにより、この展開をコンパイル時に最適化することができ、優れた構文と手動で最適化したコードに非常に近いパフォーマンスを可能にします。


将来のレンジベースの標準ライブラリ向けテキスト書式設定
Arno Schödl

テキスト書式設定は長年にわたりC++ライブラリの著者にとってお気に入りの問題でした。今回の講演では、テキスト書式設定の問題にとって、Rangeと少しのメタプログラミングの組み合わせが非常に洗練されたソリューションになることを実証したいと思います。内部での反復と共に範囲の1形態をご紹介します。これらは外部のイテレータをさらすというよりも、1つずつ要素を生成しています。これらの生成元の範囲を使用してフォーマットされる値を表し、概念的に遅延評価された文字列に変えます。これらは最終的にコンテナに拡張される前に、今日使用されている通常の文字列と同じように、関数の戻り値、標準のアルゴリズムの入力値、他への埋め込み、同じように遅延評価された文字列などとして使用可能です。正しいインターフェースを選択することで、手動で最適化された特殊コードを使用した同等の文字列を作成するよりもわずか15%の遅延になるまで、この拡張を最適化することができます。


イテレータが完全に見当違いである理由(代わりに何を使うべきか)
Arno Schödl

イテレータについては理解していますね? 皆さんはイテレータをどのように説明しますか? 「イテレータは要素のシーケンスに入るまで使用されています。」 この説明で良さそうでしょうか? 近年、範囲の概念はイテレータを公開するものを意味するために採用されています。特に、範囲は要素のシーケンスを遅延して変化させる、またはフィルタリングするための範囲アダプタを含みます。また、これらもイテレータを持っています。
これで問題ありませんか? 残念なことに、答えは「ノー」です。C++の出現以来、我々はイテレータの概念を使用していますが、根本的に不備があります。特に、イテレータによって、要素あるいは要素間の境界を示すように意図されているかどうかによって動作が異なります。つまり要素と境界は2つの特徴的な概念です。今回の講演では、問題が実際にあり、実際的な意味を持っていることを実証します。また、その対処方法を提案し、問題に対処するだけでなく、コードをより明確にしてミスを防ぐソリューションを提示したいと思います。


イテレータからRangeへ—来たるべき標準ライブラリの進化
Arno Schödl

C++ライブラリでは、対のイテレータが偏在しています。通常、このような対をRangeと呼ばれることが多い単一のエンティティに組み合わせると、さらに正確で読み取り可能なコードができることが知られています。このようなRangeのコンセプトの正確なセマンティクスを定義することは非常に困難です。理論を考慮すれば、実践で問題が発生します。設計目標の一部は相互に矛盾します。


エラー対応の実践的アプローチ
Arno Schödl

どのプログラムでもエラーは発生しており、その原因はプログラム内のバグであったり、プログラムが動作している環境であったりします。エラーを無視すればプログラムは完全に信頼できないものになりますが、一方で考えられるエラーすべてに対応するとなると、大きなメリットが得られない複雑な作業が増えることになります。think-cellでは、弊社が使用し、改良を続けている原理に基づいた独自のエラー処理のアプローチを紹介する予定です。これは他では使用されていないアプローチです。この講演では、当社が実際に使用している方法をお伝えするので、参加者は次回のプロジェクトにおいて、少ない労力でより信頼できるソフトウェアを書けるようになるでしょう。


C++ウィークリーエピソード CppCastのインタビュー
Arno Schödl

Rob IrvingとJason Turnerによる2018年1月24日のCppCastでは、think-cellのRangeライブラリとthink-cellでのC++の開発の概要についてArnoにインタビューを行いました。


シンプルなPowerPointアドインの開発は、一体どれだけ大変な作業か?
Valentin Ziegler

Office開発には、退屈なVBA Macrosや紋切り型のJavaScriptが大きく関係してきます。Valentinがこれまで話をした多くの開発者が、think-cellのコードベースには100万行のC++コードがあることと、私たちがそれをこのように短く保つために、汎用ライブラリを作らねばならないことを知って驚きます。私たちは、ユーザーが短い時間で優れた外見のスライドを作成できるようにするため、もっともシンプルなユーザーインターフェースをPowerPoint上に実装するべく努力しており、このため私たちは非常に強力なツールを使用する必要があります。レイアウトと配置の問題を解決するために私たちがどのように最先端のアルゴリズムを適用しているか、また、ホストアプリケーションとのシームレスな統合のために私たちがどのような課題を克服しなくてはならないかについてお見せしましょう。


業務用ソフトウェアの改造
Simon McPartlin

ソフトウェアへのパッチ適用は、バグの修正、機能の追加、ソフトウェアのユーザビリティやパフォーマンスの改善に対する強力ながらもリスキーな方法です。本講演ではソースコードが利用できない場合のソフトウェアへのパッチ適用を取り上げます。アクティビティは一般にハッキングと言われています。このようなアクティビティが必要とされる理由と時期について論じてから、設計や堅牢なパッチの実装について詳しく見てみます。適切なパッチの場所を探すために使用するさまざまなツールや技術について述べて締めくくります。


std::coutは機能しなくなっている — iostreamが退場すべき理由とは?
Sebastian Theophil

弊社ではつい最近、ソフトウェアを他のプラットフォームに移し始めたばかりです。このプロセスで、iostreamとC-style I/Oの難点を発見しました。本講演では、弊社のコードベースからiostreamを除去した理由と、これを何に置き換えたのかについて簡単に説明します。


C++ メモリモデル
Valentin ZieglerとFabio Fracassi

C++メモリモデルはマルチスレッドがメモリや共有データとどのように相互作用するかを定義するもので、プラットフォームでそれぞれの並列コードを開発者が論証できるようにしています。本講演では、C++でのマルチスレッド化された実行とデータ競合、コンパイラやハードウェアの最適化によって並列コードが受ける影響、ロックや不可分操作の使用による未定義の動作の回避方法について説明します。次に不可分操作の異なるメモリオーダー、その保証やパフォーマンスに焦点を置きます。


C++ vs. Java
Valentin ZieglerとFabio Fracassi

当社ではC++を高く評価しており、毎日使用しています。この講演では、C++は複雑だという評判はあるものの、概念的にJavaよりも優れた言語なのはなぜか、についてご説明いたします。なぜ? C++は価値セマンティクスを把握しているため。C++には抵抗のないビヘイビアが含まれているため。C++はガーベジのコレクションを強要しないため。C++を使用すると、抽象的で効率の良いコードを書けるため。


科学出版物

散布図のラベル付けのための効率的なアルゴリズム
Sebastian TheophilとArno Schödl
AAAI 2006の手順

本書ではポイントフィーチャのラベル付け問題の新しいバリエーションに対して、効率的なアルゴリズムを提示します。目標は、相互にあるいは他のポイントと交わらないように、最大数のポイントのラベルを適切に配置することです。最初に限られた先読みで貪欲法を使用するアルゴリズムについて述べます。次に繰り返しラベルを再グループ化するアルゴリズムを示します。各グループで最初のアルゴリズムを呼び出し、最適なラベル付け順序の近似値を特定するものです。提示されたアルゴリズムは商用製品でチャートのラベル付けに使用されており、弊社の評価では他のラベル付けアルゴリズムをはるかに凌駕する成果を生んでいることを示しています。


縦棒グラフのラベル付けのためのスマートなアルゴリズム
Sebastian MüllerとArno Schödl
SMART GRAPHICS 2005の手順

本書では縦棒グラフやその派生物のラベル付けに向いたスマートなアルゴリズムを提示します。効率的に問題を解決するために、2つの下位の問題に分けています。その他のカラムがすでにラベル付けされている状態で、単一のカラムのラベル用に優れたラベル付けを発見するという問題を解決するため、最初に幾何学的アルゴリズムについて述べます。次にどのカラムにラベル付けを行うかどうかの優れた順序、一部の限られた先読み用に繰り返し使用する最初のアルゴリズムを見つけるための戦略を示します。提示されたアルゴリズムは商用製品でチャートのラベル付けに使用されており、実際に満足のいく成果を挙げていることを示しています。


グラフカット・テクスチャ:グラフカットを使用する画像や映像の合成
Vivek Kwatra、Arno Schödl、Irfan Essa、Greg Turk、Aaron Bobick
SIGGRAPH 2003の手順

本書では、画像や映像のテクスチャ合成向けの新しいアルゴリズムをご紹介します。弊社のアプローチでは、サンプルの画像または映像のパッチ領域は変換され、出力にコピーされてから、新しい(そして通常はより大きな)出力を生成するために最適な継ぎ目でつなぎ合わされます。他の手法とは対照的に、パッチのサイズは演繹的に選ばれるのではなく、グラフカット手法を使用して、入出力テクスチャの間で特定のオフセット用に最適なパッチ領域を決定します。動的計画法とは異なり、継ぎ目の最適化を意図した弊社のグラフカット手法はあらゆる次元で適用可能です。特に2Dと3Dで調査し、通常の画像合成に加えてビデオテクスチャ合成を実行しています。


スプライトアニメーション制御
Arno SchödlとIrfan Essa
SCA 2002の手順

本書では、スプライトアニメーション制御の生成に関する新しいアプローチについて述べます。スプライトとは、動くオブジェクトの映像のフレームを再配置することで作成されたアニメーションです。弊社の手法によって、ユーザーはフレキシブルなコスト関数を使用してアニメーションを指定することができます。コスト関数はスプライトのシーケンスを繰り返し再配置することで自動的に最適化されます。


ビデオテクスチャ
Arno Schödl、Richard Szeliski、David H. Salesin、Irfan Essa
SIGGRAPH 2000の手順

本書では、ビデオテクスチャと呼ばれる新しい種類の媒体をご紹介します。写真と映像の中間あたりの性質を持っています。ビデオテクスチャは無限に変化し続ける画像のストリームを提供します。個々のビデオテクスチャのフレームは時々繰り返されますが、ビデオシーケンス全体としては二度と繰り返しません。デジタル写真の代わりにビデオテクスチャを使用して、静止画像に動的な性質と明示的なアクションを与えることができます。

詳細な情報をご希望ですか?

think-cellでの仕事、求人情報、イベントについてご質問がある場合は、お気軽にジュリア・ザチャック(Julia Zhachuk)までお問い合わせください。

hr@think-cell.com
+49 30 6664731-81

think-cell人事部門責任者マリサ・フリーズ(Julia Zhachuk).


共有する