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

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

446:r
04/10/30 08:20:36
>>444
offsetof

使った事無いけど。多分。

447:r
04/10/30 08:25:36
>>444
つーか

TEST_STRUCT srcData[] = ...;

for( int i = 0; i < ...; i++ )
　　　　dstArray.push_back( srcData[i] );

じゃなくて？

448:デフォルトの名無しさん
04/10/30 09:57:07
>>444
実体でなくポインタを維持すればいいなら、
std::vector<void *>dstArray;
dstArray.push_back(reinterpret_cast<void *>(&srcData.mInt));
dstArray.push_back(reinterpret_cast<void *>(&srcData.mLong));
dstArray.push_back(reinterpret_cast<void *>(srcData.mChr));
構造体のメンバの列挙は誰かがやらないといけないからねぇ。
static const unsigned sOffsets[] = {
offsetof(TEST_STRUCT, mInt),
offsetof(TEST_STRUCT, mLong),
offsetof(TEST_STRUCT, mChr),
};
for (unsigned i = 0; i < sizeof(sOffsets) / sizeof(*sOffsets); ++i) {
dstArray.push_back(reinterpret_cast<void *>(reinterpret_cast<char *>(&srcData) + sOffsets[i]));
}
これでもなんとかなるかな。

449:デフォルトの名無しさん
04/10/30 19:41:55
>>446
「offsetof」なんて初めて聞いた！
…と思ったらひょっとしてC++の言語仕様にはないものですよね？
ぐぐってみたらどうやら「.NET Framework」なのかな？

>>448
ふむふむ、ポインタを駆使すれば結構なことが出来そうですね。
しかしなんていうか難しいというかちょっぴり複雑に…。(^^;

基本的に私もメンバを一つ一つ指定することになんの抵抗も無かったんですが、
最近職場でBorlandC++Builderに慣れた同僚が、

「構造体のメンバって一つ一つ名前でアクセスしないといけないんですかねぇ？
　面倒くさいですねぇ」

…などと話していたので、興味を持った次第でつ。
これができるとどういうメリットがあるかという話ですが、
（C++Builderの話限定になってしまうのですが）
ＤＢの不特定なテーブルから、フィールド名を指定せずに
不特定の構造体のメンバにデータを突っ込めるため、
プログラムの汎用性が高まるということらしいです。

450:デフォルトの名無しさん
04/10/30 22:20:56
offsetofを知らないだけならともかく(それも問題だが)、C#って・・・
絞り込みも出来ない、googleのトップしか見ないで、２番目は無視する人かね

451:448
04/10/31 01:07:37
>>449
offsetofなんて、Cでもマクロで簡単に書ける代物なんだけど。
標準ヘッダを探してみることもできないのかな?

452:デフォルトの名無しさん
04/10/31 02:37:42
うわ～ん、そんなにいじめるなぁ～。ヽ(`Д´)ﾉ
簡単にできるというのがいいのだよ。
めんどっちいのはイヤ。

453:デフォルトの名無しさん
04/10/31 02:45:31
しかし、とりあえずoffsetofというマクロが
標準的に用意されてることを教えていただき、
ありがとうございますた。m(_ _ )m

454:r
04/10/31 17:05:43
クラスのメンバを、別々に、同じベクタに入れる意味がわからん

455:デフォルトの名無しさん
04/11/25 02:44:24
最近書き込みがないね。

456:デフォルトの名無しさん
04/11/25 04:01:13
重複スレだからな。

457:デフォルトの名無しさん
04/11/26 03:07:57
C言語とJavaとRuby使って，そこそこ書きました．
次はC++にチャレンジするかと，プログラミング言語C++を買ってきました．
難しいです．何書いてるのかわかりません．
俺の頭が悪いのが原因でしょうが，C++の難しさに挫けそうです

458:デフォルトの名無しさん
04/11/26 08:15:19
ヽ（冫、）ノｽﾞｺｰｯ
何処が難しいか言ってみて。
十分習得出来る知識あるように見えるけど…

459:デフォルトの名無しさん
04/11/26 10:26:54
>>458
>十分習得出来る知識あるように見えるけど…
んな事が >>457 読んで解るのか！ESPer でつか？

460:デフォルトの名無しさん
04/11/26 10:52:23
>>459
Yep

461:デフォルトの名無しさん
04/11/26 14:05:17
>>457
CからC++に移ったばかりの人
for (int i = 0; i < 10; i++) {
v[i] = 1;
}

C++を使い慣れてきた人
for (std::vector<int>::iterator it = v.begin(); it != v.end(); it++) {
*it = 1;
}

C++が「使える」と言えるレベルの人
std::fill(v.begin(), v.end(), 1);

これでやっと中級に入門です。先は長いです。くじけそうです。

462:デフォルトの名無しさん
04/11/26 14:07:40
C++のことがある程度わかってくると、++、--は前置にするもんです。

463:デフォルトの名無しさん
04/11/26 16:44:04
運置

464:デフォルトの名無しさん
04/11/26 21:17:08
>>462 どうして？

465:デフォルトの名無しさん
04/11/26 21:20:14
>>464
前置の方がコピーのコストがかからないから

466:デフォルトの名無しさん
04/11/26 21:27:04
>>465 どうして？

467:デフォルトの名無しさん
04/11/26 21:32:47
>>466
More Effective C++の項目6を嫁

468:デフォルトの名無しさん
04/11/26 21:36:34
>>467
読んでみた。ありがとう。
インライン展開されるような場合は別に気にしなくていいね。

469:デフォルトの名無しさん
04/11/26 22:23:28
>>461
それ見てC++の方がタイプ量多い割にたいしたこと出来ない。
Cの方が1000万倍マシと悟った。

470:デフォルトの名無しさん
04/11/26 22:24:18
>>469
それはちょっと勘違いだ。
C++ は C より便利だよ。

471:デフォルトの名無しさん
04/11/26 22:24:53
>>467
んじゃ、これから
Effective ++C
と書くことにしちくりマンボ

472:デフォルトの名無しさん
04/11/26 22:28:36
>>471
山田君、座布団一枚持ってっちゃって

473:デフォルトの名無しさん
04/11/26 22:32:14
>>468
テンプレートでの汎用プログラミングのために常に
前置にしておくと後々組み込み型をクラスにしたくなった
とき修正量が減る。

474:デフォルトの名無しさん
04/11/26 23:07:05
>>473
組み込み型かクラスかは別に関係ないような？

475:デフォルトの名無しさん
04/11/26 23:35:39
>>474
クラスだとテンポラリオブジェクトが生成されるよ。
インライン展開されてもね。

476:457
04/11/27 02:51:11
思ったよりレスが…ありがとうございます．

>>458
最初は俺も楽勝だろーとか思っていたのですが，何故か頭が受け付けません．

>>461
今の俺の書き方だと，モロ最初の書き方ですね…

477:デフォルトの名無しさん
04/11/27 03:07:44
>>461
C++を究めた人はアセンブリに戻る。

478:デフォルトの名無しさん
04/11/27 03:10:04
>>477
そういう内容のメガデモ作品があったな

479:デフォルトの名無しさん
04/11/27 06:47:22
>>461の二番目みたいに、全く抽象化されてもいないのに
無理やりイテレータ使う意義って、全くないように思えるんだが

480:デフォルトの名無しさん
04/11/27 09:02:51
インポラリ

481:デフォルトの名無しさん
04/11/27 09:22:04
>>457
> C++の難しさに挫けそうです
「プログラミング言語C++」の難しさに挫けそうなだけだろ。

482:デフォルトの名無しさん
04/11/27 09:34:42
>>479
そんなことはない。
少なくともコンテナを差し替えられる。

483:デフォルトの名無しさん
04/11/27 23:14:25
そんなこといったら、最初の書き方ならば
vectorを配列にさしかえれるという利点があるなｗ

484:デフォルトの名無しさん
04/11/27 23:16:08
>>483
vectorを配列に差し替えても、あまり嬉しくはないだろう。

485:デフォルトの名無しさん
04/11/27 23:37:44
速くなるやん

486:デフォルトの名無しさん
04/11/28 04:04:31
>>485
そういう用途なら、boost::arrayがあるから利点とはならない。

487:デフォルトの名無しさん
04/11/28 04:36:03
boost::rangeでcontainerとbuilt-in arrayが汎用に扱えるようにもなったしね

488:デフォルトの名無しさん
04/11/28 11:09:50
後からコンテナを差し替えやすいってのが利点。

489:デフォルトの名無しさん
04/11/28 17:27:41
コンテナの差し替えなんかするのか？ホントか？

テンプレート引数で型を受け取るときに、
どのコンテナでもOKなのは、確かに意義があるといえるが

前述の例はそういうわけでは全くないし、
正直、三つある例のどの書き方でも、優劣はないと思うが

490:デフォルトの名無しさん
04/11/28 20:57:16
前述の例だけみればたしかにどれでもいいレベルの話だけど、
意識の持ち方のことを言ってるんじゃないの？
できるだけSTLコンテナやSTLアルゴリズムを使おうという。

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用名前空間を１ヶ所用意して、
特殊な動作は全部そこに書く/書かせるということと同じでしょう。
もちろん名前空間の内部が第三者によって手を加えられる（特殊化ではなく）という問題はありますが。

次ページ