C++は難しすぎ難易度:2

C++は難しすぎ難易度 ..

491:デフォルトの名無しさん
04/11/28 21:39:47
しっかし、組み込み型(intとかdoubleとか)のコンテナならSTLのアルゴリズムは
教科書通りに使えるんだが、クラスになると途端に使い物にならなくなるのは
どういうこと?
STLの範囲で済ます場合、メンバ関数ならアダプタでなんとかなるが、メンバ変数は
叙述関数・関数オブジェクトを用意しなければならない。
正直、boost::bindやboost::lambdaが無かったらやってられないよ。
でもこれも一長一短で、boost::lambdaは動かないコンパイラもあるし(bcc32)、
boost::bindは遅いし。

492:デフォルトの名無しさん
04/11/28 22:55:18
> boost::bindは遅いし。
なんで？

493:デフォルトの名無しさん
04/11/28 23:17:06
>>492
なんでだろう? 俺が聞きたいよ。
アセンブリコード見たけどよく分からん。あまり最適化されてない様子。
lambdaは早いんだけどな。
単純なlambda式なら、イテレータをループで回すより早かったりする。

494:デフォルトの名無しさん
04/11/28 23:47:31
>>493
テストコード出せる？

495:デフォルトの名無しさん
04/11/28 23:49:47
boostの一部のライブラリを見てると、素直にC++にクロージャを足した
新しい言語を作って使えよと言いたくなる。

496:デフォルトの名無しさん
04/11/28 23:55:10
boost使ってる時点で負け組み

497:デフォルトの名無しさん
04/11/28 23:57:22
>>496
何を使うと勝ち組みになれるの？
boost のめざそうとしているものを使わなくてもいいってこと？

498:デフォルトの名無しさん
04/11/29 03:52:25
>>495
C++Builder言語

499:デフォルトの名無しさん
04/11/29 08:41:38
C++が難しいのは、テンプレートのがポリモルフィズムより速いからだと思う。

500:デフォルトの名無しさん
04/11/29 08:55:56
URLﾘﾝｸ(pc5.2ch.net)
ｽﾚﾘﾝｸ(tech板)

501:デフォルトの名無しさん
04/11/29 09:53:18
>>495
templateの良し悪しはともかくとして、
言語のコアとしてそういった概念のシンタックスを
持つのではなく、メタプログラミングによって後から
追加できるのっていいなと思うけど。

502:デフォルトの名無しさん
04/11/29 11:15:07
このスレ見てるとげんなりしてくるなｗ

503:デフォルトの名無しさん
04/11/29 11:19:09
>>501
同感、クロージャーなどを突っ込むよりtemplate機能をもっと整理して
この種の機能はライブラリとして実装してもらいたい。
クロージャー以外にもデザパタ一式ガベコレ一式程度は自働ジェネレートできるくらいがいい。
言語のコアはあくまでシンプルで高速な物がいい。

504:デフォルトの名無しさん
04/11/29 12:55:33
VC++で計算した数値を引数で表示したいんですが、printfで表示されません。だからMessageBoxを使って表示したいんですがエラーがでます。どうしたらいいんでしょうか？どなたか分かる人教えてください。

505:デフォルトの名無しさん
04/11/29 13:10:08
( ﾟДﾟ)ﾎﾟｶｰﾝ

506:デフォルトの名無しさん
04/11/29 15:55:09
505うぜーよ！！
知らないならくるな！！！
消えちまえーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

507:モウモウ
04/11/29 21:13:40
>>504
とりあえず、現状のソース見せて。

508:デフォルトの名無しさん
04/11/29 21:15:44
質問した本人はそのスレ全てを覚えてるとは思えないが…(笑)

509:デフォルトの名無しさん
04/12/04 16:22:48
「ファイアーエムブレム」は難しすぎ
URLﾘﾝｸ(game.2ch.net)
Linuxは難しすぎ
URLﾘﾝｸ(pc.2ch.net)
三連複は難しすぎ
URLﾘﾝｸ(cocoa.2ch.net)
メモ帳は難しすぎ
ｽﾚﾘﾝｸ(win板)

510:デフォルトの名無しさん
04/12/13 13:46:51
C++はSTLと継承を使いこなし始めた辺りが
生産性・理解向上の分水嶺だった記憶がある。

511:釣られたか(w
04/12/13 14:01:00
>504
ConsoleとWinアプリは違うから。
デバイスコンテキストをキーワードに勉強しる。

あとこの手の質問はVC++のスレ・・・って適当なの無いな今は　MFC限定しか

512:デフォルトの名無しさん
04/12/13 14:44:57
>>511
★初心者にVisual C++を教えるスレ★ Part16

513:デフォルトの名無しさん
05/01/01 23:35:39
C++には、他に類を見ない自由と絶対的な○○が与えられている。

514:デフォルトの名無しさん
05/02/15 18:08:52
C++の機能限定版とか無いの？

515:デフォルトの名無しさん
05/02/15 18:32:19
>>514
例外、クラス、関数オーバーロードや
デフォルト引数などの機能を取り除いた
C　というものがあります。

516:デフォルトの名無しさん
05/02/16 18:00:21
>>514
EC++なんてものもある。
Wikipedia項目ﾘﾝｸ

517:デフォルトの名無しさん
05/02/17 00:39:05
>>516
だがしかし、はっきり言ってウンコだ。

518:デフォルトの名無しさん
05/02/19 00:11:41
>>516
例外処理が省かれてるのが最大の問題だな。

519:361=別名ポリホ
05/02/19 00:26:05
>>518

テンプレートも名前空間もない。
実際にEC++環境があったのでコーディングしてみたことがあるけど、
全然C++らしくない。

520:デフォルトの名無しさん
05/02/19 06:54:53
まああくまでもembeddedだからねえ。

521:デフォルトの名無しさん
05/02/22 15:21:43
時々、ECMAScript をバイナリに落とすことが出来ればと考えることがある。

obj = new Object;
obj["Method"] = function( a, b )
{
　echo("OK");
}

obj.Method(); // OK

441 がやりたいことも、プロトタイプ取得で簡単OK

522:デフォルトの名無しさん
05/02/23 14:30:47
漏れの考えはこうだ！

>461 様の例で「ＣからＣ＋＋に移ったばかりの人」の書き方は
いかにも効率が悪そうな印象を受けるけど、
漏れが「仕事で」プログラムを作るなら、
迷わずこのやり方を取る。
（かなり馬鹿にされるだろうけど…。）

そして趣味で（個人的な事情で）プログラムを作るなら、
「Ｃ＋＋を使い慣れてきた人」や「Ｃ＋＋が『使える』というレベルの人」のような
書き方ができるように努力するだろう。

なぜなら仕事でプログラムを作り、それを他の技術者に引き継ぐ場合、
単純な書き方がもっとも無駄な手間を省くからだ。

そして多くの場合、理解しにくいバグの発生を予め抑制することができる。
また、改修を加えるときや、
不幸にしてプラットフォームの異なる環境へ移植する場合にも、
少ないコストで作業を終えることができるであろう。

スレ違いで申し訳ないけど、
引継ぎ作業によるコストって、
プログラムの書き方で随分変わるんですよ。

「凄いＣ＋＋技術者」の書いたプログラムを引き継いだ場合、
「凄くないＣ＋＋技術者の私」が改修を加えるのは大変なんですよ。

523:デフォルトの名無しさん
05/02/23 15:30:38
>>522
ごく普通なC++プログラマな私からすれば、他人のソースを引き継いだときに
ループが書いてあったらそれだけで要注意項目になります。
std::fillならそのまま読み飛ばせる分だけ、引き継ぎコストは抑えられるわけですな。
構造体も然り。初期化処理をその構造体を利用する側でやらなければいけないよりは
コンストラクタを書いておいてくれたほうがよっぽど確実。
まぁ、「凄くないC++技術者=C++をベターCとしてしか使えない技術者」というなら別ですが。

524:デフォルトの名無しさん
05/02/23 18:11:34
ようするに522が凄いC++技術者になればいいだけ。

525:デフォルトの名無しさん
05/03/12 16:40:27
なんで一時オブジェクトは非const参照に変換できないんだ
template<typename E, typename T, typename A, typename Value>
inline std::basic_string<E, T, A>& ToString(std::basic_string<E, T, A>& rstr, Value t) {
　　return rstr = static_cast<std::basic_ostringstream<E, T, A>&>(std::basic_ostringstream<E, T, A>() << t).str();
} //static_castしないとエラーを吐く。これはコンパイラのせいだと思う。
#define ToStr0(t) ToString(std::string(), t)

template<typename E, typename T, typename A, typename Value>
inline std::basic_string<E, T, A>& ToString(std::basic_string<E, T, A>* pstr, Value t) {
　　return *pstr = static_cast<std::basic_ostringstream<E, T, A>&>(std::basic_ostringstream<E, T, A>() << t).str();
}
#define ToStr1(t) ToString(&std::string(), t)

int main() {
　　cout << ToStr0(5) << endl;　　//エラー：一致するものが見つからない
　　cout << ToStr1(.125) << endl; //OK
　　return 0;
}
って書こうと思ったんだよ。
そしたらふと思いついてこうしたら動くんだよ。
#define ToStr0(t) ToString((std::string&)std::string(), t)
頼むからこんなのキャスト無しでも適当にやってくれよ。

そもそもオブジェクトを値渡しで返そうとするとインライン展開できない
ってのがなけりゃこんなことで悩む必要は無かったんだよ＞Borland

526:デフォルトの名無しさん
05/03/12 17:34:19
それはインライン展開しない方がいいと思うが。

つうか、boost::lexcal_castとか素直に使った方がええんじゃないの？

527:デフォルトの名無しさん
05/03/12 19:06:53
>>526
lexcal_cast.hppをインクルードするとエラーになってしまうもんで。

528:デフォルトの名無しさん
05/03/13 04:15:03
>>525
> //static_castしないとエラーを吐く。これはコンパイラのせいだと思う。

ostream に対する operator << の戻り値は ostream& だから、
コンパイラに依らずエラーになるはず。
一時オブジェクトで処理しようとしているのが間違い。

529:デフォルトの名無しさん
05/03/13 11:35:07
>>523
for ( xxx i = foo.begin(); i != foo.end(); ++i.) {
　nannka(*i, arg1, arg2, arg3);
　kannka(*i, arg4, arg5);
｝

こんなのは、NGで
一回しか使わんつまんねえファンクタわざわざ宣言して
for_eachなりつかわんとNGなんだよな？

アンタがそうゆう主義なのはかまわんが
それがごく普通かねえ？

つうか、実務経験なさそうなふいんき

530:デフォルトの名無しさん
05/03/13 13:12:54
>525
形式的には、一時オブジェクトは右辺値なので非 const 参照に変換できない。

非 const 参照→呼び出された側で変更される
＋
一時オブジェクト→もともと定数だった可能性がある / すぐに破棄される
＝定数のものを変更しようとしている / 変更された値が破棄される
ということでデフォルト安全側に倒してるんじゃないでしょうか。

531:523
05/03/13 15:09:14
>>529
んにゃ、一々ファンクタ書くまでもない処理ならループでもいいんでない?
ただ、ファンクタもいらんような単純な処理まで一々ループを書くなって話。
適切な比較オペレータを持っているクラスだというのに一々findループを書く神経は疑うってことね。
まぁ、>529の例ならファンクタ書かれるよりはループで書かれた方がよっぽどまし。
更に言えば、for (int i = 0; i < foo.size(); i++) なんて書かれるよりずっとまし。

532:デフォルトの名無しさん
05/03/15 02:44:42
そこでlambdaですよﾜﾗ

533:デフォルトの名無しさん
05/03/19 05:54:34
>>531
しょーもないことにこだわってるあたり覚えたての学生とみた（遠い目

534:デフォルトの名無しさん
05/03/19 10:29:39
「まし」とか繰り返して、さも自分にはもっといい案があるかのように匂わせておいて
結局そのまま書かずに退散するのが「らしい」ですよね ;-)

535:523
05/03/19 10:41:38
んー、ないよ～
単にどっちがいいかって書いただけだし。
ファンクタを作らなくてもalgorithmのfind使えるケースで自分でループ書くのや
iterator使わずに制御変数でループを回すのが要注意だって話で。
>529の例ならそれでなんも問題ないんでない?
#そもそも私自身がファンクタ作るの苦手だw

536:デフォルトの名無しさん
05/03/21 12:01:02
C++よりMLの方がいいよ。

537:デフォルトの名無しさん
05/03/24 05:34:21
まあバランスが大事だよな

538:デフォルトの名無しさん
05/03/25 07:52:46
Ｃ＋＋はすさまじく肥大化した言語。しかし、慣れると機能が多くて便利なのも事実だったりする。
シンプルといわれていたJAVAもバージョンが新しくなるにつれて肥大化が進んでいる。
Ｃ＃はＣ＋＋から機能を削ったとはいえ、機能を付け加えているから最初から肥大化している。
機能が多い言語は必ず肥大化し、複雑になってしまう。

シンプルで初心者に優しいけど「不便な言語」よりは、複雑で便利な言語のほうが良いと思が、
複雑な言語は初心者には優しくない。

初心者にやさしい「複雑な言語」があれば望ましいけど、それは無理かもしれない。

539:デフォルトの名無しさん
05/03/25 08:59:47
>>538
(行き着く先は)自然言語。
そして曖昧さと冗長性が増える罠。

540:デフォルトの名無しさん
05/04/25 00:25:10
シーピーピー　シーピーピー　シーピーピー　シーピーピー
シーピーピー　シーピーピー　シーピーピー　シーピーピー
ろ　く　な　も　ん　じ　ゃ　ね　ー

541:デフォルトの名無しさん
05/04/25 08:41:55
負け犬?

542:デフォルトの名無しさん
05/04/26 23:11:19
int n;
n.~int();
これがコンパイルを通ってしまうのに驚いた。
こんな関数にint型の値を渡してもコンパイルが通ったからまさかと思ってやってみたら通った。
template <class T>
void Destroy(T& t)
{
　　t.~T();
}

543:デフォルトの名無しさん
05/04/26 23:52:59
>>542
VS.net2003だと下のテンプレ関数のみ通った。
n.~int();は error C2059: 構文エラー : ''<L_TYPE_ambig>'' って出る。

544:デフォルトの名無しさん
05/04/27 00:21:50
テンプレートじゃなくても通るのが正しいような気がする。

545:デフォルトの名無しさん
05/04/27 13:49:42
>>538
今ならまだＤ言語のライブラリは少ない…貧弱

546:デフォルトの名無しさん
05/04/27 14:17:59
C++もなにかしようと思ったら機能が貧弱だよ
GCもないし、拡張工事をせざるを得ない
良くも悪くもCなんだな

547:デフォルトの名無しさん
05/04/28 00:29:01
>>546
そうだね、あせんぶらにもGCつければべんりだね（わら

548:デフォルトの名無しさん
05/04/28 05:10:40
>>546
そうじゃなくて、君の頭じゃC++は無理なんだよ。

549:デフォルトの名無しさん
05/04/28 05:16:58
何見当違いの煽りをしてるんだか。

550:デフォルトの名無しさん
05/04/28 07:44:37
javaは.closeを書かせておいてGCがあると
主張するのは無理がある。同期のコードなんてCそのものだ。
そういえばGenericsもプリプロセッサで実装しているし
assertの実装は失笑である。javaは新しいCなのだろう。
DはRAIIというのがあるようだ

551:デフォルトの名無しさん
05/04/28 17:52:40
C++はむずかしいので、機械語で書いてます。

552:デフォルトの名無しさん
05/04/28 18:04:09
>551
俺にはそっちの方がムズい…

553:デフォルトの名無しさん
05/04/29 02:10:38
BCBのヘルプに
「alloca 関数の使用はあまりお勧めできません。」
って書いて有るんですけど、そうなんですか？

554:デフォルトの名無しさん
05/04/29 09:14:17
>>553
スタックを食い潰すし、移植性に乏しいからでは?

555:デフォルトの名無しさん
05/04/29 10:02:13
C99ならVariable Length Arraysを使ったほうが良いかと。

556:デフォルトの名無しさん
05/04/29 17:30:06
C++ならstd::auto_ptrを使ったほうが良いかと。

557:デフォルトの名無しさん
05/06/02 20:59:36
仮想関数を使えばswitch-caseの嵐から抜けられるわけで、個人的にはそれだけで大満足です。

558:デフォルトの名無しさん
05/06/02 23:37:01
>557
だね。場合分けをすることなしに、異なる振る舞いを事前に記述して、コンパイラ任せにできる
有利性、というか。

でも、その有利性を理解できない層というのも確実にあって、それは何かっつーと、
仮想関数という概念、というか言語仕様を知らない層なんだよね。C++はもちろん、
Javaも知らないという層。switch-caseで、あり得る場合分けが全部ソース上に
明記してあった方が判りやすいしデバッグしやすいじゃん、と主張してきそうな、
えてしてそういう層が実装仕様を決めやがるんだよなあ。おっとこれはグチだな。すまん。
誰か強力に布教してくんねーかな。俺はもー疲れた。

559:デフォルトの名無しさん
05/06/03 05:12:20
>>558
無理。そういう層は大抵「学習意欲」＜「日々の仕事をこなすこと」だから。

560:デフォルトの名無しさん
05/06/03 11:21:57
switch-case の代わりとしての仮想関数なら C でも出来るわけで。

561:デフォルトの名無しさん
05/06/03 11:26:56
>>560
だからどうした？

562:デフォルトの名無しさん
05/06/04 00:16:50
C++儲のおいらでも560には半分同意。
switchの代わりなら構造体+関数ポインタでも
それほど労力がふえるとも思えない。
勿論、仮想関数の方が楽なのは事実だけど。

むしろ、Cで困るのはコンストラク・デストラクタ・templateがない事。
auto_ptrを見ても分かるようにデストラクタが非仮想であっても、
templateと組み合わせればものすごく便利になる。
これが無い故に生成と破棄がセットになったリソースを複数作る
処理で、生成失敗時の破棄処理を書いてるとうんざりする。

563:デフォルトの名無しさん
05/06/04 01:28:29
要するに、リソースリークを避けるための下らない労力、プログラムの本質
から大きく外れたロジックやコードがCでは多くを占めてしまうってこったよな。
文字列やリストなんて単純なものも、Cでは悩みの種だ。

まあメモリリーク回避だけならGC使う手もあるがなー。
GC使えるような環境なら今時Cなんて使うなよという話もあるが。

564:デフォルトの名無しさん
05/07/13 23:42:53
この速度ならぬるぽ

565:デフォルトの名無しさん
05/07/13 23:45:51
>564
ｶﾞｯ!
ちゅーかまたお前かっ！

566:デフォルトの名無しさん
05/07/20 22:15:59
sageてぬるぽもなかろうに
それよか、こんな過疎スレで
sageぬるぽに3分でｶﾞｯした565の方が神

567:デフォルトの名無しさん
05/07/24 23:15:44
int main()
{
　 std::locale::global(std::locale("japanese"));
　 _bstr_t bs(L"ほげ");
　 std::wcout << bs << std::endl; //static_cast<const wchar_t *>(bs)とすれば無問題。
　 return 0;
}

VC7.1だとbsはconst wchar_t *か悪くてwchar_t *へ変換されるかと思いきゃ、
なぜかこれに解決される。せめてconst wchar_t *とであいまいにしてくれよ。
template<class _Elem, class _Traits> inline
　 basic_ostream<_Elem, _Traits>& __cdecl operator<<(
　 basic_ostream<_Elem, _Traits>& _Ostr, const char *_Val)

568:デフォルトの名無しさん
05/07/30 10:43:10
今更だけどブロック内での関数宣言を廃止し、全て変数宣言と見なすという仕様にすれば良かったのにと思う。

569:デフォルトの名無しさん
05/07/31 00:36:05
>>568
そのメリットは？

570:デフォルトの名無しさん
05/07/31 01:25:38
>>569
コンストラクタ呼び出しで作った一時オブジェクトでローカル変数を直接初期化できる。

struct S0 { S0(); };
struct S1 { S1(S0 zero); };

int main()
{
　S1 x(S0()); // 現行の規格では関数宣言
　...
}

571:デフォルトの名無しさん
05/07/31 04:20:58
>570
S1 x = S0(); で回避できると思うけど、いちいち気にするのがいやってこと？

572:デフォルトの名無しさん
05/07/31 04:45:26
>>571
その書き方だと暗黙の変換とコピーコンストラクタが必要になる。
S1を↓のようにするとコンパイルできない。
struct S1 { explicit S1(S0 zero); };
struct S1 { S1(S0 zero); private: S1(S1 const&); };

573:デフォルトの名無しさん
05/07/31 05:09:49
>>569
ブロック内で関数宣言する奴なんて見かけない。みんなヘッダをインクルードする。
570みたいなコードは誰もが最初変数宣言だと思ってはまる。
それだったら全部変数宣言にするほうが、わかりやすいんじゃないかと考えた。

たとえば「ブロック内では関数宣言をしたければexternを付ける必要がある。
externなしで関数・変数宣言どちらともとれるときは変数宣言」とでもすればよかったのにと思う。

574:デフォルトの名無しさん
05/07/31 10:32:18
>>573
Cとの互換性を最優先した結果、なんだろうなあ。

575:デフォルトの名無しさん
05/08/01 12:09:55
>>570
S1 x((S0()));

()の2バイト分も面倒か？

576:デフォルトの名無しさん
05/08/01 14:22:05
対処法の有無はこの話題には関係無いだろう。

577:デフォルトの名無しさん
05/08/02 00:55:12
>576
その対処法によって、570のいう、
> コンストラクタ呼び出しで作った一時オブジェクトでローカル変数を直接初期化できる。
ことができない(実際にはできる)という、現行規格への不満が解消されるのだから関係ある。

まぁ570が、一時オブジェクトをローカル変数のコンストラクタに渡す文法を知らなかっただけのようだが。

578:570
05/08/02 01:51:48
知ってたよ。

579:デフォルトの名無しさん
05/08/02 03:51:30
一見変数宣言に見えてしまうややこしさを問題としてるという論点に気付かない>>577を暖かく見守る俺が579ゲットですよ

580:577
05/08/02 10:28:59
結局568の主張は、
とくに機能的な違いはないけど、今の文法は見た目がわかりにくいから、
ブロック内での関数宣言を廃止し、全て変数宣言と見なすという仕様にすれば良かったのに
ってことなのね。

ぱっと見のわかりやすさは重要だと思うけど、もう二重に括弧つける癖がついたんで、どうでもいいかなと思う。
>579 サンキュー。これからも暖かく見守ってください。

581:デフォルトの名無しさん
05/08/05 01:15:34
このスレの人たちは英文をバリバリに読めるのか？
俺全然読めない。

582:デフォルトの名無しさん
05/08/05 06:24:21
英語しかなければ読むけど、ちょっと下手という程度なら日本語に喜んで飛びつきますが何か。
規格だってISOではなくJISの訳を読むし。

583:デフォルトの名無しさん
05/08/05 10:31:42
キチガイ翻訳はお断りだが

584:デフォルトの名無しさん
05/08/08 16:18:38
>>583
じゃお前が翻訳してくれ

585:デフォルトの名無しさん
05/08/08 18:40:15
それが出来りゃ原書読むわい

586:デフォルトの名無しさん
05/08/15 09:49:34
糞　ス　レ　勃　て　て　ん　じ　ゃ　ね　え　よ　脳　挫　傷　！

587:デフォルトの名無しさん
05/08/15 12:19:58
>>586
今頃何言ってんの？m9(ry

588:デフォルトの名無しさん
05/08/15 13:32:23
ﾌﾟｷﾞｬ（ｒｙ

589:デフォルトの名無しさん
05/09/03 20:06:30
OSのベータ版を市販するやり方は
どこにもマネできないくらい最強

590:デフォルトの名無しさん
05/11/21 20:30:09
JavaScriptは難しすぎ
ｽﾚﾘﾝｸ(hp板)

591:デフォルトの名無しさん
05/11/28 14:52:04
ポインタと参照を混ぜるとややこしいから、ポインタで統一してるんだけど
参照しか使えない場合もあるしなんなんだよ！！

592:デフォルトの名無しさん
05/11/28 15:29:17
俺はなるべく参照を使って、仕方ない時だけポインタを使う

593:591
05/11/29 14:48:00
あっそうかスマートポインタ使えばいいんだって使ってるプロジェクト
見たことねえorz

594:デフォルトの名無しさん
06/01/04 11:55:46
もっともっと難しくなって構わないから早く来いC++0x。
なんてこのスレで言うとぼこぼこにされそうだ。

595:デフォルトの名無しさん
06/01/06 00:21:22
C#に慣れてきたらC++触るのﾃﾗダルくなってきた…
つーか、同じVisualStudioなのにエディタの出来があからさまにVC#＞＞＞＞＞＞VCなのは何の嫌がらせだよ

596:デフォルトの名無しさん
06/01/06 00:35:56
>>595
(ﾟ∀ﾟ)人(ﾟ∀ﾟ)ﾅｶｰﾏ

597:デフォルトの名無しさん
06/01/08 01:29:03
>>595
Ｃ＃はＭ＄が作った言語だからＪａｖａ、Ｄｅｌｐｈｉ潰しをしながら
普及のために本気にならんといかんのだよ
Ｃ＋＋についてはＭ＄の都合におかまいなく拡張されたりするから
ほんとはサポートすんのヤなの
だけどＣ＃がコケた時の保険のつもりで一応サポートしとくの
これが戦略。わかる？
ほんとはＣ＃、ＶＢで世界を支配したいの
あとはオマケ

598:デフォルトの名無しさん
06/01/08 03:30:39
>>597
2バイト文字使うなら
せめて♯を使えよと。

599:デフォルトの名無しさん
06/01/08 19:48:58
エディタはEmacs系を使えばいいのだ、勝手に補間するVSの親切エディタとは手を切れ、
あれは人を堕落させる。

600:デフォルトの名無しさん
06/01/09 00:59:30
>>595
言語仕様が複雑でC#よりﾏﾝﾄﾞｸｾからじゃないかなあ。

601:デフォルトの名無しさん
06/01/09 21:15:09
>>595
なんか、MSはC#を無理やり推し進めている感じだしね。
FXではWIN32 API呼ぶのにオーバーヘッドがあるようだし・・・

602:デフォルトの名無しさん
06/01/11 23:05:13
つーかアプリのパフォーマンスにAPIのオーバーヘッドなんざ
ほとんど関係ないと思うが。処理の9割以上は自分のコード
の中だろ？

603:デフォルトの名無しさん
06/01/13 12:29:12
だから、３０歳過ぎて、社会の政治的な要因に太刀打ちできるような
立場になってからもデザインパターンみたいな一技術で重宝されるような
人物に対して「逃げ道だよな」って言ってるの。２０代の奴がやりたくてもできないような
ところで自分をアピールする術を持ってないのかって。
中堅者のやることっていったら、２０代の奴が仕事をしやすいように、いろいろと根回しすることだろ？
年齢重ねても、やることが２０代の延長だったら会社に居る意味ねーよ。
スパゲティコードだとか、その辺は中堅社員が口出すことじゃねーって。
むしろ、２０代の奴が気付いて、中堅社員に意見をＵＰして、それから中堅社員が根回しするのが理想。
要は、いい歳こいて低レベルな話してんじゃねーよって。もっと抽象的になれってことだ。

604:デフォルトの名無しさん
06/01/13 13:44:16
>>603
> だから

まで読んだ。

605:デフォルトの名無しさん
06/01/13 18:34:11
>>603
日本語でおｋ

606:デフォルトの名無しさん
06/01/14 03:46:11
日頃誰にも吐き出せず溜め込んでいたモノを一気に吐き出したようだが、
そうやって長年熟成させてきた割には深みゼロなのが哀しいね。
まぁ、この程度の頭だから、誰にも認められずストレス溜めてるんだな。

607:デフォルトの名無しさん
06/01/14 13:09:20
>>603
デジャブか。
どっかでみたレスだ。

608:デフォルトの名無しさん
06/01/16 18:52:13
>>606
では君が深みのある話をしてくれ。ぜひ読みたい

609:デフォルトの名無しさん
06/01/17 11:53:19
>>608
「では」の使い所が変ですね。

610:デフォルトの名無しさん
06/01/17 17:23:19
>>603
> 「で

まで読んだ。

611:デフォルトの名無しさん
06/01/17 18:50:02
普通に603より609のほうが深いのが悲惨だなｗ

612:デフォルトの名無しさん
06/01/26 21:11:27
>>609
ではどうすれば正しいのか教えてくれ

613:デフォルトの名無しさん
06/01/26 21:54:07
その使い方は正しい。>>608は変。

614:デフォルトの名無しさん
06/01/29 20:48:13
>>613
どう変なのか説明よろ

615:デフォルトの名無しさん
06/01/30 07:10:13
繋がりがまるでない。

616:デフォルトの名無しさん
06/01/30 12:01:29
>>614
批判に対して「じゃあお前がやってみろ」というのは
反論にも何にもなってないわけですが、
小学生くらいだと別におかしいとは思わないようですね。

617:デフォルトの名無しさん
06/01/30 22:33:06
お前らもっと生産的なことに労力を使うように汁。

618:デフォルトの名無しさん
06/04/21 14:44:27
C++を使いはじめて10年以上になるが、
これまでC++をC++として使える奴って未だ見た事がない。
このスレでC++を絶賛している奴は本当にC++を使いこなしているのか疑問。

619:デフォルトの名無しさん
06/04/21 19:12:33
2chだし、ピンキリいると思うよ。

620:デフォルトの名無しさん
06/04/21 21:41:08
そもそも何を持ってC++をC++として使っているというのかが曖昧。

621:デフォルトの名無しさん
06/04/22 01:17:52
2chでなくてもピンキリ
URLﾘﾝｸ(sourceforge.jp)

622:デフォルトの名無しさん
06/04/22 10:47:13
>>618
おまいの周囲の連中のレベルなんか知ったこっちゃないが
>このスレでC++を絶賛している奴は
「絶賛」する奴 (いたっけ？) は信用するな。
見た目だけで「あいついい女だよな」っつってる奴は
その女と付き合ってるわけではない。

623:デフォルトの名無しさん
06/04/29 16:21:55
そもそもオブジェクト指向が難しすぎ
gotoを使って何が悪いんだ

624:デフォルトの名無しさん
06/04/29 17:17:48
>>623
それはない。

625:デフォルトの名無しさん
06/05/01 12:07:03
>623
オブジェクト指向とgoto不要論を同じレベルで論じるなよ

626:デフォルトの名無しさん
06/05/22 14:29:18
>>595
>つーか、同じVisualStudioなのにエディタの出来があからさまにVC#＞＞＞＞＞＞VCなのは何の嫌がらせだよ
だよな

627:デフォルトの名無しさん
06/05/24 11:55:09
C++の標準化委員会は冒険的に過ぎるところがある。
C++がこれだけ強力な言語になったのは彼らの力だけど、
いろいろと取り返しの付かない失敗をしている。
slice_arrayで大恥をかき、exportや<cNNN>ヘッダで実装者を悩ませ、
言語仕様の穴を利用してauto_ptrを実装してしまう。
koenig lookupなんかは、ライブラリの設計ミスを言語仕様側で
取り繕おうとして傷口を広げた例だね。
もう少しやる気の無い連中、あるいは後方互換性にこだわらない連中が
標準化をやっていればこんなに難しい言語にはならなかっただろうに。

628:デフォルトの名無しさん
06/05/24 12:40:01
で、C++のどこが難しいんだ？
クラスが分からないのか？

629:デフォルトの名無しさん
06/05/24 12:54:45
>>627
概ね頷けるところだが、
> koenig lookupなんかは、ライブラリの設計ミスを言語仕様側で
> 取り繕おうとして傷口を広げた例だね。
これだけ、聞いた事が無い話だった。
何のこと？

630:デフォルトの名無しさん
06/05/24 13:05:06
>>627
>後方互換性にこだわらない
ここ同意

631:デフォルトの名無しさん
06/05/24 13:12:19
後方互換性は、言語使用の複雑さの原因であることは確かなんだが
普及の速度には大きく貢献してるだろうから、単純に否定できないと思うんだ。

632:デフォルトの名無しさん
06/05/24 15:52:15
まぁ、実際に携わってみれば誰もが苦しむところだろうな。

633:デフォルトの名無しさん
06/05/24 17:05:09
>>631
まあそうなんだけど、予約語の使いまわしが
初学者を混乱させてんじゃないかな、と。

634:デフォルトの名無しさん
06/05/24 18:51:51
ケーニヒがなかったら
a + 1 // OK a.operator+(1)
1 + a // NG
my_namespace::operator+(1,a) // OKだが書いてられるか

635:デフォルトの名無しさん
06/05/24 20:17:10
D&Eを読めば嫌と言うほど互換性確保に努めてきた様子がひしひしと伝わってくる。

636:デフォルトの名無しさん
06/05/24 21:43:18
初学者のためにOSのカーネルがコンパイルできなくなるなんて
許されないからな

637:デフォルトの名無しさん
06/05/24 23:01:13
>>629 >>634
operatorやswapをこんな感じにしておけばKoenig lookupは要らなかった。
lessを提供すればless_equalも勝手に実装してくれるとか、
そういう仕組みを作ることもできる。

namespace std {
　　 ...
　　 namespace hooks {
　　　　 template <class T1, class T2>
　　　　 struct plus_traits;

　　　　 template <class T>
　　　　 struct plus_traits<std::complex<T>, std::complex<T> > {
　　　　　　 typedef std::complex<T> result_type;

　　　　　　 static std::complex<T>
　　　　　　 plus(const std::complex<T> &a1, const std::complex<T> &a2)
　　　　　　 { ... }
　　　　 }
　　 }
}

template <class T1, class T2>
std::hooks::plus_traits<T1, T2>::result_type
operator+(const T1 &a1, const T2 &a2)
{ return std::hooks::plus_traits<T1, T2>::plus(a1, a2); }

638:デフォルトの名無しさん
06/05/24 23:17:26
>>637
それだと operator+ を定義していないクラスに + を使おうとしたとき、
plus_trais についてのエラーメッセージが出るよね？それもなんかおかしくね？

639:デフォルトの名無しさん
06/05/24 23:25:01
>>637
わざわざstd::huck::plus_traitsに持っていく意味がわからない。

640:デフォルトの名無しさん
06/05/25 00:19:15
>>638-639
std::hooksに含まれているテンプレートを部分特殊化してくれって意味。
オーバーロード解決に相当する処理をテンプレートで実装する必要があるから、
現行C++の機能だけで完全に実現できるかは分からんけど、
必要ならコンパイラにいくつか機能を追加すればいい。

641:デフォルトの名無しさん
06/05/25 00:41:39
>>640
コンパイラに koenig lookup を追加すればいいってことだな。

642:639
06/05/25 02:39:06
>>640
その意味はわかるけど意図が判らない。
直接operator　+を特殊化すればよいのではないかと思った。

643:デフォルトの名無しさん
06/05/25 02:46:28
>>637
これはこれで一時期は真剣に考察されていた案ですけれど，
結局「分かりにくい」ということで一度標準委員会で否決されているんですよね．
swap の場合ですけれど．

特にデフォルトがない hook の場合，特殊化に基づく hook の提供は
exact match を要求する，つまり特殊化したい型それぞれに
いちいち全部特殊化を用意しなければならない
（これは base-derived や cv-qualification まで含めて厳密にやらないといけない）
のに対して， ADL による hook は loose match で済む，
例えば base に対する特殊化が derived に自動的に適用されるような
直感的なあり方に一応適合します．
この議論は関数テンプレートの部分特殊化 (FTPS) が導入されても
基本的な議論の流れに大きな変化はないでしょう．
（というか，クラステンプレートの静的メンバ関数を用いるそもそもの動機は，
FTPS が現行規格で存在しないことの workaround だったはずです）

もちろん ADL による hook の提供の場合も，一般に挙動が非常に予測しにくい，
つまり，名前空間お構いなしでありとあらゆる名前空間を潜在的にぶち破る
凶悪な特性を持ちえることと，一般に汎用プログラミング特有の構文指向な面が
強く出る（hook がどう定義されているか（signature-oriented）ではなくて
hook をどう呼び出したか (syntax-oriented) に意味が左右されやすい）
という非常に大きな欠点を抱えるのも確かです．

644:デフォルトの名無しさん
06/05/25 02:47:08
>>637
より踏み込んだ議論として，そもそも hook の所有権・所在の
あり方に関する議論もあります．

特殊化に基づく hook の提供の場合，特定の名前空間に hook の所在が
固定されますが，それはそもそも正しいのか？
全く関係の無いサードパティが提供するヘッダとプライマリテンプレートに依存し，
その名前空間を開けて hook を提供しなければならなくなる状況も想定され，
それは本当に正しいのか？という疑問です．
そういう意味では ADL による hook があらゆる名前空間を
潜在的にぶち破る特性を逆手にとって，
「大域の ADL hook 用名前空間（global ADL namespace）に hook をおく」と
考えることも， hook の所在の中立性という観点からは
あるいは悪くないともいえます．

少なくとも「ライブラリ設計の欠点とその補完としての ADL」という観点は
少し視野が狭すぎるような気がします．

645:デフォルトの名無しさん
06/05/25 03:00:06
>>642
operator+ には特殊化するべきプライマリテンプレートがそもそもないです．
また，関数テンプレートの部分特殊化が現行規格に存在しないために，
一般にクラステンプレートに対して関数テンプレートを特殊化することができない，
という事情もあります．クラステンプレートの静的メンバ関数を
わざわざ持ち出すのは，関数テンプレートの部分特殊化の
エミュレーションのためだと思ってもらえれば良いかと思います．

646:デフォルトの名無しさん
06/05/25 05:56:24
>>643-644
> ADL による hook は loose match で済む，
こいつの解決策だけど、
案1: オーバーロードを追加するとき、新しい名前を導入したとみなさないで
部分特殊化と同様に扱えるような構文を導入する
lazyoverload operator+;
namespace std {
　　 ...
　　 namespace hooks {
　　　　 lazyoverload swap;

　　　　 template <class T, class Alloc> void
　　　　 swap(std::vector<T, Alloc> &a1, std::vector<T, Alloc> &a2)
　　　　 { a1.swap(a2); }
　　 }
}
template <class T> std::complex<T>
operator+(const std::complex<T> &a1, const std::complex<T> &a2)
{ ... }
コンパイラから見ればKoenig lookupとほとんど同じ機能だから、
実装は不可能ではないはず。

647:デフォルトの名無しさん
06/05/25 06:09:37
案2: typeofなどの機能を導入してオーバーロード解決の機構を
テンプレートから活用できるようにする
template <class U>
struct plus_traits<std::complex<int>, U> {
　　 static std::complex<int>
　　 plus(const std::complex<int> &a1, int a2)
　　 { ... }
　　 static std::complex<double>
　　 plus(const std::complex<int> &a1, double a2)
　　 { ... }

　　 typedef typeof(plus(const std::complex<int> &, U)) result_type;
};
実現性がどの程度なのかは分からんけど、可能ならテンプレートの力はかなり増す。

648:デフォルトの名無しさん
06/05/25 13:11:41
>>646
>>643さんが指摘されてる、クラステンプレートの部分特殊化による手法の問題は、
class Aに対してstd::hooks::???_traits<A>を実装したとして、
その後AのサブクラスであるB,C,...Zを作成した際に
全く同じstd::hooks::???_traits<B>, ... std::hooks::???_traits<Z>を
実装しなければならないということだと思うのですが。
この点、ADLの場合は基底クラスを引数にとる関数一つで用は足ります。

派生クラスと基底クラスの関係は、
オーバーロード解決では考慮されますが（部分）特殊化の解決では考慮されません。

>>643のコードを見る限り、operator+(T,T)の部分特殊化として
operator(const complex<T>&, const complex<T>&)を定義しているようですが、
これでは、>>643で言及された問題は解決できません。

ただし、ADLがない世界を仮定して、更にlazyoverload云々を無視して
普通のオーバーロードだと考えれば、>>643の問題はないように思います。
これは、hook用名前空間を１ヶ所用意して、
特殊な動作は全部そこに書く/書かせるということと同じでしょう。
もちろん名前空間の内部が第三者によって手を加えられる（特殊化ではなく）という問題はありますが。

649:デフォルトの名無しさん
06/05/25 13:51:00
>>648
普通のオーバーロードだとこれが動かない。
template <class T>
std::complex<T> operator+(std::complex<T> a1, std::complex<T> a2);

namespace std {
　　 template <class T>
　　 struct plus : public std::binary_function<T, T, T> {
　　　　 T operator()(const T &a1, const T &a2) const
　　　　 { return a1 + a2; }
　　 };
}

template <class T>
std::valarray<T> operator+(std::valarray<T> a1, std::valarray<T> a2);

650:648
06/05/25 14:43:27
>>649
std::plus::operator()内のa1+a2のことを言っていると思いますが、
いまいちよくわからないので、推測しながら答えます。

まず、complexのoperator+が、
plus内部から解決されないことを問題にしているのであれば、
>ADLがない世界を仮定して、
ということです。
もう少し補足すると、ADLがない結果として、
std名前空間内にoperator+がないことも仮定しています。

また、valarrayのoperator+が最後に定義されていることから、
two phase lookupを問題にしているとも推測できますが、
それでも特に問題がないのではないでしょうか？

どこを問題にしてるかを明らかにしてもらえれば、
より有意義に議論できると思います。

651:648
06/05/25 14:55:55
よく考えてみたら、ADLがない場合には
two phase lookupの挙動が変わりそうな気がしてきましたが
そこまでは考えていませんでした。

652:デフォルトの名無しさん
06/05/25 16:19:50
>>650
plusからはcomplexのoperator+は見えるけどvalarrayのoperator+は見えない。
646で書いたlazyoverloadというのはoperator+を全部見てくれという意味。

653:デフォルトの名無しさん
06/05/25 17:56:54
>>652
一応確認しておきますが、通常のC++における>>649のコードの問題点は、
両方のoperator+がstd名前空間内にないことですよね？
>>649の"ような"コードでは、complexのoperator+もstd::plus::operator()からは呼ばれませんし、
（>>649のコード単体ではcomplexのoperator+は呼ばれますが、
　std::basic_string等のoperator+がstd名前空間内に定義されてしまうと呼ばれなくなる）
逆に、両方のoperator+がstd名前空間内にあれば、両方ともplusから呼ばれます。

で、本題に戻りますが、>>643で指摘された問題点と
lazyoverloadには何の関連があるのでしょうか？
今の段階では、
> ADL による hook は loose match で済む，
という部分を勘違いされているように思えます。

あと、
>lazyoverloadlazyoverloadというのはoperator+を全部見てくれという意味。
の全部というのは、名前空間を無視して全部ということでしょうか？

654:デフォルトの名無しさん
06/05/25 23:59:35
>>653
>>643の問題を普通のC++で解決するのが大変or不可能であることは認識している。
で、その解決策として部分特殊化でなくオーバーロードでhookを実現
できるようにする(>>646)か、メタプログラミング向けの機能を追加する(>>647)
ことを考えた。
> >lazyoverloadlazyoverloadというのはoperator+を全部見てくれという意味。
> の全部というのは、名前空間を無視して全部ということでしょうか？
lazyoverload宣言をした名前空間の中だけ。解決したいのは次の問題。
namespace nnn {
　　 int fff(int) { return 0; }
　　 template <class T> int good() { return fff(T()); }
　　 template <class T> int bad() { return nnn::fff(T()); }
　　 int fff(char) { return 1; }
}
と定義されているとき、nnn::good<char>()は1を返すけどnnn:bad<char>()は
0を返してしまう。テンプレートを定義した時点で見える関数だけでなく、
インスタンス化した時点で見える関数を全部候補にしてくれ、というのが
lazyoverloadの意味。

655:デフォルトの名無しさん
06/05/26 00:55:41
>>654
標準準拠のコンパイラでは、
そのコードでは、nnn::good<char>()も0を返すはずです。
というのは、point of instantiationの文脈で名前解決を行うためには、
unqualifiedな関数呼び出しで（これはOK）、かつADLを介する必要があります。
しかし、charにはassociated namespaceがないため、ADLが行われません。
その結果、point of definitionの文脈で名前解決が行われます。

というのを昔、>>643の中の人（多分）にどこかのスレッドで教えてもらった記憶があります。

ちなみに、>>643に対する一つの解決法として
現在、boost.rangeなどで使われているものがあります。
lazyoverloadによる結果と違うのは、
fundamental type用のフックが定義できるかどうかということでしょうか。

656:デフォルトの名無しさん
06/05/26 01:10:18
>>655
>現在、boost.rangeなどで使われているものがあります。
>lazyoverloadによる結果と違うのは、
>fundamental type用のフックが定義できるかどうかということでしょうか。

あと、フック関数の定義される場所が
１ヶ所の名前空間になるか(lazyoverload)
複数の名前空間にまたがるか(boost.range)ということでも違いますね。

657:デフォルトの名無しさん
06/05/26 01:38:15
>>655
> そのコードでは、nnn::good<char>()も0を返すはずです。
これですね。勉強になりました。
URLﾘﾝｸ(www.open-std.org)
> fundamental type用のフックが定義できるかどうかということでしょうか。
ADLが利用できて、operator以外であれば、フックにダミーの引数を入れて
無理矢理ADLをやらせる手がありますね。
namespace hooks {
　　 struct hack;
}
template <T> int really_good() { return fff(hooks::hack(), T()); }
struct hooks {
　　 int fff(hack, int) { return 0; }
　　 int fff(hack, char) { return 1; }
}
struct abc {
　　 struct A {};
　　 int fff(hooks::hack, A) { return 2; }
}

658:デフォルトの名無しさん
06/05/27 02:44:49
lazyoverload を持ち出している方の動機は一応理解できているつもりです．
ですが， lazyoverload という提案はあくまで今手に入る
言語の仕様ではないので，これに関する議論は少し避けさせてもらいます．
提案自体に対しても，特に後方互換性の点で色々あら捜しはできるかとも
思いますけれど，それも指摘したところであまり実になるとは思わないので，
もうちょっと一般的なことをつらつら書かせてもらいたいと思います．

hook をある名前空間に集約するべきか，あるいは
あらゆる名前空間（associated namespace）に散在させるべきかは
一般に非常に難しい問題だと思います．
例えば swap という hook を考えたとき（これは現行規格の文言では
ADL 経由で発見される hook であるとは明示されていませんが），
swap という操作は問題ドメインをほとんど限らない非常に一般的な操作・概念で，
1つの名前空間に集約する方向性はそれほど正しいとは思えない．
どちらかというと各ユーザ定義型の associated namespace においておくほうが
おそらく正しい． std 名前空間に集約するという方策もある意味中立性が高いので，
std 名前空間に swap という hook を集約してしまう考え方もあるかとは思いますが，
そうした場合，今度はそれまで考慮されてこなかった新しい hook が登場してきた
場合に，その hook をどこに集約するべきなのかという問題が常についてまわります．

659:デフォルトの名無しさん
06/05/27 02:45:30
もちろん ADL による hook でも問題はあります．
先の swap を ADL 経由の hook とする場合，あらゆる名前空間において
"swap" という名前の非メンバ関数の意味を潜在的に予約してしまいます，
これのため，あらゆるドメインで "swap" という名前に対する共通のコンセンサス
（つまり2つのオブジェクトの状態を交換するという操作の名前であるという共通認識）
が取れるという（楽観的な）前提が必要になります．
実際， swap に対する将来的な規格の方向性は現在のところこの立場のようですが，
一方でこの話を金融関連のドメインで仕事をしている方たちにしたところ，
「swap という言葉は金融関連のドメインではまったく違う意味で使われる
（ので swap という名前に共通のコンセンサスが取れるという認識は甘い）」
と異論がきてしまった，という話もあったようです．
swap という非常に一般的と思われる名前1つでこの状況ですから，
おそらくある名前を全ての名前空間で潜在的に予約してしまう ADL hook のあり方は
一般には非常に受け入れがたい．
現在， Boost.Range などで導入されている ADL hook の名前では，
この問題を避けるため，マクロの名前規則を髣髴とさせる
boost_ なんて prefix が付いています．
しかしこれでは ADL による hook の大きな利点であった
「hook の所在の中立性」をかなり殺してしまっています．
実際，この観点から名前を boost_begin じゃなくて range_begin にしたら？
という議論も見受けられます．

次ページ