■過去ログ置き場に戻る■ 1- 次250 最新50


[memo] "9999999999_00.html#R20" という感じで、URLの最後に "#RレスNo" を追加すると幸せになれます。

C++相談室 part47
1 名前:1 ◆u3CudPDzYA :2006/02/15(水) 00:44:55
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE(VC++など)などの使い方の質問はその開発環境のスレに
お願いします。

前スレ
C++相談室 part46
http://pc8.2ch.net/test/read.cgi/tech/1136690107/

2 名前:1 ◆u3CudPDzYA :2006/02/15(水) 00:45:25
1 http://mimizun.mine.nu:81/2chlog/tech/piza.2ch.net/tech/kako/980/980175292.html
2 http://pc.2ch.net/tech/kako/996/996640937.html
3 http://pc.2ch.net/tech/kako/1003/10038/1003832761.html
4 http://pc.2ch.net/tech/kako/1009/10090/1009071535.html
5 http://pc.2ch.net/tech/kako/1014/10142/1014217496.html
6 http://pc.2ch.net/tech/kako/1018/10184/1018454705.html
7 http://pc.2ch.net/tech/kako/1021/10217/1021787032.html
8 http://pc3.2ch.net/tech/kako/1025/10250/1025010364.html
9 http://pc3.2ch.net/tech/kako/1027/10273/1027347982.html
10 http://pc3.2ch.net/tech/kako/1029/10293/1029315669.html
11 http://pc3.2ch.net/tech/kako/1032/10323/1032345774.html
12 http://pc3.2ch.net/tech/kako/1035/10350/1035005882.html
13 http://pc3.2ch.net/tech/kako/1038/10380/1038031395.html
14 http://pc5.2ch.net/tech/kako/1041/10413/1041328679.html
15 http://pc5.2ch.net/tech/kako/1043/10436/1043605481.html

3 名前:1 ◆u3CudPDzYA :2006/02/15(水) 00:45:44
16 http://pc5.2ch.net/tech/kako/1045/10457/1045746245.html
17 http://pc5.2ch.net/tech/kako/1047/10475/1047560042.html
18 http://pc5.2ch.net/tech/kako/1050/10501/1050177746.html
19 http://pc5.2ch.net/tech/kako/1052/10526/1052625846.html
20 http://pc5.2ch.net/tech/kako/1055/10551/1055162298.html
21 http://pc5.2ch.net/tech/kako/1057/10575/1057580107.html
22 http://pc5.2ch.net/tech/kako/1060/10603/1060361082.html
23 http://pc5.2ch.net/tech/kako/1062/10626/1062690663.html
24 http://pc5.2ch.net/tech/kako/1066/10665/1066546387.html
25 http://pc5.2ch.net/tech/kako/1067/10679/1067949669.html
26 http://pc5.2ch.net/test/read.cgi/tech/1070164402/ (迷子)
27 http://pc5.2ch.net/test/read.cgi/tech/1074454641/ (迷子)
28 http://pc5.2ch.net/test/read.cgi/tech/1077985164/
29 http://pc5.2ch.net/test/read.cgi/tech/1082047479/
30 http://pc5.2ch.net/test/read.cgi/tech/1084030770/

4 名前:1 ◆u3CudPDzYA :2006/02/15(水) 00:47:48
31 http://pc5.2ch.net/test/read.cgi/tech/1086185282/
32 http://pc5.2ch.net/test/read.cgi/tech/1088236078/
33 http://pc5.2ch.net/test/read.cgi/tech/1090180012/
34 http://pc5.2ch.net/test/read.cgi/tech/1092018643/
35 http://pc5.2ch.net/test/read.cgi/tech/1093958200/
36 http://pc5.2ch.net/test/read.cgi/tech/1096304546/
37 http://pc5.2ch.net/test/read.cgi/tech/1098543578/
38 http://pc5.2ch.net/test/read.cgi/tech/1101473340/
39 http://pc5.2ch.net/test/read.cgi/tech/1106466303/
39(実質40) http://pc8.2ch.net/test/read.cgi/tech/1106527792/
40(実質41) http://pc8.2ch.net/test/read.cgi/tech/1113408957/
41(実質42) http://pc8.2ch.net/test/read.cgi/tech/1120190961/
43 http://pc8.2ch.net/test/read.cgi/tech/1124113879/
44 http://pc8.2ch.net/test/read.cgi/tech/1128512737/
45 http://pc8.2ch.net/test/read.cgi/tech/1133007604/

5 名前:1 ◆u3CudPDzYA :2006/02/15(水) 00:48:15
■基本■
[C++ FAQ]
 http://www.parashift.com/c++-faq-lite/
 http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
  Cとその仕様を比較しながらの解説なので分かりやすい。
  ***** 質問の前に必ずこの二つに目を通してください *****

[禿 Stroustrup]
 http://www.research.att.com/~bs/
[C++ International Standard]
 http://www.kuzbass.ru/docs/isocpp/
 http://www.kuzbass.ru/docs/ansi_iso_iec_14882_1998.pdf
 http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=38110&ICS1=35&ICS2=60&ICS3=
[JTC1/SC22/WG21 - C++]
 http://www.open-std.org/jtc1/sc22/wg21

[C/C++ Users Journal]
 http://www.cuj.com/
[cppll (ML)]
 http://www.trickpalace.net/cppll/ (日本語)

6 名前:1 ◆u3CudPDzYA :2006/02/15(水) 00:48:31
■Books■
amazon.com C,C++関連書籍
 http://www.amazon.com/exec/obidos/tg/browse/-/3956/ref=br_bx_c_1_3/

The C++ Programming Language
 http://www.amazon.com/exec/obidos/ASIN/0201700735/
 http://www.amazon.co.jp/exec/obidos/ASIN/475611895X/ (翻訳)
C++ Primer (3rd Edition)
 http://www.amazon.com/exec/obidos/ASIN/0201824701/
 http://www.amazon.co.jp/exec/obidos/ASIN/4756140068/ (翻訳)
The C++ Standard Library
 http://www.amazon.com/exec/obidos/ASIN/0201379260/
 http://www.amazon.co.jp/exec/obidos/ASIN/4756137156/ (翻訳)
Effective C++
 http://www.amazon.com/exec/obidos/ASIN/0201924889/
 http://www.amazon.co.jp/exec/obidos/ASIN/4756118089/ (翻訳)
More Effective C++
 http://www.amazon.com/exec/obidos/ASIN/020163371X/
 http://www.amazon.co.jp/exec/obidos/ASIN/4756118534/ (翻訳)
Exceptional C++
 http://www.amazon.com/exec/obidos/ASIN/0201615622/
 http://www.amazon.co.jp/exec/obidos/ASIN/4894712709/ (翻訳)
More Exceptional C++
 http://www.amazon.com/exec/obidos/ASIN/020170434X/
Exceptional C++ Style
 http://www.amazon.com/exec/obidos/ASIN/0201760428/

7 名前:1 ◆u3CudPDzYA :2006/02/15(水) 00:48:51
C++ Coding Standards
http://www.amazon.co.jp/exec/obidos/ASIN/0321113586/
http://www.amazon.co.jp/exec/obidos/ASIN/4894716860/(翻訳)

■Books(Templateまわり)■
Effective STL
 http://www.amazon.com/exec/obidos/ASIN/0201749629/
 http://www.amazon.co.jp/exec/obidos/ASIN/4894714108/ (翻訳)
Modern C++ Design
 http://www.amazon.com/exec/obidos/ASIN/0201704315/
 http://www.amazon.co.jp/exec/obidos/ASIN/4894714353/ (翻訳)
C++ Templates
 http://www.amazon.com/exec/obidos/ASIN/0201734842/
C++ Template Metaprogramming
 http://www.amazon.com/exec/obidos/ASIN/0321227255/

8 名前:1 ◆u3CudPDzYA :2006/02/15(水) 00:49:10
■Libraries■
[Boost]
 Boost http://www.boost.org/
 (日本語) http://www.kmonos.net/alang/boost/
 (日本語) http://shinh.skr.jp/boost/
[STL]
 STLport http://www.stlport.org/
STLport http://stlport.sourceforge.net/
 SGI-STL http://www.sgi.com/tech/stl/
 STLFilt http://www.bdsoft.com/tools/stlfilt.html
 (日本語) http://www005.upp.so-net.ne.jp/episteme/html/stlprog/
 (日本語) http://www.wakhok.ac.jp/~sumi/stl/
[Loki]
 http://www.moderncppdesign.com/
 LokiPort-MSVC7 http://www.geocities.com/rani_sharoni/LokiPort.html
 LokiPort-MSVC6sp5 http://fara.cs.uni-potsdam.de/~kaufmann/?page=lokiport

9 名前:デフォルトの名無しさん :2006/02/15(水) 00:50:39
>>1


                       ↓↓↓↓↓↓↓↓↓


         テンプレその他      >>1-10付近参照         これ重要


                       ↑↑↑↑↑↑↑↑↑

10 名前:デフォルトの名無しさん :2006/02/15(水) 00:50:50
>>1


11 名前:1 ◆u3CudPDzYA :2006/02/15(水) 00:53:21
■関連スレ■
【初心者歓迎】C/C++室 Ver.24【環境依存OK】
http://pc8.2ch.net/test/read.cgi/tech/1131691023/
【C++】STL(Standard Template Library)相談室 4
http://pc8.2ch.net/test/read.cgi/tech/1130680264/
C/C++の宿題を片付けます 60代目
http://pc8.2ch.net/test/read.cgi/tech/1139053955/
C/C++でのWindowsPrograming議論スレ(質問お断り)
http://pc8.2ch.net/test/read.cgi/tech/1049790146/
managed C++ やろうぜ!! 002
http://pc8.2ch.net/test/read.cgi/tech/1139043535/
【.NET】 C++/CLI について語ろうぜ 【最適】
http://pc8.2ch.net/test/read.cgi/tech/1126450441/
ATL/WTL Part4
http://pc8.2ch.net/test/read.cgi/tech/1134388951/

12 名前:1 ◆u3CudPDzYA :2006/02/15(水) 00:54:02
STLつかうと一気に実行ファイルサイズが10倍に?!

環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない。

すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

C1010: プリコンパイル済みヘッダーの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの?

#include <stdafx.h>

後氏ね。

言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。

13 名前:デフォルトの名無しさん :2006/02/15(水) 00:56:15
>>12
テラワロス

14 名前:デフォルトの名無しさん :2006/02/15(水) 00:56:30
おつ>>1

15 名前:前スレ979 :2006/02/15(水) 00:57:17
>1
せっかくテンプレまとめてたのに、規制で立てられなかったんだ。
ゴメンよ。

>>5-8 にいくらか修正入れたんで、貼っとく。

>5
禿サイト URL 変更。
- http://www.research.att.com/~bs/
+ http://public.research.att.com/~bs/
[JTC1/SC22/WG21 - C++]の URL 末尾に / 追加
- http://www.open-std.org/jtc1/sc22/wg21
+ http://www.open-std.org/jtc1/sc22/wg21/
>6-7
"C++ Coding Standards" を 6 に移動。
>8
全体的に書き換えたんで次のレスに貼る。

16 名前:前スレ979 :2006/02/15(水) 01:00:09
>8
[STL] を [標準ライブラリ] に変更。
STLport は sourceforge に移動して2番手に降格。
標準ライブラリ実装とドキュメントの参照先として
GNU libstdc++ と Apache STDCXX を追加。
Loki のリンク先を sourceforge に変更。
MSVC7 への LokiPort は本家に取り込まれたので削除。

■Libraries■
[Boost]
 Boost http://www.boost.org/
 (日本語) http://www.kmonos.net/alang/boost/
 (日本語) http://shinh.skr.jp/boost/
[標準ライブラリ]
 SGI-STL http://www.sgi.com/tech/stl/
 STLport http://stlport.sourceforge.net/
 GNU libstdc++ http://gcc.gnu.org/libstdc++/
 Apache STDCXX http://incubator.apache.org/stdcxx/
 STLFilt http://www.bdsoft.com/tools/stlfilt.html
 (日本語) http://www005.upp.so-net.ne.jp/episteme/html/stlprog/
 (日本語) http://www.wakhok.ac.jp/~sumi/stl/
[Loki]
 http://sourceforge.net/projects/loki-lib/
 LokiPort-MSVC6sp5 http://fara.cs.uni-potsdam.de/~kaufmann/?page=lokiport

17 名前:前スレ979 :2006/02/15(水) 01:02:38
以上、次スレ立てるときに確認のうえ取り込んでもらえると嬉しい。
あ、 >9 も大事だと思うので次スレ立てる人は、何卒よろしく。

18 名前:デフォルトの名無しさん :2006/02/15(水) 01:02:54
趣味プログラミング用にdigital marsにstlportのstl突っ込んでるけど、他のも突っ込めるのかな・・・
スルーよろ

19 名前:デフォルトの名無しさん :2006/02/15(水) 01:04:48
http://pc8.2ch.net/test/read.cgi/tech/1136690107/996

>union {int *upi; char *upv;} u;
>
>int *pi;
>char *pv;
>
>pi = static_cast<int *>(pv); /* ok */
>pi = reinterpret_cast<int *&>(pv); /* ng */
>u.upv = pv;
>pi = u.upi; /* ng; 上と同じ */

ng とは何を指す? ( ill-formed でも undefined-behavior でもない)

助け船: reinterpret_cast の写像は implementation-behavior

20 名前:デフォルトの名無しさん :2006/02/15(水) 01:06:01
19 訂正
-implementation-behavior
+implementation-defined-behavior

21 名前:デフォルトの名無しさん :2006/02/15(水) 01:07:15
>>19
>ng とは何を指す? ( ill-formed でも undefined-behavior でもない)
もともとint *だったものをその変換でint *に戻したとき、元の値が復元されることが保障されていない、ということがいいたかった。

>助け船: reinterpret_cast の写像は implementation-behavior
さんくす。俺もさっき気づいた。

22 名前:デフォルトの名無しさん :2006/02/15(水) 01:08:50
>>19
なんで引用部分の void が char に置換されてんの?

23 名前:デフォルトの名無しさん :2006/02/15(水) 01:12:08
>>22
>>19 の頭がおかしいから

24 名前:デフォルトの名無しさん :2006/02/15(水) 01:13:08
>>21
implementation-defined-behavior は「保証される」ぞ

>>22
いかん、説明忘れた
void* とビット表現とアラインメントが /必ず/ 同じ char* で話した方が通じやすいと判断してそうした

25 名前:デフォルトの名無しさん :2006/02/15(水) 01:18:17
>24
>implementation-defined-behavior は「保証される」ぞ
ごめん。よく分からん。
もちろん実装によって保障されることはあるだろうけど。
「実装にかかわらず保障される」と言えばよかったか?

>void* とビット表現とアラインメントが /必ず/ 同じ char* で話した方が通じやすいと判断してそうした
それならintをcharに置換するべきじゃないか?

26 名前:デフォルトの名無しさん :2006/02/15(水) 01:20:21
>>25
> それならintをcharに置換するべきじゃないか?
それじゃもっと意味がわからん。
置換するべきじゃなかった、が正解。

27 名前:デフォルトの名無しさん :2006/02/15(水) 01:20:27
>>25
> それならintをcharに置換するべきじゃないか?
それだと no good にならんじゃん。

28 名前:デフォルトの名無しさん :2006/02/15(水) 01:22:09
>>25
文書化の義務がないのは undefined-behavior と unspecified-behavior

>それならintをcharに置換するべきじゃないか?

からかう気なら当然そうしていたけどね
フェアじゃないから

29 名前:デフォルトの名無しさん :2006/02/15(水) 01:24:01
話が見えん。結論らしきものがあるなら、誰か一旦まとめてくれ。

30 名前:デフォルトの名無しさん :2006/02/15(水) 01:27:01
void func(void* pv)
{
int* pi;

pi = (int*)pv;
pv = pi; // 元の値に必ず戻る

pi = (int*)pv;
pi++;
pv = pi; // 今の論点はこれ
}

31 名前:デフォルトの名無しさん :2006/02/15(水) 01:29:54
わりい、今日はもう寝る

32 名前:デフォルトの名無しさん :2006/02/15(水) 01:36:11
>>27
>それだと no good にならんじゃん。
なんで?「reinterpret_castの結果は実装依存であって、結果の表現は元の値の表現と同じであるかもしれないし、
そうでないかもしれない」と書いてあるけど。
unionの方は記述を見つけられなかった。

>文書化の義務がないのは undefined-behavior と unspecified-behavior
それは知ってる。だから処理系はint * -> void * -> int *の変換が元に戻るかどうかを
文書化しないといけない。
でもそれは、処理系によらずこの変換が元に戻るということを意味しない。

33 名前:デフォルトの名無しさん :2006/02/15(水) 01:42:40
>だから処理系はint * -> void * -> int *の変換が元に戻るかどうかを
>文書化しないといけない。

(-_-)zzzz ISO がすでに文書化していることを処理系の実装者が文書化する必要はないムニャムニャ

34 名前:デフォルトの名無しさん :2006/02/15(水) 01:56:43
>>33
おいおい、大丈夫か?

ここまでの流れ
>>19 : ngってなんだ
>>21 : その方法でvoid * -> int *の変換を行うと、もとの値に戻ることが保証されないってことだ。
>>24 : implementation-defined-behaviorは保証される。
>>25 : でも「実装にかかわらず保障される」とは言えない。
>>28 : implementation-defined-behaviorは文書化されなければいけない。
>>32 : そうだけど、それは無関係


だから、
>だから処理系はint * -> void * -> int *の変換が元に戻るかどうかを
>文書化しないといけない。
と言ったのは、>>19でngと書かれている変換についてであって、
static_castや暗黙の型変換についてではない。

35 名前:デフォルトの名無しさん :2006/02/15(水) 02:35:10
>>34
まとめ乙。でもよく分からん。
まだ結論に達していないってことで、議論している
命題を示してもらえるといいのだろうか?
「〜が〜であることは処理系依存か?」っていう感じで。

36 名前:デフォルトの名無しさん :2006/02/15(水) 04:16:47
>>16
boost のところには cppll の翻訳されたヤツも入れたほうがよくね?

37 名前:デフォルトの名無しさん :2006/02/15(水) 16:20:54
・(reinterpret_castは)安全でないか、実装依存であるか、あるいは両方である。
・static_castと違ってreinterpret_castの結果は、元のタイプにキャストバックする以外の安全な使い方がない。
・reinterpret_castは低レベルの操作であり、通常は実装系依存の変換だけに使う。

(from D&E)


38 名前:デフォルトの名無しさん :2006/02/15(水) 16:42:09
a[10][10] の内容を b[10][10] に代入するにはどんな文書けばいいでしょう?

39 名前:デフォルトの名無しさん :2006/02/15(水) 16:53:57
>>38
型わからんので適当に
b[10][10]=a[10][10];

40 名前:デフォルトの名無しさん :2006/02/15(水) 16:58:37
>>39
型はintでつ
説明足りなかったみたいなので補足します。
aの0.0〜10.10までを丸ごとbに代入したいんですけどできますかね?

41 名前:デフォルトの名無しさん :2006/02/15(水) 17:02:50
memmove(b,a,sizeof(int)*10*10);か?

42 名前:デフォルトの名無しさん :2006/02/15(水) 17:14:46
出来ないなぁ・・・
やっぱり一つずつ入れてくしか無いのかな

43 名前:デフォルトの名無しさん :2006/02/15(水) 17:14:49 ?
memmove(b,a,sizeof(a))
のほうが安全かと。

44 名前:デフォルトの名無しさん :2006/02/15(水) 19:36:21
>>43
そういう風に書くときはdestinationのサイズでsizeofすべきじゃないのかい?


45 名前:デフォルトの名無しさん :2006/02/15(水) 19:55:58
>>44
いやどっちか一方にあわせるのが間違いなのではないかと

46 名前:デフォルトの名無しさん :2006/02/15(水) 20:02:26
>>32
>文書化しないといけない。

ISO/IEC14882 5.2.10 Reinterpret cast の 7 を一読されたい

つまり、いくら union の代わりに reinterpret_cast を使っても
結局 implementation-defined-behavior に依存するか unspecified-behavior に依存するかを
選択するのみであり、http://pc8.2ch.net/test/read.cgi/tech/1136690107/943-944 よりも
処理系依存についてアドバンテージのあるコードが書けるわけではなく、
よって http://pc8.2ch.net/test/read.cgi/tech/1136690107/952 の指導を具体化するコードは
前スレ〜このスレでは現在のところ示されていない

・・・と主張しているのだが、いかがだろうか

47 名前:デフォルトの名無しさん :2006/02/15(水) 20:04:12
>>44
(int)&a + sizeof b 番地が未実装の場合は?

48 名前:デフォルトの名無しさん :2006/02/15(水) 20:14:19 ?
>>44-45
aとbの大きさが違うかも知れないと仮定したら危険度はどっちも同じ。
どうしても気になるなら
if (sizeof(a) == sizeof(b)) {
 memmove(a, b, sizeof(a));
}
とでもすればよい。

49 名前:デフォルトの名無しさん :2006/02/15(水) 20:48:26
>>46
どうも議論がかみ合っていないと思ったが、やっと理解できた。

俺の主張は、あるint *の値をvoid *に暗黙に変換した後、
そこから元のint *の値を処理系に依存せずに復元するには、
unionやreinterpret_castではなくstatic_cast(またはCスタイルのキャスト)を
使わなければならない、というもの。

http://pc8.2ch.net/test/read.cgi/tech/1136690107/943
は(俺の主張では)処理系依存ではない。
http://pc8.2ch.net/test/read.cgi/tech/1136690107/944-945
は処理系依存。

50 名前:デフォルトの名無しさん :2006/02/15(水) 20:54:01
>>49
了解

51 名前:デフォルトの名無しさん :2006/02/16(木) 00:38:24
>>50
え? 49 じゃないけど、了解じゃねぇだろ。あんた >46 なんだよな?

「 void* vp の指すメモリ位置に int の 10 を書き込み、
 書き込んだ int 型オブジェクトに続くメモリ位置を指すように
  vp を更新する」
という処理を対象として。以下の3つの実装が提示されている。

1: ip = static_cast<int*>(vp); *ip = 10; vp = ip + 1;
2: union { void* vp; int* ip; } u; u.vp = vp; *u.ip++ = 10; vp = u.vp;
3: *reinterpret_cast<int*&>(vp)++ = 10;

ここで
1 は http://pc8.2ch.net/test/read.cgi/tech/1136690107/943
2 は http://pc8.2ch.net/test/read.cgi/tech/1136690107/944
3 は http://pc8.2ch.net/test/read.cgi/tech/1136690107/945
という対応になる。

さて、未定義でも処理系依存でも不定でも無い実装を「ポータブル」と呼び、
ポータブルを O ポータブルでないものを X として順に並べると、
>>46 は XXX
>>49 は OXX
と言っていると思う。

まだ「 1 はポータブルか?」という命題が残ってるんじゃね?
ちなみに俺はポータブルだと思う。

52 名前:デフォルトの名無しさん :2006/02/16(木) 00:52:32
>>51
+ 1
^^^
ISO/IEC14882 5.2.10 Reinterpret cast の 7 を一読されたい

53 名前:デフォルトの名無しさん :2006/02/16(木) 01:04:17
>>52
5.2.9 static cast の 10



54 名前:53 :2006/02/16(木) 01:06:35
そもそも 1 に関しては
reinterpret_cast が絡んでいないように思うのですが。

55 名前:デフォルトの名無しさん :2006/02/16(木) 01:18:24
きっと>>52の持っているC++コンパイラにおける、static_castの実装は、次のようになっているんだ!


template <typename T, typename P>
T static_cast(P p){ return reinterpret_cast<T>(p) ; }

56 名前:デフォルトの名無しさん :2006/02/16(木) 02:12:43
#define CAST_DEFINITION(NAME)\
template <typename T, typename P>\
inline T NAME##_cast(P p) { return (T)(p); }

CAST_DEFINITION(static)
CAST_DEFINITION(reinterpret)
CAST_DEFINITION(const)
CAST_DEFINITION(dynamic)

#undef CAST_DEFINITION

57 名前:デフォルトの名無しさん :2006/02/16(木) 02:32:25
>>56
何のつもりか知りませんが、コンパイルできませんよ。
コンパイルできても意味無さそうだし。

58 名前:デフォルトの名無しさん :2006/02/16(木) 03:23:58
ネタ
マジ

59 名前:デフォルトの名無しさん :2006/02/16(木) 04:03:37
ネタのつもりだったのか?笑いどころがサッパリ分からん。

60 名前:デフォルトの名無しさん :2006/02/16(木) 05:01:27
http://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/jpdndeepc/htm/deep04202000.asp
> グローバル スコープを持ち、_ で始まる名前
が、予約されているとあるんですが、
ここで言うグローバルスコープとは
ネームスペース内のグローバル変数も入りますか?

61 名前:デフォルトの名無しさん :2006/02/16(木) 05:05:36
>>60
入ろうが入るまいが関係ないと思うんだが?

62 名前:デフォルトの名無しさん :2006/02/16(木) 05:29:06
>>60
入らない。

63 名前:60 :2006/02/16(木) 05:29:13
>>61
えっと、つまり、
namespace hoge{
int _fuga;
}
とかしてもOK?ってことです。

64 名前:60 :2006/02/16(木) 05:32:28
>>62
おっ、よかったー
感謝!

65 名前:デフォルトの名無しさん :2006/02/16(木) 05:33:23
>>63
その通り。17.4.3.1.2の1

66 名前:デフォルトの名無しさん :2006/02/16(木) 05:33:46
で、まさかそれをやろうとしてるんじゃあないだろうな

67 名前:デフォルトの名無しさん :2006/02/16(木) 05:37:43
めんどっちいので _ は後ろに付けろ。

68 名前:デフォルトの名無しさん :2006/02/16(木) 05:42:48
それはprivateクラスメンバでやってる香具師が多いから混乱の元

69 名前:60 :2006/02/16(木) 05:55:53
やろうとしてるというかもうやってたりw
テンプレートクラスで参照される static const な感じにしたいデータの配列があるんですが
テンプレート引数に関わらず固定なのでクラス外に出しちゃえばうまくいくかなと思い出したのですが
インタフェースとしての変数じゃないよという意味をこめて _ が付いてます。

70 名前:デフォルトの名無しさん :2006/02/16(木) 06:08:14
んー、でもね、
処理系によっては、_で始まるシンボルを#defineしてたりするから
使わないほうが良いと思うよ。
偶然同じ名前だったときに、エラーが意味不明になるし。

ctype.hとか覗いてみそ。

71 名前:デフォルトの名無しさん :2006/02/16(木) 07:53:09
boostだと外に見せたくないものはboost::detailの中に押し込んでいるな。

72 名前:デフォルトの名無しさん :2006/02/16(木) 09:48:21
gcc 3.4.2のctype.hは、規格上実装者予約とされているもの以外#defineしてないようだ。

_で始まる名前は規格で全予約にせず、わざわざ一部だけを予約するよう明記してあるので
私はクラスメンバーにだけ使用している。
コーディング規約で禁止されていない限り、堂々と使用していいと思う。
名前の付け方は規格・規約違反をせず、かつ一貫していることが重要。

73 名前:デフォルトの名無しさん :2006/02/16(木) 16:00:27
俺は Hidden とかいう名前空間使ってるな。

74 名前:デフォルトの名無しさん :2006/02/16(木) 16:25:37
既存の変数に別名を付けたいときってどうすればいいですか?
例えば、格子点を表すために
typedef std::pair<int,int> point;
としたとき、point::first を point::x の名前でアクセスしたいんですが、
どうすればいいんでしょう?

それなりに大きなプログラムならラッパーを書く気になるんですが、
数百行くらいの小さなプログラムでそれをやるのもなんだかなあという気がして。


75 名前:デフォルトの名無しさん :2006/02/16(木) 16:31:22
#define x first

76 名前:デフォルトの名無しさん :2006/02/16(木) 16:33:41
#define x first
とか
int std::pair<int, int>::*const x = &std::pair<int, int>::first;
とか。

77 名前:デフォルトの名無しさん :2006/02/16(木) 16:35:04
何故pairにpointと言う名前をつけたいのか判らん。
座標を扱いたいならstd::complex<int>の方がいい希ガス。

78 名前:デフォルトの名無しさん :2006/02/16(木) 17:10:24
というかそもそも無理に標準のテンプレート使わんでもいいだろ。

79 名前:デフォルトの名無しさん :2006/02/16(木) 17:10:30
>>74
std::pairを使うのが悪いと言ってみる。それくらい自作の構造体でいいだろ。

80 名前:デフォルトの名無しさん :2006/02/16(木) 17:21:15
>>60,63,69
おいまてまて、確かに困るのは自分だけかもしれんが
グローバルネームスペースに予約されてるってことは
>>63とやるといつ_fugaが衝突起こしても知りませんよ?
って意味だぞ?
using namespace hoge;を一切やらないならいいかも
しらんが、まあ無難にいくなら使わない方が良い

81 名前:デフォルトの名無しさん :2006/02/16(木) 17:29:01
>>80
衝突を起こしたら修飾すればいいだろ。そのための名前空間だ。

というか、言語の話とスタイルの話は分けて考えたほうが良くないか?

82 名前:74 :2006/02/16(木) 17:38:57
>>75-76 #define x first
いまはこれでお茶を濁してるんですが、これだと std::pair<int,int> に関係ない部分にある
int x, first; というコードも通らなくなるので、他の方法が無いものかと思って質問しました。

>>77-79
typedef std::pair<int,int> point; としたのはあくまで例です。
不適切でしたら適当なものを想定してください。

>>76 int std::pair<int,int>::*const x = &std::pair<int,int>::first;
すみません、これの使い方がよくわかりません。教えていただけないでしょうか?


他になんかないでしょうか?

83 名前:デフォルトの名無しさん :2006/02/16(木) 17:43:50
突然失礼します.

C++ の例外処理の「スタックの巻き戻し」という項目について,
具体的にコンパイラがやっていることがつかめません.
教科書的には...
「“スタックを上にたどって”例外ハンドラを探す処理」
と書いてあるのですが, その「スタックを上にたどって」という部分が
いまいちつかめません.

(つづく)


84 名前:83 :2006/02/16(木) 17:52:56
スタックを上にたどるというのがは,
return 文に似ているということまでは解るのですが,
例外処理機構は, どうやって該当する例外ハンドラを見つけ出しているのか...
例外処理は手間のかかる処理だとよく言われているのと,
どのように関連しているのか...
が, 私の中で特に謎めいております.


85 名前:デフォルトの名無しさん :2006/02/16(木) 17:55:50
>>82
>>>76 int std::pair<int,int>::*const x = &std::pair<int,int>::first;
>すみません、これの使い方がよくわかりません。教えていただけないでしょうか?
それを定義しておいて、
point pt;
pt.*x = 5;
などと使う。

86 名前:デフォルトの名無しさん :2006/02/16(木) 18:25:21
やっぱ座標取り扱いクラスを自作するのが一番じゃね?

87 名前:デフォルトの名無しさん :2006/02/16(木) 18:27:59
>>84
適当なデバッグ環境が使えるなら、コールツリーを見たことがあると思う。
VisualStudioなら「呼び出し履歴」かな。
それを辿るのと(ほぼ)同じことをやっているんでないかな。
どうしても気になるなら、適当な関数に入ったところでスタックをダンプしてみればいい。
プログラムの配置されたアドレスが順に入っているのが見えるはずだ。

つーか、アセンブラ出力を読むのが一番か。

88 名前:75 :2006/02/16(木) 18:55:11
>>>75-76 #define x first
>いまはこれでお茶を濁してるんですが

冗談で書いてたのに、本当に使ってるとはワラタ

89 名前:83 :2006/02/16(木) 19:29:58
>コールツリーをたどるのとほぼ同じことをやっているんでないか
てことは, やっぱり BCC 5.5.2 が吐く
call @__InitExceptBlockLDTC
ていうのは,関数の呼出しごとに, どこかに状態情報を記録してると言うわけですか.
# 関数の入り口でいつも呼ばれてるのね.
そして...
push 0
push 0
push 0
push 0
push 0
push 0
lea eax,dword ptr [ebp-52]
push eax
push offset @@$xt$14MyString@Error
call @_ThrowExceptionLDTC$qpvt1t1t1uiuiuipuct1
add esp,36

これでスローと. orz

90 名前:デフォルトの名無しさん :2006/02/16(木) 19:30:56
>>53
>>52 で示すべきだった条項は確かにそれで、この点の誤りは認める
そのうえで >>30 を一読されたい

ところで規格を引用して議論しているときの「処理系依存」という用語は曖昧なので
 ・不適格
 ・処理系定義
 ・処理系限界
 ・文化圏固有
 ・未定義
 ・未規定
 ・拡張
の、どれを指しているのかをはっきり示していただきたい

>>55
そのサンプルにはクラス型でない T へのポインタに対する
static_cast<void*>(T*) と reinterpret_cast<void*>(T*) の相違および
static_cast<T*>(void*) と reinterpret_cast<T*>(void*) の相違のうちの
どれを主張する意図があったのかを拝聴できれば幸いである
現状、あなたの意図は伝わっていない

91 名前:デフォルトの名無しさん :2006/02/16(木) 19:31:21
>>86
御意

92 名前:デフォルトの名無しさん :2006/02/16(木) 20:07:43
>>90

>>53じゃないけど、>>30が何を論点だと主張してるのかが分からん。

>の、どれを指しているのかをはっきり示していただきたい
少なくとも俺は、そのうち「不適格」「拡張」以外の何れか一つを満たすものを「処理系依存」と呼んでいた。
「不適格」ってill-formednessのことだよな。
「拡張」という用語は知らないのでなんともいえない。

>現状、あなたの意図は伝わっていない
static_castについての議論にreinterpret_castの項を持ち出した>>52を単に茶化しているだけかと。

93 名前:デフォルトの名無しさん :2006/02/16(木) 22:08:29
>>92

>>30 の主張は、2つの型 T と U のいずれか一方が void で他方が void でないとき、
(1) 一旦 T* を U* にキャストした後で
(2) T* にキャストし直した
場合の動作が、翻訳処理系もしくは実行環境のいずれの特徴にも依存しないのは
(1) - (2) 間で値を変更していない場合に限るため、
http://pc8.2ch.net/test/read.cgi/tech/1136690107/934 の要求を「ポータブル」に満たす解はなく、
このことに限らず void* が必要となる処理の多くが本質的に処理系に依存するということだ

用語「拡張」については JIS X3014 1.4 処理系の適合の 8 を参照されたい

94 名前:デフォルトの名無しさん :2006/02/16(木) 22:28:38
>>93

>>30 のどの部分の動作が処理系依存なんですか?
最後に pv = pi を行っている部分ですか?

4.10-2 によると、void* への変換自体は動作が規定されていると思うのですが。

95 名前:デフォルトの名無しさん :2006/02/16(木) 22:35:34
>>94
その手前でpi++していることが問題。

96 名前:デフォルトの名無しさん :2006/02/16(木) 22:37:45
>>94
そう
あのコード片に書いた限りの用事なら void* を使う必要はない

97 名前:デフォルトの名無しさん :2006/02/16(木) 22:38:07
>>96
pi の型は int* なので、インクリメント自体は問題がないですよね。
その前の void* -> int* の結果が問題だということでしょうか?

98 名前:デフォルトの名無しさん :2006/02/16(木) 22:39:41
>>96
まあ、それはその通りなんですけど、
今問題にしているのは本当に処理系依存なのかどうかということなので・・。

99 名前:デフォルトの名無しさん :2006/02/16(木) 22:40:03
93 訂正
-翻訳処理系
+翻訳環境

100 名前:デフォルトの名無しさん :2006/02/16(木) 22:42:38
>>98
今問題にしているのは http://pc8.2ch.net/test/read.cgi/tech/1136690107/952 の「指導」の妥当性

101 名前:デフォルトの名無しさん :2006/02/16(木) 22:52:30
>>93
>>>30 の主張は、2つの型 T と U のいずれか一方が void で他方が void でないとき、
void *に対して有効なポータブルな操作は実質的にstatic_cast(とNULL判定)だけだから、
void *と非voidへのポインタを対等に扱ってもしょうがない。
つまり、次のような関数があったとき、
void *func(void *pv)
{
return (int *)pv + 1;
}
この関数のまともな使い方は、有効なint *を渡して、結果をint *にキャストして使うことだけだ。
この使い方は一般に次のように書ける。
int *a = /* something */;
void *b = (int *)func(a);
そして、
assert(b == a + 1);
このassertがポータブルに成立することを確かめてほしい。

>用語「拡張」については JIS X3014 1.4 処理系の適合の 8 を参照されたい
さんくす。

102 名前:101 :2006/02/16(木) 22:53:38
>void *b = (int *)func(a);
訂正
int *b = (int *)func(a);

103 名前:デフォルトの名無しさん :2006/02/16(木) 23:02:22
>>30 の例を少し変えてみた。

int i = 0;
int* pi1 = &i;

void* pv = pi1;

// ここから 30 の後半と同じような処理
int* pi2 = pv;
// pi1 と pi2 の値が同じになることは 5.2.9-10
// pi1 の値は正常な int* の値であるので、pi2 も同様
++pi2;
// pi2 の値は問題なくインクリメントされる
pv = pi2;

// ここで 30 終了

あとは、pv の使い方に依存するだろうけど、
pv を int* にキャストして使うのは問題ないよね。

何か見落としある?

104 名前:デフォルトの名無しさん :2006/02/16(木) 23:03:09
>>101
「このassertがポータブルに成立する」のは、
「この使い方は一般に次のように書ける」からに過ぎない

すでに >>96 で述べたように、>>101 のコード例には void* を使う必要性が全くない
void* を使う必要性のある例を示さないと、問題の核心をつかないまま
不毛なやり取りから脱却しえないと予言する

105 名前:デフォルトの名無しさん :2006/02/16(木) 23:10:44
>>104
今この場にいる人は、
純粋に標準を見ながらポータブルかそうじゃないかを吟味してる人と、
>>104>>100 のように必要性、妥当性を絡めている人がいると思う。

で、大体前者の人は、後者の言う必要性等をどうでもいいと思ってる(多分)。
だから話がかみ合わないんじゃないかと思うのですが。

あと、どうしても void* が必要になる場合として
operator new 関連があるのではないでしょうか。

106 名前:デフォルトの名無しさん :2006/02/16(木) 23:13:46
>>104
>「この使い方は一般に次のように書ける」からに過ぎない
「過ぎない」って…
俺が言った「一般に」は「必ず」という意味だが。

>すでに >>96 で述べたように、>>101 のコード例には void* を使う必要性が全くない
そんなことはない。
前すれでも指摘したが、>>101のfuncをコールバックとして渡すことを考えてみてくれ。
逆に言うと、ある種のコールバック(templateと組み合わされて静的に解決されるものを含む)以外に
void *をポータブルに使える(かつ、void *を使う必要がある)例を俺は知らない。

107 名前:デフォルトの名無しさん :2006/02/16(木) 23:17:31
>>106
>前すれでも指摘したが、>>101のfuncをコールバックとして渡すことを考えてみてくれ。

それを考えるのは主張者であるあなた自身の領分であって、
こちらは具体例を示して頂かないとあなたが何を主張しているのかは決定できない

108 名前:106 :2006/02/16(木) 23:18:37
確かにoperator newなんかのからみでvoid *が要るね。それも追加。
でも、その場合も同じことかと。
void *a = operator new(100);
void *b = (int *)a + 1;
のとき、
assert((int *)b == (int *)a + 1);

109 名前:デフォルトの名無しさん :2006/02/16(木) 23:23:23
>>108
void *b = (int *)a + 1;
/* この間に複数の型の sizeof やバウンダリに依存する処理がない */
assert((int *)b == (int *)a + 1);

同じもの同士をいくら比べても例になっていない

110 名前:デフォルトの名無しさん :2006/02/16(木) 23:32:30
>>107
了解。forループを一般化するgeneric_forを考えよう。
この関数は、void *の初期状態とbool (*)(void *)の継続判定関数とvoid *(*)(void *)の状態更新関数と
void (*)(void *)のループ本体を取って、void *型のループ変数を使ったforループをエミュレートする。
void generic_for(void *init, bool (*pred)(void *), void *(*update)(void *), void (*body)(void *))
{
for(void *data = init; pred(data); data = update(data)) body(data);
}

generic_forを使って、intの配列の各要素(0が終端)を表示する関数printを書くことができる。
bool print_pred(void *pv) { return *(int *)pv; }
void print_body(void *pv) { std::cout << *(int *)pv << ' '; }
void print(int *a)
{
generic_for(a, print_pred, func, print_body); /* funcは>>101のもの */
}
これが「void *が必要で、かつポータブル」な例になってると思うがどうだろう。
この例自身は相変わらず役に立たないけど、書き換えて意味のある例を作るのは難しくないはず。

111 名前:デフォルトの名無しさん :2006/02/16(木) 23:38:50
>>110
いろいろ問題あるだろうが
とりあえず良く頑張った







そろそろスレの流れ戻そうぜ

112 名前:デフォルトの名無しさん :2006/02/16(木) 23:46:02
いやこの流れこそ本来の相談室の意義。
議論は詰めていかないと。

113 名前:デフォルトの名無しさん :2006/02/16(木) 23:53:46
>>110
残念ながら、これも void* は必要ない
単一のメモリ領域上に int 以外の型が混在しない以上、
回避〜改善すべき処理系の特徴に依存する動作が存在しない

114 名前:デフォルトの名無しさん :2006/02/16(木) 23:54:18
えー、そうなのか・・・


てっきり水掛け論してるんだとおもったよ (´・ω・`)


いっぱい置いておきますね っ
(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・`)
(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・`)
(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・`)
(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・`)
(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・(´・ω・`)

115 名前:デフォルトの名無しさん :2006/02/17(金) 00:04:11
>>113
>残念ながら、これも void* は必要ない
>>110のgeneric_forは一種の「アルゴリズム・ライブラリ」のコードで、
print_pred, prent_body, print, funcがそのユーザのコードだと考えてくれ。
「アルゴリズム・ライブラリ」の作者は、ユーザがforループの状態変数として
どんな型(この場合はint *)の変数を望むか知らない。
「アルゴリズム・ライブラリ」をポータブルにしたいのなら、変数をvoid *で扱うしかない。
(テンプレートを使えば話は別だが、コードの膨張を押さえるために
テンプレートを使わずにvoid *を使うのは一つのテクニックだ)

>単一のメモリ領域上に int 以外の型が混在しない以上、
>回避〜改善すべき処理系の特徴に依存する動作が存在しない
単一の領域上に一つの型しか存在しなくても、void *を使う必要があることもある。
この例もそうだし、qsortもそうだ。

116 名前:デフォルトの名無しさん :2006/02/17(金) 00:05:43
ところで、対象計算機は何?対象となるCはどの標準?

117 名前:デフォルトの名無しさん :2006/02/17(金) 00:11:34
>>115
C の qsort はテンプレートがないからああなっただけ
テンプレートによる C++ のみからなるコードの膨張対策には継承やインラインを使う
(逆効果になりやすいので注意を要するが、それこそ処理系の特徴に依存する部分が大きい)

118 名前:デフォルトの名無しさん :2006/02/17(金) 00:13:53
>>104,107,113
「ポータブルかどうか」の話を済ませてから必要性について考えてくれないか?
前者の議題が核心に近づくたびに必要性の話題にすり変わってしまって
正直ウザイ。

119 名前:デフォルトの名無しさん :2006/02/17(金) 00:15:39
>>118
途中から参加した人に過去ログ全部読んでこいとまでは言いたくないが
そもそもの発端くらいは押さえてきて欲しい

だからこそ前スレでの発言へのリンクを意図的に多用している

120 名前:デフォルトの名無しさん :2006/02/17(金) 00:16:23
>>117
どう書くのが、「好ましい」かは、また別の話かと。
>テンプレートによる C++ のみからなるコードの膨張対策には継承やインラインを使う
Boostはtype erasureと称してvoid *を使っている。

121 名前:デフォルトの名無しさん :2006/02/17(金) 00:17:59
>>120
>>117 ですでに答えているので書くことがない

122 名前:デフォルトの名無しさん :2006/02/17(金) 00:22:21
ていうか、ポータビリティについて話したい人は、
必要性について言われても無視すればいいだけでは。

というわけで、ポータビリティについて。

http://pc8.2ch.net/test/read.cgi/tech/1136690107/934の問題は
>>103 のようにやればポータブルなのでは。
要するにはじめの vp の値が、正常な int* の値から変換されたものであれば特に問題なし。

123 名前:デフォルトの名無しさん :2006/02/17(金) 00:27:12
>>119
俺は http://pc8.2ch.net/test/read.cgi/tech/1136690107/952 だよ。
「 void* を使う必要性」や「 qsort の現在の有用性」なんかは興味無い。
個人的には議論の余地さえ感じない。

124 名前:デフォルトの名無しさん :2006/02/17(金) 00:28:33
>>122
void* を使うのをやめろと言っていいなら当然そうしていた
それができない理由に根本的な処理系依存がある ・・・と読んだが、違うだろうか

125 名前:デフォルトの名無しさん :2006/02/17(金) 00:39:59
>>124
何を言いたいのかよくわからないのですが、
前スレの 934 が void* を使わざるを得ない理由に
処理系依存があるということ?
それでも何が言いたいのかよくわからないので
もう少しわかりやすく書いてもらえませんか?

126 名前:デフォルトの名無しさん :2006/02/17(金) 00:41:40
>>124
じゃあ、お前の主張をまとめるとこれでいいか?

http://pc8.2ch.net/test/read.cgi/tech/1136690107/934 がvoid *を使っているのは根本的な処理系依存のためであろう。
したがって、これへの回答として提示されたどの方法を使ったとしても、結果として処理系依存は免れ得ない。

127 名前:デフォルトの名無しさん :2006/02/17(金) 00:46:08
>>125
int オブジェクトに対して int 以外の型のポインタでアクセスまたはその逆を行い
あるいは他言語とリンクする場合などが C++ ポインタから型を取り除く主な理由で
共用体の抱える問題と根は同じ

ここで共用体を持ち出す根拠は
http://pc8.2ch.net/test/read.cgi/tech/1136690107/944

128 名前:デフォルトの名無しさん :2006/02/17(金) 00:46:26
>>126
そのとおり

129 名前:デフォルトの名無しさん :2006/02/17(金) 00:57:28
>>128
それなら異論はない。

もつかれ。

130 名前:デフォルトの名無しさん :2006/02/17(金) 00:57:29
>>122
「正常な int* の値から変換されたものであれば」という
条件付けは無くても、ポータブルであると言えると思う。

void* vp = malloc(sizeof(int)*2); // int[2] を動的確保
int* ip = static_cast<int*>(storage); // 確保した配列の先頭を指すポインタを作成
vp = static_cast<int*>(vp) + 1; // void* から作成した int* に + 1 という演算を加えて void* に戻す。
assert(vp == (ip + 1)); // 常に成り立つ

この後、 short* sp = static_cast<short*>(vp) などとして sp を使用しても、
ip と同等に正当だと言えるだろう。
これがポータブルでないと言うのなら、このような malloc() による
オブジェクトの動的確保をすべてポータブルでないと言うことになると思う。

C/C++ プログラマが十分なサイズを持つメモリ領域を void* として取得し、
その領域に int なり int[2] なり short なり、好きな型のオブジェクトを配置することは
認められており、 malloc() の存在意義でもある。

131 名前:130 :2006/02/17(金) 00:58:31
ごめんよ。
- int* ip = static_cast<int*>(storage); // 確保した配列の先頭を指すポインタを作成
+ int* ip = static_cast<int*>(vp); // 確保した配列の先頭を指すポインタを作成

132 名前:デフォルトの名無しさん :2006/02/17(金) 01:02:12
>>130
sp++; をお忘れかな? それとも故意?

133 名前:デフォルトの名無しさん :2006/02/17(金) 01:03:19
一生懸命スレを消費しているところ悪いが、一つ疑問に思ったので答えて欲しい。
無論、知らなければ自分の無知ということで、何も書か無くて結構。
対象はANSI-Cでいいよ

ポインタ変数の実体とは何か?
ポインタ変数に"メモリ上における大きさ"は存在するか?

この2点、分かっている人がいたら、たとえ嘘でもいいから書きなぐってください

134 名前:デフォルトの名無しさん :2006/02/17(金) 01:06:39
>>127
static_cast よりも軽い型変換(boost::implicit_castレベル)しか
行っていないのに、共用体(より強力な型変換)を持ち出す根拠がわかりません。

> ここで共用体を持ち出す根拠は
> http://pc8.2ch.net/test/read.cgi/tech/1136690107/944

共用体の場合どうなるかということを言っているだけで
ここで共用体を持ち出す根拠には全くなっていません。

また、http://pc8.2ch.net/test/read.cgi/tech/1136690107/944
がポータブルか否かも議論の余地が残っているように思います。

>>132
インクリメントに関しては >>103 のコメント部分に反論をお願いします。

135 名前:デフォルトの名無しさん :2006/02/17(金) 01:07:01
>>133
> ポインタ変数の実体とは何か?
その答えはポインタで無い変数と同じ。

> ポインタ変数に"メモリ上における大きさ"は存在するか?
その答えはポインタで無い変数と同じ。

136 名前:デフォルトの名無しさん :2006/02/17(金) 01:07:02
>ポインタ変数の実体とは何か?
整数
>ポインタ変数に"メモリ上における大きさ"は存在するか?
存在する

137 名前:デフォルトの名無しさん :2006/02/17(金) 01:08:03
>>132
意味がわからん。
あんた、ずーっとそうだが、相手のエスパー能力に依存しすぎ。
自分以外が読んだときのことを考えて書いてくれ。

138 名前:デフォルトの名無しさん :2006/02/17(金) 01:08:36
( ;゚Д゚) 日本の将来に危機を感じた…

139 名前:デフォルトの名無しさん :2006/02/17(金) 01:11:25
>>138
現在に危機を感じてくれ。

140 名前:デフォルトの名無しさん :2006/02/17(金) 01:19:06
>>133
>対象はANSI-Cでいいよ

よくない
C スレへどうぞ

>>134
型情報を除去することの何が「軽い」のかが説明されていないので答えようがないが
とりわけ C++ に於いて型システムを騙すことは危険度の最も高い部類に属することであると主張する

void* vp = malloc(sizeof(int)*2); // int[2] を動的確保
int* ip = static_cast<int*>(storage); // 確保した配列の先頭を指すポインタを作成
vp = static_cast<int*>(vp) + 1; // void* から作成した int* に + 1 という演算を加えて void* に戻す。
assert(vp == (ip + 1)); // 常に成り立つ

/*この後、*/ short* sp = static_cast<short*>(vp); /* などとして sp を使用しても、 */
vp = static_cast<short*>(vp) + 2; // void* から作成した short* に + 2 という演算を加えて void* に戻す。
assert(vp == (sp + 2)); // 常に成り立つ
assert(vp == (ip + 1)); //ip と同等に正当だと言えるだろう。



141 名前:デフォルトの名無しさん :2006/02/17(金) 01:19:52
>>133

> ポインタ変数の実体とは何か?
アセンブラでもシコシコやってろ

> ポインタ変数に"メモリ上における大きさ"は存在するか?
アドレスを保存する必要があるとしればそりゃコンピュータに関係する罠
アドレスがオフセット位置で分かるってんなら、わざわざポインタにメモリ使って保存なんてしない
配列なんかそうだろ?

> 対象はANSI-Cでいいよ
ANSI-Cって実装まで含んでいたっけか

142 名前:デフォルトの名無しさん :2006/02/17(金) 01:30:07
サンプルが new でなく malloc という稀な例になる理由からして・・・

143 名前:デフォルトの名無しさん :2006/02/17(金) 01:31:28
>>142
…それは見なかったことにしてやろうぜ…

144 名前:デフォルトの名無しさん :2006/02/17(金) 01:33:00
>>140
後半のコードは sp + 2 が malloc() で確保したサイズを
超えたメモリ位置を指すことになるので不正と言えるだろう。
でもそれは void* についての議論とは何の関係も無いよ。

>>142-143
new だと void* が出てこないからサンプルにならないだろ。

あと >>137

145 名前:デフォルトの名無しさん :2006/02/17(金) 01:33:20
> ポインタ変数の実体とは何か?
入門書的にはメモリ上の記憶位置を示す値を格納する入れ物.

>ポインタ変数に"メモリ上における大きさ"は存在するか?
アドレス用の入れ物の大きさはホストマシンに依存する.
大きさというのを位置の差として考えると,
ptrdiff_t 型というので測れる.
C++ でも ptrdiff_t 型が存在するから, 言葉上, それで通用する.
私だけかもしれないけれど.


146 名前:デフォルトの名無しさん :2006/02/17(金) 01:35:38
>>144
>でもそれは void* についての議論とは何の関係も無いよ。

あなたが指摘したことが関係ないだけ

147 名前:デフォルトの名無しさん :2006/02/17(金) 01:36:30
146 続き

実はちょっとだけ関係あるが、あの重箱の隅を見事言い当てられるだろうか

148 名前:デフォルトの名無しさん :2006/02/17(金) 01:37:36
>後半のコードは sp + 2 が malloc() で確保したサイズを
>超えたメモリ位置を指すことになるので不正と言えるだろう。
番兵アドレスだから, 読んだり書いたりしなければオッケ.


149 名前:デフォルトの名無しさん :2006/02/17(金) 01:38:24
>>140
処理系依存の例は良くないと思う。

150 名前:デフォルトの名無しさん :2006/02/17(金) 01:38:46
>>148
ご名答

151 名前:デフォルトの名無しさん :2006/02/17(金) 01:39:21
>>140 の後半
それは、>>122 でいう
> 要するにはじめの vp の値が、正常な int* の値から変換されたものであれば
という前提に反している。
だから、正当かどうかはわからん。

僕の主張はこの部分のみです。

> void* vp = malloc(sizeof(int)*2); // int[2] を動的確保
> int* ip = static_cast<int*>(storage); // 確保した配列の先頭を指すポインタを作成
> vp = static_cast<int*>(vp) + 1; // void* から作成した int* に + 1 という演算を加えて void* に戻す。
> assert(vp == (ip + 1)); // 常に成り立つ


>>140 の前半
様々なキャストの中で一番危ない、reinterpret_cast の例を出されても・・・
ということだったのですが、忘れてください。


152 名前:デフォルトの名無しさん :2006/02/17(金) 01:40:33
まとめうpどこかにある?

153 名前:デフォルトの名無しさん :2006/02/17(金) 01:42:51
>>146
>>130 は「 >>51 の 1 はポータブルである」という命題が真であると言うための論拠だよ。
あんた結局この命題についてはどういう立場なのさ?

>>147,148,150
は?これが「ご名答」?
sizeof(int) == (sizeof(short) * 2) である場合に限るんじゃないの?

154 名前:デフォルトの名無しさん :2006/02/17(金) 01:42:57
>>151
その引用の範囲のみに限定すると void* を使うこと自体が異常
非常に悪いスタイルの strictly conforming program というだけ

155 名前:デフォルトの名無しさん :2006/02/17(金) 01:44:50
>>154
ポータビリティの議論がしたい人には無視されるだけ。

156 名前:デフォルトの名無しさん :2006/02/17(金) 01:47:00
一度も言語を実装したこと無い人のオナニーが展開されるだけ
これ以上の無駄は無い
どんどんスレを消化していってくれたまえ

157 名前:デフォルトの名無しさん :2006/02/17(金) 01:50:03
>>153
同じものをいくら比べても自明なだけで
このやりとりの中で問題になっていることに
何ら影響しない

「ご名答」は 148 氏のように瞬殺できる人には
説明がいらないと判断して端折っているもので
いわば将棋の投了図のようなもの

158 名前:デフォルトの名無しさん :2006/02/17(金) 02:02:48
>>157
うまく会話になってないな。

「同じもの」って何と何?
「自明」って、何が?
「このやりとり」って、どこを指してるの?

で、 >>148 は sizeof(int) == (sizeof(short) * 2) の場合に限るんじゃないの?
ポータビリティの話をしてるときにその前提は無いと思うんだけど。

159 名前:デフォルトの名無しさん :2006/02/17(金) 02:05:04
>>158
同じ変換経路を通ったもの同士が同じことを「ポータビリティの例だ!」と噛みつかれても・・・

160 名前:デフォルトの名無しさん :2006/02/17(金) 02:07:53
>>159
質問されたことには答えるのが会話の基本です。
あなたにはその基本が欠けている。

161 名前:デフォルトの名無しさん :2006/02/17(金) 02:10:03
>>160
ちゃんと答えています
期待した答えと違う事実を否定することこそ非難されるべき人格上の特徴だが
その方面を始めるなら即座に離脱する

162 名前:148 :2006/02/17(金) 02:10:09
> sizeof(int) == (sizeof(short) * 2) の場合に限るんじゃないの?
よく見てみるとそうでした. すみません.
にしても, キャストの嵐は見づらい;;


163 名前:デフォルトの名無しさん :2006/02/17(金) 02:10:11
最近は>>160の様に自己言及型の厨が湧きやすいです
皆さんくれぐれもご注意してください
m9(`・ω・´)9m そこのオマエだ そうそう

164 名前:148 :2006/02/17(金) 02:13:10
>ポータビリティの話をしてるときにその前提は無い
(亀レス)
たしかに.


165 名前:デフォルトの名無しさん :2006/02/17(金) 02:16:07
うは。「ご名答」ワロス

166 名前:デフォルトの名無しさん :2006/02/17(金) 02:20:10
超えたメモリ位置を指すことになるので不正と言えるだろう。
超えたメモリ位置を指すことになるので不正と言えるだろう。
超えたメモリ位置を指すことになるので不正と言えるだろう。

167 名前:デフォルトの名無しさん :2006/02/17(金) 02:20:41
ちなみに malloc はある境界要求を満たす

168 名前:デフォルトの名無しさん :2006/02/17(金) 02:24:01
寝る

169 名前:午後の紅茶 :2006/02/17(金) 02:25:39
他人のC++のソースコードのコンパイルができなくて困っています。
ソースコードにDirectX8.0のヘッダファイルが使われているのですが、
ヘッダファイルが入手できません。
DirectX8.0が使われているソースコードをコンパイルする方法がありましたら
教えてください。

170 名前:デフォルトの名無しさん :2006/02/17(金) 02:26:26
>>169
お前、SDKって知ってるか?

171 名前:午後の紅茶 :2006/02/17(金) 02:34:05
9.0のSDKは手に入れたのですが、8.0のSDKを入手できません。
d3d8.hやd3dx8.hが見つからないとエラーが出てしまいます。

172 名前:デフォルトの名無しさん :2006/02/17(金) 02:41:56
>>169-171
スレ違い。↓逝け。
【C++】 DirectX初心者質問スレ Part7 【C++】
http://pc8.2ch.net/test/read.cgi/tech/1132216611/

173 名前:デフォルトの名無しさん :2006/02/17(金) 02:45:43
結局さ、
http://pc8.2ch.net/test/read.cgi/tech/1136690107/952
にイチャモンつけてるのは一人だったの?
会話の難しい彼意外に居たら意見を述べて欲しいんだけど。

174 名前:デフォルトの名無しさん :2006/02/17(金) 03:12:11
ブラウザで自分の描いた絵と誰かの描いた絵を等価交換
好きな絵を描いて右下の送信&交換ボタン(Submit drawing)を押すだけ
国内 http://rakugake.ninja-x.jp/
海外 http://www.sketchswap.com/
Un Do、消しゴムは無し。交換した絵が手抜きだったとしてもヘバらないでいこう

175 名前:デフォルトの名無しさん :2006/02/17(金) 09:16:22
今までお金がないから、Effective C++とMoreをずっと学校の図書館から借りて読んでたんだけど、
金ができたんで手元に置いときたくなったら、第三版(の翻訳?)がでるせいかAmazonじゃもう買えないんですね。

どこか買える所しりませんかorz

176 名前:デフォルトの名無しさん :2006/02/17(金) 12:48:45
本を買う金が無いってどこまで困窮してんのよ

177 名前:デフォルトの名無しさん :2006/02/17(金) 14:10:57
勉強の為の本くらい親に買ってもらってもいいと思うんだ。
家が極貧とかだったらスマン。

178 名前:デフォルトの名無しさん :2006/02/17(金) 14:25:29
>>176-177
世の中にはそういう奴もいるよ。
俺も学生時代は貧乏だったから、お前らの書き込みにカチンときた。

179 名前:デフォルトの名無しさん :2006/02/17(金) 15:11:17
飲み食い遊びの費用と同じカテゴリで捉えるから
「買えない」って話になるんじゃないかと。
学費とかと同じカテゴリで考えて払えないならご愁傷様

180 名前:デフォルトの名無しさん :2006/02/17(金) 15:20:38
今は授業にもあるからわからんが、
コンピューター関連は親には完全に趣味と思われてたな

181 名前:デフォルトの名無しさん :2006/02/17(金) 15:56:12
まあ、専門書って高いしね。
貧乏でも月1冊ぐらいは買えると思うけど。

182 名前:デフォルトの名無しさん :2006/02/17(金) 15:59:34
void*については議論は収束したのかな。

必要性があるかどうかや、望ましいコード例かどうかは論点から除外した上で
適宜ISO/IEC 14882:1998等の仕様書を参照しながら
誰かまとめてもらえると嬉しいな。
できれば、int*ではなく、基本型・関数・POD型・クラス型・派生クラスのメンバ関数
などのポインタの場合で分けてもらえると神です。

183 名前:デフォルトの名無しさん :2006/02/17(金) 16:46:03
>>179
それでも買えないよ。毎月 8000 円に食費抑えてやっと生活できてたのに。
そういう人間だっているんだよ…。

184 名前:デフォルトの名無しさん :2006/02/17(金) 16:48:21
('A`) 古書もダメと来たもんだ

185 名前:デフォルトの名無しさん :2006/02/17(金) 16:57:19
        _,,:-ー''" ̄ ̄ ̄ `ヽ、
     ,r'"           `ヽ.
 __,,::r'7" ::.              ヽ_
 ゙l  |  ::              ゙) 7
  | ヽ`l ::              /ノ )
 .| ヾミ,l _;;-==ェ;、   ,,,,,,,,,,,,,,,_ ヒ-彡|
  〉"l,_l "-ー:ェェヮ;::)  f';;_-ェェ-ニ ゙レr-{   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  | ヽ"::::''   ̄´.::;i,  i `'' ̄    r';' }   | 8000円は喰い杉
 . ゙N l ::.  ....:;イ;:'  l 、     ,l,フ ノ   | 2000円で食いつなぐ
 . |_i"ヽ;:...:::/ ゙'''=-='''´`ヽ.  /i l"  < のが昔のカメラ小僧なんだよな今のデブヲタは昔の
   .| ::゙l  ::´~===' '===''` ,il" .|'".    | カメラ小僧を知らないから困る
    .{  ::| 、 :: `::=====::" , il   |     \________
   /ト、 :|. ゙l;:        ,i' ,l' ノト、
 / .| \ゝ、゙l;:      ,,/;;,ノ;r'" :| \
'"   |   `''-、`'ー--─'";;-'''"   ,|   \_

186 名前:デフォルトの名無しさん :2006/02/17(金) 17:12:00
>>183
俺も学生のころとかは貧乏人だったんで技術書が買えんかった。
でも、当時はコンピュータ関係の書籍の絶対量も少なかったし
学校の図書室でコンピュータ関係の本を入荷希望したら
かなり高い確率で買ってもらえたし、他に借りるヤツが
いなかったから連続で借り続けても苦情が来なかったし
ほぼ独占状態だったなぁ。
・・・同じ手が使えるかもしれんし、駄目もとで図書室行ってみ?

187 名前:デフォルトの名無しさん :2006/02/17(金) 17:34:58
classの継承する必要性がよくわからないんですが、
ただ同じコードを書く手間が減るだけ?

188 名前:デフォルトの名無しさん :2006/02/17(金) 17:45:24
>>187
インタフェイス((純粋)仮想関数とか入ってるクラス)の実装は名前と意味を示すことが出来る
クラスの継承は名前と意味と機能を引き継ぐことが出来る
もっと言えば、継承は一つの識別子の様に働く(あるclassを継承している⇒あるclassの様に扱える、他)

189 名前:デフォルトの名無しさん :2006/02/17(金) 17:45:47
>>187
いろんな理由があるけど、せめて
「ただ同じコードを書く手間が減る」

「同じコードを同じように修正する手間が減る」
ぐらいは連想してくれ。

190 名前:デフォルトの名無しさん :2006/02/17(金) 20:22:09
相談です.

#include <stdio.h>
#include <string.h>
class A {
public:
char m_str[10];
};
class B {
public:
A m_data;
inline A getData( void ) const{ return m_data; }
};
int main(void)
{
B classB;
strncpy( classB.getData().m_str, (char*)"123456789", 10 );
printf("%s\n", classB.getData().m_str);
return 0;
}

以上のコードで詰まってるんです.
どこが悪いのかわからないのですが教えていただけないでしょうか.

191 名前:デフォルトの名無しさん :2006/02/17(金) 20:25:20 ?
>inline A getData( void ) const{ return m_data; }
>strncpy( classB.getData().m_str, (char*)"123456789", 10 );
>printf("%s\n", classB.getData().m_str);

ヒント: コピーコンストラクタ

192 名前:デフォルトの名無しさん :2006/02/17(金) 20:31:26
「何がどう悪いか」を書くようにしようね

193 名前:デフォルトの名無しさん :2006/02/17(金) 20:32:13
>>192 は >>190 へ

194 名前:190 :2006/02/17(金) 20:33:24
>>191
A getData( void ) const{ return m_data; }
を実行したときに, コピーコンストラクタが起動されるのに,
コンストラクタらしきものが無いからコピーされない,
という解釈でよろしいでしょうか??

195 名前:190 :2006/02/17(金) 20:40:13
言葉足らずでした. すみません.
症状は, 上記のコードを実行しても何も表示されないというものです.
A* getData( void ) const{ return &m_data; }
の方では上手くいくんだけどなぁ(ぶつぶつ).

196 名前:デフォルトの名無しさん :2006/02/17(金) 20:40:35 ?
>>194
まあこの件に関して言えば、コピーコンストラクタを定義するのも解法の一つ。
一般的には
>inline A getData( void ) const{ return m_data; }
ここを何とかするべきのような気がしないでもない。

197 名前:デフォルトの名無しさん :2006/02/17(金) 20:41:05 ?
>>195
ヒント: 参照

198 名前:190 :2006/02/17(金) 20:49:01
>197
inline A& getData( void ) const{ return m_data; }
とすると

エラー E2357 test.cpp 13: 参照は 'const A' で初期化されているが
'A' 型の左辺値が必要(関数 B::getData() const )

と. 今度はエラーの意味がわからなくて困ってます.

199 名前:デフォルトの名無しさん :2006/02/17(金) 20:56:45 ?
>>198
あーめんどくせえ。
ヒント: const

200 名前:デフォルトの名無しさん :2006/02/17(金) 21:01:13
>>194
A getData( void ) const{ return m_data; }
だと、m_dataをコピーした一時オブジェクトが返される。
その返された一時オブジェクトに変更を加えてもm_dataには反映されない。

201 名前:190 :2006/02/17(金) 21:02:12
動いたー♪

const 除ければ良かったのか.
…というかこんな浅い解釈でいいのかな.
問題がまだ残ってますが,
ともかくありがとうございました.


202 名前:190 :2006/02/17(金) 21:03:04
>>199

203 名前:デフォルトの名無しさん :2006/02/17(金) 21:04:06
ちょっとスレ違いなのかもしれないんだけど、
C言語ポインタ完全制覇という本に

C++は奥が深く、こんな言語をプロジェクトで採用するとプログラマーがついて来れない。
こんな言語の全貌を理解できる人がいるのか。とにかく厄介な言語である。

という感じのことが書いてあったんですが、C++を使って開発するプロジェクトはマイナーなのですか?
今のところクラスを一通り勉強しただけですが、そんなに難解な言語だという印象はないのですが・・・

204 名前:デフォルトの名無しさん :2006/02/17(金) 21:05:06 ?
>>201
若干不安だ・・・
A& const getData()
const A& getData()
A& getData() const
がそれぞれどういう違いがあるのか勉強しる。

205 名前:デフォルトの名無しさん :2006/02/17(金) 21:05:12
>>182
>>51 OXX で決まり。
これじゃ不満か?

206 名前:190 :2006/02/17(金) 21:08:39
>>200
そうだったのかー.
解説ありがとうございました.

>>204
ラジャー.


207 名前:デフォルトの名無しさん :2006/02/17(金) 21:09:36
>>203
C++の全てを理解する必要はないよ。

208 名前:デフォルトの名無しさん :2006/02/17(金) 21:12:19
>>205
不満だけど同じ説明を繰り返すのが面倒なんでやらない

209 名前:デフォルトの名無しさん :2006/02/17(金) 21:14:59
>>208 おまえはもういい。しゃべるな。今日は早めに寝ておけ。

210 名前:190 :2006/02/17(金) 21:15:49
>>200
何気に気になったので, 気づいた事をカキコ.
> A getData( void ) const{ return m_data; }
>だと、m_dataをコピーした一時オブジェクトが返される。
>その返された一時オブジェクトに変更を加えてもm_dataには反映されない。
この原則は, inline 指定した関数に対しても変わらないと...


211 名前:デフォルトの名無しさん :2006/02/17(金) 21:17:43
>>210
inline指定したからって挙動が変わったら大変だ罠。
ついでにつっこんでおくと、inlineをつける場所が違うし、
クラス宣言の中に直接定義を書いたメンバ関数は、自動的にインライン扱いされる。
(インライン化されるかどうかはコンパイラの判断だけど)

212 名前:デフォルトの名無しさん :2006/02/17(金) 21:22:32
クラス内部で
inline ってつける必要あるんですか?

213 名前:190 :2006/02/17(金) 21:23:09
>>211
わたしゃてっきり
inline A getData( void ) const{ return m_data; }
ってのは
m_data
みたく置き換わるのかと...

214 名前:190 :2006/02/17(金) 21:25:00
>>212
無いみたいです. (メモメモ)


215 名前:デフォルトの名無しさん :2006/02/17(金) 21:30:44 ?
>>213
inline修飾は#defineのようにプリプロセスとして動く物ではない。
「インライン化される」というのはコンパイルされたコードが出現のたびに埋め込まれる
(スタックを消費する呼び出し手順なしに実行される)ことが期待されるということ。

実際にそうなるかならんかは処理系依存だし、そうしなければならないわけでもないし
そうなったかどうかを通知する義務も無いのでinlineと付けたからって挙動が変わって
たら大変だ。

216 名前:デフォルトの名無しさん :2006/02/17(金) 21:41:06
>>203
確かに馬鹿でかくて所々無駄に難しい箇所が見られる言語だが
そんなんでビビってちゃ何も手につかないよ
何屋になっても OS やバスの仕様みたいに強烈複雑なのが出てくるのに
たかが C++ 程度でってのが正直なところ

また新しいのを憶えなきゃってときは確かにガクブルだけど
及び腰じゃ何も動かせない
腹くくって正面から向き合うだよ

>>209

>おまえはもういい。
はいはい

>しゃべるな。今日は早めに寝ておけ。
しゃべろうが寝ようが
あなたの指図は受けない

217 名前:デフォルトの名無しさん :2006/02/17(金) 21:43:13
('A`) 煽り煽られ共倒れ・・・か

218 名前:190 :2006/02/17(金) 21:47:49
>>215
納得いたしました.

inline 修飾子(?)の効用については,
一昔前の register 程度だと言うことですね.
そのうち inline も使われなくなるときが来るのだろうか.

わかりやすい説明ありがとうございました.

219 名前:デフォルトの名無しさん :2006/02/17(金) 21:50:44
>>205 ありがとう。
漏れがかつて書いたメモリプールのコードはポータブルでないと確定した(死

220 名前:デフォルトの名無しさん :2006/02/17(金) 21:54:39
>>219
なんか変
ポータブルではないからこそデフォルトの実装やサードパーティのライブラリがなくて
あなたが書くことになったんじゃないの?

221 名前:デフォルトの名無しさん :2006/02/17(金) 21:55:12
>>219
どんなコード?

222 名前:デフォルトの名無しさん :2006/02/17(金) 21:56:54
インライン展開の是非を強制できる指定ができたらいいと思うことはある。
あと、現状でも手動でインライン展開しやすくするよう実装をコピペして増やしていると
実にばからしいと思う。
処理系によっては、事実上強制する指定もできるが。

223 名前:デフォルトの名無しさん :2006/02/17(金) 22:27:53
>>222
C++ でも C でも、ある程度は実装レベルを想像しながら書いていけるのは
安心感があっていいけど、何か特定のシーケンスを強く期待する場合は
その部分はアセンブラで書いたほうがいいとも思う

あくまでトンデモなコードを吐かれないように気をつけて書くってだけで
それ以上の期待は俺はしてないけど、どうかな

224 名前:デフォルトの名無しさん :2006/02/17(金) 23:04:00
ゲーム開発用のMS製コンパイラは強制インライン展開キーワードがあるお

225 名前:デフォルトの名無しさん :2006/02/17(金) 23:24:56
gccも最適化オプションにforceinlineがあるしな

226 名前:190 :2006/02/17(金) 23:28:39
>>204
const A& getData( void ) const{ return m_data; }
とすると上手くいった. ということは,
const{ ... }
とすると, 戻り値が const 扱いになるってことだろうか.

inline キーワードをつい付けたくなるところといえば, Set, Get 関数.
それ以外の関数にはインライン展開して欲しくない.
てのは言いすぎか;;

>>255
__forceinline てのが, サクラエディタのコードで使われてたのは
それのことか...


227 名前:デフォルトの名無しさん :2006/02/17(金) 23:34:10
>>226
そのあたり(204)の話は、ググってもすぐ見つかるし、まともな本なら
調べればすぐわかるよ。

228 名前:190 :2006/02/17(金) 23:39:10
>>227
そーなのかー. 情報収集スキル分補充してきます.


229 名前:デフォルトの名無しさん :2006/02/17(金) 23:48:30
>>224-225

多くのコンパイラでなにがしかオプション指定があるのは知ってるけど
>>222 が言ってるのはそういうことじゃないだろ
最後の一行はもちろん読んでるよな

230 名前:デフォルトの名無しさん :2006/02/18(土) 00:07:52
>>226
メンバ関数の括弧の後のconstはメンバを書き換えないということから、
thisがconstなポインタとして扱われるという効果がある。

231 名前:190 :2006/02/18(土) 00:35:21
>>230
>thisがconstなポインタとして扱われる
納得いたしました.
const T *foo;
とするとコンパイラは,
*foo, foo->
という記述に対してエラーを出すということと併せて.

>>204 の最初の二つは,
ポインタ * の読み方に似てるからどうにか自力で解りそう.


232 名前:デフォルトの名無しさん :2006/02/18(土) 01:25:06
>>203
その本の著者が、
「そんなに難しい言語を解説しちゃう俺って天才w」
って読者に偉ぶってるだけ


233 名前:デフォルトの名無しさん :2006/02/18(土) 01:43:31
「それでもメジャーになるくらいのメリットがC言語にはある」
っていう意味だろとマジレス

234 名前:デフォルトの名無しさん :2006/02/18(土) 01:45:05
ぶっちゃけCマニア以外、コードを読めて、自分の思い通りのコード書ければどうってことない
それだけのこと

235 名前:デフォルトの名無しさん :2006/02/18(土) 01:48:13
effective C++は読むべき。
今読んでるけど、その辺のことも書いてあった。

236 名前:デフォルトの名無しさん :2006/02/18(土) 01:49:52
>>235
は、inlineキーワードについてです。

237 名前:デフォルトの名無しさん :2006/02/18(土) 01:58:34
inlineってデフォルトだと関数の実体が1KB以下ならインライン展開するんだっけ?
VCだけ?
それとも俺の勘違(ry

238 名前:デフォルトの名無しさん :2006/02/18(土) 02:04:41
>>237
規格では何も決まってない。

239 名前:デフォルトの名無しさん :2006/02/18(土) 02:32:01
inlineについてはefficient c++の方が詳しいと思うぞ

240 名前:190 :2006/02/18(土) 05:11:05
スレ違いを承知で, 恐れ入りながら申し上げます.

Effective C++ って,
『Accelerated C++』 + 『プログラミングC++第3版』
のペアを放っておいてでも読むべき!
といわれるほど内容が濃いのかなと,
半信半疑な私なのですが, 世間的にはどうなんでしょう.


241 名前:デフォルトの名無しさん :2006/02/18(土) 05:49:52
それら2冊は「C++でプログラムを組む方法」を学ぶための本だけど、
Effective C++は「C++でより良いプログラムを組む方法」を学ぶための本であり、
「C++そのもの」の基礎については既に読者が理解している前提で書かれている。

だから「まだ自分は言語の基礎からして怪しいな〜」と思うなら、
その「ペア」をまずこなすべきかと。まぁ俺なりの意見として。

242 名前:デフォルトの名無しさん :2006/02/18(土) 12:06:10
std::copyとmemcpyなんですが、皆さんはどういう基準で使い分けてますか?
それともstd::copyに統一してたりするんでしょうか?

243 名前:デフォルトの名無しさん :2006/02/18(土) 12:44:58
>>240
放っておいてなんて言わずに全部読め

244 名前:デフォルトの名無しさん :2006/02/18(土) 13:29:55
>>240
本読むの遅いか読む時間が無いと勘違いしてる人?
とりあえず流し読みでいいから全部目を通して、その後熟読するようにすると時間節約できるよ。

通勤通学の時間とかはあんまりおすすめじゃないけど、寝る前の1時間を読書だけに当てればその3つなら流し読みで
1週間かからないし。(全部理解するのでなくて何となくこんな事がこの辺りに書いてあったと覚える程度でいい)



245 名前:デフォルトの名無しさん :2006/02/18(土) 15:05:27
>>242
memcpy()などのレガシーな関数は、ポインタを生で扱わないといけないようなとき以外は封印している漏れガイル。

246 名前:デフォルトの名無しさん :2006/02/18(土) 15:09:34
>>242
迷ったらstd::copy。
std::memcpyは組み込み型やPODにしか使えない。

いいトコ取りする方法もある。
http://www.kmonos.net/alang/boost/classes/enable_if.html

247 名前:190 :2006/02/18(土) 16:46:49
>>244
たしかに本読むの遅い方です.

PG本を買うときに不安になることで,
持ってる本に書いてあることとか, 熟読すれば気づけることとか,
「使ってりゃわかるでしょ」的なこととかが
つらつらと書かれてある本なのかもというのがある.
# とはいえさすがに 「プログラミング作法」を買うときは即買いだった.
『時間ねぇー!』とかそういうんじゃなくて.


248 名前:デフォルトの名無しさん :2006/02/18(土) 19:51:30
このコードが、VC7.1で問題なく動くのですが、いいのでしょうか?

//Primary Class
template <typename T>
class C
{
  T value ;
public :
  C(T const &val) : value(val) {}
  void print(void) { std::cout << "Generic value : " << value << std::endl ; }
} ;


//C<int>::print()だけを特殊化、ただし、わざとtemplate<>をコメントアウト

//template <>
void C<int>::print() { std::cout << "Specialized value : " << value << std::endl ; }

main()
{
  C<int> c(100) ;
  c.print() ;//問題なし
}

C++ Templatesという本によると、
メンバの特殊化にも、template<>プレフィクスをつけなければならないと書かれているのですが。

249 名前:デフォルトの名無しさん :2006/02/18(土) 22:17:38
Hoge& foo = new Hoge;
のようにnewしたインスタンスを参照で受けることはできますか。


250 名前:デフォルトの名無しさん :2006/02/18(土) 22:49:19
>>249
俺のところではこういうことができた。
Hoge& foo = *new Hoge;
delete &foo;
だが、これがやっていいことなのかどうか分からない。


■過去ログ置き場に戻る■ 1- 次250 最新50
DAT2HTML 0.33f Converted.