C++相談室 part61 - 暇つぶし2ch

C++相談室 part61 ..

752:デフォルトの名無しさん
08/05/10 17:33:03
>>747
言いたいことがよくわからない。
キーが与えられたら要素を返す method と代入する method (というか
メンバ関数）を作るってことじゃないの？変更がどうあるのかもよくわからん。

753:デフォルトの名無しさん
08/05/10 17:47:52
XYZにoperator< を定義してsetに突っ込む

754:デフォルトの名無しさん
08/05/10 17:52:37
>>747
3次元座標値ってどんな領域なのよ？

まず問題の概要を説明しやがれ
このスカポンタン

755:デフォルトの名無しさん
08/05/10 17:55:46
>>754
そこは重要じゃないだろ

756:デフォルトの名無しさん
08/05/10 18:01:09
これでいいだろ
#include<map>
class XYZ {
int x, y, z;
public:
XYZ(int x, int y, int z) : x(x), y(y), z(z) {}
bool operator<(const XYZ& rhs) const {
return x < rhs.x || (x == rhs.x && (y < rhs.y || (y == rhs.y && z < rhs.z)));
}
};
int main()
{
std::map<XYZ,int> m;
m[XYZ(0,1,2)] = 100;
}

757:デフォルトの名無しさん
08/05/11 05:35:20
#include <new>
としているコードを見かけますが、
わざわざ<new>をインクルードするのなぜなのでしょうか?
インクルードしなくてもnewは普通に使えますよね？

758:デフォルトの名無しさん
08/05/11 11:02:53
いらないと思うんだった、コメントアウトして再コンパイルしてみればいいんじゃね？

単に習慣でインクルードしてるだけかもしれないし。

759:デフォルトの名無しさん
08/05/11 11:14:42
placement new, std::nothrow, std::bad_alloc を利用する際にインクルードするヘッダファイルであって、
普通の new を使うためにインクルードするヘッダファイルではない。

760:デフォルトの名無しさん
08/05/11 11:23:57
>>757
precement newやnew演算子のオーバーロードをするときに使う。

761:デフォルトの名無しさん
08/05/11 11:28:16
オーバーロードする際に必要だっけ？

762:デフォルトの名無しさん
08/05/11 11:28:52
そんな事はない

763:デフォルトの名無しさん
08/05/11 11:29:54
だよねー

764:デフォルトの名無しさん
08/05/11 12:34:18
かわいい女の子が寝る前に
1分間枕元に立ってくれるための
おまじないだと、先輩から聞いたことがる。

765:デフォルトの名無しさん
08/05/11 15:51:39
映画版呪怨ですね。わかります。

766:デフォルトの名無しさん
08/05/12 00:39:48
struct xstring_traits{
　　　bool is_w() const {...}
　　　...
};
struct vstring_ref { // デフォルトコピーコンストラクタ使用
　　　const xstring_traits* tr_;
　　　const char* begin_;
　　　const char* end_;

　　　const wchar_t* wbegin(){return tr_->is_w() ? reinterpret_cast<const wchar_t*>(begin_) : NULL;}
　　　...
};
struct vstring_buffer {
　　　const xstring_traits* tr_;
　　　char* begin_;
　　　char* end_;
　　　...
};
struct vstring {...}; // コピーでメモリ再確保

767:766
08/05/12 00:40:35
(続き)

やっぱ引数がconst std::stringだと
std::string以外から受け取る場合のコストが気持ち悪いし、
const char* でことあるごとにstrlenとかするのも無駄だし、
WindowsだとTCHARとかの場合もあるけど、
WinAPIに関係無い部分にまで<tchar.h>入れるの嫌だし。

で、ただでさえ多い文字列クラスをさらに増やすのかと
葛藤しつつも自作文字列クラスを・・・。

皆はやっぱり普通にstd::string？
Windowsの場合は、
typedef std::basic_string<TCHAR>する人もいるよね。

768:766
08/05/12 00:41:33
×引数がconst std::string
○引数がconst std::string&

769:デフォルトの名無しさん
08/05/12 00:55:18
俺は、普段はconst std::string&で済ます。
std::basic_string<TCHAR>のtypedefもWindowsプログラムならよく使う。
767も言うコストが気になるならRangeを引数に取るテンプレートにする。

770:デフォルトの名無しさん
08/05/12 01:29:45
スレチだけど俺は TCHAR でちゃんと動くコード(mbcsをちゃんと処理するコード)を
書く気はさらさらないので、欺瞞的なTCHARの使用はなるべく避けてWCHARにしてる。

771:デフォルトの名無しさん
08/05/12 01:44:18
俺も全部 TCHAR で書いてるけど、string::find とか平気で使ってるわ。
mbcs じゃほとんど動かんコードになってる。

772:デフォルトの名無しさん
08/05/12 07:10:43
>>767
文字数が必要ならこうする手も。

void hoge(const char* str, size_t len) { }
inline void hoge(const std::string& str) { hoge(str.c_str(), str.length()); }

773:デフォルトの名無しさん
08/05/13 13:28:40
なんで、private継承、protected継承すると、アップキャストができなくなるのだ？

774:デフォルトの名無しさん
08/05/13 13:44:30
外からprivateなメンバにアクセスできないのと同じ
外からprivateな基本クラスにはアクセスできない

775:デフォルトの名無しさん
08/05/13 13:48:23
>>773 外からできなくなるだけで、中からならアップキャストできるよ。

776:デフォルトの名無しさん
08/05/13 17:32:36
private継承するboost::operatorsがなんで動作するのかも良くわかんないな。

777:デフォルトの名無しさん
08/05/13 17:41:24
分かんない事ばかりなのに使わなければならないC++って、怖くね？

778:デフォルトの名無しさん
08/05/13 17:47:31
>>776
friend関数はクラスのメンバではないから・・・かな？

class　A　{
private:
　　friend　void　foo()　{　...　}　//　メンバのように見えるけど実はグローバル関数なのでアクセス制御は効かない
};
int　main()　{
　　foo();
}

779:デフォルトの名無しさん
08/05/13 17:48:13
C++以外の言語も使いますが分からないことだらけです。

780:デフォルトの名無しさん
08/05/13 19:36:07
何が分からないか判っていれば解ったも同然だ

781:デフォルトの名無しさん
08/05/13 19:54:24
friend関数、VC2005からtemplate<class T>を頭につけないと
コンパイルが通らなくなったんですね。C++0xはまだなのに
こういう仕様変更はひそかにやってるんですか？

それとも、もともと規格書にはこう決められていてやっと
Vc++2005で対応できた、ということですか？

782:デフォルトの名無しさん
08/05/13 20:31:33
>>777
わかんない部分は無理して使う必要はないし。
でも、わかった後それを使うと今までだらだら長く書いていたコードがすっかりコンパクトにまとまってショックを受けることが多々ある。

783:デフォルトの名無しさん
08/05/13 20:43:20
>>781
それは後者

でも前者みたいなひそかな変更もVC++はよくやる。
いや、きちんと文書化されているけどね。
例えばtype traits支援とかC99の%a書式とか。

784:デフォルトの名無しさん
08/05/15 12:41:47
もう C++ なんて好きでもないし使いもしない理由。
URLﾘﾝｸ(www.hyuki.com)

悔しいけど納得した。

785:デフォルトの名無しさん
08/05/15 13:24:39
確かにめんどくさいし手間が掛かる…

786:デフォルトの名無しさん
08/05/15 14:04:26
C++ Programming Languageを端から端まで二度読める知能があれば右辺値参照ごときにどうして瞼が落ちるのか。

787:デフォルトの名無しさん
08/05/15 14:14:04
落ち着かない仕様
時間の掛かる修正
度重なる保守

788:デフォルトの名無しさん
08/05/15 14:15:27
C++は仕事に向かない言語とういのには同意だな

789:デフォルトの名無しさん
08/05/15 14:30:05
C++ Programming Languageを二度読むのに必要なのは知能ではなくて忍耐力だからな

790:デフォルトの名無しさん
08/05/15 14:57:10
性能に取り憑かれているのは自分でも気づいているがどうしてもやめられない。

791:デフォルトの名無しさん
08/05/15 15:08:56
Java も使うけど、C++ の方が楽に感じる事多いな。
気を付けないと保守が大変というのはわかる。
ただ、どの言語でも保守の問題はあるし、気を付ければ
そんなに問題ないと思ってるけど。まぁ、5年後になんて
言っているかはわからんが。

792:デフォルトの名無しさん
08/05/15 15:57:49
C++の全機能を使わなければならない、という規約でもあったのだろうか？
演算子オーバロードは危険だと思ったなら、単にその機能を使わなければよい。
参照は不要でポインタがあれば十分だと思ったなら、単にその機能を使わなければよい。
添え字が範囲の中にあるかテストしてほしいと思ったなら、at()メンバ関数を使えばよい。

なぜ、C++の全機能 vs Cの比較なんだろう？
C+α(Better C) vs Cの比較をしないのはなぜだ？

要するに、マヌケだってことだ。

793:デフォルトの名無しさん
08/05/15 16:00:18
>>784のリンク先

C++に過剰に複雑なところがあるのは同意なので、
その人(翻訳者でなく)がC++嫌ですって言うこと自体に批判は特に無いけど、
ちょっとツッコミ書くてｓｔ。

＞C の方を使いたくなる
別に複雑な機能を使わなくても、
　・#defineマクロ(MAXなど)の代わり程度のtemplate
　・fopen,fcloseみたいなのをRAIIに扱うための極薄ラッパー
などの簡単で便利なものだけ「better C＋おまけ」程度に使えば良いと思う。
巧みで知識もあると言う割には、要領が悪い気がしないでもない。

＞Java や Groovy に
そこでGroovyは無いと思う・・・

俺もjava好きだから良いんだけど、
もうちょっと他の言語も挙げれば良いのに・・・

794:デフォルトの名無しさん
08/05/15 16:17:12
>そこでGroovyは無いと思う・・・
ググったら実質両方Javaでワロタｗ

795:デフォルトの名無しさん
08/05/15 16:22:57
>>792
> C+α(Better C) vs Cの比較をしないのはなぜだ？
自分一人で遊んでいるときしか、そういう使い方がうまくいかないからでは。

796:デフォルトの名無しさん
08/05/15 20:19:22
なぜ今更そのネタを

797:デフォルトの名無しさん
08/05/15 21:02:02
>>792
> C++の全機能を使わなければならない、という規約でもあったのだろうか？
あるとしたら逆だろう。○○しか使ってはいけない、という規約が無くてカオス化する。
あるいは、そういう規約がちゃんと機能して、自分の仕事がうまくいっているとしても、
「ここまでの規約が無ければ収拾つかなくなるC++って・・・」という虚しさは感じることになる。

「C++に文句を言う奴は、C++を使い切れないマヌケだけ」
というのは、C++信者の反撃としては割とお約束だし、部分的には当たっている。
実際、「一人でちょっとしたものを作ることさえできない」人間の八つ当たりも結構見られるし。
ただ、C++の難点というのは、主に「個人の能力ではどうにもならないところ」に表れるものであって、
この話を個人の能力に全部収めて着地させようというのは、わかっててやってるなら
いかにも姑息な「問題のすり替え」ではある。

798:デフォルトの名無しさん
08/05/15 21:14:38
> 個人の能力ではどうにもならないところ
ってどこだろう

799:デフォルトの名無しさん
08/05/15 21:19:29
他人の脳味噌は自分の脳味噌ではない、という事実とか、
そういう風にして複数の脳味噌によって構築された「すんげえ規模」とか。

800:デフォルトの名無しさん
08/05/15 21:21:47
名前マングリングとかABIとかじゃね

801:デフォルトの名無しさん
08/05/15 21:37:50
C++最高！とまでは言わないが、ハードと離れた言語は使う気しないな

802:デフォルトの名無しさん
08/05/15 21:39:21
>>799
それはC++に限った話じゃないな
CでもJavaでもPHPでもよくある話だ

>>800
ABIが規定されていてうまく機能している言語ってあります？

ちなみに、自分はC++信者なわけではない
素直な感想と疑問

803:デフォルトの名無しさん
08/05/15 22:46:45
>>797
どの言語でも仕事で coding する時は文法的に正しければなんでも良い
なんてことは無いはずだが。規約を全く無くせば収拾つかなくなると思うが。
規約を決めるのを C++ に限ったことではない。

元の記事はむしろ binary の compatibility を問題にしてるんじゃないかな。

804:デフォルトの名無しさん
08/05/15 23:05:02
>>802-803
「有るか無いかでいったら、どの言語にだってあるぞ」
というのは確かにその通りだけど、この場合はC++の「度合いのひどさ」を問題にしているわけで、
ゼロじゃないからどの言語もみんな仲間！　ってのは、話の持って行き方としてちょっと違うと思う。

805:デフォルトの名無しさん
08/05/15 23:15:56
>>804
でもJavaぐらいだと>>799の問題は似たようなものな気がするけど
だんだん複雑になってきてるし
ある程度表現力が高い言語になると普遍的な問題じゃないかな

C++だとまともに書けない人でもJavaなら書けるのだろうか
そんな人がPythonならまともに書けるのか？

806:デフォルトの名無しさん
08/05/15 23:39:39
規模の問題はちょっと違うだろうね。

名前マングリングに関しては確かにC++のは委員会とかの人も
普通に「どうにかしたい」って思ってそうだけど、
実質、ABIがさえ合えば問題無し、って程簡単じゃないから
再コンパイルした方が良い。

UNIX、Linux系ではオプションの変更程度で再makeすることも多いし。
それに完全にバイナリで使うなら.soとか.dllで考え方が良い。

807:デフォルトの名無しさん
08/05/15 23:46:07
例外とか this ポインタの実装手段の違いとかも問題になるんじゃね。

808:デフォルトの名無しさん
08/05/16 00:27:21
>>797 で言っている問題で、何でも使うか使わないかは、
compile し直そうが残る問題が多いけど。特に保守性考えると。

件の ABI の問題は compile し直せばいい問題じゃないの？
（だから問題になりえないと言っているわけではないが）

ちょっと違うことを問題にしていて議論が混ざってる気がする。

809:デフォルトの名無しさん
08/05/16 21:20:35
質問があります

代入演算子をprotectedないしprivateにしたいんですが、
実装はデフォルトで生成されるものそのままでいいんです

class Hoge
{
　// さまざまなメンバ変数(代入演算子があったりなかったりする)
　Hage hage;
　Fuga fuga;
　int hensuu;
protected:
　Hoge& operator=(const Hoge&);
};

ってやったらリンクエラーになるんですがどうすればいいでしょう
イチイチ中身書くのも面倒で・・・

810:デフォルトの名無しさん
08/05/16 22:07:43
イチイチ中身書くしかない

811:デフォルトの名無しさん
08/05/16 23:25:47
C++0x では default キーワードでデフォルト実装を作ってくれるそうです。

812:デフォルトの名無しさん
08/05/16 23:26:25
handle-bodyイディオムで書いて、handleの代入演算子をprotectedなりにすればどう？

813:デフォルトの名無しさん
08/05/17 01:09:30
バイナリとしての0x00をchar配列に格納したいんですが、終端文字として認識されてしまいます。
こういう時ってどうすればいいのでしょうか？？
ご教示いただけると幸いです。

814:デフォルトの名無しさん
08/05/17 01:16:56
もしかしてstrcpyとか使ってるのか?

815:デフォルトの名無しさん
08/05/17 01:21:39
レスどもです。
いえ、const char [] 型に0x00を含む文字列を格納して、cout とかで出力しようとすると0x00以降が出力されないんです。

816:デフォルトの名無しさん
08/05/17 01:22:37
考えるだけでも恐ろしい

817:デフォルトの名無しさん
08/05/17 01:22:59
それは当たり前　仕様　0は文末というのが原則です。

818:デフォルトの名無しさん
08/05/17 01:24:21
出力させたいんだったら、string使えば出来るはず。　こっちはサイズまではちゃんと出力したと思う。
たとえばstr.resize(10000,'\0'); cout<<str;とする。

819:デフォルトの名無しさん
08/05/17 01:24:53
とすると、バイナリとしての0x00を途中に含むchar文字列を作りたいんですが、無理なんでしょうか？？

820:デフォルトの名無しさん
08/05/17 01:25:58
0を含むchar配列はできるよ　でもstrlenとかは間違える　自分で長さを管理すればよい。

821:デフォルトの名無しさん
08/05/17 01:27:56
たとええばchar配列で0を含まないならstrcpy、strcmpなどを使い、
0を含むなら長さを自分で指定するmemcpyやmemcmpを使う。

822:デフォルトの名無しさん
08/05/17 01:28:55
いや作れるよ
char配列の内容がNTCSであることを仮定している関数・APIに
NTCSでないchar配列を突っ込んでいることが間違いなだけ

823:デフォルトの名無しさん
08/05/17 01:47:42
なるほど！
0x00を入れると格納はされているけど出力できていなかったということですね。
長さを指定したら出力できました。
レス下さった方々ありがとうございましたｍ(_ _)ｍ