>>200
C++の部分はネイティブなのでOSに依存する
C++の部分はネイティブなのでOSに依存する
スマン。CPU毎にバイナリは必要で、
clangに -macrh=xxx-xxx-xxx オプションを指定して CPUやOSを
指定してコンパイルしておくことを想定していた。
ただし、複数のCPU/OS向けのバイナリを1つのAPKにパッケージして、
使用時に自動選択する事が出来るらしい。
clangに -macrh=xxx-xxx-xxx オプションを指定して CPUやOSを
指定してコンパイルしておくことを想定していた。
ただし、複数のCPU/OS向けのバイナリを1つのAPKにパッケージして、
使用時に自動選択する事が出来るらしい。
わざわざjavaを使わなきゃいけないのが気にくわない
その場合、javaだけで書くこと以上のメリットある？
その場合、javaだけで書くこと以上のメリットある？
速度が速い。
てかそれってjavaのアプリ作っているだけじゃ
Androidアプリは、Javaで書くのが基本とされてるけど、
Chromeブラウザなんかはきっと、C++で書いたものを ARMなどの
CPU向けのnative binaryに直し、それをAPKにパッケージ化して
配布してるのではなかろうか？ AmazonのFire7 や Fire HD 8 などの
タブレットのCPUはどちらもARMらしい。スマホもARMが多いのかな。
Chromeブラウザなんかはきっと、C++で書いたものを ARMなどの
CPU向けのnative binaryに直し、それをAPKにパッケージ化して
配布してるのではなかろうか？ AmazonのFire7 や Fire HD 8 などの
タブレットのCPUはどちらもARMらしい。スマホもARMが多いのかな。
>>205
基本的な描画系と入力系をライブラリ化しておけば、メインロジック部分は
C++で書けると思うよ。
基本的な描画系と入力系をライブラリ化しておけば、メインロジック部分は
C++で書けると思うよ。
さっき、AdoptOpenJDK なるものをインストールしてみたら、
java と javac コマンドが起動することを確認した。
多分このJDKは、Oracle フリーで無料でクローズド商用利用できると思う。
java と javac コマンドが起動することを確認した。
多分このJDKは、Oracle フリーで無料でクローズド商用利用できると思う。
jniはjavaのプラットフォームにc++での開発成果物を持ち込むためのもので、そうでないならわざわざそんなもの使う意味は薄い
マルチプラットフォームなアプリを作りたいならQtなりwxなりを使った方が速いし楽
マルチプラットフォームなアプリを作りたいならQtなりwxなりを使った方が速いし楽
そもそも、Androidアプリにとってのシステムコール(API)とは、Javaの関数だと
思うので、この構造自体は Android における「最も高速なアプリ」になっている
と思う。
思うので、この構造自体は Android における「最も高速なアプリ」になっている
と思う。
>>210
一般アプリ作者は大丈夫だと思うな。一番危ないのは、オイラみたいに、
ToolKit作って儲けようなんて思ってる人なのさ。(^_^;)
一般アプリ作者は大丈夫だと思うな。一番危ないのは、オイラみたいに、
ToolKit作って儲けようなんて思ってる人なのさ。(^_^;)
糞デカイ上に更新面倒なjavaのruntime入れさせるほうが害悪だろ
flashより糞度が高い
flashより糞度が高い
AndroidはJREはプリインストール済みなんじゃないの？
オイラは実機持ってないので全く分からないんだな。
オイラは実機持ってないので全く分からないんだな。
androidで実質c++でのアプリ開発する仕組みなら既にある
jniそのまま使うよりは大分マシ
jniそのまま使うよりは大分マシ
Qt は、内部的に Backend で Java を使ってるのかな。
なんかJavaを間違って理解してるっぽい。
vector に格納されてる値から添え字の番号を取得するための最も手軽な方法はなんでしょうか
イテレータから添え字番号を取得することはできますが、あくまで値からやりたいです
イテレータから添え字番号を取得することはできますが、あくまで値からやりたいです
格納してる値にインデックスの手がかりがないんだったら
findで探して結果のイテレータから取得するしかないな
findで探して結果のイテレータから取得するしかないな
>>223-224
ありがとうございます
格納する値の範囲もサイズも小さいvectorなので、今回は辞書を作って対応しようと思います
ありがとうございます
格納する値の範囲もサイズも小さいvectorなので、今回は辞書を作って対応しようと思います
奇遇なことに辞書も三行くらいです
そら奇遇ですな。
>>200
とても興味を覚えました
私は、そろそろ言語間でライブラリも共用されるべきだと考えています
一つの記述体で各言語共通というのはさすがに難しいにせよ、
Java のライブラリと同等なもの（名前と機能が共通のもの）が C++ にもあってもいいんじゃないか？と数年前から妄想しています…
とても興味を覚えました
私は、そろそろ言語間でライブラリも共用されるべきだと考えています
一つの記述体で各言語共通というのはさすがに難しいにせよ、
Java のライブラリと同等なもの（名前と機能が共通のもの）が C++ にもあってもいいんじゃないか？と数年前から妄想しています…
もうJavaのことは忘れて生きろ
JavaとC++に共通インターフェースを作るのは反対。
車輪の再発明にしかならない。自由を奪うだけの愚策。
車輪の再発明にしかならない。自由を奪うだけの愚策。
>>232
共通ライブラリを使う側にとってはオプションであることは当然。
共通ライブラリを作る側の話をすべき。共通ライブラリの規格決定権者が増えすぎること自体が好ましくない。
これはEU諸国がトルコがEU参加することを拒否する感覚に近い。
共通ライブラリを使う側にとってはオプションであることは当然。
共通ライブラリを作る側の話をすべき。共通ライブラリの規格決定権者が増えすぎること自体が好ましくない。
これはEU諸国がトルコがEU参加することを拒否する感覚に近い。
>>233
私は EU には否定的（グローバリストの巣窟であり、普通選挙／自由選挙による合意形成をスキップするポジションを作って人を操作するからくり、トルコもたぶん目が覚めているのでは？）ですが、それはさておき、
すでにある java/classpath スケルトンを真似してしまおう、という低姿勢・低いプライドを貫くのであれば、規格策定者は基本要らなくなりませんか？だって真似するだけだし…
私は EU には否定的（グローバリストの巣窟であり、普通選挙／自由選挙による合意形成をスキップするポジションを作って人を操作するからくり、トルコもたぶん目が覚めているのでは？）ですが、それはさておき、
すでにある java/classpath スケルトンを真似してしまおう、という低姿勢・低いプライドを貫くのであれば、規格策定者は基本要らなくなりませんか？だって真似するだけだし…
まだC++98しか知らないと、取り残されますか。
まずは、Javaと瓜二つな C#、.NET、C++/CLIが今どうなっているか考えてみては。
>>229
ちょっと話しはズレるけど、あなたの賛同で嬉しくなったので、入手した耳寄りな
情報を書いておこうと思う。既に知ってる人も当然いると思うけど、
WebAssemblyで作ったようなWebAppliは、ブラウザのURL欄やタイトルバーなどが
表示されてしまうのが難点として残っていた。ところがなぜかElectronでは消せて
いたのでChromeではなくChromiumを使っているからかと思っていた。
ところが、manifest.json なるものを書いて、HTMLにそのファイルを使うように
書いておいて、display プロパティーを standalone やfullscreen にすると、
URL欄が消せるらしい。
ちょっと話しはズレるけど、あなたの賛同で嬉しくなったので、入手した耳寄りな
情報を書いておこうと思う。既に知ってる人も当然いると思うけど、
WebAssemblyで作ったようなWebAppliは、ブラウザのURL欄やタイトルバーなどが
表示されてしまうのが難点として残っていた。ところがなぜかElectronでは消せて
いたのでChromeではなくChromiumを使っているからかと思っていた。
ところが、manifest.json なるものを書いて、HTMLにそのファイルを使うように
書いておいて、display プロパティーを standalone やfullscreen にすると、
URL欄が消せるらしい。
>>237
もう時代はすっかり html/css/js ですね…
VSCode も Electron ですし…
もう時代はすっかり html/css/js ですね…
VSCode も Electron ですし…
質問を変えてみよう。
C++11やC++14のコードは、職場で取り入れられてますか。
C++11やC++14のコードは、職場で取り入れられてますか。
>>239
ガンガン取りいれてるよ。
なにげにでかいのが日本語識別子の保証。適切に使うと可読性が笑っちゃうくらい上がるｗ
ヘッダーのプロトタイプ宣言とかが特におすすめかな。
あとchar16_t/char32_tも結構ありがたい。WindowsとUNIX系のOS間で同じ文字コードとして共通で使える型が以前はなかったからね。
20でようやく入るみたいだが、なぜchar8_tを入れかったのか(´･ω･｀)
std::initializer_listもかなり便利。型安全で個数も分かる上に、引数の一番後ろじゃなくてもいいので、cの...と違って気軽に使える。
あとよく使うのは範囲for文と、イテレータの簡略化かな。いくつかの演算子をオーバーロードすれば良いだけだから、
結構気軽に範囲for文対応のイテレータを書ける。
ラムダ式も関数の引数に直接関数を埋め込んだりできて便利。
ガンガン取りいれてるよ。
なにげにでかいのが日本語識別子の保証。適切に使うと可読性が笑っちゃうくらい上がるｗ
ヘッダーのプロトタイプ宣言とかが特におすすめかな。
あとchar16_t/char32_tも結構ありがたい。WindowsとUNIX系のOS間で同じ文字コードとして共通で使える型が以前はなかったからね。
20でようやく入るみたいだが、なぜchar8_tを入れかったのか(´･ω･｀)
std::initializer_listもかなり便利。型安全で個数も分かる上に、引数の一番後ろじゃなくてもいいので、cの...と違って気軽に使える。
あとよく使うのは範囲for文と、イテレータの簡略化かな。いくつかの演算子をオーバーロードすれば良いだけだから、
結構気軽に範囲for文対応のイテレータを書ける。
ラムダ式も関数の引数に直接関数を埋め込んだりできて便利。
>>240
＞char16_t/char32_tも結構ありがたい
確かに
char16_t と u"" がなければ win32api W 系とか途方に暮れていたとおもいます… http://2chb.net/r/tech/1434079972/53
＞char16_t/char32_tも結構ありがたい
確かに
char16_t と u"" がなければ win32api W 系とか途方に暮れていたとおもいます… http://2chb.net/r/tech/1434079972/53
ガンガン最新を追うべきとまでは思わないけど、
C++11 は最低限度じゃないかなぁ。
C++11 は最低限度じゃないかなぁ。
17便利すぎ
variant,visit,lambda,if constexpr
のコンボで捗る
variant,visit,lambda,if constexpr
のコンボで捗る
つーか今はもうC++11の機能は使わずにC++で書け!といわれても
やりきる自信がなくなった・・
やりきる自信がなくなった・・
古い環境だと最近のサンプルがビルドできなくて困る
c++11とか名乗るから誤解されるんだよ。
c++++とかのがイメージ的に正しい。
c++++とかのがイメージ的に正しい。
C#ってことか。
repeat文って入らないの？
>>249
repeat(int i; n) で for(int i; i<n; i++) と同じ意味な機能
repeat(int i; n) で for(int i; i<n; i++) と同じ意味な機能
>>250
そんなどうでも良いもののために予約語追加する意味って
その文法じゃ初期値すら変えられない
そんなどうでも良いもののために予約語追加する意味って
その文法じゃ初期値すら変えられない
初期値はi=0とかすればいいのか
でもそうなるとi=1にした場合何回ループするのか混乱しそう
でもそうなるとi=1にした場合何回ループするのか混乱しそう
>>229
QtとかGtk、wxとか色々有るじゃん。。。
入れるの面倒くさいなら、Power Builder(だっけ？)とかの有料開発環境はVSを除いてマルチプラットフォームなライブラリが売りだぞ。
QtとかGtk、wxとか色々有るじゃん。。。
入れるの面倒くさいなら、Power Builder(だっけ？)とかの有料開発環境はVSを除いてマルチプラットフォームなライブラリが売りだぞ。
>>253
Java の人も C# の人も c++ の人も python も ruby も一緒の名前で一緒の機能が使えたら，コストの中でも一番高くつく勉強コストを減らせるのではないでしょうか
Java の人も C# の人も c++ の人も python も ruby も一緒の名前で一緒の機能が使えたら，コストの中でも一番高くつく勉強コストを減らせるのではないでしょうか
こんなので十分だろ
https://ideone.com/I6e8NZ
https://ideone.com/I6e8NZ
>>254
うん。
それはまさにそうで、だからQt,Gtk,wxあたりのメジャー所は色んな言語にラッパーがある。
うん。
それはまさにそうで、だからQt,Gtk,wxあたりのメジャー所は色んな言語にラッパーがある。
webプログラマーなんですが、右辺値、fowardっていつ使うのか気になります
というかなんでそこまで、厳密に分ける必要があるのか
業務で使ってる方、使用例を教えてください
というかなんでそこまで、厳密に分ける必要があるのか
業務で使ってる方、使用例を教えてください
右辺値というかムーブ関数の定義といらなくなるオブジェクトにstd::move付けとくのは絶対損にはならないからとりあえずやっとく
forwardはテンプレートライブラリ作るなら必須だけど自分では使ったことないなあ
forwardはテンプレートライブラリ作るなら必須だけど自分では使ったことないなあ
コピーにコストがかかる場合は、std::swapやstd::moveのが早い場合があるからね。ムーヴはコピーじゃなくて引っ越しだから。
まあ理論上はね。。そういう実装になってるかどうかはコード見ないとわからんけどね。
基本的には高速化が目的でmove使わなくてもなんとかなるが、
所有権絡むとmoveは必須になる
forwardはtemplateで引数渡すときにmoveやら参照やらの完全転送する場合必須
所有権絡むとmoveは必須になる
forwardはtemplateで引数渡すときにmoveやら参照やらの完全転送する場合必須
ちょっと実際にやってみようか。コピーコンストラクタで十秒待つコードを書く。ムーヴコンストラクタとムーヴ代入でなにもしない。
この状態でstd::moveを使わないで代入すると十秒かかる。
この状態でstd::moveを使わないで代入すると十秒かかる。
訂正。「コピー代入で十秒待つコードを追加」
>>264
>所有権絡むとmoveは必須
必須とまでは言えない
T::T(const T& obj)
という通常のコピコンを定義して、コピコンの中でconst剥がししたら
とりあえず所有権の移動もmove無しで逝ける
>所有権絡むとmoveは必須
必須とまでは言えない
T::T(const T& obj)
という通常のコピコンを定義して、コピコンの中でconst剥がししたら
とりあえず所有権の移動もmove無しで逝ける
>>260
高速化のために出来るのは、アルゴリズムのレベルでの工夫を別にすれば、出来ることはショートカットだ。
高速化とは近道なんだよ。
場合分けが出来るなら、どうしてもやらなければならないこと、やらなくてもいいことを「区別」できる。
区別できるなら、やらなくてもいいことは省略できる。
言語での区別が無くても、たとえば C でも区別を陽に書けばムーブみたいなことだって、そりゃあ出来るけども、
そんなクソ面倒くさいことはしたくないので言語でのサポートがあるとありがたい。
まあ速度的にそこまで必要ないってのなら、区別を積極的に利用しなくてもかまわないよ。
でも、必要なときに出来る方法が用意されているとうれしいし、
C++ を使うときというのはそれなりに実行速度が必要なときだろうし。
高速化のために出来るのは、アルゴリズムのレベルでの工夫を別にすれば、出来ることはショートカットだ。
高速化とは近道なんだよ。
場合分けが出来るなら、どうしてもやらなければならないこと、やらなくてもいいことを「区別」できる。
区別できるなら、やらなくてもいいことは省略できる。
言語での区別が無くても、たとえば C でも区別を陽に書けばムーブみたいなことだって、そりゃあ出来るけども、
そんなクソ面倒くさいことはしたくないので言語でのサポートがあるとありがたい。
まあ速度的にそこまで必要ないってのなら、区別を積極的に利用しなくてもかまわないよ。
でも、必要なときに出来る方法が用意されているとうれしいし、
C++ を使うときというのはそれなりに実行速度が必要なときだろうし。
とわいえmoveコンストラクタの方が意図が明確なコードが書けるから良い。
moveコンストラクタがふさわしい例っていやーつぎごケース。
class BarWithBigData {
Foo* m_pBigData;
BarWithBigData() : m_pBigData(new Foo[1000000000000] { }
~BarWithBigData() { delete[] m_pBigData; }
BarWithBigData(BarWithBigData&& rhs) { m_pBigData = rhs.m_pBigData; rhs.m_pBigData = NULL; }
Foo* refBigData() { return m_pBigData; }
};
ちなstd::arrayは使った無いから知らん
moveコンストラクタがふさわしい例っていやーつぎごケース。
class BarWithBigData {
Foo* m_pBigData;
BarWithBigData() : m_pBigData(new Foo[1000000000000] { }
~BarWithBigData() { delete[] m_pBigData; }
BarWithBigData(BarWithBigData&& rhs) { m_pBigData = rhs.m_pBigData; rhs.m_pBigData = NULL; }
Foo* refBigData() { return m_pBigData; }
};
ちなstd::arrayは使った無いから知らん
訂正orz、
誤：
Foo* m_pBigData;
BarWithBigData() : m_pBigData(new Foo[1000000000000] { }
正：
Foo* m_pBigData;
public:
BarWithBigData() : m_pBigData(new Foo[1000000000000]) { }
誤：
Foo* m_pBigData;
BarWithBigData() : m_pBigData(new Foo[1000000000000] { }
正：
Foo* m_pBigData;
public:
BarWithBigData() : m_pBigData(new Foo[1000000000000]) { }
コピコンの中でconst剥がしってちょっと何言ってるか分からない
十秒待つ待つコードはWindowsなら#include <windows.h>してSleep(10*1000);であり、
Linuxなら#include <unistd.h>してsleep(10);だ。
C++11ならstd::chronoに待つ関数があったはず。
Linuxなら#include <unistd.h>してsleep(10);だ。
C++11ならstd::chronoに待つ関数があったはず。
const_castだろ。jk
まあ実際にはそんなムーブをゴリゴリ書くことはなくて
m_pBigDataをunique_ptr<array<Foo, 1000000000000>>にしてムーブctor、ムーブop=、デストラクタを=defaultにするけどな
m_pBigDataをunique_ptr<array<Foo, 1000000000000>>にしてムーブctor、ムーブop=、デストラクタを=defaultにするけどな
auto_ptrよりヤバイ奴
const_castでconst外した後実際に書き換えてしまうとかw
const_castでconst外した後実際に書き換えてしまうとかw
>>277
ちなconst T&で渡されたﾌﾞﾂを関数内でconst_castして書き換えることはそれ自体は合法
ROM上のオブジェクトを渡して死ぬことは有り得るがしたら呼び出し側の違反
また最適化にしくるとしたらそれはコンパイラーのバグ
ちなconst T&で渡されたﾌﾞﾂを関数内でconst_castして書き換えることはそれ自体は合法
ROM上のオブジェクトを渡して死ぬことは有り得るがしたら呼び出し側の違反
また最適化にしくるとしたらそれはコンパイラーのバグ
>>278
ROM上になくても const T 型で構築されたオブジェクトを書き換えたら未定義動作になるから、
値が変わらない前提の最適化は許されてるよ。
const 無しで構築されたオブジェクトを指す const& の話と混同してそうだね。
ROM上になくても const T 型で構築されたオブジェクトを書き換えたら未定義動作になるから、
値が変わらない前提の最適化は許されてるよ。
const 無しで構築されたオブジェクトを指す const& の話と混同してそうだね。
質問: c🐴++のrust相対の優位性はなんですか？
>>280
正しくないコードをコンパイル出来る。
C++ はプログラマを信頼するのだ。
正しくないコードをコンパイル出来る。
C++ はプログラマを信頼するのだ。
>>278
未定義じゃないか
c++03 5.2.11の7にはこんなことが書いてある
[Note: Depending on the type of the object, a write operation through the pointer, lvalue or pointer to data
member resulting from a const_cast that casts away a const-qualifier68) may produce undefined behav-
ior (7.1.5.1). ]
未定義じゃないか
c++03 5.2.11の7にはこんなことが書いてある
[Note: Depending on the type of the object, a write operation through the pointer, lvalue or pointer to data
member resulting from a const_cast that casts away a const-qualifier68) may produce undefined behav-
ior (7.1.5.1). ]
>>282
Depending on the type of the objectにおいてmay produce undefined behaviorである
すわなちオブジェクトの型によっては未定義動作に成りえる、
と言っているだけなのでconst T&渡しされたパラメータの書き換えがNGの祥子にはなんね
>>279
>const T 型で構築されたオブジェクトを書き換えたら未定義動作になる
それはそう。しかしconst T&渡しされた関数内でコンパイラはそれを判断できないから
そういった関数内で、参照型かポインタ型引数で関数に渡されたlvalueのconst_castした結果はあくまでlvalue扱い
のはず…
Depending on the type of the objectにおいてmay produce undefined behaviorである
すわなちオブジェクトの型によっては未定義動作に成りえる、
と言っているだけなのでconst T&渡しされたパラメータの書き換えがNGの祥子にはなんね
>>279
>const T 型で構築されたオブジェクトを書き換えたら未定義動作になる
それはそう。しかしconst T&渡しされた関数内でコンパイラはそれを判断できないから
そういった関数内で、参照型かポインタ型引数で関数に渡されたlvalueのconst_castした結果はあくまでlvalue扱い
のはず…
>>283
関数内では const& であることを根拠に最適化に使えないのは合ってる。
でもだからといって const& で受け取ったものを書き換えてもよいとは言えない。
void f1(int const&);
int f2()
{
int const x = 1;
f1(x);
return x;
}
x は int const なので、 f2() の return x は f1() が const_cast して x を
書き換える可能性を無視して return 1 に最適化できる、という話。
BarWithBigData const x; が >>275 のコピーコンストラクタに渡された後も
const_cast<BarWithBigData&>(rhs).m_pBigData = NULL; を無視して書き換え前の
m_pBigData が使われる可能性がある。
関数内では const& であることを根拠に最適化に使えないのは合ってる。
でもだからといって const& で受け取ったものを書き換えてもよいとは言えない。
void f1(int const&);
int f2()
{
int const x = 1;
f1(x);
return x;
}
x は int const なので、 f2() の return x は f1() が const_cast して x を
書き換える可能性を無視して return 1 に最適化できる、という話。
BarWithBigData const x; が >>275 のコピーコンストラクタに渡された後も
const_cast<BarWithBigData&>(rhs).m_pBigData = NULL; を無視して書き換え前の
m_pBigData が使われる可能性がある。
規格が云々言わなくても、9割のプログラマの意図に反してるで終わる話
頼むからそんなコードは頭の中にしまっといてほしい
頼むからそんなコードは頭の中にしまっといてほしい
つまりはそれ自体は問題ないが、constとして生成したオブジェクトを渡した瞬間にダメになると言うことか
で、渡すこと自体は制限できないから
プログラム中に罠を仕掛ける事が出来るわけだ。
で、渡すこと自体は制限できないから
プログラム中に罠を仕掛ける事が出来るわけだ。
てか、mutable付けとけば問題なくなるな。
const_castも要らないし良いことずくめじゃないかw
>>285
わかりたそうする。>>275のケースは素直にムーブコンストラクタを使えば良い。または↓でもだいたいおk
BarWithBigData::BarWithBigData(BarWithBigData& rhs) { m_pBigData = rhs.m_pBigData; rhs.m_pBigData = NULL; }
だいたいというのはムーブコンストラクタ有りの規格のC++コンパイラで↑の非constなコピコンだけ書く警告が出ることがあるからｲﾔﾝ、
>>286
>つまりはそれ自体は問題ないが
いや問題がある可能性が潰せていない。
void f1(int const&);
int f2()
{
int x = 1;
f1(x);
return x;
}
（xがconst無し)の場合であってもf1(x)がxを書き換えない前提の最適化がf2()にかかったりすると、
f1(x)内で変更したxの値がreturnされるxの値に反映されない可能性がある（f1(x)の呼び出し前後でxがレジスタに乗ったままであるとか、
わかりたそうする。>>275のケースは素直にムーブコンストラクタを使えば良い。または↓でもだいたいおk
BarWithBigData::BarWithBigData(BarWithBigData& rhs) { m_pBigData = rhs.m_pBigData; rhs.m_pBigData = NULL; }
だいたいというのはムーブコンストラクタ有りの規格のC++コンパイラで↑の非constなコピコンだけ書く警告が出ることがあるからｲﾔﾝ、
>>286
>つまりはそれ自体は問題ないが
いや問題がある可能性が潰せていない。
void f1(int const&);
int f2()
{
int x = 1;
f1(x);
return x;
}
（xがconst無し)の場合であってもf1(x)がxを書き換えない前提の最適化がf2()にかかったりすると、
f1(x)内で変更したxの値がreturnされるxの値に反映されない可能性がある（f1(x)の呼び出し前後でxがレジスタに乗ったままであるとか、
ラムダに11個の引数を参照で渡すのと、キャプチャするの、どっちが速いかな？
測ればいいだろ
参照渡しな時点でその場で呼び出すのだろ。
最適化かければ結局同じようなアセンブリになるよ。
最適化かければ結局同じようなアセンブリになるよ。
それはわからんだろ
ブロック待ちするかもしれないわけで
ブロック待ちするかもしれないわけで
引数で渡すとスタックに積まれる可能性があるけど、キャプチャするとそうならないのでは。
いや、形式上は無名クラスにキャプチャを変数としてぶちこんだもののインスタンス作ってメンバ関数のoperator()呼ぶのだから、スタックは使うだろ。
C言語じゃダメなんですか！
いいよ
無駄に複雑にしとるな。
海外だと、Javaに負けて、Rustに圧倒的実力で追いやられるC++
本当に、コンパイル時に何かしたいならRustだけどね
全部足すと500%位になりそうだから、複数の言語を使う人が多いんだろね。
江添が転職できずに困っとるw
まあこいつがクソなだけでc++の問題ってわけじゃないんだがイメージは悪いわな。
まあこいつがクソなだけでc++の問題ってわけじゃないんだがイメージは悪いわな。
こうしてみるとホッシーの全タクシー移動ってのは理に適ってるな
バカな公害に捕まる心配が減る
バカな公害に捕まる心配が減る
なんか私怨でもあるんかいな
喫煙者が目に入った途端癇癪起こして殴り掛りかかる狂犬なんだっけ？
知らね
よく人を招いているようだし揉めたことがある人も少なくはないんじゃいか
よく人を招いているようだし揉めたことがある人も少なくはないんじゃいか
>>310-311
当事者の様々な主張の食い違いがあるので、結論としては「わからない」。
少なくとも彼自信の主張としては掴みかかってきたのを払いのけた結果として眼鏡が割れたということになっている。
(江添が殴りかかったわけではなく、むしろ防衛した側、と江添は主張している。)
江添が煙草について過激な意見を持っているのは確かだが、
シェアハウス内で禁煙場所であると合意がなされている場所で煙草を吸った客人がいたというところは当事者全体が認めているようだ。
当事者の様々な主張の食い違いがあるので、結論としては「わからない」。
少なくとも彼自信の主張としては掴みかかってきたのを払いのけた結果として眼鏡が割れたということになっている。
(江添が殴りかかったわけではなく、むしろ防衛した側、と江添は主張している。)
江添が煙草について過激な意見を持っているのは確かだが、
シェアハウス内で禁煙場所であると合意がなされている場所で煙草を吸った客人がいたというところは当事者全体が認めているようだ。
恨みというかまともにコード書かない奴がクソ意見で現場荒らすって事自体がクソだと思うわけで、
まあその反動で現場で働くことができないって事になればザマァって思う。
まあその反動で現場で働くことができないって事になればザマァって思う。
現場を荒らしてる？
どのプロジェクトにも参加してないと認識してたけど乗り込んでケチつけてたりするのかな
まあ俺ドワンゴとは縁が無いからどこで何してようが関係ないけど
まあ俺ドワンゴとは縁が無いからどこで何してようが関係ないけど
C++がPython抜いて3位 - 4月TIOBE言語ランキング 2019/04/17 10:55 後藤大地
https://news.mynavi.jp/article/20190417-810363/
TIOBE Softwareから、2019年4月のTIOBE Programming Community Index (PCI)が公開された。
TIOBE PCIは、複数の検索エンジンの検索結果から、対象となるプログラミング言語が
どれだけ話題になっているかをインデックス化したもの。
4月TIOBE Programming Community Index / 円グラフ
2019年4月はC++がPythonを抜いて3位に返り咲いた。ただし、Pythonのシェアが下落したの
ではなく、Pythonの増加傾向をC++の増加が上回ったことによる結果と思われる。C++は
長期にわたって下落傾向が続いていいたものの、2019年に入ってから増加傾向へ転じている。
Pythonも増加傾向が続いており、どちらも今後さらにインデックス値を増やす可能性がある。
長期にわたって1位を確保しているJavaは依然として1位のポジションにあるが、下落の
傾向が続いている。2位のC言語も長期で見ると下落を続けており、C++やPythonの存在感が
強くなってきている。
https://news.mynavi.jp/article/20190417-810363/
TIOBE Softwareから、2019年4月のTIOBE Programming Community Index (PCI)が公開された。
TIOBE PCIは、複数の検索エンジンの検索結果から、対象となるプログラミング言語が
どれだけ話題になっているかをインデックス化したもの。
4月TIOBE Programming Community Index / 円グラフ
2019年4月はC++がPythonを抜いて3位に返り咲いた。ただし、Pythonのシェアが下落したの
ではなく、Pythonの増加傾向をC++の増加が上回ったことによる結果と思われる。C++は
長期にわたって下落傾向が続いていいたものの、2019年に入ってから増加傾向へ転じている。
Pythonも増加傾向が続いており、どちらも今後さらにインデックス値を増やす可能性がある。
長期にわたって1位を確保しているJavaは依然として1位のポジションにあるが、下落の
傾向が続いている。2位のC言語も長期で見ると下落を続けており、C++やPythonの存在感が
強くなってきている。
俺が検索しまくったからだろうな。
今もしインターネットが完全にシャットダウンされると
プログラム書けなくなるプログラマけっこう数いるだろうな
プログラム書けなくなるプログラマけっこう数いるだろうな
どうやってダウンロードしたの？
巡集じゃできなかった…
巡集じゃできなかった…
githubじゃない？
そうなんだ、ありがとう
どういたしまして。
江添は職質裁判でも、不当判決が出たので控訴するみたい
警官は、複数人で口裏合わせするから、民間人は勝てない
漏れもやられたけど、酒酔い運転でも、漏れが機械に息を吹き掛けても、ランプが点かない。
そこで、警官がクルッと後ろを向くと、ランプが点く
そっと見たら、酔っ払い警官が、自分で息を吹きかけて、ランプを点ける
こういう裁判で争っている人もいるけど、
警官は複数人で口裏合わせするから、絶対に勝てない！
警官は皆、このやり方で出世しとる
警官は、複数人で口裏合わせするから、民間人は勝てない
漏れもやられたけど、酒酔い運転でも、漏れが機械に息を吹き掛けても、ランプが点かない。
そこで、警官がクルッと後ろを向くと、ランプが点く
そっと見たら、酔っ払い警官が、自分で息を吹きかけて、ランプを点ける
こういう裁判で争っている人もいるけど、
警官は複数人で口裏合わせするから、絶対に勝てない！
警官は皆、このやり方で出世しとる
ありゃ普通に対応してりゃ済む話だと思うがね。
やってることは完全に当たり屋だろ。
やってることは完全に当たり屋だろ。
どんだけ江添好きなの？ｗ
日本でC++真剣にやってるのって彼だけだし
だけ、というのは言い過ぎだと思うが、
日本語で最新の C++ の事情を本にしているのは江添くらいしかいないからなぁ。
江添本人は自分のことを実務家ではなく教育者だと考えているようだし、
(肩書は何なんだろ？ エヴァンジェリストのようにも見えるが……)
今のポストは妥当なとこだろ。
そのままやってくれればありがたいもんだ。
日本語で最新の C++ の事情を本にしているのは江添くらいしかいないからなぁ。
江添本人は自分のことを実務家ではなく教育者だと考えているようだし、
(肩書は何なんだろ？ エヴァンジェリストのようにも見えるが……)
今のポストは妥当なとこだろ。
そのままやってくれればありがたいもんだ。
つまり他の日本人は竹刀とか木刀ってことか。
江添個人の裁判は完全にスレチなんだよなあ
仮に違法な取り締まりだと判断されても警察のやり方が改まるわけもないだろうし
仮に違法な取り締まりだと判断されても警察のやり方が改まるわけもないだろうし
江添すなわちC++なのだから
江添の話題は全てC++の話題だょ
江添の話題は全てC++の話題だょ
宗教の話はよそでやってくれないか
もう少しc++の話をしてくれと思う事もある
はちみつさんも真剣にやってると思います。
こんな事言うと勘違いされそうだが、はちみつ餃子はちゃんとしてると思うよ
C++に関しておかしなことは言っていない
ていうか、はちみつ餃子ってものすごい不味そうなんだがそんなの本当にあるのだろうか・・？
C++に関しておかしなことは言っていない
ていうか、はちみつ餃子ってものすごい不味そうなんだがそんなの本当にあるのだろうか・・？
肉料理にはちみつを入れること自体はわりと普通
量の問題
量の問題
いや明らかに開発してねーだろって感覚じゃねーか。
まあここならそれでもいいんだろうけれど。
まあここならそれでもいいんだろうけれど。
>>338
ググればわかるけどはちみつ餃子はそこそこありふれた料理だよ。
その昔、 higepon が自分でもどうして higepon などと名乗ったかわからない
と述べていたので、そのくらい意味不明感じにしようと思って適当に
思いついた語をコテハンにした。
Scheme スレが本来の住処なので当初は SCHEME餃子 と名乗っていたけど、
他のスレにも顔を出すようになったのでなんとなくはちみつ餃子になった。
およそ意味不明な組合せにしたつもりだったんだけど、
実際にある料理だとは後になってから知った。
ググればわかるけどはちみつ餃子はそこそこありふれた料理だよ。
その昔、 higepon が自分でもどうして higepon などと名乗ったかわからない
と述べていたので、そのくらい意味不明感じにしようと思って適当に
思いついた語をコテハンにした。
Scheme スレが本来の住処なので当初は SCHEME餃子 と名乗っていたけど、
他のスレにも顔を出すようになったのでなんとなくはちみつ餃子になった。
およそ意味不明な組合せにしたつもりだったんだけど、
実際にある料理だとは後になってから知った。
initializer_listを引数に取るオブジェクトを引数に取る関数で
下記のケースでUniversal Initializationが効かないのですが
何かいい手はないでしょうか
using KVPCollectionType = std::map<std::string, std::string>;
void f(const KVPCollectionType&& kvps = {});
f(); // OK
f({}); // OK
f(KVPCollectionType{{"key1", "value1"},{"key2","value2"}}); // OK
f({{"key1", "value1"},{"key2","value2"}}); // NG これをやりたい！！
下記のケースでUniversal Initializationが効かないのですが
何かいい手はないでしょうか
using KVPCollectionType = std::map<std::string, std::string>;
void f(const KVPCollectionType&& kvps = {});
f(); // OK
f({}); // OK
f(KVPCollectionType{{"key1", "value1"},{"key2","value2"}}); // OK
f({{"key1", "value1"},{"key2","value2"}}); // NG これをやりたい！！
エピ…いや何でもない
すみません、訂正です
× void f(const KVPCollectionType&& kvps = {});
○ void f(const KVPCollectionType& kvps = {});
× void f(const KVPCollectionType&& kvps = {});
○ void f(const KVPCollectionType& kvps = {});
アークエンジェルに搭載されてるstd::variant<>。
wandboxで試したらclangでもgccでもc++11 -pedanticで通ったけど？
ごめんなさい、ごめんなさい。本当にごめんなさい。
勝手に脳内で要約したのが間違えまくってました
正確には以下の通りです。
#include <map>
#include <memory>
using KVPCollectionType = std::map<std::string, std::string>;
class c {
public:
c(const KVPCollectionType&& kvps = {}){}
};
int main()
{
auto ok = std::make_shared<c>(KVPCollectionType{{"key1", "value1"},{"key2","value2"}}); // OK
auto ng = std::make_shared<c>({{"key1", "value1"},{"key2","value2"}}); // NG!!!
}
勝手に脳内で要約したのが間違えまくってました
正確には以下の通りです。
#include <map>
#include <memory>
using KVPCollectionType = std::map<std::string, std::string>;
class c {
public:
c(const KVPCollectionType&& kvps = {}){}
};
int main()
{
auto ok = std::make_shared<c>(KVPCollectionType{{"key1", "value1"},{"key2","value2"}}); // OK
auto ng = std::make_shared<c>({{"key1", "value1"},{"key2","value2"}}); // NG!!!
}
全てのバグを絶滅せよ。
「今日は死に日和」好評発売中。
「今日は死に日和」好評発売中。
C++11や14を使ってる人、コンパイラは何ですか。
ゲームエンジン作ってる人いますか
clとgcc。
c+11以降はバージョン違うと全く別のコンパイラ
Twitchでプログラミングしてるやつの中でゲームエンジンも居たような
>>347
テンプレートの推論ルールとして「関数テンプレートのパラメータとして波カッコの初期化子リストを渡して型推論させることはできない。」
ということになっている。 ( https://cpprefjp.github.io/lang/cpp11/uniform_initialization.html )
make_shared の実際の型は template <class T, class... Args> shared_ptr<T> make_shared(Args&&... args); なので、
このとき Args が推論できない以上はどうにもならん。
型を固定した専用の関数をはさんでこんな感じにするくらいのことしか思いつかないな。
#include <map>
#include <memory>
#include <initializer_list>
#include <utility>
using KVPCollectionType = std::map<std::string, std::string>;
class c {
public:
c(const KVPCollectionType&& kvps = {}){}
c(const std::initializer_list<typename KVPCollectionType::value_type>){}
};
std::shared_ptr<c> make_c_shared(std::initializer_list<typename KVPCollectionType::value_type> a) {
return std::make_shared<c>(std::move(a));
}
std::shared_ptr<c> make_c_shared(KVPCollectionType&& a) {
return std::make_shared<c>(std::move(a));
}
int main() {
auto ok = make_c_shared(KVPCollectionType{{"key1", "value1"},{"key2","value2"}});
auto ng = make_c_shared({{"key1", "value1"},{"key2","value2"}});
}
テンプレートの推論ルールとして「関数テンプレートのパラメータとして波カッコの初期化子リストを渡して型推論させることはできない。」
ということになっている。 ( https://cpprefjp.github.io/lang/cpp11/uniform_initialization.html )
make_shared の実際の型は template <class T, class... Args> shared_ptr<T> make_shared(Args&&... args); なので、
このとき Args が推論できない以上はどうにもならん。
型を固定した専用の関数をはさんでこんな感じにするくらいのことしか思いつかないな。
#include <map>
#include <memory>
#include <initializer_list>
#include <utility>
using KVPCollectionType = std::map<std::string, std::string>;
class c {
public:
c(const KVPCollectionType&& kvps = {}){}
c(const std::initializer_list<typename KVPCollectionType::value_type>){}
};
std::shared_ptr<c> make_c_shared(std::initializer_list<typename KVPCollectionType::value_type> a) {
return std::make_shared<c>(std::move(a));
}
std::shared_ptr<c> make_c_shared(KVPCollectionType&& a) {
return std::make_shared<c>(std::move(a));
}
int main() {
auto ok = make_c_shared(KVPCollectionType{{"key1", "value1"},{"key2","value2"}});
auto ng = make_c_shared({{"key1", "value1"},{"key2","value2"}});
}
>>347
ちゃんと考えたら >>354 はいらんことしとるな……
これで充分か
#include <map>
#include <memory>
#include <utility>
using KVPCollectionType = std::map<std::string, std::string>;
class c {
public:
c(const KVPCollectionType&& kvps = {}){}
};
std::shared_ptr<c> make_c_shared(KVPCollectionType&& a) {
return std::make_shared<c>(std::move(a));
}
int main() {
auto ok = make_c_shared(KVPCollectionType{{"key1", "value1"},{"key2","value2"}});
auto ng = make_c_shared({{"key1", "value1"},{"key2","value2"}});
}
ちゃんと考えたら >>354 はいらんことしとるな……
これで充分か
#include <map>
#include <memory>
#include <utility>
using KVPCollectionType = std::map<std::string, std::string>;
class c {
public:
c(const KVPCollectionType&& kvps = {}){}
};
std::shared_ptr<c> make_c_shared(KVPCollectionType&& a) {
return std::make_shared<c>(std::move(a));
}
int main() {
auto ok = make_c_shared(KVPCollectionType{{"key1", "value1"},{"key2","value2"}});
auto ng = make_c_shared({{"key1", "value1"},{"key2","value2"}});
}
>>354-356
ありがとうございます、その手を使わせていただきます
状況によって推定ルールが変わるのはやめて欲しいなってちょっと思ったんですけど。
ありがとうございます、その手を使わせていただきます
状況によって推定ルールが変わるのはやめて欲しいなってちょっと思ったんですけど。
メンバアクセスにthis->つける？
エディタの補完機能使いたいときにたまにそうやって補完して最後に消す。
が、たまに忘れる。
が、たまに忘れる。
IDEの都合で付ける事が良くある
付けないと補完候補多すぎて
付けないと補完候補多すぎて
ああなるほど
補完候補を絞るのには便利ですね
補完候補を絞るのには便利ですね
メンバであるという保証ができるので付ける
メンバ名は頭にm_付けろみたいなクソルールよりずっといいと思うので付けるべき
仮引数と別の名前つけるのだるいからm_は別に良いと思う
メンバ変数に専用の色付けたらいいじゃん
引数そのままメンバに入れるなら引数に_つけてvar(_var)って初期化してるわ
バーバー
ハンガリアン記法は、入力補完のないエディタ上での可読性を高めるのに役立ってるでしょ。今でも。
ゴミ使ってる奴のことなんか知らん
あれ可読性落ちるだろ
定期的にunsignedとsigned混在させてハマるアホをみるとハンガリアン必要だと思うわ
C#で入力補完のないエディタがどうとかさすがにナンセンスでは
だってvisual studio使うじゃん
だってvisual studio使うじゃん
どっちでもいいわ。
大抵の場合そんなとこに気を使わんといかんコードになってることのが問題。
大抵の場合そんなとこに気を使わんといかんコードになってることのが問題。
関係あることわかってなくて草
黙ってろゴミｗ
>>380
コードの問題じゃなくて言語仕様の問題だから
こういうえらそうなくせに何もわかってないカスが一番始末に困る
コードの問題じゃなくて言語仕様の問題だから
こういうえらそうなくせに何もわかってないカスが一番始末に困る
いつの間にかハンガリアンが言語仕様になってた。。
ハンガリアンも防御的なプログラミングと考えたら悪くないよ
成り立ち調べてみな
でも基本型とポインタだけだな
クラスには無用だと思う
成り立ち調べてみな
でも基本型とポインタだけだな
クラスには無用だと思う
てめーらはまともなIDEかエディタ使ってねえのかよ
むしろVSがないと何も書けない
VSがあっても何も書けない。
c++みたいに型情報ありがデフォルトの言語でハンガリアンとか二重メンテもいいとこだわ。
前方宣言したクラスをTにしたスマポメンバでコンパイル通るときと通らないときがあって調べてたら
デストラクタがインライン（暗黙）だと駄目だとわかった
しかもこの問題が起こるのはunique_ptrのときだけでshared_ptrはデストラクタの定義に関係なく通る
わけわからんぞ
教科書に書いておいてくれ
class ClassB;
class ClassA{
public:
ClassA();
private:
std::unique_ptr<ClassB> u; // NG
std::shared_ptr<ClassB> s; // OK
}
---
class ClassB;
class ClassA{
public:
ClassA();
~ClassA(); ←これでunique_ptrもOK
private:
std::unique_ptr<ClassB> u; // OK
std::shared_ptr<ClassB> s; // OK
}
デストラクタがインライン（暗黙）だと駄目だとわかった
しかもこの問題が起こるのはunique_ptrのときだけでshared_ptrはデストラクタの定義に関係なく通る
わけわからんぞ
教科書に書いておいてくれ
class ClassB;
class ClassA{
public:
ClassA();
private:
std::unique_ptr<ClassB> u; // NG
std::shared_ptr<ClassB> s; // OK
}
---
class ClassB;
class ClassA{
public:
ClassA();
~ClassA(); ←これでunique_ptrもOK
private:
std::unique_ptr<ClassB> u; // OK
std::shared_ptr<ClassB> s; // OK
}
>>388
unique_ptr<T>のデストラクタはインスタンス化するときにTが完全型であることを要求する（デストラクタで直接Tのデストラクタを呼ぶ）
unique_ptrを内包するクラスのデストラクタが暗黙だとクラス内でコンパイラによって実装されるけど、その場でunique_ptrのデストラクタを要求する
しかし、その翻訳単位内でTの定義が無ければコンパイルエラーとなる
unique_ptr<T>を内包するクラスのデストラクタがとりあえず宣言だけでもあると
実際の定義がある場所で同様の事が起こるので、その場所でTの定義が見つかればいい
その場合に定義を書かないと、コンパイラさんが適切な翻訳単位内に定義をおいてくれるみたい
shared_ptrは動的削除子のおかげでデストラクタが呼ばれるところで適切にデリータを定義し、デストラクタを呼ぶようになっているのでこの様な問題は起こらない
shared_ptr<T>のデストラクタ内ではTのデストラクタを直接呼び出すようなコードが無い
unique_ptr<T>のデストラクタはインスタンス化するときにTが完全型であることを要求する（デストラクタで直接Tのデストラクタを呼ぶ）
unique_ptrを内包するクラスのデストラクタが暗黙だとクラス内でコンパイラによって実装されるけど、その場でunique_ptrのデストラクタを要求する
しかし、その翻訳単位内でTの定義が無ければコンパイルエラーとなる
unique_ptr<T>を内包するクラスのデストラクタがとりあえず宣言だけでもあると
実際の定義がある場所で同様の事が起こるので、その場所でTの定義が見つかればいい
その場合に定義を書かないと、コンパイラさんが適切な翻訳単位内に定義をおいてくれるみたい
shared_ptrは動的削除子のおかげでデストラクタが呼ばれるところで適切にデリータを定義し、デストラクタを呼ぶようになっているのでこの様な問題は起こらない
shared_ptr<T>のデストラクタ内ではTのデストラクタを直接呼び出すようなコードが無い
うーんC++プライマー8500円かぁ。本家のプログラミング言語C++第4版はもっとするし
情報量からすると安いが本一冊にポンと出すにはお高い……日本語である程度網羅的な本となるとこの2冊くらいよね
情報量からすると安いが本一冊にポンと出すにはお高い……日本語である程度網羅的な本となるとこの2冊くらいよね
set<double> って int のときと同様にちゃんとソートされるんですか？
NaNが無ければ大丈夫NaNじゃね
NaNが無ければ大丈夫NaNじゃね
のちに永久保存される平成最後のスベり
たしかにそうだな・・いよいよ平成最後なんだな
みなさん、>>393-394 みたいな事にならないよう、気をひきしめましょう
みなさん、>>393-394 みたいな事にならないよう、気をひきしめましょう
平成最後っていう言い回し使われすぎて嫌いになってきた
イテレータの参照を次に移すときってなんでitr++ではなく++itrなの？
ヤフーでぐぐれ
素直な実装だとitr++より++itrのほうが速いんじゃないかなあ、となんとなくみんなが思っているから
