テンプレート・パラメータ = void* のコンパイラ・バグ - ページ 17 1...1011121314151617181920 新しいコメント Ilya Malev 2018.12.20 21:50 #161 ひょっとして、サポーターのピラミッドコードってあったんですか？どちらかというと、私が最初かな ))))) Dmitry Fedoseev 2018.12.20 21:53 #162 Ilya Malev:ひょっとして、サポーターのピラミッドコードってあったんですか？どちらかというと、私が最初かな ))))) これは、横文字コード支持派に起因していると思われる。 Ilya Malev 2018.12.20 21:54 #163 Dmitry Fedoseev:これは、水平コード支持陣営に起因するものである。そうですね、拙速でしたね。最高の例は、あまりにも超越的であったため、私たちの死すべき現実への移行を生き延びることができなかった......」。 Stanislav Korotky 2018.12.20 22:16 #164 Ilya Malev:ひょっとして、サポーターのピラミッドコードってあったんですか？どちらかというと、私が最初かな ))))) これは難解な表現です。 Ilya Malev 2018.12.20 23:06 #165 Stanislav Korotky:難読化である。ええ、私はあなたから遠いです。いわば、目指すべきものがあるのです )) Ilya Malev 2018.12.21 00:01 #166 pavlick_:一般的には、はい、できます。 ラッピングなしなら削除されない、ラッピングありなら削除される、すべてがクリアになる。 ZS: でも、もしやるなら、標準のプラスライブラリとなるべく似たようなもの（名前、動作など）にしたいので、僕には選択肢がないんです。すでにすべてが書かれているのに、なぜわざわざ別の仕様書を作るのか？- 動的なOOPの中で自動的な構造を作るのはナンセンスだ- 動的構造は、特定の処理のために作成されたもの（選択項目に対するクエリのようなもの）と、既存の要素集合からの 選択として作成されたもの（混合型もありうる）に分ける必要があります。- 今のところ、オブジェクトへの「独自の」参照の数を計算することで解決できると考えています。ラッパーを作成する必要はありませんが（それで問題が解決するのかはよくわかりません）、µlにすでにあるポインタのメカニズムを複製して、少なくとも参照カウンタを含む私のメソッドを追加しなければなりません（ところで、habraの記事で議論されていました。）- もし、価値あるものが出てきたら、フォーラムやkodobaseに投稿するつもりです。） Алексей Тарабанов 2018.12.21 00:22 #167 Ilya Malev:- 動的なOOPの中で自動的な構造を作ることはナンセンスである- 動的構造は、特定の処理のために作成されたもの（選択項目に対するクエリのようなもの）と、既存の要素集合からの 選択として作成されたもの（混合型もありうる）に分ける必要があります。- 今のところ、オブジェクトへの「独自の」参照の数を計算することで解決できると考えています。しかし、µlにすでに存在するポインタのメカニズムを複製し、私のメソッドを追加し、少なくとも参照カウンタを含める必要があります（ところで、これはhabraからのあなたの記事で議論されていました。- それを全部実行してみて、何かいいことがあれば、とりあえずフォーラムやkodobaseに投稿してみますね :)とても興味深いです。パイ○ンには飽きた。 Ilya Malev 2018.12.21 00:36 #168 というか、しないほうがいい。何も公表しない...。 pavlick_ 2018.12.21 01:13 #169 Ilya Malev:まあ、配列を作るときに、削除するときに要素を削除するかどうか、デフォルトでオンかオフか（お好みで）、というオプションを追加で渡すことは誰も禁止していないんですけどね。結局のところ、アイテムを削除したいのかどうか、推測することはできません))。削除が必要なポインタの配列で、コピー演算子=()とコピーコンストラクタ(µlではデフォルトで存在しない)を無効にするにはどうしたらいいでしょうか。これにより、コンストラクタ経由のパラメータがジャンクであることが明確になります。2つのアイデアが生まれます。 1. deleted文のある型をテンプレートパラメータを通して渡し、クラスのメンバに する（そしてそれは不必要なリソースの浪費になる）。 2. ラッパーの中でポインターを渡す :)(そうそう - あのクソ包装)。 3.部分的に特化したものを使えば抜け出せるかもしれないが、それがない。 一般的にプラスライブラリは名作です、もっと良いものが書けると思ったら、それは間違いでしょう。 Ilya Malev 2018.12.21 01:23 #170 pavlick_:0.このような配列を書き、驚きの結末を迎えたわけですが、削除が必要なポインタの配列で、コピーする operator=() とコピーする constructor（デフォルトではどのみち µl にはない）を無効にするにはどうしたらいいでしょうか？これにより、コンストラクタ経由のパラメータがジャンクであることが明確になります。2つのアイデアが生まれます。 1. deleted文のある型をテンプレートパラメータを通して渡し、クラスのメンバに する（そしてこれは不必要なリソースの浪費になる）。 2. ポインタラッパーを渡す :)(そうそう - あのクソ包装)。 3.部分特化で抜け出せるのに、それがない。 一般的にプラスライブラリは名作です、もっと良いものが書けると思ったら大間違いです。しかし、その内容は、多くのTCを構築するのに必要な作業よりも、はるかに広い範囲の作業を想定して書かれています。グラフプロセッサを使ったニューラルネットワークのような変種や、タンバリンを使ったダンスは考えていません。 0.すでに作成された ダイナミックなオブジェクトが転送されることはお伝えしました。これは、選択用に特別に作成されたオブジェクト（後で削除する必要があります）、または使用されているが削除されていないオブジェクトへの参照のいずれかです。リストオブジェクトは、作成する責任はありません。ただ、必要な限り、アドレス指定、アクセス、保存を行うだけです。 1. ... 2. ... 3... つまり、抽象的なものではなく、具体的な細かいタスクを考える必要があるのです。guiを書かなければならないのであれば、それも意味がないですね。近くのスレッドで純粋構造体を使った素敵なguiを書いている人がいるようです)。 1...1011121314151617181920 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ひょっとして、サポーターのピラミッドコードってあったんですか？どちらかというと、私が最初かな )))))
ひょっとして、サポーターのピラミッドコードってあったんですか？どちらかというと、私が最初かな )))))
これは、横文字コード支持派に起因していると思われる。
これは、水平コード支持陣営に起因するものである。
そうですね、拙速でしたね。最高の例は、あまりにも超越的であったため、私たちの死すべき現実への移行を生き延びることができなかった......」。
ひょっとして、サポーターのピラミッドコードってあったんですか？どちらかというと、私が最初かな )))))
これは難解な表現です。
難読化である。
ええ、私はあなたから遠いです。いわば、目指すべきものがあるのです ))
一般的には、はい、できます。
ラッピングなしなら削除されない、ラッピングありなら削除される、すべてがクリアになる。
ZS: でも、もしやるなら、標準のプラスライブラリとなるべく似たようなもの（名前、動作など）にしたいので、僕には選択肢がないんです。すでにすべてが書かれているのに、なぜわざわざ別の仕様書を作るのか？
- 動的なOOPの中で自動的な構造を作るのはナンセンスだ
- 動的構造は、特定の処理のために作成されたもの（選択項目に対するクエリのようなもの）と、既存の要素集合からの 選択として作成されたもの（混合型もありうる）に分ける必要があります。
- 今のところ、オブジェクトへの「独自の」参照の数を計算することで解決できると考えています。ラッパーを作成する必要はありませんが（それで問題が解決するのかはよくわかりません）、µlにすでにあるポインタのメカニズムを複製して、少なくとも参照カウンタを含む私のメソッドを追加しなければなりません（ところで、habraの記事で議論されていました。）
- もし、価値あるものが出てきたら、フォーラムやkodobaseに投稿するつもりです。）
- 動的なOOPの中で自動的な構造を作ることはナンセンスである
- 動的構造は、特定の処理のために作成されたもの（選択項目に対するクエリのようなもの）と、既存の要素集合からの 選択として作成されたもの（混合型もありうる）に分ける必要があります。
- 今のところ、オブジェクトへの「独自の」参照の数を計算することで解決できると考えています。しかし、µlにすでに存在するポインタのメカニズムを複製し、私のメソッドを追加し、少なくとも参照カウンタを含める必要があります（ところで、これはhabraからのあなたの記事で議論されていました。
- それを全部実行してみて、何かいいことがあれば、とりあえずフォーラムやkodobaseに投稿してみますね :)
とても興味深いです。パイ○ンには飽きた。
まあ、配列を作るときに、削除するときに要素を削除するかどうか、デフォルトでオンかオフか（お好みで）、というオプションを追加で渡すことは誰も禁止していないんですけどね。結局のところ、アイテムを削除したいのかどうか、推測することはできません))。
削除が必要なポインタの配列で、コピー演算子=()とコピーコンストラクタ(µlではデフォルトで存在しない)を無効にするにはどうしたらいいでしょうか。これにより、コンストラクタ経由のパラメータがジャンクであることが明確になります。2つのアイデアが生まれます。
1. deleted文のある型をテンプレートパラメータを通して渡し、クラスのメンバに する（そしてそれは不必要なリソースの浪費になる）。
2. ラッパーの中でポインターを渡す :)(そうそう - あのクソ包装)。
3.部分的に特化したものを使えば抜け出せるかもしれないが、それがない。
一般的にプラスライブラリは名作です、もっと良いものが書けると思ったら、それは間違いでしょう。
0.このような配列を書き、驚きの結末を迎えたわけですが、削除が必要なポインタの配列で、コピーする operator=() とコピーする constructor（デフォルトではどのみち µl にはない）を無効にするにはどうしたらいいでしょうか？これにより、コンストラクタ経由のパラメータがジャンクであることが明確になります。2つのアイデアが生まれます。
1. deleted文のある型をテンプレートパラメータを通して渡し、クラスのメンバに する（そしてこれは不必要なリソースの浪費になる）。
2. ポインタラッパーを渡す :)(そうそう - あのクソ包装)。
3.部分特化で抜け出せるのに、それがない。
一般的にプラスライブラリは名作です、もっと良いものが書けると思ったら大間違いです。
しかし、その内容は、多くのTCを構築するのに必要な作業よりも、はるかに広い範囲の作業を想定して書かれています。グラフプロセッサを使ったニューラルネットワークのような変種や、タンバリンを使ったダンスは考えていません。
0.すでに作成された ダイナミックなオブジェクトが転送されることはお伝えしました。これは、選択用に特別に作成されたオブジェクト（後で削除する必要があります）、または使用されているが削除されていないオブジェクトへの参照のいずれかです。リストオブジェクトは、作成する責任はありません。ただ、必要な限り、アドレス指定、アクセス、保存を行うだけです。
1. ...
2. ...
3...
つまり、抽象的なものではなく、具体的な細かいタスクを考える必要があるのです。guiを書かなければならないのであれば、それも意味がないですね。近くのスレッドで純粋構造体を使った素敵なguiを書いている人がいるようです)。