このようにしたらいい。
struct _RTL_CRITICAL_SECTION;
struct _RTL_CRITICAL_SECTION *CriticalSection;
https://timsong-cpp.github.io/cppwp/n4659/basic.lookup.elab#2
https://timsong-cpp.github.io/cppwp/n4659/basic.scope.pdecl#7
探検
C++相談室 part139
レス数が1000を超えています。これ以上書き込みはできません。
このようにしたらいい。
struct _RTL_CRITICAL_SECTION;
struct _RTL_CRITICAL_SECTION *CriticalSection;
https://timsong-cpp.github.io/cppwp/n4659/basic.lookup.elab#2
https://timsong-cpp.github.io/cppwp/n4659/basic.scope.pdecl#7
1つのコンパイル単位内でそれはないだろ。
変数の宣言をした時点で解決可能なクラスが使われるというしごく当たり前な結果に。
https://ideone.com/JyKDmi
https://ideone.com/gTeZlX
https://ideone.com/uPjViG
解決不可能だった場合は、一番近いnamespaceから選択される
https://ideone.com/LpC58v
×https://ideone.com/LpC58v
正しくは、解決不可能だった場合は、同じ階層から選択されるみたい。
AとBがともにNS2に存在する場合
https://ideone.com/m5leMs
コンパイルエラー。 AがNS2 Bがひとつ外側のNS
https://ideone.com/9IY4BC
同階層にBがない場合、グローバルからも選択されることはない。
https://ideone.com/cMhwpW
× https://ideone.com/9IY4BC
〇 https://ideone.com/JOSLLa
ある。
単に人間に見えているタグ名が同じというだけで、コンパイラ内部では、
全く別の識別番号(というより、通常、コンパイラ内部の構造体定義データの先頭アドレス)
になっており、タグ名が同じでも識別番号が異なれば、全く別物と扱われる場合がある。
ものすごい微妙な動きをするみたいだ・・・。
struct Base の定義を見てみると、外側に既に struct Data が定義されていても、
なぜか、Data は、「nested Data」すなわち、Baseの内部クラスの方を「参照」して
しまうらしい。規則性はどこにあるんだろう。まだ英文読んでないけど。
struct Node {
struct Node* Next; // OK: Refers to Node at global scope
struct Data* Data; // OK: Declares type Data
// at global scope and member Data
};
struct Data {
struct Node* Node; // OK: Refers to Node at global scope
friend struct ::Glob; // error: Glob is not declared, cannot introduce a qualified type ([dcl.type.elab])
friend struct Glob; // OK: Refers to (as yet) undeclared Glob at global scope.
/* ... */
};
struct Base {
struct Data; // OK: Declares nested Data
struct ::Data* thatData; // OK: Refers to ::Data
struct Base::Data* thisData; // OK: Refers to nested Data
friend class ::Data; // OK: global Data is a friend
friend class Data; // OK: nested Data is a friend
struct Data { /* ... */ }; // Defines nested Data
};
1. 外部クラスを参照したい場合の書き方：
struct Data {
struct Node* Node; // OK: Refers to Node at global scope
・・・
};
2. 内部クラスを参照したい場合の書き方：
struct Base {
struct Data; // OK: Declares nested Data
・・・
};
【考察】
後者の方は、「『宣言子』を「何にも書かずに」、ただ不完全定義として、
「struct Data」と書いている。こういう独特の特徴的な書き方で、
新しいタグ名の導入と見なされているのではないか。
一方、前者の方は、 「struct Node」だけではなく、「*Node」という「宣言子」を
書いてしまっているので、新しいタグ名の導入とは見なされない気がする。
先日書いた、CRITICAL なんたらの例では、宣言氏を書いていたので、「1」
の方の扱いとなり、外部クラスの参照と見なされた・・・。
D&E の 6.3.1 にそのあたりの解説があるので読んでみると面白いかも。
「病的な例」を含めてわかりやすい解決ルールを作ろうと奮闘したあげくに
まあまあマシなルールとしてそうなったって感じ。
結局、>>610 のような結論であってるのかな？
ﾎﾟｲﾝﾀだからｻｲｽﾞが決定できることになる
ﾎﾟｲﾝﾀなら前方宣言で前方参照できる
1. のほうは構造体へのポインタを宣言してるから、対応する構造体を探して外部の定義を見つけてる。
そんなに微妙でもないと思う。
ｲﾝｽﾀﾝｽのｻｲｽﾞが決定できないし
ｺﾝｽﾀﾗｸﾄﾀも呼び出せない
普通にｺﾝﾊﾟｲﾙｴﾗｰになる
ｸﾗｽ(もしくは構造体)のﾒﾝﾊﾞにｱｸｾｽする場合も同じく
前方宣言でなくｸﾗｽ(もしくは構造体)の宣言がないと
ﾒﾝﾊﾞがわからない
普通にｺﾝﾊﾟｲﾙｴﾗｰになる
前方参照だけで問題はない
ﾏｼﾞで頭悪いｼﾛｳﾄしかいない
不完全型のポインタが完全型になる話なんか今更ドヤ顔でしても恥ずかしいだけだよ
低学歴知恵遅れってなんでこんな頭悪いん
頭悪いくせに頭悪いﾚｽをする
さすが低学歴
C/C++ では、ある1つの宣言で、ポインタ変数を定義する場合でも、それと同時に構造体の
宣言(定義)が行われる事がある。たとえば、
TYPE *ptr; は、ポインタ変数の ptr を定義しているが、TYPE の部分が
struct TPerson { ・・・ }
だった場合は、変数 ptr の定義と同時に、構造体 TPerson も定義する。
さらに、TYPE の部分が、
struct TPerson
であった場合も、不完全定義として構造体 TPerson を定義することがある。
実際、先に挙げた例では、1つの行で、全く始めて _RTL_CRITICAL_SECTION 構造体が
出てきて、その不完全定義と同時にその構造体へのポインタ型のメンバ変数を宣言
していた。
この前方宣言は一番内側の namespace かブロックに所属する扱いになる。
要するに一部の前方宣言は省略できるってだけだよ。
あとは>>613でおk
オール無問題
>>610における2の書き方を前方宣言と解釈するなら、
構造体定義の中で前方宣言可能なﾌﾞﾂが他にはfriendぐらいしか無い件について：
（externは書けない、staticは別の意味になる
しかもfriendは直後に完全型かポインタか参照を要求するですしおすし、
struct Data;という構文の際立ったユニークさは明らかすぐる…
そちらは前方宣言と言って良いかも試練、
struct Data;
struct Foo {
struct Data* m_pData; // struct Fooはstruct Dataへのリンクを有する
/*....*/
};
struct Data {
struct Foo* m_pFoo; // Dataはstruct Fooへのリンクを有する
/*...*/
};
そもそもなんで型の名前やクラス名だけではなくて、タグ名なんてものが存在し続けているのかというと、
struct Data;というのがやりたかったから、およびその必要が（上のようなケースで）あったからに他ならない
struct Data* ptr;の記法が特殊なだけで、
struct Data;は一貫して前方宣言なのでは？
>struct Data* ptr;の記法が特殊なだけで、
(不完全型)* ptr; とされてもコンパイラはptrへの代入や関数に引数渡しするコードを問題なく吐けるから
int val; というのと大して変わらない話
コンパイラにとってはｽｹﾞｰ普通の日常業務
>struct Data;は一貫して前方宣言なのでは？
前方宣言というには>>610における2の書き方で新しいタグ名の導入と見なされるという挙動がﾋﾞｮｰｷ
もはやそれは内部クラスの定義にほぼ等しい（不完全な定義というだけ
struct A {
struct Data* ptr; // as ::Data
struct A {
struct Data* ptr; // ::Data
};
struct A {
struct Data;
struct Data* ptr; // A::Data
};
前方宣言のあるなしで、解釈の変わるstruct Data* ptr;の記法はやっぱり特殊なんだと思うけど。
C++において、不完全な型という概念はあるけど、不完全な定義という概念はないのでは？
と記述した場合、そこからたどれる名前空間のどの階層であっても
事前に宣言または定義が行われていれば、その時点で特定可能なstruct Dataへのポインタと解釈されるけど、
解決不可能であった場合には、struct Aと同階層にあるstruct Dataとみなされる <- この動作が特殊
バカなのかな？
なぜなら、次のコードの(A)、(B)のコメントアウトを外しても
それ自体はエラーにならない（つまりstruct Bar; は同一スコープ内で重複が許される
このときは(D)でエラーになる
しかし、(A)と(B)をコメントアウトすると何のエラーにもならない
むしろstruct Bar* m_pBar; の方が普通に前方宣言的に働く（Fooのスコープに縛られない
#include <stdio.h>
struct Foo {
//struct Bar; // (A)
//struct Bar; // (B)
struct Bar* m_pBar; // (C)
};
struct Bar {
int x;
int y;
};
struct Bar* g_ptr;
int main()
{
Foo test;
test.m_pBar = g_ptr; // (D)
}
△： struct Bar;が前方宣言では「ない」という主張
○： 構造体の定義ブロック内のstruct Bar;が前方宣言では「ない」という主張
で、struct Bar* m_pBar; の方が普通に前方宣言的に働く（スコープローカルな新たなタグBarを作ったりしない）のに --(1)
構造体の定義ブロック内のstruct Bar;は明らかにスコープローカルな新たなタグBarを作り出すという変態機能を有している --(2)
つまり(2)を指して一貫して前方宣言だと主張するなら、(1)のstruct Bar* m_pBar;も前方宣言の一種だと言わねば不正直である
構造体の定義ブロック内のint i;は明らかにスコープローカルな新たな変数iを作り出すんだけど、
それも変態機能だと思うの？
>struct Bar;は明らかにスコープローカルな新たなタグBarを作り出す
構造体定義ブロック内に限らずとも、前本宣言はもともとすべてスコープローカルだけど。
それはグローバルであっても、中間階層の名前空間であっても、
多重ネストの構造体の中間階層で会っても同じ。
ポインタでない場合というと
struct aho;
struct boke
{
aho begin();
aho end();
};
こういうのもあるな
記憶だと、手元にある ARM(Annotated Reference Manual) にも、確か
何か書いてあった。
見るのがメンドクサくてここに質問を書いたんだ。スマン。
>>636
なるほどｽｹﾞｰよくわかりた
>>635
構造体の定義ブロック内のint i;は2回同じものを書いたらエラーになるから宣言ではなくて定義じゃわﾊﾟｵｰﾝ
構造体の定義ブロック内のint i;は2回同じものを書いたらエラーになるから宣言ではなくて定義じゃわﾊﾟｵｰﾝ
その他の方々もだいたいおk
RPC
・WM_COPYDATA メッセージで送り合う。
Windows ならメールスロットとパイプもアリかな。
データ本体（ｽｹﾞｰ巨大かもしれない）の共有にいちいち通信時間を要する手段は除外されるんじゃ…
やっぱプロセス間の同期をミューテックスか何かのプロセス間でも使える同期オブジェクトまたはソケット通信とかでとる前提で、
データ本体のはメモリ共有かファイルという手段になるのではなかろうかと、
OpenClipboard
共有のニーズが生じてからファイルを作るのならそうだが
最初から共有データとしてファイルが存在する場合はそうではない
というわけで質問者の意図にはようわからん点がある
想像力が欠如すぐる…
共有しようとするデータのサイズが1 TBなら、全部送ろうとしたら3GB/sの転送速度でも333秒かかる
ファイルを1個置いといてfseek()する方がまだまし
別の計算機でﾃﾞｨｽｸｱｸｾｽさせて
それを通信でやりとするｱﾎなｼｽﾃﾑ構成にするﾔﾂがあとを絶たないのがよくわかる
著しい低学歴知恵遅れがそういうことよくやる
何度も何度も計算機Aから計算機Bの数十ｷﾞｶﾞを超える共有ﾌｧｲﾙの内容を計算機Aにすべて読み込んで
計算機Aで処理をなん百回も繰り返す
しかも共有に使うSamba
つまりNBT（）
Windows共有とまったく同じ
つまり毎回毎回計算機Bにﾃﾞｨｽｸｱｸｾｽして通信（NBT経由）使って
計算機Aで読込むということを意味する
それで遅い遅いなんでといってたからな。。。
世の中には想像を超えるこんな頭悪いのが現実にいる
むしろ毎回データ全部を丸ごと送る想定なら、高速な通信手段で良くて
「データ共有する」（>>643)という質問者の動機にならない件について：
メモリ共有であれば通信より高速を目指す目的で毎回データ全部を丸ごと送る風に使われることもあるが
質問者>>643は共有手段として「ファイル」も挙げているから
いきなりそこまで話を限定できないﾜｹ
データベースみたいなデータを出し入れ管理するプロセスなりサーバなりを設けるというのも
>>643の答えに含まれるのかもしれん…
>>656の思い込みとはうらはらに、
データベースXにアクセスするプロセスA、Bは、明らかにXが管理するデータを共有しているが、
Xの管理するデータ丸ごとを毎回送りつけ合うわけではないし、
1. プロセスAが巨大なファイル中の一部のデータの読み込みをファイルシステムに要求する
2. ストレージから読みだされたデータが返される
1. プロセスAがプロセスBが持つ巨大なデータ中の一部のデータをRPCで要求する
2. プロセスBからデータが返される
データベースなら例えばSQLでやりとりやね
既にオンメモリで数ギガ扱うのに対応してるしプログラム間通信も高速
なにより統一されたプロトコルでオンメモリからネットにまでアクセスできるのが便利
これを実現する手段として>>644-646のような手段があるわけだが、それ認識してなかったのか。
COPY_DATAやメールスロットはOS提供の簡易的なプロセス間通信サービス
RPCはデータ以に上さらに高度にアクセスするプロシージャ
データをやり取りする手段の話ね。
>これを実現する手段として>>644-646のような手段があるわけだが、それ認識してなかったのか。
>>644-646はデータを送りつけるという通信の手段のみ述べており、データ共有の実現に行き着いていない
もちろん通信だけでもプロセスAとBの間で情報の共有はできるが、
>>644-646の言説だけでは、情報を表す入れ物である「データ」の共有に行き着いていないﾜｹ
>>644-646の言説が含意するのは、同じ情報iを、プロセスAがデータa、プロセスBがデータbとして持っている状況、
というところ止まりで、aとbは別物。さらにいうと、同じ形式のデータであることすら導くことができない
この差異は形而上の問題ではなく、現実の設計の問題である
>>644-646だけでは、AがBに情報伝達するにあたりBに通信する（通信のエンドポイントとしてBを起こす）必要があるから
Bが風邪で休んだりするとAの仕事まで止まってしまうことが確定する
一方、AがExcelシートXに情報を書き、Bが必要なときXの情報を参照する、という方式だと（他に付帯条件が無ければ）Aは問題なく仕事を続けられる
データ共有というのは後者
どっちにしても通信時間が云々というのが的外れなのは変わらない。
見苦しい。
Excelのブック共有だってExcelアプリケーションがファイル共有とか使って頑張ってるから実現できてるんだし
そもそも>>643は手段レベルの話だし
結局通信についてもデータ共有についても素人なのでした
最近覚えたのかな？ w
普通の伝書鳩より訓練が難しいんだぞ
実は、GDI の Device Context の HDC も、プロセスの垣根を越えて渡す方法がある、
メモリコピーは伴わずに。やり方は、PrintWindow(HWND hWnd, HDC hDC, DWORD flag)
API を使って、WM_PRINT メッセージを送るというもの。これを使えば、グラフィックデータ
ならBITMAPデータも伝達できる。たとえば、HDC を用いて GDI+ の LockBits() を
使うと良い。L。
https://mevius.5ch.net/test/read.cgi/tech/1474384848/338
私はwebしかやったことないので組み込み系の経験はありません
ここはダーマの神殿ではない、と言いたいとこだけど、年齢によるね。
未経験でも30歳前後なら余裕、35歳超えなら諦めろ。
というか組み込み系でC++を使っている分野ってあるにはあるけどそんなに多くはないよ。
組み込みLinuxでのアプリ開発ぐらいなんじゃない？
老害から言わせてもらうとアレは組み込みソフトじゃないけど。
25です
Linuxでのアプリ開発分野ならあるんですね‥
別に組み込みじゃなくてもいいんですけど、探したら組み込みがほとんどって感じです
本気で探しているのですが、難しいです‥
頑張って探してみます
募集要項に経験者って書かれてても怖がらずどんどん応募してみては？
相変わらずこの業界は人手(奴隷)不足なのでそう苦労せず転職できると思う。
売り手市場の今は転職先の会社を見極めて選り好みすることができるので、下手に妥協せず納得行くまで転職活動頑張って！
ありがとうございます！
目標に向かって頑張ります
相談に乗ってもらってありがとうございます
相談してよかったです！
それように人員を募集してるかっていうとしてないけど
普通に羨ましいです‥
自分は中々見つからないです
組込でガッツリは使ってないけどBetter CとしてC++使ってる所はそれなりにあるよ
それ以外だと大規模なゲーム開発くらいしかあんまり聞かないな。
言語縛りにする意味がわからんな
メタプログラミング駆使して行数少なく書いてもぶっちゃけ大した価値ない
逆にやりすぎて嫌われるのがオチ
CPU、キャッシュ、バスアーキ、OS、ABI、Toolchain、各種デバッグ手法などを知ってる方が重要
あんなしょうもないのを書けないほうがおかしい
罠や地雷や落とし穴が満載で人間が書くもんじゃない
今いるのやや学術よりのとこなんだけど、回りがPythonばかりになってきて690の気持ちが分かってしまう
QtはQtCreatorが使いづらくて
制御系とかそもそもGUIが無い環境に実装出来ないから？
それに最近はGUIはweb方面のエコシステムを流用するのが流行だしはっきり言って厳しい
cairo を取り入れようとか、
ウェブアプリケーション風の DOM ベースのやつ (?) とか。
動作モデルが色々とあるので、
どれかに統一するのはしんどいと思う。
ベースの動作モデルを意識させないほど厚いライブラリを
標準に入れるのもちょっとどうかと思うし。
そういうのは「言語」かってことだよ
ISO/IEC14882は言語を定義する規格で、
GUIを定義する規格なら別の文書番号になるだろう
OSを定義する規格がそうであるように
標準のスレッドすら不要
大抵結局native handle使うはめになるし
デバッガと連携しないし
一方でatomicは使えるな
肴はあぶったイカでいい
ノートPCのキーが勝手に連打されるような状態になったので、
「キー入力の連打を感知したら、連打された入力をキャンセルする」というソフトが欲しいのですが、
どこかにあるでしょうか？
無ければ、自作も考えますが、キー入力をキャンセルさせる方法がよくわかりません。
いわゆるチャタリングってことかな。
ざっとググってみた感じだと ccchattttter や Keyboard Chattering Fix というソフトがあるみたいだね。
ソフトウェアとしては、他のプロセスが受け取るイベントを横取りすることになるから、
アプリケーションレベルでやるならフックを仕掛ける (DLL Injection など) か、
あるいはデバイスドライバのレベルでどうにかするという方法も考えられる。
＞ ccchattttter や Keyboard Chattering Fix
さっそく、試してみました。
これらは、同じキーが連打された場合のみのキャンセルでしょうか？
違うキーが連続で誤入力されたりするので、その場合は対応できないかも？
フックするというのは、どうやるのかわかりませんが、ちょっと調べてみます。
constexpr unsigned N = 10;
std::array<int, N> arr = {{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 }};
2行目の 二重の中括弧は何を意味してる？
どう解釈するの？
それキーボードに異物が入ってないか？
かつて俺が面倒見てた客先ではホチキスの針が原因の障害が複数回あったぞ
異物が入っていない正常な状態で起きるチャタリングは
設計の段階でしっかり対策されているはずなので
それまで問題なかったキーボードが突然そういう状態になったのなら
何らかの事故を疑ったほうがいい
以下の二種類あるらしいけど、何で2.の方は二重括弧になってるの？
外側の括弧の意味、内側の括弧の意味がそれぞれ知りたい。
1. std::array<int, 5> n = {1, 2, 3, 4, 5};
2. std::array<int, 5> n { {1, 2, 3, 4, 5} };
内側の括弧はコンストラクタの仮引数がinitializer_listであることに対応
= は、一時オブジェクトを作ってコピコンかムブコンという意味だったが
C++17でこの意味が廃止され単なる過去の名残となった
つまり、2. の方は、以下の記法の ()を{} に変えただけということ？
3. std::array<int, 5> n ( {1, 2, 3, 4, 5} );
つまり、コンストラクタ名を Xxxx とすれば、
Xxxx( リスト型 &list1 ) {
}
みたいな事になってるということかな。
↑ libstdc++ の template struct(?) の array のソースを見てみたら、
// No explicit construct/copy/destroy for aggregate type.
とコメントされていた。明示的なデストラクタが何も無いので、その {・・・}
の部分は、コンパイラが初期化処理まで全部やってるってことなのかも
知れないけど、どういう仕組み？
TYPE _M_instance[N] みたいなメンバがあるけど、ここにコンパイラが初期値を
書き込むんだろうか。どういう仕様なんだろう。
ああなるってことかな。まだよく分からん。
1. CPerson person = CPerson( 25, MALE, "Yamada Taro" );
2. CPerson person = { 25, MALE, "Yamada Taro" };
3. CPerson person { 25, MALE, "Yamada Taro" };
OpenGLを使って
注視点を行列で回転させたいのですが
どなたか参考になるサイトやソースが
あれば頂けないでしょうか
std::arrayはpublicに内部の配列を公開してて、コンストラクタデストラクタを一切書かないことで集成体となって、その初期化は集成体初期化で行う
二重かっこの外側はarrayの初期化、内側のかっこはstd::array内部配列への集成体初期化
ただし、C++14以降は二重かっこを省略できる
https://cpprefjp.github.io/lang/cpp14/brace_elision_in_array_temporary_initialization.html
＞バスアーキ
古い8086とかだったら書籍に載っていましたが、最近はどうでしょうか？わけのわからない仕様書しかないのでしょうか？
なるほどだんだん分かってきた。
struct CPerson {
int m_dat1[2];
int m_dat2[3];
};
なら、古い C の時代から、確か、
CPerson person = { {1,2}, {3,4} }; // (1)
みたいに書けた。だから、
struct CMyArray {
int m_dat1[5];
};
なら、
CMyArray a = { {1,2,3,4,5} }; // (2)
と書けるのは当然、ってことだよね。それでC++14以降はさらに、
(1)の場合は、全部一列に並べて、
CPerson person = { 1, 2, 3, 4 }; //(1')
と書ける様になった。結果として、(2)も、
CMyArray a = { 1,2,3,4,5 }; // (2')
と書ける様になった。
そういうことだよね、多分。それでさらに、「=」を省略したような書き方も
できると。そういえば昔から、コンストラクタを持つ CPerson の場合に、
1. CPerson person=CPerson(・・・)；
2. CPerson person(・・・)；
は確か等価で引数つきのコンストラクタが呼び出されるんだった。
そして、新しい C++ では、小括弧 () を、波括弧 {} に書き換えることも
可能になったみたいな話で、
3. CPerson person=CPerson{・・・}；
4. CPerson person{・・・}；
みたいなことも書けるようになったのかな。
その通りだと思う
集成体以外で{}を使う初期化を一様初期化と呼ぶそう
https://cpprefjp.github.io/lang/cpp11/uniform_initialization.html
OpenGLを使って
注視点を行列で回転させたいのですが
どなたか参考になるサイトやソースが
あれば頂けないでしょうか
確か、古くからある OpenGL の場合、GL_XXXX 見たいな定数を指定して、ViewMatrix
見たいなのを設定するんだったはず。
http://www.mss.co.jp/technology/report/pdf/19-08.pdf
http://www.mss.co.jp/technology/report/pdf/18-07.pdf
スレチ
ここにもゲ製作技術板にもGLスレあるだろ
あとは線形代数の勉強しろとしか
>>730
そんな手順の話じゃないと思うぞ
スレチ
「const auto 関数名 = [変数名](引数) -> 戻り値の型」
例えば、以下のように書くとcに5が返ります。
int X;
const auto hoge = [X](int a, int b) -> int
{
return a + b;
}
int c = hoge(2, 3);
[X]のところは、宣言してある変数ならなんでもいいみたいですが、何者かよく分かりません。
知らなかった。。
その[X]は、関数外部の変数 X を関数内部で使えるようにする意味があるらしい。
それを書いておかないと、グローバル変数やクラスのメンバ変数以外は、参照できなく
なるようだ。
必要ないなら空はその通りだと思う
お前さんが思い浮かべてるカッコで括ったそれと同じものかどうかは知らん
>お前さんが思い浮かべてるカッコで括ったそれと同じものかどうかは知らん
特に何も思い浮かべてないけど。
class Hoge {
int m_x;
Hoge(int x) : m_x(x) { }
int operator(int a, int b) const { return a + b + m_x; }
};
int main() {
int X = 10;
Hoge hoge(X);
int c = hoge(2, 3);
printf("c=%d\n", c); // 15
}
C++におけるラムダ式の存在意義を半否定している
と思ったり
思わなかったり…
#include <stdio.h>
class Hoge {
int& m_x;
Hoge(int x) : m_x(x) { }
int operator(int a, int b) const { return a + b + m_x; }
};
int main() {
int X = 10;
Hoge hoge(X);
int c = hoge(2, 3);
printf("c=%d\n", c); // 15
X = 20;
int c2 = hoge(2, 3);
printf("c2=%d\n", c2); // 25
}
誤： Hoge(int x) : m_x(x) { }
正： Hoge(int& x) : m_x(x) { }
つまり、
auto f1 = [](int x){ retrurn x;}
auto f2 = [&](int x){ reutrn x; }
この場合、f1の型は通常の関数ポインタ、f2の型はstd::functionになるということ。
たとえば、
void hoge(auto func(int x)->int)
{
.....
}
こういう関数を作ったとして、f1は引数に渡せるけど、f2はエラーになるし、
f2を渡そうと思ったら、std::functionで受ける必要がある。
多分、
>この場合、f1の型は通常の関数ポインタ、
mjk、
>>748に関数ポインタにならずにすむからくりまで示したのに…
>>755
f2はテンプレート引数で渡せば良い
主にそういう目的のﾌﾞﾂのはず
f1は同じシグネチャの関数ポインタに暗黙変換可能、であるだけで型自体はコンパイラ依存のラムダ式の型
普通にf1を引数渡ししてインライン展開を気体するものでだいたい合ってるはず…
今から書くコードで積極的に使うもんじゃない
qsortみたいな用途だったら、新しく書くコードでも関数ポインタが適していると思うけどね。
std::functionよりテンプレートの方が早いみたいだね。
関数の静的型チェック、自発的なメモリ管理
って恐ろしく相性悪いと思われる。
そんな無理するくらいならおとなしく継承、オーバーライド使った方がマシ。
32バイトくらいの memcpy() でも、数マイクロ・セカンド位(1.0*10^(-6)(s))かかる事が分かった。
ちなみに、1クロックは、3.3 * 10^(-10) 位なので、たった32バイトに1万クロックくらいかかって
いる事が分かった。
ためしに単純な for ループと DWORD *ptr で転送してみても結局、それ位の
小さなサイズだと、同じくらいかかることも判明。
同じマシンでも、もっと大きなサイズのコピーだと、for ループで行っても、
1回のループで、4クロックくらいしかかからない。
推測だが、jmp 命令は、10バイト程度前の番地に戻る程度でも、ループ回数が
少ない場合は、物凄く極端に遅いが、ループ回数が多くなるとなんと1クロックで
実行できるようになるらしい。
ただし、余り定かではない。
いくらなんでも、32バイトで1万クロックは遅すぎるように思う。
ちなみに、Sleep(1000); とすると、ちゃんと、1.0 (s) と表示されるので、
速度の計算ミスではないはず。
「高分解能」と言っても、1.0 マクロセカンド位の精度だったとは、予想外・・・。
memcpy1つとってもそうそう単純なものではない。
引数がどんな型を持つ関数を渡すかを事前にどこで決めるかが問題だし、
それ事前に決められるならクロージャーの必要性は低くなるだろ。
あと資源解放のタイミングをどうするかを明示させるシンタックスってのは多分相当難しい。
その辺、クロージャーを用意する言語は普通はGCに任せる。
「関数を渡す」って何がどこに関数を渡す話なんだろうか。
var ChildInput = React.createClass({
_onChange: function (e) {
this.props.onChange(e.target.value);
}
}
)
とかするやつをイメージしてる。
>クロージャって関数とその外側の環境を合わせたものだろ
それは新たな関数を作ったことになるんじゃー
>>748の
> int X = 10;
> Hoge hoge(X);
という部分は、f(a, b) = a + b + 10という関数を作ってゐる
Xを変えることによってg(a, b) = a + b + 9とかh(a, b) = a + b + 8とか
Hogeクラスのクロージャでいくらでもバリエーションを作れる
>>748で言えばHoge::operator()が関数でm_xがその外側の環境だろ。
そこで関数を渡すとか作るとかあるいは静的型チェックと相性が悪いというのが
どういうことを言っているのかわからん。
関数オブジェクトを作ってるというならわかるけど。
従来と比べて特に良くなったり悪くなったりするわけはない。
オブジェクトの寿命の管理がやりづらいってのは C++ では今更な話で、
ラムダ式がどうこうとか言ってもしょうがなくない？
>m_xがその外側の環境だろ
オブジェクトhogeの中に囲い込まれている（キャプチャされたﾌﾞﾂである）からちげう
hogeをコピーしたり別の関数に引数渡ししたら付いていくという意味でも外側の環境ではない
諦めたらそこで終了だよ！！！
開発環境はvisual studioです
PowerShell でも良い
command_1 ;
command_2 ;
コマンド1 が終わったら、メール送信するなら、
command_1 ;
メール送信 ;
複雑な処理は、コマンド・シェルスクリプトよりも、Ruby などで作る方がよい
今は知らんけど、数年前だったら、メール送信は知識が結構必要だった。
SendMail Transfer Protocol なるものを使うんだけど、それを便利に発行できる
関数なりCUIプログラムがあれば使えるんだけども。
Linux だったら、aaa.txt に以下のような内容を書いて、
---------------------------------------
From: my@mail.address (あなたのメールアドレス)
To: foo@example.com
Subject: This is test mail.
(ここに空行を入れる。ここまでがヘッダ。ここから先がボディ)
メールの内容
.(ドットのみの行を入力すると終了)
---------------------------------------
$ sendmail foo@example.com < aaa.txt
とすると後れるらしい。sendmail は、CUI コマンド。
だから、VisualStudio からだと、
system( "sendmail foo@example.com < aaa.txt" );
とすれば、sendmail コマンドが存在しているなら動作する。
>>774で言っている関数の外側の環境って意味だよ。それがクロージャの中なのは当然。
いいかげん、元の「関数を渡す」って話からずれまくっているが、結局どういうことを言いたいんだろう。
いやだからc++なら継承でメソッドでオーバーライドする方が
わかりやすいし、資源も管理しやすいんじゃない？って話。
他の言語にあるからみたいな理由で合わんもの入れてもなということなんだけど。
>結局どういうことを言いたいんだろう。
クロージャ＝関数
特に()のオーバーライド（int Hoge::operator()(int a, int b) { ... }）までやった場合、
HogeクラスのインスタンスhogeはC++の構文的にも関数同然に機能の呼び出しを行える
（関数オブジェクトとかファンクタとか呼ばれるやつになる
>元の「関数を渡す」って話
クロージャ＝関数なのであるから、クロージャを、クロージャを受け取る他の関数またはクロージャに渡すという話、-- (A)
継承を使う場合のsome_typeのベースクラスをsome_typeのベースクラスを受け取る他の関数に渡すことに対応する --(B)
この場合、クロージャを使うやり方に対する継承を使うやり方のデメリットは…
、と静的型チェック周辺の話に持っていくことができるが、その前に(A)や(B)が共通認識になったのか、それとも理解不能なのかどうか確認しておきたい
>クロージャ＝関数
そういう前提で言っていたのか？
ID:AQ4G8Wg10は明らかにクロージャと関数を使い分けているようだが。>>766>>773
じゃあそこは了解したとして、(A)(B)の条件の下でもう一度>>768の質問をするよ。
関数の静的型チェックとクロージャの相性が悪いところってたとえばどんな？
（マルチキャストみたいなおまけ機能もファンクタとして実現したクロージャになら追加できる
ファンクタとしてクロージャする分には型安全性も同等なので、ファンクタとデリゲートは混同上等のはず…
>関数の静的型チェックとクロージャの相性が悪いところってたとえばどんな？
知らん
>>766はクロージャの実現方法について黒魔術的な何かを想定しているのではないか…
C++におけるクロージャの簡単な実現方法はファンクタ、であって、ファンクタには特に型安全や資源解放に関するファンクタ固有の問題は無いと思う
何しろファンクタは普通のクラスHogeの普通のインスタンスhogeとして>>748風に書けるので…
一方、広義のクロージャは、変数を束縛するしくみ＝クロージャなので、型安全という概念をそもそも含まない
この広義のクロージャをC++上で実現しようとしているのだとしたら知らん
> いやだからc++なら継承でメソッドでオーバーライドする方が
> わかりやすいし、資源も管理しやすいんじゃない？って話。
だからそんなことはないと私は述べてる。
ラムダ式を使いたいときというのはほとんどの場合は小さな関数を作りたいときなんだよ。
それも一回しか使われないような使い捨てのものをだ。
使い捨てるのならば、別の場所で定義して (名前を付けて) から使うのはまわりくどい。
わかりにくくて管理しづらくなる。
もちろん、場合によってはラムダ式が適さない場合だってある。
そういう場合まで何もかもをラムダ式に置き換えろってんじゃないだ。
ラムダ式が適しているときにラムダ式を使えってだけのことで、しかもそれは案外に多いってことだ。
>>776ではクロージャと関数を区別して書いていたのに対して、>>777は単に
>クロージャ＝関数
と言いたかっただけなんだな。
誤： 変数を束縛するしくみ＝クロージャ
正： 変数を束縛して作った関数（ただし束縛すべき変数のリストが空のときもある）＝クロージャ
型安全な言語なら型安全に、そうでない言語でもそれなりにやっぱクロージャ＝関数ェ、
>ラムダ式を使いたいときというのはほとんどの場合は小さな関数を作りたいときなんだよ。
>それも一回しか使われないような使い捨てのものをだ。
ここが自分の感覚と違う。
ラムダ式を使いたい時ってもう少し動的な関数作成に関わる場合という感覚。
単に名前付けを省略したいくらいならどうとでもなると思うし、個人的にはそんな興味ない用途。
何かを根本的に勘違いしてるとしか思えない
面倒だってぶつくさ言うやつ定期的に現れるよな
なぜc++使おうとしているのか、自分を見つめ直した方がいいぞ
有り得ない。
自分で定義したクラスをインスタンス化してグローバル変数として扱いたいです。
グローバル変数には実体がないといけないと思うのですが、new演算子は
ポインタにしか使えないですよね？
この場合どうしたらいいでしょうか
myclass mc;
とか定義すればよい
いやだからc++でなんでラムダ式とか入れちゃうのかっていう話をだね。。
jsのノリを無理やり入れたがってるのはc++の仕様の方で別に俺は入れたくない
って意見なのだが。
wwwwwwwww
オブジェクトとクロージャはメカニズム的には似たようなもんだ
という感覚は言語処理系に明るい人の感覚としては元々ある。
C++ にラムダ式が追加される前に書かれたこの記事が面白いよ。
"クロージャとオブジェクトの微妙な関係"
http://www.itmedia.co.jp/enterprise/articles/0703/29/news069.html
JavaScript の「オブジェクト」だって、その内実は環境への操作だ。
つまりはクロージャを基礎にしてオブジェクトに見せているんだから、
その逆をやる言語があったって別に不自然なことではなかろ。
なるほど！
教えてもらったとおりnew使わないでできました！
関数・メソッドから、引数渡しでもないのに、外側の変数を参照できるから
Ruby のブロックがクロージャ。
ブロックの外側の変数が参照できる
一方、Ruby の関数は、外側の変数を参照できないから、
JavaScript, Python, PHP よりも、すごい強固
Ruby だけは、クロージャの外に、関数をスコープを作っている。
さらに関数の外側がクラスで、クラスの外側がモジュール
モジュール > クラス > メソッド(関数) > ブロック(クロージャ)
Ruby 独特の構造！
しかし理解すればするほど、c++ならやっぱクラス生成でよくね？って気になるが。
繰返して述べるが、 C++ のラムダ式は単純なクラスの定義と使用を同時に出来る構文糖でしかない。
何故か「クロージャ」と混同した書き込みがあるが
(もちろんいわゆるクロージャの概念からおおいに影響は受けているのだろうが)
C++ のラムダ式は C++ に新しい概念を導入するものではない。
これはさすがに言い過ぎ
関数型のリテラルという概念は C++98 にはなかった
だから C++11 になったとき新しく憶えた
既存の概念の組み合わせでできているから
割とすんなり憶えられたけどね
いやまあ正解なんだけどさ・・・
ん、cl.exe の 19.16.27024.1 では通るが？
ようなGUIプログラムを作って試していて、local auto 変数に確保した
16バイトの char 配列に、sprintf で色の #RRGGBB の文字列を合成
して JS に渡して canvas の context の style に直線の色を設定していた。
で、同時に、KeyDown イベントでで20文字ほどのグラフィック文字列を出して
いた。なお、そっちの方でも、全く同じ関数を使って、上記の色の文字列
を合成していた。
すると不思議なことに、KeyDownイベントで文字列を書いた後は、
必ず、直線の方の色が変わってしまう。必ず青色で書くようにしているはずなのに。
ログをとってみると、
char szBuf[16];
sprintf(szBuf, "#%02X%02X%02X", r, g, b);
で szBuf に対して、最後の 0終端文字が、書き込まれていないことが判明。
よく見ると、KeyDownイベントで色のためではなく、出力したい
文字列そのものの文字の一部が直線描画の方の szBuf の #RRGGBB の直後に
残ったままコピーされているように振舞っていた。
ためしに、sprintf() の命令の直前に、memset(szBuf, 0, 16); とすると
正常化することも確認した。
Emscripten のライブラリの不具合だろうか？
memset( szCol, 0, 16 );
memset( szCol, 'W', 10 );
szprintf( szCol, ・・・ );
とした場合は、W の文字が残ったままになることも分かった。
szCol[7] = 0;
とすると、正常化することも分かった。
エラーがでてしまいます。
ポインタの宣言
TimerParameter *_timerParameter;
インスタンス化
_timerParameter[_timerSize] = new TimerParameter(time, function, one_loop);
TimerParameterコンストラクタ
TimerParameter::TimerParameter(ULONG time, void(*function)(), bool one_loop)
{
_function = function;
_oneLoop = one_loop;
_timeSpan = time;
resetTimer();
}
自分で作ったTimerParameterクラスをnewして_timerParameterメンバに入れると以下のエラーが発生してしまいます
sketch\timerState.cpp: In member function 'bool TimerState::timerSet(long unsigned int, void (*)(), bool)':
timerState.cpp:14:30: error: no match for 'operator=' (operand types are 'TimerParameter' and 'TimerParameter*')
_timerParameter[_timerSize] = new TimerParameter(time, function, one_loop);
インスタンス化の左辺が適切でないのが原因だと思うのですが、この書き方はダメなのでしょうか？
newすれば実体確保できるとの認識でしたが、やはり別に実体を用意しないといけないのでしょうか
https://www.s-cradle.com/developer/sophiaframework/tutorial/Cpp/newdelete.html
new TimerParameter(...)の型はTimerParameter *
あと、
Type * ptr;
ptr[2] = createType();
なんてやっちゃダメなのわかってる？
Type * ptr;
ptr = new Type[10];
ptr[2] = createType();
ならいいんだけど
あと、"_"で始まる名前は処理系予約だし
timeはcの標準関数にtime_t time(time_t *t);があるんでやめれ
{1.33333334, 3.99918277},
{2.56883338, 1.29994666}
}
このようにvector<vector<float>>をdouble型の要素で初期化しようとすると縮小変換が必要とのエラーが出ます
どうしたら縮小変換しつつ初期化出来るんですかね？
>ならいいけど
よくないだろ。なぜコピーさせるのか
Developerとして参加するプロジェクトをどうしたいとか、どんな価値を提供できるかとかが重要じゃないかな
C++をより良い言語にしたいです
今はアルゴリズムの研究をしてるのですが、C++をより良い言語にしたいと個人的に思ってるのと、自分が作った言語機能を人に使ってほしいんです
>>848
Boost‥
100回リジェクトされた頃には相当な経験が詰めるはずなので挑戦してみます
C++自体を改良したいなら標準化委員会に行くかコンパイラの開発に参加しよう
どっちも検討してみます
char型はwindowsがsjis、それ以外がutf8、
wchar型は64bit linuxが32bitで、それ以外は16bit、
どのプラットフォームでも同じようにつかえるchar16_t/char32_tはAPIやライブラリが未整備な上、エンディアンの問題がつきまとう、
と、マルチプラットフォームで各種文字コードの透過的な相互運用は事実上不可能な状態だからな……
デバッガでpngのシグニチャ確認したら臼ngとなるとか、コメントにπを書いたら赤の波線が出るとか。
ユーザーのコードページを変える以外に方法がないらしい。
方法あったの！？
エンディアンの問題も、x86,ARMに続いてRISC-Vがリトルだから、流れとしてはリトルで統一ってことになるのかな。そうなったら楽でいいなw
結局リトルに収斂したな
おれは昔からリトルが自然と感じてたのでいい流れだ
ネットとの相性が悪いのは残ってしまうが
(2) で (3)の vsprintf() を呼び出そうとした瞬間に、なぜか (4) に来ずに、
(5)に戻ってきて a4 に制御が戻って来てしまうことが判明。タイマーイベント
を使ってる。誰か原因の見当が付く人いない？
EM_ASM( {
function js_OnTimer() {
console.log( 'begin of js_OnTimer()\n' ); //a1
var cl_OnTimer = Module.cwrap('OnTimer', 'number', ['number']);
console.log( 'js_OnTimer(), before calling cl_OnTimer(1)\n' ); //a2
var rc = cl_OnTimer(1); //a3
console.log( 'js_OnTimer(), after calling cl_OnTimer(1)\n' ); //a4
console.log( 'end of js_OnTimer()\n' ); //a5
}
setInterval(js_OnTimer, 1000);
});
extern "C" int OnTimer( int a ) {
OnTimerCore();
return 0;
}
void OnTimerCore() {
MyPrintf( "begin(MyPrintf) of OnTimerCore(), %d", 123 ); // (1)
printf( "begin(printf) of OnTimerCore(), %d\n", 456 ); // (5)
}
void MyPrintf( const char *pszFormat, ... ) {
char szBuf[2048];
va_list va;
va_start( va, pszFormat );
EM_ASM( { console.log( 'MyPrintf, before call vsprintf()\n' ); }); //(2)
vsprintf( szBuf, pszFormat, va ); // (3)
EM_ASM( { console.log( 'MyPrintf, after call vsprintf()\n' ); }); //(4)
va_end( va );
}
原因は、main 関数の最後に書いておいた、次のループにあった :
for ( ;; ) {
emscripten_sleep(36000000); // 何日間も待つ。
}
このループをコメント・アウトするだけで、vsprintf() が1つ前の戻り先に
戻ってしまう不具合も、sprintf() が 0 終端文字を書いてくれない不具合も
共に起きなくなった。
このループを書いていたのは、Emscripten 1.35 で、かつ、
wasm ではなく、asm.js で試していたときに、キー押下イベント
などが発生した時に
Assertion failed: the runtime was exited (use NO_EXIT_RUNTIME to keep
it alive after main() exits)
というエラーが出るためだった。つまり、main() 関数が終わると、
「ランタイム」(ランタイム・ライブラリ?) も終了してしてしまうので、
main() を終わらせられなかった。だから、main() の最後に、なんらかの
無限待機の仕組みが欲しくなって書いていたのだった。
現在は このループを除去しても警告が出なくなっているが、
Emscripten の Version を上げたせいか、asm.js ではなく、wasm の方を
使うようになったせいかは分からない。
あとから拡張しやすいって意味か？
ビットアドレスとバイトアドレスの増加方向が同じになるとかかな。
ワードサイズが変わっても低位バイトの位置が変わらないから拡張しやすいってのも
もちろんあると思う。
まあ、FPGAと高級言語を使うようになってからは滅多に気にすることは無くなったけど
cast するときにも便利。
メモリに書かれた 32BIT整数を 8BIT 整数として取得したい際など、
先頭アドレスが変わらないので、速度効率が上がりやすい。
もし、BIG ENDIAN だとそのようなときに、「3」足さないといけなく
なってしまうと思う。
BYTE u8;
u8 = (BYTE )u32;
とするコードがあったとする。u32 を、ポインタで置き換えたいとき、
Uint32 *pUint32;
u8 = (BYTE )*pUint32;
と書くのも正解だが、
u8 = *(BYTE *)pUint32;
と書くのも正解で、実は、後者の方が効率は良い場合があるとされる。
なぜなら、メモリから前者は4バイト読んでから上位バイトを捨てるが、
後者では最初から上位バイトを読まないから。
この場合、Little Endian だと、後者の書き方でも混乱が少ないが、Big Endian
だと何を意味しているのか分かりにくくなる。というのは、
(BYTE *)のようなポインタ型への cast は、旧来の C では、アドレス値自体は
変更せずに、型だけを変更するというのが伝統的な実装だったため
(ただし、C++ の場合、多重継承していた場合は、その原則を破ってアドレス値が
変化する事があるが。)。
BigEndian の場合、最後の書き方の実装に不安定要素が残るように思える。
ありがとうございました。
配列の実態作ったらできました！
_を接頭文字で使うのは結構規模の大きいオープンソースプロジェクトのソースで
メンバー変数の頭に_を使ってたのでやってました。
気を付けます。
話は少し変わるんですが、>>809でクラスをnewせずに使うというのが書かれていますが、
オブジェクトをnewせずに使うことって結構あるんでしょうか？
普段C#やっているのですが、クラスは基本的にnewでインスタンス化して使うものと思っていたので、（コンストラクタで特に初期化処理がなくても）
>話は少し変わるんですが、>>809でクラスをnewせずに使うというのが書かれていますが、
>オブジェクトをnewせずに使うことって結構あるんでしょうか？
どちらかというと、C++では new する必要ない場合は、new しないことが
良い書き方。new は、好きなタイミングで削除したいようなオブジェクトの場合
のみ使用する。構造体やクラスのメンバの中に、別のクラスのオブジェクトが含まれている
ような場合は、new しないのが原則。
ある意味では、そのような習慣があるからこそ、C++ は効率が良いともいえる。
実は、new や malloc は、確保するサイズにかかわらず、大体 170 クロックほど
必要。delete や free と合わせると、合計 300 クロック必要となる。
一方、そのまま、new せずに「埋め込んだ」場合は、基本的に「0」クロック。
この差はとても大きなものとなることがある。
最初から最後まで存在し続けて、特別な終了処理が必要ないオブジェクトなら、わざわざヒープを確保して実行時に初期化する必要はないでしょ。
あと、staticなオブジェクトのコンストラクタはmain関数の前にグローバルコンストラクタから呼び出されるのだが、
これを利用して、プログラム起動時にやっておきたい初期化処理をクラス内で記述する目的に使うこともあるね。
さすがに良い書き方っていうのはどうかと思うけどな。
staticなオブジェクトにしちゃうと、初期化の順番が制御できないから、気をつけて使わないとコンパイラ依存のコードになってしまうし。
ありがとうございます。
このあたりのC++とC#の慣習の差異に違和感を覚えていたのですが、かなりスッキリしました。
必要な場合は new しても良い。でも、クラス Cxxxの中には、文字列の CString
クラスのオブジェクトや、何らかのリストのオブジェクトが複数含まれて
いたりすることも多い。それらのメンバを全て new する場合と、埋め込み
でそのまま使う場合とでは、Cxxx をインスタンス化するときの時間に雲泥の
差が出てしまう。Cxxx が、5つのクラス・オブジェクトを含んでいた場合、
それらを new するだけで、170 * 5 クロックも余分に掛かってしまう。
この数値には、各コンストラクタの処理時間は含まれていないので。
この場合だと、全て new すると、850 クロックも余計に掛かることになる。
さらに、Cxxx オブジェクトがデストラクトされる場合には、合計で、この
1.8 倍程度の時間が new しない場合より余計に掛かることになってしまう。
思い出したので追加しておく。
Little Endian の場合、
>Uint32 u32;
>BYTE u8;
>u8 = (BYTE )u32;
の代わりに、
Uint32 u32;
BYTE u8;
u8 = *(BYTE *)&u32;
という書き方も出来て、こっちの方が、処理効率が良い場合があるとされている。
しかし、BigEndian だとこの書き方は混乱を招きやすく、かつ、処理効率も
上がらないと思われる。
総合的に考えると、Little Endian の方が処理効率が上がりやすいはずだ。
>>875はstaticな変数のことははじめから言ってなくて、構造体のメンバやスタックに積まれるケースのように自動的にメモリ確保されるケースのことを言っていると思われる。
確か、関数呼び出し連鎖の途中の関数が誰も catch せずに放っておけば、
親の関数にまで戻れるはずなので、一応、同じようなことが出来る気もする。
長い間使ってないので、むしろ、setjmp, longjmp がどういうものだったか
の方を忘れてしまったけど。
たしかそれでいけたと思うな・・・。
https://github.com/electronicarts/EASTL.git
なかなかいいかも
上の桁とか（整数という概念上は）何桁まで伸びるかわからないのだから
しかし一方人間の認識上は上の桁から見て量を把握したいという要求があり、
不幸にもラテン語が左から書くのにアラビア数字が右から書く慣習だったため
二つの文化を取り持つ玉虫色の解決策としてビッグエンディアンとかネットワークバイトオーダーみたいなものが生じた
外に出すデータや互換性保ちたいデータは普通そうすると思うよ。
アラビア数字書くとき右から書いてるの？変わった人ね
単純なASCIIソートで正しくソートできるのはどれかという話にもつながる。
数学的にはそれで完全に正しい。
しかしコンピュータには誤差があるので、
itoa() や printf() などを自分で実装するような場合、
よく考えないといけないかも知れない。
log_10(x) で計算すると N 桁だということになったとしても、
itoa() などを実装するアルゴリズムによっては、ある条件の時に
誤差によって、1ケタだけずれるかもしれない。
めったに無いことだが、これで銀行システムや戦闘機のシステムが
ダウンしたりするかも知れないので、数学は重要。
即答することは出来ない。アルゴリズムを慎重に選ばないと、その誤差によって
システム・ダウンやアプリのハングアップ、保護例外などを引き起こす可能性が
わずかだが存在するかもしれない。
のときに整数mは十進n桁の数と言える。
不等式に常用対数を適用し、
n <= log_10 (m) < n+1
が得られる。つまり、1以上の整数mに常用対数を適用し、さらにガウス記号を適用したものがmの桁数だ。
m=0のときは一桁になることに注意する。
文字列の格納先のメモリを確保するときのサイズ見積もりに対数を使う場合は
ワーストケースで誤差が出た場合に備えればいい
siv3dみたいなのを探してます
オープンソースで参考になるやつ
glfw
>>914
うーん
一応webgl考えてみます
変換関数そのものをプログラムしたい場合に、あらかじめ桁数が分かって
いる方が便利 or 効率が良い、場合があり、log_10(x)を使用したくなってしまう。
ところがが、log 計算には誤差が有る可能性があるので、その値を過信するのは
問題だと言うことが言いたかった。
例えば、文字列化する際には、多くのアルゴリズムでは、下の方の桁から
決まっていく。しかし、文字列バッファには、上のケタから左詰で入れて
行く必要がある。となると、最初から桁数が分かっていれば、簡単に
プログラムできるのではないかと言う誘惑に駆られてしまう。
後、10で割っていって余りを使う方法は簡単ではあるが、そのアルゴリズム
そのものにも誤差が有る可能性が指摘されている。
＞10で割っていって余りを使う方法は簡単ではあるが、そのアルゴリズムそのものにも誤差が有る可能性が指摘されている。
え？10で割っていくのにどうして誤差が出るの？
変換関数の中でメモリ割り付けを行うのが好みなのか？
logは人間の感覚特性にマッチした量的尺度を表したり（例：dB）、
情報量の表現に使う（同じものがいっぱいあるという状況は情報量を上げない）という目的が大きい
intは何桁だ？
coronaがオープンソース化されたらしい
2dだが
前提として浮動小数点数(float/double など) の話だけど、誤差が無いとは言い切れない
事は分かると思う。
誤差を少なくする方法として、10で割ったりせずに、最初から、
10000.0, 1000.0, 100.0, 10.0, 1.0, 0.1, 0.01, 0.001
20000.0, 2000.0, ・・・
30000.0, 3000.0, ・・・
40000.0, 4000,0, ・・・
のようなものを計算しておいて、比較したり引き算したりする方法が
あるそうな。
浮動小数点値の場合、当然かもしれないが log を使わずに、IEEE の仕様を元に
指数部のBIT部分を読んで利用する方がいいらしい。
それなら10進演算だろ
IEEEでも定義されてる
科学計算だと対数で問題ない
自分で printf() を実装する場合の、浮動小数点数を文字列に直す時の話。
printfはオーバーロードできるしグローバル以外の空間にも導入できる
Boost.PythonでPythonスクリプトを読み込んで実行した場合は素の遅いPythonの速度になる認識であっているでしょうか？
また、Boost.PythonでJIT版Pythonを実行することは可能でしょうか？
全然その辺知らないけど、
そもそも、python の言語仕様自体がJITを使ったとしてもC/C++ほどの速度には
ならないはずだし、そもそも NumPy 使わないと遅いということは聞いてる。
大体のスクリプト言語は、言語仕様の段階で例えコンパイル言語化しても
どうすることも出来ない遅さが含まれてしまってる。
numpy使ったからと言って馬鹿が描くと素のpython以上に遅くなる
バカがイキって作ったライブラリより普通に速いから。
・自動メモリ管理
・リンクリストと配列を余り区別しない書き方をする人が多い傾向。
これらがあるので、pythonをコンパイル型にしてもある程度以上の高速化は
難しいと思われる。
Pythonの配列(list)はvector相当の動的配列
実はリンクリストが動的配列より速いケースってC++でも現実にはほとんど無くて、あまり価値のないデータ構造だよ
拡張・縮小にメモリの再確保が不要で抽象化を必要としないから、Cのような生ポインタを好んで使いまくる言語と相性がいいだけ
3000行のありがたいソースコードを読み解けば何かが分る
普通に動的配列だな
でも便利だからforward_listを使うことはある
std::get<N>( t ) ってファンキー過ぎやしませんか。
下手に使うとコンパイルに時間食われそう。
冷静に考えてみな
テンプレート化すればメンバ関数にすることはできるのでは？
すまん、いま泥酔状態だ
あとでな
t.template get<0>()
と書かなきゃならなくなってこりゃないわーで皆が合意したからじゃ
std名前空間汚れすぎ。
それは確かに糞仕様だと思うが
テンプレートの意味から言えば仕方ないのかも知れない
(どんな型でも入れられるならテンプレート以外でやるべき)
オーバロードで
std::pairでもstd::arrayでも生配列でも
std::getにすることによってテンプレート引数にtupleと見なせる型(pair,array)を使うことができるようにしたいからそうなっている
dynamic_castをしてみてnullptrかどうかを判断するのがベストな手順なんですか？
RTTIから実際の型情報を引っ張ってくる手段はないものでしょうか
もちできるけど、検査したい型を継承した型を渡されたら動かないよ？
それこそポリモーフィズムで派生クラスのthisを直でもらえばいいんじゃないの
typeid で type_info 取れるよ。
基底クラスにenum Type 等を持たせてswitchも手の一つ。
処理内容によってはvisitor パターンが使える。俺が知ってるのはこれくらい。
ダウンキャストが必要になるなら、選択はそれしかない
ダウンキャストしたいんだよね？
なんで実際の型情報なんかを欲しがる理由がわからん
不意にフレーズが浮かんだのです。
nullptrでキャスト可否を確認するのは普通の使い方だろ…
.c_str()をconst_castしてるけどあかんの
グレースケール化させて処理をしています
乱数生成などは理解しているんですがその乱数を使ってどのような値として輝度値に影響させるのかが分かってません
よろしくお願いします
visual c++を使用しています
Mat s;
src.convertTo(s, CV_16S);
Mat noise(s.size(), CV_16S);
randn(noise, 0, sigma);
Mat temp = s + noise;
temp.convertTo(dst, CV_8U);
今こう考えているんですがあっていますでしょうか
srcが原画像、dstがノイズ画像です
RTTIから実際の型情報を引っ張ってくる手段というとtypeidだね
void func(ios_base* ptr)
{
if(typeid(*ptr) == typeid(istream) { /* ... */ }
if(typeid(*ptr) == typeid(ostream) { /* ... */ }
}
非constのchar配列を要求するという事は書き換えられる可能性がある
逆にconst付でchar配列を返す方は書き換えないという前提で渡してる
面倒だけどコピーしてから渡すべき
さすがに神経質すぎる
そのライブラリの関数が文字列を書き換えない仕様なんだったら信用すればよい
そんなこと言い出したら何一つ信用できなくなってプログラムなんか書けん
書き換えない、という仕様なら最初からconstを要求すればいいだけのこと
constを要求していない以上書き換えられる可能性を考慮するのは当たり前の前提
そのようなスキルの低い作者の作ったライブラリの何を信用しろと言われるのか
凄いこと言うなあ
現場の人間か責任を負う立場の人間かで意見も異なるのがわかるだろうに
「契約相手がそう言ってるなら信用すればよい。違っていたら相手の責任だ。」で終わりだよ
バカの言うことなんて信用しないで安全に倒した方が正解だわ。
なんて仕様書に書いてあるのか
文字列を表示します
text : 表示する文字列
これが仮にtextを書き換えてしまうとして、それをコピーで回避できたとしても、
そんなレベルのゴミがまともに機能するとは到底思えん
そんなことを言い出したらキリがない
1. 要素数を N としたとき、1つの要素の処理に要する時間が O(N) になるか、
O(1) などの違いなので、本質的にハードがいくら良くなっても解決する
問題ではない。O(N) のアルゴリズムは、N が大きくなった場合には、
ハードの良さを台無しにしてしまう。なので、アルゴリズムの選定はとても
重要。
2. 動的配列でも、配列の最後に追加する場合は、リンクリストと遜色ない速度は
出る可能性は十分あるが、配列の途中に追加する場合は、宇宙人でも無理。
3. 逆に、リンクリストの場合は、先頭から数えて、「k 番目の要素」にランダム
にアクセスすることを高速化することは、宇宙人でも無理。
4. 「宇宙人でも無理」の意味が理解できるためには、数学的感性が必要。
理解できない人には理解できないかもしれない。
問題は、リンクリストの途中に挿入したいとき、予め挿入位置の直前や直後のノードへのポインタを持っていなければならないことだ
そんなケースは現実の開発において殆ど無い
持っていなければ挿入位置に辿り着くまでにO(N)のシーケンシャルアクセスが発生する
そして、リンクリストはメモリアクセスの局所性が欠片もないデータ構造であり、
動的配列と比較してシーケンシャルアクセスのパフォーマンスは極めて劣悪である
そのケースなんですけどね
うん。レアケースだね。
あかん。データを壊したくなかったら、別途コピーしたものを渡すべき。
で、そのリンクリストがパフォーマンス的に勝るデータ量はおいくらだと思ってる？
大きめの画像くらいのサイズならデータの中央に挿入するとき、リンクをたどって挿入するより再確保、再配置した方がシーケンシャルアクセスになるから早いからな
ハードウェアの特性によりシーケンシャルなコピーは相当速いためPythonで一般的に扱う問題では挿入だろうが何だろうがリンクリストが勝ることはまずない
動的配列に多数の要素を挿入するなら挿入する要素数分ブロックコピーでずらしてから空けた隙間に書き込むだけだからリンクリストより圧倒的に速い
予め要素数が分からない場合は、いったん別の動的配列に追加していってから纏めて挿入すればよい
＞再確保、再配置
ここ c++ だよね
再配置というのはコピーコンストラクタが働く、てことだよね
挿入のたびにコピーコンストラクタが動くなんて馬鹿のやることだ、という常識が通用するところだよね
＞ブロックコピーでずらしてから
ユーザーによるコピーコンストラクタが定義されていたら「それだけでは済まない」のでは？
その場合リストを使えばいいのでは
それでもリンクリストよりは速いわ
新しいスレッドを立ててください。
life time: 98日 16時間 29分 4秒
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 岸田総理「誰ひとり取り残さない社会」実現へ [煮卵★]
- 異例！ド軍ロバーツ監督が大谷翔平と緊急会談…「ぶら下がった果実を生かしきれていない」 [フォーエバー★]
- 慶應義塾長が国立大の学費増額を提言「年55万→150万に」 文科省の会合で ★2 [少考さん★]
- トライク(三輪自動車)が大型貨物に追突、男性死亡 男児意識不明 ヘルメットなし [蚤の市★]
- 休日に全く食事を取らない（取れない）人が過去25年で倍増している [ネギうどん★]
- 【芸能】日テレ退社→フリーの上重聡アナ、仕事なさすぎてヤバイ！ 5月予定ガチ公開… 現状、仕事が決まっているのが3日 [冬月記者★]
- AFC U23アジアカップ カタール2024★8
- AFC U23アジアカップ カタール2024★9
- とらせん
- 【酒】日本vsUAE【U23アジアカップ】
- とらせん祝勝会 ★2
- こいせん 全レス転載禁止
- この女の子ニーハイや脚見てムラムラすふ？
- 【画像】最新ラブライブ、ぼざろみたいになる
- FANZA10円セール開催中！！
- 誰もいない駐車場で一人で10時間くらい駐車場練習したい
- ウーバーイーツでケバブしか食ってない男
- いなり寿司を盗んだ74歳の女性を現行犯逮捕→82時間拘束→警察の誤認逮捕でしたｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ