トップページ⇒tech
988コメント299KB

Boostを語れゴラァ part5

■ このスレッドは過去ログ倉庫に格納されています
0001BOOTS2007/10/18(木) 08:09:35
語って.はぁと part boost::mpl::int_<5>

過去スレ
part 4 http://pc11.2ch.net/test/read.cgi/tech/1175663346/
part 3 http://pc11.2ch.net/test/read.cgi/tech/1158991211/
part 2 http://pc8.2ch.net/test/read.cgi/tech/1139313234/
part 1 http://pc8.2ch.net/test/read.cgi/tech/1091198276/

■関連サイト■
Boost C++ Libraries
http://www.boost.org/

Boost 翻訳プロジェクト
http://boost.cppll.jp/HEAD/

Let's Boost
http://www.kmonos.net/alang/boost/

boost info
http://shinh.skr.jp/boost/
0263デフォルトの名無しさん2007/12/29(土) 14:07:18
>>262
何いちいち反応しているの？
興味がないなら無視すればいいだけだろ

#include <boost/current_function.hpp>
により Visual C++ では
#define BOOST_CURRENT_FUNCTION __FUNCSIG__
にされてしまうのはなぜ？
Visual C++ なら __FUNCTION__ があるので
#define BOOST_CURRENT_FUNCTION __FUNCTION__
にならないといけないはずなのに
0264デフォルトの名無しさん2007/12/29(土) 14:39:12
>>263
いやいや興味はあるよ。
“自意識過剰なのか”という点についてね。
0265デフォルトの名無しさん2007/12/29(土) 15:22:05
void foo(){}
void bar(){}
boost::function<void(void)> f1 = foo;
boost::function<void(void)> f2 = bar;
assert(!(f1 == f2))

なぜこの比較が通らないんでしょうか？
assert(f1 == foo) なら通るんですが・・
boost::function のインスタンス同士の
比較はできないのでしょうか？
単純に関数ポインタの比較のようなことをしてくれればいいのですが．
02662652007/12/29(土) 15:52:01
Frequently Asked Questions
Why can't I compare boost::function objects with operator== or operator!=?
http://www.boost.org/doc/html/function/faq.html#id1215129

そのまんまのことが書いてありました．
死ね，俺．
没年2007．
0267デフォルトの名無しさん2007/12/29(土) 16:01:08
>>264
スレ違い
0268デフォルトの名無しさん2007/12/31(月) 12:16:54
gcc4.1だと1.34.1よりsvn headの方が不具合が少ないような気がするんですが
気のせいですよね？
0269デフォルトの名無しさん2007/12/31(月) 15:38:12
1.34.1後にバグが修正されてるのだっていっぱいあるんだろうから
不思議ではないだろ
0270デフォルトの名無しさん2007/12/31(月) 23:49:00
Boost ではデバッグバージョンのライブラリと通常バージョンの
ライブラリが用意されていますよね、普通。たとえば bjam
でビルドすると両方のライブラリが作られるし、
Debian GNU/Linux や Ubuntu で boost-dbg を入れると
デバッグ用のライブラリが /usr/lib 以下に入り、
通常バージョンのライブラリと同居します。

で、ふと思ったのですが、Linux の一般的なディストリビューション
(RHEL や Debian) で libhoge, libhoge-dev を入れると
/usr/lib 以下に入る libhoge.a や libhoge.so は一種類だけで
特にデバッグバージョンと通常バージョンという区別はありません。
Linux のディストリビューションではパッケージングの際に
デバッグ情報をつけるか否か、デバッガで扱えるように
最適化をオフにするか否か、などについて取り決めがあるのでしょうか？
0271デフォルトの名無しさん2008/01/02(水) 12:19:06
1.35 って asio まわりの頻繁なコミットが終わったら
リリースされるのかな？
0272デフォルトの名無しさん2008/01/02(水) 16:28:40
GILがまともに使えるようになってからにしてほしいな。
jpegとpngの読み込みを正式にコミットして、
pngも通過色とかまともに対応して、
スケーリングなども用意して。
0273デフォルトの名無しさん2008/01/02(水) 16:29:41
GILとは？generic imaging libraryかなんか？
0274デフォルトの名無しさん2008/01/03(木) 02:20:39
VC++8.0とboost1.34.1を使って開発しています。

struct my_device
{
typedef char char_type;
typedef bidirectional_device_tag category;

streamsize read(char_type *s, streamsize n);
streamsize write(const char_type *s, streamsize n);
};

int main()
{
my_device device;
stream<my_device> s(device);
char one = 'b', two = 0;

s.put(one);
s.get(two);
}

my_device::write
my_device::read
の順番で呼ばれると思ったのですが、なぜかmy_device::readのほうしか呼ばれません。
なぜこのようになるのかご存じの方がいらっしゃいましたら教えてください。
0275デフォルトの名無しさん2008/01/03(木) 07:35:44
Boost Graph Library (BGL) 使っている人いますか？
BGL ではグラフの頂点や辺にプロパティを設定して
値を持たせることができますが（たとえば「色」とか），
ある値をプロパティとして持つ頂点や辺を高速に
列挙させることはできるのでしょうか？

頂点イテレータなどで全探索して列挙するのはつらいので，
プロパティマップを boost::multi_map::multi_map_container
などをつかってキーでも値でもインデックスされているような
コンテナでプロパティを保持できればと思っているのですが．

外部プロパティとして持てばよいのではないかとも思うのですが，
たとえば boost::print_graph は vertex_index_t を内部プロパティ
として持っていることを前提に作られているので，
内部プロパティの持ち方を指定してうまくやれればいいと思っています．
0276デフォルトの名無しさん2008/01/03(木) 08:51:59
こういうものを作ったんですけど、もしかして似たようなものがboostにありますか？
もしあるのだったらboostの方を使いたいです。

int var;
//キャストが必要な長い式
var = (int)(0.123456789 * 9.87654321 / 0.123456789);

//「キャストをする」と表明するだけで
//具体的な型や乱雑な括弧が必要ない
var | mycast = 0.123456789 * 9.87654321 / 0.123456789;
0277デフォルトの名無しさん2008/01/03(木) 09:00:12
仕様の詳細（初期化のみ？コピー等の動作は？）がよくわからんが、BOOST_AUTOみたいなもんかね。
0278デフォルトの名無しさん2008/01/03(木) 09:16:53
仕様というか、単に=よりも結合順位の高い演算子で左辺の参照を受け取って
operator =で右辺を代入してるだけ。
0279デフォルトの名無しさん2008/01/03(木) 09:19:18
どういうときに使うの？
0280デフォルトの名無しさん2008/01/03(木) 09:28:45
「キャストをする」と表明するしたいだけで具体的な型や乱雑な括弧を書きたくない時。
0281デフォルトの名無しさん2008/01/03(木) 09:35:05
BOOST_AUTOって変数になるトークンと初期化式を書いて
初期化式の型から変数の型を判断するやつだね。
俺が書いたのは単に代入用だけだよ。
0282デフォルトの名無しさん2008/01/03(木) 09:36:58
template<typename T>
class auto_cast_wrarapper {
    T& obj_;
public:
    auto_cast_wrarapper(T& obj)
        : obj_(obj)
    {}
    template<typename U>
    T& operator=(U const& obj) {
        return obj_ = static_cast<T>(obj);
    }
};
class auto_cast {};
template<typename T>
auto_cast_wrarapper<T> operator|(T const& lhs, auto_cast rhs) {
    return auto_cast_wrarapper<T>(lhs);
}
static auto_cast mycast;

こんな感じかな。まあboost::enable_ifとか使ってもうちょっと上手く実装してるとは思うけど。
とりあえずboostに同様のものは無かったと思われ。
02832822008/01/03(木) 09:39:57
wrarapperってなんだorz
wrapperね。
0284デフォルトの名無しさん2008/01/03(木) 10:17:30
乱雑な括弧もなにも、右辺全体を一組の括弧で括るだけじゃないか。
0285デフォルトの名無しさん2008/01/03(木) 10:23:04
まあ、Cのキャストを使ってる時点でなんだかなぁ、と思う。
varがint形とdouble形のコンストラクタと代入演算子を持っていて、
それぞれ意味が違う場合はどうするの？
0286デフォルトの名無しさん2008/01/03(木) 14:48:38
組み込み方にしか適応できない様にする。
0287デフォルトの名無しさん2008/01/03(木) 18:11:52
>274
単にバッファリングされてるだけなんじゃないの？
>Note that the Iostreams library provides buffering by default. Consequently, the stream out must be flushed before
>the characters written are guaranteed to be reflected in the underlying string.

>http://www.boost.org/libs/iostreams/doc/tutorial/container_sink.html

>275
「BGLでは」ではなくて、むしろ「adjacency_list と adjacency_map では」が正しいんじゃないの？
内部プロパティに対するアクセス方法としては、PropertyGraph か MutablePropertyGraph に対応するものしか
用意されてないし、EdgeList とかの持ち方はカスタマイズできるけど内部プロパティの持ち方はカスタマイズできないと思う。
で、内部プロパティと外部プロパティを併用したら駄目なん？
あるいは、いっそのこと、自分で BGL の Concept に沿ったクラスを作っちゃえばいいんじゃないかな？
0288デフォルトの名無しさん2008/01/03(木) 18:39:49
274です。
writeの後にflushをしたら期待した動作になりました。
ありがとうございました。
0289デフォルトの名無しさん2008/01/03(木) 19:17:02
>>287
そうですね．外部プロパティとの併用にします．
BGL って Graphviz への出力もできるし，
その時の VertexPropertyWriter は
boost::bind や boost::lambda でファンクタ
自在に作れるし，便利ですね．
0290デフォルトの名無しさん2008/01/04(金) 01:55:41
string の vector の vector について、
各要素を std::cout に出力したいとき、
boost::bind でうまくファンクタかけないかな？
0291デフォルトの名無しさん2008/01/04(金) 10:42:43
3行目が全く意味不明
0292デフォルトの名無しさん2008/01/04(金) 10:47:30
>>291
std::vector<std::string> の参照を受け取ると
その内容を全部ずらずらと書き出すようなファンクタを
コードの途中で必要に応じて作り出せないだろうかということです。
0293デフォルトの名無しさん2008/01/04(金) 12:16:30
>>292
void operator()(const std::vector<std::string>& v)
{
　std::copy(v.begin(), v.end(), ostream_iterator<std::string>(cout, " "));
}
とかじゃだめなのか？何でboost::bindが必要なんだ？
0294デフォルトの名無しさん2008/01/04(金) 12:17:28
void operator()(const std::vector<std::string>& v) const
{
　std::copy(v.begin(), v.end(), ostream_iterator<std::string>(cout, " "));
}

constつけた。
0295デフォルトの名無しさん2008/01/07(月) 19:19:40
Boost.Statechartの事なんですが、ある状態がイベントを受け取った時、
その状態クラスのメンバ変数の値によって、次の状態に遷移するしないを分ける事はできますか？

http://www.kmonos.net/alang/boost/classes/statechart.html
ここのサンプルで例えれば、
「Locked状態はn回Coinイベントを受け取ったらUnlocked状態に遷移」という風にしたいです。
0296デフォルトの名無しさん2008/01/08(火) 14:27:54
http://d.hatena.ne.jp/niitsuma/20080108
boost.pythonをcmake（クロスプラットフォームmake）から使う方法まとめてみました
0297デフォルトの名無しさん2008/01/09(水) 20:03:20
某ソフトウェアをビルドしようとして
./configureやると
checking whether the Boost::DateTime library is available... yes
checking for main in -lboost_date_time... no
configure: error: Unable to find Boost.DateTime library, currently this is required.
って出て失敗するので，Boostライブラリを手動インストールしたのですが認識してくれません．

# ldconfig -v
で確かに
libboost_date_time-gcc41-mt-1_34_1.so.1.34.1 -> libboost_date_time-gcc41-mt.so
libboost_date_time-gcc41-1_34_1.so.1.34.1 -> libboost_date_time-gcc41.so
と追加されているはずなのですが，configureｇが認識していないようです．
これどうやったら直りますか？

ちなみにyumで自動インストールするといけるのですが，自分はboost::filesystemとか使いたいので
bjamつかって自前でビルドしてインストールしました．
02982972008/01/09(水) 20:04:41
すみません環境を書き忘れました．
Fedora Core 6でカーネルのバージョンが2.6.18-1.2798.fc6です

宜しくお願いいたします．
0299デフォルトの名無しさん2008/01/09(水) 20:07:30
/etc/ld.so.conf.d/
に
boost.conf
とかいう名前のファイル作ってboostインストールしたパスを書く
/usr/local/boost/lib
とか
それから
#ldconfig
0300デフォルトの名無しさん2008/01/09(水) 20:07:57
develパッケージをインスコしてないだけじゃねーの
0301デフォルトの名無しさん2008/01/09(水) 20:22:26
>>299
やってみましたが駄目でした．
ldconfig -v
/usr/local/lib:
(途中省略）
libboost_date_time-gcc41-mt-1_34_1.so.1.34.1 -> libboost_date_time-gcc41-mt.so
libboost_date_time-gcc41-1_34_1.so.1.34.1 -> libboost_date_time-gcc41.so
となっているので，ライブラリ自体は認識していると思います．

今気づいたのですが
checking whether the Boost::DateTime library is available... yes
ということはライブラリ自体は認識しているようですね...

checking for main in -lboost_date_time... no
と成っています-lboost_date_timeがおかしいということでしょうか...

>>300
yum install boostってやるときちんと./configureできてビルドできるのですが，今回は
boost::filesystemとか使いたいのでbjamつかって自前でビルドしてインストールしました．
0302デフォルトの名無しさん2008/01/09(水) 20:47:12
http://osdir.com/ml/network.bit-torrent.libtorrent/2006-10/msg00003.html
エラーメッセージでググると確かにdevel 入れろってアドバイスされてるね

sudo apt-get install libboost-dev libboost-date-time-dev
libboost-filesystem-dev libboost-serialization-dev libboost-thread-dev
libboost-regex-dev libboost-program-options-dev

fedoraは apt-get を yum install にすればいいのかな
0303デフォルトの名無しさん2008/01/13(日) 14:52:55
boostって、どうしても使わないと駄目なのですか?
会社の先輩が boost、boost と boost 自慢して煩いのですが。
0304デフォルトの名無しさん2008/01/13(日) 15:08:39
最近のコンパイラのみ使うのであれば、
使わなきゃ損。
使えない奴は低能。
0305デフォルトの名無しさん2008/01/13(日) 15:15:24
boost無かったらC++使いたくない
0306デフォルトの名無しさん2008/01/13(日) 15:17:44
boost も使えなかったら一人前とは言えない。
0307デフォルトの名無しさん2008/01/13(日) 15:23:50
boostが無いC++なんかただの欠陥言語
0308デフォルトの名無しさん2008/01/13(日) 15:25:29
TR1でいいじゃん
0309デフォルトの名無しさん2008/01/13(日) 15:59:13
filesystemで相対パスを絶対パスに変換する方法があると
Lets boostで書いてあったのですが、具体的にどうやれば
良いのでしょうか？
0310デフォルトの名無しさん2008/01/13(日) 16:35:30
current_path()で得たもので./を置換したらどうだろうか？
0311デフォルトの名無しさん2008/01/13(日) 16:39:01
アクセスできるなら相対パスでも絶対パスでもいいと思うが。
絶対パスである必要はあるの？
0312デフォルトの名無しさん2008/01/13(日) 16:41:41
別のAPIの関数に渡すためとか
0313デフォルトの名無しさん2008/01/13(日) 16:45:07
>>310
Letsだと変換が用意されてるように書かれてましたが、
自前変換しかないんですかねぇ。
0314デフォルトの名無しさん2008/01/13(日) 16:48:12
仮に自前で処理するとなると、 ./ で始まってる場合、
../ の場合、何も付いてない場合、ドライブレターの場合(最初から絶対パス)、
さらに/が\な場合など、かなり面倒な・・・
0315デフォルトの名無しさん2008/01/13(日) 17:05:29
complete()
とか、
system_complete()
で簡単に変換できると思うが。
0316デフォルトの名無しさん2008/01/13(日) 17:16:18
soreda
0317デフォルトの名無しさん2008/01/13(日) 17:20:34
>>315
まさにsoreda！
感謝感謝
0318デフォルトの名無しさん2008/01/14(月) 00:43:06
>>303
だってC++の標準ライブラリが貧弱すぎて話にならないから。
簡単なところでは正規表現とかshared_ptrとか。
bindとmem_fnもC++標準のよりBoostのほうが使いやすい。
0319デフォルトの名無しさん2008/01/14(月) 01:25:06
>>318
どうでもよくね?
プログラム全体から見ると、Boostで楽になる部分なんて 1% 以下でしょ。
0320デフォルトの名無しさん2008/01/14(月) 01:28:18
使いにくかったら存在価値ないもんな
0321デフォルトの名無しさん2008/01/14(月) 01:28:25
shared_ptr で楽になる部分はもの凄く大きいぞw
0322デフォルトの名無しさん2008/01/14(月) 01:34:13
>>321
あれって、参照カウンタで管理してるんでしょ?
循環参照したらオワタになるので、素人に使わすと逆に危ないよ。

そもそも、new するシチュエーションってそうそうあるか?
なるべく new を避けて書くのが C++er の嗜みだとおもうが。
0323デフォルトの名無しさん2008/01/14(月) 01:35:58
new しないでまともにオブジェクト指向プログラミングできるかよ。
デザインパターンの半分は使えなくなるんじゃね。
0324デフォルトの名無しさん2008/01/14(月) 01:37:00
C++標準ライブラリが貧弱だとは思わないけど
もの足りないと思うひとがBoost使ってることが多いだろうね

数万行のコード書いたら1%ってめっちゃでかいと思うんだ
(実際は1%どころじゃないけど)
0325デフォルトの名無しさん2008/01/14(月) 01:40:10
循環参照が必要になる時点で大体設計おかしいんだけど、
まあ素人に使わせるとそうなることはあるかもしれんな。
0326デフォルトの名無しさん2008/01/14(月) 01:44:03
>>323
殆どのインスタンスは、自分の親クラスのメンバ変数として一緒に確保されるから、
大きな new delete が時たまあるだけってのが普通じゃない?
細かい単位で new delete 繰り返すなんてのは、C++ には似合わないと思うが。
そういうふうに書いてくれ、と頼まれたなら仕方ないが。
0327デフォルトの名無しさん2008/01/14(月) 01:50:13
Boostを使える（に理解のある）会社を紹介してください＞＜
0328デフォルトの名無しさん2008/01/14(月) 01:57:01
プログラミングで難しいのって、エラー時の例外処理だったり、パフォーマンスのチューニングだったり、
デバッグだったり、プロジェクトの管理だったりだよね。
Boostってあんまどうでもよくない ?
0329デフォルトの名無しさん2008/01/14(月) 01:59:20
>>322
weak_ptr
0330デフォルトの名無しさん2008/01/14(月) 02:02:09
>>328
よくない
プログラミングで難しいのには「大量のコードを書くこと」や「難しい処理を実装すること」
は当然あるだろ
だったらコード量が減って、難しい処理を(Boost使わないよりは)簡単に実装できるなら使ったほうがいいんじゃない
0331デフォルトの名無しさん2008/01/14(月) 02:09:09
>>330
>プログラミングで難しいのには「大量のコードを書くこと」や「難しい処理を実装すること」
>は当然あるだろ

えーーーー
無いなぁ。難しい処理ってのは、確かに難しいんだけど、
Boost 使ったぐらいでどうこうなるレベルの処理を、普通は難しいとは言わないよなぁ。

Boostって、「うっかりミスが防げるかもね！！」 レベルの話でしょ。
0332デフォルトの名無しさん2008/01/14(月) 02:16:40
Boostを使うと、面倒くさかったことが簡単にできることはよくある。
しかし、難しい処理の実装は、Boostを使ってもやっぱり難しいよ。
0333デフォルトの名無しさん2008/01/14(月) 02:28:31
Boostのメリットってなんだろうなと改めて考えちゃったが、
>>332が非常に簡潔な答えをくれた。

「面倒くさい」
0334デフォルトの名無しさん2008/01/14(月) 02:59:04
>>303
×どうしても使わないと駄目
○メリット大きい・デメリットやリスクが少ないなら使う
まあBoostに限らないけど。

使いこなせる人間がわずかしかいないプロジェクトに導入したりするのはまずいかと。
新しいものを覚えるコストはゼロじゃないよ。
(誰か1人が使うだけで話が完結するならいいかもしれんが)

まあ、各人がBoostを使えた方が開発効率がよいとは思う。
気長に導入しようって話ならいいんでは?
0335デフォルトの名無しさん2008/01/14(月) 03:31:24
boost使ったからって2倍も3倍も生産効率があがるわけじゃないしなぁ
0336デフォルトの名無しさん2008/01/14(月) 03:43:36
3倍効率が上がらないライブラリは導入しません。
0337デフォルトの名無しさん2008/01/14(月) 04:41:24
だいたい、ライブラリって何かに特化しているから丸投げで来て便利なわけだよな。
でも、Boostって何かに特化しているってわけでもないんだよな。
だから使ったところで丸投げできないし、結局あんまブーストしない。
0338デフォルトの名無しさん2008/01/14(月) 05:07:10
STLを使うのと同じ理由じゃいかんのかな。
0339デフォルトの名無しさん2008/01/14(月) 08:45:01
Boostはもう便利と言うより無いと不自然なライブラリになってる
効率上げると言うより無いと効率下がる
いまさらshared_ptrもfunctionもutilityもoperatorsもcstdintも無しで済ませるのは苦痛だ
0340デフォルトの名無しさん2008/01/14(月) 09:22:08
>>326
超頻出の Strategy パターンとか、大体 new が必要になるよね。
必要ない事もありはするけど。
shared_ptr や ptr_container があるだけで、メモリ管理がだいぶ楽になる。
0341デフォルトの名無しさん2008/01/14(月) 10:08:58
ptr_list に delete してほしくないポインタを渡すことはできますか？
0342デフォルトの名無しさん2008/01/14(月) 10:11:14
boostを使わないって？
使いこなせる人間がわずかしかいないって？（勉強はしないの？）
こういうことだから日本のIT産業は
0343デフォルトの名無しさん2008/01/14(月) 11:21:35
>>341
コンテナを渡すといいよ
0344デフォルトの名無しさん2008/01/14(月) 11:22:59
>勉強はしないの？

勉強する香具師は少数派
0345デフォルトの名無しさん2008/01/14(月) 11:22:59
>>341
ptr_container系はデストラクト時に必ず要素をdeleteする。
嫌ならデストラクト前にdeleteしてほしくないメンバをコンテナから削除しないと駄目。
0346デフォルトの名無しさん2008/01/14(月) 11:30:29
業務系はboostを勉強する暇があったら資格取れって話になるからな。
資格さえあれば仕事もついてくるって構図だから仕方ないけど。
0347デフォルトの名無しさん2008/01/14(月) 11:54:48
>>343>>345
大体分かりました。
その制限を踏まえて色々考えてみます。
0348デフォルトの名無しさん2008/01/14(月) 12:43:05
>>340
普通メンバ変数として確保しておいて、切り替え時にインターフェイス用のポインタを切り替えるだけだな。
いちいち new するとかタコすぎる
0349デフォルトの名無しさん2008/01/14(月) 12:46:16
まあ、そうやるときもあるけども、
new した方がいい時も多い。
0350デフォルトの名無しさん2008/01/14(月) 12:47:26
>>339
なんかさ、開発効率って、結局そういうところで決まらなくね?
むしろ、>>328 のようなことの方が影響大きいと思うのだが。
0351デフォルトの名無しさん2008/01/14(月) 12:49:46
だいたい、メモリ管理なんてそんなに面倒か?
メモリリークなんて、リソースリークも含めてここ数年出したことねぇなぁ。
設計がおかしいんじゃね?
0352デフォルトの名無しさん2008/01/14(月) 12:55:06
自分の世界しか見えてない人多すぎ
0353デフォルトの名無しさん2008/01/14(月) 13:39:37
面倒だからjava、C#はGCを実装したんだろ
0354デフォルトの名無しさん2008/01/14(月) 14:48:47
GCは便利だね。だけどあれはメモリコンパクションあってのものだと思うよ。
メモリコンパクション無しで、しかも参照カウンタで管理だなんて、存在価値なくね ?
0355デフォルトの名無しさん2008/01/14(月) 14:58:47
Boostを知らない者はC++を知らない (自明)
C++を知らない者はCを知らない　(templateはマクロでvirtualは関数ポインタだった)
Cを知らない者はプログラミングを知らない (自明)

対偶を取ろう
プログラミングを知る者はBoostを知っている
0356デフォルトの名無しさん2008/01/14(月) 15:05:47
ど頭から真理でないやんけ
0357デフォルトの名無しさん2008/01/14(月) 15:07:58
たしかに、templateはマクロで仮想関数は関数ポインタだが、
だからといって、どうして、「C++を知らない者はCを知らない」ということになるんだ?
普通逆だろ。
「C++のtemplateと仮想関数は、元々はCのマクロと関数ポインタであるので、
C++の元となったCを理解していないと、C++を理解したということにならない。」
となるのが普通だろ。

(自明)とか使ってる時点で釣りなんだろうが。

0358デフォルトの名無しさん2008/01/14(月) 15:15:50
>>355 乙
危うく納得するところだった。
こういう詭弁はなんと命名されているのだろうか？個別性質と集合抱合のすり替え？
0359デフォルトの名無しさん2008/01/14(月) 15:27:01
要はこういうこと。

偽： 「C があったから C++ が生まれた。」
真： 「C++ が生まれたのは、C があったから。」

C++の基礎としてCがあるのであって、Cの拡張としてC++があるというわけではない。
「Cの拡張としてC++がある」というのは一見正しそうだが、単なる結果論に過ぎない。
マンガの見すぎ、精神論、文系脳。
ただ単に、「C++の基礎としてCがある」という事実があるだけ。
これがロジカルな思考、現実、理系脳。
0360デフォルトの名無しさん2008/01/14(月) 16:38:26
>>359
論理学・集合論的に説明してくれないと.....。
0361デフォルトの名無しさん2008/01/14(月) 16:43:49
＞C++ が生まれたのは、C があったから。
表現を簡単にしすぎて誤解しやすい表現になってる気が。
0362デフォルトの名無しさん2008/01/14(月) 16:51:57
>>359
どう見ても「理系」の推論方法ではないな。そもそも「理系」という言葉を使う時点でアウトだ。
>>355 は一種のジョークだ。
■ このスレッドは過去ログ倉庫に格納されています