1read 100read
2013年01月プログラム64: C++相談室 part98 (763) TOP カテ一覧 スレ一覧 2ch元 削除依頼
【統計分析】機械学習・データマイニング3 (203)
GCCについて part10 (234)
推薦図書/必読書のためのスレッド 69 (468)
【マック】Macintoshプログラミング質問箱 (544)
D言語 Part30 (915)
Pythonのお勉強 Part47 (919)

C++相談室 part98


1 :2012/09/18 〜 最終レス :2013/01/14
最近勉強始めた超初心者なんだが
参考書のプログラム書いてコンパイル時に
エラーE2316 seftはostreamのメンバーではない関数ってエラーが出てしまった。
原因が自分で調べてもわからなかったんで
分かる人が居たら教えて欲しい。
以下ソース↓
//seft02.cpp
#include <iostream>
using namespace std;
int main()
{
int a = 10, b = 100;
cout << "16進数表示" << endl;
cout.seft(ios::hex, ios::basefield);
cout << "a = " << a << endl;
cout << "b = " << b << endl << endl;
return 0;
}

2 :
このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
                  京都大学霊長類研究所

3 :
柵(しがらみ)

4 :
なんでスレ立ててんだよ
こっちでやれ そしてここは削除依頼しろ
C++相談室 part98
http://toro.2ch.net/test/read.cgi/tech/1345823164/

5 :
で?

6 :
>>1 setfの間違い。

7 :
このスレはpart99という事にして再利用するか?

8 :
えっと、次ここでいいのか?
======
初期化リストを返す関数って許されていますか?
下に貼るコードの動作がおかしくて困っています。
また、forward_listにすれば解決はしますが、
何度も呼ばれる場合、パフォーマンスは初期化リストの方がいいですよね?
#include <iostream>
#include <utility>
#include <initializer_list>
std::initializer_list<int> test(const std::pair<int,int>& e) {
//return {1,2,3}; //ok!
return {e.first,e.second,e.first}; //undefined?
}
int main()
{
for (auto i: test(std::make_pair(1,2))) {
std::cout << i << std::endl;
}
}

9 :
ムリポ

10 :
コンパイルは普通に通っちゃうんだけど・・・

11 :
うん

12 :
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレに
お願いします。
前スレ
C++相談室 part98
http://toro.2ch.net/test/read.cgi/tech/1347964922/
(従ってこのスレは実質part99となります)
姉妹スレ
【初心者歓迎】C/C++室 Ver.80【環境依存OK】
http://toro.2ch.net/test/read.cgi/tech/1348161305/
■長いソースを貼るときはここへ。■
 http://codepad.org/
 http://ideone.com/

13 :
■基本■
[C++ FAQ]
 http://www.parashift.com/c++-faq/
 http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
  Cとその仕様を比較しながらの解説なので分かりやすい。
  ***** 質問の前に必ずこの二つに目を通してください *****
[C/C++ リファレンス]
 http://en.cppreference.com/w/cpp (英語)
 http://ja.cppreference.com/w/cpp (↑の日本語訳だけどまだ未完)
[Stroustrup]
 http://www.stroustrup.com/
[C++ International Standard]
 http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=50372
[JTC1/SC22/WG21 - C++]
 http://www.open-std.org/jtc1/sc22/wg21/
  ここから規格の最新ドラフトがダウンロードできる。
[JIS X3014]
 http://www.jisc.go.jp/app/pager?%23jps.JPSH0090D:JPSO0020:/JPS/JPSO0090.jsp=&RKKNP_vJISJISNO=X3014
  ISO規格の日本語訳。JIS X3014:2003はISO/IEC 14882:2003 (E)に対応。

14 :
■Books■
amazon C,C++関連書籍
 http://www.amazon.com/exec/obidos/tg/browse/-/3956/ref=br_bx_c_1_3/
 http://www.amazon.co.jp/b/?node=754384
The C++ Programming Language
 http://www.amazon.com/exec/obidos/ASIN/0201700735/
 http://www.amazon.co.jp/exec/obidos/ASIN/475611895X/ (翻訳)
C++ Primer (3rd Edition)
 http://www.amazon.com/exec/obidos/ASIN/0201824701/
 http://www.amazon.co.jp/exec/obidos/ASIN/4756140068/ (翻訳)
The C++ Standard Library
 http://www.amazon.com/exec/obidos/ASIN/0201379260/
 http://www.amazon.co.jp/exec/obidos/ASIN/4756137156/ (翻訳)
Effective C++
 http://www.amazon.com/exec/obidos/ASIN/0201924889/
 http://www.amazon.co.jp/exec/obidos/ASIN/4756118089/ (翻訳)
More Effective C++
 http://www.amazon.com/exec/obidos/ASIN/020163371X/
 http://www.amazon.co.jp/exec/obidos/ASIN/4756118534/ (翻訳)
Exceptional C++
 http://www.amazon.com/exec/obidos/ASIN/0201615622/
 http://www.amazon.co.jp/exec/obidos/ASIN/4894712709/ (翻訳)
More Exceptional C++
 http://www.amazon.com/exec/obidos/ASIN/020170434X/
 http://www.amazon.co.jp/exec/obidos/ASIN/4894714833/ (翻訳)
Exceptional C++ Style
 http://www.amazon.com/exec/obidos/ASIN/0201760428/
 http://www.amazon.co.jp/exec/obidos/ASIN/4894714663/ (翻訳)

15 :
■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/

16 :
■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 C++ Standard Library (STDCXX) http://stdcxx.apache.org/
 STLFilt http://www.bdsoft.com/tools/stlfilt.html
 (日本語) http://episteme.wankuma.com/stlprog/ (※1999年発行注意)
[Loki]
 http://sourceforge.net/projects/loki-lib/
 LokiPort-MSVC6sp5 http://fara.cs.uni-potsdam.de/~kaufmann/?page=lokiport

17 :

STLつかうと一気に実行ファイルサイズが10倍に?!
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: プリコンパイル済みヘッダーの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの?
#include <stdafx.h>
後R。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
------------------------------------------------------------------
一応テンプラ書きました

18 :
>>8
http://cpplover.blogspot.jp/2011/05/initializerlist.html
こんなのがあるからだめだろうね
規格票にはどう書いてあるか探してみるけど

19 :
>>18
ありがとうございます。
しっかし委員会の人たちは本当に偉いな・・・。
何年も前から知ってるけどこれからも頑張ってほしい。

20 :
Pimplイディオムの意義がよく分かりません
コンパイル時間を縮めるとあるのですが、どうにも理解出来なくて・・・

21 :
パンプル

22 :
インターフェースさえ決まっていれば中身を何度変更しようがコンパイルされるのは1つのcppだけで済む

23 :
PImplで作ったオブジェクトをコピーすると普通の方法ではポインタが指す実体が一つしかないため
Deep Copyにならない
インターフェース内に代入演算子関数やコピーコンストラクタを書くと正常に動作するがそうすると
中身を変更する度に代入演算子やコピーコンストラクタも変更しなければならないため
PImplの意味が失われてしまう
コピーしない場合に限りPImplを使うか、コピーするための特別なスマポを作る必要がある

24 :
pimpl_ptrとか一回作ればその問題は終わりだろ
素人でも1時間あればそれなりのものは作れる

25 :
クラスでnewを使って
動的にインスタンス生成することの
メリットが分かりません
教えて下さい

26 :
>>25
ばーか^^

27 :
あっはっは

28 :
>>25
メリットなんなない。
止めたほうがいい。

29 :
>>20
1. コンパイル時間を縮める
2. private メンバをヘッダから隠せる
これが pimpl の意義
通常は private メンバを変更しただけで
そのヘッダをインクルードしている全ての .cpp が再コンパイルされる
private メンバなんて外部から見えないのだから、これは非常に不合理だと言える
pimpl を使えば private な実装が全て1つの .cpp 内に収まるので
private な実装を変更する限りにおいては1つの .cpp が再コンパイルされるだけで済む
また、private な実装を他から隠匿出来るという点が
商業的に役に立つ場合がある

ただ、pimpl 以外にも似たような事を行う方法はある
まずインタフェースだけのクラスを作って、
そのクラスを継承して実装し、その派生クラスの生成関数だけを外部に公開する、というもの

両者は1, 2の目的を満たしているという点でよく似ているけど、
生成したメモリを管理する責任の所在が異なるというのと、
あとはここから更に継承したいという場合に違いが出てくる

30 :
>>29
> 通常は private メンバを変更しただけで
> そのヘッダをインクルードしている全ての .cpp が再コンパイルされる
private関係ねえぞ。
お前の書くソースは汚そうだ。

31 :
pimplって何て発音するの?

32 :
>>29
> 通常は private メンバを変更しただけで
> そのヘッダをインクルードしている全ての .cpp が再コンパイルされる
「再コンパイルされる」じゃねえぞ。
「しなければ問題が起きる」もしくは「実害の有無に関わらず、すべきである」のいずれかの問題だ。馬鹿が。

33 :
>>31
ぽいんぽる

34 :
今日はウソツキ村からの観光客がやけに多かったですね

35 :
>>31
ttp://www.nicovideo.jp/watch/sm758341

36 :
>>31
http://translate.google.co.jp/#en/ja/pimpl
左の窓の下のスピーカーのアイコンクリックしてみ

37 :
>>32
まともなプログラマなら「通常は」依存関係を元に
自動的に再コンパイルされるような環境でプログラムするので
「通常は」再コンパイルされる
理論的に再コンパイルしなくても実害がない場合もそりゃあるが(メンバ関数だけ増やした時とか)、
それでもまともな環境でプログラムしてりゃ通常は再コンパイルされる

38 :
cppファイルあるのにprivateメンバなんて書くか普通?
普通に匿名名前空間に関数おけばいいだろ

39 :
publicメンバにしか触れないじゃん

40 :
>>39
こいつ最高にアホ

41 :
メンバ変数への参照を渡すって事か
正直プログラムが読み辛くなるだけだぞ

42 :
>>41
いっぺんやってみればわかるけど関数にしたほうがわかりやすい
引数で副作用を絞れるからバグも減るから良いことしかない

43 :
>>37
再コンパイルされるなら何も問題ないんじゃない?

44 :
>>25
・生成するインスタンスの数を実行時に決定できる
・インスタンスの寿命をより自由に制御できる

45 :
全コンパイルに数時間かかるシステムの構築に関わればpimplのありがたみがわかるよ

46 :
>>32
それは確かに問題だろうが、
今の論点とは関係ないだろ

47 :
>>43
時間がかかる

48 :
>>42
そんな変なプログラムは他の人が保守し辛い

49 :
>>48
そういう実装を好む会社と仕事をしたことがあるが、
完全に C の思想になっていると感じた

50 :
なんでもかんでも自分でやりたい奴って思考がCだよな

51 :
>>50
確かに
Cはもう時代遅れになりかけている
それにもかかわらず高いシェアを未だに誇っているというのはCOBOLと同じで
老害が多いって事

52 :
COBOLは保守が主なんだから老害なんていったらバチが当たるぞ

53 :
保守してる奴は老害だろ

54 :
なんじゃそりゃ。アホかいな。

55 :
>>51
Cでなきゃ何でファームウエアやドライバを書くんだ
方言は当然ありとして
おまえら結局ファームエアもドライバも作りたくないって
仕事をえり好みしてるだけだろ
若いのがそんなていたらくであることが
今の製造業のピンチを招いたんだよ

56 :
>>55
典型的な老害思考
C++で書いてもCと同じように書けば問題ない

57 :
C++でかいたらでかくなるでしょ

58 :
小さくて速いのがいいのだ

59 :
>>57
Cの機能だけを使えばならねーよアホ
使った事ねーんだな

60 :
>>58
かぶりものは?

61 :
>>56
方言はありだと言っただろう
Cの流れを汲む言語をすべて含むという意味だ
おまえせいぜい片手できくくらいしか知らねえだろ
それから C++ の C にない機能をふんだんに使っても
ヘボがバカやらない限り問題なんか起きねえよ
要注意は例外と RTTI くらいだがコンパイラのマニュアルをよく読むこった

62 :
>>61
それ論理的におかしなことになってるだろ

63 :
>>50 「なんでもかんでも自分でやりたい奴って思考が(C++ではなく)Cだよな」
>>51 「確かに (C++と違って)Cはもう時代遅れになりかけている」「それにもかかわらず高いシェアを未だに誇っているというのはCOBOLと同じで老害が多いって事」
>>55 「Cでなきゃ何でファームウエアやドライバを書くんだ 方言は当然ありとして 」
>>56 「典型的な老害思考 C++で書いてもCと同じように書けば問題ない 」
>>61 「方言はありだと言っただろう Cの流れを汲む言語をすべて含むという意味だ (ゆえにC++はCに含む)」

64 :
61は頭悪そう

65 :
>>63
つまりアレか
C++ 独自の機能が C の何に相当するか見通せてないんだな
クロージャや intializer_list がおまえにとっては魔法の箱か

66 :
>>65
何そのちぐはぐな反応は

67 :
>>66
何だその荒唐無稽な反応は

68 :
>>66
何だその焼肉定食な反応は

69 :
>>57
C++で書くと大きくなる妄想乙

70 :
実際でかくなるでしょ

71 :
C++じゃだめだ

72 :
おなじ機能で、C版とC++版をつくってるよ。いつもC++のほうがでかい

73 :
コンパイラによるだろ
VCやgccはiostreamや例外を使わないとほとんど同じになっちゃうぞ

74 :
増加分の具体的な明細に立ち入ったことないやつがテキトーほざいてるだけだよな

75 :
例外処理は仕方ないとしても
IOstreamはライブラリとかじゃなく
別言語に移管し改めてitegrateすべき時期に来たと思うんだ

76 :
自分一人で勝手にしてれば?

77 :
>>72
そりゃSTLをたっぷり使うとか、大きくなるような書き方をしてるだけだ

78 :
>>48
その程度で保守できなくなるなんてよほどの低脳なんだなぁ
class Type {
OtherType m;
void PrivateFunc();
public:
void Method();
};
void Type::PrivateFunc() { m.DoSomething(); }
void Type::Method() { PrivateFunc(); }
これを
class Type {
OtherType m;
public: void Method();
};
static void PrivateFunc(OtherType & m) { m.DoSomething(); }
void Type::Method() { PrivateFunc(m); }
こうすればコンパイルコストの削減、不要なメンバアクセスによる副作用の予防といった明らかなメリットがデメリットなしに見込める
たったそれだけの話なのに何がそんなに難しいんだろうか?
低IQの脳みそって本当にかわいそうだわ


79 :
>>78
コンパイルコストごときを理由にそういう設計が振り回されるか

80 :
>>79
逆に聞くがこれを否定する論理的な理由は?

81 :
class Type {
OtherType m;
public: void Method() { m.DoSomething(); }
};
これでいい

82 :
>>80
privateメソッドの仕様はクラスの仕様と不可分
クラス外で定義するのは危ないよな

83 :
>>78
あなたの言ってるメリットは、実装以降どころかコンパイル以降の話。
それらの都合のためにオブジェクト指向を否定するかのごとく設計に犠牲を強いているようだ。

84 :
>>82
危ないって?
匿名関数のどこが危ないの?

85 :
>>83
C++はもともと純粋なオブジェクト指向言語じゃないですよ?
あなたのほうこそ自分の勝手な都合でC++の能力を犠牲にしていませんか?

86 :
>>78
> static void PrivateFunc(OtherType & m) { m.DoSomething(); }
これが綺麗に見えるのは幻覚。
使っているprivateメンバー変数がたった一個だから。
このメンバーも使おう。さらにこれも、と追加していったとき、
privateの範囲内で当該クラスに閉じた世界の話になるはずなのに、
そのやり方していたら、そのクラスとクラス外の様々なstatic関数に広く影響を与えることになる。
そんな作り方してると内部仕様の変更に対する隠れた抵抗勢力になる。
そういうのでがんじがらめにしておくと、悪い方への変化はしやすいけど、良い方への変化はしにくくなる。
それは誰かを陥れるために使う戦略で、日常は使うな。

87 :
>>78
君はその道を突き進めばいいと思うよ
俺はついていかないけど
でもそっちの世界の人達も頑張って欲しい

88 :
>>86
ねえ君はアホなの?
短いレスでサンプルを示すためにあえて十分小さい例を出しただけなのに、それに噛み付いてくるなんて言葉遊び覚えたばかりの中学生みたいな反応で笑えるね
メンバーが増えれば増えるほど匿名関数のほうが有利になるんだけど?
増えたメンバーのうちその処理にひつようなメンバのみにアクセスを絞ることができるから
メンバ関数を直接書くより遥かに信頼性、安全性が高い
馬鹿はメンバ関数そのまま書いて無秩序にメンバにアクセスし整合性を保つ難易度を上げている
というかそもそも君はなにか勘違いしてるだろ
この匿名関数はそのクラスのプライベートメンバとして作られるのだから
クラスの内部仕様の変更でこの匿名関数に変更があってもクラスの外部には1バイトも影響しないんだが?
まずそこから理解することからはじめよう
なにごとも最初の一歩が肝心だよ
君は初心者かもしれないけどそこはちゃんと押さえておこう。いいね?

89 :
>>88
ひとまとめにしてなんかの意味を持たせようというところにクラスの意義があり、それはprivateなメソッド(メンバ関数)とて同じことなのだが、
それをわざわざstaticな関数にばらし、クラスのメンバ変数の形にばらし、と要素にくだり細部フォーカスとするのは、それではなんのためのクラスか首をかしげるのだが?
privateなメソッドであっても、そのクラスがクラスの形を保っていることに意味があるんでは?
それともprivateな処理は、クラスというまとまりをばらしてしまうことの方がおおいのか?
static な関数の引数に、クラスのメンバ関数がずらずら並ぶのは、アクセスを明示する意味ではいいのだが、他にメリットがみえてこない
むしろ「まとまり」を欠いた散漫なコードにみえる

90 :
コンパイルを速くするためだけにクラスをばらばらにする奴とは一緒に仕事したくないな

91 :
>>78
それでコンパイルコスト削減になってると思うのがチャンチャラおかしい

92 :
>>78
もう大人しくCでプログラム組んでろ

93 :
今日もC++に助けられました。感謝。
コンパイラの性能、強い型、程よい暗黙の変換などがなければ、困難なデバッグを諦めていたことでしょう。
Javascriptのデバッグとか考えただけで身の毛もよだつ・・・

94 :
プロファイラでお薦めありませんか?
struct A {
void func1();
void func2();
};
みたいなのがあったときに、単純にそれぞれにかかった合計時間が計測できればいいのですが・・・

95 :
http://p11.chip.jp/okanonaoko

96 :
>>78
典型的なCに染まった老害だろ
たまに現場にいるけどここ十数年ほどは干され傾向だろ

97 :
>>89
教科書を開いてクラスをもういちど勉強したほうがいいよ
クラスの重要チェックポイントをいくつかあげるとすると
・公開されたプロパティと処理の一箇所への集中
・カプセル化による詳細の隠蔽
・継承とポリモーフィズム
なんだよね
要するに非公開であるべきクラスの実装の詳細がどうなってるのかなんてものはクラスの概念にはまったく必要ない話なんだよ
privateなメンバ関数であろうが外部の匿名関数だろうがその選択によってクラスとして正しいか正しくないかなんてのは変わらないんだ
だとしたらこの部分は純粋にその機能としての優位性で選ぶのが正しいIT技術者のあるべき姿だろう
君もここで、またひとつ勉強になったね
第二段落の質問への答えだが、プライベートな処理はまとまりをばらすことが非常に多いよ
それは当然だろう。クラスの公開機能を実装するためのサブ処理をメンバ関数や匿名関数で行うのだから
それがクラスの一部分だけを処理するのは当然の話だ
それと、君は『むしろ「まとまり」を欠いた散漫なコード』にみえるというが
目に見えないだけで不要な変数にも平気でアクセスでき、副作用を生み出しかねない状況のほうが
遥かにまとまりの無い不安定な状況であるということを自覚しようね
おそらくだが、君はいまだに、コードの「見た目」が気に入らないだけでその機能的な部分に美意識を持っていないように見受けられる
それは識別子を並べたときに不ぞろいだ、汚い、と感じ無駄なスペースやタブでこぎれいに並べようとする無意味で低俗な美意識と同じことだよ
そういうのは素人から中級者にありがちなことなのだが、しっかりと勉強し成長すればコードの見た目より機能的な合理性と美しさというものを理解し優先するようになる
君は今はまだその段階に無いが君もいずれ理解できるだろうから心配しなくてもいい
>>91
君のプロジェクトにある適当な良く使われているクラスをピックアップし
@新しいプライベートメンバ関数をヘッダに追加し、cppに実装を書く
A新しい匿名関数をcppに書く
場合に分けてリビルドしたときのコンパイルコストを実測してみなさい
それで判らないなら君は時計を見る能力を持っていないことになるので病院で診断を受けることをお勧めする

98 :
>>97
だらだらと長くて美しくない文章を書く人ですね

99 :
http://toro.open2ch.net/tech/
みんなこっち行こうず
IDあるほうがまだマシ

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼
WindowsDDK各種についてのスレ (750)
C++相談室 part98 (763)
TypeScript part1 (326)
【3DS】プチコンを語るスレ【DSi】 (676)
だめです! HSP厨は絶対に犯罪です。 (947)
【最速へ】LowLevelVirtualMachine【LLVM】 (520)
--log9.info------------------
まおゆう魔王勇者 13 (911)
リトルバスターズ!は原作通り池沼を独善で救う糞アニメ9 (799)
ラブライブ! 活動5日目 (811)
PSYCHO-PASS サイコパス 係数オーバー41 (861)
新世界より 神栖40町 (560)
マギ−MAGI− 第28夜 (501)
たまこまーけっと Ωおもち16個目 (799)
閃乱カグラ 4っぱい (363)
gdgd妖精s(ぐだぐだフェアリーーズ) 39代目 (219)
宇宙兄弟 part26 (467)
ヤマノススメ 3合目 (268)
僕は友達が少ないNEXT 隣人部活動記録98ページ (451)
ガールズ&Rァー GIRLS und PANZER 359輌目 (610)
聖闘士星矢Ω -セイントセイヤオメガ- 119星座 (813)
キューティクル探偵因幡 2 (502)
問題児たちが異世界から来るそうですよ? Part3 (229)
--log55.com------------------
【戦場の絆】どんな質問にも全力で答えるスレpat69
【賞金戦】戦場の絆将官晒しスレ301【笑官戦】
BORDER BREAK ボーダーブレイク1723GP
スーパードラゴンボールヒーローズ第164弾
【GP参戦】戦場の絆第480戦隊 【再盛期☆】
【ジオン】戦場の絆Aクラ晒し251【崩壊BTL】
【BBC】BASEBALL COLLECTION 4球目
Wonderland warsワンダーランドウォーズ晒しスレ101