C++相談室 part97

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

前スレ
C++相談室 part96
http://toro.2ch.net/test/read.cgi/tech/1341029267/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.79【環境依存OK】
http://toro.2ch.net/test/read.cgi/tech/1341052801/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　http://ideone.com/

■基本■
[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://www2.research.att.com/~bs/
[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)に対応。

■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/ (翻訳)

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

　　　　　　　 ,　'´　　_. -‐'''"二ニﾆ=-`ヽ、
　　　　　　／　　 ／:::::; -‐''"　　　　　 　 `ｰノ
　　　　　/　　　／:::::／　　　　　　　　　　　＼
　　　　 /　 　 /::::::/　　　　　　　　　 |　|　|　 |
　　　　 |　　　|:::::/　/　　　　　|　　|　|　|　|　 |
　 　 　 |　　　|::/　/　/　|　　| ||　 |　| ,ﾊ .| ,ﾊ|
　 　 　 |　　　|/　/　/　/|　,ﾊﾉ|　/|ﾉﾚ,ﾆ|ﾙ'
　　　　 |　　　|　 |　/　/ ﾚ',二､ﾚ′ ,ｨｲ|ﾞ/　　　私は只の数ヲタなんかとは付き合わないわ。
.　　　 　|　　　＼ ∠イ　 ,ｲイ|　　　 ,`-' |　　　　　　頭が良くて数学が出来てかっこいい人。それが必要条件よ。
　　　　 | 　　　　l＾,人| 　` `-' 　 　 ゝ　 |　　　　　　　　さらに Ann.of Math に論文書けば十分条件にもなるわよ。
　 　 　 | 　　　　 ` -'＼　　　 　 　ｰ' 　人　　　　　　　　　　一番嫌いなのは論文数を増やすためにくだらない論文を書いて
　　　　|　　　　　　　 /(l 　　 　＿＿／　 ヽ、　　　　　　　　　　　良い論文の出版を遅らせるお馬鹿な人。
　　 　 |　　　　　　　（:::::`‐-､__ 　|::::`､ 　 　 ﾋﾆﾆヽ、　　　　　　　　　あなたの論文が Ann of Math に accept される確率は?
　 　　|　　　　　　／ `‐-､::::::::::`‐-､::::＼　　 /,ﾆﾆ､＼　　　　　　　　　　　　それとも最近は Inv. Math. の方が上かしら？
　　　|　　　　　　|::::::::::::::::::|` -､:::::::,ﾍ￣|'､　 ﾋﾆ二、　＼
.　　 |　　　　　　/::::::::::::::::::|::::::::＼/:::Ｏ`､::＼ 　 |　'､　　 ＼
　　 |　　　　　 /:::::::::::::::::::/:::::::::::::::::::::::::::::'､::::＼ﾉ　　ヽ、　 |
　　|　　　　　 |:::::／:::::::::/:::::::::::::::::::::::::::::::::::'､',::::'､ 　/:＼__/‐､
　　|　　　　　 |／:::::::::::/::::::::::::::::::::::::::::::::::Ｏ::| '､::|　く:::::::::::::￣|
　　 |　　　　 /_..-'´￣`ｰ-､:::::::::::::::::::::::::::::::::::|/:/`‐'::＼;;;;;;;＿|
　　　|　　　　|／::::::::::::::::::::::＼:::::::::::::::::::::::::::::|::/::::|::::/:::::::::::/
　　　 |　　　/:::::::::::::::::::::::::::::::::|:::::::::::::::::::::Ｏ::|::|::::::|:::::::::::::::/

メモリ4GBで、別に困ってはいない
しかし、ずっと4GBでいい、とは思っていない
一応、8GBまで増やせるから、そのときが来たら8GB搭載させる

だが、現実問題として、4GBで困ってない
ぶっちゃけ2GBでも困らない

じゃあ、今のPCのメモリを2GBに減らせるのかと考えると、なんか減らしはしたくない

こうしてステマにハメられて、メモリは増加の一途をたどってきたのだ

だからこそ、あえての16GB搭載マシンを買う
それがチョイ悪オヤジの、「あえて」の外し方

>>6
で？

テンプレ貼り完了

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

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

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

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

#include <stdafx.h>
後死ね。

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

仮想環境動かすとなると
メモリ2GBとかカツカツであり得ない

office2000で書類つくったりIE5.5でネット見てるぐらいなら2GBで十分。
OSはWindows2000Professionalな

>>10
仮装マシンがウィンドウズなら厳しいが、リナックスならわりと大丈夫

Better Cで、別に困ってはいない
しかし、ずっとBetter Cでいい、とは思っていない
一応、C++03の仕様まで知ってるから、そのときが来たらC++03の機能まで使う

だが、現実問題として、Better Cで困ってない
ぶっちゃけCでも困らない

じゃあ、今後コードをCで書くかと考えると、なんか書きたくはない

こうしてステマにハメられて、言語機能増加をたどってきたのだ

だからこそ、あえてのC++11対応コンパイラオプションを使う
それがチョイ悪オヤジの、「あえて」の外し方

Windows Meで、別に困ってはいない
しかし、ずっとWindows Meでいい、とは思っていない
一応、Windows XPまで更新できるから、そのときが来たらWindows XP搭載させる

だが、現実問題として、Windows Meで困ってない
ぶっちゃけWindows 98SEでも困らない

じゃあ、今のPCのOSをWindows 98SEに載せ替えるかと考えると、なんか載せ替えたくない

こうしてステマにハメられて、OSはバージョンアップの一途をたどってきたのだ

だからこそ、あえてのWindows Vista搭載マシンを買う
それがチョイ悪オヤジの、「あえて」の外し方

==だけじゃなくて!=もオーバーライドしないとだめなの？

#include<utility>にあるstd::utilty::re_opsをusing namespaceするなら==だけでいい

http://www.cplusplus.com/reference/std/utility/rel_ops/

まじか
!=がなにをやっても真だから気が狂いそうだったわ

vectorを継承しようとしたら、おばあちゃんに「やめなさい」と言われたんだけど
具体的には何がどういう理由でダメなの？

お前のおねだりの仕方が下手だったんだろ

>18
お前のばーちゃんハイスペックだな……

>>18
http://www.google.co.jp/search?q=virtual+%E3%83%87%E3%82%B9%E3%83%88%E3%83%A9%E3%82%AF%E3%82%BF+%E6%9C%AA%E5%AE%9A%E7%BE%A9

>>21
ありがとう
vectorを継承するなら、デストラクタを明示的に呼び出せばいいのね

ん？それじゃ解決にならないような
問題は基本クラスのナマポでdeleteした場合、サブクラスのデストラクタが呼ばれないこと
動的削除子がサポートされているスマポを使えば問題ない

vector<T>のポインタで削除しなければいいだけだから。

継承して、かつ、親クラスの箱には収まらないようにできれば
克服できるってことじゃろうか

C++でfcntl()ってどのヘッダ使うの？
cstdlibみたいなのある？

それはOS依存ググレ

>>18
仮想デストラクタがないという理由とか？
でもポインタ経由でないなら安心のような気も

というか>>21に書かれてた

>>23
これは初めて知った
スマポ便利過ぎる

class A {
int* ip;
public:
A(int i = 0) : ip(new int[i]) {}
// virtual ~A() { delete[] ip; }
~A() { delete[] ip; }
};

class B : public A {
double *dp;
public:
B(int i = 0) : dp(new double[i]) {}
~B() { delete[] dp; }
};

int main()
{
A* ap = new B;
delete ap; // メモリリーク発生！

boost::shared_ptr<A> sap(new B); // 放置してもメモリリークは発生しない
}

>>18
コンピュータおばあちゃんwww

A *b=new B
をエラーにする方法ってある？

継承しなければいい

>>32
もう少しくやしく

こんなやつに継承されるなんて……くやしいっ…！

>>34
く、くそっ。笑ってしまったｗ　くやしいっ…！

>>31
protected継承

>>36
ありがとう
これでvectorを継承してvector *a=new Bekutaをエラーに出来る

private継承でええやん

>>31
private継承
アクセス権の変更でstd::vectorにはキャストできないが、
std::vectorのフル機能をラッピング関数なしで公開できる。

struct Example:private std::vector<int>
{
　　using std::vector<int>::push_front;
　　using std::vector<int>::push_back;
　　・・・以下略・・・
};
ちなみにusingは省略可。なんでusingと書けるかはしらん。

包含でええやん

どっちがいいかな
やってみなくちゃわからない

包含より権限の格上げの方が記述量すくないぞ。
オーバーロードの面倒見る必要ないからな

>>39
省略するな
てか、using宣言とアクセス宣言を混同するな

>>43
したら何が困るん？

ランダムな文字列を作る関数ってstringに無かったっけか
見つからん。 気のせいだったかな。

無いよ

>>43
>using宣言とアクセス宣言を混同するな
???

> ???
どうやら本気でわからんようだな
地味ながら右辺値参照と比肩する問題かも

クラス及び構造体内で使用するusingって付けようが付けまいが
動作上は全く同じ仕様だよな

>>48
右辺値参照が問題？
勘違いでないのなら、２つの問題をそれぞれ示してくれ。

7月２９日に行われた「脱原発」の抗議行動前に
日比谷公園で行われていた反日左翼たちの集会の様子
その後、この労組を中心とした反原発デモ行進が始まった。ｗｗｗｗｗ
http://blog-imgs-44.fc2.com/d/e/l/deliciousicecoffee/DSCN1478.jpg
http://blog-imgs-44.fc2.com/d/e/l/deliciousicecoffee/DSCN1479.jpg
http://blog-imgs-44.fc2.com/d/e/l/deliciousicecoffee/DSCN1494.jpg
これで、「多様な人たちが自由に何の制約もなく参加している」とか
「組織型の運動との違いを感じ…」などと良くも言えるものだ！


7月29日　国会包囲　反原発デモに参加された一般人？？？の方々ｗｗｗｗｗ

日大全共闘
http://blog-imgs-44.fc2.com/d/e/l/deliciousicecoffee/DSCN1540.jpg
芝工大全学闘＆明大全共闘
http://blog-imgs-44.fc2.com/d/e/l/deliciousicecoffee/DSCN1542.jpg
アジア共闘●＆三里塚闘争勝手連＆日米軍事同盟反対　アジア米軍総撤収
http://blog-imgs-44.fc2.com/d/e/l/deliciousicecoffee/DSCN1547.jpg
9条の会
http://blog-imgs-44.fc2.com/d/e/l/deliciousicecoffee/DSCN1582.jpg
郵政労働者ユニオン
http://blog-imgs-44.fc2.com/d/e/l/deliciousicecoffee/DSCN1588.jpg
芸大教組
http://blog-imgs-44.fc2.com/d/e/l/deliciousicecoffee/DSCN1600.jpg
緑の党
http://blog-imgs-44.fc2.com/d/e/l/deliciousicecoffee/DSCN1603.jpg
ピースボート (社民党&北朝鮮)
http://i.imgur.com/lY0nX.jpg
http://mamorenihon.files.wordpress.com/2011/05/peaceboat.jpg

今話題の滋賀県教組
http://takemikazuchi.iza.ne.jp/images/user/20120723/1875097.jpg

>>40
Semper fi! Do or die!

private継承って便利やね

shared_ptrの動的削除子とweak_ptrとshared_from_thisはそうとう強力だよな。

これだけのためにboostをいますぐ入れるべき。

c#なら、んな面倒ないのになぁ

C#でもリソースは扱うだろ
そこらへんは変わらんよ

>>54
アプローチの仕方が全く異なる言語を持ちだされて例えられても困る
C++はGCがなく、パフォーマンスを最重要視した言語
いわばGCに相当する作業を自分でやる

例えばリアルタイムな応答が必要なクリティカルな部分を走らせている
時に突然GCが走ってしばらく固まったりしたら致命的
ゲームなんかはそう
他にもこういう場面は多いだろう
計測機器とか
もう時間的に余裕が出来てから初めて不要なリソースを解放する
用途が違う

ガベコレは別スレッドでやればいいじゃん
今時そんなんで止まらないよ

>>57
「GCが無いのは省いているから」でFAにしとけよ……

今時速度面でGCで困る事はないよ
大量に開放されるのが嫌ならできるだけ
未参照領域を作らないようにすりゃいいだけ
問題なのはアホみたいなメモリー消費量
アプリケーション起動数やスレッド数に影響するし
切迫してる場合はスライシング起こす

打ち間違えたスライシングじゃなくてスラッシング

なんかC++の実行バイナリって、妙にでかくね？ 気のせい？

気のせい

気のせい

キーの自動入力で悩んでいます。
http://oshiete.goo.ne.jp/qa/4023937.html
上の質問の解答の使い方を「何度も」実行すると
Access violationというエラーが出てしまいます。
何度も実行（キーの自動入力）できるようにするにはどうしたらよいでしょうか。
アドバイスをよろしくお願いします。

>>57
再入不能な処理を別スレッドでやると何かいいことあるのか？

>>57
技術的に無理な事を書かれてもねえ

開放したメモリの整列処理を別スレッドでやるプールアロケータとかなら作れるかも

std::vector<Hoge> h(10);
の動作が、VC++とCentOS 5 gcc で違うのね。

windows:10回コンストラクタが呼ばれる
linux:1回コンストラクタが呼ばれ、9回は初めに生成したもののコピー

これでハマッタorz。

はまる場合って？
中に動的生成なメンバを持っていて自前のコピーコンストラクタが書かれてないとか？
それって何か問題ある？

元々コピーを考慮してないクラスだったんだろ

バージョンすら書いてないがその違いってC++03とC++11の違いじゃねーの
http://en.cppreference.com/w/cpp/container/vector/vector

>>70
それだと潜在的なバグなわけで、どっちみちいつか問題が露呈する
と言うかvectorのメンバ関数push_back()ですらコピーコンストラクタを
呼び出すだろ
どういう事をしようとしていたんだ？
C++11の場合一時オブジェクトならムーブコンストラクタを呼び出すが

>>71
2) Constructs the container with count copies of elements with value value.

としか書いてないから実装の違いだね

ヘッダから自動的にcppを作るスタイルがいいのか
cppから自動的にヘッダを作るスタイルがいいのか
どっちがおすすめかしら

待て待て間違っていた

3) Constructs the container with count value-initialized (default constructed, for classes) instances of T. No copies are made.

だね

No copies are made.

だからC++11はコピーで初めに生成した値を広げる動作はしない事が保証されているのか
じゃあC++03の実装の違いとしか言いようがない
そんな事で問題が出るようなクラスの書き方をする方が間違っている

>>69-70
shared_ptr を内包させたクラス。

コンストラクタでインスタンスを生成していたのだが、
2個目以降が1個目のコピーになると、1つのインスタンスを共有する10個の要素ができる。
vector<Hoge> hoge(10,Hoge());


>>71
visual studio 2010 vs gcc44 4.4.6
なるほど、さんくす

＞vector<Hoge> hoge(10,Hoge());
で解決した・・が抜けた

>>75
なるほどこういう罠があったからC++11ではコピーコンストラクタで初期化値を
広げるのをやめたのか

めんどくせえなcppって
高級なのに中身意識しないとバグるとかゴミやん

参照とポインタの使い分けをどうしようか
結局のところ単にヌルチェックを省けるポインタなんだよな

自動で " を \" に変換してくれるストリーム
って作るの簡単？

streambufを自作すればできると思う

fizzbizzより簡単な気がする がんばれ

マジかよナベツネより簡単な話だったのか
おれはどこにも入社出来そうもない気がしてきた

>>82
厳密には文字コードを考慮すべきじゃね

>>84
char16_t

wchar_t ならまだしも16_tなどと前方位救いようの無いアホウを口汚く罵倒したい方も多いと思いますがわかんないヤツには何言っても判らんので
続きは文字コードスレで

と、知ったかぶるのでした

「情報弱者」と呼ばれないために 〜たとえ政治に興味がなくとも、これを知ることは国民 の義務です

http://farm8.staticflickr.com/7145/6520530187_c0c80ff8a7_b.jpg
http://farm8.staticflickr.com/7013/6719110227_2855a7ef07_b.jpg
http://farm7.staticflickr.com/6188/6138002658_85eb1d2445_b.jpg
http://farm8.staticflickr.com/7205/6887664245_d57b0f4279_b.jpg
http://farm8.staticflickr.com/7037/6891009867_1095f43d34_b.jpg

template<typename T,typename U> struct super
{
typedef T t;
typedef U u;
};
template<typename T,typename U> struct sub : public super<T,U>
{
void test()
{
u index;
sizeof( u );
}
void test(u index)//ここ
{}
};
ここでu is undefinedというエラーが出ます。何故でしょうか。
VS2008だと出ません。

本物のエラーメッセージ見ないことには断言できないが、
typename super<T,U>::uと書いてないからじゃないか？

>>75

shared_ptr自体はコンテナ用件満たすけど、そいつを持ってるクラスはコンテナ用件満たしてるの？
満たしてないもんをvectorとかに入れない方がいいよ。

どうしてもいれたいなら、そのクラスをshared_ptrで来るんで入れればOK。

コンテナ要件ってなに？

これならgcc4.7.1でNo Warningで通った

template <typename T, typename U>
struct Super {
typedef T t;
typedef U u;
};

template <typename T, typename U>
struct Sub : public Super<T, U> {
void test() {
typename Super<T, U>::u index;
std::cout << sizeof(index) << std::endl;
}
void test(typename Super<T, U>::u index) {
std::cout << sizeof(typename Super<T, U>::u) << ' ' << index << std::endl;
}
};

int main()
{
Sub<double, float> ss;
Super<double, float>::u ss2 = 123.4f;
ss.test();
ss.test(ss2);
}

コンテナ要件とは

§23.1 Container requirements

このうちboost::shared_ptr(C++11ならstd::shared_ptr)は

4 In Table 64, T is the type used to instantiate the container, t is a value of T,
and u is a value of (possibly const) T.
Table 64 Assignable requirements

expression　return type post condition
t = u 　　　　T&　　　　 　 t is equivalent to u

の条件を満たさないので入れてはいけない
(代入した途端に内部状態が変化してしまう)

>>94
状態が変化したところで "t is equivalent to u" を満たしているから問題ないのでは？

>>93
そもそもVS2008で通るのが間違いなんですか？

>>94
それはおかしい
post conditionが等価なら内部状態が変化してもいい

問題はstd::vector<Hoge> h(10);　のように書いてるからでしょ

std::shared_ptrは宣言と同時にポインタの参照先を指定しなければならない
それをどこも指してないスマポを入れるからおかしくなるんだろ

つまりスマポを含んだオブジェクトをコンテナに入れる時は、入れる時に既にスマポが
どこか具体的なオブジェクトを指している状態になっていなければならない

だからvectorの宣言時に大きさを指定したりresize()する事なく、push_backもしくは
push_frontで代入すれば問題が起きない

ちょっと考えてみればこの意味がわかるはず

>>97
> std::shared_ptrは宣言と同時にポインタの参照先を指定しなければならない
>>98
> つまりスマポを含んだオブジェクトをコンテナに入れる時は、入れる時に既にスマポが
> どこか具体的なオブジェクトを指している状態になっていなければならない

んなわけねーだろ。

>>98
最初のスマポをどこか指してる状態にしてpush_back()してresize()しても
おかしくなる可能性があるぞ

要するにresize()は使わない事と、大きさを指定する場合はデフォルトの
一時オブジェクトを指定すればいいんだろと思う

C++11はその辺何をしても問題が起きなくなってるんだろうな

簡単に言うとC++03が定められた時に実装の違いによってboost::shared_ptrのような
参照カウントを持つスマポを入れた時の挙動まで予測してなかったんだろう

それでContainer Requirementsが舌足らずなんだよ

C++11の規格票を見るとずっとその辺が厳密になっているよ
それとスマポの穴が閉じてある

この先またboostで変な物が出てくるとまた規格をすり抜ける可能性はある

>>100-101
shared_ptr のコピーがオブジェクトを共有するのは当たり前なわけだが、
「おかしくなる」だとか「スマポの穴」だとか、お前ら何のこと言ってんの？

>>102
「実装の仕方」で挙動が変わるような規格ではダメって事

念のためISO/IEC14882:2003を読んでみた

§23.2.4.1 vector constructors, copy, and assignment
Complexity: The constructor template <class InputIterator> vector(InputIterator
first, InputIterator last) makes only N calls to the copy constructor of T (where N is the
distance between first and last) and no reallocations if iterators first and last are of forward,
bidirectional, or random access categories. It makes order N calls to the copy constructor of T
and order logN reallocations if they are just input iterators.

とあるので、はっきりとコピーコンストラクタを呼び出すと書いてある
これは実装の違いではなく、実装の仕方を規定している
これがshared_ptrのようなオブジェクトには不都合なんだろう

resize()は

§23.2.4.2 vector capacity
void resize(size_type sz, T c = T());
6 Effects:
if (sz > size())
insert(end(), sz-size(), c);
else if (sz < size())
erase(begin()+sz, end());
else
; //do nothing

となっているので問題は生じないと思われる

C++11では変わっているかと思うと

>>103
C++03 では vector<T>(n) はデフォルト引数とし生成される T() の n 個のコピーになると決まっている。
「「実装の仕方」で挙動が変わる」って、何のこと言ってるの？

23.3.6.2 vector constructors, copy, and assignment
10 Complexity: Makes only N calls to the copy constructor of T (where N is the distance between
first and last) and no reallocations if iterators first and last are of forward, bidirectional, or random
access categories. It makes order N calls to the copy constructor of T and order log(N) reallocations
if they are just input iterators.

と書いてあり変わっていない。もう少し注意深く読むと

explicit vector(const Allocator& = Allocator());
1 Effects: Constructs an empty vector, using the specified allocator.
2 Complexity: Constant.
explicit vector(size_type n);
3 Effects: Constructs a vector with n value-initialized elements.
4 Requires: T shall be DefaultConstructible.
5 Complexity: Linear in n.
vector(size_type n, const T& value,
const Allocator& = Allocator());
6 Effects: Constructs a vector with n copies of value, using the specified allocator.
7 Requires: T shall be CopyInsertable into *this.
8 Complexity: Linear in n.

とあり、やはりサイズのみを指定した場合の実装は規定されていない。最初にデフォルトコンストラクタ
で初期化したオブジェクトをコピーコンストラクタでコピーしてもいいし、n数回デフォルトコンストラクタを
呼び出しても良い。つまりC++11であってもshared_ptrを入れる場合はC++03同様注意が必要
という事になる。これは互換性を重視したために仕様を変更しなかったのだろう。

しかし>>75のような不都合が残ったままというのはやはり不安を感じる。

>>105
だから、使う側が注意しないといけないわけ

vector<T>(n)でshared_ptrを入れると、参照カウントがnになった状態になる
vector<T>(n, Obj())のように明示すればn回デフォルトコンストラクタが呼び出され、
それぞれの参照カウントが1になる

それだけの事

>>106
> explicit vector(size_type n);
> 3 Effects: Constructs a vector with n value-initialized elements.
> 4 Requires: T shall be DefaultConstructible.

この規定でコピーしていいわけないだろ。

>>107
C++03 だったらどっちも同じ。 C++11 なら、逆じゃね？
（ Obj() は T() の間違い？）

>>109
だな
C++03だと vector<T>(n) は vector<T>(n, Obj()) の事になるので同じ
C++11だと vector<T>(n) はそれぞれがデフォルトコンストラクトされ、
vector<T>(n, Obj()) は Obj() がコピーされる

紛らわしいな
だれかスパッと纏めて

スマポ使用禁止
コンテナ使用禁止

スマポなんて元から使わないしwww
スマポは弱者の道具、車椅子みたいなもんだからね
コンテナは使うから許して

>>111
vector<T>(n), vector::resize(n) について。

C++03 では (n, value) と同じオーバーロードがデフォルト引数 T() で呼び出されて
value の n 個のコピーからなる vector が得られた。
（ただし resize(n) は呼び出し前からあった要素はそのままね。）

C++11 での右辺値参照導入に際して、おそらくこれらの操作がそのままだと
CopyConstructible を要求することになってしまって理不尽な要求や無駄なコピーを
生じてしまうことから、 DefaultConstructible だけで使えるようにそれぞれ n だけを
受け取るオーバーロードが追加されて n 個それぞれ個別に初期化された要素からなる
vector が得られるようになった。

この変更によって、例えば >>75 のように T が内部に shared_ptr を持つような
オブジェクトの場合の shared_ptr の use_count(), unique() などについて
vector<T>(n) などの結果が変わることになってしまった。

vectorの中身ってポインタにするか実体にするか悩むよね

いやべつに。

ばあいによる
つまり悩む

実体で不都合が出たらポインタにするだけじゃないの？

実体はソートパフォーマンス悪いからポインタかな
ムーブがあると大差なくなるんだっけか

テンプレートって中身もヘッダに書かないといけないの?
どんどんヘッダが大きくなって、ヘッダの意味なくね?

ヘッダの意味って何？

基本はそうだが、次世代のはプリコンパイル済みて黄な粉とやってくれたような

export 復活しないかな
しっかり練り直して

>>119
誰かgccでムーブコンストラクタあり/なしでSTLのパフォーマンスがどの位変わったのか
テスト出来ないかな

俺の所のgccは4.7.1にしてあるので-std=c++0xがデフォルトになってしまったらしくて
テスト出来ない

以下についてご教授下さい。
既存のソースをDLL化するに当たってテスト的にVisual Studio 2005にて
「C++ クラスライブラリ」と「C++ コンソールアプリ」の２つのプロジェクトを起こしてテストをしています。
ここでクラスライブラリプロジェクト側で以下のようなコードを記述しました。
typedef struct s {
　int a;
} S;
namespese testdll {
　public ref class Class1 {
　public:
　　S sss;
　}
}
これをビルドすると「S sss;」の記述でC4368のエラーとなってしまったので、ネットで調べてポインタで定義することにしました。
S sss; → S *sss;
これでビルドが通ったので、コンソールアプリプロジェクトに上記で作成したDLLの参照を追加し、以下の様なコードを記述しました。
using namespace testdll;
int main(array<System::Class1::String ^> ^args) {
Class1 tt;
　tt.sss = new S;
}
これをビルドをするとC2248のエラーになってしまいます。
メンバ変数sssはpublicで定義しているのですが何故かprivateの扱いになってしまいアクセスすることができません。
アクセサを作成すればアクセスすることは出来るのですが、出来ればアクセサを使わずにpublicでアクセスできればと考えています。
DLL側の定義方法が悪いのか、呼び出し方が悪いのか検討がつかず困っています。
改善策をご教授いただければ幸いです。よろしくお願い致します。

それC++じゃないよ

C++/CLIはC++じゃねーつってんだろ！

>>125
まずC#で書け

つーかpublicフィールドなんて作るなよ

フィールド言うな

環境によってwcslen()がstdの中に入ってたり入ってなかったりするのですが
この違いを同じコードで吸収する方法ありますか

入ってないってことはないんじゃないか

>>124
-std=c++98 すればいいんじゃないの？

>>131
Cのヘッダは<c〜>を使わず、<〜.h>を使う。
尤もMicrosoftの規格違反糞コンパイラ使わないのが正解だがね。

msのにはあるぞ

>131
wcslenが要るところだけusing namespace stdる。
...
{ using namespace std; hoge=wcslen(...)}
...

もろちん、
> 尤もMicrosoftの規格違反糞コンパイラ使わないのが正解だがね。
なのは当然である。

>>134
>Cのヘッダは
昔の本でC++のコード中に<iostream.h>とか書いてる奴あったこと思い出したｗ

VC6談義が捗るな

>>130
つ[C++/CLI]

別言語だしな
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-372.pdf

>>139
CLIでもfieldとdata memberは別物扱いだぞ

>>141
ダウト
ttp://vene.wankuma.com/ecma372/04_definition.aspx

朝鮮人の扱い方
　 ∧ ゝ∧
　（　´∀｀）　　　【 旧日本陸軍の朝鮮兵に対する注意書き】
.ノ��|ソ|"＼
＼ﾉ」==ヽ!ノ
　/＿l ＿|
一、いつ、いかなる時でも唐辛子粉を食事に際し好きなだけ使わすこと。
一、絶対に頭、体を叩いてはいけない。怨みを持って復讐する気質があり、脱走の原因となる。
一、清潔な食事運搬用バケツと雑巾バケツの区別をよく教えること。
一、危険な状況下では銃を投げ捨てて哀号！と泣き出す習癖があるから、日本兵二名で一名の朝鮮兵を入れて行動せよ。
　　＿＿
　 │　　|
＿☆☆☆＿
　（ ´_⊃｀） 　 【米軍による韓国兵の扱いマニュアル 】
　（　 ∞　）
　｜ ｜　|　
　（_＿）＿）
１．韓国人には強気で押せ。抵抗する場合は大声で命令しろ。　２．命令を聞かない場合は身体で解らせろ。
３．同じことをくり返す場合、犬のように何回でも同じ様に叱れ。こちらが上と言うことを身体で解らせろ。
４．理由は聞くな。どうせ大したことは言っていない。
５．身体で解らせた場合、根に持つ場合があるので、後で身辺には気をつけて行動しろ。但し、徹底的に解らせる迄、手を抜いてはいけない。
６．相手を3才児と思い、信用したり頼りにはするな。重要な仕事は任せるな。
　,,,,,,,,,,,,,,,,
　ﾐ,,,,,;露;;;,ﾐ
　∩；｀_っ´∩
　ヽ　　　 /　 　【 旧ソ連共産党による朝鮮の扱い方 】
　　|　　　|
　　 し⌒Ｊ
1、頭痛の種になるだけだから関わるな　2、手段を選ばぬキチガイ揃いだから関わるな
3、関わるとこっちが痛い目に遭うから関わるな　4、関わってきたらウォッカ飲んで忘れようぜ

C++11ではdecltypeで関数の返値の型推論できるけど
C++11使わないで返値が入力で代わる関数の
返値型をtemplateみたいな方法で指定する方法ないものでしょうか

>>143
出た！ネトウヨの陰謀論

>>145
Cの次がなんでDじゃなくC++なのかぐらいどうでもいい

もともとトランスレーターだからな
Cを進めてCを返すから後置インクリメントなんだよ

>>144
C++11 でも動的な型演繹はできない
auto a(int b)
{
switch(b)
{
case 0: return int();
case 1: return float();
default: return b;
}
}
decltype(a(0)) c;

templateなdecltypeの型解決は出来ないのか
何とも中途半端な仕様

そうか。
メソッドチェーンの途中でヌルオブジェクトを返せばいいのか。

boost::mplの型vectorのn番目の型も
nが動的に決まる場合は
無理なの？

ワーニングが消えないのですが方法ありますか？
出来ればワーニング自体を無効にする方法は使いたくありません

HMENU hMenu = (HMENU)lpMeasureItemStruct->itemID;
warning C4312: '型キャスト' : 'UINT' からより大きいサイズの 'HMENU' へ変換します。

reinterpret_cast

HMENUやめてUINT使えばいいだろ馬鹿なのお前？

#pragma warning(disable : 4312)

>>155
warning自体を無効にする方法は使いたくないと書いたのですが日本語が理解できませんでしたか？
本当に役に立ちませんね

>>154
寧ろitemIDをHMENUにしたらいいんじゃねw

ゴミクズですね

>>156
あんたがどこか遠い世界に逝けは問題が解決するんじゃないかと思う

>>156
坊や、だだをこねる前に warning とは何かを確認して出直してきな
それと君が使っているコンパイラでは警告コードの 4000 番台には特別な意味があるぞ

(HMENU)(UINT_PTR)

reinterpret_cast<HMENU>(reinterpret_cast<UINT_PTR>(lpMeasureItemStruct->itemID))

HMENU hMenu = 0;

ホモ

いいかげんCキャスト使うの止めろ
それと雑魚共はWin32APIから出てくるな

は？何様じゃ

御子様じゃ。

>>144
オーバーロードすりゃできるだろうよ

パーかおめ

int value = Function( Tag<WM_LBUTTONDOWN>() );
char value = Function( Tag<WM_DESTROY>() );
long value = Function( Tag<WM_CREATE>() );

マンコ公園でシャセイ大会を行うプログラムはC++ではどう書いたらいいですか？

まず男になれ

>>172
俺は女になりたい

俺も女になりたい
・・・が、普通の女じゃいやだ
普通の女の可愛さを偏差値50とすると51.8くらいがいい
普通より微妙に若干可愛いような気がする程度

お願いします

//昔おなべにちんこくれって言われたときにあげれば良かった

なんでホモがこんなところにいるんですかねえ……

多重継承したんでしょう

♂と♀を多重継承すると一人で妊娠出来るのかな

２０１２年８月１９日フジテレビ抗議デモinお台場　告知動画
http://www.nicovideo.jp/watch/sm18497988
8月19日　フジデモ一周年　お台場フジテレビ抗議デモ　告知動画
http://www.nicovideo.jp/watch/sm18468199
【告知】８・１９フジデモ一周年inお台場
http://www.nicovideo.jp/watch/sm18413040


かつての「視聴率王」も今は昔――フジテレビに異変が起きている。

2004年から7年間、年間視聴率3冠王に君臨していたが、昨年、日本テレビにその座を奪われたのに始まり、
オダギリジョーが主演した今年4月期のドラマ「家族のうた」は、視聴率3％台で打ち切り。
さらに4〜6月期の平均視聴率はテレビ朝日にも抜かれ、3位に。7月には「3冠王を逃したため」（フジテレビ関係者）、
局長やプロデューサーなどが大幅に入れ替わるテコ入れがなされたが、"迷走"は止まらない。

その一例が情報番組「とくダネ！」だという。
言わずと知れた小倉智昭がメーンキャスターを務める朝の看板番組だ。
同局の人気アナ、ナカミーこと中野美奈子の退社に伴い、
7月からキャスターに抜擢されたのがタレントの菊川怜だったが、その評判が芳しくない。
「同じ時間帯では、日テレの『スッキリ!!』と『とくダネ！』が視聴率を競い、これまではフジが優勢でした。
週5回の放送で負け越しが続くなんてことはほぼなかったのですが、菊川に代わった翌週から、1勝4敗が2週続きました。
扱うニュースなどにもよるので一概にキャスターの責任にはできませんが、菊川が原因だという声がもっぱらです」（番組関係者）

一方、菊川の起用と同時期にあった人事異動が業界で臆測を呼んでいる。情報制作局長や情報制作センター室長、
番組のチーフプロデューサーらが軒並み交代したのだ。テレビ局では、長く続いた番組を終わらせたり、
「大物」キャスターやタレントを降板させたりする際に、局側も相応の立場の人間が異動するのが慣例とされている。
「大物の降板などと同時に異動する局もあるが、フジは必ずしもそうではない。
今度の人事異動は、小倉さんの降板をにらんだもの、という声があります」（同）
もしかして、小倉さん、最後の夏!?

▽週刊朝日
http://www.wa-dan.com/article/2012/07/post-968.php

>>177
かたつむりはそれでも二人だそーです、ひとりはリスクがやっぱりでかいのか？

>>179
カタツムリに聞いて来い

プログラマーはホモ多いよ

>>179
でかいよ
繁殖スピードと個体数の少ないカタツムリみたいな生き物は
遺伝子同士の掛け合わせで強化していかないと間に合わない
ウイルスみたいに繁殖スピードが速くて個体数の多い生き物は突然変異でも間に合うから
自己増殖でOK

多重継承はバグの元だ。
♂と♀のインターフェースだけ多重実装しろよ。

♂から♀にキャストすればいい

>>184
子供産めるようになるのかなwktk

ネトウヨは2chまとめブログ「てきとう」を見よう

C++11はいつごろ一般的に普及しますか?

俺はgcc44に対応している所から使ってる。

>>187
VC11がもうすぐ出るからそしたら流れが変わる

>>185
♂から♀へキャスト→股の棒・胸毛等が無くなり中性的になる
♂と♀を多重継承→ふたなり
♂を継承し♀にあるメゾットを一部追加→男の娘・オカマ
♀を継承し♂にあるメゾットを一部追加→男装女子・オナベ
全然違うぞ

詳しいですね、その筋の方ですか？

米を使った欧風料理か？

それはdynamic_castすると殆どがNULLになるな

ヌルヌルになるのか

遺伝的アルゴリズムでオスメスみたいな関係性を定義する事あるけど
絶対に継承にはならないよね。冗談とは言え男女を継承で解決しようとか
程度が知れるわぁ・・・。

ネタスレでマジレスしてるキチガイがいるよｗ

これはひどい・・・

夏だから仕方がない

返値がコンテナになる関数で
Return value optimization
したい

例えば

std::vector<double>
my_push_back(std::vector<double>& v,double &x){
//return std::vector(v).push_back(x)// Return value optimizationにできない
std::vector vv(v);
vv.push_back(x);
return vv;
}

なんとかReturn value optimizationにするにはどうすればいいのでしょうか

右辺値参照なので気にしない

C++11のムーブコンストラクタを使えよ

C#のLINQみたいなのメタプログラミングで出来ない？

key/value 両方ともUniqueで、片方から片方を検索したいです。

std::map<> だと片方しか検索できないのですが、
自分でmapを2個用意して、それっぽいのを作るしかないでしょうか？

何か良い方法あったらおしえてください

困ったときのブースト

あった、ビットマップなんちゃらね。

ありがとう　尻貸すよ

前スレ？でもちょっと出てたが（HDDが飛んだ＆最近忙しかったのでわかんね
#include <stdafx.h>
は、本来のプリプロセッサの仕様的には
#include "stdafx.h"
の方が適切だと思うわけだが（VSの「クラスの追加」とかで出てくるスケルトンコードもそうなっている
まあどっちであっても（たぶん無条件にカレントの.pchから探そうとしているから）動くし、
プリコンパイル済みヘッダーとかローカルな仕様なんで、そういう書き方も許されるのだと納得しようと思えばできるが

プロジェクトにローカルなヘッダは q 文字列
そうでないヘッダは h 文字列

Hoge *p = piyo.search("fuga");
if(p) p->are()->sore();

みたいなコードでif文とかうざいので、
piyo.search("fuga")->p->are()->sore();
としたいときには、search()の戻り値がどんなときでも
ﾇﾙﾎﾟにならないことを保障すればいいんだけど
これって作法的にはどうなの？ 下品なやり方？

まんなかのp->はいらなかった無視して

ヌルポならなにもしないラッパーを返すか例外を投げるが？

thisがNULLかチェックする。

... are(...) {
if (this == NULL) { return NULL; }
...
}

... sore(...) {
if (this == NULL) { return }
...
}

>>211
びっくりするほど無能でびっくりした
どうやってare()にたどりつくんだよ

なるほど。でもare()やstore()がvirtualな場合は使えないね。

>>210
・何もできないラッパーを返す
・何もできない基底を返す
設計上、どっちがいいの？
気分的には何もしないラッパーよりも何もしない基底の方がいい気がする
派生部品を基底で返すのって良くない気がしない？

引数って参照かポインタか良く悩むんだけど
最近になって、両方作っとけばいいことに気づいた。
おれはてんさいかもしれん。

>>215
実体渡しを作らないからてんさいではない。

出力にはポインタ、単なる引数は参照

>>217
単なる参照なんだけどポインタを渡す羽目になることってあるだろ
unko( string &s ) にポインタchinkoを渡すときに
unko( *chinko )って書くのはなんかキモイ

>>208
つ例外

>>214
Maybeはc++でスマートに書けないのかな

>>218
string*とかのナマポを持ってる方がキモイ

>>219
無きゃ無いで何もしない というコードなので、例外はいらん

>>221
生ポじゃなくても同じような事象ありえるだｒぽ

>無きゃ無いで何もしない
なら>208のようにif文を使うのがわかりやすい
もしif文を書かねばならない箇所が多くなるなら、
それは検索機能のコードが一箇所にまとまっていないという別種の問題に思える

piyo.search("fuga")が"fuga"を見つけられなかった場合例外を投げる、でも一応動くが
もし"fuga"を見つけられないというのがありふれた事象なら、piyo.search()を直接または間接に
呼ぶ側が、例外が来るのか、途中の階層で捕捉されるのかを常に意識せざるを得ないからウザさは減らない
また、例外のスローはポインタ1個返すだけの関数リターンより遅いし、unwindは魔法だし、
捕捉する側では例外オブジェクト別の分岐コードが吐かれるとかでパフォーマンス的にも損をする

>>224
ありがとう。
検索コードが散らばるというか、たくさんあるのが前提なコードなので
piyo.search2("fuga")->are()->sore();
2の方を使ったらﾇﾙﾎﾟオブジェクトを返すようにした。

>>199
std::vector<double>
// std::vector<double> & //にするとうまくいかない
my_push_back(const std::vector<double>& v,const double &x){
std::auto_ptr<std::vector<double> > pv(new std::vector<double>(v) );
pv->push_back(x);
return *pv;
}


std::vector<double> v;
v.push_back(1.1);
std::vector<double> v2(my_push_back(v,2.2 ));
std::cout << v2[0] << " " << std::endl;//ちゃんとした数値じゃない

void unko( hoge &chinko )
という関数を呼び出すときに、 chinko を刹那的に作りたいんだけど
unko( hoge dummy ) と書くとエラーになる。

class A{
virtual void func();
}
class B : public A{
void func();
}

って感じでオーバーライドして、その上で

vector <A> vec;
vec.push_back(B())
vec[0].func();

っていう呼び出し方するとB::func()じゃなくてA::func()が呼ばれます
どうにかしてB::func()の方を呼びたいんですがいい方法ないでしょうか

>>228
virtualやめるかB::func()

>>228
vector<A> である限り無理

std::vectorクソ使えない

>>228
BのサイズがAと違ったらどうなるんこれ

ああそういう事か
push_backする時にスライシングが起きてるのか
ポインタで保持しないとだめだな

なんとかして
A a(B());
a.func();
がスライシングを起こさず正常に動いて、かつB::func()が呼ばれるような言語を探すことだね。

class A {
public:
virtual void func() {
std::cout << "A" << std::endl;
}
};

class B : public A {
public:
void func() {
std::cout << "B" << std::endl;
}
};

int main()
{
std::vector<A> vec;
std::vector<A*> vecp;

vec.push_back(B());
vec[0].func();

vecp.push_back(new B);
vecp[0]->func();
delete vecp[0];
}

ptr_vectorとかvector<shared_ptr<>>とか使わねえといつかdelete書き忘れるだろう

>>236
知ってるけど使わなかった

>>234
構文上はともかくとして、
原理上配列に実体を置く方法なら
どの言語であろとダメだろ

スマートポインタ崇拝者てなんかマルチスレッド信者似の胡散臭さ漂わせてるな
ソレ使ってまともに組上げた事無いのに信心だけはいっちょまえて感じの

循環参照してデッドロックを起こしたとか辛いことあったのか？
ほら泣けよ、みんな慰めてくれるぞ。

しょせん辺境の地場信仰だからマルチスレッドほど気持ち悪い事には成らんだろう。

>>239
ｐｇｒ

RAIIを頑なに否定してた人もいたな

マルチスレッド信者ってなんぞ？
マルチスレッドなんて必要悪だろちょっと処理に時間がかかれば
画面が真っ白になるような、そんなソフトばっか作ってんのか。

そうか、参照を使ってもスライシングってあるのか

必要ないとこまでスマポにするカスは別の言語使うか死んだ方がいい

わぁいマルチスレッド あかりマルチスレッド大好き

何の必要があって生ポ使うのかわからん

逆だろスマポの必要性が無い限りは生なんだよ
なんの考えもなしに安全に倒したいならもうC系列を使う意味がない
もっと安全で書きやすい洗練された言語を使えばいい

そりゃ素人は言語を自由に選べるからいいけどさ

玄人ならなおさらだ
低級言語を扱う資格無し

夏だな・・・

そこまでスマポが嫌ならCつかってりゃいいのに
普通は必要なパフォーマンスを出しつつ高級機能を使いたいからC++使ってる

スマポは必要最低限でいいだろ
使わないといけないのは設計が破綻してる事が多いし。

俺はboostを使う上でどうしようもない時以外は極力避けてるよ

具体的にどういう問題に当たった？
夏休みのガキじゃないなら具体例挙げられるよな。

「使わないといけないのは設計が破綻」
これ何回も聞いたけど何故なのかいつも説明がないよね

インスタンスの管理放棄だから、
規模が大きくなるとバグの温床になる。

他の手段で実現できないかをまず検討。
なるべく継承じゃなくてコンポジションで実現できないかと同じくらい気をつけてる。

ちなみに254以外は俺じゃないからしらない

ナマポが必要な場合って、これぐらいだな。
あとは、自動変数とスマポで済む。
・インタープロセス
・生配列のイテレーション用
・Cの関数を使う場合

>>257
理屈じゃなく何があったか事実を書けよ
机上だけの問題なら原発は絶対安全ですぐらいどうでもいい

フクシマのせいで、世界に原発が安全であると間違ったメッセージを送ってしまった。

スマートポインタ使うことが設計の破綻ならほかの言語ではどんな設計にしても破綻してるな
スマートポインタにすることで、かえって管理方法を明示できる側面もあるよ(色々なスマートポインタがあるから)

かくいう自分は最近モバイル開発ばかりだからスマートポインタ使ってないけど

>>257
アホだなー

>>257
スマートポインタは管理放棄じゃなくて、自動管理で済むって話。
スマートポインタを使った場合に発生するバグがあるというのなら、その例を挙げてみてよ。

>>261
なぜモバイル開発だということがスマートポインタを使わなくなる理由になるの？

>>260
それはない

被災３県、戻らぬ外国人観光客　放射能不安、円高も追い打ち
ttp://www.sankeibiz.jp/business/news/120724/bsd1207240503003-n1.htm

まーたデストラクタ否定党か

>>264
GCの有る言語しか開発に使わせてもらえないからだろう

>>264
c++慣れしていないプログラマがかわるがわる投入されるからということと
うちのような中小ゲームデベロッパではunityが幅きかせてきてそもそもc++のコードをあまり書かなくなってきた

言語が違うならそりゃ論外だな。

>>269
そんな本筋の外の部分に論外だのなんだのと言われてもな。
>>264からだけを読んで誤解してない？

本筋の外だから論外なんだろ？議論する必要が無い。何かおかしいか？

話しそらさず>>257は>>259に答えろよ
これで答えられれば一旦話がまとまるだろ

>>271
お前はあとがきだけを読んで小説の中身を判断する人間か

>>271
元レスの論旨をあえて無視して噛み付いてみただれかさんの存在が論外

「中身を判断」だの「噛み付い」ただの、意味が分からないよ。
「論外」を悪口の一種かなんかだと思ってるのか？
単に、他の言語の話は議論の対象にならない、と言ってるだけなんだけど。

論外話はいいから、スマポで困った事例を早く出せよ

おれは>269=271=275なわけだけど、>257の人だと思われてたのなら違うよ。
誤解させたのなら悪かったよ。しばらく黙っとく。

>>263
循環参照とか？(照れ

はじめに信心だけはいっちょまえて危険性を指摘してあるのにバカダナー

スマポだと過去の資産との兼ね合いがな

スマポは危険
スマポは危険
ナンミョウホウレンゲキョ
ナンミョウホウレンゲキョ

スマポで困る点があるのは判るんだが、
ナマポ使いが宗教に見えて仕方ない

なるべくスマポを使うようにして、必要があればナマポを使う
それでいいじゃないの

スマポなんて、所詮ナマポのラッパーなんだから、使わなくても事足りる。
ここで、スマポを使うように言う奴らは何なの？どこから金をもらってるの？？

ここで、ナマポを使うように言う奴らは何なの？どこから金をもらってるの？？

みんなナマポ宗教が気持ち悪いと思ってるだけだが

>ナマポ
メモリポインタだろ；

どっちかというとスマポ推進派だが
スマポはマルチコア環境できちんと動作させられるようなスマポ
（参照カウントが更新される度に他コア固有キャッシュをフラッシュしたりスヌープする必要がある
は
パフォーマンス的にナマポにかなり劣るのでは

配列数を操作したいのですが、以下の様なやり方でできるでしょうか？

適当なクラス
Hoge* hoge;
現要素数
int Elements=0;

※配列の最後尾にひとつ追加する時
new(hoge + Elements) Hoge();
Elements++;

※配列の最後尾をひとつ削除する時
Elements--;
delete(hoge + Elements);

>>287
そのへんがトレードオフだよね

>>288
やれるもんならやってみろ

>>288
できるよ

>>287
スレッド間でそんなに排他ロック呼び出しながら通信するか？
あと、スレッド間通信はスマポ経由じゃなくメンバー変数の実体で良くね。
スレッド間でスマポを使うとしたらスレッド全体を管理してるオブジェクトをスマポに突っ込むぐらい。

>>287
その状態と同じ動作するプログラムが生ポインタ使って簡単になるとは思えないな。

>>288
普通<memory>にあるunchecked_uninitialized_copyとか
uninitialized_xxxx系関数で処理する。

>>287
お前の中でスマポ=参照カウントかよ

>>288
hoge の確保サイズはどうやって決めるの？確保サイズ以上に追加されたらどうするの？
っていうか vector 使え。

多分B木とか新しいコンテナ作る気じゃね？

>>254=257だが、
俺は「スマポ極力使うな」派で、「ナマポ派」じゃないよw

>>263
管理放棄ってのは、メモリのnew/deleteの話ではなく、設計上の意味合い。
「スマートポインタの管理者」の話で、もう1つ上のレイヤーの話。
インスタンスには単一の管理者が居るという設計にした方がシンプルだと思う。

これの不具合の具体例は、コードが難読になる程度。じわじわくる。

これが具体例？
なりそうな気がするよ、程度にしか読めないんだが

なぜスマポを使うべきでないのかという説明になってないな

>>299
大半の人がそう。気軽にスマポをぶん回す。
新卒相手の場合は、設計をまず見直すように言う。

いや、それは判るんだけど具体例をね。

>>298
つまり所有権の共有が必要ないところで所有権共有のためのスマートポインタを使うな
って言ってるんだよね？そりゃそうだね。

だったら shared_ptr とか「所有権共有のためのスマートポインタ」とかちゃんと言え。
「スマートポインタ」でひとくくりにするな。

スレ間違えたった

ところで話変わるけど、STLにアトミックな変数操作できる
クラスとか変数とかってある？

std::atomicとか

共有しない場合でもunique_ptrで済む所でナマポ使うメリットも無いよね
例外処理とかめんどくさすぎるし

>>305
"STL" が何を指しているのかよくわからんが、 C++11 には標準ライブラリ <atomic> があるよ。

>292
参照カウンタの一貫性を複数コア間で保つためには一般論としては重い排他ロックか、
キャッシュスルーアクセスが要るが、どっちにせよ数百オーダーのクロックサイクルを消費する
もっとも、スヌープを高速で行う特殊なハードウェアが用意されていればその限りではないが
IAにそんなものがあるのかは知らん（ていうか無いっぽい

>293
ナマポなら上記対策が不要なｼﾁｭではプログラマの責任の下で上記対策を省けるが、
使用環境制限のない汎用スマポだと無条件にコア間同期が行われてしまうのではないか
（同一コア内のスレッドセーフのみ保証される軽量なスマポでも選択でき無い限りは

>295
おk
続けて

>>306
>>308
ありがとう。おれ、atomic、おぼえた。

>>309
スマポに対する排他コストじゃなくて、スレッド上での排他一般を
コストが問題になるほどするか？って書いたんだけど。

一貫性云々言う人が生ポインタ使ってるのか...
この人みたいな使い方なら保持者以外弱参照でいい気がするなぁ

>>309
プログラマの責任が増えたるんなら難しくなってるってことだな。

っていうかそもそも、なるべく共有オブジェクトへのアクセスを
減らすだろうし、そうすれば効率面でもたいして差は出ない。

共有オブジェクトへのアクセスがガンガン入ってる状態で
アクセスひとつひとつの効率が〜とか、いったい何を目指してるの？
って話になる。

>311
スマポの中で行われる排他の話をしているのであって、
スマポに対する排他の話ではないにょろよ

>313
>っていうかそもそも、なるべく共有オブジェクトへのアクセスを
>減らすだろうし
これはごもっとも
コピーできるものはスレッドローカルにした方が速いし問題も少ない

>共有オブジェクトへのアクセスがガンガン入ってる状態で
>アクセスひとつひとつの効率が〜
ああすまん、スマポの参照カウンタの同期が必要、というのはスマポの破棄時のみであって、
スマポを介した他オブジェクトへのアクセスはナマポとあんまり変わらない（コア間同期不要）だな

自己解決しました☆

>314 訂正；
誤：スマポの破棄時
正：スマポの生成、破棄、所有オブジェクトが変わる（代入等）のいずれかのとき

韓国ハンファグループ日本法人のハンファ・ジャパンは２日、
総合商社の丸紅が建設を計画している日本全域の太陽光発電所に、
向こう４年間で約５０万キロワット分の太陽光モジュールを供給することで
丸紅側と合意したと明らかにした。近く本契約を締結する。

　供給されるモジュールは全てハンファソーラーワンの製品で、
売上額は６０００億ウォン（約４１６億円）に達すると見込まれる。

　日本への太陽光モジュールの供給が本格化したのは、
東日本大震災が発生した昨年３月以降だ。

　ハンファグループは震災後、鳩山由紀夫元首相の支援要請に応じて
太陽光発電システムなど１０億ウォン相当の支援を実施。
これを機に金升淵（キム・スンヨン）グループ会長が日本を訪れ、
野田佳彦首相や丸紅の朝田照男社長と面会し、太陽光発電事業での提携を協議した。
http://japanese.yonhapnews.co.kr/headline/2012/08/02/0200000000AJP20120802003300882.HTML



>ハンファグループは震災後、鳩山由紀夫元首相の支援要請に応じて
>太陽光発電システムなど１０億ウォン相当の支援を実施。
>これを機に金升淵（キム・スンヨン）グループ会長が日本を訪れ、
>野田佳彦首相や丸紅の朝田照男社長と面会し、太陽光発電事業での提携を協議した。

>>309
boostもしらないのか？　shared_ptrは排他制御のアリナシ選択できるぞ。

>>314
>スマポの中で行われる排他の話をしているのであって、
>スマポに対する排他の話ではないにょろよ
そういう話じゃなくて、実用上影響が極めて小さくねって話よ。
スレッド上での10分の1の時間をスマポの排他に費やすんならそりゃ問題だが
固定で2μ秒しか消費しないなら気にする必要が無いでしょ。

スマポで不具合多発する具体例は、生ポとの共生。これが一番来る。
寿命管理に気を使わなくていいスマポで組んでる中に、使用者全員が寿命管理を確実に行わなければならない
ナマポが入ってきたらマジ悪夢。　１コだけでもしゃれにならん。


使うならどっちかに統一下ほうがいいし、どう考えてもスマートポインタベースで、どうしても必要な場合のみ
スマートポインタで寿命管理をしつつ生ポインタも取り出して扱うべき。

こういうバカが居るから無駄なコストかさんで品質悪い製品が出来上がるんだろうな
どうせスマポ以外も妥協しまくりの糞コード書くんだろ

>>319
weak_ptrで渡すと、コードが少し冗長になっちゃうのが嫌なんだよな
それでも使うべきなのだろうか

>>320
Ｃ＋＋でスマポ使うのは開発期間短縮のためだよ。低品質でも納期優先なｋｓ仕事ばかりなのさ。

>>321
独立したモジュールとかリソースから使い始めてみるといいよ。とくに寿命管理が面倒くさいヤツ。
生ポと相互乗り入れしなきゃ、並列に使うのはさほど問題はない。

>>319
ナマポはクラスで蓋をすればぜんぜん臭くせずに済ませることもできる（カプセル化）
ていうかスマポ自体その実現方式の一つであるとも言える
大域オブジェクトやSTLのコンテナ要素の管理をスマポに統一するのはそこそこ良い考えだが
あーまあいいや納期までにちゃんと動いて問題が無いものができるなら何だってよろしい

>>320
無駄なコストって、何のこと言ってるんだ？

>>323
shared_ptrがナマポにフタしてくれてるんだがねｗｗ

>>325
そう書いてるだろ

ナマポで生活したいが仕事はしたくないな

boost::ptr_vectorはスマポじゃないの？

後でOpenMPで並列化する可能性あるプログラムで
boost::ptr_vector使ってしまった
ptr_vectorの中みてみたらstd::auto_ptrとか使ってるし
並列にしたらバグが出まくるってことでいいのでしょうか

>>329
「並列にする」の意味もわからんしauto_ptrを中で使ってたらなんだと言うのか。

>>288
バグがあるかもしれないけど無理矢理書いてみた
普段何気なく使っているvectorの裏側が覗けたような気分になる

http://ideone.com/0EdOx

OpenMPに対応するときにちゃんと排他しなきゃ
そりゃコンテナのたぐいはなんであれバグるだろうよ

OpenMPって数学屋さんとかプログラマじゃない人がマルチコアの恩恵を受けるために使うものだと思ってた

ストラウストラップの本の13章なんですが、
struct Color {
　enum Color_type {
　　red = 0, ...
　}
}
ってなっててShape::set_color(Color col)というメソッドに
s1.set_color(Color::red)
って呼び出しできるのはなぜでしょうか？
set_color()の引数はColorオブジェクトのはずなのに
何で列挙のint型整数を渡せるのですか？

>>334
えっ？渡せないでしょ？
持ってる版が違うのか、ストラウストラップの本でその箇所をみつけられなかったけど

>334
>何で列挙のint型整数を渡せるのですか？
まず、Color_typeはint型ではない。Color_type→intの暗黙の型変換は行われない
その上でだが、たぶんColor構造体にColor_typeからColorを生成するコンストラクタ
Color::Color(Color_type col)とかが定義されてんｼﾞｬﾈｰﾉ
（ストラウストラップの本は引っ張り出していないが、VS2008では（引用コードに抜けているセミコロンをいくつか追加と）
　上記コンストラクタ追加でコンパイルが通る

ちなみにColor_typeがもしクラスか構造体なら、Color_typeにColorへのユーザー型変換が定義されている可能性もある
今回はColor_typeが列挙型なのでその可能性はないが

>>334
ColorにColor_type(か、同様のもの)を取るコンストラクタない?

あっ見つけた「ストラウストラップのプログラミング入門」のことか
コンストラクタColor(Color_type)が定義されてるから渡せる

つかちゃんと説明されてるじゃん

アドバイスありがとうございます。
ストラウストラップのプログラミング入門の本でした。

>まず、Color_typeはint型ではない。Color_type→intの暗黙の型変換は行われない
>コンストラクタColor(Color_type)が定義されてるから渡せる

いまいちわかってないのですが、Color::redと書いたときに
Color(Color_type)のコンストラクタが呼ばれて自動的にColorオブジェクトが
作られるってことでしょうか？

これは、enumがColorクラス内に書いてあるから可能なのでしょうか？
列挙子は、int型を割り振るものだと思い込んでいたもので。

>つかちゃんと説明されてるじゃん

すみません、見てみたいので場所を教えていただけないでしょうか。

Color c1(Color::red);
s1.set_color(c1);
これだとColorのコンストラクタはenumのColor_type型をとり、
set_color()は、Colorオブジェクトをとる
ならすぐに納得できたのですが・・・

s1.set_color(Color::red);
だとset_color()がColor_type型をとることになってしまい
型エラーになりそうな気がするのですが・・・

暗黙的にColor::Color_typeを取るColorのコンストラクタが呼ばれて生成されたオブジェクトがset_color()に渡される
これは変換コンストラクタと言うみたい

>>340
Color(Color_type)はColor_typeからColorへの変換であるので
コンパイラによる暗黙の変換がされるということ。
この辺りの変換規則は少し分かりずらいけど覚えるしかない。
p.398にColor作成のためコンストラクタを利用してるというhintが
書かれているけど変換規則が分からないと意味が掴めないかも。

>>341
簡単のため関連するシンボルの公開属性が全部public:でnamespaceも共通である（全シンボルが問題なく見える）として、
　1. Color_typeからColorを生成するコンストラクタColor::Color(Color_type col)が定義されている
2. 上記コンストラクタがexplicitつきでない
場合、
　s1.set_color(Color::red);
という呼び出しは、
　s1.set_color(Color(Color::red));
として解決され得る、だったﾊｽﾞ、
暗黙の型変換絡みはいろいろややこしい

変換コンストラクタですね・・・初めて聞きました。
ヒントにさらっと書いてあったのがこのことだとわかりませんでした。
とりあえず暗黙の型変換で置き換えられるというのはわかったので
納得して先へ進もうと思います。

ありがとうございました。

>>333
OpenMPよりもパフォーマンス出せる例というと
どんな場合がありますか？

>>326
スマートポインタで実現されていることを自前でそれぞれやるのを推奨するようなアホな書き込みだってことだろ

自前の管理システムなら一箇所で複数のポインタを管理できる
スマポはポインタ一つを一つの管理者が管理するから冗長で無駄だらけ
そもそもスマポでくるんでもくるまなくてもどちらにせよオブジェクトをなんらかの目的で管理するシステムを書くのだからそのシステムに寿命管理も組み込めば済む話だよね

いちいち自前の管理システムを使わないといけないのか。最悪だな

スマポと同等機能をポインタの種類分、毎回コーディングしてるのか。

胸が熱くなるな。

>>348の設計は、1つのクラスに2つ以上の機能があるな

スマポを毎回書いていると聞いて金玉がヒュンとなった

>>346
MPIとかスレッドプールじゃね

>>348
個別管理で無駄が生じるケースも稀だし、その無駄が有意な差として顕在化することもさらに稀だろう。

個別管理の無駄によって性能要件を満たせなくなったのなら自前管理を書いてもいい。
ただし計測環境と結果をコメントで添えたうえでな。

普通書くだろ
スマポつっても場面場面で答えは違うし
十分もあれば新しいのかけてパフォーマンス上がるんだからめんどくさがらずに書くべき

>>351
>>348と全く関係ないけど1つのクラスで機能1つだけってどんな状態？

パフォーマンス、パフォーマンスってどんな用途でスマポがボトルネックになってんだよ

>>357
インスタンスの生成消滅サイクルが早いときやソートを頻繁に行うときとか無視出来ない

>>352
つ 去勢手術

>>358
ソートを頻繁に行うとは？
Codepadに貼り付けて速度測ってくるから具体例を書いてくれ

>>358
空間効率なのか時間効率なのか、時間効率だとすればどの操作について言ってるのか？

どうせまたスマポといえばshared_ptrしか頭に無い人がわめいてるんでしょ。

今はsharedの話だろ
再発名や自前の管理コード書くのだるいからって文脈なんだから

>>360
ゲームとか作ればわかる

>>361
スマポは両方クソだからな

>>364
作れば判るじゃなく、具体的コードを示してくれ

>>365
auto_ptr, unique_ptr は空間効率も時間効率も生ポインタと変わらないんだが。

>>363
ならshared_ptrと言え。「スマポ」で括るな。

>>366
面倒

>>367
ダウト

はい、計測せずに言ってることがバレました。

>>370
疑うんなら差が出るコードを作ってみろよ。

>>372
削除子使えば悪くなるのは当然だろ

>>369
グラフィック処理してるが基本はプロファイラー
実測なしで判断しようがない
問題箇所だけなら50行も掛からんだろ
それぐらい渋るな

スマポでパフォーマンスに影響が出るほど 作成削除してたら、
使わないでも酷い状況になってると思うがw

unique_ptrのコストが問題になるってそれ生ポ使ってももうダメだろ

>>373
削除子使ってもサイズ変わらんぞ。
http://ideone.com/Fs05r
struct MyDelete { void operator () (int* p) const; };
static_assert(sizeof(std::unique_ptr<int, MyDelete>) == sizeof(int*),"");

>>377
アホか

>>378
373の「削除子使えば」がこれと違うんなら、説明してもらわねばわからん。

つーか、削除子要らない普通の delete ならパフォーマンス違わないのは
認めてるってことでいいの？

>>379
コンパイルのパフォーマンス最悪だろ

>>380
あー <memory> クソ重いよな。 <unique_ptr> とか <allocator> とか分けて欲しい。

で、 >367 は認めるってことでいいの？

主語が抜けてる奴にアホ呼ばわりされたくは無いわな

>>381
デリータによるが？

>>383
どんなデリータの話をしてる？状態持ち？
それは生ポインタを使うとどんなコードになるのか、考えて言ってるのか？

>>384
ローカルなアロケーターもたせると参照の複製が全部に必要になる
集中管理なら実体一つで十分
スマポ終わったな

>>385
それなら確かにデリータ付きの unique_ptr は効率悪くなるな。

それでもって「スマポ効率悪い」とかいうのはおかしいけど。

最適化を前提にしてんのか？

効率がどうこう言ってて最適化抜いてるわけないだろ。

速度が気になる場面が来るまではスマポ使ってればいいじゃん
全体の8割は速度どうでもいいんだから、本当に気になる2割で
ナマポを気をつけて使えばいい

ナマポのみとスマポのみで開発した場合、開発期間が５０％程度短縮されると思うんだが。

>>347
別に漏れは>323においてナマポにクラスで蓋をできると言っただけであって、
蓋をする手段の中でスマポを使うことまで否定したつもりはないにょ
（コンストラクタ内での例外でリソースリークする危険性を完全に封じるのにauto_ptr<T>ぐらいは使うし
また、一般にナマポ p = new T(); をスマポ p(new T());に変えることはだいたい正義なことはわきまえておりますにょ
しかしたとえばナマポ配列において、配列の破棄日時≦要素の破棄日時が保証されたコードが既存であるときに、
いちいちstd::vector<スマポ<ナマポの指す型> >に書き換えて計算量増大のリスクを犯すよりは
std::vector<ナマポ>ぐらいにしといて外から要素のナマポが一切見えないようにクラスで蓋をすることを選ぶわ
とかいろいろ〜
（なおこのような改造の場合、コンストラクタ内例外への対処としてスマポ<ナマポの指す型>を使うわけにはいかず
そこは専用のdeallocatorを書く、しかしクラスで蓋をする。結果的にスマポの出番無し、というケースがしばしばある

>>391
なんだ・・・スマポ使いかよ・・・

スマポ マルチスレッド タイガーバーム

>>391
軽量スマポの場合、std::vector<ナマポ>とstd::vector<スマポ<ナマポの指す型> >で計算量の違いって本当にあるか？
そのケースだと俺もナマポ使うだろうけど。

std::vector<std::unique_ptr<> >使うわ

あるかないかで言えばあるけど、普通ボトルネックにならんよな
自分以外の誰かが触るか、開発期間が長期化するか、とか
そのあたりの速度以外の観点で使うかどうか決めるわ

>>364
ゲームなんか作らんから判らんわ〜
コーディックの保守してるけどスマポ自体がボトルネックになったこと無いわ〜
フレームを跨ぐ動体の追跡とかでソート使うけど
対象判定処理の方がよっぽど時間がかかってスマポで削った僅かな時間で
どうにか出来そうとか思ったことないわ〜

ゲーム会社でゲーム作ってるけどスマポのコストが問題になったことなんて一度もないわ

プログラマでゲーム作ったことない奴は地雷

ゲームつってもオセロもテトリスも将棋もゲームだからな

テトリスはともかく、将棋は処理速度が半端なく要求されるよね
こういうジャンルではスマポうんぬんは確かに響くと思う

ゲームは環境の制約もあるからなぁ
ゆとりたっぷりの富豪プログラミングできる人が羨ましいわ

将棋でスマポもクソもねぇよ
本格的にやるならビット演算入れるし
構造体やクラスレベルの処理より
コンテナや配列操作に時間掛けるほうが多いだろ

いまじゃ将棋の板も32bitで3個、64bitで2個あれば
盤面の有無状態が表せるしな。
コマの種類も10種類しかいらないから4bitでいい。
コマの種類と盤面の状態、手持ちを一つの配列にすりゃ
コンパクトでかなりの並列性が得られる。
便利な時代になったもんだよ。

>本格的にやるならビット演算入れる

わらかすな。

その程度のドカタが混じってもぶち壊さないで済むように、スマポやらGCやらが発展してるんだから。
ただ、「マトモに組める人」と「底辺」の効率の差は、10倍なんてもんじゃないんだけどね。

>>405
あの程度のものを整数型1つでひとコマとか
構造体1個でひとコマとかやってんの？

効率は実測が基本。

>>407
今の将棋プログラムが、その程度の「当たり前の効率化」をやってないとでも思ってるの？

「ビット演算で効率化することを思いついた俺ってかっこいい」って？

はからなくてもみつもれるのが二流の最低ラインって常識だろ

そうだな。「はからなくてもみつもれる」なんて言っちゃうやつは三流だよな。

将棋やオセロ類は実測すりゃビット演算が響くよ
処理消費が全体で65%近くになるから
小手先だけで10倍近く処理が縮む
枝が増えればキャッシュミス増えて速度も安定しないし

>>409
当たり前の話なのになんで突っかかってんの？
知らなかったの？

>>411
三流実測厨は黙ってろ

ごめん10倍どころではないな。
詰で30分掛かってた所が1分足らずに改善したこともあった。

最近は最適化やら何やらで糞コードでもそれなりには出るからね。
値渡しと参照渡しの違いが分からないまま走ってる人もいるんじゃないの。

>>413
>本格的にやるならビット演算入れるし

ビット演算を使う程度のことが「本格的にやる」に含まれると
そう考えている人がいることに、まさに驚愕したよ。
そんな世界、全然知らなかったから。

おい、おまえらポインタどこいった

>>409
何が言いたかったの？

>>417
本格的にやらないなら配列で済ませるよ？

本気でやらないならむしろコマも盤面もオブジェクト化して
グラフで繋ぐわ。やってて面白い。

ぶひひ

>>417
本格的じゃなくてもビット演算使ってちまちま作る人か

多分いつでも速度に妥協しないナマポさんなんだろ

>ビット演算を使う程度のことが「本格的にやる」に含まれると
>そう考えている人がいることに、まさに驚愕したよ。
>そんな世界、全然知らなかったから。

簡単な要件でもビット演算使うのが常識とかいう思考勘弁してほしいわ

C/C++のビット演算がどんなコードに展開されてるか見た事あるか？
ひでえコードだぞ

compiler intrinsicsに置き換えた方が良いと思う

はした金詰まれればどんな案件でも方針でも文句言わずやる
お前らにはその心意気が足りん
正しい正しくないじゃ無いんだよこの業界
上司がナマポ教なら部下も改宗しないとダメ
それができないなら解雇だな

>>426
コンパイラー次第だろ
プロファイラーで改善が見られれば十分

>>425
俺は>>417じゃないけど、それは単に君のレベルが論外に低いからだって。

ビット演算なんかそんな気張って使うようなものかよ。
非常識過ぎる。

腕次第

ID記念パピコ

>>429
ビットフラグだの符号の取り出しだのその程度なら解るが
速度求めてないのに一般に配列で済むような物をビット演算するとか無いわ
気張ると改善に時間の無駄だろ

>>427
筋さえ通りゃ金次第で何でもやってのける命知らず
不可能を可能にし 巨大なプロジェクトを粉砕する

CG関係ってビット演算なんじゃないの？
最近はその辺は全部自動なのか

はあ？

まずCGってのがなんなのかの説明から必要。
わけのわからん個人的な思い込みを一般常識的に考えるのはやめよう。

自称自分はすごい人の予感・・・

結局,OpenMP使うより速度が上がる
テクニックってどんななの？

バリアント型みたいなのを作ってるんだけど
中身がdoubleのときのdouble同士の四則演算は
doubleのを使ってほしいし
中身がstringのときはstringのを使ってほしい

今はoperatorを乗っ取ってif文で分岐してるけど
異種間のときだけ変換を手助けすればすむようにしたい

>>439
そうですか。

>>440
そうなんです。

>>441
頑張ってくださいね。

>>442
はい。

doubleクラスってあるの？

>>438
自前で並列化を全て制御した方がパフォーマンス上がるのはごく普通のこと。
もっとも、下手にやるならOpenMPの方がマシってのはあるけど。
下手な人がアセンブラで書いたってコンパイラにすら負けるという事態がよくあるように。

>>439
type_traints

>>438
単にMPIに変えただけでも速くなる

C++で質問なんですが。
最近プログラムの高速化について調べているのですが
最近のCPUはどんどん高速化していって、キャッシュサイズ等も増えてきているが
メモリはパスの互換性の問題等から速度は昔とあまり変わっていないので
速いプログラムを書くにはメモリとあまりやりとりせずにCPUのキャッシュに乗せるのが
有効とあったのですが、プログラムでCPUのキャッシュに乗せるというのがイメージできません。
コードで明示的にキャッシュに乗せる事は出来るのでしょうか？それとも、キャッシュにのるサイズのデータなら
自動的にキャッシュを使われるようになっているのでしょうか？

メモリ効率を考えれば自然にキャッシュ効率もよくなることが多いよ

>>448
キャッシュの仕組み調べてみれば判ると思うよ。

使用するメモリがキャッシュサイズ以下で連続していれば乗っかってアクセススピードが改善される。

C/C++つこてるとチョットした事でスグだいなしに成るからキャッシュなんて気にする必要は無いんじゃないかな

そうでもないよ。ランダムアクセスするよりシーケンシャルアクセスした方がずっと速い。

>>448
100万回とかそれ以上の計算をCPUのキャッシュサイズ超える配列と
キャッシュサイズに収まる配列でやって測ってみりゃいいだろ

大きめの多次元配列を走査する多重ループのループ変数を入れ替えて計算してみるとどうすればキャッシュ効率いいか見えてくる

大容量L3キャッシュを備えているという事は、それだけフラッシュ/再フィルにも
時間が掛かるって事だぜ

だから一概に速くなるとは言えない
小規模なループなら速くなるだろうけど、メモリを広くランダムにアクセスするような
プログラムではむしろメモリの速度とレイテンシの低さが効いてくる

御託並べるなら該当スレに行ってくれ。その辺りになると、最早C++標準から遠ざかり過ぎている。

llvm clangとgccはどっちが速いのか

const変数って定数にコンパイル時に定数に置き換えられるんですか？

定数式で初期化されたconst変数は定数として扱われます

ありがとうございます。
最後に静的const 動的const
まとめてconst変数ということを付け加えて
質問を終わらせていただきます。

静的const =rvalue
動的const =lvalue
ってことでいいの？

動的const, 静的constってオレオレ用語か伝わればいいわってぐらいで見てたが
用語の意味を知りたいなら正しい用語を使え。動的const, 静的constなんか無い。
それからconstは右辺値しかない。const_castでconst外せるが、外したらそれはもうconst変数じゃない。

> constは右辺値しかない

マジで！？

static関数の用途は大量にあるのに
static変数(非const)の用途ってホントねぇなぁ。
シングルトンだのオブジェクトのカウントだの方法論だけはあるが
実際何に使うかってのが全然ない。
ファクトリー用のホルダーに使おうかと思ったが
影響範囲がデカすぎる。何かしら使おうとすると影響範囲の広さがガンになる。

>>394
別に計ったわけではないが、
100万要素のstd::vector<T>が100万1要素に増えたとき、
Tのコピコンが100万回呼ばれて、その後Tのデストラクタが100万回呼ばれるわけじゃん？
さらにT*なら1要素8バイトで住むところが、shared_ptr<T>あたりだと一気に16バイトじゃん？

>>465
ユニポなら問題ないじゃん？

ユニポはようわからんのだけど、
コピコンもデストラもナマポより時間コスト大でねえが
つまり、複数のユニポが同一のアドレスを指さない、という規則からすれば、
コピコンでコピー元は所有権を失わねばならないから、0にでもせざるを得ないので、0にするオペレーションが1回、
デストラで0かどうか判定して、0でないときのみヒープ開放という条件分岐が1回、
それぞれ増えるんではないの

>>455
3次キャッシュのご利益は、マルチコア構成においてコア間でデータの一貫性を保つのに要する時間を
短縮できるところにある（外部メモリからでなく、3次キャッシュから2次キャッシュをfillすれば良いので）
インテルかどっかが試験的に48コアとか作ってたと思うが、あれは3次キャッシュはあっても
3次から2次へのfillは自動では行われない

上で思わずIAにスヌープを高速で行う特殊なハードウェアが用意されていないみたいなことを書いたが
正確ではなかったかも試練、orz

>>465
そのウンコみたいなコードはちょっと手を入れたほうがいいんじゃね？

ユニポ厨はアホ
ポインタは複製が作れてなんぼだろ
パフォーマンスが同等でもユニポの利用シーンは限られてくる

ユニポでもポインタの複製は作れるだろ

>>463
int const x; で const な左辺値ができる。何かの間違いだろ。

>>472
それはエラーだ。

>>467
その考察は正しいと思うけど、実際にはそれで増える処理時間がネックになることは
ほとんど無いだろうから、そこを疑って計測もせずに生ポインタを使うという選択には
ならない。

>>473
あ、ごめん。 int const x = 0; で。

クライアントコードで使うやっつけ仕事ならスマポがベストだ
ライブラリ制作ではナマポか最悪でもユニポにしたほうがいい

またスマポ=shared_ptrの人か。ブレないな。

>>477
実際もっとも代表的なスマポがshared_ptrだろ
いい略称もないしスマポといったら暗黙にshared_ptr
ほかのスマポはわかるように書く
これがベストなのは言うまでもない

auto_ptrさんのことを忘れるなよ

>>478
お前ん中ではな

>>480
いやいや、常識です

>>481 >>480

>>482
世間にもっと目向けてみ？
ひきこもってちゃ何も分からないよ？
普通スマポって言ったらまずshared_ptrを思い浮かべるからな

>>483 要出典

>>483
仮にそうだとしてさ、効率の議論をしてるそばで効率特性のまったく違うものを
ごっちゃにするような呼称を使うのはダメだろ。

>>485
ごっちゃになってないよ
スマポ→shared_ptr
ユニポ→unique_ptr
ナマポ→生ポインタ
auto_ptrは議論に含めない
標準ならこれで十分だし今は非標準の話はしてないでしょ

スマポの本質はRAIIであり例外安全だ
だから基本はauto_ptr(C++11ではunique_ptr)

shared_ptrは利便性とコストのトレードオフを考えてから使うもので
代表的なわけが無い

>>486
まさに お前ん中ではな としか言いようが無いなｗ

>>488
論理的に考えろバカ
標準でポインタといったらshared_ptr,unique_ptr,*の三種類だ
そしてunique_ptrはユニポ、*はナマポと使い分けてる
残ったスマポは同じく残った一つのshared_ptrをさす以外にないだろ
理系じゃないやつには一から説明しないとわからないか？

>>486
unique_ptr ∈ スマートポインタは事実であり、「スマポ」は
スマートポインタのことだろうというコンセンサスのもと
「スマポ」が unique_ptr を除外するような分類は通じない。

>>487
機能の問題じゃない
歴史的経緯からいってスマートポインタっていったら思い浮かべなきゃいけないのはまずLoki::SmartPtrかboost::shared_ptrなんだよ
そこから知名度で絞ってboost::shared_ptrが来るだろ？
それを標準で置き換えたstd::shared_ptrがスマポの代名詞になるのが当然の流れだ

>>489
論理的に考えろバカ
混乱するという指摘がある中でカタカナ３文字の略称にこだわる必要がないだろ

>>490
お前はそんなんだから友達いないんだよ
日常的なコミュニケーションレベルの話で、
重箱の隅つついてこれは数学的には〜だから〜無い〜ハイ論破〜っていまどき小学生でも言わないよ？
何時何分何秒地球が何回まわった時？みたいな言葉遊びレベルにも劣る

>>492
混乱してるのは身勝手な俺理論で自爆してる奴だけ
常識的な感覚持って素直に「スマポっていったら普通sharedだよね〜」って受け入れれば済む話

>>489
unique_ptr ⊂ Smart pointer
論理的（）

>>491
最初にC++の標準として採用されたのはstd::auto_ptr
歴史的（）

>>493
最後はレッテル貼りかｗ
馬鹿の極みだな

>>493-494
なんだお前、論理的に考える理系じゃなかったのかよｗｗｗ

頭堅いなぁお前ら
そんなんじゃ日常生活にも困るレベルだべ？

オレオレ定義をさも常識のように語るお前の方が頭堅いよ

>>495
機能的な包含関係じゃなくて
今は識別子での関係を議論してんだよカス
int hoge; long fuga;
だからhoge ⊂ fugaだぜぇ〜的なあほなこと言ってるのがお前な

最初に（爆笑）
お前は物事の最初だけしか見ないのかよｗｗｗｗｗｗそのあとどうなった？黒歴史に認定されただろうがｗｗｗｗｗ
お前の言い分が通るなら歴史的に天動説が最初だから天動説が正しいんだよ〜〜〜〜って言ってるようなもん。完全なる白痴ｗｗｗｗｗ

レッテル張り？何言ってんだ冷静にお前を評価しただけ
韓国人は屑って、当たり前のこと言って、レッテル張り乙って反論された気分だわｗｗｗ

これはもうさすがにわざとだろ。

この板はなぜかIDが出ないからなぁ

>黒歴史に認定
もしかしてunique_ptrに置き換えられたことを言ってるのだろうか
もしそうなら初心者丸出しだが

初心者でごめん

>>502
何言ってんだこいつ

ナマポ最強って事で手を打て。

そうだなナマポで書くのが最強だな
どうしてもスマポ使いたいあほがいた場合にもナマポからの乗り換えなら簡単だし
逆にスマポからナマポに乗り換えるのは面倒が多い
スマポで書いたコードは再利用しにくく、再利用を繰り返すとスマポ使用コードがどんどん拡大していく
そしてauto_ptrからunique_ptrへの乗り換え、boostからstdへの乗り換えが同時多発的に起こるとその不都合が目に見えて表れてくる
boost::shared_ptrを返すファクトリを再利用しようとしたのに、新しいプロジェクトではstd::shared_ptrやstd::unique_ptrを使うルールでやっていて、変換作業が追加されてだるい、といったことがそこかしこで起こるんだ
でもナマポで書いたファクトリだったらならstd::shared_ptrやstd::unique_ptrを、あるいはboost::shared_ptrを義務付けたプロジェクトでもたやすく再利用できる

>>503-504
auto_ptrは初期のムーブセマンティクスと言えるもの
C++11でムーブセマンティクス及び構文を整理した結果
コピーセマンティクスでムーブを行うauto_ptrと齟齬が起きた

しかしauto_ptrを直接修正すると既存コードがコンパイル出来なくなるため
齟齬が無いよう修正した実装を別の名前unique_ptrで提供して
auto_ptrを非推奨とすることになった

http://ideone.com/cb4Ie
auto_ptrをunique_ptrに置き換えた上で、左辺値からムーブしている箇所に
std::moveを付加する必要がある

>>507
チゲーよauto_ptrはSTLでまともに使えねーからぶっちされたんだよ
その時点でauto_ptrは黒歴史認定されてboost::shared_ptrかそれに相当するスマポへ移行してたんだよ
unique_ptrへの置き換えなんてのは後付けの理由の一つでしかない

>>506
生ポインタでいいってことは単に new した（ delete しないといけない）ポインタ返すだけで
いいってことだとして、それなら std::auto_ptr 使っとけば boost::shared_ptr, std::unique_ptr,
std::shared_ptr のどれにも簡単に変換できるから別に困らないよ。

>>508
> チゲーよauto_ptrはSTLでまともに使えねーからぶっちされたんだよ

それが「コピーセマンティクスでムーブを行うauto_ptrと齟齬が起きた」なんだろ。

> その時点でauto_ptrは黒歴史認定されてboost::shared_ptrかそれに相当するスマポへ移行してたんだよ

コンテナに入れるなってことになっただけで、それ以外では普通に使えたよ。

>>509
あふぉか
auto_ptrじゃカスタムデリータつかえんだろ
ポインタはすべてnew/deleteとかどんだけ〜

>>510
×普通に使えていた
○不便に目をつぶり慎重に取り扱っていた

>>511
「コンテナに入れるな」以外でauto_ptrの何が不便だったの？

スマポ版、Erが例外を投げてもリークしない
http://ideone.com/AZ2sV

ナマポ版、B()未実装
http://ideone.com/dA56A

ナマポ派の人、これのB()でa,b,cにnewする
例外安全なコードを書いてみてくれないか？

>>511
確かにカスタムデリータが要るならauto_ptrは使えない。
ならunique_ptr相当のものが要るな、って話になるだけ。
生ポインタにはならない。

>>513
こんなくだらない問題だして何がしたいの？
http://ideone.com/YD9A6

~B(){delete c; delete b; delete a;}
も書いとけよｗ

>>515
出題者でもないしそのコードがまったくダメだとも言わないが、代入２回になってるのは気になるな。
unique_ptrなら初期化で済む。

>>516
それを言うならコピーとかムーブとかも・・・
やっぱ生は無いな、実際。

>>516
ナマポだとそういううっかりがあるんだな

>>515
new使用箇所全部そのように書いてるなら問題無いよ
単に手間じゃ無い？って思っただけ

>>516,519
そこは気になったけど
コメント欄部分を書き変えろという意図に解釈したから書かなかったんだよ

>>517
代入二回が気になるのは代入処理がカプセル化されて見えないオブジェクトだけだろ
ポインタで気にする奴なんかいねえしそもそもnewのコストにまぎれてポインタ代入なんか気にもならんわ

>>520
大した手間じゃないだろ
コンパイル時間とタイプする時間天秤にかけたらタイプしたほうが得とすぐに気がつく

COMオブジェクトにshared_ptr<COM>使わないといけないときのあの屈辱感が癖になる

CComPtrか_com_ptr_tは使わんのか

>>501
出たら出たで荒れていそうだけどなこのスレ

でも強制IDになれば、このスレに限らず板が
今よりかはまともになる気がする

自作PC,ハード,ソフト,linux,ゲ製とか強制IDなのにな

自演してるわけでもないしID関係ないだろ

執拗に個人攻撃を繰り返す無自覚荒らしが喜ぶだけだな

NGにできるじゃん

ム板はスルーできない性格の子が多いからNGで逃げるなんて卑劣なまねはしないと思う

IDをNGにしたって1日で戻るから意味ないね

というか素人じゃないんだし1レスごとにIP変えるだろ

そうそう、ID板なんて、ム板では無駄。

単発乙で終わり

http://live.nicocast.com/channel/toriimiyukki

>>475
それも右辺値だろ。

>>515
初期化リスト使ってないのがイラッとする
B():
　a( 0 ),
　b( 0 ),
　c( 0 )
try
{
　a = new A(1);
　b = new Er();
　c = new A(2);
}
catch(...)
{
　delete c;
　delete b;
　delete a;
　throw;
}

>>536
こういう人て自分で何も考えられないアホなんだろうな
形だけ覚えて中身をなにも理解してない
そして感情論だけで批判する
仲間にいたら最悪だな

>>537
批判じゃなくて批難な

メンバーの初期化で例外が発生することを考えてれば
ポインターでも普通初期化リストで初期化する癖が付くもんだと思うが
あるときは、初期化リストあるときはコンストラクター内みたいな
一貫性が無く汚いコード書いてんのかねぇ。
それともよく知らずバグをはらんだコードを書き続けてただけか

>>539
メンバーで例外出るとしてもポインタはコンストラクタ内初期化でも全く問題ないが？
お前はいったい何を言ってるんだ

ID出たらこっちはID変えながら個人攻撃できるから有難いんだけれども

単発乙で終わり

c++って求人あるの？実務経験3年以上ばかりで業界未経験は入り込めむ余地がない

探せば在るけど新卒はスキルより熱意（）、将来性（）、コミュ力（）だからC++の勉強しても意味ないよ

ゲームで中堅以上なら必須だけど、年々できる人が減るきがする

>>536
それ未定義動作ね。
15.3 p10
"Referring to any non-static member or base class of an object in the handler for a
function-try-block of a constructor or destructor for that object results in undefined behavior."

>>521
コンパイル時間とタイプする時間とを秤にかけるとはなかなか面白い考察だが、
コンパイル時間の方には読み手が安全性を確認する手間も乗せてやってくれ。

c++の勉強って熱意にも将来性にも含まれないんだな
大人しくPHPやjavaから業界に潜り込もうか
vc++ばっかでg++なんて尚更に見たことない

>>546
へぇ〜function-try-blockって実際使ったことなかったけど
こんな実行順序だったのか、知らなかった

http://ideone.com/e9puX

>>548
>vc++ばっかでg++なんて尚更に見たことない
お前だけだ、安心しろ。

>>540
問題はちょっとあるケースがある
メンバa,b,cの初期化リストを省略すると、宣言順でデフォコンが呼ばれ、
その後コンストラ本体で代入が行われるべきものと解釈される
この無駄は、a,b,cに代入演算子が定義されている場合、最適化で除去され難い
C++の最適化でおおっぴらに呼び出し回数の削減が認められているのはコンストラ（コピコン含む）だけ
代入は、普通の関数扱い（呼び出しに副作用がないと無条件に仮定することは認められない）から
よほど賢いコンパイラでないと呼び出しを削減したり、他の呼び出しとの順序を変えたりはしないし、
できない

>>551
ポインタの話なのに「代入演算子が定義されている場合」は無いだろう。

代入しないの？

じゃあa,b,cの代入演算子がinlineだったらどうなのか？
これも議論の余地があり、たしかにinlineであれば一般論としては
副作用の危険性もへったくれもなく関数呼び出しを除去してデータフロー最適化を利かせられるが、
初期化リストにおいては
本当にデータフロー最適化して（たとえば）aのコンストラクタが呼ばれたとみなすタイミングが不分明になると、
例外発生時にaを構築済みとみなしてデストラクタを呼ぶべきか、
未構築とみなして呼ばざるべきか、コンパイラに判断できなくなりかねないので
普通のコンパイラは初期化リストとそれ以外の間でコードを混ぜるような最適化まで踏み込まない

でもそんなの関係ねぇ

>>548
PHPはゴミだから論外

>>550
みんなg++の求人って見かけるもんなの？

#include<iostream>

template<typename T>
class first
{
typedef T* pointer;
};

template<typename T>
class second
{
typename first<T>::pointer p;
};

int main()
{
second<int> i;

i.p; // error!

}

fixお願いします。

>>558
なんのエラー？
無いメンバ使うなよ

>>558
structにするかpublic:を付ける
http://ideone.com/mTEH0

【初心者歓迎】C/C++室 Ver.79【環境依存OK】
http://toro.2ch.net/test/read.cgi/tech/1341052801/

>>559-560
ありがとうございます。

>>557
C++の仕事はよくみかける
VC++の仕事は今はもうみかけない

C++ばりばり掛けるなら我が社へ是非。
私の部署の案件は、gcc(含む派生版)8割、VC++1割、C#.net1割だ。

VC++ 指定の案件は無いけど、仕事で VC++ は普通に使う。

>>563
待遇とアクセス方法は？

いえないだろうけど、業種は知りたいなぁ
ゲーム以外でつかってるところってあるのかな

>>563
興味本位で聞きますけれど、c++がバリバリ書けるって、どんなレベルを指すのでしょうか?
デバドラとかコンパイラが書けるレベル？Linuxカーネルやapacheのコミッタとか？
それと、GUI周りって一般的には何が使われているんですか？motif?
guileなんかも書けた方が良い？

LinuxカーネルにC++なんか使うかよ

デバドラ
コンパイラ
Linuxカーネル
apache
motif?
guile

自分が難しいと思ってる単語必死に並べたんだろ。
生暖かくスルーしてやりなよ。

>>568
macの一部はc++で書かれているって、どっかの名無しが言ってた
>>569
難しいとは思わないが知ってる単語ならべただけなことは否定しない
てか、linuxなんて組込み、制御の他に何か使うような場面なんてあるの？

カーナビの芋臭いモニタはmotifだと思ってた
gdbじゃSTLのvectorなんか整形してくれないし、pythonかguileぐらいは弄れないと仕事にならんでしょ

くにへかえるんだな

>>572
君には聞いてないし、そもそも仕事で使ってないでしょ

まあ空軍少佐がC++使うことはないわな

>>574
おまえ専門卒だろw

募集はしているから、見ている人は判ると思う。
待遇は交渉次第。案件つきで来てくれたら優遇できると思う。
組み込み、通信系、数値演算、画像処理からちょっとしたGUIまで。
他人の書いたソースを理解してチューニングしたり移植したりできれば、
ライブラリは都度覚えればいい。

ってところかな。

>>576
情報を提供、ありがとうございました。もっと趣味で使い込んでから転職で移ろうと思います。

マ板の流れ

まいったな

なんちゃってーゲハハ

>>579
うるせーしね

>>580
禿同

やっぱ、ctimeよりtime.hを読むようにしたほうがいいな。
time.hにしかないものとctimeにもあるものと
両方読むときに困るわ

inputなstreamから、outputなstreamへ
全部流し込みたいんだけど、
ifs >> ofs
ってやったらエラーになったんだけど、なんで？

無理だから

ofs << ifs

ロストファンタズマ

>>583
>>のオーバーロードにstd::ofstreamを取る関数がない

やるなら
std::istreambuf_iterator<char>(std::cin) iic;
std::istreambuf_iterator<char> iiend;
std::ostreambuf_iterator<char>(std::cout) oic;
std::copy(iic, iiend, oic);
とか

なぜistream_iteratorの代わりにistreambuf_iteratorを、ostream_iteratorの代わりに
ostreambuf_iteratorを使うのかはやって見れば分かる
速度の問題

ただし実装依存なので必ずしも速くなる保証はない
1文字ずつの入出力の必要性がなく、先読み、まとめて書き込みが可能なために
最適化されていれば速くなるって事

ifs >> ofs.rdbuf();
http://ideone.com/UD5eJ

ディスクリプタをストリームに出来る？

うん

>>582
ctime = time.h では？

>>591
お前は一行目しか読めないのか

>>592
だってQは頭が悪いのに「俺様は頭がいいぜ」と自分で自分を褒めるしかない
自己愛性パーソナリティ障害患者ですから

>>590
ありがとう

>>582
>>592
へえ、ctime の実体と time.h　に差異があるんですね。手元の環境のctime 自身にも
This is the C++ version of the Standard C Library header @c time.h,
* and its contents are (mostly) the same as that header,
と mostly と書いてあるくらいですね。

time.h　をインクルードしたときも、名前空間は　std:: になるのでしょうか？

>>567
linuxのデバドラはCだが
c++でトライバ書かれたオープンソースのOSなんて恐くて使えない

C++のどの機能がドライバ向きじゃ無いと主張するのかね？

向いてないんじゃなくて、C++ のアドバンテージがあまり生かせない。

単にbetter cとして使ってもか？言っている事がよく分からないんだが
そりゃドライバにSTLを使う奴はそうそういないだろ

C++のアドバンテージ？
Cも書けるしC++の便利なところも使える

C99さえ使えれば

>>599-600
単に C と同じように使うなら、そのまま C 使うだろ。
カーネルまで C++ で書き直すならいざ知らず、ドライバだけ C++ なんてありえない。

better Cとして使うとか言ってる時点でc++はカーネルに向かないって自分でもわかってるくせに
linuxカーネルのコンパイラはgccだからbetter C的な部分はCでも書けるし

Cで書くと単純にコードが増えるんでメンドクサイ
あとテンプレート使いたい
まぁ、CRTが使えない場合はCRT依存の機能が全く使えないんだけど
カーネルモードならいざ知らずユーザーモードドライバーなら
CRT使えるからわざわざC使う道理もない

>>603
extern "C" を書くのが面倒臭いから
デバイスドライバは主にストラテジー部分とI/Oハンドラに分けられる
要するにデータをセットして後はハードウェアからの割り込みを待つわけだが、
こういう処理を書くのにそもそもC/C++だと面倒くさい

最も低レベルの部分は今でもアセンブラを使っている

だが、それ以外の部分はC/C++で十分であり、そうなると問題はC++の
名前マングリング(関数の多重定義を既存のリンカで実現するために使われ
ている技法)が問題になる

だから extern "C" でCで書いた部分とリンクが必要になるが、それが面倒臭い
だから全部C++でCライクに書いてしまう

OSのAPIならほとんどコールバックを使用しているのでC++の方がむしろ都合が良い

>>605
横槍だがextern "C"ってちまちまかかんでも
ブロックで書けるだろ。そんなに面倒か？

カーネルの話なのになんでユーザ空間の話になってんの？
Cで書けばextern Cも糞もない

そういう問題じゃないんだなー

C++でCの機能だけを使って書いた物とリンクする場合の手間がいらないだろうって
話をしているのに

なぜわざわざ余計な手間を掛けて機能が違わないCを使う必要があるんだ？

いやようわからんが、カーネルモードデバッガでC++シンボルのマングリングを
適切に処理できる奴がまだないからｼﾞｬﾈｰﾉ、
カーネルモードデバッガ様が言語処理系依存のマングリング規則を解決せねばならない義理も無いし、

それと、必ずしも解決不能な問題ではないが、C++のブートローダ（相当のランタイム）はCよりちょっとめんどくさい

カーネルモードデバッガでテンプレート関数やインライン関数に
正しくブレークポイントをかけたりステップ実行できるとか
どんだけ未来だよ、と個人的には思う
言い忘れたが、C++流デバッグのためにはメソッド呼び出しにおける暗黙の第一引数thisとか、
ポインタ渡しの言い換えに過ぎない参照渡しもぜひデバッガ─側で解決してほしいし

>>605
今時割り込み処理ごときでアセンブラって、どんな環境なんだ？

>>611
（えっ？！）

なにっ

>>611
なんだって？割り込み処理がC言語の規格に入っているって？それは初耳

何なに？OSを使えばいいって？そのOSから呼び出されるのがデバイスドライバ
なんですけど
それをどう書くかという話なんですが

開発環境次第なんじゃない

なんでCの規格の話に摩り替わるのか意味不明過ぎるな

環境依存の話は次スレで

【初心者歓迎】C/C++室 Ver.79【環境依存OK】
http://toro.2ch.net/test/read.cgi/tech/1341052801/

>>616
>611は割り込みハンドラをCの関数として書くと言っているんですが…

>>618
だからそれがどうしてCの規格の話になるんだ。
そんなの例えば組み込みの世界じゃ昔から当たり前。馬鹿かよまったく。


俺はよく知らないが、WindowsのDDK（今は名称変わってると思ったが）でも
とっくにアセンブラは必用がなくなっていると聞くが。

だから環境依存の話はここでするなって

それにC++じゃなくてCの話ならなおさらスレ違い

>>614
本当に低レベルな奴は gcc の __interrupt__ 属性とか
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

Linux/Windows とかの OS なら ddk とかのフレームワークがあるので、
Ｃだけで用が足りることも多いよ。

マジでレスしてるなら、相当勉強不足だから、Windows DDK のドキュメントとか
Linux デバイスドライバのソースでも読むことをお勧めする。

>>619
>そんなの例えば組み込みの世界じゃ昔から当たり前。
えっ？！
割り込みハンドラの初段からCの関数だったりしたら、一般に割り込みの度に半分ぐらいのレジスタが破壊されるぞ…
（確かに処理系依存の呼び出し規約の話であって、純粋はC言語規格からはそれるが

えーと、
・どんだけレジスタ破壊し捲くってんだよ
・どんだけレジスタ少ないんだよ

どっちで突っ込もうかw

>>623
高水準ｗプログラマは黙ってろよｗｗｗ

>>621
だからそれは環境依存

>>622
いい加減馬鹿自慢は見苦しい。

>>626
後学のためにどこらへんが馬鹿なのかkwsk

>>625
環境に依存せずに書けるかどうかなんていう前提条件は誰もつけてない。
君以外は。

どっか病気なんじゃないの君。

>>626
GCCの__interrupt__属性などを使って初めて素のCの関数で割り込みハンドラが書けるわけだが
Understand?

>>629
何を訳のわからんことを言ってるんだ。
マジで病気だろあんた。

>>630
>何を訳のわからんことを
はいこの問題を論ずる資格無し

オンラインで参照しやすいところでNois IIの例だが
↓ここの表7-2とか
http://www.altera.co.jp/literature/hb/nios2/n2cpu_nii51016_j.pdf

「呼び出し元で保存される汎用レジスタ」r8〜r15は呼び出し元が保存義務を負うが、
割り込みハンドラは呼び出し元が無く、割り込み信号でいきなり呼ばれる点が通常の
（つまり、呼び出し規約を遵守するコンパイラが想定する）関数呼び出しとは異なる
そんなｼﾁｭで素のCの関数が呼ばれたら、表7-2で言えばr8〜r15が割り込みの度に破壊される
__interrupt__属性はこの呼び出し規約を割り込みハンドラ向けに変更するもの

>>625
だからどんな環境よ？ [>>611]
って書いてあるんだが、頭大丈夫か？

アセンブリをアセンブラー呼ばわりする自称ハード屋の話は信用できん

ハードウェア割り込み(IRQ)ハンドラ
システムコール側のソフトウェア割り込み(SWI)ハンドラ
OSから呼ばれる割り込みハンドラ(Linuxのシグナル,Windowsの構造化例外)

で話が噛み合ってない気がする

デバイスドライバの話してる時に、

> システムコール側のソフトウェア割り込み(SWI)ハンドラ
> OSから呼ばれる割り込みハンドラ(Linuxのシグナル,Windowsの構造化例外)

なんて持ち出すアホは君以外にはいないと思う。

>>635
きっと相手はそれをわかっていて、文脈上の環境をすり替えたに違いない！
って相互に考えてると思われ

>>636は割り込みベクタに直にドライバのエントリが置かれると思ってそう

>>638
割り込みハンドラーのエントリーポイントとでも言うならわかるが、
ドライバのエントリってＯＳによって意味違うから、いきなり使う奴は
多分ドライバ書いたことが無いアホ。

Windows のドライバエントリ
http://support.microsoft.com/kb/102989/ja

割り込みとポーリングの区別も付いてない奴がいそう
特にUSBは両方共使っていて複雑だしモードも多いし

>>639
割り込みベクタって書いた時点で分かるだろアホ

なにがわかるんだ？
お前のアホさ加減かよ (w

質問なんだけど詳しい人おしえて
ドライバの関数って普通はカーネル経由で呼ばれて、レジスタは気にする必要無いんじゃないの？
__interrupt__ってそのカーネルを書くときに使うやつじゃないの？
I/O用の関数をカーネルが持ってる場合はアセンブリ無くてもドライバ書けるんじゃないの？

>>640
どこのレベルで話しているか知らんけど、USB プロトコルはポーリングしか使ってないぞ。
インタラプト転送モードってあるけど、デバイス側から非同期で割り込みが上げられるわけじゃないよ。
※ 3.0 は知らんので、3.0 にあるならスマン。

>>642
分からないならいいよアホｗ

>>644
転送完了した時に割り込みで知らせてんだよアホ
あんたのマシンに何のOSが入ってるかは知らんが、Widowsならリソース見てみろや
ちゃんとUSBの割り込みがあるだろうが
単なる飾りだと思ってんのか？

>>643
せめてＯＳぐらい書かないと、ドライバって千差万別だから、知ったか君が自分の知ってるＯＳの
話し始めて収拾付かなくなるぞ。




って、このスレの流れ見てもわからない奴に説明してもしょうがないか。

>>646
「USB プロトコル」って文字が見えないのかよ…

>>645
捨て台詞乙。

>>647
Linuxで、出来ればWindows(XP以降どれでも)もおながいします

まあ、環境次第ではなにつかっても書けるようになってるとしか言い様がないだろ。

新規ハードだったらどうなるだよ。

>>648
ああUSBプロトコルはポーリングだな
だからバースト転送なんか行うと(外付けHDDとか)CPU負荷が半端ない
もっともUltra DMAを使ってるSATA IDEもUSBほど負荷は高くないが似たようなもんだけど

>>650

>>621
>> Windows DDK のドキュメントとか
>> Linux デバイスドライバのソースでも読むことをお勧めする。

>>649
割り込みベクタに設定するドライバ側の割り込みハンドラのエントリポイント
割り込みベクタの話に>>639のURLを出してくる時点でただの文盲

>>652
>だからバースト転送なんか行うと(外付けHDDとか)CPU負荷が半端ない

何がだからかは知らんが、今時 USB のポーリングに CPU が関与する奴なんて
相当珍しいぞ。

>>653
大雑把な説明も無理？

>>652
SATAでも専用ボードを差してる奴は勝手にHDDとコントローラの間でハンドシェイク
するので時々CPUが指示を与える(セクタ番号とか)だけなんでSCSIに近いな

事実SATAカードを差すとSCSIカードとして認識される

>>654
> 割り込みベクタに設定するドライバ側の割り込みハンドラのエントリポイント

だったら、初めからそう書けばいいだけの話。

> 割り込みベクタの話に>>639のURLを出してくる時点でただの文盲

適当な言葉使うから馬鹿にされてるだけだよ。

>>658
文盲がよく言うｗｗ

>>655
ポーリングにCPUが関与するとは言ってないだろ
だが転送の時にCPUがI/Oに直接携わっている割合が多いから外付けHDDはCPU負荷が高い

嘘だと思うなら「外付けHDD CPU負荷」でぐぐってみろ
粗悪なドライバのために泣いてるユーザーが多い事がわかるから

>>656
大雑把には、>>643 の理解であってるよ。
そういう風にするために、色々設定とかが必要だけど。

>>660
それは、USB がポーリングがどうかには関係が無い。
データ転送に CPU を使うかどうかの問題。
ごっちゃにするなよ。

http://pc.watch.impress.co.jp/docs/column/interface/20100902_390904.html
http://pc.watch.impress.co.jp/docs/column/interface/20100902_390904.html

この当たりよく読んどけよ

USB2.0がいかにオーバーヘッドが高いか、そしてUSB3.0でそれがどのように改良されて
CPU負荷を減らす事に成功しているか分かる

> Core Solo 1GHzを搭載した富士通のLIFEBOOK U)にUSB 2.0対応のマウスを接続すると、
> いきなりCPU負荷がガンと上がってしまい、むしろ使い勝手が落ちてしまうという経験をしたことがある

しょぼい機器持ってるアホ記者の記事貼って何をしたいんだ？

>>661
回答ありがとう
そういうやり方でドライバを作るのってマイナー？
最初に興味持った>>611-614の流れがそんな感じだったので
※自分は勿論ドライバ開発経験無し

>>664
最悪の状況を想定しとけって話だよ
自分の所でだけ動けばいいってそれ仕事人の態度じゃないぞ

>>665
今時普通にＣだけでドライバ作ってる。
(もちろん、全てではないが。)

>>612-614 は、無視していい。

それは案件次第
どんな範囲で何ができればよいかは常に有限

>>666
> 自分の所でだけ動けばいいってそれ仕事人の態度じゃないぞ

別にそいつのシステムの保守請け負ってるわけじゃないし、どうでもいいよ。

>>667
ありがとう

低層と高層な仕事だと、どちらが安定しているもんなの?

>>667
ｷｲｯ >612を無視していいリストに含めんなﾊｹﾞ
>611に対する反応としては>612で全く正しい

>>672
>>612

ハードウェア設計者は高いみたいだけどな。
アセンブラや低レベルができますってのはオプションなんじゃない？

言語自体はアセンブラの方が簡単な希ガス

アセンブラは簡単だけど超面倒臭いな
レジスタとかフラグとか常に考えないといけないし、同じ事をするのに
C/C++で一行で書ける事が何十行になったりする

こんな感じのconstついたり、つかなかったりを型で条件分けしたパターンがいくつも続く場合って
１つにまとめれないのでしょうか

template<typename T1, typename T2>
f(const T1 & t1,const T2 & t2
,typename boost::enable_if<boost::is_arithmetic<T1> >::type* = 0
,typename boost::enable_if<boost::is_arithmetic<T2> >::type* = 0
){...

template<typename T1, typename T2>
f(T1 & t1,const T2 & t2
,typename boost::disable_if<boost::is_arithmetic<T1> >::type* = 0
,typename boost::enable_if<boost::is_arithmetic<T2> >::type* = 0
){...

できるにはできるが





















馬鹿には無理

C++0xになるけど、
template<typename T1, typename T2>
void f( T1 && t1, T2 &&t2 ){}
でまとめられる予感。

template<typename T1, typename T2>
inline
void fsub(T1 & t1,T2 &t2 ){...}

template<typename T1, typename T2>
void f(consy T1 & t1,const T2 &t2 ){f_sub}

boostのプリプロセッサでそういうのを展開するのがあるんだが
重すぎて大変。

>>675
その何十行をマクロ化することに燃えてた時代もあったな。

>>681
今ではcompiler_intrinsicsとなって固まったけどな
こいつが吐くコードがまたたまにバカみたいに無駄の多いコードで

gccやMS C/C++ Optimized Compiler付属のアセンブラって
アセンブリでマクロ書けるんだっけ？

>>683
MASM はかける。今はmlはMS(V)C に付属しているんですか？

cl.exeにアセンブリ食わせられるがアセンブラ自体がどこの有るかは知らん

int*　a,b int c,dがあります。
c,dはaとbの長さがあります
aとbの長さzとは*aをa[0] ,a[1],...と分解して
さらにa[0],[1],...を２進数列で分解してx_1,.......,x_32, y_1,...........
と分解したとき2進数列のz番目以下の値は定義されていることをいいます。
このときaのｃまでの値後ろにbのdまでの値を付け加えたeを作りたいんですけど、
eに対してもまたfを付け加えてgを作ったりしなければなりません。
このときa,b,e,fのデータ構造を全て同じなものに書き換えて効率のよいものにしたいのですけど
どのようにしたらいいですか？

vector<int>でおｋ

>>686
説明が判らん。
cはポインタaの長さがある。
これだけでもう、ちんぷんかんぷんだ。
まして、bは整数型でaとは型が違うのに同じように扱うのか?
それに、*aをa[0], a[1],... と分解するってどういうことだ?
*aがそれすなわちa[0]なのに分解とはどういうことだ?
データ構造を効率化するよりも先ず、他人に説明できる方が重要だぞ。

>>686
全然わからんｗ
現状で精一杯のコードをさらせば、誰かが最適化してくれるんじゃね

https://sites.google.com/site/efcpp01/wiki/wiki04
std::shared_ptr, std::unique_ptrが標準であるので，それを使えばよい．
また，これらのスマートポインタは「オーバヘッドがゼロ」であるため，生ポインタを使うときとくらべてもパフォーマンスに遜色はない．
なので，使える環境があるなら積極的に使えばよい．


ってマジなの？オーバーヘッドゼロってどういう原理？

ヴォイニッチ手稿よりは読解がたやすい
>686は、intを32 bitと仮定しており、aやbの長さzは、aやbが指すint型配列のビット数、
ただし「2進数列のz番目以下の値は定義されている」とあるから、zは32 の倍数とは限らない（定義のされ方次第
という具合に、zはaやb形式のビット列の正味のビット数を指す
こう考えれば
>このときaのｃまでの値後ろにbのdまでの値を付け加えたeを作りたいんですけど、
の意味は明らかで、aが指す配列の先頭cビットと、bが指す配列の先頭dビットを連接したビット列eを作りたい、の意

vector<bool>とかboost::dynamic_bitsetじゃだめなん？

へえ
dynamic_bitsetにはappend()ってメソッドがあるのか
奇っ怪なコンテナだな
確かに標準のstd::bitsetじゃ大きさ固定だし

>>690
スマポ一神教の糞どもがスマポを布教しようと嘘で勧誘してんだよ
オウム真理教の麻原が空を飛べるとかいうのと同じぐらいの嘘っぱち
だからそんな邪教には手を出さず生ポインタをつかうべきそうするべき

>>690
std::unique_ptr<T>はともかく、
std::shared_ptr<T>については、ナマポ＋参照カウンタ（か何か）が必要なので、空間のオーバーヘッドゼロ（ナマポと同じメモリ消費）というのはちと怪しい
空間のオーバーヘッドがゼロでないということは、代入やコピーはナマポより遅くなりかねない
（まあ代入やコピーの時間がナマポと同じになる実装が全く不可能かというとそうでもないが

また、とうぜんながら構築や破棄は素のnew/deleteよりは遅い

ただ、スマポが保持するTのオブジェクトへのアクセスの時間オーバーヘッドは、最適化がちょっとがんばればゼロになる

と思う

ｽﾏﾝ、
>（まあ代入やコピーの時間がナマポと同じになる実装が全く不可能かというとそうでもないが (695)
これはないわ、実装を工夫してスマポ本体のサイズをナマポと同じにできても、
代入やコピーの際に所有権に関する処理（委譲や参照カウンタの更新とか何か）があるので
どうしてもナマポの代入よりは遅くなるハズ

shared_ptrは動的削除子がある分どうしても重くなるわな
(virtual destructor不要)
でもあれだけの機能を備えつつメモリをナマポの倍しか使わないとか優れもの

sharedで遅いのは生成破棄と複製だな
カウントはアトミック操作だからどうしても時間かかる
boostのほうならマクロでOFFにできるけど

過去の同じような話題

302 ：デフォルトの名無しさん [sage] ：2012/05/25(金) 17:04:43.03
　shared_ptrはともかくunique_ptrは消費メモリもオーバーヘッドも生ポインタと変わらんと思う

303 ：デフォルトの名無しさん [sage] ：2012/05/25(金) 17:23:15.50
　生成と破棄x30000000、sizeof比較

　int*: time: 2.13s
　http://ideone.com/2tLcx

　std::unique_ptr<int>: time: 2.13s
　http://ideone.com/wtba4

　std::shared_ptr<int>: time: 4.41s
　http://ideone.com/UDuJE

　sizeof:
　http://ideone.com/EtftU
　> sizeof(int*) = 4
　> sizeof(std::unique_ptr<int>) = 4
　> sizeof(std::shared_ptr<int>) = 8

結論＝ユニポ使え、ということなのか？

try-catchで例外安全にするの面倒だし
所有権が移るような代入もそんなに使わないから俺はスマポメイン

所有権の無い参照としてのポインタは当然ナマポだから
全体としてはナマポ方が多いけど

�@変数のスコープがはっきりしてる場合
ポインタではなく自動変数を使えば良い

�Aスコープを超えて寿命があるがしっかりと所有権が管理されてプログラマの支配下にある場合
むしろプログラマの管理から意図せずして所有権を奪いかねないunique_ptrではなく生ポインタを使うべきである

�Bスコープを超えて寿命が在り、なおかつ共有するオブジェクトが多くプログラマに管理しきれない場合
shared_ptrを使うべきである



以上の考察からunique_ptrに存在価値はほぼない

またスマポで荒れるのか

>>702
ユニポは意図しないと所有権が移動しないようになってるけど

>>702
�Aは何でナマポだと解決するの？

また生ポ脳か

質問ですが、class Bについて、メソッドでなく普通の関数として等値演算子
　bool operator==(const B& lhs, const B& rhs);
を定義し、なおかつBの派生クラス（公開属性で派生）Dのオブジェクトx, yについては
　x == y
と書いても上のoperator==()が呼ばれないようにしたいんですが、何かいい方法無いでしょうか
やっぱり bool operator==(const D& lhs, const D& rhs);を定義して、
ただし例外でも投げるみたいな作りにしないといけないんですかね…

>>702
�Aでボロが出てるぞ

お前ら解ってないな
デストラクタってのは見えないコードなんだよ
プログラマが支配者の環境ではそんな悪魔が入り込む余地はないほうがいいんだよ

>>707
Dの等価演算子を宣言だけして未定義にすればいい

>>707
こんな感じ？
http://ideone.com/M0fbC
http://ideone.com/9wI7R

特殊化をコンパイルエラーにさせる場合って普通どう書くんだっけ？

これ影響範囲大きいか、ごめん>>711は無しで

struct B { int i; };
struct D : B { };

bool operator == (B const & a, B const & b) { return a.i == b.i; }
bool operator == (D const & a, D const & b);

int main(void) {
B b;
D d;
b == b;
// d == d;
return 0;
}

>>707
Bの派生全て呼ばれないようにしたいのか
それともDだけなのか

>>710
なるほどごもっともです。Dの等値比較をやろうとするとリンクエラーになるからわかるというわけですね

>>711
コンパイル時エラーの起こし方が超クールっすね
おまけにB以外のクラスの等値比較が全部エラーになるというあたりがＧＪですな

だいたい>710のやり方で実用上ほぼ問題無いのですが、基底クラスB一つに対して
派生クラスが大量にある場合、派生クラスのoperator==()の宣言忘れがあったりすると怖いですね、、
まあ派生関係の子についてもらさずやっておけば、孫以下は安心みたいですが、、

そういう設計になる理由が気になる

bool operator==(const B& lhs, const D& rhs);
bool operator==(const D& lhs, const B& rhs);
bool operator==(const D& lhs, const D& rhs);

たぶん意図しているだろう挙動を得るには宣言が3つ必要だから忘れるなよ

>>715
これ派生に限らず、Bとまったく関係無いクラスまで
<T>で取り込んじゃうからで危ないかも

>>716
まあ等値演算させたくないDをBから公開属性で派生するのはやめるのが吉ですかそうですか、
等値演算以外のｼﾁｭでDからBへの型変換を希望するときのために、明示的型変換（にほぼ近い）メソッドをDに設ける。
B& D::GetB(); とか。（ユーザー定義型変換にexplicitが書けて、かつコンストラクタ呼び出し回数の最適化がきちんと利けばればクールなんですがね…orz
というわけで、>710で凌ぎつつ、様子を見てGetB()を設ける方向でいこうかと

>>717
Dの等値比較を見たコンパイラは引数にB,D混在な宣言より先に
bool operator==(const D& lhs, const D& rhs); の宣言を探し、
それがあればそれを使うのでB,D混在バージョンの宣言は不要なはず
（ていうかそもそもC++コンパイラって、暗黙の型変換の介在で呼び出し可能な全ての引数の組み合わせを全部チェックするんでしたっけ…

基本的に基底にできることを派生できなくするpublic継承は邪道なんだよ（個人的にはvirtualも邪道だと思っている）
能力の包含関係でいうとBはDに含まれてないといけない
まあ理想だからすべてがそうなるとはならないんだけどね

bool operator == (D const&, D const&) = delete;

>>719D同士の比較だけ禁止したいなら一つでいいけど
DとBの比較も禁止したいんだろ？ってこと

混在した2つがあれば用は足りるとはいえ
意図を明確にするためには全部書いたほうがいいんだろうなあ

>>711みたいにtemplate使った上にboost.type_traitsのenable_if, is_base_of, is_same辺りを組み合わせれば

>>701
> 所有権の無い参照としてのポインタは当然ナマポだから
当然参照だろ？何言ってるんだ？

>>707
DはBをprivate又はprotected継承してusingでメンバを公開するのはどうだろうか
アップキャストが出来なくなるからoperator==が呼ばれないと思う

ナマポの戦いはこれからも続く

>>726のコード
ttp://codepad.org/jAqgVmxh

Bへのアップキャストはしたい、けれどもBのイコール演算子を適用したくないってのはもう設計ミスってる気がする

きのこたけのこ並

仮想関数じゃないとオーバーライドはできないよ
と関係ないつっこみ

新しいクラスで全部ラップしちゃえよ

>>730
そんな事無い
virtualは親クラスのポインタや参照から呼ぶときにvtblを参照して飛ぶもので少なくともvirtualじゃないとオーバーライド出来ないとかでは無い
以下実証コード、あと子クラスがオーバーライドを提供する場合はusing宣言が要らなかったことを訂正
ttp://codepad.org/pxdDc7Wb

それはオーバーライドではなく隠蔽(hiding)です

ggってきた
なるほど親クラスの関数が仮想関数でありかつ型が一致していないとオーバーライドではないので>>732で言ったことは間違いだと
今まで誤った解釈をしていたわありがとう

初心者が横から入りすみません。
http://codepad.org/l7ZHi7GZ は教科書どおりで初心者としてよく理解できるのですが、

基底クラスを private で継承したとき、
http://codepad.org/FzZmEaBe　 （？）
http://codepad.org/DlFN6fRN　　 （？？？）
がコンパイルできない理由がわからないでいます。

基底クラスを private で継承したとき main() からみえないものはなにでしょうか？
よろしくお願いいたします。

main()からは継承していないかのように見えるとでもいえば簡単だろうか

親クラス

>>707
template< class Derived > bool B::operator==( const Derived& rhs );
template< class Derived > bool operator==( const Delived& lhs, const B& rhs );
これじゃだめだったか？

>http://codepad.org/DlFN6fRN
関係ないけどこれエラー行が分かり辛いな
実際のエラー箇所はLine 41なのに

>>716>>728
設計ミス設計ミス簡単に言うたかてな〜；；
・operator==(lhs, rhs)は、lhsとrhsの実体が同一である限り真偽が一貫しているべきである（さもないと予想外のｼﾁｭでバグを生じる
・オブジェクトは状態を持つ。これは、operator==(lhs, rhs)が、lhsとrhsの実体が同一であっても
　一貫性を保たない（時とともに真偽が変わる）ような設計が言語思想上禁止まではされていないことを意味する
　オブジェクトの状態変更を禁止して、全部オブジェクトの新規生成に置き換えるのはパフォーマンスに響くケースもある
　（真に一貫性を強制したければ、関数型言語でも使うわ
・Bをpublic継承するD（複数種類ある）は一般にBにない追加データメンバをもち、そのうちの一部は時とともに状態を変えてD同士の==にも影響する
・この場合、時間とともに変化する追加データメンバを持ってしまったDのopeator==(D, D)狙い撃ちで禁止するのが最も近道

C++の自由度の高さの中から全ての要件とプログラマの立場からの希望を満たす設計をひねり出すのは
なかなかに時間と根気を要する仕事でありまして、後者はしばしば後回しにされがち
ていうか設計のための設計はｲﾗﾝ、というのが管理する立場の平均的意識であるﾊｽﾞ

>>722
説明不足でもうしわけなかったが、BからDを継承する際に追加されたデータメンバの時間変化が問題なので、
BとDの比較は特に問題は無い

まぁjavaのequalsもgetClassで比較して派生クラスだったら
実行時例外にするとかよくあることだしな
実行時よりコンパイル時に分かる方がいい

>>739
確かに Line 41 を表示しないのは手抜きだな。

Visual Studio 2010 だとこんなかんじ。

------ ビルド開始: プロジェクト: Test, 構成: Debug Win32 ------
main.cpp
main.cpp(41): error C2247: 'B::hiddendisplay' はアクセスできません。'D' は 'private' で 'B' からの継承で使われています。
main.cpp(15) : 'B::hiddendisplay' の宣言を確認してください。
main.cpp(20) : 'D' の宣言を確認してください。
main.cpp(5) : 'B' の宣言を確認してください。
========== ビルド: 0 正常終了、1 失敗、0 更新不要、0 スキップ ==========

gcc 4.1.2じゃそんなもんだろ
http://ideone.com/4LHUo

>>721
Visual Studio 2008/2010で通らないでつД`;)

VC2010で、operator ==でenable_ifしようと思ったら、
引数が多すぎます、既定のパラメを指定できません、って怒られたわ。
それじゃと思い、テンプレート引数上でenable_ifを使ったら、
そういうの使えるの、classだけだから。関数はダメって怒られた。

型を持った配列を作るにはクラスに埋め込むしかないのでしょうか？

boostのスレッドってなんで消えたの？

要らないからじゃね？

boost::threadがなくなったのかと一瞬思った

マルチスレッドプログラミングしたい場合の選択肢を全て
おしえてください。

C#

C++スレッドなのでC#の話題は他でお願いします。

C++からC#を呼べばいいハイ論破

>>750
これから登場するかもしれない選択肢まで含めて網羅することは不可能。
一般的なものを挙げることは可能だが、それなら普通に検索すればいい。

>>750
まずあなたが知っているものを挙げてください

そういえばC++でpthreadのかっこいいラッパーって無いよね

>>756
うんこに金箔つけてもうんこはうんこ

>>757
うんこを塗りつけるんだから逆じゃね？

犬のうんこを処理する際に素手でそのままもちかえることはできないが
うんこをビニールぶくろに入れてしまえばたやすく処理できる
これがカプセル化です

いいえ違います。それはラッパーです。

ラッパのマークの？

どんどん？

shared_ptrって一時的にスレッドセーフ解除することはできないんですか？

>>763
ナマポもらって突っ走ればいいじゃん

スマポって大抵は参照カウンタ持ってるよね？

shared_ptr とかで、「誰かが今参照してマース」 というのを
確認する手段ってある？

use_countとかuniqueとかあるじゃん

>>739
>>736
ありがとうございます。おっしゃるとおり「基底B から派生Dが導出されている」ことがmain() からみえないとすれば納得できます。
継承の書式における private/protected/public はメンバのアクセス制御だけではないのですね。

VC10 / VC11RCにて

std::wstring r1 = L"3445";

std::wcout << r1 << std::endl;

std::wregex wr2(L"(.)\1+");
std::wstring fmt2(L"x");
std::wstring r2 = std::regex_replace(r1,wr2,fmt2);

std::wcout << r2 << std::endl;

実行結果
3445
3445

任意の数字列にて、同じ数字が連続するものを"x"に置換したいのです。
この場合"3x5"になって欲しいんですが、何故マッチしないのでしょうか？

>>768
君さ、これは恥ずかしいことになってるぞ。

L"(.)\1+" →　L"(.)\\1+"

正規表現のエスケープシーケンスとC++の文字列リテラルのエスケープシーケンスで
二重にエスケープシーケンスでワケワカになっちゃうのは分かるけどさ。

>>769
oh...
確かに。
ありがとうございました！

そんなあなたにraw string literal

template<typename Ret...>
Ret foo(...){...
return ret;}

template<typename Ret...>
void foo_cps(Ret &ret ,...){...
ret=... ;
}

関数の返値を2通りの扱いできるようにしてるのだけど
同じ定義を2回,毎回書くのバカらしい
何かよい方法ないでしょうか

内容的に違うじゃん、左辺値と純右辺値で

ttp://codepad.org/zImnVYAZ
上のリンクにあるようなコンストラクト時にストリームを受け取り、デストラクト時にそのストリームにログを出力するクラスを作っています
ここでもしそのストリームが例外を投げるとしたらデストラクタで例外を投げることとなってしまい、危険なコードになってしまいます
なので、リンクのようにデストラクタにおいては例外を握り潰し、その代わりとして例外発生時にそれを伝播させる関数を作ることで対処しようと思いました
この他にデストラクタで例外を投げてしまうことへの対処法は有るのでしょうか、お聞かせ願いたいです

iphoneアプリ、Windowsアプリを売って生き残れ

格安iPhoneEラーニング(学習動画多数あり)
http://tinyurl. com/7wj77om
コワーキングスペースJP
http://tinyurl. com/76vdrny
コワーキング帳
http://tinyurl. com/brzs486

javaやlinuxは手間がかかる　一人でやるには手間がかかりすぎる　手間がかからないで一人で開発できて
人の多いところで直接販売できる仕組みが提供されているメーカ製言語だけやる　ずばりiphone またはWindow 8 Metro App Store C#
やるならメーカー製の言語 洗練された仕様 脆弱性が少なく 開発ソフトが優れ 課金ライブラリ アップデートライブラリが提供されていて 情報、書籍が多く開発しやすい
奴隷になりたければオープン系をやればいい　時間がかかり 人は多く 仕事の取り合い 足の引っ張り合い 脆弱性が多く 互換性がなく 癖があり 大規模開発中心
詳細設計しかできない体になって年取ってぽいだ　独立もできない　手間のかかりすぎる仕様だから　

派遣屋 IT経営者はその方が喜ぶ　大規模分割開発では使い捨てても独立はできまい 嫌なら辞めろ 代わりはいくらでもいる
若い派遣営業は舐めた態度をとってくる ひどいピンハネ

オープン言語、日本独自開発 言語・フレームワーク ガラパコ携帯 javascript html5 android java linux python rubyやnode.jsとかやめとけ
メディアに金を払ってステマ宣伝してくるが釣られて手を出しても情報は少なく手間がかかり スパゲッティコード 未完成 デスマに陥る
コンパイルできないからパクられ 　直接売る場所がないから企業に買い叩かれ金にならない　生きていけない奴隷仕様だ

ここから抜け出すにはiPhone一択 またはWindow 8 Metro App Store(未確) C#
Objective-CやC#を覚えるとサーバーサイドからクライアントサイドまでカバーでき人の多い場所でソフトを売る権利を得られる
仕事や趣味でObjective-CやC#をやっておけば派遣切りされても会社辞めることになってもソフトを売って生きていける　それはセーフティーネットになる
WEBサーバーIIS Win2008ServerVPS SqlServer Oracle MySql 言語はマーケットで売れるメーカー製のみ C#は自分用業務支援ツールとして使える　
例えばPHPでWEBアプリを作っていて管理者画面はC＃(EXEアプリ)で作るとかなり早く作れる（Smartyなんか使うよりもかなり早くだ）
C#のソースを出さなければWEBアプリの著作権も守れる ASP.net(C#)+管理EXEアプリ(C#)+iPhone

C#マーケット　Windows8 Metroアプリ WindowsPhone Surface PS Vita Xbox360 iPhone(mono使用)
iPhoneマーケット iPhone iPad 予定 iTv iCar i (家電製品)

地方に安い土地を買いコンテナ型の格安高性能オフィスを建て(300万〜500万)
レンタル自習室＆シェアオフィス・コワーキングで収入を得ながらそこでアプリを開発する
http://tinyurl. com/7pb2yaa
http://bit. ly/iLIpJa
iPhoneはヤフオク脱獄iphoneで 15kで買える IIJmio,イオン.BB.exite,DTIで月千円程度で利用できる

>>775-776
ばーか＾＾

>>774
void close(){
　if(closed){return;}
　closed=true;
　output();
}
~Logger(){
　try{close();}catch(...){}
}

close呼び出しは必須でなく推奨扱いにして使う側に任せる

独立に必要なのは詳細設計以外のフェーズなんかじゃない
資金500万の使い方すら頓珍漢もいいとこ何もわかってない

言ってる内容から察するに
こいつ自身にとって独立が自らの問題になったことはない

最近「ハッシュ」とやらを知ったがすげえ高性能だな
感動した

いまいちハッシュの高性能性がわからない俺に解説オナシャス

連想できるところ
あとは朝マックのあれ

お題
ハッシュから連想できるもの

連想配列

ハッシュポテト

ジェットストリーム・・・　いや何でもない

一方向性関数

バッシュ

金色のハッシュベル!

std::map

それは二分木や

ハッシュといえばディープ・パープルだろ？

人名でありそうだな……
と思って最初に浮かんだのはヴァッシュだったorz

>>792
それから連想するのが ADAYINTHELIFE だな

クロノトリガーの時の最果てに居る時の賢者ハッシュ

>>795
ライブアライブのハッシュを忘れるなよ
先に出たのはあっちだぞ

>>778
やはりそれが最善でしょうか
ありがとうございました

>>774
明示的に処理する関数を用意することは当然として
デストラクタでのエラー処理の挙動は外から与えるように作ればよい
文脈によってエラー処理の方針は常に変化するのであるからクラス側で固定するべきではない

>>798
なるほど
しかしそのクラスはテンプレートクラスで、どのような例外が投げられるかは全く分かりません
またそのクラスは頻繁に生成破棄を繰り返すので動的に関数を持ち運ぶのは出来ればしたくないです
静的に処理するにはどのような方法が有るでしょうか

>>799
そういう場合はポリシーを使いましょう

どうせデストラクタのタイミングでのエラー処理じゃログ出すくらいしか出来ない

プログラミング10数年にして今さら dynamic_cast を知ったんだが、
何が便利（どう使えばいい）か教えてくれ。

キャストできないときに NULL が返るのは分かったが、
別に NULL チェックがしたいわけじゃないし、
キャストするときは大抵基底で判別してからやらない？

キャストしまくってポインタが返ってきたものだけ処理するとか…そんな書き方するのか…？

使わないで書けるなら使わないしどうしても使わないと面倒なら使う

普通にC++使ってれば使う場面なんて一生に一度ぐらいじゃないか

だってメイヤーズおじさんが使うなって言うんだもん

>>801
ハンドラで例外を受け取って後で再スローという手も

//close
void f1(){
　Logger<T> lg(st);
　lg.put();
　lg.close(); // throw
}
void f(){
　f1();
　f2(); //実行されない
}
―――――――――
//handler
void f1(){
　ExHandler h;
　{
　　Logger<T> lg(st, h);
　　lg.put();
　}
　h.checkThrow(); // throw
}
void f(){
　f1();
　f2(); //実行されない
}

ありがとう。

ずっとC言語キャストばっか使ってたから、今の仕事でC++キャストを強制されて、すげーストレスなんだ…。
他のキャストはとりあえず分かったフリをしたが、dynamic_cast だけはこんな仕様必要か？って思ってしまったんだ。
とりあえず我慢してC++キャスト使っていくよ…。

…アンダーバーとか面倒じゃないのかねぇ。

デストラクタでの例外の可能性のあるコードって握りつぶそうが何しようがそれはもはやバグだから俺ならすぐに落としてしまうが
開発段階でそんなコードはぜんぶ潰すように心がける

> 他のキャストはとりあえず分かったフリをしたが、
> dynamic_cast だけはこんな仕様必要か？

リップマン先生も同じこと言ってたし

>>807
キャストは少ないほどよい
キャストは基本的に悪
悪い事はめんどくさい事しないとできないようにしよう
というのがC++の文化
だからキャストはだらだら長くてださい予約語を割り当てた
Cスタイルキャストも仕様から除外したかったが互換性のために仕方なく残した

>>807
そもそもすげーストレスになるほどキャストを使っているという状況が
おかしいのではないか？

DAYONE-

キャスト使いまくるとかどんな設計なんだよそれ……

>>810-813
やっと動き出した仕事なので、書きまくってる訳じゃないです。
ファイル読み込みでポインタいじらにゃいかんところで使ってたぐらいです。

ストレスってのは、今までの書き方ができないストレスかなぁ。
>>812の通りで無駄に長くて、変な文字打たせて、揚句ソースは汚くなるし、
やってることは変わらないというのがどうにもね…。

>>800
STLにおけるアロケータのような仕組みはポリシークラスというのですね、勉強になりました
しかしポリシーを用いてもスローされる例外の種類が分からない以上適切な処理を行うのは難しいと思うのです
解決策としてはストリームを渡すことによってそのストリームの状態を使ってエラー処理してもらう事になるのでしょうか

>>9
数年ぶりに来たけど、まだあって安心した。

std::pair と同じデータ構造使いたいけど
同じ型だとコンパイルの自動型推論（ポリモアフィズム？）でおかしくなるので
struct mypair: std::pair
{};
を作った。

継承なんてしてるせいで実行速度減らないか心配
std::pairをそのまま使った方が速度は速い？

かわんないんじゃね

>>802
D&E読めば書いてあるがRTTIの一環で考案された。
基本的には派生クラスの機能を使用する時も仮想関数でキャストしなくてもいいようにするはずだが、
時には特定の派生クラスの型情報がいる時もあり、そういう場合にdynamic_castでダウンキャストする。
他の機能もそうだがこういう余分な機能は必要になった時に使えばいいのであって必要なければ使わなくてもいいんだ。

>>813
タグとして使うならあるいわ・・・

if( dynamic_cast< Attribute< true, true, true >& >( object ) )
{
　return object.Something();
}
else
{
　return object.Example();
}

参照じゃぬるぽ来ないぞ

そういやそうだった

デバッグ時には結構使うけど

ばぁぶー！

if( dynamic_cast< std::tuple< Can, You, Speek, English >* >( bob ) )
{
　　std::puts( "No. So I'm japanese." )
}

キャストを多用する奴はキャス

opneMPって.net3.5以降入ってないように思えるけど
消滅しないよね？

釣りか

質問させてください。
比較演算子を仮想関数にしたいのですが、下のように書いても、引数の型が違うため、動的結合になってくれません。
（下記プログラムでは派生クラスが一つしかありませんが、実際には多数あります。）

仕方ないので、基本クラスのoperator==だけを定義し、そこで実行時の型を判定して型に応じた処理をさせているのですが、
これだとオブジェクト指向の意味が半減するような・・・。こういう場合、どう書くのが一般的なのでしょうか？

class Base
{
public: virtual bool operator==(const Base& obj) const
{
cout << "基本クラスの処理\n";
return true;
}
};

class Delived : public Base
{
public: virtual bool operator==(const Delived& obj) const
{
cout << "派生クラスの処理\n";
return Base::operator==(obj);
}
};

int main()
{
Delived d1, d2;
Base *pB1 = &d1, *pB2 = &d2;
if(*pB1 == *pB2) { } // Baseクラスしか呼ばれない
return 0;
}

自己レスです。

改めてプログラムを眺めていて気付いたのですが、派生クラスの演算子を

virtual bool operator==(const Delived& obj) const
ではなく
virtual bool operator==(const Base& obj) const
とすればうまくいきそうです。（試してみたところ、うまく動いています。）

派生クラスの演算子なのに基本クラスの参照で引数を受け取るのは何だか変な気持ちですが。。。

もし考え違いをしているようでしたらご指摘くださればありがたいです。

http://codepad.org/X49BBIRw
どうしても==で派生まで比較したいならこんな感じかねぇ
でもvirtualで実装した演算子は混乱を招くから一部の便利なパターンを除いてお勧めしないよ

自分が作るなら
operator == はvirtualにしないでスライシング＆等価判定にして
派生まで含めた完全な等価判定はvirtual Equalsを直接呼び出す風に書くけど

>>831
貼っていただいたソース拝見しました。確かにこれなら派生分を含めて判定可能ですね。
わざわざ完全なソースまで作っていただき、ありがとうございます！

ところで、「一部の便利なパターン」とは、どんなパターンなのでしょうか？
もしよろしければ、後学のために教えていただけると嬉しいです。

>830
ﾌﾟｰｸｽｸｽｸｽそれは当たり前であって、
同一シグネチャのメソッドの振る舞いがオブジェクトによって変わるというのが多態性だというのに、
シグネチャ自体を最初からBaseとDelivedで相違させて多態とかYOUは何をしたかったのか

また、>830の処置で一見多態を実現できたとしても、Delived::operator==(const Base& obj)の中で
objが本当はどのクラスなのか特定して適切な比較演算を行うという難事業が待っておる
>831の最後のようなやり方でも、Equals()がconst Base&を引数としてとる限りは同じ話
dynamic_castでも使わないことには解決しない

なにかってに話しかけ店の？

dynamic_cast を使えばいいってだけだね、くだらん
このケースでは dynamic_cast 相当の関数を自作だってできる（>>833 にはできなさそうに見えるが）

dynamic_castなんか必要ないが？

>>835
dynamic_cast相当の機能をプログラマが書いても良いが、
未来におけるDelivedの潜在的設計者全員にそれを強制する仕組みが別途要るわけだが
>835クンには設計センスがないね〜

一方ロシアはoperator==()を仮想関数などにせず、Equals()も設けず、dynamic_castも使わずに解決した

流れ追ってるか？

ぷーくすくす配達クラスで何がしたいの？
必要に応じてってだけで強制することには全然ならないんだが =0; はともかく

>>839
=0;は実体化できないのだからdynamic_castのしくみで比較できなくとも実害ｱﾘﾏｾﾝﾈｰ
それはともかく、わざわざ藻前は仮想関数テーブルのアドレスをプログラマに算出させるのか
それとももっと原始的な方法をとって、Delivedが追加される度にクラス識別コード一覧の定義ファイルをメンテナンスせねばならないつくりにしたいのか

あほ =0; は実体化できるよ

>>841
kwsk

vtable の実装には全然関係ないし
識別コードって GUID のことか？　これまた全然いらないし

ダブルディスパッチする手もあるが

どうやらぷーくすくす君は仮想関数をやめてif文の羅列にしたいらしい

シリアライズしてバイナリ比較
ハイおしまい

>>843
dynamic_cast相当の機能は少なくとも型の互換性情報をオブジェクト内に埋め込まねば始まらない
C++のdynamic_castは、仮想関数を1つ以上持つオブジェクトに必ず埋め込まれている
仮想関数テーブル（vtable）のアドレスをそれに利用している

>識別コードって GUID のことか？　これまた全然いらないし
上記のように互換性情報の埋め込みが全くいらないというdynamic_castはありえない
識別コード不要のテクニックとして、構造体の先頭に構造体サイズを持たせ、その大小で、
キャスト可能か否か判定する方法が存在はするが、既存フィールドの順序を厳格に保たねばならないなど、
コンパイラが責任をもてない規則が増える

>>845
>837の最後の1行が藻前にはそう見えるのかそうか…達者でな

>>831で解決してる問題をわざわざ引き延ばすな
炎上質問法はもう流行らないから

>>846
生成時の（ていうか、一般にvtableへのポインタとかあるので生成直前の、が正しい）領域全体のゼロクリアをお忘れなく

vtable の実装がどーとか言うまえに
まず virtual の外から見た使い方くらい押さえろよ
この流れはそれだけで充分だぞ

>>846
単にdynamic_cast使ったほうが早くね？
インライン化されて条件が消え失せてくれることもあるし

bool Delived::operator == ( const Base &base )
{
　if( !dynamic_cast< Delived* >( &base ) ) return false;
// 他
}

>>851
ここではoperator == ( const Base &base )がvirtualなので、
operator==()に与えられる引数の型（真 or Delivedのどれか）を
コンパイル時に真に一意に決定できる場合にしかインライン化されない

当然そのときはdynamic_castも最適化で除去されるわけで、
dynamic_castを使ったら速くなる、というのは偽のような気がするが

>>852

bool Compare( const Base &left, const Base &right )
{
　　return left == right;
}

if( !Compare( Delived(), Base() ) )
{
　　std::puts( "Not equal" );
}

MSのコンパイラーならこういうコードはインライン化されて
最終的にstd::putsだけになる。インライン展開される機会って
そんなに少なくないから十分じゃないか？

template <class D> struct TypeInfo {
static void * GetTypeID(void) { static int i ; return &i ; }
};

struct Base {
virtual void * GetTypeID(void) const = 0 ;
virtual bool operator == (Base const & obj) const = 0 ;
} ;

struct Derived1 : Base {
/* override */ void * GetTypeID(void) const { return TypeInfo<Derived1>::GetTypeID() ; }
/* override */ bool operator == (Base const & obj) const {
if(this == &obj) return true ;
if(TypeInfo<Derived1>::GetTypeID() != obj.GetTypeID()) return false;
return CompImpl(static_cast<Derived1 const &>(obj)) ;
}
bool CompImpl(Derived1 const & obj) const;
}

これがほぼ最強やな

struct Derived1 : Base {
/* override */ void * GetTypeID(void) const { return TypeInfo<Derived1>::GetTypeID() ; }
/* override */ bool operator == (Base const & obj) const { return TypeInfo<Derived1>::GetTypeID() == obj.GetTypeID() && *this == static_cast<Derived1 const &>(obj) ; }
bool operator == (Derived1 const & obj) const { return this == &obj || /* ry */ ; }
};

いやこうだな

実測してみたら？多分dynamic_castの方が速いか同じ速度だよ

>>856
それ以前にdynamic_castじゃ簡潔に書けないよ
ためしに一回書いてみ？
typeid（組み込みか自作か）の比較が必要になってくるから

だよな
最初にdynamic_castとか言い始めたアホは誰だよ

わたしです

>>857
どういう事？派生と一致するとマズイって事かい？

dynamic派はちょっとコードさらして
普段実行時型なんて使わんからホントにできんのかちょっとこんがらがってきた

>>829 以降、基底・派生が混在した等値比較をどう意味づけるのか、はっきり読み取れないんだが
みんな同意のうえで話してるの？

等値の条件に型の一致を必要とするなら typeid の比較が当然なんだろうけどさ、片方が一方の
派生である場合に基底部分だけの一致で等値とみなすことも考えられるよね？ dynamic_cast を
使うって言う人はたぶん後者で考えてるよね？

質問者です。たくさんのレスありがとうございます。

>>833
キャストが必要であるにしても、最初に自分が採っていたやりかた（基本クラスですべての処理をする）に比べると随分すっきりする
ので、よしとします。

>>839
基地がたくさんあって、配達をされた内容によって基地ごとに処理をわけたかったんですwww
非常にお恥ずかしい。

>>862
皆さんほどC++に詳しくないので、あまり議論についていけてないのですが。。。

基本クラスは抽象クラスで、基本クラスの実体を生成することはありません。
また、実際の運用上、配達…じゃなかった、派生クラスAのオブジェクトと派生クラスBのオブジェクトを比較するといったような、
異なる派生クラスどうしを比較することもありません。

よって、たとえば>>830の方法で処理する場合、派生クラスの比較処理は、自分の型に強制的にキャストして比較してやればうまくいきます。
念のために、別の派生クラスのオブジェクトが渡された場合にエラーとなるよう、何らかの処理は入れるつもりですが。

>>862
>派生である場合に基底部分だけの一致で等値とみなすことも考えられるよね？ dynamic_cast を
>使うって言う人はたぶん後者で考えてるよね？
別に。つかむしろ話は反対で、operator==()を仮想関数とするという残念な基本構想のため、
dynamic_castでも使わねば
　virtual bool Delived::operator==(const Base& obj)
というシグネチャに従い、Delivedクラスである*thisと、Baseクラスにアップキャストされたobjの比較しかできませんよ、みたいなノリ

あ、いや、考え違いをしていました。
異なる派生クラスどうしでの比較は起こりえますです。

いずれにせよ、派生クラスの比較演算子の中で、異なる型が来た場合は同値でないと判断させればいいですね。

その方法がdynamic_castなのか別の方法なのかは、今回の質問の意図からは外れますので、あまり気にしません。

> operator==()を仮想関数とするという残念な基本構想のため

残念なのでしょうか？ 本来はどうすべきなのでしょうか？

ちなみに今回やりたいことは、以下のようなことです。

作成したいのは、一種のドローソフトのようなものです。ワードの図形描画機能とかIllustratorに近いものを想像してください。
図形にはいろいろ種類があります。たとえば直線や円や四角のような（実際にはちょっと違うのですが、まあ似たようなものです）。
「図形」クラスが基本クラスで、「直線」等が派生クラスです。

ユーザーは、キャンバス内に複数の図形を描画できます。
プログラムでは、それらは図形クラスのポインタを集めたコンテナ（ただの配列ですが）で保持しています。

ユーザーが描画処理を開始する前にバックアップとしてコンテナのコピー（深いコピー）を作成しておき、編集完了操作後に、バック
アップしたコンテナと編集されたコンテナとで比較を行って、変更されていた場合は「変更されているが保存するか？」という確認を
表示します。

コンテナの比較は、保持している図形の個数が等しいかどうかをまず判定し、等しい場合は、その中に保持されている個々の図形の
比較演算子を順次呼び出すことで比較をおこないます。
コンテナが保持しているのは基本クラスであるところの「図形」クラスのポインタなので、if(*pBase1 == *pBase2) のような比較が
発生します。

このような内容なのですが、operator==()を仮想関数にしないとすれば、どうするのが適切なのでしょうか？

初心者的な内容だと思いますが、良い方法があればご教示くださいませ。

>>865
違う型は等値でないとしていいならtypeidの比較でFAだな。
dynamic_castだと指定の型とその派生型を区別しないから不適。

>>866
各クラスの operator == は普通に同じ型の引数を取るものを定義。
で、 virtual bool Equals() const = 0 は各クラスで typeid を確認した後に *this == ...
とすれば自然な気がする。

この実装部は型が違うだけになるんで、基底クラスにテンプレートで置いとけば少し楽が
できるだろう。派生クラスを定義するのが限られた範囲なら、宣言まで含めてマクロにしても
いいかもしれない。

>>857
if( typeid( *this ) != typeid( base ) ) return false;
で良いわけか。これなら孫クラスからDelived::operator==( base )呼び出しても使えるな。

あとtypeidって結局v_tableに展開されるんだよな。いちいちID持つより速いだろうね。
if( *this->v_table != base.v_table ) return false;

とっくに答えでてる話を延々といつまでやってんだよwww

>>868
なんでわざわざEqualsとoperator==で二重定義するのか判らん

>>871
中身が違うからだよ

詳しく

>>868は、C#のbool Equals(object obj)のガイドラインを地で行くやり方だな
Equals()の引数が空なの書き損じミスらしいがｗ

>>871
非virtualなbool Delived::operator==(const Delived& obj);を書けば、そちらはtypeidの比較が明白に不要で
かつvtableが介在しない分、コンパイラがちょっとがんばるだけでインライン展開も思いのまま
円と円とか、四角と四角、を比較する場合は a == bと書いて最適なコードが生成される
どれかの図形とどれかの図形の比較のときは、プログラマにEquals()を呼んでもらう、みたいなノリ
（C#のガイドラインではoperator==()から結局Equals()を呼んでるが、これはおそらくJITだからあまり効率に響かないのであろう

>>870
同意見

「残念な基本構想」を強いて挙げるなら operator == がメンバという点くらいだが
これだけ延々と話すほどの情報量はない

画像処理で画像の横方向foreachと縦方向foreachの2重ループ書くことが頻繁にあるんだけど
こういう2重ループをまとめたライブラリーみたいなの、ないのでしょうか

>>876
関数にまとめればおしまいだろうしアプリごとの都合がいろいろ入りそうだし、ないんじゃないかな。

>>875
>866はぎりぎりセーフだが、typeidの一致確認後、Delivedとしての内容の一致比較まで踏み込む場合は>868でFA
つまり、Baseや派生クラスとの比較を担保するvirtualなEquals()と、同一のDelived同士の比較のみ担保する非virtualなoperator==()の構成で正しい
さもないと、Baseおよびその派生クラス全てからfriendされ、巨大なif文とともに全てのDelived同士の比較ロジックを内臓する
巨大なoperator==(const Base& a, const Base& b)を書く羽目になる
長くなってｻｰｾﾝ；

>>874
普通仮想関数でも引数の型が決まってりゃインライン展開されるよね。
>>853 みたいな話で。
そのへんどう考慮してんの？

>>876
もし「画像」の二重ループのさせ方が表記上一定の構文で良く、
それに対して呼び出すべき処理も表記上一定の構文で良くて記号のみ変わるようなら
テンプレートでFA、なのでは

二重ループ処理を関数にまとめる、でも良いが、そうすると呼び出すべき処理を関数ポインタで渡さねばならず、
実行速度上多少不利かもしれない
（すくなくともインライン展開の出る幕は完全に無くなってしまう

friend っておまえ・・・　（図工

>>878
>つまり、Baseや派生クラスとの比較を担保するvirtualなEquals()と、同一のDelived同士の比較のみ担保する非virtualなoperator==()の構成で正しい

逆の関係のほうが良くね？operator==使うときの用途は完全一致しか無いんだから
部分一致の判定だけ別関数にしといた方がいいよ。
大体根底クラスの部分一致ならスライシングさせてもできるし。

障子をきれいに貼るにはどうしたらいいんですか？

>>880
関数ポインタ？あんたC++標準アルゴリズム知らんの？

>>878
> さもないと、Baseおよびその派生クラス全てからfriendされ、巨大なif文とともに全てのDelived同士の比較ロジックを内臓する
> 巨大なoperator==(const Base& a, const Base& b)を書く羽目になる

巨大なif文にしたくないからこそ、virtualにしようとしているのですが。。。

派生クラスでoperator==をvirtualにして、
bool DerivedX::operator==(const Base &obj)
{
if(typeid(*this) != typeid(obj))
return false;
DerivedXクラスの内容比較
}
とすれば、巨大なifを作る必要はないと思いますが、間違ってますでしょうか？

>>882
>>878は部分一致で判定をしようとしているのではなく、単に引数の型が同一派生クラスどうしか否かによって、関数をわけようと
言っているのだと思いますが。

まあ好みの問題かもしれないことはお断りしておくが、
>>879
コンパイラに仕事しなくていいと伝えられる場合は伝えたほうが良い希ｶﾞｽ

>>882
一般に、Delived::operator==()にDelived以外のクラスとの比較機能も持たせると、
当てはまるクラスが追加される度に、我々が==演算子というものに対して期待する性質
（常等性（a==a）や交換則（a==bならb==a）や結合則（a==bかつb==cならa==c）といったもの）
が損なわれていないか、気にかけ続ける必要が生じてしまう
Equals()にはそこまで強い期待は世間的に無く、"Equals()"というシグネチャに出くわしたプログラマは
やや注意深く仕様書を読むであろうから、多少異常な等値演算の機能を持たせても問題が少ない

>>876
フィルターを書けるとか塗りつぶしたいとか具体的に何がしたいの?
用途によっちゃboost::gilで済むだろうよ
元々Adobeが使ってた画像処理用高機能ライブラリだ

>>885
そりゃ分かってるよ。ただ言語的に不自然という話。
部分一致の方法は言語的に元々用意されてて自分のコードだけ
特殊な事をすれば他のライブラリーと協調性が無くなるんだよ。

○言語的に用意されてる方法

// 完全一致
delived == baseB;

// 部分一致1
baseA = delived;
baseA == baseB;

// 部分一致2
Base &baseA = delived;
baseA.Base::operator==( delived );

最後間違えた・・・

// 部分一致2
Base &baseA = delived;
baseA.Base::operator==( baseB );

>>885
>878は、>875（「operator == がメンバ」である点が残念）に対するレス
非メンバの大域関数としてbool operator==(const Base&, const Base&)を設け、
かつDelivedやBaseにおいて、operator==()またはそれと同様な機能のメンバを公開しなかった場合、
大域関数の中身が酷い事になりますよ、みたいなノリ

仮想関数が全く要らないという本日正午ごろの発言は撤回すますごめん；

>>884
正直知らんが、>887は、イテレータを作れと言うのでもなく、二重ループを行う関数を作れと明白に言っているので
>880はそれほど間違った指摘ではないつもり

アンカーミスった、orz
×: >887
○: >877

>>890
処理を渡すためには関数ポインタが必要になる、というのは明らかに間違い。
標準アルゴリズムのように関数オブジェクト使えばインライン展開も可能。

関数ポインターがインライン展開されないってのも間違いだけどぬ
テンプレートの引数に渡した場合はインライン展開の対象になる
厳密にはインライン展開できる関数の引数に渡した場合はインライン展開できる

s/Delived/Derived/g

openMPが消滅したとして
何が並列化の標準になるの？
>>827
> 827 名前：デフォルトの名無しさん [sage]： 2012/08/19(日) 08:55:26.16
> opneMPって.net3.5以降入ってないように思えるけど
> 消滅しないよね？

>>887
gil何かが物足りないから
いつもOpenCVだ
c++と画像処理は相性良くないのかもしれない

256諧調ですむならいいけどねぇ。

足りないときは16bitにすればよくね？

1色素をdoubleにして1画素256bitか
1色素をfloatにして1画素128bitにしとくといい感じ

まぁ、1色素intにして少数位置ずらしたほうが速度出るけど

色素に浮動小数点数使っても指数部ビットが無駄になる気がするけど・・・

http://unkode-mania.net/lang/CPP

きっと0.0001Luxから1000万Luxまで扱うHDRなんだろう

すいません。初めて投稿するのですが、巡回セールスマン問題の完全列挙法を再起呼び出しでやれ
という課題がゼミで出ているのですが、全然分かりません。ネットで結構調べたのですがダメだったので、
どなたか教えてくれる方ございましたら、お願いいたします。

>>902
自然光計算したら28bitなんて直ぐ潰れるもんな

>>903
まず再起呼び出しはわかるのか？

>>903
「巡回セールスマン問題」と「完全列挙法」と「再起呼び出し」をそれぞれググって
何が分からないのか書いてみたら？

宿題は宿題スレでやるべきじゃね？

「分かりません」と書いて提出しろ。

>>907
>>903がヒントでなく答えそのものを求めてるならそうだな

>>903
字面的に「全ルートを列挙して解け」ってことだろ……
列挙するのに再帰使えってこと

>>910
そのとおりです。意味は分かったんですけど、プログラムが書けないんです･･･

先生にわかりませんって言って教えてもらえ

　　　　　　　　　　　　　　　　　　）
　　　　　　　　　　　　　（
　　　 　　　　　,,　　　　　　　　）　　　　　　）
　　　　 　　　　ﾞﾐ;;;;;,_　　　　　　　　　　　（
　　　　 　　　　　ミ;;;;;;;;､;:..,,.,,,,,
　　　　　　　　　　i;i;i;i; '',',;^′..ヽ
　　　　　　　　　　ﾞゞy､､;:..､）　　｝
　　　　　　　　　　　.¨.､,_,,､_,,r_,ノ′
　　　　 　　　　/;:;":;.:;";i; '',',;;;_~;;;′.ヽ
　　　　　　　　ﾞ{y､､;:...:,:.:.､;:..:,:.:.　._　　､｝
　　　　　　　　".¨ｰ=v ''‐ .:v､,,､_,r_,ノ′
　　　　　　　/;i;i; '',',;;;_~⌒¨;;;;;;;;ヾ.ﾐﾞ´ﾞ^′..ヽ
　　　　　　 ﾞ{y､､;:...:,:.:.､;:..:,:.:.　._　　.､）　　､｝
　　　　　　　".¨ｰ=v ''‐ .:v､冫_._ .､,_,,､_,,r_,ノ′
　　　　　　/i;i; '',',;;;_~υ⌒¨;;;;;;;;ヾ.ﾐﾞ´ﾞ^′.ｿ.ヽ
　　　　　　ﾞ{y､､;:..ゞ.:,:.:.､;:.ﾐ.:,:.:.　._υﾟo,,'.､）　　､｝
　　　　　　ヾ,,..;::;;;::,;,::;):;:;:; .:v､冫_._ .､,_,,､_,,r_,ノ′

>>911
1. 再帰自体ワカラン
2. 再帰で探索する方法がワカラン
3. 「枝刈り」がワカラン
4. 巡回セールスマン問題を解く方法が想像できない
どの番号？

>>914
2番です^^巡回セールスマン問題を解くためのアルゴリズムは理解できているとおもいます。
再起でプログラムを組む方法が馬鹿なので想像できないのです；；

>>915
多分どちらかと言えば「深さ優先探索」を使うんだろうね
「深さ優先探索 再帰」とかのワードでググってみたら？

void　SAIKI(コンテナ)
{
while(1)
{
行き先を探す
見つかった　コンテナに行き先を入れる　SAIKI(コンテナ)
見つからなかった　break;
}
}
こんなんじゃねーの

>>916
ありがとうございました。違いました（＞＜)
質問が下手すぎました。すんません。
巡回セールスマン問題の厳密解を総当り法で求めるプログラムを再起呼び出し
を用いて作成せよ。っていう問題なんですが、宿題なので宿題板で質問した方が
よろしいでしょうか？お手数おかけして申し訳ございません。

>>903
> ネットで結構調べたのですがダメだったので

もしかして、「再帰」じゃなくて「再起」で調べたから見つからなかったというオチじゃないよな。

>>918
>違いました（＞＜)
とりあえずC++だの言う以前に頑張って学ぼうぜ
頑張ろうぜ

>>918
　　B
A＜|＞D
　　C
※A-B, A-C, B-C, B-D, C-Dの連結

のような道があったとして
まずA, B, C, Dから探索開始、Aからとして
　「Aから(B,C)を探索」出来る、でBについて
　　「Bから(C,D)、既に通ったAは除外して探索」出来る、Cについて
　　　「Cから(D)、既に通ったA,Bは除外して探索」出来る

Ａ┬Ｂ┬Ｃ─Ｄ
　│　└Ｄ─Ｃ
　└Ｃ┬

そうやって再帰的に探索する
探索結果のうち距離が最小になるものを返せばいい

まずCの上にLispを作ります
ambで巡回する都市を列挙します
3行ぐらいで解けます

Aに帰らないとダメっぽいけどまぁそれぐらい追加できるか

行列で解くとはやいよ

sealedってできないん？継承禁止的なあれ

C++11で struct A final{}; というように継承禁止出来るようになるので
お使いのコンパイラが対応するまで長らくお待ち下さい。

class Sealed {
Sealed() {}
Sealed(Sealed const & obj) {}
public:
static Sealed * New() { return new Sealed(); }
};

すいません自己解決しました

>>918
ありがとうございます。なんとかなりそうです＾＾
みなさんいろいろありがとうございました。

失せろゴミ

>>927
static Sealed Create() { return Sealed(); } も欲しいが
コピコンが空だと困るな

それじゃ継承できちゃう

= default があれば・・・と言いたい所だが
それがあるなら final があるというジレンマ

継承とテンプレート、データ構造ぐらいしか知らない
次何やろか

C#やればいいよ