1001コメント336KB

C++相談室 part47

レス数が1000を超えています。これ以上書き込みはできません。

00011 ◆u3CudPDzYA

2006/02/15(水) 00:44:55

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE(VC++など)などの使い方の質問はその開発環境のスレに
お願いします。

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

00021 ◆u3CudPDzYA

2006/02/15(水) 00:45:25

00031 ◆u3CudPDzYA

2006/02/15(水) 00:45:44

00041 ◆u3CudPDzYA

2006/02/15(水) 00:47:48

00051 ◆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/ (日本語)

00061 ◆u3CudPDzYA

2006/02/15(水) 00:48:31

00071 ◆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/

00081 ◆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

0009デフォルトの名無しさん

2006/02/15(水) 00:50:39

>>1乙

　　　　　　　　　　　　　　　　　　　　　　　↓↓↓↓↓↓↓↓↓

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

　　　　　　　　　　　　　　　　　　　　　　　↑↑↑↑↑↑↑↑↑

0010デフォルトの名無しさん

2006/02/15(水) 00:50:50

>>1
乙

00111 ◆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/

00121 ◆u3CudPDzYA

2006/02/15(水) 00:54:02

STLつかうと一気に実行ファイルサイズが10倍に?！

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

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

C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？

#include <stdafx.h>

後氏ね。

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

0013デフォルトの名無しさん

2006/02/15(水) 00:56:15

>>12
ﾃﾗﾜﾛｽ

0014デフォルトの名無しさん

2006/02/15(水) 00:56:30

おつ>>1

0015前スレ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
全体的に書き換えたんで次のレスに貼る。

0016前スレ979

2006/02/15(水) 01:00:09

>8
[STL] を [標準ライブラリ] に変更。
STLport は sourceforge に移動して２番手に降格。
標準ライブラリ実装とドキュメントの参照先として
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

0017前スレ979

2006/02/15(水) 01:02:38

以上、次スレ立てるときに確認のうえ取り込んでもらえると嬉しい。
あ、 >9 も大事だと思うので次スレ立てる人は、何卒よろしく。

0018デフォルトの名無しさん

2006/02/15(水) 01:02:54

趣味プログラミング用にdigital marsにstlportのstl突っ込んでるけど、他のも突っ込めるのかな・・・
スルーよろ

0019デフォルトの名無しさん

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

0020デフォルトの名無しさん

2006/02/15(水) 01:06:01

19 訂正
-implementation-behavior
+implementation-defined-behavior

0021デフォルトの名無しさん

2006/02/15(水) 01:07:15

>>19
>ng とは何を指す？（ ill-formed でも undefined-behavior でもない）
もともとint *だったものをその変換でint *に戻したとき、元の値が復元されることが保障されていない、ということがいいたかった。

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

0022デフォルトの名無しさん

2006/02/15(水) 01:08:50

>>19
なんで引用部分の void が char に置換されてんの？

0023デフォルトの名無しさん

2006/02/15(水) 01:12:08

>>22
>>19 の頭がおかしいから

0024デフォルトの名無しさん

2006/02/15(水) 01:13:08

>>21
implementation-defined-behavior は「保証される」ぞ

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

0025デフォルトの名無しさん

2006/02/15(水) 01:18:17

>24
>implementation-defined-behavior は「保証される」ぞ
ごめん。よく分からん。
もちろん実装によって保障されることはあるだろうけど。
「実装にかかわらず保障される」と言えばよかったか？

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

0026デフォルトの名無しさん

2006/02/15(水) 01:20:21

>>25
> それならintをcharに置換するべきじゃないか？
それじゃもっと意味がわからん。
置換するべきじゃなかった、が正解。

0027デフォルトの名無しさん

2006/02/15(水) 01:20:27

>>25
> それならintをcharに置換するべきじゃないか？
それだと no good にならんじゃん。

0028デフォルトの名無しさん

2006/02/15(水) 01:22:09

>>25
文書化の義務がないのは undefined-behavior と unspecified-behavior

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

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

0029デフォルトの名無しさん

2006/02/15(水) 01:24:01

話が見えん。結論らしきものがあるなら、誰か一旦まとめてくれ。

0030デフォルトの名無しさん

2006/02/15(水) 01:27:01

void func(void* pv)
{
int* pi;

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

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

0031デフォルトの名無しさん

2006/02/15(水) 01:29:54

わりい、今日はもう寝る

0032デフォルトの名無しさん

2006/02/15(水) 01:36:11

>>27
>それだと no good にならんじゃん。
なんで？「reinterpret_castの結果は実装依存であって、結果の表現は元の値の表現と同じであるかもしれないし、
そうでないかもしれない」と書いてあるけど。
unionの方は記述を見つけられなかった。

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

0033デフォルトの名無しさん

2006/02/15(水) 01:42:40

>だから処理系はint * -> void * -> int *の変換が元に戻るかどうかを
>文書化しないといけない。

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

0034デフォルトの名無しさん

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や暗黙の型変換についてではない。

0035デフォルトの名無しさん

2006/02/15(水) 02:35:10

>>34
まとめ乙。でもよく分からん。
まだ結論に達していないってことで、議論している
命題を示してもらえるといいのだろうか？
「～が～であることは処理系依存か？」っていう感じで。

0036デフォルトの名無しさん

2006/02/15(水) 04:16:47

>>16
boost のところには cppll の翻訳されたヤツも入れたほうがよくね？

0037デフォルトの名無しさん

2006/02/15(水) 16:20:54

・(reinterpret_castは)安全でないか、実装依存であるか、あるいは両方である。
・static_castと違ってreinterpret_castの結果は、元のタイプにキャストバックする以外の安全な使い方がない。
・reinterpret_castは低レベルの操作であり、通常は実装系依存の変換だけに使う。

(from D&E）

0038デフォルトの名無しさん

2006/02/15(水) 16:42:09

a[10][10]　の内容を　b[10][10]　に代入するにはどんな文書けばいいでしょう？

0039デフォルトの名無しさん

2006/02/15(水) 16:53:57

>>38
型わからんので適当に
b[10][10]=a[10][10];

0040デフォルトの名無しさん

2006/02/15(水) 16:58:37

>>39
型はintでつ
説明足りなかったみたいなので補足します。
aの0.0～10.10までを丸ごとbに代入したいんですけどできますかね？

0041デフォルトの名無しさん

2006/02/15(水) 17:02:50

memmove(b,a,sizeof(int)*10*10);か？

0042デフォルトの名無しさん

2006/02/15(水) 17:14:46

出来ないなぁ・・・
やっぱり一つずつ入れてくしか無いのかな

0043デフォルトの名無しさん

NGNG

memmove(b,a,sizeof(a))
のほうが安全かと。

0044デフォルトの名無しさん

2006/02/15(水) 19:36:21

>>43
そういう風に書くときはdestinationのサイズでsizeofすべきじゃないのかい？

0045デフォルトの名無しさん

2006/02/15(水) 19:55:58

>>44
いやどっちか一方にあわせるのが間違いなのではないかと

0046デフォルトの名無しさん

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 の指導を具体化するコードは
前スレ～このスレでは現在のところ示されていない

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

0047デフォルトの名無しさん

2006/02/15(水) 20:04:12

>>44
(int)&a + sizeof b 番地が未実装の場合は？

0048デフォルトの名無しさん

NGNG

>>44-45
aとbの大きさが違うかも知れないと仮定したら危険度はどっちも同じ。
どうしても気になるなら
if (sizeof(a) == sizeof(b)) {
　memmove(a, b, sizeof(a));
}
とでもすればよい。

0049デフォルトの名無しさん

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
は処理系依存。

0050デフォルトの名無しさん

2006/02/15(水) 20:54:01

>>49
了解

0051デフォルトの名無しさん

2006/02/16(木) 00:38:24

>>50
え？ 49 じゃないけど、了解じゃねぇだろ。あんた >46 なんだよな？

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

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 はポータブルか？」という命題が残ってるんじゃね？
ちなみに俺はポータブルだと思う。

0052デフォルトの名無しさん

2006/02/16(木) 00:52:32

>>51
+ 1
^^^
ISO/IEC14882 5.2.10 Reinterpret cast の 7 を一読されたい

0053デフォルトの名無しさん

2006/02/16(木) 01:04:17

>>52
5.2.9 static cast の 10

005453

2006/02/16(木) 01:06:35

そもそも 1 に関しては
reinterpret_cast が絡んでいないように思うのですが。

0055デフォルトの名無しさん

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) ; }

0056デフォルトの名無しさん

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

0057デフォルトの名無しさん

2006/02/16(木) 02:32:25

>>56
何のつもりか知りませんが、コンパイルできませんよ。
コンパイルできても意味無さそうだし。

0058デフォルトの名無しさん

2006/02/16(木) 03:23:58

ネタ
マジ

0059デフォルトの名無しさん

2006/02/16(木) 04:03:37

ネタのつもりだったのか？笑いどころがサッパリ分からん。

0060デフォルトの名無しさん

2006/02/16(木) 05:01:27

http://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/jpdndeepc/htm/deep04202000.asp
> グローバルスコープを持ち、_ で始まる名前
が、予約されているとあるんですが、
ここで言うグローバルスコープとは
ネームスペース内のグローバル変数も入りますか？

0061デフォルトの名無しさん

2006/02/16(木) 05:05:36

>>60
入ろうが入るまいが関係ないと思うんだが？

0062デフォルトの名無しさん

2006/02/16(木) 05:29:06

>>60
入らない。

006360

2006/02/16(木) 05:29:13

>>61
えっと、つまり、
namespace hoge{
int _fuga;
}
とかしてもOK?ってことです。

006460

2006/02/16(木) 05:32:28

>>62
おっ、よかったー
感謝！

0065デフォルトの名無しさん

2006/02/16(木) 05:33:23

>>63
その通り。17.4.3.1.2の1

0066デフォルトの名無しさん

2006/02/16(木) 05:33:46

で、まさかそれをやろうとしてるんじゃあないだろうな

0067デフォルトの名無しさん

2006/02/16(木) 05:37:43

めんどっちいので _ は後ろに付けろ。

0068デフォルトの名無しさん

2006/02/16(木) 05:42:48

それはprivateｸﾗｽﾒﾝﾊﾞでやってる香具師が多いから混乱の元

006960

2006/02/16(木) 05:55:53

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

0070デフォルトの名無しさん

2006/02/16(木) 06:08:14

んー、でもね、
処理系によっては、_で始まるシンボルを#defineしてたりするから
使わないほうが良いと思うよ。
偶然同じ名前だったときに、エラーが意味不明になるし。

ctype.hとか覗いてみそ。

0071デフォルトの名無しさん

2006/02/16(木) 07:53:09

boostだと外に見せたくないものはboost::detailの中に押し込んでいるな。

0072デフォルトの名無しさん

2006/02/16(木) 09:48:21

gcc 3.4.2のctype.hは、規格上実装者予約とされているもの以外#defineしてないようだ。

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

0073デフォルトの名無しさん

2006/02/16(木) 16:00:27

俺は Hidden とかいう名前空間使ってるな。

0074デフォルトの名無しさん

2006/02/16(木) 16:25:37

既存の変数に別名を付けたいときってどうすればいいですか？
例えば、格子点を表すために
typedef std::pair<int,int> point;
としたとき、point::first を point::x の名前でアクセスしたいんですが、
どうすればいいんでしょう？

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

0075デフォルトの名無しさん

2006/02/16(木) 16:31:22

#define x first

0076デフォルトの名無しさん

2006/02/16(木) 16:33:41

#define x first
とか
int std::pair<int, int>::*const x = &std::pair<int, int>::first;
とか。

0077デフォルトの名無しさん

2006/02/16(木) 16:35:04

何故pairにpointと言う名前をつけたいのか判らん。
座標を扱いたいならstd::complex<int>の方がいい希ガス。

0078デフォルトの名無しさん

2006/02/16(木) 17:10:24

というかそもそも無理に標準のテンプレート使わんでもいいだろ。

0079デフォルトの名無しさん

2006/02/16(木) 17:10:30

>>74
std::pairを使うのが悪いと言ってみる。それくらい自作の構造体でいいだろ。

0080デフォルトの名無しさん

2006/02/16(木) 17:21:15

>>60,63,69
おいまてまて、確かに困るのは自分だけかもしれんが
グローバルネームスペースに予約されてるってことは
>>63とやるといつ_fugaが衝突起こしても知りませんよ？
って意味だぞ？
using namespace hoge;を一切やらないならいいかも
しらんが、まあ無難にいくなら使わない方が良い

0081デフォルトの名無しさん

2006/02/16(木) 17:29:01

>>80
衝突を起こしたら修飾すればいいだろ。そのための名前空間だ。

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

008274

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;
すみません、これの使い方がよくわかりません。教えていただけないでしょうか？

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

0083デフォルトの名無しさん

2006/02/16(木) 17:43:50

突然失礼します.

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

(つづく)

008483

2006/02/16(木) 17:52:56

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

0085デフォルトの名無しさん

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;
などと使う。

0086デフォルトの名無しさん

2006/02/16(木) 18:25:21

やっぱ座標取り扱いクラスを自作するのが一番じゃね?

0087デフォルトの名無しさん

2006/02/16(木) 18:27:59

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

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

008875

2006/02/16(木) 18:55:11

>>>75-76 #define x first
>いまはこれでお茶を濁してるんですが

冗談で書いてたのに、本当に使ってるとはﾜﾗﾀ

008983

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

0090デフォルトの名無しさん

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*) の相違のうちの
どれを主張する意図があったのかを拝聴できれば幸いである
現状、あなたの意図は伝わっていない

0091デフォルトの名無しさん

2006/02/16(木) 19:31:21

>>86
御意

0092デフォルトの名無しさん

2006/02/16(木) 20:07:43

>>90

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

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

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

0093デフォルトの名無しさん

2006/02/16(木) 22:08:29

>>92

>>30 の主張は、２つの型 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 を参照されたい

0094デフォルトの名無しさん

2006/02/16(木) 22:28:38

>>93

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

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

0095デフォルトの名無しさん

2006/02/16(木) 22:35:34

>>94
その手前でpi++していることが問題。

0096デフォルトの名無しさん

2006/02/16(木) 22:37:45

>>94
そう
あのコード片に書いた限りの用事なら void* を使う必要はない

0097デフォルトの名無しさん

2006/02/16(木) 22:38:07

>>96
pi の型は int* なので、インクリメント自体は問題がないですよね。
その前の void* -> int* の結果が問題だということでしょうか？

0098デフォルトの名無しさん

2006/02/16(木) 22:39:41

>>96
まあ、それはその通りなんですけど、
今問題にしているのは本当に処理系依存なのかどうかということなので・・。

0099デフォルトの名無しさん

2006/02/16(木) 22:40:03

93 訂正
-翻訳処理系
+翻訳環境

0100デフォルトの名無しさん

2006/02/16(木) 22:42:38

>>98
今問題にしているのは http://pc8.2ch.net/test/read.cgi/tech/1136690107/952 の「指導」の妥当性

0101デフォルトの名無しさん

2006/02/16(木) 22:52:30

>>93
>>>30 の主張は、２つの型 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);
このasserｔがポータブルに成立することを確かめてほしい。

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

0102101

2006/02/16(木) 22:53:38

>void *b = (int *)func(a);
訂正
int *b = (int *)func(a);

0103デフォルトの名無しさん

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* にキャストして使うのは問題ないよね。

何か見落としある？

0104デフォルトの名無しさん

2006/02/16(木) 23:03:09

>>101
「このasserｔがポータブルに成立する」のは、
「この使い方は一般に次のように書ける」からに過ぎない

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

0105デフォルトの名無しさん

2006/02/16(木) 23:10:44

>>104
今この場にいる人は、
純粋に標準を見ながらポータブルかそうじゃないかを吟味してる人と、
>>104 や >>100 のように必要性、妥当性を絡めている人がいると思う。

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

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

0106デフォルトの名無しさん

2006/02/16(木) 23:13:46

>>104
>「この使い方は一般に次のように書ける」からに過ぎない
「過ぎない」って…
俺が言った「一般に」は「必ず」という意味だが。

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

0107デフォルトの名無しさん

2006/02/16(木) 23:17:31

>>106
>前すれでも指摘したが、>>101のfuncをコールバックとして渡すことを考えてみてくれ。

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

0108106

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);

0109デフォルトの名無しさん

2006/02/16(木) 23:23:23

>>108
void *b = (int *)a + 1;
/* この間に複数の型の sizeof やバウンダリに依存する処理がない */
assert((int *)b == (int *)a + 1);

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

0110デフォルトの名無しさん

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 *が必要で、かつポータブル」な例になってると思うがどうだろう。
この例自身は相変わらず役に立たないけど、書き換えて意味のある例を作るのは難しくないはず。

0111デフォルトの名無しさん

2006/02/16(木) 23:38:50

>>110
いろいろ問題あるだろうが
とりあえず良く頑張った

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

0112デフォルトの名無しさん

2006/02/16(木) 23:46:02

いやこの流れこそ本来の相談室の意義。
議論は詰めていかないと。

0113デフォルトの名無しさん

2006/02/16(木) 23:53:46

>>110
残念ながら、これも void* は必要ない
単一のメモリ領域上に int 以外の型が混在しない以上、
回避～改善すべき処理系の特徴に依存する動作が存在しない

0114デフォルトの名無しさん

2006/02/16(木) 23:54:18

えー、そうなのか・・・

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

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

0115デフォルトの名無しさん

2006/02/17(金) 00:04:11

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

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

0116デフォルトの名無しさん

2006/02/17(金) 00:05:43

ところで、対象計算機は何？対象となるCはどの標準？

0117デフォルトの名無しさん

2006/02/17(金) 00:11:34

>>115
C の qsort はテンプレートがないからああなっただけ
テンプレートによる C++ のみからなるコードの膨張対策には継承やインラインを使う
（逆効果になりやすいので注意を要するが、それこそ処理系の特徴に依存する部分が大きい）

0118デフォルトの名無しさん

2006/02/17(金) 00:13:53

>>104,107,113
「ポータブルかどうか」の話を済ませてから必要性について考えてくれないか？
前者の議題が核心に近づくたびに必要性の話題にすり変わってしまって
正直ウザイ。

0119デフォルトの名無しさん

2006/02/17(金) 00:15:39

>>118
途中から参加した人に過去ログ全部読んでこいとまでは言いたくないが
そもそもの発端くらいは押さえてきて欲しい

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

0120デフォルトの名無しさん

2006/02/17(金) 00:16:23

>>117
どう書くのが、「好ましい」かは、また別の話かと。
>テンプレートによる C++ のみからなるコードの膨張対策には継承やインラインを使う
Boostはtype erasureと称してvoid *を使っている。

0121デフォルトの名無しさん

2006/02/17(金) 00:17:59

>>120
>>117 ですでに答えているので書くことがない

0122デフォルトの名無しさん

2006/02/17(金) 00:22:21

ていうか、ポータビリティについて話したい人は、
必要性について言われても無視すればいいだけでは。

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

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

0123デフォルトの名無しさん

2006/02/17(金) 00:27:12

>>119
俺は http://pc8.2ch.net/test/read.cgi/tech/1136690107/952 だよ。
「 void* を使う必要性」や「 qsort の現在の有用性」なんかは興味無い。
個人的には議論の余地さえ感じない。

0124デフォルトの名無しさん

2006/02/17(金) 00:28:33

>>122
void* を使うのをやめろと言っていいなら当然そうしていた
それができない理由に根本的な処理系依存がある　・・・と読んだが、違うだろうか

0125デフォルトの名無しさん

2006/02/17(金) 00:39:59

>>124
何を言いたいのかよくわからないのですが、
前スレの 934 が void* を使わざるを得ない理由に
処理系依存があるということ？
それでも何が言いたいのかよくわからないので
もう少しわかりやすく書いてもらえませんか？

0126デフォルトの名無しさん

2006/02/17(金) 00:41:40

>>124
じゃあ、お前の主張をまとめるとこれでいいか？

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

0127デフォルトの名無しさん

2006/02/17(金) 00:46:08

>>125
int オブジェクトに対して int 以外の型のポインタでアクセスまたはその逆を行い
あるいは他言語とリンクする場合などが C++ ポインタから型を取り除く主な理由で
共用体の抱える問題と根は同じ

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

0128デフォルトの名無しさん

2006/02/17(金) 00:46:26

>>126
そのとおり

0129デフォルトの名無しさん

2006/02/17(金) 00:57:28

>>128
それなら異論はない。

もつかれ。

0130デフォルトの名無しさん

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() の存在意義でもある。

0131130

2006/02/17(金) 00:58:31

ごめんよ。
- int* ip = static_cast<int*>(storage); // 確保した配列の先頭を指すポインタを作成
+ int* ip = static_cast<int*>(vp); // 確保した配列の先頭を指すポインタを作成

0132デフォルトの名無しさん

2006/02/17(金) 01:02:12

>>130
sp++; をお忘れかな？　それとも故意？

0133デフォルトの名無しさん

2006/02/17(金) 01:03:19

一生懸命スレを消費しているところ悪いが、一つ疑問に思ったので答えて欲しい。
無論、知らなければ自分の無知ということで、何も書か無くて結構。
対象はANSI-Cでいいよ

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

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

0134デフォルトの名無しさん

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 のコメント部分に反論をお願いします。

0135デフォルトの名無しさん

2006/02/17(金) 01:07:01

>>133
> ポインタ変数の実体とは何か？
その答えはポインタで無い変数と同じ。

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

0136デフォルトの名無しさん

2006/02/17(金) 01:07:02

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

0137デフォルトの名無しさん

2006/02/17(金) 01:08:03

>>132
意味がわからん。
あんた、ずーっとそうだが、相手のエスパー能力に依存しすぎ。
自分以外が読んだときのことを考えて書いてくれ。

0138デフォルトの名無しさん

2006/02/17(金) 01:08:36

(　;ﾟДﾟ)　日本の将来に危機を感じた…

0139デフォルトの名無しさん

2006/02/17(金) 01:11:25

>>138
現在に危機を感じてくれ。

0140デフォルトの名無しさん

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 と同等に正当だと言えるだろう。

か

0141デフォルトの名無しさん

2006/02/17(金) 01:19:52

>>133

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

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

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

0142デフォルトの名無しさん

2006/02/17(金) 01:30:07

サンプルが new でなく malloc という稀な例になる理由からして・・・

0143デフォルトの名無しさん

2006/02/17(金) 01:31:28

>>142
…それは見なかったことにしてやろうぜ…

0144デフォルトの名無しさん

2006/02/17(金) 01:33:00

>>140
後半のコードは sp + 2 が malloc() で確保したサイズを
超えたメモリ位置を指すことになるので不正と言えるだろう。
でもそれは void* についての議論とは何の関係も無いよ。

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

あと >>137

0145デフォルトの名無しさん

2006/02/17(金) 01:33:20

> ポインタ変数の実体とは何か？
入門書的にはメモリ上の記憶位置を示す値を格納する入れ物.

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

0146デフォルトの名無しさん

2006/02/17(金) 01:35:38

>>144
>でもそれは void* についての議論とは何の関係も無いよ。

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

0147デフォルトの名無しさん

2006/02/17(金) 01:36:30

146 続き

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

0148デフォルトの名無しさん

2006/02/17(金) 01:37:36

>後半のコードは sp + 2 が malloc() で確保したサイズを
>超えたメモリ位置を指すことになるので不正と言えるだろう。
番兵アドレスだから, 読んだり書いたりしなければオッケ.

0149デフォルトの名無しさん

2006/02/17(金) 01:38:24

>>140
処理系依存の例は良くないと思う。

0150デフォルトの名無しさん

2006/02/17(金) 01:38:46

>>148
ご名答

0151デフォルトの名無しさん

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 の例を出されても・・・
ということだったのですが、忘れてください。

0152デフォルトの名無しさん

2006/02/17(金) 01:40:33

まとめうｐどこかにある？

0153デフォルトの名無しさん

2006/02/17(金) 01:42:51

>>146
>>130 は「 >>51 の 1 はポータブルである」という命題が真であると言うための論拠だよ。
あんた結局この命題についてはどういう立場なのさ？

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

0154デフォルトの名無しさん

2006/02/17(金) 01:42:57

>>151
その引用の範囲のみに限定すると void* を使うこと自体が異常
非常に悪いスタイルの strictly conforming program というだけ

0155デフォルトの名無しさん

2006/02/17(金) 01:44:50

>>154
ポータビリティの議論がしたい人には無視されるだけ。

0156デフォルトの名無しさん

2006/02/17(金) 01:47:00

一度も言語を実装したこと無い人のオナニーが展開されるだけ
これ以上の無駄は無い
どんどんスレを消化していってくれたまえ

0157デフォルトの名無しさん

2006/02/17(金) 01:50:03

>>153
同じものをいくら比べても自明なだけで
このやりとりの中で問題になっていることに
何ら影響しない

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

0158デフォルトの名無しさん

2006/02/17(金) 02:02:48

>>157
うまく会話になってないな。

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

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

0159デフォルトの名無しさん

2006/02/17(金) 02:05:04

>>158
同じ変換経路を通ったもの同士が同じことを「ポータビリティの例だ！」と噛みつかれても・・・

0160デフォルトの名無しさん

2006/02/17(金) 02:07:53

>>159
質問されたことには答えるのが会話の基本です。
あなたにはその基本が欠けている。

0161デフォルトの名無しさん

2006/02/17(金) 02:10:03

>>160
ちゃんと答えています
期待した答えと違う事実を否定することこそ非難されるべき人格上の特徴だが
その方面を始めるなら即座に離脱する

0162148

2006/02/17(金) 02:10:09

> sizeof(int) == (sizeof(short) * 2) の場合に限るんじゃないの？
よく見てみるとそうでした. すみません.
にしても, キャストの嵐は見づらい；；

0163デフォルトの名無しさん

2006/02/17(金) 02:10:11

最近は>>160の様に自己言及型の厨が湧きやすいです
皆さんくれぐれもご注意してください
m9(｀･ω･´)9m そこのオマエだ　そうそう

0164148

2006/02/17(金) 02:13:10

>ポータビリティの話をしてるときにその前提は無い
(亀レス)
たしかに.

0165デフォルトの名無しさん

2006/02/17(金) 02:16:07

うは。「ご名答」ﾜﾛｽ

0166デフォルトの名無しさん

2006/02/17(金) 02:20:10

超えたメモリ位置を指すことになるので不正と言えるだろう。
超えたメモリ位置を指すことになるので不正と言えるだろう。
超えたメモリ位置を指すことになるので不正と言えるだろう。

0167デフォルトの名無しさん

2006/02/17(金) 02:20:41

ちなみに malloc はある境界要求を満たす

0168デフォルトの名無しさん

2006/02/17(金) 02:24:01

寝る

0169午後の紅茶

2006/02/17(金) 02:25:39

他人のC++のソースコードのコンパイルができなくて困っています。
ソースコードにDirectX8.0のヘッダファイルが使われているのですが、
ヘッダファイルが入手できません。
DirectX8.0が使われているソースコードをコンパイルする方法がありましたら
教えてください。

0170デフォルトの名無しさん

2006/02/17(金) 02:26:26

>>169
お前、SDKって知ってるか？

0171午後の紅茶

2006/02/17(金) 02:34:05

9.0のSDKは手に入れたのですが、8.0のSDKを入手できません。
d3d8.hやd3dx8.hが見つからないとエラーが出てしまいます。

0172デフォルトの名無しさん

2006/02/17(金) 02:41:56

>>169-171
スレ違い。↓逝け。
【C++】 DirectX初心者質問スレ Part7 【C++】
http://pc8.2ch.net/test/read.cgi/tech/1132216611/

0173デフォルトの名無しさん

2006/02/17(金) 02:45:43

結局さ、
http://pc8.2ch.net/test/read.cgi/tech/1136690107/952
にイチャモンつけてるのは一人だったの？
会話の難しい彼意外に居たら意見を述べて欲しいんだけど。

0174デフォルトの名無しさん

2006/02/17(金) 03:12:11

ブラウザで自分の描いた絵と誰かの描いた絵を等価交換
好きな絵を描いて右下の送信＆交換ボタン（Submit drawing）を押すだけ
国内　http://rakugake.ninja-x.jp/
海外　http://www.sketchswap.com/
Un Do、消しゴムは無し。交換した絵が手抜きだったとしてもヘバらないでいこう

0175デフォルトの名無しさん

2006/02/17(金) 09:16:22

今までお金がないから、Effective C++とMoreをずっと学校の図書館から借りて読んでたんだけど、
金ができたんで手元に置いときたくなったら、第三版(の翻訳?)がでるせいかAmazonじゃもう買えないんですね。

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

0176デフォルトの名無しさん

2006/02/17(金) 12:48:45

本を買う金が無いってどこまで困窮してんのよ

0177デフォルトの名無しさん

2006/02/17(金) 14:10:57

勉強の為の本くらい親に買ってもらってもいいと思うんだ。
家が極貧とかだったらｽﾏﾝ。

0178デフォルトの名無しさん

2006/02/17(金) 14:25:29

>>176-177
世の中にはそういう奴もいるよ。
俺も学生時代は貧乏だったから、お前らの書き込みにカチンときた。

0179デフォルトの名無しさん

2006/02/17(金) 15:11:17

飲み食い遊びの費用と同じカテゴリで捉えるから
「買えない」って話になるんじゃないかと。
学費とかと同じカテゴリで考えて払えないならご愁傷様

0180デフォルトの名無しさん

2006/02/17(金) 15:20:38

今は授業にもあるからわからんが、
コンピューター関連は親には完全に趣味と思われてたな

0181デフォルトの名無しさん

2006/02/17(金) 15:56:12

まあ、専門書って高いしね。
貧乏でも月1冊ぐらいは買えると思うけど。

0182デフォルトの名無しさん

2006/02/17(金) 15:59:34

void*については議論は収束したのかな。

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

0183デフォルトの名無しさん

2006/02/17(金) 16:46:03

>>179
それでも買えないよ。毎月 8000 円に食費抑えてやっと生活できてたのに。
そういう人間だっているんだよ…。

0184デフォルトの名無しさん

2006/02/17(金) 16:48:21

('Ａ｀)　古書もダメと来たもんだ

0185デフォルトの名無しさん

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'" :|　＼
'"　　 |　　 `''-､`'ー--─'";;-'''"　　 ,|　　＼_

0186デフォルトの名無しさん

2006/02/17(金) 17:12:00

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

0187デフォルトの名無しさん

2006/02/17(金) 17:34:58

classの継承する必要性がよくわからないんですが、
ただ同じコードを書く手間が減るだけ？

0188デフォルトの名無しさん

2006/02/17(金) 17:45:24

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

0189デフォルトの名無しさん

2006/02/17(金) 17:45:47

>>187
いろんな理由があるけど、せめて
「ただ同じコードを書く手間が減る」
↓
「同じコードを同じように修正する手間が減る」
ぐらいは連想してくれ。

0190デフォルトの名無しさん

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;
}

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

0191デフォルトの名無しさん

NGNG

＞inline A getData( void ) const{ return m_data; }
＞strncpy( classB.getData().m_str, (char*)"123456789", 10 );
＞printf("%s\n", classB.getData().m_str);

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

0192デフォルトの名無しさん

2006/02/17(金) 20:31:26

「何がどう悪いか」を書くようにしようね

0193デフォルトの名無しさん

2006/02/17(金) 20:32:13

>>192 は >>190 へ

0194190

2006/02/17(金) 20:33:24

>>191
A getData( void ) const{ return m_data; }
を実行したときに, コピーコンストラクタが起動されるのに,
コンストラクタらしきものが無いからコピーされない,
という解釈でよろしいでしょうか？？

0195190

2006/02/17(金) 20:40:13

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

0196デフォルトの名無しさん

NGNG

>>194
まあこの件に関して言えば、コピーコンストラクタを定義するのも解法の一つ。
一般的には
＞inline A getData( void ) const{ return m_data; }
ここを何とかするべきのような気がしないでもない。

0197デフォルトの名無しさん

NGNG

>>195
ヒント：　参照

0198190

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 )

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

0199デフォルトの名無しさん

NGNG

>>198
あーめんどくせえ。
ヒント：　const

0200デフォルトの名無しさん

2006/02/17(金) 21:01:13

>>194
A getData( void ) const{ return m_data; }
だと、m_dataをコピーした一時オブジェクトが返される。
その返された一時オブジェクトに変更を加えてもm_dataには反映されない。

0201190

2006/02/17(金) 21:02:12

動いたー♪

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

0202190

2006/02/17(金) 21:03:04

>>199

0203デフォルトの名無しさん

2006/02/17(金) 21:04:06

ちょっとスレ違いなのかもしれないんだけど、
C言語ポインタ完全制覇という本に

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

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

0204デフォルトの名無しさん

NGNG

>>201
若干不安だ・・・
A& const getData()
const A& getData()
A& getData() const
がそれぞれどういう違いがあるのか勉強しる。

0205デフォルトの名無しさん

2006/02/17(金) 21:05:12

>>182
>>51 OXX で決まり。
これじゃ不満か？

0206190

2006/02/17(金) 21:08:39

>>200
そうだったのかー.
解説ありがとうございました.

>>204
ラジャー.

0207デフォルトの名無しさん

2006/02/17(金) 21:09:36

>>203
C++の全てを理解する必要はないよ。

0208デフォルトの名無しさん

2006/02/17(金) 21:12:19

>>205
不満だけど同じ説明を繰り返すのが面倒なんでやらない

0209デフォルトの名無しさん

2006/02/17(金) 21:14:59

>>208 おまえはもういい。しゃべるな。今日は早めに寝ておけ。

0210190

2006/02/17(金) 21:15:49

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

0211デフォルトの名無しさん

2006/02/17(金) 21:17:43

>>210
inline指定したからって挙動が変わったら大変だ罠。
ついでにつっこんでおくと、inlineをつける場所が違うし、
クラス宣言の中に直接定義を書いたメンバ関数は、自動的にインライン扱いされる。
（インライン化されるかどうかはコンパイラの判断だけど）

0212デフォルトの名無しさん

2006/02/17(金) 21:22:32

クラス内部で
inline ってつける必要あるんですか？

0213190

2006/02/17(金) 21:23:09

>>211
わたしゃてっきり
inline A getData( void ) const{ return m_data; }
ってのは
m_data
みたく置き換わるのかと...

0214190

2006/02/17(金) 21:25:00

>>212
無いみたいです. (メモメモ)

0215デフォルトの名無しさん

NGNG

>>213
inline修飾は#defineのようにプリプロセスとして動く物ではない。
「インライン化される」というのはコンパイルされたコードが出現のたびに埋め込まれる
（スタックを消費する呼び出し手順なしに実行される）ことが期待されるということ。

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

0216デフォルトの名無しさん

2006/02/17(金) 21:41:06

>>203
確かに馬鹿でかくて所々無駄に難しい箇所が見られる言語だが
そんなんでビビってちゃ何も手につかないよ
何屋になっても OS やバスの仕様みたいに強烈複雑なのが出てくるのに
たかが C++ 程度でってのが正直なところ

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

>>209

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

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

0217デフォルトの名無しさん

2006/02/17(金) 21:43:13

('Ａ｀)　煽り煽られ共倒れ・・・か

0218190

2006/02/17(金) 21:47:49

>>215
納得いたしました.

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

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

0219デフォルトの名無しさん

2006/02/17(金) 21:50:44

>>205 ありがとう。
漏れがかつて書いたメモリプールのコードはポータブルでないと確定した（死

0220デフォルトの名無しさん

2006/02/17(金) 21:54:39

>>219
なんか変
ポータブルではないからこそデフォルトの実装やサードパーティのライブラリがなくて
あなたが書くことになったんじゃないの？

0221デフォルトの名無しさん

2006/02/17(金) 21:55:12

>>219
どんなコード？

0222デフォルトの名無しさん

2006/02/17(金) 21:56:54

インライン展開の是非を強制できる指定ができたらいいと思うことはある。
あと、現状でも手動でインライン展開しやすくするよう実装をコピペして増やしていると
実にばからしいと思う。
処理系によっては、事実上強制する指定もできるが。

0223デフォルトの名無しさん

2006/02/17(金) 22:27:53

>>222
C++ でも C でも、ある程度は実装レベルを想像しながら書いていけるのは
安心感があっていいけど、何か特定のシーケンスを強く期待する場合は
その部分はアセンブラで書いたほうがいいとも思う

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

0224デフォルトの名無しさん

2006/02/17(金) 23:04:00

ゲーム開発用のMS製コンパイラは強制インライン展開キーワードがあるお

0225デフォルトの名無しさん

2006/02/17(金) 23:24:56

gccも最適化オプションにforceinlineがあるしな

0226190

2006/02/17(金) 23:28:39

>>204
const A& getData( void ) const{ return m_data; }
とすると上手くいった. ということは,
const{ ... }
とすると, 戻り値が const 扱いになるってことだろうか.

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

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

0227デフォルトの名無しさん

2006/02/17(金) 23:34:10

>>226
そのあたり(204)の話は、ググってもすぐ見つかるし、まともな本なら
調べればすぐわかるよ。

0228190

2006/02/17(金) 23:39:10

>>227
そーなのかー. 情報収集スキル分補充してきます.

0229デフォルトの名無しさん

2006/02/17(金) 23:48:30

>>224-225

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

0230デフォルトの名無しさん

2006/02/18(土) 00:07:52

>>226
メンバ関数の括弧の後のconstはメンバを書き換えないということから、
thisがconstなポインタとして扱われるという効果がある。

0231190

2006/02/18(土) 00:35:21

>>230
>thisがconstなポインタとして扱われる
納得いたしました.
const T *foo;
とするとコンパイラは,
*foo, foo->
という記述に対してエラーを出すということと併せて.

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

0232デフォルトの名無しさん

2006/02/18(土) 01:25:06

>>203
その本の著者が、
「そんなに難しい言語を解説しちゃう俺って天才ｗ」
って読者に偉ぶってるだけ

0233デフォルトの名無しさん

2006/02/18(土) 01:43:31

「それでもメジャーになるくらいのメリットがC言語にはある」
っていう意味だろとマジレス

0234デフォルトの名無しさん

2006/02/18(土) 01:45:05

ぶっちゃけCマニア以外、コードを読めて、自分の思い通りのコード書ければどうってことない
それだけのこと

0235デフォルトの名無しさん

2006/02/18(土) 01:48:13

effective C++は読むべき。
今読んでるけど、その辺のことも書いてあった。

0236デフォルトの名無しさん

2006/02/18(土) 01:49:52

>>235
は、inlineキーワードについてです。

0237デフォルトの名無しさん

2006/02/18(土) 01:58:34

inlineってデフォルトだと関数の実体が1KB以下ならインライン展開するんだっけ？
VCだけ？
それとも俺の勘違(ry

0238デフォルトの名無しさん

2006/02/18(土) 02:04:41

>>237
規格では何も決まってない。

0239デフォルトの名無しさん

2006/02/18(土) 02:32:01

inlineについてはefficient c++の方が詳しいと思うぞ

0240190

2006/02/18(土) 05:11:05

スレ違いを承知で, 恐れ入りながら申し上げます.

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

0241デフォルトの名無しさん

2006/02/18(土) 05:49:52

それら2冊は「C++でプログラムを組む方法」を学ぶための本だけど、
Effective C++は「C++でより良いプログラムを組む方法」を学ぶための本であり、
「C++そのもの」の基礎については既に読者が理解している前提で書かれている。

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

0242デフォルトの名無しさん

2006/02/18(土) 12:06:10

std::copyとmemcpyなんですが、皆さんはどういう基準で使い分けてますか?
それともstd::copyに統一してたりするんでしょうか?

0243デフォルトの名無しさん

2006/02/18(土) 12:44:58

>>240
放っておいてなんて言わずに全部読め

0244デフォルトの名無しさん

2006/02/18(土) 13:29:55

>>240
本読むの遅いか読む時間が無いと勘違いしてる人？
とりあえず流し読みでいいから全部目を通して、その後熟読するようにすると時間節約できるよ。

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

0245デフォルトの名無しさん

2006/02/18(土) 15:05:27

>>242
memcpy()などのレガシーな関数は、ポインタを生で扱わないといけないようなとき以外は封印している漏れガイル。

0246デフォルトの名無しさん

2006/02/18(土) 15:09:34

>>242
迷ったらstd::copy。
std::memcpyは組み込み型やPODにしか使えない。

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

0247190

2006/02/18(土) 16:46:49

>>244
たしかに本読むの遅い方です.

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

0248デフォルトの名無しさん

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<>プレフィクスをつけなければならないと書かれているのですが。

0249デフォルトの名無しさん

2006/02/18(土) 22:17:38

Hoge& foo = new Hoge;
のようにnewしたインスタンスを参照で受けることはできますか。

0250デフォルトの名無しさん

2006/02/18(土) 22:49:19

>>249
俺のところではこういうことができた。
Hoge& foo = *new Hoge;
delete &foo;
だが、これがやっていいことなのかどうか分からない。

0251デフォルトの名無しさん

2006/02/18(土) 22:54:11

>>250
多分問題ないと思う。

0252デフォルトの名無しさん

2006/02/19(日) 00:14:28

>>250-251
動作に問題は無いだろうが、可読性に問題があると思う。

std::auto_ptr<Hoge> p(new Hoge);
Hoge& foo = *p;

こんなんじゃダメなの？

0253デフォルトの名無しさん

2006/02/19(日) 00:18:37

>>248
g++ ではコンパイルできなかったので、よくない。
本題ではないが main() の戻り値を省略してるのもコンパイルエラーになった。

0254248

2006/02/19(日) 00:25:19

>>253
やはりそうですか。

main()はもちろん、貼り付けるための省略です。
return書くと、一行増やさないと読みづらいですし。

VC++どうなっているんだろう。
メンバの特殊化には、template<>を省略してもおｋ
クラスの特殊化には、省略できない（でも、ちゃんと意図を認識できているようなエラーメッセージを吐く）

template<>がなくても受け付けるような、
文法のルールを実装していそう。

なんでメンバでは省略を許しているのか不明ですが。

0255248

2006/02/19(日) 00:36:49

話は変わりますけど、main()でコンパイルエラーになるのはいいですね。
VCは以下が全部、問題なく通る……。

main() {} //まあ、K&Rだし
main() { return 0 ; } //これは、まあ、Cという歴史的理由で通るというのも分かるかな。
void main() {} //これはありえない。

int main() {}
ただこれは、禿の解説を見るに、問題なさそうなんですが。

ttp://www.research.att.com/~bs/bs_faq2.html#void-main

　＞In C++, main() need not contain an explicit return statement. In that case, the value returned is 0, meaning successful execution. For example:

0256デフォルトの名無しさん

2006/02/19(日) 00:48:23

>>255
戻り値の省略は規格で認められていない。 VC が緩いようだ。
return の省略は禿の言うように規格で認められていて、動作も決まっている。

0257デフォルトの名無しさん

2006/02/19(日) 00:49:03

>>254
VC8.0 では、/Za で言語拡張をキャンセルすると、template<> のないメンバの特殊化体定義はエラー(C2906)になる。

0258248

2006/02/19(日) 00:55:48

>>257
VC7.0と7.1も同じなようです。
MS独自のものだったんですか……。

0259デフォルトの名無しさん

2006/02/19(日) 00:57:36

Effective C++の第３版って日本語予定ありますか？

0260デフォルトの名無しさん

2006/02/19(日) 01:02:41

>>259
今のところ無かったはずだが
まだ店頭在庫で改訂2版置いてるところ結構あるから探して買うが吉

0261・∀・）っ-○●◎- ◆Pu/ODYSSEY

2006/02/19(日) 02:24:40

More～の訳がマシなやつキボン

0262デフォルトの名無しさん

2006/02/19(日) 12:08:23

>>261
原文(英語)のも買えば解決。もしくは（ｒｙ

0263デフォルトの名無しさん

2006/02/19(日) 13:15:57

Effective C++の第３版はどうなってるか興味あるな
(Boostの紹介があるのがすげえとか見たけど
Boostとあろうものがそれくらいで歓喜するなよと)
C++すっかり変わってしまったから

0264デフォルトの名無しさん

2006/02/19(日) 14:00:26

>>263
英語版を見る限り、boostに関する内容はないようだ。
templateに関する項目は確かに増えているが、これだけなら、
C++ Templatesの方がずっと詳細だし、やっぱりEffective
シリーズは初心者向けという色合いが強いように思える。

もちろん日本語版が出たらそれも買うつもり。

0265デフォルトの名無しさん

2006/02/19(日) 21:31:20

・どうやって、C++で作ったプログラムをUNIXでシステム化するのか。
・クライアントがVCで、サーバがC++の時に、
　どうやってデータのやりとりを行うのか。
・なぜ、C++でOracleとの連携が取れるのか。

そういう情報が載っているサイトや本を教えて下さい。

0266デフォルトの名無しさん

2006/02/19(日) 21:36:12

釣り？

0267デフォルトの名無しさん

2006/02/19(日) 22:31:46

>>265
http://www.google.co.jp/search?hl=ja&q=visual+C%2B%2B+oracle&lr=

0268265

2006/02/19(日) 23:12:34

釣りではありません。
本当にわからないので、知りたいんです。
ですから、勉強できる本やサイトが知りたいんです。

0269デフォルトの名無しさん

2006/02/19(日) 23:21:52

ネタにマジレスしてすまんな・・・

>>268
> C++で作ったプログラムをUNIXでシステム化
「プログラムをシステム化」って何だ？

> クライアントがVCで、サーバがC++の時にどうやってデータのやりとりを行うのか。
今まで一度も「クライアントがVC」なんて条件聞いたことないわけなんだが、
ま、普通にTCPとかUDPとかでいいんじゃない？

> なぜ、C++でOracleとの連携が取れるのか。
Oracleが外部にプログラムインタフェイスを公開してるからじゃない？

サイト調べるよりまずググり方学んできた方が・・・

0270デフォルトの名無しさん

2006/02/19(日) 23:26:33

釣り臭いポイント

・質問が複数ある。
・どの質問も微妙にスレ違い。
・VCとC++を違うものとして扱ってる。
・一見、明確な質問のようだが、
　よく見ると自分がどの程度わかっていて、
　どういったことが疑問なのかさっぱりわからない。

0271デフォルトの名無しさん

2006/02/19(日) 23:28:09

総合すると

　　　　　　エンジニア視点ではなく、ユーザ視点で見てる

ってことかな・・・

0272デフォルトの名無しさん

2006/02/19(日) 23:31:21

>>271
だね。

>>265
意地悪するつもりはないが、俺たちじゃ君の力にはなれそうにありません。
まずは、書店にでも行って自分がわかるレベルの書籍を探してください。

0273デフォルトの名無しさん

2006/02/19(日) 23:48:56

全く同じtypedefを二度以上するのは問題ですか？
たとえばこんなの
typedef int Int;
typedef int Int;
VCだと全く何も言われないんだけど。

0274デフォルトの名無しさん

2006/02/19(日) 23:53:02

typedef って宣言扱いだっけ？
宣言なら何度でもOK
定義なら一回だけ。

0275265

2006/02/20(月) 00:22:28

いや、基本はUNIXでC++で製造したプログラムがなぜ動くのかを知りたいんです。
自分は、ライブラリを作っているだけなのに、
何で動いているのかを知りたいんです。

0276デフォルトの名無しさん

2006/02/20(月) 00:22:59

>>275
ｋｔｋｒ！！！！！！！！！！！１１１１１１１１１１１
トリつけろ、お前面白いｗｗｗｗｗ

0277デフォルトの名無しさん

2006/02/20(月) 01:09:04

>>275
http://www.amazon.co.jp/exec/obidos/ASIN/4822281493/
http://www.amazon.co.jp/exec/obidos/ASIN/4822281019/
とりあえず、このへんの本でも読んどけ。

>>276
おちつけｗ

0278デフォルトの名無しさん

2006/02/20(月) 01:12:25

>>275
そんなことも知らないでプログラム動かしてたのかよ・・
仕方ないから教えておいてやる
一回しか言わないからな、しっかり記憶しておけよ

これで動いています
ttp://www.amazon.co.jp/exec/obidos/ASIN/B000059HU5/qid%3D1140365474/503-1346873-8247132

0279277

2006/02/20(月) 01:16:16

マジレスした俺は負け組ですか？

>>275の様子からするとやっぱり俺は
負け組ってことになりそうな予感・・・orz

0280デフォルトの名無しさん

2006/02/20(月) 01:16:38

>>275
まずはUNIXがなぜ動くのかから疑問に思え。

0281デフォルトの名無しさん

2006/02/20(月) 01:35:05

こんな天然物は最近珍しいな。大切にしようぜ。

0282デフォルトの名無しさん

2006/02/20(月) 03:19:54

複数のiteratorとかchar*とかをひとつのiteratorと見せかけれるものはありませんか?

std::vector buf;

void f(char* s, int n) {
　typedef std::istream_iterator<char> input_iterator;
　std::copy( input_iterator(source), input_iterator(), std::back_inserter(buf) );　　// これと
　std::copy( buf.begin(), buf.end(), s );　　　　　　　　　　　　　　　　　　　　　　　　　　// これを一回で済ませたいです
}

がんばれば自分で作れなくもないと思うのですが、標準やboostとかで用意されてるものがあればそちらを使いたいです

0283デフォルトの名無しさん

2006/02/20(月) 03:24:40

>>282
標準にはない。
Boostにもその機能そのものはなかったと思う。

0284デフォルトの名無しさん

2006/02/20(月) 09:04:48

>>282
boostにzip_iteratorというのを見つけた

0285デフォルトの名無しさん

2006/02/20(月) 09:09:44

>>282
std::vector<char> buf なら、別に char* にコピーする必要無いと思う。

0286デフォルトの名無しさん

2006/02/20(月) 13:34:45

>>284
zip_iteratorは282がやりたいことには使えない

0287デフォルトの名無しさん

2006/02/20(月) 16:19:44

>>282
その例ならそもそもsource.readを使ったら駄目なのか？

0288デフォルトの名無しさん

2006/02/20(月) 17:16:25

複数のイテレータをメンバに持って、それらすべてに同じ操作を適用するような
multi_iteratorを書けばいいかもしれない。
boost/iterator_facadeあたりを使えば多少は楽に。

class multi_iterator : public boost::iterator_facade<...> {
　typename some::iterator& s;
　typename other::iterator& o;
　increment() { ++s; ++o; }
...
};

クラステンプレートにすれば任意のイテレータを複数持てる。
イテレータの数を任意にしたければ、mpl/BOOST_PPでの自動生成で。
dereference()等ではstd::map()で返すとか。問題多そうだが。

0289デフォルトの名無しさん

2006/02/20(月) 17:18:45

質問者の最初の書き込みにすでにそういうことが書いてあった。駄レスｽﾏｿ

0290デフォルトの名無しさん

2006/02/20(月) 17:23:31

>>287
istream_iterator<char>は空白を読み飛ばすから、readじゃ代用できない。

0291デフォルトの名無しさん

2006/02/20(月) 18:06:37

function_output_iteratorを使って書いてみた。使いかたに癖があってあまり便利じゃないかも。

template <typename T> inline void output(boost::tuples::null_type, const T &) {}
template <typename Cons, typename T> inline void output(Cons &c, const T &x)
{
*c.get_head() = x;
++c.get_head();
output(c.get_tail(), x);
}

template <typename Tuple> struct replicator
{
replicator(const Tuple &t) : iters(t) {}
template <typename T> void operator()(const T &x) const { output(iters, x); }
private:
const Tuple iters;
};

template <typename Tuple> boost::function_output_iterator<replicator<Tuple> > make_broadcast_iterator(const Tuple &t)
{ return boost::function_output_iterator<replicator<Tuple> >(replicator<Tuple>(t)); }

int main()
{
char *s = new char[1000];
std::vector<char> v;
typedef std::istream_iterator<char> iic;
std::back_insert_iterator<std::vector<char> > ins(v);
char *p = s;
std::copy(iic(std::cin), iic(), make_broadcast_iterator(boost::tie(ins, p)));
}

0292デフォルトの名無しさん

2006/02/20(月) 18:14:38

gccのgompはどこからダウンロードできるのでしょうか？

0293デフォルトの名無しさん

2006/02/20(月) 19:15:52

branchの方に普通にあったと思ったけど？

0294デフォルトの名無しさん

2006/02/22(水) 17:06:17

たとえば、

sql_alias x1, x2;

sql_expr expr =
select( x1["a"], "b", "c", "d" )
.from[ inner_join( x1 = "table1" ), ( x2 = "table2" ), x1["a"] == x2["a"] ]
.where( x1["a"] == _1 && between( "b", 1, 10 ) )
.order_by( desc( x1["a"] ) );

string sql4ora = gen_oracle( expr );
string sql4mssql = gen_sqlserver( expr );

みたいな、C++によるλライクなSQLジェネレータを作るとしたら
需要あるのだろうか？

0295デフォルトの名無しさん

2006/02/22(水) 18:13:05

たぶん漏れが知らないだけだろうけど、対象SQLサーバによらず同じコードですむ
（PHPでいうPEAR::DBのような）フリーのC++用データベースライブラリはほしいな。

>>294お願い(*'-')人

0296デフォルトの名無しさん

2006/02/23(木) 01:30:01

>>282
これでいいじゃんｗ

BOOST_FOREACH(char ch, boost::make_iterator_range(input_iterator(in), input_iterator()))
{
buf.push_back(ch);
*s++ = ch;
}

0297デフォルトの名無しさん

2006/02/23(木) 01:51:30

>>282
これでもいいじゃん?

using namespace boost::lambda;
for_each(input_iterator(source), input_iterator()
, (bind(&std::vector<char>::push_back, &buf, _1), *var(s)++ = _1));

0298デフォルトの名無しさん

2006/02/23(木) 03:26:56

>>296
foreach.hppはどこで手に入る？

0299デフォルトの名無しさん

2006/02/23(木) 05:46:48

>>298
CVS の HEAD

0300298

2006/02/23(木) 06:19:08

>>299
thanx

0301デフォルトの名無しさん

2006/02/23(木) 14:34:45

foreachのソースは言語オタクにはたまらないんだろうが
俺にはさっぱりわからんｗ

0302デフォルトの名無しさん

2006/02/24(金) 23:20:48

テンプレートとかSTLとか全然使ってない。
std::sprintf()だけあればいいよ。って思うの俺だけ？

0303デフォルトの名無しさん

2006/02/24(金) 23:22:28

>>302
お前だけじゃないだろうが、自分の知らないことが世の中には
たくさんあることだけは忘れないようにしよう。

0304デフォルトの名無しさん

2006/02/24(金) 23:30:49

>>302
あなたがC++の何を使おうが、それはあなたの自由。
テンプレートやSTLを使う人間を否定さえしなければ問題ない。

0305デフォルトの名無しさん

2006/02/24(金) 23:33:58

>>302
せめてboost::formatにしようぜ。

0306デフォルトの名無しさん

2006/02/24(金) 23:39:28

>>304の訳

>>302
勝手にすれば？
ウゼェからとっとと消えろ

0307デフォルトの名無しさん

2006/02/24(金) 23:49:36

再利用性考えまくったコードが一回でお蔵入りってのもあるけどな。

0308デフォルトの名無しさん

2006/02/24(金) 23:49:40

テンプレートを使わせようと必死な>>305-306が見苦しく、大変失礼いたしました。

0309デフォルトの名無しさん

2006/02/24(金) 23:54:59

いや寧ろ、テンプレートを使えない香具師が必死になっているようにしか見えないのだが。

それはさておき、いつも迷うのだが文字列処理する関数は次のどれを引き数にとるべきかな?
・const char *
・std::string
・const std::string &

0310デフォルトの名無しさん

2006/02/24(金) 23:59:43

>>309
だれも必死になんかなってないだろ。

const std::string& がデフォルトだろうな。
std::string 渡すときもコストが低いし、
const char* のインターフェースを兼ねることもできる。
ただ、動的なメモリ確保に制限がある場合は const char* に
したほうがいいだろう。
std::string による値渡しは参照渡しに比べてメリットがあるとは思えない。

0311デフォルトの名無しさん

2006/02/24(金) 23:59:45

>>309
公に晒すならconst char*以外に有り得ない。

0312・∀・）っ-○●◎- ◆Pu/ODYSSEY

2006/02/25(土) 00:01:55

ここ最近WindowsのGUIベッタリなコードしかかいてない俺はLPCSTR

0313デフォルトの名無しさん

2006/02/25(土) 00:08:48

どうしてもって時以外はconst char*じゃね？

0314デフォルトの名無しさん

2006/02/25(土) 00:28:16

>312
最近というのならLPCTSTR（もしくはLPCWSTR決め打ち）じゃないのか？

つまり、
普通はconst std::wstring &
訳ありの時はconst wchar_t *

となる時代はいつの事やら。

0315・∀・）っ-○●◎- ◆Pu/ODYSSEY

2006/02/25(土) 00:44:33

std::basic_string<TCHAR>

0316309

2006/02/25(土) 00:52:49

ふむ、考えてみたら文字列リテラル渡すこともあるからconst char *がいいのかな。
THX!

0317デフォルトの名無しさん

2006/02/25(土) 01:13:26

const std::string& には文字列リテラル渡せますよ、と。

0318デフォルトの名無しさん

2006/02/25(土) 04:36:08

そこでメモリの動的確保が問題になりますよ、と。
既に書かれているわけですな。

0319デフォルトの名無しさん

2006/02/25(土) 08:52:22

どうしても気になるときにはこんなこともする。
void hoge(const char*);

inline void hoge(const std::string& s)
{
hoge(s.c_str());
}

0320デフォルトの名無しさん

2006/02/25(土) 10:05:58

class StringOrPtr
{
public:
StringOrPtr(const char* p) : p_(p) {}
StringOrPtr(const string& str) : p_(str.c_str()) {}
operator const char*() const { return p_; }

private:
const char* p_;
};

なんてのを作ったが、見た目が気持ち悪かったので使わなかった。

0321デフォルトの名無しさん

2006/02/25(土) 11:42:03

>>320
stringの寿命がわからんところで使って死にそうなコードじゃね。

0322デフォルトの名無しさん

2006/02/25(土) 13:56:09

>>320-321
こういう場面で必要。
http://www.tietew.jp/cppll/archive/8082
http://www.tietew.jp/cppll/archive/8098

0323デフォルトの名無しさん

2006/02/25(土) 14:58:49

可変長引数辞退忌避してるからなぁ。

vargsって過去互換以外でつかうか？

0324デフォルトの名無しさん

2006/02/25(土) 16:15:49

printf類自体は代わりにboost::formatもあるしな。

0325デフォルトの名無しさん

2006/02/25(土) 18:05:31

以前Effective C++が欲しいと言ってたものです。
紀伊国屋のサイトで購入できました。（店舗から取り寄せ）
私の検索時であと３店舗、今はあと１店舗しか残ってなさそうなので
他に興味がある方はお早めに。

0326デフォルトの名無しさん

2006/02/25(土) 18:26:48

boostは無駄が多い

0327デフォルトの名無しさん

2006/02/25(土) 18:37:22

あれだけたくさんのライブラリが入っているのに
「boost は」なんて一括りにして評価するのは
バカか悪意を持ったものとしか思えない。

0328デフォルトの名無しさん

2006/02/25(土) 18:40:18

可変長引数は必要が有れば使う
Javaでも後から追加になったくらいで
便利な機能だと思うけど・・

0329デフォルトの名無しさん

2006/02/25(土) 18:46:17

boost厨って何で必死なんだろうね

0330デフォルトの名無しさん

2006/02/25(土) 18:53:17

こちらへどうぞ。

Boostを語れゴラァ part2
http://pc8.2ch.net/test/read.cgi/tech/1139313234/

0331デフォルトの名無しさん

2006/02/25(土) 19:05:56

BOOTSを語れゴラァ part2
http://pc8.2ch.net/test/read.cgi/tech/1139266461/

0332デフォルトの名無しさん

2006/02/25(土) 19:10:17

わろすわろす

0333デフォルトの名無しさん

2006/02/25(土) 19:34:32

グローバルで構造体を確保しています。
これをグローバルで確保せずにSTL使ってnewで確保しようと思ってます。
newの速度はどうなんでしょうか？

0334デフォルトの名無しさん

2006/02/25(土) 19:43:31

どうなんでしょうね。

0335デフォルトの名無しさん

2006/02/25(土) 19:48:22

new の評価結果の代入先がグローバルのポインタだったりしたらアフォだな

0336デフォルトの名無しさん

2006/02/25(土) 20:15:55

STLとnewの文脈上の関連がわからないんだが

0337デフォルトの名無しさん

2006/02/25(土) 20:20:28

new は言語の機能
STL はライブラリ
STL は new の応用例

0338デフォルトの名無しさん

2006/02/25(土) 20:27:56

>>333
速度なんぞ気にせず使って良いと思う。
それが問題になることはまず無いはず。

>>336
newした構造体をvectorかなんかに突っ込むんでしょ。

…とすると
> STL使ってnewで確保しようと思ってます。
ってのは表現がおかしいな。

0339デフォルトの名無しさん

2006/02/25(土) 20:37:24

IQが20くらい違ってくると会話に支障が出てくるらしいぞ
ってことできっと>>333は未曾有の大天才なんだろう

0340デフォルトの名無しさん

2006/02/25(土) 20:55:57

クラス内のプライベート変数のポインタを外部に渡す関数を作ろうと思ってるんですが
そんなことするのって設計としてあり？

0341デフォルトの名無しさん

2006/02/25(土) 21:00:05

NG。駄目駄目。ありえない。

0342デフォルトの名無しさん

2006/02/25(土) 21:00:31

ﾌﾟﾗｲﾍﾞｰﾄﾒﾝﾊﾞのﾊﾝﾄﾞﾙを返すなんて信じられないわ！

0343デフォルトの名無しさん

2006/02/25(土) 21:10:14

constなポインタならOKなんじゃない？

0344デフォルトの名無しさん

2006/02/25(土) 21:10:20

>>340
constなポインタならまあありかもしれん。

0345デフォルトの名無しさん

2006/02/25(土) 21:21:54

const でも delete はできるからなあ・・・

0346デフォルトの名無しさん

2006/02/25(土) 21:23:03

>>343
はらわた曝す設計になってる時点で外部でconst外しがされると思われ。

0347デフォルトの名無しさん

2006/02/25(土) 21:25:50

ポインタ型の変数ではなく、「メンバ変数」へのポインタではないか？
（もちろんメンバへのポインタでもない通常のポインタ

0348デフォルトの名無しさん

2006/02/25(土) 21:30:23

const外しの邪法を行う人間相手にはconst参照を返すメソッドも無力だからなぁ。
正直そんな腐った奴の面倒までは見なくて良いような気が。

0349デフォルトの名無しさん

2006/02/25(土) 21:31:43

そういう奴は private 破りもあっさりやりそうだな

0350デフォルトの名無しさん

2006/02/25(土) 21:31:53

constな参照返せば良いんでないかい？

0351デフォルトの名無しさん

2006/02/25(土) 21:34:11

>>350
はらわた曝す設計になってる時点で外部でconst外しがされると思われ。

0352デフォルトの名無しさん

2006/02/25(土) 21:36:13

こんな感じです。
class test {
private:
int test1[10];
public:
int *GetTest(){
for ( int i=0; i<10; i++)
{
if ( test1[i] == -1 ) return &test1[i];
}
return NULL;
}
}
どうでしょうか？

0353デフォルトの名無しさん

2006/02/25(土) 21:37:56

参照のconstは外せないでしょ
わざわざポインタ取り出せば、外せるけど
それこそ、そんな奴の面倒まで見切れない

0354デフォルトの名無しさん

2006/02/25(土) 21:38:27

話がループしてるって。

>340よ、誓うんだ。二度とそんなことはしないと！

0355デフォルトの名無しさん

2006/02/25(土) 21:41:19

>>352
それだけなら別に可かと
test1[10]がお互いに・若しくは他のメンバと関係しあっているのなら不可

0356デフォルトの名無しさん

2006/02/25(土) 21:44:47

>355
理解力不足ですいません。ほかのメンバと関係しあっているのならってのは
どういうことですか？

0357デフォルトの名無しさん

2006/02/25(土) 21:46:18

>>353
残念ながら外せます。

#include<string>
#include<iostream>
class human{
    std::string name_;
public:
    const std::string&name(){return name_;}
    human(const std::string&name):name_(name){}
};
int main(){
    human a("test");
    const_cast<std::string&>(a.name())="a";
    std::cout << a.name();
}

まぁconst外しする奴は腐ってるから面倒見なくても良いと思うけどなー。

0358デフォルトの名無しさん

2006/02/25(土) 21:47:37

>>352

>>355の言ってる以外にも、

「空き」を意味するために、NULLと-1の両方を使ってるのが邪悪。
半年もたったら自ら使い方を間違ってささりそう。

0359デフォルトの名無しさん

2006/02/25(土) 21:50:10

constﾎﾟｲﾝﾀを返すのは別にいいでしょ
それをconst_castする香具師がﾎﾞｹなのであって、クラス自身は問題なしなはず

0360デフォルトの名無しさん

2006/02/25(土) 22:44:58

352です。
この使い方自体はconstでポインタを渡せば特に問題ということでいいでしょうか？
ちなみに-1とNULLを使ってるのは意味があります。
class test {
private:
int test1[10];
public:
const int *SetTest(int i_num){
for ( int i=0; i<10; i++)
{
if ( test1[i] == -1 )
{
test[i] = i_num:
return &test1[i];
}
}
return NULL;
}
}

Test test;
int *pNum;
pNum = test.SetTest(10);
if ( pNum != NULL )
{
// 操作するときはこんな感じ
}

のような使い方をしようと思っているのですがどうでしょうか？
この中のintをSTL・newとかを使って管理しようかなと思ってます。

0361デフォルトの名無しさん

2006/02/25(土) 22:52:34

>>360
全体が分からないからなんだけど
その「操作」ってやつをTest内で実装すれば内部を晒すこともない

設計が良くない感じはするね

0362デフォルトの名無しさん

2006/02/25(土) 23:00:02

いや、-1とNULLに意味があるのはわかる。
わかるけど、後々使い方を間違えやすい実装だよ、と言ってるわけ。

もし、test.SetTest(-1)ってやったらどーなるの？

悪いこと言わないから、せめて、アサーションくらい入れときましょう。

const int *SetTest(int i_num){
assert(i_num != -1);
for ( int i=0; i<10; i++)

もっと言うなら、空きがあるかどうかを記録するための配列を、
値を保持する配列とは別個に持った方が良いと思うよ。

そうすれば、使ってる側は、格納する値が-1かどうかは気にせずに済むから。

0363デフォルトの名無しさん

2006/02/25(土) 23:00:23

int *pNum;
pNum = test.SetTest(10);
if ( pNum != NULL )
{
// 操作するときはこんな感じ
}
はどこでも行われる可能性があると思っていただいたほうがいいです。
Test testはシングルトンで扱っていろんなとこから値がセットされて
いろんなとこからいじる可能性があります。

0364デフォルトの名無しさん

2006/02/25(土) 23:18:05

>>356
例えば、class testがメンバ変数「int　a」を保持していたとして
aとtest1[10]が依存しあっているのなら・・・・の意です。

0365デフォルトの名無しさん

2006/02/25(土) 23:21:42

＞// 操作するときはこんな感じ
ここには具体的には何が入るの？

0366デフォルトの名無しさん

2006/02/25(土) 23:38:08

class test {
private:
typedef struct {
int flag;
int point;
}T_TEST　test1[10];
public:
const T_TEST *SetTest(int i_num){
for ( int i=0; i<10; i++)
{
if ( test1[i].flag == -1 )
{
test[i].point = i_num:
return &test1[i];
}
}
return NULL;
};
};

Test test; // これはシングルトンで扱う
// 以下はいろんなところで使う-----------
int *pTest;
pTest = test.SetTest(10);
if ( pNum != NULL ){ pTest.point++; }

いろいろ変更してこんなかんじにしましたがどうでしょう？

0367デフォルトの名無しさん

2006/02/25(土) 23:38:40

>>360
素直に、vector＜ｉｎｔ＞じゃダメ？

0368デフォルトの名無しさん

2006/02/25(土) 23:44:07

全角托ｲ

0369デフォルトの名無しさん

2006/02/25(土) 23:46:03

ウホ帰れ
うんこ臭いんだよ

0370デフォルトの名無しさん

2006/02/25(土) 23:52:18

ちょ、ちょっとまて。
フラグを用意したのはＯＫ。でも、なぜフラグまで外部にさらす？

あと、値を変更させるつもりならconstポインタは使えないから・・・
それと、pTestの型はどっちみち間違い。

俺に3行変えさせてくれ。
int *SetTest(int i_num){ ← ここ
と
return &test1[i].point; ← ここ。
と
if ( pNum != NULL ){ *pTest++; }

>>360
STLのvectorを使うなら、サイズ変更でメモリの再割り当てが起きたときのことも考えておかないとダメ。

0371デフォルトの名無しさん

2006/02/25(土) 23:58:40

Σ(ﾟДﾟ；)やべ。

3つめは
if ( pTest != NULL ){ *pTest++; }

の間違い。

0372デフォルトの名無しさん

2006/02/26(日) 00:04:30

366と360は同一人物なのでよろしく、もう一度書きます。
class test {
public:
typedef struct {
int flag, point, money;
}T_TEST;
private:
T_TEST　test1[10];
public:
T_TEST *SetTest(int i_point, int i_money){
for ( int i=0; i<10; i++) {
if ( test1[i].flag == -1 ) {
test1[i].point = i_point;
test1[i].money = i_money;
return &test1[i];
}
}
return NULL;
};
};

Test test;

T_TEST *pTest;
pTest = test.SetTest(10);
if ( pNum != NULL ){ pTest.point++; }

フラグまで外部に晒すのは構造体のメンバが複数あるので結果的にフラグも
見えてしまう状況はいたしかたないと思ってます。

0373デフォルトの名無しさん

2006/02/26(日) 00:13:12

> 366と360は同一人物なのでよろしく、もう一度書きます。
すまそ。

> フラグまで外部に晒すのは構造体のメンバが複数あるので結果的にフラグも
> 見えてしまう状況はいたしかたないと思ってます。

いたしかたなくない。

typedef struct {
int point, money;
} T_TEST;

typedef struct {
int flag;
T_TEST data;
} T_DATA;

ついでを言えば、flagの型もintよりboolの方がよいとは思うが。

0374341

2006/02/26(日) 00:20:42

>>372
SetTestがダサい。メソッド名から
・未使用のT_TESTを検索する
・それにi_numをセットする
と二つのことをしていることが読み取りにくい。（Testをセットしているんじゃないし）

0375341

2006/02/26(日) 00:23:31

やるならせめて
class test {
private:
  typedef struct {
    int flag;
    void setPoint(int i_num){
      point = i_num;
    }
  private:
    int point;
  }T_TEST　test1[10];
public:
  const T_TEST *getTest(int i_num){
    for ( int i=0; i<10; i++){
      if ( test1[i].flag == -1 ){
        return &test1[i];
      }
    }
    return NULL;
  };
};

Test test; // これはシングルトンで扱う
T_TEST *pTest = test.getTest();
if ( pNum != NULL ){  pTest->setPoint(10);}

くらいしなきゃ。コンパイルしてないしかなり詰めも甘いけど。

0376341

2006/02/26(日) 00:27:08

うわ、コピペ元間違ってんじゃん。

T_TEST *pTest = test.getTest();
if ( pTest != NULL ){ pTest->setPoint(10);}

だな。なんかいつの間にかパラメータも増えてるけど…。

0377デフォルトの名無しさん

2006/02/26(日) 00:36:21

>375
private:
int point;
}T_TEST　test1[10];
の部分なんですがこのところでメンバが多くなって10個ぐらい増えた場合に
単純にセッターを10個増やすことになると思いますがそれはC++では普通にやる
ことなんですか？

0378デフォルトの名無しさん

2006/02/26(日) 00:37:04

リファレンサ・クラスを作るだな

0379341

2006/02/26(日) 00:46:19

必要なら作るべき。けど普通そこまでにはならないと思う。
外部からset、getとか頻繁にし過ぎるようだったら設計が悪い。

あまり多くのメンバが追加されるようなら
T_TESTがする仕事が多すぎないかとか、
分割した方がいいか検討しなきゃな。

0380デフォルトの名無しさん

2006/02/26(日) 10:39:20

リファレンサ・クラスとはなんでしょうか？
検索でもあんまりひっかからないので教えて

0381cccc

2006/02/26(日) 10:47:51

VC６．０

アドレス、A、Bが分かっていて、AからBまでをファイルに書き出す方法は、
ありませんか？

0382デフォルトの名無しさん

2006/02/26(日) 10:57:28

>>381
copy((char*)A,(char*)B,std::ostreambuf_iterator<char>(stream));

0383デフォルトの名無しさん

2006/02/26(日) 12:31:12

stream.write((char*)A, (char*)B - (char*)A);

0384デフォルトの名無しさん

2006/02/26(日) 12:35:37

http://www.open-std.org/jtc1/sc22/wg21/
News 2006-02-26: The C++ Standard Library Issues List (Revision 41) is available (.tar.gz)
News 2006-02-26: C++ Standard Core Language Issues List (Revision 40) is available, also committee version

0385デフォルトの名無しさん

2006/02/26(日) 16:41:15

>>382-383
なんでわざわざわかりづらいコード書くんだよ。
VCって言ってるんだからWin32のAPI使えばいいだろ。
WriteFile(fileHandle, A, B-A, &bytesWritten, 0);

複雑なマクロが書けるとかテンプレートが使いこなせるとか、
マニアックなコードで短い行数で書ける奴が偉いなんて時代は
2002年頃までに終わってるんだよ。

0386デフォルトの名無しさん

2006/02/26(日) 16:46:22

ネタだよな？

0387デフォルトの名無しさん

2006/02/26(日) 16:46:46

>>385
お願いだからスレタイと>>1を読んでくれ。

0388デフォルトの名無しさん

2006/02/26(日) 17:13:32

>>385
たしかに382-383は不親切な回答だと思ったかもしれないが、
ここはC++のスレなんだからC++の標準ライブラリでの方法を答えるのが筋だろ。

0389デフォルトの名無しさん

2006/02/26(日) 17:38:47

明らかに>>381が>>1読んでないの分かってて書く>>382-383も
荒れる原因作ってるだけだろ。どのヘッダをインクルードすればいいのかとか
また質問しに来たらどうすんだか

0390デフォルトの名無しさん

2006/02/26(日) 17:55:43

何喧嘩してんだ
低能同士仲良くしろよ

0391デフォルトの名無しさん

2006/02/26(日) 18:01:04

>>390
よそのスレで馬鹿にされたからって
八つ当たりすんなよw

0392デフォルトの名無しさん

2006/02/26(日) 18:13:35

そうだね、仲良くしよう。>>390

0393デフォルトの名無しさん

2006/02/26(日) 18:26:03

よそのスレで馬鹿にされた低能==>>391

0394デフォルトの名無しさん

2006/02/26(日) 18:36:10

このスレもだんだん過疎化が激しさを増してきたからいいかげん

【C++】STL（Standard Template Library）相談室 4
http://pc8.2ch.net/test/read.cgi/tech/1130680264/

Boostを語れゴラァ part2
http://pc8.2ch.net/test/read.cgi/tech/1139313234/

今後、この２つをどうするか語らないか。

0395デフォルトの名無しさん

2006/02/26(日) 18:36:28

C++のオブジェクトをP2Pのような相互通信するオブジェクトと捉えて
プログラミングしようと思ってるんですが、ナカナカ上手くいかないっす（涙

基本的には、
1. 各機能オブジェクト間で状態遷移を通知し合う。
2. 各機能オブジェクトは上位のオブジェクトに保持されるが、上位のオブジェクトがすることは、各機能オブジェクトに、さらに上位から送られてきた命令を分散するだけで一切実際の処理はしない。するとしても初期値設定ぐらい。

boost::signalあたりで実装はしてみたんですがイマイチスマートに書けないんですよね。

…わけわからんこと言ってすいません。

0396デフォルトの名無しさん

2006/02/26(日) 18:42:41

>>394
STL スレは統合していいと思うけど Boost はなあ。
時期標準といっても案件によっては使わせてくれない場合も多いし・・・。

0397デフォルトの名無しさん

2006/02/26(日) 19:06:12

>>395
もうちょい「上手くいかない」の内容とか
各機能がなんなのか書けば誰か助けてくれるかもよ。

…>390みたいなやつも紛れ込んでるけどさ。

0398デフォルトの名無しさん

2006/02/26(日) 19:17:43

class Aの中でclass Bのインスタンスを一個だけ使うような場合ってどうしてますか？

class A {
B b;
};
ってするか、
class A {
A() {b = new B:}
~A() {delete b;}
B *b;
};
ってするか。
上の方が簡単だけど、Bのコンストラクタに引数があると困る。

0399デフォルトの名無しさん

2006/02/26(日) 19:20:27

はぁ？

0400デフォルトの名無しさん

2006/02/26(日) 19:20:42

>>394
BOOTSを語れゴラァ part2
http://pc8.2ch.net/test/read.cgi/tech/1139266461/

0401デフォルトの名無しさん

2006/02/26(日) 19:21:53

>>398
class A {
B b;
A() :b(...) { ... }
};

0402デフォルトの名無しさん

2006/02/26(日) 19:26:53

とりあえず最初はBが
・値オブジェクトなら先の方、
・参照オブジェクトなら後の方
でやっちゃうかな。まぁケースバイケースだけど。

0403402

2006/02/26(日) 19:39:46

ところで俺>341なんだけど、
>352の彼は問題解決したのかなぁ。

どうなったか書いてくれんと落ち着かない…

0404デフォルトの名無しさん

2006/02/26(日) 19:59:41

>>401
それってBがAの基底クラスじゃなきゃおかしくね？

0405デフォルトの名無しさん

2006/02/26(日) 20:01:09

>>404
ただのメンバの初期化の構文だが。

0406デフォルトの名無しさん

2006/02/26(日) 20:10:40

>>352は
test1の定義を、int *test1にして
コンストラクタでtest1 = new int[10];すればOK。
インスタンス1つならstatic int test1[10];でもいい。
セッタなんてﾏﾝﾄﾞｸｾ

0407デフォルトの名無しさん

2006/02/26(日) 20:36:46

バリアント型を使用したあとの、
メモリの解放ってどうやればいいんでしょうか？
なんか呼び出すたびにメモリ使用容量が増えている気が・・

0408デフォルトの名無しさん

2006/02/26(日) 20:39:16

#include <iostream>
#include <functional>
#include <boost/function.hpp>

struct SomeObject{
　void Do(int) { std::cout << "hogehoge" << std::endl; }
};

int main(){
　SomeObject t;
　boost::function<void (int)> g = std::bind1st( std::mem_fun(&SomeObject::Do), &t );
　g(0);
　return 0;
}

だとコンパイル通って、

struct SomeObject{
　void Do(void/* ここと */) { std::cout << "hogehoge" << std::endl; }
};

int main(){
　SomeObject t;
　boost::function<void (void/* ここと */)> g = std::bind1st( std::mem_fun(&SomeObject::Do), &t );
　g();/* ここを変更 */
　return 0;
}

だと通らなくなるんだけど…理由わかる人がいたら教えてもらえませんか？
環境はVC2005Express + boost 1.33.1です。

0409デフォルトの名無しさん

2006/02/26(日) 20:54:41

>>408
std::bind1stは二引数の関数オブジェにしか使えない。

0410デフォルトの名無しさん

2006/02/26(日) 20:55:01

bind1stは2引数の関数オブジェクトにしか使えないという糞設計だから。
boost::bindを使いましょう

0411デフォルトの名無しさん

2006/02/26(日) 21:00:58

>>409-410
マジthxですm(_ _)m
bind1stは二引数関数オブジェクト専用だったんですね（汗

一応動いたコード

#include <iostream>
#include <functional>
#include <boost/bind.hpp>
#include <boost/function.hpp>

struct SomeObject{
　void Do(void) { std::cout << "hogehoge" << std::endl; }
};

int main(){
　SomeObject t;
　boost::function<void (void)> g = boost::bind( std::mem_fun(&SomeObject::Do), &t);
　g();
　return 0;
}

0412デフォルトの名無しさん

2006/02/26(日) 21:10:52

>>411
-boost::function<void (void)> g = boost::bind( std::mem_fun(&SomeObject::Do), &t);
+boost::function<void (void)> g = boost::bind( &SomeObject::Do, &t);
でいいよ

0413デフォルトの名無しさん

2006/02/26(日) 21:14:27

>>412
本当だ、普通にコンパイル通った…。
mem_funまでやってくれるんだ…すごい…。

0414デフォルトの名無しさん

2006/02/26(日) 21:25:52

>409
オブジェﾜﾛﾀ

0415デフォルトの名無しさん

2006/02/26(日) 22:16:26

同じクラスであればunionを使うのは問題ありませんか？
座標を示すx,y,zという値があり、場合によってはdata[0]～[2]のように
配列っぽくアクセスしたい場合があります。
x,y,zはPOTではなく、関数なども持つクラスだとして、以下のように
unionを使うのはOKでしょうか？

union {
　{
　　foo data[3];
　};
　{
　　foo x,y,z;
　};
};

unionがメモリの内容を複数の解釈をするっていうものであるならば、
問題はない様な気がしますが。

0416デフォルトの名無しさん

2006/02/26(日) 22:28:58

>>415
構造体の各要素の配置は規定されてなかったと思う。
だからおそらくだめ。

0417デフォルトの名無しさん

2006/02/26(日) 22:34:52

>>415
配置以前に、規格上「コンストラクタを、デスクトラクタ、コピー代入演算子を定義したクラス型はunionのメンバにできない」となっているから、
基本的にはPOD型じゃないとダメかと。

0418デフォルトの名無しさん

2006/02/26(日) 22:55:26

>>415
foo data[3], &x = data[0], &y = data[1], &z = data[2];
あるいは
foo x, y, z, *data[] = { &x, &y, &z };
*data[0] のように * がつくが、
「配列っぽく」という要求は満たす

0419デフォルトの名無しさん

2006/02/26(日) 23:09:54

目的の為なら手段を選ばず。

struct
{
foo x,y,z;
foo& operator[](int i)
{
switch(i)/*以下略

0420プリプロセッサ

2006/02/26(日) 23:27:26

次は俺の出番か？

0421デフォルトの名無しさん

2006/02/26(日) 23:31:15

>>420
いや、俺だ。雑魚は引っ込んでろ。

0422デフォルトの名無しさん

2006/02/26(日) 23:39:34

>419
わりと普通じゃんと思ってしまう俺はもうJavaには移れませんか、そうですか

0423デフォルトの名無しさん

2006/02/26(日) 23:49:30

>>422
(･∀･)人(･∀･)

0424デフォルトの名無しさん

2006/02/27(月) 00:24:48

>415
名前にちょっとかっこが付くけど、普通にこんなんじゃ駄目か？
struct bar
{
foo data[3]
foo &x() {return data[0];}
略

0425デフォルトの名無しさん

2006/02/27(月) 00:30:34

俺なら>>424より>>419を選ぶ。

0426デフォルトの名無しさん

2006/02/27(月) 00:36:08

C++なら424でも十分

0427デフォルトの名無しさん

2006/02/27(月) 00:44:33

　　　　〃〃∩ 　_, ,_
　　　　　⊂⌒（　`Д´）　＜　だって括弧ヤダヤダ！
　　　　　　｀ヽ_つ ⊂ノ

0428デフォルトの名無しさん

2006/02/27(月) 00:50:06

そこで#define x x()で(r

0429デフォルトの名無しさん

2006/02/27(月) 00:59:28

ここで変態的なのを出してみる。

struct bar
{
foo x,y,z;
foo& operator[](int i)
{
static foo bar::* hage[] = {&bar::x,&bar::y,&bar::z};
return this->*(hage[i]);
}
};

0430デフォルトの名無しさん

2006/02/27(月) 01:01:17

あやまれ！
ツルッパゲのオッサンにあやまれ！

0431デフォルトの名無しさん

2006/02/27(月) 01:19:29

平成18年2月27日、2chム板C++相談室 part47スレッドを訪問した際、
ツルッパゲのオッサンの方に、私は不遜な対応をし、同氏の名誉を傷つけ、
またご迷惑をおかけしました。心よりお詫びいたします。

自身の軽率で傲慢な言動を恥じ、深く反省しております。

今後は、常に自分の立場をわきまえ、念頭に置いた行動をとりますことをお誓いいたします。
二度とこのような失態を招かない所存にございますゆえ、
このたびに限り、寛大なるご措置をお願い申し上げます。

0432デフォルトの名無しさん

2006/02/27(月) 01:24:09

>>431 の潔さに感動した！

0433デフォルトの名無しさん

2006/02/27(月) 01:28:21

>>429
const 忘れてるよ。付けても最適化してくんないみたいだけどね。

- static foo bar::* hage[] = {&bar::x,&bar::y,&bar::z};
- return this->*(hage[i]);
+ static foo bar::* const bjarne[] = {&bar::x,&bar::y,&bar::z};
+ return this->*(bjarne[i]);

0434・∀・）っ-○●◎- ◆Pu/ODYSSEY

2006/02/27(月) 01:29:53

タブクリア吹いたｗｗｗｗ

0435・∀・）っ-○●◎- ◆Pu/ODYSSEY

2006/02/27(月) 01:56:18

Cスタイルの初期化は出来なくなるがこんなのどう？

struct Point3D {
float &x, &y, &z;
float data[3];
Point() : x( data[0] ), y( data[1] ), z( data[2] ) { }
//以下略
};

0436デフォルトの名無しさん

2006/02/27(月) 01:57:48

>>435 デカくて嫌。

0437デフォルトの名無しさん

2006/02/27(月) 08:53:00

でも俺なら>>435にするけどなあ。
>>419, >>429のやつだと、
data[0], data[1], data[2]が順に等間隔で並ばない可能性があるから、
いつかハマりそう。

0438デフォルトの名無しさん

2006/02/27(月) 09:33:59

static int hoge[60]
みたいにstaticを使って動的にメモリを確保できないのでしょうか？

つまり
x=60;
static int hoge[x];
みたいなことがしたいんですが

0439デフォルトの名無しさん

2006/02/27(月) 09:45:35

>>438
staticがどの意味のstaticなのかわからん。

0440デフォルトの名無しさん

2006/02/27(月) 13:41:57

>>438,439
どの意味でも無理。

0441デフォルトの名無しさん

2006/02/27(月) 13:54:31

静的なのに動的とはこれいかに？

ソースコードを書き換え→コンパイラを起動→実行

0442デフォルトの名無しさん

2006/02/27(月) 15:15:03

>>440
ほんとだ。

C99の
> static int (*p_sum_h)[h] = sum_h; 　//OK static を使っているけどこれは OK
(http://seclan.dll.jp/c99d/c99d04.htmから引用）
と混乱してたよ。

0443デフォルトの名無しさん

2006/02/27(月) 16:40:58

どうも動作がむちゃくちゃおかしいので、一応確認しておきたいのですが

typedef struct{
　char* txt[16];
}TS, *LPTS;

void testcode( void ){
　TS ts;
　char* smptxt = "abcdefghijklmn";
　ts.txt[0] = smptxt;
　ts.txt[1] = smptxt;
　ts.txt[2] = smptxt;
}

みたいなコードで、ts.txt[0]への代入後、どうもts.txt[1]以降の内容も変化
変化した内容は[1]が0x68676665、[2]が0ｘ6ｃ6ｂ6a69とのことなので、
どうやらsmptxtの文字列が突っ込まれているようです
VC++2003の問題だとは思うのですが、もしかして何か俺の方でやっちゃってます？

0444デフォルトの名無しさん

2006/02/27(月) 16:56:38

>>443
なんだかわかんないのだけれども、
[0]のところにブレークポイントしかけて、
その時点で[1]と[2]の中身も変化してしまうということ？

0445デフォルトの名無しさん

2006/02/27(月) 17:02:16

>>443
そのテストコード、VC++2003で試してみたけど、正常に動作したよ。
(testcode(void)の最後にprintfで表示させてみた）
ts.txt[]の参照文字列を表示させても同じだし、ts.txt[]の指しているアドレスを
確認したけど同じだった。
別のところに問題があるんじゃないの？

0446443

2006/02/27(月) 17:23:29

>>444
その通りです
[0]への代入のところにブレークポイントを置いてチェックすると
[0]への代入時に[0]にはsmptxtのアドレス、[1]以降に変な値が入ってます
今確認してみたところ、[1]への代入、[2]への代入時には[1]以降のデータは変化してないっぽいです

>>445
うーん…
新しいプロジェクトで同じことやっても同じ結果が出てるんですよね…
（＝ビルドオプションの類の問題じゃなさそう）
となると、バージョンか開発環境の設定？

0447445

2006/02/27(月) 17:38:38

>>446
ちなみに、コンパイラのバージョンは最適化コンパイラで13.10.3077(for 80x86)
コンパイルは、コンソールからなにもオプションつけないで、clでやっている。
（コマンドラインアプリとして、mainくっつけて実行）

0448デフォルトの名無しさん

2006/02/27(月) 18:16:19

>>443
ts.txt[0]への代入直後、ts.txt[1], [2]の（初期化および）代入以前の状態だと
ts.txt[1], [2]の値は不定だから。

…なわけないよな…。
参考までに、g++3.4.2では、ts.txt[0]代入前後で[1], [2]の値に変化はなかったよ。

0449415

2006/02/27(月) 21:24:51

いろいろと参考になります。
クラスはunionにできないんですね。

x,y,zへのアクセスとdata[0]～[2]へのアクセスのコストが等しくなる
方法がいいんですが、>>419ならインライン展開されると見て大丈夫ですか？

初期化の際に多少コストがかかるのは問題ないです。

0450デフォルトの名無しさん

2006/02/27(月) 22:05:21

インライン展開されるかどうかなんて環境によるだろ

0451デフォルトの名無しさん

2006/02/27(月) 23:15:55

俺はVC++8.0に __forceinline を指定して、極力
インライン展開を使用するようにして使っているが、例えば>>435を
使っても使わない時と比べ5clockほどしか増えない。

0452デフォルトの名無しさん

2006/02/27(月) 23:18:26

5clockｗ

0453デフォルトの名無しさん

2006/02/27(月) 23:32:12

インライン関数はどうでもいいが、何でもかんでもvirtual付けたがる奴いるよな。
重いんだよ。絶対継承される自信があるときだけにしてくれ。

0454デフォルトの名無しさん

2006/02/27(月) 23:44:16

何も継承していないし、
どこからも継承されていないクラスは、
コンパイラの最適化で、virtualを外せないものなのかな。

というか、デフォルトでvirtualで、必要のないものだけ、
コンパイラが判断してvirtualを外すという仕様はどうだろう。

Dが確か、そういう仕様だったはず。

0455454

2006/02/27(月) 23:45:00

もちろん、継承されていても、virtualを外せる場合は結構あると思うんだけど。

0456・∀・）っ-○●◎- ◆Pu/ODYSSEY

2006/02/27(月) 23:47:28

問題はfloatごときに同じ数だけアドレス型の領域が増えるのが効率が悪すぎることだ。

0457デフォルトの名無しさん

2006/02/27(月) 23:51:51

>>454
その D の仕様では virtual テーブルまで消えるのか？
単に呼び出し時に virtual テーブルを経由せずに呼び出すことを
「virtualを外す」って言ってるだけじゃないの？
もしそれだけなら、 C++ でも最適化の範囲内で可能。

0458デフォルトの名無しさん

2006/02/27(月) 23:57:47

>>454
Dの仕様書ではこうなってた。
>コード生成時にDはクラス階層を全て把握していますので、
>オーバーライドされていない関数への呼び出しは全て最適化されて non-virtual になります。

こういう言語ではvtableは常に作るのかな。デストラクタは常にオーバーライドされるし。

0459454

2006/02/28(火) 00:26:42

C++は、やはり速度優先といった感じがしますね。

自分の考えとしては。

vtableがあるというだけでは、vtable分のサイズと、
vtableへの参照だけなので、

int型のメンバ変数ひとつのクラスを何十万と作るわけじゃなければ、
別に気にしなくてもいいんじゃないか、などと思えてしまいます。

それでも、JAVAや.NETまで、思い切ることができない性格ですが。

0460デフォルトの名無しさん

2006/02/28(火) 01:37:56

はじめまして、現在VC++2003を用い開発をしているのですが、
Win32コンソールアプリケーションからWin32DLLを動的に明示リンクした際に、
なぜかReleaseでのみ問題が発生します。

DLL側は
__declspec(dllexport) int LL_OpenArchive(LPCTSTR szFilePath)
{
return s_osaArcEx.OpenArchive(szFilePath);
}
の様に宣言しており、もちろん定義ファイルでエクスポートを定義しております。

アプリケーション側は
typedef int (__stdcall *LL_OpenArchive)(LPCTSTR);
の様にプロトタイプ宣言を行いLoadLibary,　GetProcAdressを用い関数のアドレスを取得しています（そこまでは問題有りません）

取得した関数に引数としてchar s[512]の様な固定長CHAR配列にgetsで文字列を取得したものを当てています。
が、Releaseビルドでその処理を行うと、sのアドレスが4バイト引かれるのです。Debugではおこりません。
ためしにDLL側の関数の中身をreturn 0;のみにしたりもしましたが状況は変わりませんでした。
このようなことはあり得るのでしょうか？
またどう対処すればよろしいのでしょうか？　ご教授お願い致します。

0461デフォルトの名無しさん

2006/02/28(火) 01:43:29

>>460
よくある。対策は↓
コンパイラの、プログラム全体の最適化 (/GL) を一回はずしてリビルド。
終わったらもう一回有効にして再度リビルド。

0462デフォルトの名無しさん

2006/02/28(火) 03:54:49

誰かが言わなくちゃいけないから俺が言う。
>460
回れ右して初心者スレかWin32APIスレにGo!

0463デフォルトの名無しさん

2006/02/28(火) 03:59:37

>454
お前のちっぽけな価値観だけで、
偉大なるC++をどうこうしたいと妄想するなんて片腹痛い。

0464デフォルトの名無しさん

2006/02/28(火) 05:45:17

宣言だけが記述されたヘッダと、（実装をコンパイル済みの）オブジェクトファイルしかない状況でも
virtualは付け外しできるのかな。
そのオブジェクトファイルは、他の（CやFortranなどの）言語でも使用される一般的なツールでリンクできるという条件で。
可能なら、継承されててもnon-virtualにできる選択肢を残した上で、virtualは自動化してもらえれば便利だね。

0465デフォルトの名無しさん

2006/02/28(火) 07:03:11

>>463
そういうのは北朝鮮でやってね（ﾌﾟ

0466デフォルトの名無しさん

2006/02/28(火) 08:02:45

C++の本でいいのはどれでしょう？
ASCIIの「C++言語入門」は持ってますが古い規格なので
最近新しく探しているのですが、これはと思ったのは分厚く
7000円もするので買うのを躊躇しています。
リッチー＆カーニハンの「プログラミング言語C」のような
解説書を探しています。
よい本がありましたら教えてください。

0467デフォルトの名無しさん

2006/02/28(火) 08:12:18

>>466
プログラミング言語C++がC++版K&Rと言われてる

俺が他にお勧めするのは、Accelerated C++
後はもう店頭在庫のみだがEffective C++

0468デフォルトの名無しさん

2006/02/28(火) 09:10:58

>>466
古い規格での標準C++の勉強は終わっていて、7000円は高すぎて禿げてしまうというのなら
標準規格はIS、FDIS（>>5）を参照するという手もある。

0469デフォルトの名無しさん

2006/02/28(火) 09:14:23

>>460
スレ違いだがあえて答えてやろう。
エクスポートしてる関数にも_stdcall付けやがれ。

0470460

2006/02/28(火) 11:04:01

スレ違いだったにもかかわらず教えて頂きありがとうございました。
結果的には__stdcallのつけ忘れでした
初歩的orz
相談室と書いてあったので早とちりしてしまいましてご迷惑おかけしました。
ありがとうございました。

0471デフォルトの名無しさん

2006/02/28(火) 12:16:14

>>454
多くの C++ コンパイラはコンパイル単位でしか最適化しないので
そーゆー、複数のコンパイル単位間での最適化は
望むべくもなく。

0472466

2006/02/28(火) 21:12:31

>>467-468
ありがとうございます。
教えていただいたタイトルを頼りに本屋を渡り歩いてみます。

レスが遅くなりましてすみませんでした。（今帰宅しました）
International Standard は詳しくて良さそうですね。
あんまり英語得意じゃないんですが、日本語版の本を購入
するまでは頑張ってこちらで勉強してみます。

0473デフォルトの名無しさん

2006/02/28(火) 22:40:46

>>472
標準規格を見るだけならhttp://www.jisc.go.jp/のJIS検索から規格番号X3014でいける。

0474デフォルトの名無しさん

2006/02/28(火) 23:31:34

C++でBCDを使うためのノウハウみたいなのが紹介されてる本やサイトってありますかいね？

0475デフォルトの名無しさん

2006/03/01(水) 01:11:46

Google からたどり着いたこのアドレス
http://www.open-std.org/jtc1/sc22/wg21/prot/
規格とかダウンロードできて、便利だなｰとか思ってたんだけど、
よく見るとトップに "members' pages" って書いてある。

これ、ダウンロードしてもいいの？

0476デフォルトの名無しさん

2006/03/01(水) 01:20:26

>>475
内部向け　ってだけで「会員専用」の意ではない。

0477デフォルトの名無しさん

2006/03/01(水) 02:26:40

根っからのtemplate hackerの俺としては今後コンソールアプリを作るとき以下のようにmainを書こうと思うのですが、おまえらやC++規格的にはアリですか?
とりあえずVC++2005EE的にはアリのようです

#include <iostream>
#include <typeinfo>

template<class char_t> int main(int argc, char_t* argv[])
{
　　std::cout << typeid(char_t).name() << std::endl;
　　return 0;
}

namespace startup{
//int main(int argc, char* argv[])　コメントアウトとかして切り替える
//{
//　　return main<char>(argc, argv);
//}

int wmain(int argc, wchar_t* argv[])
{
　　return main<wchar_t>(argc, argv);
}
}

mainとかwmainをnamespaceとかにいれてｲｲﾉｶﾅｰ

0478デフォルトの名無しさん

2006/03/01(水) 02:39:51

>>477
#if defined(UNICODE) とかで切り分けろバカｗ
あと、main や wmain はnamespaceいれちゃダメ。

0479デフォルトの名無しさん

2006/03/01(水) 10:06:07

>>478
UNICODEって標準じゃなくてWindowsSDKで使われてる識別子じゃなかったっけ?

0480デフォルトの名無しさん

2006/03/01(水) 14:12:17

>>479
そうだけど、_UNICODEだって独自のものだから、どっちもどっち。

0481デフォルトの名無しさん

2006/03/01(水) 16:14:49

UNICODE も _UNICODE も何のことだか分からない俺。

0482デフォルトの名無しさん

2006/03/01(水) 19:35:23

てか、windows 以外で wchar_t ベースの main に対応してる環境なんてあんのか？

0483デフォルトの名無しさん

2006/03/01(水) 19:53:32

struct base {
　base() {}
　virtual ~base() {}
};

template <typename T> struct derived : public base {
　typedef T member_type;
　T value;
　derived(T value) : value(value) {}
};

template <typename T> base* derived_generator(T value) {
　return new derived<T>(value);
}

base* tmp = new derived_generator(1);

このとき、tmpからmember_typeがintであることを知る方法はないじゃろうか…。

int value = dynamic_cast<derived<int>*>(tmp)->value;

とすればvalueはとれるんじゃが、型がintだと明示したくないのじゃ。

TYPE obtain() const { return dynamic_cast<derived<TYPE>*>(tmp)->value; }

このTYPEはderived<TYPE>::member_typeと等しいのじゃが、どうにかして取り出せんもんかのう。
爺にはとんと見当がつかんのじゃ…。

0484デフォルトの名無しさん

2006/03/01(水) 19:54:54

base* tmp = derived_generator(1);
じゃった。書き写さずコピペすればよかったのう…。

0485デフォルトの名無しさん

2006/03/01(水) 19:58:51

爺さん，無理だと思うよ．
member_typeの型情報が必要な処理はderivedの中に入れるしかないよ

0486デフォルトの名無しさん

2006/03/01(水) 20:02:38

>>483-484
それができないからこそ、boost::anyにはany_castがあり、次期C++にはautoが導入される

0487デフォルトの名無しさん

2006/03/01(水) 20:06:38

あるいは型情報を外に出すとか
typedef int My_Type;
struct base {
base() {}
virtual ~base() {}
};
template <typename T> struct derived : public base {
typedef T member_type;
T value;
derived(T value) : value(value) {}
};
template <typename T> base* derived_generator(T value) {
return new derived<T>(value);
}
typedef derived <My_Type> My_Derived;
int main ()
{
base* tmp = derived_generator(1);
My_Type value = static_cast<My_Derived*>(tmp)->value;
return 0;
}
爺さんこんなのはどうだい？

0488デフォルトの名無しさん

2006/03/01(水) 20:13:19

>>486
これはautoで解決できる問題じゃないと思う。

0489デフォルトの名無しさん

2006/03/01(水) 20:22:00

autoで思い出したんだが、auto型のメンバ変数は許可されるのだろうか？
その辺詳しい人いたら教えてけれ(´･ω･`)

struct Hoge {
　　auto value_;

　　template <class T>
　　Hoge(T v) : value_(v) {}
};

こんな構造体を書いた時、
Hoge h(int(10)), h(double(1.0));
な風に使ってしまうと、テンプレートのようにHogeに複数の実体が作られるのかどうか…

0490デフォルトの名無しさん

2006/03/01(水) 20:24:51

暗黙の型変換付のboost::anyとか

struct base{
    struct inner_base{
        virtual inner_base*clone(){return new inner_base;};
        virtual ~inner_base(){}
    };
    template<typename T>
    struct inner_derived : inner_base{
        typedef T member_type;
        T value;
        inner_derived(const T&value):value(value){}
        inner_derived*clone(){return new inner_derived(value);}
    };
    inner_base*value;
    template<typename T>base(const T&value):value(new inner_derived<T>(value)){}
    base(const base&value):value(value.value->clone()){}
    base&operator=(base b){swap(b);return *this;}
    base():value(new inner_base){}
    ~base(){delete value;}
    void swap(base&b){inner_base*p=value;value=b.value;b.value=p;}
    template<typename T>operator T&(){return dynamic_cast<inner_derived<T>&>(*value).value;}
};
#include<iostream>
int main(){
    base tmp=1;
    int value = tmp;
    std::cout << value;
}

0491デフォルトの名無しさん

2006/03/01(水) 20:46:37

>>485-490
爺に教えてくれて感激じゃ…。じゃが、やはり標準C++では無理なことかのう。

>>487のようにしてしまうと、

derived_generator(1);

この関数テンプレートは、引数の型を判別して derived<int> のインスタンスを生成するのに
別の場所でintだと明示しないとならないのは厳しいのう。

と思うたら

>>490
これはすごいことじゃ…天狗じゃ…天狗が現れおった…！！
爺の用途には暗黙の型変換でも十分じゃ。じっくり読むだえ。

0492デフォルトの名無しさん

2006/03/01(水) 21:09:45

>>489
要らないと思う。
クラステンプレートとそれを生成するテンプレート関数でいいだろ。

0493デフォルトの名無しさん

2006/03/02(木) 18:45:41

class HogeState;
void change( HogeState* new_state );

class HogeState{
　int ahe, uha;
public:
　void foo(){
　　change( new HogeState );
　　ahe = 777;
　}
　void foo2(){
　　ahe = 888;
　　change( new HogeState );
　}
};

HogeState* state = 0;
void change( HogeState* new_state ){
　if( state ) delete state;
　state = new_state;
}

int main(){
　HogeState hoge;
　hoge.foo();
　hoge.foo2();
　return 0;
}
foo()では、自分がdeleteされた後にaheに代入し、しかもエラーが出ませんが、これはOKなんでしょうか？
foo()が駄目だとしたら、foo2でも危うい気がするのですが、実際どうなんでしょう。

無理矢理1ファイルに書いたら意味のないコードになってしまいました。ご容赦を。

0494デフォルトの名無しさん

2006/03/02(木) 18:54:01

>>493
> change( new HogeState );
newで新しく確保して、それを渡しているだけ。hoge関係なし。
> if( state ) delete state;
deleteにNULL渡しても問題ないからif(state)は意味ない。
deleteで開放しているのはさっき新しく確保したHogeStateであってhogeではない。
> state = new_state;
仮引数に代入した所で意味はない。

なんか大混乱コードだなぁ。

0495493

2006/03/02(木) 19:18:19

本当だ、なんだこれは…。申し訳ないです、元はこんなのでした。
class Hoge{ //Hoge.h--------------------------------
　HogeState* state;
public:
　Hoge(){ state = new HogeState; }
　void changeState( HogeState* new_state ){ delete state; state = new_state; }
　void foo(){ state->foo( this ); }
　void foo2(){ state->foo2( this ); }
};
class Hoge; //HogeState.h---------------------------
class HogeState{
　int ahe;
public:
　void foo( Hoge* hoge );
　void foo2( Hoge* hoge );
};
#include "HogeState.h" //HogeState.cpp---------------
#include "Hoge.h"
void HogeState::foo( Hoge* hoge ){
　hoge->changeState( new HogeState );
　ahe = 777;
}
void HogeState::foo2( Hoge* hoge ){
　ahe = 888;
　hoge->changeState( new HogeState );
}
#include "HogeState.h" //main.cpp--------------------
#include "Hoge.h"
int main(){
　Hoge hoge;
　hoge.foo(); hoge.foo2();
}

0496デフォルトの名無しさん

2006/03/02(木) 19:24:20

>494
仮引数？

> さっき新しく確保したHogeState
ちがわね？

0497デフォルトの名無しさん

2006/03/02(木) 19:44:44

>>495
> ahe = 777;
deleteされたインスタンスに対してメンバ変数に変更を加えてるのでダメ

> ahe = 888;
deleteされる前に触ってるからOKだけど
直後のchangeStateで触ったインスタンスはdeleteされるので意味なし

じゃないかな？

0498493

2006/03/02(木) 19:50:12

497さんレスありがとうございます。
デリート済みインスタンスの関数であっても、
メンバにアクセスしなければ大丈夫、という結論でよろしいのでしょうか。

メンバ関数であっても、所詮は関数という感じでよさそうなのですね。

0499デフォルトの名無しさん

2006/03/03(金) 03:24:13

エラー・例外が出ないから大丈夫、というのは個人的にはあんまり好きではないな。
メンバ関数にはthisポインタが渡されるだけで、あとは確かに通常の関数とほぼ同じだが
thisポインタが無効になった時点でそれ以上そのクラスオブジェクトは仕事を続けるべきではないと思う。

0500475

2006/03/03(金) 03:43:39

今アクセスしたら認証要求が出たよ・・・
やっぱりダメだったんだろうな。

0501デフォルトの名無しさん

2006/03/03(金) 15:57:56

このスレに書いたからだろｗ

0502デフォルトの名無しさん

2006/03/03(金) 16:45:00

std::exceptionやstd::runtime_error等の例外クラスの
wchar版はなぜ提供されないのでしょうか？
std::wexceptionとかstd::wruntime_errorとか

0503デフォルトの名無しさん

2006/03/03(金) 17:30:43

>>502
俺はwcerrなんかのワイド文字ストリームがマルチバイト文字へ変換する仕様だからだと思っている。
その変換処理の最中に例外を投げたくなるようなことになったら、どうしようもなくなるだろうと。

0504デフォルトの名無しさん

2006/03/03(金) 18:03:36

単純に、例外の中で例外を投げればって思った俺は駄目ですか？

0505503

2006/03/03(金) 18:34:00

>>504
俺は例外が発生している最中に例外が投げられることを問題に思っているのではなく、
エラーメッセージが表示できないことだと思っている。

もちろん画面への表示という行為も失敗するかもしれないけどさ。

0506デフォルトの名無しさん

2006/03/03(金) 20:57:48

>>502
wchar_t 版がない理由は知らんが、char版でもUTF-8をブチ込むことは許されてるからそれで我慢汁カウパー。

0507デフォルトの名無しさん

2006/03/04(土) 00:28:50

コンストラクタは、protectedに,
デストラクタは、virtual で public に
というクラス定義がありますが、これは
どういう理由でこのようにしているのでしょうか？

0508デフォルトの名無しさん

2006/03/04(土) 00:33:03

>>507
インターフェースとして使うように設計されていて、
実際に new などで生成されるのは派生クラスだけ
ということが想像できるが、作った奴に聞いてコメント書かせるのが正解。

0509デフォルトの名無しさん

2006/03/04(土) 00:33:19

>>507
継承して使え。と書いた人が主張している。

0510デフォルトの名無しさん

2006/03/04(土) 00:34:14

>>507
コントラはそのクラス変数の作成時に呼ばれる関数だから
作成されていないのに外部から勝手に呼ばれたら困る。だからプロテク。
デストラはそのクラス変数が破棄されるときに呼ぶものだが
途中で破棄したい場合に外部から呼ぶため。だからパブリ。

0511デフォルトの名無しさん

2006/03/04(土) 00:35:36

>>510 ｷﾓｲ

0512デフォルトの名無しさん

2006/03/04(土) 00:59:17

static なメンバ関数内で new するというパターンなんかもあるよ。

0513デフォルトの名無しさん

2006/03/04(土) 01:12:05

>>512
事前条件が厳しいときのファクトリーパターンであってますか？

0514デフォルトの名無しさん

2006/03/04(土) 01:20:45

>>512
それだとコンストラクタは private だろ。

0515デフォルトの名無しさん

2006/03/04(土) 01:56:15

もしかして、時代はwchar_tが普通で、
const char *とか書いてる自分は駄目なんじゃないか
と怖くなる今日この頃、皆様はいかがお過ごしでしょうか？

0516デフォルトの名無しさん

2006/03/04(土) 02:21:47

vc8からはデフォルトでwchar_tだしな(UNICODE, _UNICODE)

0517デフォルトの名無しさん

2006/03/04(土) 03:38:58

まだ使ったこと無いんだけど、vc8ではsizeof(wchar_t)っていくつなの？

0518デフォルトの名無しさん

2006/03/04(土) 03:40:42

( ﾟдﾟ)ﾎﾟｶｰﾝ

0519デフォルトの名無しさん

2006/03/04(土) 08:36:01

>>517
WindowsがUTF-16を使っているので、Windowsの処理系ではまず間違いなくsizeof (wchar_t)は2です。

0520デフォルトの名無しさん

2006/03/04(土) 13:08:53

>>519
さんくす。

sizeof(wchar_t)を4にするオプションがないかと期待したんだけど。
wchar_tを使っても可変長エンコーディングからは逃れられないのか。

0521デフォルトの名無しさん

2006/03/04(土) 14:10:37

>>520
仕様：「本ソフトウェアはサロゲートペアに対応していません。将来的にも対応する気はありません。」

0522デフォルトの名無しさん

2006/03/04(土) 14:55:52

>>519-520
確か、CodeWarriorなら Windows でも 4 == sizeof(wchar_t) だよ。

0523デフォルトの名無しさん

2006/03/04(土) 16:00:14

>>521
サロゲートペアが理解できないユーザーからクレームが来るくらいなら、
可変長エンコーディングを我慢したほうが精神衛生上良いかと。

>>522
クロス開発環境だからWindowsアプリは作れないけど、ってオチ？

0524デフォルトの名無しさん

2006/03/04(土) 16:49:18

>>522
フツーにWindowsアプリが作れますがなにか？

0525デフォルトの名無しさん

2006/03/04(土) 16:58:56

>>524
ttp://www.metrowerks.co.jp/information/2005/info0323.html

0526デフォルトの名無しさん

2006/03/04(土) 17:10:21

>>525
いや、そんくらい知ってるって。

0527デフォルトの名無しさん

2006/03/04(土) 17:29:40

販売終了、サポート終了の製品を紹介されて、どうすれば？

0528デフォルトの名無しさん

2006/03/04(土) 23:48:49

おまいら書くとき何使ってる？
俺まぢでメモ帳。

0529デフォルトの名無しさん

2006/03/04(土) 23:50:34

>>527
そんなのもお構いなしで押し付けるのが信者という物です。

0530デフォルトの名無しさん

2006/03/05(日) 00:22:16

>>528
xyzzy。とても快適。

0531デフォルトの名無しさん

2006/03/05(日) 00:24:16

>>528
VSのIDEマンセー！
まあ、もうすこしインテリセンスがインテリになればいいんだけど。

0532デフォルトの名無しさん

2006/03/05(日) 00:27:34

簡単な実験をするときはxyzzyで書いてcl
普段はVSのIDE
味気ないなぁ

0533デフォルトの名無しさん

2006/03/05(日) 00:29:37

VS8重すぎ・・・
ファイル閉じるのに5秒くらいかかるよ・・・
複数ファイル一気に閉じると1分以上待たされる

というわけで、xyzzyに一票

0534デフォルトの名無しさん

2006/03/05(日) 00:33:18

流石に１分はまたないが、起動と終了に時間が掛かる。

0535デフォルトの名無しさん

2006/03/05(日) 00:37:30

2005は糞重いね

0536デフォルトの名無しさん

2006/03/05(日) 00:39:09

ただ、2回目からの起動が2003に比べて早くなってるね。
逆に言えばメモリに常駐してる部分が大きいってことかね。

0537デフォルトの名無しさん

2006/03/05(日) 00:41:53

>>536
ハァ？

ドトネトで、ネイティブコードのキャッシュが残るから、
二回目から起動が早くなるんだろう。

0538デフォルトの名無しさん

2006/03/05(日) 01:16:24

急ぎ働きのときはcat、
ちょっと編集するときはvi、
腰据えて作業するときはXyzzy、
他人に見せるときは桜エディタ。

0539デフォルトの名無しさん

2006/03/05(日) 01:24:55

スレ違いの流れに疑問を口にしないお前らに失望

0540デフォルトの名無しさん

2006/03/05(日) 01:25:45

＞他人に見せるときは桜エディタ。
なぜなんだか、とても気になる

0541デフォルトの名無しさん

2006/03/05(日) 01:27:27

>>539
そうだよな
お前らマでやれよ

emacs

0542デフォルトの名無しさん

2006/03/05(日) 01:33:22

ﾜﾛｽｗｗ

0543デフォルトの名無しさん

2006/03/05(日) 01:58:12

>>539
だって過疎化が進んで寂しんだもん。

0544デフォルトの名無しさん

2006/03/05(日) 02:00:12

std::mem_fun()の使い方が今一よく判らん。
って話はSTLスレ向きかな。

>>540
Xyzzyはフォントを小さくしているしタブや2バイト空白が見える設定にしているから
他人には(特に老眼入ってる連中には)激しく読みにくいらしいから。
どうせ普段使わないからってことで、キーワードの色付けも自分の好みよりも派手にしてある。

0545デフォルトの名無しさん

2006/03/05(日) 05:59:12

ある構造体型が定義されているのですが、
そこには

typedef struct tagStructName : public tagHogehoge{ /* tagHogehogeは構造体です */

public:
tagStructName(){};

void memberFunction();
}

などとありました。構造体の継承？何それって状態なんですが
考え方としてはクラスと同じ考え方でいいんですか？

0546デフォルトの名無しさん

2006/03/05(日) 06:02:15

良い

0547デフォルトの名無しさん

2006/03/05(日) 06:03:32

おｋ

すみませんでした

0548デフォルトの名無しさん

2006/03/05(日) 13:03:20

産みの親の発音を教えて

0549デフォルトの名無しさん

2006/03/05(日) 13:28:28

そんな無理に話題作らなくてもいいから

0550デフォルトの名無しさん

2006/03/05(日) 13:43:43

>>548
釣られておく。
ttp://public.research.att.com/~bs/bs_faq.html#pronounce

0551デフォルトの名無しさん

2006/03/05(日) 14:09:10

テンプレの[禿 Stroustrup]ってのみて
秀丸の人が開発者コミュニティでも作ったのかなと思ったじゃねーか

0552デフォルトの名無しさん

2006/03/05(日) 14:54:56

>>551
たった今>>5のページ初めて開いて禿の意味がわかったｗｗｗ

0553デフォルトの名無しさん

2006/03/05(日) 15:11:24

ちなみに他には
ハーブサッター＝髭
メイヤーズ先生＝ふさふさ
と言われている
覚えておくといいぞ

0554デフォルトの名無しさん

2006/03/05(日) 16:48:17

質問です。XP、VS8 です。

変数が静的か動的かを調べる方法はないでしょうか？
具体的には、以下のようなことがしたいと思ってます。

list<int *> List;

// 静的な変数を追加
int a=0;
List.push_back(&a);

// 動的な変数を追加
int* b = new int(0);
List.push_back(b);

// 全開放
list<int *>::iterator itr;
for (itr=List.begin(); itr!=List.end(); itr++)　{
　if ( (*itr) が動的に確保された変数 )
　　delete (*itr);
}

List.clear();

よろしくお願いします。

0555デフォルトの名無しさん

2006/03/05(日) 16:49:15

標準にはないな。

0556554

2006/03/05(日) 17:15:41

設計を見直すしかないでしょうか・・・。
ありがとうございました。

0557デフォルトの名無しさん

2006/03/05(日) 17:20:12

そんなことしたくなる状況がわからん

0558デフォルトの名無しさん

2006/03/05(日) 17:28:42

>>554
動的な変数へのポインタのみを保持したコンテナをListとは別に作って
deleteはそちらのコンテナのイテレータを介して行うとか？

0559デフォルトの名無しさん

2006/03/05(日) 17:41:23

すみませんが少々お力添えをいただけますでしょうか。

コンパイラはVC8で, cl code.cppとコンパイルしています。

現在とある画像ファイル形式(パレット方式、\0をランレングス圧縮)を
BMPに変換するコードを書いているのですが、

byte *cdata = new byte[ihead.length];

ifs.read(reinterpret_cast<char*>(cdata),ihead.length);

if(!ifs){
　　cout << "file read failed" << endl;
　　return 0;
}
string data = Decode(cdata,ihead);　// \0をデコード

delete[] cdata;

この流れで ihead.length==655 にもかかわらず、
ifs.tellp() で読み込みバイト数を調べると、 7000 バイトも読み込んでいるようなのです。
Decode 内で cdata を全て表示させて、ファイルと比較してみたところ、
読み込み位置が 639 バイト目から突然 4000 バイト以上後方にジャンプしていました。

seekg したわけでもないのに read 中にファイル読み込み位置がずれることはあるんでしょうか。

0560デフォルトの名無しさん

2006/03/05(日) 17:42:10

>>554
operator new / deleteのオーバーライドで
ヒープオブジェクトの一覧を作っちゃうとか。

まあ、そこまでするのもあれだけど。

0561デフォルトの名無しさん

2006/03/05(日) 17:44:16

>>554
おとなしいところで、フラグを使うとか。

typedef pair<bool/* dynamic? */, int *> flag_ptr;
list<flag_ptr> List;

// 静的な変数を追加
int a=0;
List.push_back(flag_ptr(false, &a));

// 動的な変数を追加
int* b = new int(0);
List.push_back(flag_ptr(true, b));

// 全開放
list<flag_ptr>::iterator itr;
for (itr=List.begin(); itr!=List.end(); itr++)　{
　if (itr->first)
　　delete itr->second;
}

List.clear();

0562デフォルトの名無しさん

2006/03/05(日) 17:44:53

>>559
バイナリモードで開いてないとか

0563デフォルトの名無しさん

2006/03/05(日) 17:45:36

>>560
Effective C++だとそれだったな。
>>559
画像ファイル等等の話は余計じゃね？

0564559

2006/03/05(日) 17:50:03

>>562
お早い返信ありがとうございます。
std::ios::binaryを指定したら、嘘のように成功しました。
お騒がせしました。

>>563
お恥ずかしながら、原因がまったく見当がつかなかったので……。
今思うと処理の内容は関係なかったですね。申し訳ありませんでした。

0565デフォルトの名無しさん

2006/03/05(日) 18:02:44

VisualStudio.NET　ATL/WTL　で開発しています。

バイナリから、JScriptの関数を呼びだすコードを書いております。
関数の呼び出しはできるのですが、JScript上の関数に引数を渡さなければいけない
場合に、どのように渡せばよいかわからないことがあります。

現在はまっているのは、JscriptのArray型です。
SAFEARRAY で CComVariantに渡してみましたが、

JScript上の関数内で、Arrayのlengthプロパティを使用できませんと
言われてしまいます。

この場合は、どのように渡せばよいのでしょうか？
また、　参考になるようなページはありませんでしょうか？

JScriptの関数呼び出しには、Invokeを使用しています。

よろしくおねがいします。

0566デフォルトの名無しさん

2006/03/05(日) 18:33:23

なんでスレ違いに気がつかないかな。
つhttp://pc8.2ch.net/test/read.cgi/tech/1134388951/

0567565

2006/03/05(日) 19:30:23

すみません。　ATL/WTL　スレに書いてきます。

0568デフォルトの名無しさん

2006/03/05(日) 21:37:45

ある class A があります
この class を引数で受け取る関数があります

void func( const set< A >& va );

この関数の中で、それぞれのAのインスタンス用に一時的な記録領域を設けたいんです。
引数にはconstで受け取りますから、class定義に含めることは出来ません。
解法として2つ考えたんですが、どっちもベストな方法には思えません。
皆さんならどう実装しますか？

1. mapを使う
map< A*, A_Temp > tempMap;
A_Temp at = *temp.find( &*va.begin() ).first;

2. class A に作業領域を含める
class A{
public:
void* pTemp;
...};

A_Temp at = (A_Temp*)va.begin()->pTemp;

0569デフォルトの名無しさん

2006/03/05(日) 21:48:49

>>568
func内で完結するデータなら1。
Aのインスタンスのある限り必要なデータなら2。

1だとしたらポインタでなくconst_iteratorをキーにすればよいと思う。

0570デフォルトの名無しさん

2006/03/05(日) 21:52:38

>Aのインスタンス用に一時的な記録領域
この意味がわからないんだが。具体的な例きぼん。

0571デフォルトの名無しさん

2006/03/05(日) 22:12:35

>>569
例えば、funcの中で、AとTempAの情報を受け取るfunc1を呼ぶとすると
func1の定義は以下のようになってしまい、なんだか複雑さが伝播してしまいます。
元々の設計が悪いのでしょうか？

void func1( const set< A >& va, map< A*, A_Temp >& tempMap );

>>570
何でもいいんですが、例えばプリンタの情報を収めるクラスがあるとします。

class Printer;

void main(){

Printer p;

// ユーザがPrinterオブジェクトに対しいろいろな操作を行う
p.set_XXX();
p.method_XXX();

// ・Printerの集合を受け取るfunc関数があるが
// この関数は、Printerに対し直接的な変更を加える訳ではないので
// const属性で受け取りたい
// ・内部では、ソートなど集合に対し操作を行うので
// 個々のインスタンスに関連付けされた領域が必要
set< Printer* > setp;
setp.insert( &p );
func( setp );

};

0572デフォルトの名無しさん

2006/03/05(日) 23:08:28

class PrinterWithSomeInfo{
public:
PrinterWithSomeInfo(const Printer *printer) : printer_(printer) {}
const Printer *getPrinter() const {return printer_;}

private:
const Printer *printer_;

[その他必要ないろいろ]
};
のsetを渡すとか。

0573デフォルトの名無しさん

2006/03/05(日) 23:33:56

void func(const set<A>& va);
じゃなくて
void func(set<const A>& va);
にしたいって話？

0574デフォルトの名無しさん

2006/03/05(日) 23:53:55

>>572
それでいってみます。
ありがとうございます。

>>573
そうですね、
その他いろいろ間違ってます。
こういう適当な性格なんで、PGには向いてないです。

0575デフォルトの名無しさん

2006/03/05(日) 23:54:59

ソートしたいだけなら、それでおｋな気がするね。

0576デフォルトの名無しさん

2006/03/06(月) 00:02:47

すみません。
試す前に聞いておきたいのですが、

テンプレートな、可変引数の関数というのは作れるのでしょうか？

template <typename T>
void func(T t, ...)
{

0577デフォルトの名無しさん

2006/03/06(月) 00:03:39

>>576
それ、そのまんまでなにも問題はありませんが、なにか？

0578デフォルトの名無しさん

2006/03/06(月) 00:04:33

> 試す前に聞いておきたいのですが、

シネヨ

0579576

2006/03/06(月) 00:04:40

>>577
作れるのですか。
ありがとうございます。早速試します。

0580デフォルトの名無しさん

2006/03/06(月) 00:10:00

(ﾟдﾟ)

0581デフォルトの名無しさん

2006/03/06(月) 00:15:09

(ﾟ д ﾟ)

0582デフォルトの名無しさん

2006/03/06(月) 00:16:23

ヘッダファイルで

template<typename T>
class A {
void func(const T& );
}

のように宣言したメソッドfuncをcppファイルで実装しようとするとうまくいかないんだけど、
そもそもできないものだったりします？

template<T>
void A<T>::func(const T& ){}
だと、外部からコールしたときに
外部参照が未解決だとコンパイラに怒られてしまう。

0583デフォルトの名無しさん

2006/03/06(月) 00:18:45

他でも使うtemplateは全部ヘッダに書きなされ

0584デフォルトの名無しさん

2006/03/06(月) 00:20:26

>>582
標準仕様に、完璧に準拠したコンパイラならいける。

つまり、exportキーワードを使えばいい。
まあ、VCもGCCもサポートしていないわけだが。

0585デフォルトの名無しさん

2006/03/06(月) 00:25:41

>>583-584
ありがとうございます。
大人しく全部ヘッダに書きます。

0586デフォルトの名無しさん

2006/03/06(月) 00:51:11

>>585
テンプレート引数に渡す型が予め分かってるなら
明示的実体化という手もある
例えばintとdoubleで実体化するのであればcppファイルに

template class A <int>;
template class A <double>;

と書いておく

0587デフォルトの名無しさん

2006/03/06(月) 00:52:13

自分のゲームプログラムなんですが
templateの使いすぎなのか
デバッグビルドだと重くて、まったく試運転出来ないのですが
そういうものですか？
VisualC++7.1 リリースビルドで30FPSなものが、デバッグだと0FPSになります。

0588デフォルトの名無しさん

2006/03/06(月) 01:08:34

templateは関係ないよ、コンパイル時に全部展開されるから。

0589デフォルトの名無しさん

2006/03/06(月) 01:42:40

>>588
それを期待して inline 重ねまくったコードが
デバッグビルドでボロボロになるんだよ。

0590デフォルトの名無しさん

2006/03/06(月) 01:48:04

templateってデバッグビルドだと実行時解釈される事あるの？

0591デフォルトの名無しさん

2006/03/06(月) 02:03:50

>>590
それはないが589はinline展開について言ってるのでは？

0592デフォルトの名無しさん

2006/03/06(月) 06:42:10

なんで急にinline展開について言うの？

0593デフォルトの名無しさん

2006/03/06(月) 07:39:45

>>582
ヘッダファイルからcppファイルをインクルードしれ。
最初は違和感あるかもしれんけど、
template の時だけはこのスタイルがベスト。

0594デフォルトの名無しさん

2006/03/06(月) 07:43:37

きんもーっ

0595デフォルトの名無しさん

2006/03/06(月) 10:54:03

インライン関数みたいな感覚でヘッダに実装したほうが自然じゃね？

0596デフォルトの名無しさん

2006/03/06(月) 11:00:39

漏れもヘッダに入れるのが普通だと思う

0597デフォルトの名無しさん

2006/03/06(月) 11:23:07

俺もそう思う

コンパイルして使うものは *.cpp　コンパイルしないで使うものは *.hpp ってしてる

0598デフォルトの名無しさん

2006/03/06(月) 11:52:48

同じく。
別ファイルに分けたいときは
拡張子はcppじゃなくhppにしてる。

0599デフォルトの名無しさん

2006/03/06(月) 11:54:33

int func()
{
　　　while(1)
　　　{
　　　　　　/*　処理　*/
　　　　　　if (条件) return 1;
　　　}
　　　return 0;
}

この条件で抜けるとネストが深くなるとか、そういった問題は起きないのでしょうか？
break;で抜けるのしか見たことがないので不安です。

0600デフォルトの名無しさん

2006/03/06(月) 11:59:59

>>599
無問題

ネストが深くなるってどんな意味で使ってる？

0601599

2006/03/06(月) 12:05:46

>>600
ありがとうございます。

＞ネストが深くなるってどんな意味で使ってる？
繰り返しの中に繰り返しとかです。
もし　return 1;　で抜けていなければ、何回もこの関数が呼ばれてこの条件で抜ける度に
while(1){
　　　while(1){
　　　　　　while(1){
　　　　　　　　　/*中略*/
　　　　　　}
　　　}
}
みたいな感じに処理されてるのかと思ったんです。

昔HSPを使っていたときに、
repeat～loopからちゃんと抜けずにgotoを使うとそういった現象に見舞われましたもので。

0602デフォルトの名無しさん

2006/03/06(月) 12:31:20

[1] もし　return 1;　で抜けていなければ、
[2] 何回もこの関数が呼ばれてこの条件で抜ける度に

抜けていなければ、抜けるたびに……？

ネストが深くなる、というより、スタックの処理が適切になされるかという意味かな。

0603デフォルトの名無しさん

2006/03/06(月) 14:06:35

>>601
「関数が呼ばれるたびに、whileが増えていく」ってことか？
ぶっちゃけありえない。

0604デフォルトの名無しさん

2006/03/06(月) 14:08:37

>>601
悪いことは言わないから、HSPのことは、きれいさっぱり忘れろ。

0605デフォルトの名無しさん

2006/03/06(月) 14:15:03

ようは、whileブロックの「終了処理（とでも言うべき何か）」がbreakによって行われるように錯覚していて。
returnでいきなり関数を抜けると、whileブロックの「終了処理」が行われずに関数処理が終わってしまう。
だから、次に同じブロックに処理が来たときに、前回の中途半端な状態が残っていて、おかしな動作に
なってしまうんじゃないか、てことだろ？

そういうアセンブラチックなことをしなくてすむのが高級言語なんだよ。
HSPはほんとうに低級なんですね。

0606デフォルトの名無しさん

2006/03/06(月) 17:38:58

deleteにNULLを渡しても大丈夫と言いますが、
DirectXのユーティリティなどで、
#define SAFE_DELETE(p) { if(p) { delete (p); (p)=NULL; } }
と定義されているのは、何故なのでしょうか

0607デフォルトの名無しさん

2006/03/06(月) 17:43:46

>>606
そのdefineと、NULLをdeleteするのとは、違うだろ～。よく見なされ。

0608デフォルトの名無しさん

2006/03/06(月) 18:34:09

>>607
いやいや、deleteにNULL渡してもOKなら
このマクロもifチェックいらないはずなのに何故、という話です

0609デフォルトの名無しさん

2006/03/06(月) 18:42:54

冗長だからだろ

問題ないのと、コストがかからないのとは違う

0610デフォルトの名無しさん

2006/03/06(月) 18:51:36

むしろif書いた方が冗長な気がするが

0611デフォルトの名無しさん

2006/03/06(月) 19:09:32

SAFE_RELEASEと一貫性を保つため？

0612デフォルトの名無しさん

2006/03/06(月) 19:10:34

DirectXのソースコードは超絶ウンコだから気をつけろ
そのifは必要ないし、inline+templateでも書けるところを
わざわざマクロを多用してるし、newが例外投げることすら
知らないし、C++初心者が書いてるようなレベルだ

0613デフォルトの名無しさん

2006/03/06(月) 19:13:03

2重にdeleteしちゃったりしても、不具合でないようにしてるのかな

0614デフォルトの名無しさん

2006/03/06(月) 19:21:55

単純に if(NULL) と delete NULL じゃ、delete NULL のほうがコストが
高いからじゃねーの？

0615デフォルトの名無しさん

2006/03/06(月) 19:32:55

ひょっとしたらNULLをdeleteしたら落ちるんじゃないかとDXUTを書いた人たちが不安に思っていたにいっぴょ。

0616デフォルトの名無しさん

2006/03/06(月) 19:38:35

NULLを渡されると落ちるような蛸なDebug用deleteを使われることを恐れてNULLチェックしているに一瓢。

0617デフォルトの名無しさん

2006/03/06(月) 19:52:04

つか、昔の VC++ だと delete に NULL 渡すと落ちた気がする。

0618デフォルトの名無しさん

2006/03/06(月) 19:56:44

昔のVCのnewはメモリ不足の例外は投げなかったな。

0619デフォルトの名無しさん

2006/03/06(月) 19:58:42

VC6 までそうだったね。
自分で例外投げるようにハンドラすげ替えたりして。

0620デフォルトの名無しさん

2006/03/06(月) 20:03:02

まあvc6はC++じゃないから仕方ない罠

0621デフォルトの名無しさん

2006/03/06(月) 20:32:39

VC6が糞なのかそれにさっさと取って代わらないドトネトが糞なのか

0622デフォルトの名無しさん

2006/03/06(月) 21:07:26

>>606
new の回数と delete の回数が一致してないと気持ち悪い、とか
new していないものを delete するのは気持ち悪い、とか。

0623デフォルトの名無しさん

2006/03/06(月) 21:14:46

ところでさぁ、さっき思いついたんだけど、
C++のこと、これからは「しーぷらら」って呼ばない?

0624デフォルトの名無しさん

2006/03/06(月) 21:18:46

>>622
newしてないものをdeleteしちゃまずいぢゃないか！

0625デフォルトの名無しさん

2006/03/06(月) 21:34:59

>>623
断る

0626デフォルトの名無しさん

2006/03/06(月) 21:41:18

そういえば、しーぷらぷら君ってどこ行ったの？

0627デフォルトの名無しさん

2006/03/06(月) 21:47:17

しーぷらぷら君ってだれ？

0628デフォルトの名無しさん

2006/03/06(月) 21:54:46

じゃぁ、「しぃぷらら」

0629デフォルトの名無しさん

2006/03/06(月) 21:56:56

EYECOMに載ってたやつ。

0630デフォルトの名無しさん

2006/03/06(月) 22:00:45

じゃ「ディズニーシー」

0631デフォルトの名無しさん

2006/03/06(月) 22:02:37

「しーたすたす」でええやん

0632デフォルトの名無しさん

2006/03/06(月) 22:07:30

時代は強い言語を求めているッ！！
Ｃ卐卐
シーダブルハーケンクロイツだッ！！

0633デフォルトの名無しさん

2006/03/06(月) 22:07:43

「しぃぷららん」にしたほうが可愛くね?

0634デフォルトの名無しさん

2006/03/06(月) 22:08:20

XとかZでよくね？

0635デフォルトの名無しさん

2006/03/06(月) 22:17:27

「しぃぱふぱふ」

0636デフォルトの名無しさん

2006/03/06(月) 22:19:20

「シー禿」

0637デフォルトの名無しさん

2006/03/06(月) 22:20:48

「禿Ｃ」

0638デフォルトの名無しさん

2006/03/06(月) 22:21:00

しーぱげぱげ

0639デフォルトの名無しさん

2006/03/06(月) 22:22:39

しぃツルッパゲ

0640デフォルトの名無しさん

2006/03/06(月) 22:26:30

つるピカハゲしぃくん

0641デフォルトの名無しさん

2006/03/06(月) 22:26:42

しぃツルりん

0642デフォルトの名無しさん

2006/03/06(月) 22:27:19

しーダメダメ

0643デフォルトの名無しさん

2006/03/06(月) 22:28:02

今禿って言った香具師ちょっと来い(`_ゝ´)

0644デフォルトの名無しさん

2006/03/06(月) 22:28:10

しーダメダメ

0645デフォルトの名無しさん

2006/03/06(月) 22:28:44

メイドさんＣＣ

0646デフォルトの名無しさん

2006/03/06(月) 22:28:51

ちょｗおまいらｗｗｗｗｗ

0647デフォルトの名無しさん

2006/03/06(月) 22:29:10

C
C++
C#
C##
C####

0648デフォルトの名無しさん

2006/03/06(月) 22:29:56

>しーダメダメ
C言語できないやつに取れる

0649デフォルトの名無しさん

2006/03/06(月) 22:31:03

>>648
test.cxx←テスト点シーダメダメって読んでた

0650デフォルトの名無しさん

2006/03/06(月) 22:58:43

しーだめだめ相談室

びじゅある　しーだめだめ

0651デフォルトの名無しさん

2006/03/06(月) 23:38:53

しーぽんぽん

0652デフォルトの名無しさん

2006/03/06(月) 23:44:55

>612
答え：DirectXはC言語でも扱えるように作られている

0653デフォルトの名無しさん

2006/03/06(月) 23:53:29

>>652 お前アホだろ。

0654デフォルトの名無しさん

2006/03/06(月) 23:56:40

まぁ「DirectXのソースコード」って表現が既に電波だな

0655デフォルトの名無しさん

2006/03/07(火) 00:05:52

ヘッダはソースコードではありませんか？

0656デフォルトの名無しさん

2006/03/07(火) 00:08:40

ありませんねぇ

0657デフォルトの名無しさん

2006/03/07(火) 00:14:43

>>656
そんな言い切れるほどの根拠はないだろ。
ちなみにプリプロセッサディレクティブ #include の機能は
"Source file inclusion" と言われる。

0658デフォルトの名無しさん

2006/03/07(火) 00:56:21

DirectXのヘッダーについて言うなら、>652はわりと正しい意見だと思う。
windows.hがいつまでたっても古臭いマクロとか#define定数とかに頼ってるのも、そう考えれば納得がいくな。

0659デフォルトの名無しさん

2006/03/07(火) 01:23:43

Cとの互換性とかいい加減X8で切っちゃえば良かったのに。
いくらなんでももうCでDirectXプログラミングとか無いと思うんだが

0660デフォルトの名無しさん

2006/03/07(火) 02:20:01

同感。今時WindowプログラミングでC使うならbetter CとしてのC++を使えばいいし(一部特殊用途除く)。
DirectXをCで使う必然性って何よ？

0661デフォルトの名無しさん

2006/03/07(火) 06:19:05

Ｃ丼

0662デフォルトの名無しさん

2006/03/07(火) 07:08:00

SAFE_DELETE() の勘違いが C と関係あるわけないだろ。

0663デフォルトの名無しさん

2006/03/07(火) 07:23:54

SAFE_DELETEはDXUTじゃなかったっけか？

0664デフォルトの名無しさん

2006/03/07(火) 07:43:34

最適化のパフォーマンスは C と C++ どっちが上げやすいのか？

0665デフォルトの名無しさん

2006/03/07(火) 07:47:20

たすたすと呼称
『Ｃで書いてんの？』
『いや　たすたす。』

0666デフォルトの名無しさん

2006/03/07(火) 07:54:32

C + _ +)

0667デフォルトの名無しさん

2006/03/07(火) 09:00:30

Ｃくさかんむり

0668デフォルトの名無しさん

2006/03/07(火) 09:08:16

expectedの解説と使い方?を教えてください。

0669デフォルトの名無しさん

2006/03/07(火) 09:54:43

explicitではなくて?

0670デフォルトの名無しさん

2006/03/07(火) 12:02:05

Cチョメチョメ

0671デフォルトの名無しさん

2006/03/07(火) 12:21:21

Cpp == Cpunipuniヾ(oﾟωﾟo)ﾉﾞ

0672デフォルトの名無しさん

2006/03/07(火) 13:39:04

>>662
>617でFAっぽくないか？

0673デフォルトの名無しさん

2006/03/07(火) 15:01:29

>>613
が正解。
だからdelete (p); (p) = NULL;だけでもよいが、不安になる人がいるのでifを付けている。

0674デフォルトの名無しさん

2006/03/07(火) 15:45:38

かえって危ない。
#define SAFE_DELETE(p) do { delete (p); (p)=NULL; } while (0)
と書き換えれ。

0675デフォルトの名無しさん

2006/03/07(火) 15:49:42

クラス化や operator という正攻法をさしおいてトリッキーなマクロ置換に走る奴のコードが
自分には回ってきて欲しくないんだが・・・

0676デフォルトの名無しさん

2006/03/07(火) 16:10:06

今からCしか使えないコンパイラに移ることも無いだろうし。
template<typename T>
void safe_delete(T*& p)
{
delete p;
p=0;
}

0677デフォルトの名無しさん

NGNG

std::fstreamから1bitずつ読み込みたいんですがどうしたらいいですか？

0678デフォルトの名無しさん

2006/03/07(火) 16:33:44

>>676
throw() もよろしく
ついでにsafe_delete_arrayとsafe_deleterとsafe_array_deleterも

0679デフォルトの名無しさん

2006/03/07(火) 16:49:26

>>676

template<typename T>
void safe_delete(T*& p)
{
typedef refuse_incomplete[sizeof(T)];
delete p;
p=0;
}

0680679

2006/03/07(火) 17:23:21

間違えた……

template<typename T>
void safe_delete(T*& p)
{
typedef char refuse_incomplete[sizeof(T)];
delete p;
p=0;
}

0681デフォルトの名無しさん

2006/03/07(火) 17:28:53

>>679

template<typename T>
void safe_delete(T*& p)
{
checked_delete(p);
p = 0;
}

ってこと？

0682デフォルトの名無しさん

2006/03/07(火) 17:36:15

こちらでよろしいでしょうか？
フレーム処理でちょっとてこずってます。
さまざまなサイトを参考にして、
メッセージループでフレーム制御をやってるのですが、
どうもうまく行きません。なぜかキーボードのキーを叩くと
アニメーションが停まってしまいます。
半日くらいgoogleほっつき回ったのですが、原因はついに分からず。
どなたか知恵を貸していただけないでしょうか？
一応ソースコードをアップロードしておきます。
環境はWinXP、VS.NET theSpoke Premiumです。
ttp://gamdev.org/up/img/4892.zip

0683デフォルトの名無しさん

2006/03/07(火) 17:40:21

せっかくtheSpokeで買ったならtheSpoke.netで聞けよ・・・

0684679

2006/03/07(火) 17:42:56

>>681
はい

0685デフォルトの名無しさん

2006/03/07(火) 18:40:00

>>677
バイト単位で読み込んでからビットに刻む

0686デフォルトの名無しさん

2006/03/07(火) 19:49:28

質問：ＶＳ２００３上で動作しているか調べる方法はありますか？
わたくしはVisualStudio2003 VC++を使っております。
DebugかReleaseかはDebugを使っています。
現在VS上でプログラムを実行してるのか、できたEXEを直接動かしてるのか
プログラムで判断することはできますか？？？？
GetCurrentDirectory()を使ってカレントフォルダを表示させるプログラムを作りました。
VS2003上でF5を押すときとは、カレントフォルダの最後に\Debugがつかないで
直接EXEを実行させるとそれがつくという違いがあるのはわかったのですが、
別な方法で正しくVS上で動作させているかプログラムで判別する方法はある
のでしょうか？

0687デフォルトの名無しさん

2006/03/07(火) 19:59:34

>>686
日本語でOK
後、1も読めない文盲は氏ね

0688デフォルトの名無しさん

2006/03/07(火) 20:40:44

はじめましてこんにちは。
質問があります。Ｃ＋＋でＣＧＩのプログラムは終わって、テスト鯖でのコンパイル→実行→テストも終わったのですが、いざ、これを無料鯖に載せて公開しようとしたところ・・・ＳＳＨの使えない鯖で、コンパイルできません。
鯖環境がどういうものか書いていない鯖なもので、ウィンドウズかＢＳＤ系でのコンパイル済みファイルをアップしても動作しない為、鯖は別環境と推定されます・・・。
っが、なんとか簡単に鯖でコンパイルすることは可能でしょうか？
他のプログラムを使う事もできるのですが、個人的に、Ｃ／Ｃ＋＋が好きということもあり、できる限り上記の方法での解決をしたいと思っております。
ちなみに、以前、どこかでそのようなスクリプトを見た事があるのですが、どうも思い出せません。
ＣＧＩファイルに・・・スクリプトで・・・Ｇ＋＋をＥＣＨＯで呼び込んで・・・・ってのはわかってるのですが・・。自分の知識の範囲外です。
お手数とは思いますがよろしくお願いします。
（ウェブプログラミングはＰｅｒｌ、ＰＨＰ、ＪＳＰ等の方が良いとわかっていても、Ｃ／Ｃ＋＋やＪａｖａなどのオブジェクト指向系（あくまで系）の方がいいっすｂ

0689デフォルトの名無しさん

NGNG

>>688
#/bin/sh
echo Content-type: text/plain
echo
make hoge

0690デフォルトの名無しさん

2006/03/07(火) 21:01:42

>>688はsystem()も知らないのか？

0691デフォルトの名無しさん

2006/03/07(火) 21:02:09

>>688
さっそく回答ありがとうございます！
これです！昔見たやつです！！
早速、試させていただきます。ありがとうございましたｂ

0692デフォルトの名無しさん

2006/03/07(火) 21:13:17

オブジェクト指向系の言語が使いたくて
スクリプト言語を使いたいなら、
Ruby や Python を鯖でコンパイルするといいよ。
容量圧迫するけど。

0693デフォルトの名無しさん

2006/03/07(火) 21:18:37

クラスがメンバー変数として配列を持っていた場合、どうやって初期化すれば良いのでしょうか？

class Class
{
public:
int array[10];
}

Class:: Class () : /* ここでarrayを初期化したい */
{
}

;

0694682

2006/03/07(火) 21:18:38

>>683
じゃ、そちらで聞きなおしてきます。失礼しました。

0695デフォルトの名無しさん

2006/03/07(火) 21:48:39

>>693
ムリ
コンストラクタの中で初期化。

0696デフォルトの名無しさん

2006/03/07(火) 21:51:03

>>693
コンストラクタ内で初期化代入するしか。
Class::Class() {
static const int arrayInits[] = {0, 1, 2, 3, 4,};
std::copy(arrayInits, arrayInits + sizeof(arrayInits) / sizeof(*arrayInits), array);
}

0697デフォルトの名無しさん

2006/03/07(火) 22:31:24

>>686
カレントフォルダは好きに変えられる。
たとえばショートカットを作れば、ショートカットのプロパティで設定できる。

もしもEXEの存在するフォルダを知りたいのであれば、
EXEへのパスを取得し、それを加工してEXEファイルのあるフォルダへのパスを取り出すようにすべき。

（書き終わってからスレ違いだと気づく＿|￣|○）

0698デフォルトの名無しさん

2006/03/07(火) 22:48:03

>>686
実行時に渡すパラメータを決めるオプションがあるから、
自分で何かパラメータ渡すように設定しておいて、
そのパラメータがあるかどうかで判定すれば良さげ。

直接動かす場合でもそのパラメータ渡せば誤認させられるけど、
どうせ Debug バージョンでしか有効じゃない処理だろうから、
そのくらいいい加減でもいいっしょ。

0699デフォルトの名無しさん

2006/03/08(水) 00:31:06

>>695-696 初期化と代入を以下略

0700デフォルトの名無しさん

2006/03/08(水) 02:05:10

以上略

0701デフォルトの名無しさん

2006/03/08(水) 03:57:45

テンプレートを使ったクラスや関数をライブラリ化しようと思っています。
テンプレートクラスは下記のような記述で明示的なインスタンス化ができたのですが、
template class Hoge<Moge>;
テンプレート関数の場合は、明示的なインスタンス化はできないのでしょうか？

環境は、VS2005です。

0702デフォルトの名無しさん

2006/03/08(水) 04:17:30

どういうとき必要なのかは知らんが、
似たようにしてできない？
あるいは template の後に <> を書くか。

0703デフォルトの名無しさん

2006/03/08(水) 04:17:33

>>701
template<class T>
void func(const T &) {
...
}

void func<int>(const int &);

たしか、こんなんでいけたと思う。

0704デフォルトの名無しさん

2006/03/08(水) 05:20:45

>>701
template<class T>
void func(const T &) {
...
}
template void func (const int &);

0705デフォルトの名無しさん

2006/03/08(水) 05:36:44

typenameつかおうね

0706デフォルトの名無しさん

2006/03/08(水) 05:48:26

>>705
どんな風に？

0707701

2006/03/08(水) 06:08:49

>>702-706
レスありがとうございます。
参考にさせて頂いて、手探りでいじってた所、
↓これで、一応コンパイルは通りました。
template void func<int>(const int&);

0708デフォルトの名無しさん

2006/03/08(水) 06:20:57

typenameを使うべきところは見当たりませんがｗｗｗ

0709デフォルトの名無しさん

2006/03/08(水) 08:12:43

template<class T>をtemplate<typename T>と書けということではないかと思う。

0710デフォルトの名無しさん

2006/03/08(水) 09:13:35

どっちでも同じじゃん。
まあ、俺は typename のが好きだけど。
template <typename> class T とかだと
typename 使えないけどね。

0711デフォルトの名無しさん

2006/03/08(水) 09:16:53

>>710
ん？なんだその構文？

0712デフォルトの名無しさん

2006/03/08(水) 09:46:24

>>711
テンプレート・テンプレート・パラメータ

0713デフォルトの名無しさん

2006/03/08(水) 09:59:20

>>711
テンプレート引数にテンプレートを渡すためのもの。
template<typename T>
class Foo {};

template<template<typename U> class T>
class Hoge
{
T<int> Bar;
};

Hoge<Foo> ahya;

Uは使わないから710のように省略できる。

0714デフォルトの名無しさん

2006/03/08(水) 10:05:12

「引数に渡す」ってのは、変な表現のような気がする
普通「引数」というと「実引数」のことじゃね？

0715デフォルトの名無しさん

2006/03/08(水) 10:18:01

>普通「引数」というと「実引数」のことじゃね？

実と仮のどちらかがデフォってことはない
あくまで「不明」もしくは周りの文脈から推定するのみ

0716デフォルトの名無しさん

2006/03/08(水) 11:17:46

モダンは確か「テンプレート引数」っつってたと思う

0717デフォルトの名無しさん

2006/03/08(水) 13:37:29

>実と仮のどちらかがデフォってことはない
>あくまで「不明」もしくは周りの文脈から推定するのみ

過去の経緯からそうなってしまった、ってのは理解ってるんだが……
一つの文章の中で argument と parameter をどちらも「引数」と表現するのはやめてほしいなあ

0718デフォルトの名無しさん

2006/03/08(水) 13:54:25

「仮引数に渡す」という表現でもおかしいんじゃないか？
「テンプレートにテンプレートを(引数として)渡す」だろ。

0719デフォルトの名無しさん

2006/03/08(水) 14:05:01

確かに、送り側から受け側まで含んだ系全体を指すニュアンスで「引数」というケースはあるな

0720デフォルトの名無しさん

2006/03/08(水) 16:31:23

>>686 の父です
697,698さんどうも情報ありがとうです。
やりたいことは、関連してプログラムに使用したいファイルがあって
プログラムからみて相対パスで実行させようとして、
①プログラムはC:\AAA\PROGRAM1\debug\PROGRAM1.EXEで
②関連ファイルはC:\AAA\hogehoge\hogehoge.txt
のときに相対パスを使ってVS上かどうかで相対パスが
"..\hogehoge\hogehoge.txt"と"..\..\hogehoge\hogehoge.txt"
の２通りでてきてしまうのですが、なんとなくカレントフォルダを
現在実行しているプログラムの存在するフォルダに変更してしまえば
相対フォルダも同一になりそうな気がするので、たぶん問題解決です。
どうもありがとうございます。

0721デフォルトの名無しさん

2006/03/08(水) 17:09:17

>>720
甘いな。ツーか、スレ違い。

0722デフォルトの名無しさん

2006/03/08(水) 19:22:56

boost::enable_shared_from_this クラステンプレートは面白いな。
何の変哲もないポインタから、shared_ptr が生成される仕組みは
単純だけど、目から鱗って感じ。

0723デフォルトの名無しさん

2006/03/08(水) 20:40:16

ソース読んだけど全然理解できん。

0724デフォルトの名無しさん

2006/03/09(木) 00:38:48

読んでみたけど・・・
どういった場面で使うのかわからん
_internal_weak_thisがどこで初期化されてんのかよくわからん
あと、const T を T const と書いてもいいことを知りますた。

0725デフォルトの名無しさん

2006/03/09(木) 00:53:35

>>724
Tがポインタだった場合に備えてじゃない？
とソースを読まずに言ってみる

0726デフォルトの名無しさん

2006/03/09(木) 00:58:32

おお！なるほど。
あと、boostの前スレにenable_shared_from_thisあったね。
でもそれ見てもわからんかったので寝ます。おやすみ。

0727デフォルトの名無しさん

2006/03/09(木) 01:05:35

>>725-726
T がポインタでも const T と T const は同じだよ。

0728デフォルトの名無しさん

2006/03/09(木) 01:06:44

>>727
そうか、スマソ(´･ω･`)

0729デフォルトの名無しさん

2006/03/09(木) 01:29:15

>>724
＞どういった場面で使うのかわからん
http://www.boost.org/libs/smart_ptr/sp_techniques.html#from_this

＞_internal_weak_thisがどこで初期化されてんのかよくわからん
boost::shared_ptr の側に boost::enable_shared_from_this 用のコードがあります．
（boost::shared_ptr が保持しようとしているポインタのクラスが
boost::enable_shared_from_this から派生しているものなら
_internal_weak_this を初期化する）

0730デフォルトの名無しさん

2006/03/09(木) 01:33:25

デフォルトコンストラクタ A()
とコンストラクタA(a, b, c)
という２種類のコンストラクタを持つクラスを定義し、
それを継承したクラス class B : public A
のデフォルトコンストラクタB(), B(a, b, c)
があるとします。B(a, b, c)が呼ばれたら A(a, b, c)
が呼ばれるようにできますか？明示的に B(a,b,c)
の中で呼ぶしか無いでしょうか？

0731デフォルトの名無しさん

2006/03/09(木) 01:37:46

B(int a, int b, int c) : A(a, b, c) {
// B(a, b, c)の処理...
}

0732デフォルトの名無しさん

2006/03/09(木) 03:06:07

各種の operator にも名前空間というモノがあるんでしょうか？例えば

namespace N {
class A {
略
friend std::ostream& operator<<(std::ostream&, const A&);
略
};//class A
}//namespace N

のように宣言した場合、この operator<< は正確には N::operator<<
ということになるのでしょうか。するとその実際処理を定義する場合にも
N::operator<< として定義するべきなのでしょうか？

そもそも std::cout << "aiueo\n"; の時の operator<< は
::operator<< なのか std::operator<< なのか・・・
ちょっと混乱しています。

0733デフォルトの名無しさん

2006/03/09(木) 03:11:57

>>732
もちろん、演算子も名前空間の中に入る。

こういう風に書くとわかりやすいかも。
やっていることは同じコード。

std::cout << "hello,world" ;
std::operator << (std::cout, "hello,world") ;

まあ、実際に使うときは、ADL、Koening Lookupなどと呼ばれている仕組みにより、
名前空間を明示しなくても呼び出せるんだけど。

0734デフォルトの名無しさん

2006/03/09(木) 03:27:13

>>733 ありがとうございます。
std::cout << "aiueo\n"; の時の << は
std::operator<< だったんですね。
その点は疑問が氷解しました。

>>722 の friend にした operator<< は、N::operator<< なのでしょうか？
というのは、class A のインスタンス a を std::cout << a; のように
ストリームに流すときの << もやはり std::operator<< なので、
friend 指定の時に

namespace N {
class A {
略
friend std::ostream& std::operator<<(std::ostream&, const A&);
略
};//class A
}//namespace N

のように operator<< の前に std:: を付けてみると、
std::operator<< should have been declared inside 'std'
とコンパイラに怒られます。そこで何も名前空間を指定せずに
>>722 のように宣言したはいいものの、その定義では
どう書くべきなのか分かりません。 N::operator<< なのでしょうか？

0735デフォルトの名無しさん

2006/03/09(木) 03:27:46

すみません、上のレスで >>722 と書いていたのは
>>732 の誤りでした。

0736732=734

2006/03/09(木) 03:39:20

>>732 で friend 指定した operator<< は
フルネームでは N::operator<< ですね。
*.cpp ファイルで定義する際にも N::operator<< で行けました。
今まで N::operator<< はクラス定義のヘッダファイル中に
直接書いていたので、いざ定義と宣言を分離しようとすると
困ってしまっていました。

0737デフォルトの名無しさん

2006/03/09(木) 04:15:22

Koenig Lookupにも限界があり、std::ostream_iteratorに
自前のクラスやstd::pairなんかを食わせると、標準に正しく準拠した
コンパイラではエラーになる。

operator<< を std名前空間に入れないとだめだからだが、標準C++
はstd名前空間をいじってはいけない事になっている。

0738732=734

2006/03/09(木) 04:22:44

>>737 このあたりは Visual C++ と g++ で挙動が違い、
悩むこともしばしばでした。さらに同じ g++ でも
バージョンによって挙動が違うこともあるので余計に。

0739デフォルトの名無しさん

2006/03/09(木) 08:03:46

>>737
自前のクラスなら operator をクラスと同じ名前空間で宣言すれば大丈夫。
std::pair はやっぱり無理。

0740デフォルトの名無しさん

2006/03/09(木) 08:16:00

>>738
friend のルールは複雑でそういう問題も発生するし、
元々がなるべく使わないで済ませたほうがいいものなんで
public な入出力メンバ関数を作っておいて、 operator では
それらを呼び出すだけにするのがいいと思う。

ちなみに gcc だと 3.4, 4.0, 4.1 と毎度 friend 周りで挙動の変更が入っている。

0741デフォルトの名無しさん

2006/03/09(木) 08:30:25

>>734
ちなみにstd::cout << "aiueo\n";の<<は
std::basic_ostream::operator <<のメンバ。
基本型とマニピュレータに対するoperator <<はstd::basic_ostreamのメンバ。

0742デフォルトの名無しさん

2006/03/09(木) 09:39:27

えー、標準C++だとfinallyが無い(gccには__finallyも無い)ので
普通はスタック上のオブジェクトのデストラクタで代用する。
これは、メモリ/ファイル/コネクション等なら普通に使えるし
大抵はいろいろな処理をまとめてclassとして扱うので抵抗は無いのだけれど
これがロックとかだと、若干使いにくい気がする。

というのは、まず、ロックのためにclassを定義するというのもなんか嫌だし
unlockするタイミングを確定させるためにわざわざブロックを作って
その先頭にロックオブジェクトの宣言だけが現れる(操作がソース上に現れない)
という形になって、美しくない(気がする)。

で、operator bool()が必ずfalseを返すこんなclassと#defineマクロを使って
Synchronized(x) { } を擬似的に作ってみたのだけれど、まずいところあるかな？

class synchronizer {
　LockObject& lock;
　explicit synchronizer(LockObject& lock) : lock(lock) {
　　lock.lock();
　}
　~synchronizer() {
　　lock.unlock();
　}
　operator bool() const {
　　return false;
　}
};
#define Synchronized(x) if (synchronizer ___locker = synchronizer(x)) ; else

0743デフォルトの名無しさん

2006/03/09(木) 09:50:00

>>742

JLib2 ( http://www.codeproject.com/library/jlib.asp ) に、
ほとんど同じコードがあったな。こっちは operator bool が常に true を返してたけど。
ただ、注意書きのところに、

// used to be "#define synchronized(x) if ( jlib::lang::Lock l_o__c_k(x) )",
// up to the C++ standard, this seems to be incorrect, it can only be
// accepted by MSVC. See C++ Language Specification, A5.

とか書いてあったから、いいかどうかは微妙なところ。

0744デフォルトの名無しさん

2006/03/09(木) 09:57:48

>>742
結局ロックのためにブロック作ってるのは変わらないし
ロックオブジェクトを先頭に置くのが美しくない?とかってのも
単に見慣れてるかどうかでは?
{
ScopedLock<LockObject> lock;
...
}
みたいなので十分分かるとは思うな
言語が synchronized構文とかサポートしてるのならともかく
オレ流マクロで構文モドキを作るのは余計説明しにくいような

0745デフォルトの名無しさん

2006/03/09(木) 09:57:55

あー、やっぱり、俺が考えつく程度のことは
当然誰か他の人も思いついてるんだよな。

どこが引っかかるかは、よく読んでから考えてみる。
とりあえず、ifの()内の変数宣言は、大昔のコンパイラは対応してないし。

0746デフォルトの名無しさん

2006/03/09(木) 15:09:25

>>729
おー、template特殊化でコンパイル時に型判断してるんですね。
template恐るべしですな。

0747デフォルトの名無しさん

2006/03/09(木) 16:17:47

VC7.1で、意味はありませんが、こんなコードがありまして

boost::bind(std::less<int>(), _1, 2)(x) ;

さらにこうすると、コンパイルできません。

boost::not1(
　　　　boost::bind(std::less<int>(), _1, 2)
　　)(x) ;

これならOKのようです。

boost::bind(
　　　　boost:not2(std::less<int>()), _1, 2
　　)(x) ;

これなら通るのですが。

std::not1(
　　　　std::bind2nd(std::less<int>(), 2)
　　)(x) ;

0748747

2006/03/09(木) 16:19:32

boostスレに行くべきだったかな……。

0749デフォルトの名無しさん

2006/03/10(金) 00:05:24

#include "boost/lambda/lambda.hpp"
#include "boost/lambda/bind.hpp"

(!bind( std::less<int>(), boost::lambda::_1, 2))(x)

0750747

2006/03/10(金) 00:54:56

>>749
おお、boost::lambdaすごい。
これは面白い。

STLのbind1sとかbind2ndとか、キモすぎで、
今まで使おうとは思わなかったんですよ。

0751デフォルトの名無しさん

2006/03/10(金) 06:58:49

演算子のオーバーロードはインライン的に高速ですか？
これも、クラス宣言に書いたり、inlineとかつけるとか？

0752デフォルトの名無しさん

2006/03/10(金) 07:34:05

気になる「的」の用法だな

0753デフォルトの名無しさん

2006/03/10(金) 08:28:33

代入演算子のオーバーロードをフレンド演算子関数で実装できないのは何故ですか？

0754デフォルトの名無しさん

2006/03/10(金) 08:36:39

>>751
普通の関数と全く同じように考えればよい。
インラインに書けばインライン展開されるだろうし、そうでなければ関数呼び出しになるだろうし。

0755デフォルトの名無しさん

2006/03/10(金) 08:43:45

>>754
あり＾＾

0756デフォルトの名無しさん

2006/03/10(金) 15:50:50

>>753
する必要がないから。あれメンバ関数よ？
加算演算子とかをfriendにするのは、
メンバ関数じゃないけど中身直接いじれると便利だから。

0757デフォルトの名無しさん

2006/03/10(金) 23:11:09

>>753
その問いに対する答えはただ１つ：　規格で禁止されているから

「なぜ禁止しているのか」なら、これは想像だが
struct X { }; つまり operator = が宣言されていないクラスに対して、
const X& X::operator = (const X&); が翻訳環境によって追加され、
そこへ随伴宣言があると例えば vtable の生成則がおかしくなったりしそうだろ

0758デフォルトの名無しさん

2006/03/10(金) 23:35:46

左辺に組み込み型を持ってこられると困るからでは？
もしフレンド関数でオーバーロードを許すなら、他のoperatorとシンタックスを合わせないといけないだろうし

0759デフォルトの名無しさん

2006/03/11(土) 00:47:02

D&Eにはoperator =が非メンバで定義されると、
場所によってコピーの方法が変わると言うまずい状況になるから
メンバとしてしか定義できないようにしたと書いてある。

ただしfriendまでは言及されていないが。

struct Hoge {/* ～ */};

Hoge x, y;

x = y; //デフォルトのコピー

Hoge& operator =(Hoge&, const Hoge&) {/* ～ */}

Hoge z;
z = x; //さっきのoperator =()

0760デフォルトの名無しさん

2006/03/11(土) 01:28:37

>>759
757 だが・・・
あんたの勝ち

0761デフォルトの名無しさん

2006/03/11(土) 09:02:05

これもC++の歪みってやつか

0762デフォルトの名無しさん

2006/03/11(土) 19:39:46

コンストラクタAで他のオブジェクトBをnewしているとします。
しかし、そこでメモリが足りなかったとします。
Aがnewで作成されている場合にポインタにNULLを返したいのですが、どうすればいいのでしょうか？

#include <stdio.h>

class B{};

class A
{
public:
　　A()
　　{
　　　　B *m_pB = new B;
　　　　if (m_pB == NULL)
　　　　{
　　　　　　//ここでA()にNULLを返させたい。
　　　　}
　　}
private:
　　m_pB;
};

void main()
{
　　A *pA = new A;
　　if (pA == NULL)
　　　　printf("NO MEMORY\n");
}

0763デフォルトの名無しさん

2006/03/11(土) 19:54:04

>>762
コンストラクタじゃ無理。newをオーバーロード汁

0764デフォルトの名無しさん

2006/03/11(土) 19:55:06

すみません、教えてください
class を使ってるということは C++ なんだと思うんですけど
iostream じゃなくて stdio を使う意味を教えてください。

0765デフォルトの名無しさん

2006/03/11(土) 20:00:03

>>764
printfとかが使いたいから。

0766デフォルトの名無しさん

2006/03/11(土) 20:10:29

scanf を愛しているから

0767デフォルトの名無しさん

2006/03/11(土) 20:13:10

>>764
iostreamはでかいんだよ。
それを静的リンクするとフロッピーディスクに入らなくなる。
動的リンクするとDLLが無いとサポートに電話がかかってくるんだよ。

0768デフォルトの名無しさん

2006/03/11(土) 20:19:06

>>762
標準に準拠したコンパイラでは通常newはNULLを返さない。例外を投げてくる。
例外を投げないようにするのにはnew(nothrow) B;などと書く。

挙げている例の場合、普通は例外を使うか、正常に構築出来なかった事をメンバ関数で伝えるか、何らかの生成用関数を挟む事などが考えられる。

0769デフォルトの名無しさん

2006/03/11(土) 20:33:57

ふと疑問
newがメモリ不足で失敗した場合に、printf()とかが
まともに動く保障はあるの？？

0770デフォルトの名無しさん

2006/03/11(土) 20:40:11

そろそろprintfの呪縛から解放されないか？
printfは、諸悪の根源。

0771デフォルトの名無しさん

2006/03/11(土) 20:56:07

>>769
聞いたことねえな
printf が内部で new を使うはずがなさそうだし、まして仕様でなどありえない
仮に malloc を使っていても new と同じ系統のサブプールを使う可能性はあっても保証はできっこない
operator new がユーザ定義される場合があるのだから

0772デフォルトの名無しさん

2006/03/11(土) 21:55:53

>>770
じゃあ、boost::formatの時代だな。

0773デフォルトの名無しさん

2006/03/11(土) 22:53:05

ポインタを返す関数の作り方がわかりません。
ソースはこんな感じです。

typedef struct
int a;
int b;
} WORK;

WORK* クラス名::GetWork()
{

}

ポインタの戻り値の設定ってこれでもおかしくないですよね。

0774デフォルトの名無しさん

2006/03/11(土) 22:55:36

もう春休みなのか？

0775デフォルトの名無しさん

2006/03/11(土) 23:00:00

>>773
こんなことやって悩んでいる予感。
WORK* クラス名::GetWork()
{
WORK w;
return &w;
}

0776デフォルトの名無しさん

2006/03/11(土) 23:21:38

違います。クラス内のパブリック変数のポインタを返してます

0777デフォルトの名無しさん

2006/03/11(土) 23:23:43

error: 2: unexpected type identifier `int'.

0778デフォルトの名無しさん

2006/03/11(土) 23:24:00

class hoge{
WORK w;
WORK& get_w(){ return w;}
};

こうじゃダメなんか？

0779デフォルトの名無しさん

2006/03/11(土) 23:25:22

class hoge{
WORK oma_www;
WORK& cho_ww(){ return oma_www;}
};

0780デフォルトの名無しさん

2006/03/11(土) 23:27:12

>>776
ソースコード省略せずに全部挙げろ

0781デフォルトの名無しさん

2006/03/11(土) 23:44:28

公開メンバ変数ってだけでもあれだが、それを指すポインタを返すメンバ関数って、
直接ポインタとるんじゃだめなのか？

0782デフォルトの名無しさん

2006/03/11(土) 23:44:59

構造体の宣言をクラスの外に出したらエラーがなくなりました。
なんででしょうか？

0783デフォルトの名無しさん

2006/03/12(日) 00:34:07

そういうことは先言えよ
エラーメッセージ１００回読んどけ

0784デフォルトの名無しさん

2006/03/12(日) 00:34:16

>>782
>>780
助けたいのは山々だけど、謎が多過ぎる

0785デフォルトの名無しさん

2006/03/12(日) 01:08:54

class C {
struct S {...};
S* func();
};

C::S* C::func(){}

C::が抜けてると見た。

0786デフォルトの名無しさん

2006/03/12(日) 01:19:19

なるほど・・内部クラスを使っていたのか

0787デフォルトの名無しさん

2006/03/12(日) 02:01:07

785さん、ありがとうございました。
ちなみに内部構造体を使ってました。

0788デフォルトの名無しさん

2006/03/12(日) 02:02:21

関数の中に関数宣言したいんだけど。

0789デフォルトの名無しさん

2006/03/12(日) 02:08:06

>>788 しろ。心ゆくまで。

0790デフォルトの名無しさん

2006/03/12(日) 02:08:27

>>788
関数の中で、クラスを定義できたりする。

int main()
{

0791デフォルトの名無しさん

2006/03/12(日) 02:08:47

>>788
void f() {
  struct local {
    static void g() { }
  };
  local::g();
}

0792デフォルトの名無しさん

2006/03/12(日) 02:09:10

int main()
{
struct hoge{
static func() {}
} ;

hoge::func() ;

}

0793デフォルトの名無しさん

2006/03/12(日) 03:24:27

前方参照２題

(1)typedef　を前方参照する裏技って無いですか？
----hoge,h
class Hoge;

class ZZ {
　　Hoge<int> *hoge;
};

----hoge,cpp
typedef HogeHoge　Hoge ;
まともにやるとコンパイル不可

(2)テンプレートクラスの前方参照は出来ない？？

0794デフォルトの名無しさん

2006/03/12(日) 03:39:40

間違えた　orz
×　　Hoge<int> *hoge;
○　　Hoge *hoge;

0795デフォルトの名無しさん

2006/03/12(日) 08:24:57

>>793
HogeHogeがこうだとすると、
template <typename T>
class HogeHoge
{
/* ～ */
};
HogeHogeの前方宣言はこうなる。
template <typename T>
class HogeHoge;

そしてクラステンプレートをテンプレート引数の指定なしにtypedefすることはできない。
typedef HogeHoge<int> HHInt;のようなことはできるけど、
typedef HogeHoge Hoge;は今のC++ではできない。

0796デフォルトの名無しさん

2006/03/12(日) 08:40:02

つ　マクロ

0797デフォルトの名無しさん

2006/03/12(日) 09:05:31

>>795
それぐらい理解済みだと思うぞ

0798デフォルトの名無しさん

2006/03/12(日) 13:05:47

テンプレートのtypedefができないのはちと悲しいよね

0799デフォルトの名無しさん

2006/03/12(日) 15:04:03

次のような名前空間があるとします。

namespace abcdefg
{
　　int result1();
　　int result2();
　　int result3();
};

もしもプログラム中どこからも int result3(); を呼び出しても参照してもいないとします。
この時実行ファイルに int result3(); の部分は組み込まれるのでしょうか？

0800デフォルトの名無しさん

2006/03/12(日) 15:11:09

コンパイラ、リンカの実装しだい。

0801デフォルトの名無しさん

2006/03/12(日) 15:13:00

>>799 それは名前空間とかには全く関係ない。
result1() と result()3 が同じ名前空間で宣言されていることと
result3() のコードがリンクされるかどうかは全く無関係

「result3() の部分が組み込まれるか？」というのはリンク対象
になるか？ということだと思うが、そりゃ result3() の定義を
含むオブジェクトファイルをリンカに食わせればたとえ全く
呼び出されていなくても無駄にリンクされるし、
当該オブジェクトファイルを静的ライブラリ化していたとして、
result1() の定義と result3() の定義が同じオブジェクトであれば
一緒にリンクされる。リンカの扱う単位はオブジェクトファイル単位だから。

0802デフォルトの名無しさん

2006/03/12(日) 15:13:22

組み込むだろ。
関すコールは直接呼ぶだけじゃなく、関数ポインタを使って間接的に
呼び出すこともあるんだから、そこまで追跡するのは無理だべ。
コールバック関数を外部モジュールへ登録するなんて場合もあるわけだし。

0803デフォルトの名無しさん

2006/03/12(日) 15:14:03

でもどこからも呼び出されていないエントリポイントが
あるときには警告してくれるリンカもある。

0804デフォルトの名無しさん

2006/03/12(日) 15:17:21

>>801-802
コンパイラ、リンカの実装しだい。

0805デフォルトの名無しさん

2006/03/12(日) 15:18:37

コンパイラ、リンカの気分次第

0806799

2006/03/12(日) 15:19:07

皆さんていねいにありがとうございます。
異なるアプリケーションで使えそうな関数を独自のライブラリとし、
複数のアプリケーションでプロジェクトに追加できるような形に
した場合、この独自ライブラリの規模が膨らむほど実行ファイルの
サイズはデカくなっていくと考えていいんですね？

0807デフォルトの名無しさん

2006/03/12(日) 15:19:56

>>802
それって参照したことになるんじゃない？
result3の識別子を使わずに確実に関数ポインタ得るのは無理だろうし。

0808デフォルトの名無しさん

2006/03/12(日) 15:21:36

>>806
静的リンクしてたら基本的にそうなるだろうな。
ただ、コンパイラ、リンカの実装によってはそうならない可能性もあるし、
特定の実装をターゲットにすれば回避策もいくらかはあるだろう。

0809デフォルトの名無しさん

2006/03/12(日) 15:22:50

一般的には、同じオブジェクトファイルに含まれるもの(不使用の関数/変数等)は
全て実行ファイルにリンクされるが
リンカによっては、それらを判断してリンクするときに除外するものもある。
つまり>>804。

「一般的なリンカ」なら、>>801-802。

0810799

2006/03/12(日) 15:24:16

>>809
Borland C++ Builder 6 ではどうでしょうか？

0811デフォルトの名無しさん

2006/03/12(日) 15:24:50

>>806 違う。
そりゃ、細かいこと言えばコンパイラ、リンカの実装次第としか
言いようがないので一般論でしか書けないけど。

静的ライブラリを作成するなら各関数ごとに異なるファイルに
定義を書くといい。100個のある関数を100個の *.cpp に書いて
コンパイルしてできた100個の *.o から libhoge.a を作って置けば、
リンクしなけりゃならない関数(を含むモジュール)だけ
リンカが取り出してリンクしてくれる。

もし100個ある関数を一つの hoge.cpp に書いてしまえば、
それをコンパイルしてできた hoge.o に100個の関数が
全部含まれているわけで、そのうち一つでもリンク対象に
なってるとリンカは hoge.o 丸ごとリンクする。

って、のがよくあるリンカの振る舞いだと思う。

0812デフォルトの名無しさん

2006/03/12(日) 15:31:00

>>810
マップファイルを出力して確認しろ

0813デフォルトの名無しさん

2006/03/12(日) 15:41:52

アドレスとポインタの差なんて、ちゃんと勉強した奴なら誰でも知ってるよ。
アドレスとポインタの差なんて、ちゃんと勉強した奴なら誰でも知ってるよ。
アドレスとポインタの差なんて、ちゃんと勉強した奴なら誰でも知ってるよ。
アドレスとポインタの差なんて、ちゃんと勉強した奴なら誰でも知ってるよ。
アドレスとポインタの差なんて、ちゃんと勉強した奴なら誰でも知ってるよ。
アドレスとポインタの差なんて、ちゃんと勉強した奴なら誰でも知ってるよ。
アドレスとポインタの差なんて、ちゃんと勉強した奴なら誰でも知ってるよ。
アドレスとポインタの差なんて、ちゃんと勉強した奴なら誰でも知ってるよ。

http://pc8.2ch.net/test/read.cgi/prog/1140616676/

0814デフォルトの名無しさん

2006/03/12(日) 16:09:21

ポインタとアドレスってちゃうん？

ポインタはアドレスを格納するための変数？

0815デフォルトの名無しさん

2006/03/12(日) 16:12:07

ポインタには型情報が付加されている。
あとは、メンバ関数ポインタとか変態じみたもの。

0816デフォルトの名無しさん

2006/03/12(日) 16:16:13

ポインタは抽象インターフェース、アドレスは具体的なもの。

0817デフォルトの名無しさん

2006/03/12(日) 16:22:47

ポインタでもまだ具体的な実装を意識させすぎてしまう、って事で
イテレーターが生み出されたんだろうな。

0818デフォルトの名無しさん

2006/03/12(日) 16:29:00

int var[N]; があったとき添え字 k を var[k] のポインタと呼んでも
一般の意味では間違いじゃあないんだよね。

0819デフォルトの名無しさん

2006/03/12(日) 16:59:10

紛らわしから一般の意味で言う場合はボインチャンって呼ぼうぜ

0820デフォルトの名無しさん

2006/03/12(日) 17:18:48

>>814
ポインタにアドレスを代入できるが
アドレスにポインタは代入できない

0821デフォルトの名無しさん

2006/03/12(日) 17:26:09

あまり関係ないが、「ポインタ」という言葉は
1) (型を持った)アドレス値
2) アドレス値を保持する変数
の２通りの使い方がされる。

厳密には1)なのだが、2)の意味で使われることも多いし、
人によっても使い方が違ったりする。

0822デフォルトの名無しさん

2006/03/12(日) 17:32:05

>>821
なにを根拠にそんないいかげんな情報を書き込んでるの？

0823デフォルトの名無しさん

2006/03/12(日) 17:34:29

ランダムアクセスできるのがポインタ
コンストなポインタがアドレス
ポインタはPOD型のイテレーター

―― C++厨の解釈 ――

0824デフォルトの名無しさん

2006/03/12(日) 17:37:07

C++厨なんて呼び方始めて見た

0825デフォルトの名無しさん

2006/03/12(日) 17:38:11

じゃ、C厨++ か？

0826デフォルトの名無しさん

2006/03/12(日) 17:38:36

飛び火しててﾜﾛｽ

0827デフォルトの名無しさん

2006/03/12(日) 17:43:10

禿中

0828デフォルトの名無しさん

2006/03/12(日) 17:44:07

>>827 ハゲいうな！
ビョーン

0829デフォルトの名無しさん

2006/03/12(日) 18:00:13

>>822
例えば、
http://www.linux.or.jp/JM/html/LDP_man-pages/man3/malloc.3.html
には、mallocが「ポインタを返す」とあるが、
mallocが返すのはアドレスの「値」であって、「変数」ではないだろ？

まあ、ぐぐってみたら、
「ポインタ」という言葉は「ポインタ変数」の意味で使われるほうが一般的
というのはわかったよ。

0830デフォルトの名無しさん

2006/03/12(日) 18:05:27

>>829
値とそれを保持する変数が同じ呼ばれ方をすることがあるのは整数型でも同じ。
ただ、あの流れで「ポインタ」と「アドレス」を混同しているのが気になった。

0831デフォルトの名無しさん

2006/03/12(日) 18:06:36

>>829
malloc が返してるのはポインタ．
それを int に評価すると，多くの場合，そのアドレスの値が得られる．

0832デフォルトの名無しさん

2006/03/12(日) 18:47:18

翔泳社の「標準講座 C++」では
「ポインタ（pointer）とは、メモリーアドレスを保持する変数のことです。」
って書いてあったよ

0833デフォルトの名無しさん

2006/03/12(日) 18:49:22

>>831
「それを int に評価すると，多くの場合，そのアドレスの値が得られる」

多くの場合、ってのがポイントだよな。

0834デフォルトの名無しさん

2006/03/12(日) 18:51:49

http://homepage3.nifty.com/mmgames/c_guide/15-04.html
こんなページみつけた

0835デフォルトの名無しさん

2006/03/12(日) 19:55:29

質問です。えーマルチです。
(書くスレ間違ったっぽい、はきだめC/C++にかいてしまった)

入力された日付(YYYYMMDD)が正しいかどうかチェックしたいのですが、
チェックする関数が見当たりません。
フォーマットが正しいかどうかなら自分でチェックすればできますが、
カレンダーにない日付もチェックしたいです。(2006/02/30はエラーみたいな)
チェック方法をしっている方おられました教えてやってください。
環境はVCでSDKです。(MFCは使ってはダメ)

0836デフォルトの名無しさん

2006/03/12(日) 20:00:48

>>835
http://www.boost.org/doc/html/date_time.html
マルチだってわかってんなら元スレからリンクぐらい貼れ。

0837デフォルトの名無しさん

2006/03/12(日) 20:01:28

>>835
方法も何もそのままだろ。
YYYY、MM、DDに切り分けて、
MMが1以上12以下でなければエラー。
DDはMMから最大日数を割り出して、(２月はうるう年も考えて)
1 <= DD <= 最大日数でなければエラー。
んな感じでいいんじゃないの。

0838デフォルトの名無しさん

2006/03/12(日) 20:07:20

>>835
おれも>>837で十分だと思うが
うるう年の算出方法は有名だし

0839デフォルトの名無しさん

2006/03/12(日) 20:08:07

>>837
そっか、スマンうるう年がいまいちわかんなくて、
便利な関数でもあればと思ったんだが、自分でチェックします。
ありがとう。
うるう年についてはここにかいてあったや。
ttp://support.microsoft.com/default.aspx?scid=kb;ja;214019

0840デフォルトの名無しさん

2006/03/12(日) 20:08:34

漏れはmktime()とlocaltime()を使うのがいいと思う。

0841504

2006/03/12(日) 20:25:04

>>840
1970年～2038年までしか扱えないっぽい・・。
作ってるアプリが2038年まで使われるとは思えないが、
boost::date_timeとやらか、自作でいこうと思います。

0842835

2006/03/12(日) 20:25:53

↑漏れは835です。

0843デフォルトの名無しさん

2006/03/12(日) 20:32:34

SystemTmeToFileTimeとか？
この答えはスレ違いだけど。

0844デフォルトの名無しさん

2006/03/12(日) 20:50:02

>>843
俺は詳しく知らないがタブンSystemTimeToFileTimeではないか？

0845デフォルトの名無しさん

2006/03/12(日) 21:02:01

あんまり細かいことを言うなや兄弟。

0846デフォルトの名無しさん

2006/03/13(月) 02:36:25

class sound{
};
class Dsound{
sound foo[2];
};
の様なクラスがあり、soundの読み込みはファイルを指定していました。
またDsoundは、2つの別々のファイルを指定するようになっていました。

このDsoundに1つのステレオ音声ファイルを読み込ませたいのですが、
よい方法はありませんでしょうか？
Dsoundが自前でステレオファイルを読み込むようにすると
sound2つを持っている意味がなくなるので、良い方法ではない気がするのですが。。

0847デフォルトの名無しさん

2006/03/13(月) 02:46:02

>>846
Dsound がステレオ音声ファイルを受け取って
sound の読み込むファイルに変換してから渡せばいいんじゃね？
C++ 関係ないな。

0848デフォルトの名無しさん

2006/03/13(月) 11:41:04

>>846
1chの音声を取り扱うクラスsoundと
Nchの音声を取り扱うクラスmulti_soundにして
class multi_sound {
std::vector<sound> snd;
};
soundでは1chのみの入出力をサポート、
multi_soundではNchまとめた入出力をサポート

と思ったが、イマイチだな。

入出力は別クラスにして、音声の実データへのアクセスはfunctorを使ったらどうだろう？

0849デフォルトの名無しさん

2006/03/13(月) 12:53:19

void f(std::string); //#1
void f(const std::string&); //#2
main() { f("TEST"); }
↑
g++: error
vc7: error
bc5: #1
Borland がぼけってことでいいと思う？

#2 もユーザ定義変換だと俺は思うが、
途中の厳密合致もカウントされるのかな

0850デフォルトの名無しさん

2006/03/13(月) 13:16:01

>>849
errorってなんだよ。何の問題もないぞ。

0851デフォルトの名無しさん

2006/03/13(月) 14:20:06

それを使いました。843、844たすかったよ。ありがとう。

0852デフォルトの名無しさん

2006/03/13(月) 15:25:56

>>850
警告じゃなくエラーね、make が止まるほう

$ g++ a.cpp
a.cpp: In function 'int main()':
a.cpp:8: error: call of overloaded 'f(const char [5])' is ambiguous
a.cpp:3: note: candidates are: void f(std::string)
a.cpp:4: note: void f(const std::string&)

問題ないって、Borland が正解ってこと？

0853デフォルトの名無しさん

2006/03/13(月) 15:53:29

>>852
VC++2003でも問題なかったけど

0854853

2006/03/13(月) 15:58:51

あ、void f(std::string&);じゃなくてvoid f(std::string)なのね。

0855デフォルトの名無しさん

2006/03/14(火) 07:01:24

newしたオブジェクトをdeleteしたのに、
タスクマネージャの該当アプリのメモリ使用量が減りません。
どうゆう事でしょうか？

0856デフォルトの名無しさん

2006/03/14(火) 07:19:27

>>855
それは、コンピュータを再起動する必要があります。

0857デフォルトの名無しさん

2006/03/14(火) 07:49:43

>>856
リークはないはずです＞＜

0858デフォルトの名無しさん

2006/03/14(火) 07:56:15

プログラムがメモリを確保するのとOSがメモリを確保するのは1対1で対応してるわけじゃないよ
OSがある程度まとめて確保してプログラムの要求で小出しする感じ

0859デフォルトの名無しさん

2006/03/14(火) 07:58:06

deleteしたメモリを何時OSに返すのか(あるいは返さないのか)は
ライブラリに一任されている。

0860デフォルトの名無しさん

2006/03/14(火) 09:53:26

じゃあ心配しないでいいんですね＾＾

0861デフォルトの名無しさん

2006/03/14(火) 11:09:36

>>860
なんでそうなる？
現にタスクマネージャから障害が報告されているんだろ？
そのアプリが意図のとおりに動かなくていいのなら心配する必要もなかろうが

0862デフォルトの名無しさん

2006/03/14(火) 11:10:06

現にタスクマネージャから障害が報告されているんだろ？

0863デフォルトの名無しさん

2006/03/14(火) 11:18:20

>861
流れ読めよ。

0864デフォルトの名無しさん

2006/03/14(火) 11:32:40

>>861のタスクマネージャは人間のことですか？

0865デフォルトの名無しさん

2006/03/14(火) 11:51:12

悪かったよ

0866デフォルトの名無しさん

2006/03/14(火) 11:54:24

僕のために喧嘩しないで＞＜

0867デフォルトの名無しさん

2006/03/14(火) 11:58:36

タスクマネージャがなにを報告してくれるの？

0868デフォルトの名無しさん

2006/03/14(火) 12:09:52

>>867
頭の優劣

0869デフォルトの名無しさん

2006/03/14(火) 13:07:13

cppllに投げられてたけど、
ttp://www.tietew.jp/cppll/archive/12614
Lambda関数とクロージャーに関する言語拡張

またぶっ壊れた案を…。（いや、あったら便利だろうけどさ）

そのうちC++言語自体が意識を持つ能動的進化を遂げるシステムとか、それなんてSF？な世界になりそうな悪寒（ｗ

0870デフォルトの名無しさん

2006/03/14(火) 13:09:24

finallyの標準化って話はないの?
そこかしこでコンパイラ拡張しまくってるのに
そんなにコストのかかる話なのかね。

0871デフォルトの名無しさん

2006/03/14(火) 13:33:12

>>870
キーワードの追加は大きいだろうな。
文法もいじることになりそうだし。

デストラクタがあるから必要性が薄いってのもあるだろう。

0872デフォルトの名無しさん

2006/03/14(火) 13:35:21

>デストラクタがあるから必要性が薄いってのもあるだろう。
これはないな

0873デフォルトの名無しさん

2006/03/14(火) 13:40:44

lambdaなんてやる暇があったら(ry

0874デフォルトの名無しさん

2006/03/14(火) 13:43:35

育毛に勤しめ。

0875デフォルトの名無しさん

2006/03/14(火) 13:45:18

exportの実装まだ～？

0876デフォルトの名無しさん

2006/03/14(火) 13:47:08

>>874
うるせー禿

0877デフォルトの名無しさん

2006/03/14(火) 13:48:51

>>870
禿がFAQでイラネって言ってるのが障害だったりしてな。
http://www.research.att.com/~bs/bs_faq2.html#finally
まずはこれに反論するのが手始めだろう。

0878デフォルトの名無しさん

2006/03/14(火) 14:13:10

http://zaraba.qp.land.to/up/src/1142313029990.jpg

0879デフォルトの名無しさん

2006/03/14(火) 14:13:36

グローバル変数int *pをプログラムの最初の方でp = new int [10]として
その後に更に配列を増やしたい時はp = new int [5]とすれば
pには15個の配列はできるのでしょうか？

0880デフォルトの名無しさん

2006/03/14(火) 14:15:21

できませんよ。結論のみいいましたが。

0881879

2006/03/14(火) 14:20:12

もし他の方法でできるのでしたら教えて下さい。

0882879

2006/03/14(火) 14:26:30

検索したら解決しました。

0883デフォルトの名無しさん

2006/03/14(火) 15:07:28

>>882
どうやってやったの？

0884デフォルトの名無しさん

2006/03/14(火) 16:44:05

vectorかrealloc使ったんじゃないの？

0885デフォルトの名無しさん

2006/03/14(火) 17:19:49

>>869
その構文がもうちょっとまともなら嬉しいんだけどな。無理だろうとは思うけど。

0886デフォルトの名無しさん

2006/03/14(火) 18:57:01

変態言語のまともな構文など逆説的変態性として排除されてしかるべきであろう。

0887デフォルトの名無しさん

2006/03/14(火) 20:56:58

C++がますます、変態、何でもあり、規格に実装が何時までも追いつかない、
そんな言語として発展しつつあって、とてもうれしいです。

0888デフォルトの名無しさん

2006/03/14(火) 20:59:56

>>869
"C++ Programming with STL.Lambda(Boost.lambda)"でいいけどな。

0889デフォルトの名無しさん

2006/03/14(火) 22:26:43

こぴーこんすとらくた

0890デフォルトの名無しさん

2006/03/14(火) 22:27:45

ぴーこ

0891デフォルトの名無しさん

2006/03/14(火) 23:15:35

Microsoft Visual C++ 2005 Expressで
C++勉強しようと思い、ブックオフで買った独習Ｃ＋＋をみながら
例題見ながら打ったら、いきなりエラーが出た。
で、http://wisdom.sakura.ne.jp/みたら、標準のヘッダ宣言は
<iostream.h>じゃなくて、<iostream>なんだね
あとusing namespaceとか。
ただ、ＶＣ＋＋６．０だと<iostream.h>で動いたので混乱した。
いつ、標準化されたの？で最近のC#もいずれ標準化されんの？
標準化されたとき、過去の定義された物に拡張された禁止事項が
増えるならわかるけど、ヘッダの宣言みたいなソースそのものを全部
書き直す事になるのって、標準化っていうの？
まぁ、俺の買った独習C++は見ると10年前出版のものだったけど
標準化ってどこの誰がしてんの、教えて。
殴りに行くから

0892デフォルトの名無しさん

2006/03/14(火) 23:17:30

【積年の】旦那にしてる密かな仕返し【恨みじゃー】
http://human5.2ch.net/test/read.cgi/ms/1141694640/

8 名前：可愛い奥様[] 投稿日：2006/03/07(火) 11:05:23 ID:8dtluKkp
夫の歯ブラシで洗面所の排水溝掃除。
洗面所をビショビショに汚した罰だ。

20 名前：可愛い奥様[age] 投稿日：2006/03/08(水) 00:40:17 ID:pRrk6A21
前に頭きた時あって
１度だけ歯ブラシで肛門カキカキしちゃった

22 名前：可愛い奥様[] 投稿日：2006/03/08(水) 01:27:12 ID:gU5mHc7J
よかった。どこのお宅も同じようなことしてて。

24 名前：可愛い奥様[] 投稿日：2006/03/08(水) 01:36:35 ID:SSSFsTqE
そうそう、ヘンなモノはダンナのお皿へ直行だよね。

41 名前：可愛い奥様[] 投稿日：2006/03/08(水) 11:55:18 ID:sjj+/60Q
見てるだけで気が晴れるな！
皆さん、頑張ってね！

42 名前：可愛い奥様[sage] 投稿日：2006/03/08(水) 20:33:51 ID:Ju2N1s7+
年金分割が楽しみじゃのう

63 名前：可愛い奥様[] 投稿日：2006/03/10(金) 08:55:20 ID:qLfJYpJR
家族で密かにはぶっている。

男性は肉体が汚く、精神が美しい傾向がある。（気に入らない相手に肉体的攻撃を加える⇒精神的攻撃も加える男は猛者）
女は肉体が美しく、精神が汚い傾向がある。（気に入らない相手に精神的攻撃を加える⇒肉体的攻撃も加える女は猛者）
女は隠れて悪事をする。気に入らない女子を便所でボコったり、便器舐めさせたり、男の友人を使ってレイプ、仲間外れにしたり。陰口、嫉妬。
女は対人関係において、この汚い性格を隠そうとするため、外面が非常によくなる。（猫かぶり）
男性諸君は外面に騙されないように気を付けて下さい。

0893デフォルトの名無しさん

2006/03/14(火) 23:17:47

標準化しているのは ISO
あと、C# は関係ない。
禿は殴らないであげてね。

0894デフォルトの名無しさん

2006/03/14(火) 23:19:52

ここ。
http://www.open-std.org/jtc1/sc22/wg21/

0895デフォルトの名無しさん

2006/03/14(火) 23:25:37

The C++ standard was published 1998-09-01 by ISO ITTF as ISO/IEC 14882:1998.
ちなみに、94年に作業原案（WD）が委員会原案（CD)になっている

0896デフォルトの名無しさん

2006/03/14(火) 23:29:54

いったんJSに吸収されたCの血統が帰ってきた。見たいな感じだね。
クロージャは便利そうだから結構ほしかった。
Lambdaとfunctionまたは、closureを予約語にしてしまったほうが綺麗なきがする。
色付きエディタで映えるし。
安易かな・・・。

0897デフォルトの名無しさん

2006/03/14(火) 23:31:15

禿はあんまし予約後を増やしたくない、みたいな話をしてたなー。
たとえば、今までclosureという変数名を使ってた奴らのことも考えてやれよ、って。

0898896

2006/03/14(火) 23:32:43

書いてる間にすれ伸びてら。

0899デフォルトの名無しさん

2006/03/14(火) 23:37:17

おっとさらに伸びてる。

>>897
俺はそんな変数名使った事ないな。
結構、根が深い拡張になりそうだからそれ位はいいと思うけどね。
一回やっちゃうと、どんどんやっちゃうから抑制のためかねぇ。

0900デフォルトの名無しさん

2006/03/14(火) 23:46:30

オートマトンの * とか closure だよね

0901デフォルトの名無しさん

2006/03/15(水) 00:15:18

>>891
独習C++も新しい版は<iostream>を使っている。
金はケチるな。新しいのを買え。

0902デフォルトの名無しさん

2006/03/15(水) 00:18:17

それにしてもなんで拡張子無しにしたんだろうか

0903デフォルトの名無しさん

2006/03/15(水) 00:28:26

つか拡張子なんていらね

0904デフォルトの名無しさん

2006/03/15(水) 00:30:32

おれはファイル名いらね

0905デフォルトの名無しさん

2006/03/15(水) 00:31:09

>>902
苦肉の策じゃまいか。
namespace って結構新しいと思ったし、今更名前かえても困る。
だから「.h 付き」は今までどおり、namespace なしのもの、
「.h 抜き」は namespace std に包んだものにしたとか。
標準化時の混乱が目に浮かぶわ。

0906デフォルトの名無しさん

2006/03/15(水) 00:34:09

>>905 だがそれがいい

0907デフォルトの名無しさん

2006/03/15(水) 00:36:21

>>905
いやその時にもうちょっとマシな命名法は無かったのかって話だ。
.hppとかあるじゃん

0908デフォルトの名無しさん

2006/03/15(水) 00:40:39

thisきーわーど

0909デフォルトの名無しさん

2006/03/15(水) 00:43:36

拡張子から離れることによって、ファイル名からヘッダ名へと抽象化されたのだ。

俺はそう思っている。

0910デフォルトの名無しさん

2006/03/15(水) 00:45:29

拡張子ないと不便だと気づかなかったのかな

0911デフォルトの名無しさん

2006/03/15(水) 00:47:54

ただのスイッチとしてコンパイラが認識するような形でもおｋっていうのを明示したんだろ。

0912デフォルトの名無しさん

2006/03/15(水) 00:49:14

>>910
たぶん夢ばっかり見て現実を見てなかったんだろうな。
.h を取っ払ったのはアホもとい前衛過ぎ。

0913デフォルトの名無しさん

2006/03/15(水) 00:49:15

>>910
プリプロセッサがヘッダ名に拡張子を付けて実際のファイル名を決めるという実装でも問題ない。

0914デフォルトの名無しさん

2006/03/15(水) 01:01:18

VBとCの根本的な違いって、何ですか？

0915デフォルトの名無しさん

2006/03/15(水) 01:04:00

目的と設計思想

0916デフォルトの名無しさん

2006/03/15(水) 01:04:47

>>914
余所逝け、ｽﾚ違いだ。

0917デフォルトの名無しさん

2006/03/15(水) 01:06:14

>>914
VB 色々楽=楽な分色々な知識が身に付かない
C 色々しんどい=しんどい分色々な知識が身に付く

0918デフォルトの名無しさん

2006/03/15(水) 01:11:00

#include 指令に指定されたリテラルがファイル実体を一意に識別するのは、ある条件を満たしている時のみ
<iostream> で引用されるファイルに「拡張子がない」などと思いこんでいる奴は天然ぼけ

0919デフォルトの名無しさん

2006/03/15(水) 01:13:28

>>918
だからそれがアホ・・・もとい、前衛過ぎなんだって。

0920デフォルトの名無しさん

2006/03/15(水) 01:13:51

>>915
>>917
なるほど、まだ自分は初心者なのでとても為になりました。
有り難う御座いました。

>>916
すいませんでした。

0921デフォルトの名無しさん

2006/03/15(水) 01:19:27

言語設計者はある程度夢を見ている方がバランスが良いと思う。

0922デフォルトの名無しさん

2006/03/15(水) 01:21:54

>>919V
おまい、V=Rでないと前衛過ぎって手合いか？

0923デフォルトの名無しさん

2006/03/15(水) 01:25:20

>>922
V→Virtual
R→Real

であってる？まぁ、そうだとしてもなにがいいたいのかよくわからん。
とにかくに俺は .h を取っ払ったのは失敗もしくは時期尚早だったと評価している。

0924デフォルトの名無しさん

2006/03/15(水) 01:27:33

a.out の拡張子も取っ払うのは時期尚早か？

0925デフォルトの名無しさん

2006/03/15(水) 01:32:36

>>924
俺は gcc を使わないからどうでもいい。

0926デフォルトの名無しさん

2006/03/15(水) 05:53:12

やってみてしばらく経った今だから見えてくるものに対して
「今となってはあれは失敗だった」というならまだしも、
あとから見えてきたことを使って当時の決断をアホだの何だのってのは
ずいぶんと卑怯な言いぐさではあるな。

0927デフォルトの名無しさん

2006/03/15(水) 06:19:13

>>926
いまとなってみれば当時の決断はアホだった、ってことだろ。

0928デフォルトの名無しさん

2006/03/15(水) 06:52:22

あんま上手な逃げ口上ではないなー

0929デフォルトの名無しさん

2006/03/15(水) 06:59:47

逃げ口上てw

まじれすだが、過去を振り返って決断が誤りだった
(決断の結果失敗した、ではない)と思うことはあるだろ？
それを批判するのが卑怯か？

0930デフォルトの名無しさん

2006/03/15(水) 07:38:06

やってみなくちゃ分からないことだったなら、
別に当時の人がアホだったわけじゃないだろ。
当時の誰もが分からなかったんだから。

まあやらずとも分かることなら、批判されてしかるべきだが。

0931デフォルトの名無しさん

2006/03/15(水) 08:04:09

当時は誰もが無知だった。

0932デフォルトの名無しさん

2006/03/15(水) 09:08:48

いい具合いなカオスの中に、発展は存在する。

0933デフォルトの名無しさん

2006/03/15(水) 09:44:05

まあどういった批判かにもよるが、当時の状況も考えずに
結果だけを見て批判するのは卑怯だな

0934デフォルトの名無しさん

2006/03/15(水) 09:53:14

卑怯なんて語が出てくるところに信心入ってるな

0935デフォルトの名無しさん

2006/03/15(水) 11:50:17

すまん。拡張子がないとなんで不便なんだ？

0936デフォルトの名無しさん

2006/03/15(水) 11:58:26

ゲイツ教の敬虔な信者だろ

0937デフォルトの名無しさん

2006/03/15(水) 12:18:17

mime type の判別が・・・

0938デフォルトの名無しさん

2006/03/15(水) 12:36:26

ヘッダファイルごときに mime type の判定をする必要性はあまり感じないし、
仮にその必要があったとしても、実際には拡張子ありのファイルを置いておいて
コンパイラが適当に判断して読みに行けばいいだけじゃん

0939デフォルトの名無しさん

2006/03/15(水) 12:46:42

その「適当な判断」も標準化せにゃならんのとちゃう。

0940デフォルトの名無しさん

2006/03/15(水) 12:53:33

拡張子は、そのファイルの内容についての「提案」であって、ファイルの内容を表しているとは限らないと思うけどな。
jpegで送ってほしいと頼むと、bmpの拡張子をjpgにして送ってくる人が後を絶たない。
拡張子など信用できない。

ヘッダ等に拡張子がなくて不便と思うのは、コードエディタ（具体的にはvimだが）で
構文強調表示を明示的に指定しないといけない点だな。
でも漏れテンプレートライブラリのヘッダは拡張子つけてないな。

0941デフォルトの名無しさん

2006/03/15(水) 12:54:08

ヘッダファイルは.hのみ。例外は許さんと言えないのがﾋﾞｮｰﾝｸｵﾘﾃｨ

0942デフォルトの名無しさん

2006/03/15(水) 13:03:43

どうでもいいけど、そろそろ次スレの時期だね。

スレタイは「C++相談室 part48」
テンプレは>>1-16
特に>>9、>>15-16に注意

標準ライブラリ・STLについての話題もC++相談室で扱う
非標準のライブラリ（Boost, Loki等）については他の専用スレ

であってるのかな

0943デフォルトの名無しさん

2006/03/15(水) 13:34:01

拡張子を入れると
いわゆるハードコーディングになるから

0944デフォルトの名無しさん

2006/03/15(水) 13:35:00

んなアホなことを言ってるのはC/C++厨だけ

0945デフォルトの名無しさん

2006/03/15(水) 13:56:19

だからプリプロセッサがどうにかすればいいだけ。

あるいはiostreamというファイルの内容が拡張子付きのファイルをインクルードするだけと言うようにするとか。

0946デフォルトの名無しさん

2006/03/15(水) 14:46:16

んなの、シンボリックリンクでいいじゃん。

0947デフォルトの名無しさん

2006/03/15(水) 15:11:10

拡張子がないと make できません！いったい！私は！どうすれば！

0948デフォルトの名無しさん

2006/03/15(水) 15:12:54

別に拡張子無くても make できるけど。

0949デフォルトの名無しさん

2006/03/15(水) 15:15:36

拡張子無しのヘッダファイルをインクルードした拡張子無しのソースを
コンパイルして、拡張子無しのオブジェクトファイルを生成し、
それをリンクして拡張子無しの実行ファイルを作る。

0950デフォルトの名無しさん

2006/03/15(水) 15:49:28

>>948
推論規則が使えないと辛いんですが。

0951デフォルトの名無しさん

2006/03/15(水) 15:50:08

別に自前のヘッダは.h付きでいいじゃん。

0952デフォルトの名無しさん

2006/03/15(水) 16:21:58

>>929
気になった単語以外何も読まずにレスするのはどうかと思うぞ。

0953デフォルトの名無しさん

2006/03/15(水) 16:49:19

同じファイル実体に対して拡張子のない名前と拡張子のある名前を同時に持たせる方法を知らなかったり
拡張子に依存した運用形態に異常な執着を持っていたり、なんかたまんねーもんあるな

0954デフォルトの名無しさん

2006/03/15(水) 16:52:00

次ｽﾚのﾃﾝﾌﾟﾚをまとめてみたよ。立てれる人お願い。

http://www.emotiongrafix.com/my/misc/cpp.txt

0955デフォルトの名無しさん

2006/03/15(水) 17:00:21

//Hello.java
class Hello
{
public static void main(String[] args){
System.out.println("hello");
}
}

0956デフォルトの名無しさん

2006/03/15(水) 18:09:01

>>955
C++でおｋ

0957デフォルトの名無しさん

2006/03/15(水) 18:13:23

ﾜﾛﾀ

0958デフォルトの名無しさん

2006/03/15(水) 21:21:18

C++相談室 part48
http://pc8.2ch.net/test/read.cgi/tech/1142423595/l50

0959デフォルトの名無しさん

2006/03/16(木) 01:35:49

>>926
当初からアホ・・・もとい、前衛過ぎると思ってましたがなにか？

0960デフォルトの名無しさん

2006/03/16(木) 10:53:36

まだ足掻くんだｗ

0961905

2006/03/16(木) 11:29:23

そんなに拡張子無いのが嫌ならincludeの中のヘッダ、
全部自分でリネームしちゃえばいいじゃん。
他の人は納得してんだから、無用な労力を負うべきだとすれば君ヒトリだ。

0962デフォルトの名無しさん

2006/03/16(木) 23:24:32

>>961
君の頭も相当アホ・・・もとい、前衛的だねぇ。

0963デフォルトの名無しさん

2006/03/16(木) 23:48:36

独りで必死に標準規格に抗うもまた良し

0964デフォルトの名無しさん

2006/03/17(金) 00:25:41

てか、お前らのなんなの？
一方は拡張子を取っ払ったことをアホだって言ってるだけだし、
もう一方も拡張子を取っ払ったことはアホだと認めてんだろ？
意見が同じなのになんでもめるの？

0965デフォルトの名無しさん

2006/03/17(金) 00:39:47

アホちゃいまんねん、パーでんねん

0966デフォルトの名無しさん

2006/03/17(金) 00:40:58

プログラマはコミュニケーション取るのが下手糞なんだよ >>964

0967デフォルトの名無しさん

2006/03/17(金) 01:11:50

拡張子なしとhppってどうやって使い分けたらいいの？

0968デフォルトの名無しさん

2006/03/17(金) 03:42:27

知るか
そのファイルを作ったやつに聞け

0969デフォルトの名無しさん

2006/03/17(金) 05:47:13

世の中にはアホしかいないから
どいつもこいつも俺の思う通りに動かない

0970デフォルトの名無しさん

2006/03/17(金) 06:31:15

.h でも .hpp でも拡張子なしでも、統一さえとれてれば何でもいいよ。

0971デフォルトの名無しさん

2006/03/17(金) 06:36:50

いちいちヘッダファイルとか作成するのﾏﾝﾄﾞｸｾ

0972デフォルトの名無しさん

2006/03/17(金) 07:57:01

>>971 Java でもつかえ。

0973デフォルトの名無しさん

2006/03/17(金) 09:46:05

.hpp は本当は保証外

0974デフォルトの名無しさん

2006/03/17(金) 10:09:52

>>973 Boost にいってやれ

0975デフォルトの名無しさん

2006/03/17(金) 10:16:35

hとhppの違いが分かりません

0976デフォルトの名無しさん

2006/03/17(金) 10:32:36

3倍もタイプ量が違うじゃないか

0977デフォルトの名無しさん

2006/03/17(金) 10:35:02

>>973
え？

0978デフォルトの名無しさん

2006/03/17(金) 10:46:42

俺の友人なんて myclass.inc とかにしてるぞ(笑

0979デフォルトの名無しさん

2006/03/17(金) 10:47:04

M$が.hを推奨してるのは明らかだしな

0980デフォルトの名無しさん

2006/03/17(金) 10:59:30

先見性が無いと言えば文字コード
JISもCP932もUCS-2もBOMも今思えば超アホなコード

0981デフォルトの名無しさん

2006/03/17(金) 11:05:04

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#533

0982デフォルトの名無しさん

2006/03/17(金) 11:05:07

半角カナをあんなとこに持ってったのは当時のハードだしあれだが、
いまだに引きずってるのがあほらしい。

0983デフォルトの名無しさん

2006/03/17(金) 11:36:22

>>982 引きずってるか？

0984デフォルトの名無しさん

2006/03/17(金) 12:31:06

incってアセンブラっぽ。

0985デフォルトの名無しさん

2006/03/17(金) 15:52:08

クラスについての質問
クラスのメンバ関数の引数のあとにconstが付いてるんだけれど、どういう意味？
自分の持ってるC++入門書には書いてなかった
void Function() const←コレ

0986デフォルトの名無しさん

2006/03/17(金) 16:07:31

>>985
constなインスタンスについてそのメンバを呼べる、ということ。
const X x;
x.Function();

0987デフォルトの名無しさん

2006/03/17(金) 16:11:51

>>985 そのメソッドの中でそのクラスのメンバ変数を
変更しませんよ、ということを宣言している。
なので変更するようなコードを書くと怒られる。

0988デフォルトの名無しさん

2006/03/17(金) 16:30:03

>>986-987
サンクス
・・すまん、どっちですか

0989デフォルトの名無しさん

2006/03/17(金) 16:43:24

>>988 どちらも同じことを言っているようにしか見えないが。

0990デフォルトの名無しさん

2006/03/17(金) 16:45:26

立場が違うけどなｗ

0991デフォルトの名無しさん

2006/03/17(金) 17:10:52

>>990
うむ。>>989 が理解できれば const は一応分かったことになるが、
const はそれだけで5杯くらいメシが食えちゃうくらい味わい深いからな。

0992デフォルトの名無しさん

2006/03/17(金) 17:13:56

constメソッドの中でSTLコンテナ使おうとしてハマるに１票

0993デフォルトの名無しさん

2006/03/17(金) 17:39:05

int main(const int argc, const char* const* const argv) {
処理
}

で、 boost::program_options を使おうとしてハマった。
なんで両方とも const とらなきゃならんのだよぉ

0994デフォルトの名無しさん

2006/03/17(金) 18:04:48

argc は確かに変だけど、argv は仕方ないだろ
ISO/IEC14882 3.6.1 Main function ではっきり非 const とされている

0995デフォルトの名無しさん

2006/03/17(金) 18:10:40

>>994 どうせ argc は値渡しだろうし、
argv の方で怒られてたんだろうな。
そうか、規格で非 const とされてたか。
それは知らなかった。

0996デフォルトの名無しさん

2006/03/17(金) 18:21:09

ていうかおまいはどこでconstとして覚えたんだ

0997デフォルトの名無しさん

2006/03/17(金) 19:35:26

>>996 わかんね。
たぶん人からもらったソース(笑

0998デフォルトの名無しさん

2006/03/17(金) 20:23:56

>>994
おいおい，嘘いっちゃいかんよ．

3.6.1 の 2 に「It shall have a return type of type int, but otherwise its type is implementation-defined.」とあるように，戻り値だけは決まってるけどあとは実装による．const を許す実装があったってかまわない．

0999デフォルトの名無しさん

2006/03/17(金) 20:27:12

>>998
多分、>>994の真意は、「規格で明示的に認められているmainの型は引数にconstがついていない」ということだろう。

1000次スレ

2006/03/17(金) 20:43:15

C++相談室 part48
http://pc8.2ch.net/test/read.cgi/tech/1142423595/l50

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。