トップページ⇒tech
983コメント338KB

C++相談室 part58

■ このスレッドは過去ログ倉庫に格納されています
0001v(^・^)v2007/09/26(水) 03:41:13
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレに
お願いします。

テンプレその他 >>2-15 付近参照

前スレ（実質 part57）
C++相談室 part56
http://pc11.2ch.net/test/read.cgi/tech/1185377587/
0153デフォルトの名無しさん2007/10/04(木) 01:15:57
>>136
boostにはなんて名前で入ってたっけ
0154デフォルトの名無しさん2007/10/04(木) 01:18:23
>>152
pAはDerivA*と分かっているとき、
DerivA* pA2 = static_cast<DerivA*>(pA->NewInstance());
のようなキャストを型安全性を損なうことなく排除できる。
0155デフォルトの名無しさん2007/10/04(木) 02:07:15
dynamic_castすれば共変なしでも安全じゃね？
0156デフォルトの名無しさん2007/10/04(木) 02:08:25
http://videointroplayer.web.fc2.com/?ii9YN1kO-TK36%+WhqyiIrhz0F110%+Kjtps4byn7a119%+esA5NHPWRF1115%+026mGIi9Z4824%+@1@_KeyboardCrusher
0157デフォルトの名無しさん2007/10/04(木) 02:29:39
>153
BOOST_PP_STRINGIZE
0158デフォルトの名無しさん2007/10/04(木) 08:19:17
これじゃだめなん？

Base *pC = new DerivC;
0159デフォルトの名無しさん2007/10/04(木) 08:20:10
Base *pC = new DerivC(pA);
Base *pC = new DerivC(pB);
0160デフォルトの名無しさん2007/10/04(木) 21:28:42
>>155
それだと余計な負荷がかかる。
0161デフォルトの名無しさん2007/10/05(金) 01:29:04
俺的c++開発環境構築メモ

目的：最終的にlinuxで動かせるようにしないといけないけどVisual Studio捨てれない

winxpにvmwareいれてゲストＯＳとしてubuntu7を入れる
ubuntuの/home/srcをsambaで共有できるようにしてホストＯＳのwinxpからみれるようにする

/home/src　= \\ubuntu\src
の下にVisual Studioのプロジェクト作成

makefileはeclipse/CDTで自動生成

あとはemacsでメインのコードの編集するけど、flymakeとか使いつつ
インテリセンスも使えてeclipse/cdtのリファクタリング機能も使える環境のできあがり
0162デフォルトの名無しさん2007/10/05(金) 04:20:16
俺がいる
0163デフォルトの名無しさん2007/10/05(金) 08:18:16
もう遅いだろうがcoLinuxを薦めてみる
0164デフォルトの名無しさん2007/10/05(金) 12:27:41
coMomongaを勧めてみる
0165デフォルトの名無しさん2007/10/05(金) 12:59:49
coLinuxの方が便利なの？
速度が速い以外のメリットがないなら、もう乗り換えれない
0166デフォルトの名無しさん2007/10/05(金) 15:23:45
coLinuxってkernelのバージョンあがるたびに中身を全消ししないといけないって聞いたのだけど
違うの？
0167デフォルトの名無しさん2007/10/05(金) 17:36:55
ヘッダファイルなどで記述したグローバルなstatic変数は，
includeしたソースが複数ある（各ソースではincludeガードが起きずに展開される）
場合も単一の存在となるんでしょうか？
それとも別々の独立した変数となるんでしょうか？
0168デフォルトの名無しさん2007/10/05(金) 17:41:00
それをインクルードしたソースファイルごとに別々に作られることになる
0169デフォルトの名無しさん2007/10/05(金) 18:02:52
ありがとうございます．
あれ，でもクラス変数などは単一なんですよね？
うーむ，基本の理解が全然出来ていない．
0170デフォルトの名無しさん2007/10/05(金) 18:26:17
クラスの static 変数はどこかで1個だけ実体を定義する必要がある。

class A{
 static int x;
};
int A::x;  // <-- これ

2個以上のソースファイルで定義したら、定義が重複してるってリンクエラーになる。
static でない普通のグローバル変数と同じあつかい。
0171デフォルトの名無しさん2007/10/05(金) 20:36:51
#includeは単にファイルをくっつけてるものと考えれば理解しやすいかも
0172デフォルトの名無しさん2007/10/06(土) 00:19:53
＞#includeは単にファイルをくっつけてるものと考えれば理解しやすいかも
くっつけるというのはちょっと違う。単にインクルードするだけ。
0173デフォルトの名無しさん2007/10/06(土) 03:48:00
>>169
ファイルスコープの static はクラスメンバやローカル変数の static とは全然
意味が違う。これは理解するとかじゃなくて覚えておく必要がある。
0174デフォルトの名無しさん2007/10/06(土) 12:08:54
C の仕様設計ミスとも言われている
0175デフォルトの名無しさん2007/10/06(土) 13:25:34
ここで聞いて良いか解りませんが
ＨＴＭＬのtableタグを抜き出して２次元配列化するのに簡単な方法ありますか？
0176デフォルトの名無しさん2007/10/06(土) 13:38:01
簡単な方法かどうかわからんが、文字を読み込みながら解析していきゃいいんじゃね？
表の大きさがあらかじめ分かってるなら楽、わかってなくても確保すりゃできる。
0177デフォルトの名無しさん2007/10/06(土) 13:43:54
rowspanとかの扱いが面倒くさいなと(´Д｀;)
0178デフォルトの名無しさん2007/10/06(土) 14:04:10
>>177
大丈夫、Lynx辺りのソースを見れば書いてあるはずだ。
# 簡単とは思えないが。
0179デフォルトの名無しさん2007/10/06(土) 19:44:49
100行くらいあるテーブルで
最後の行にだけ colspan 書いてあったり？
0180デフォルトの名無しさん2007/10/06(土) 19:55:07
それは困らんだろ
0181デフォルトの名無しさん2007/10/07(日) 22:00:29
Linuxでg++4.1.2を使ってるんですが、簡単なODR違反って、リンカが検出してくれたりしないんでしょうか？
0182デフォルトの名無しさん2007/10/08(月) 01:04:43
>>181
簡単なやつならシンボルの重複が発生してリンカのエラーになるよ。
0183デフォルトの名無しさん2007/10/08(月) 01:15:15
g++だと、クラステンプレートの中の関数はweak symbolになってしまうようで、
重複しても怒られないんだよね.....
0184デフォルトの名無しさん2007/10/08(月) 07:47:24
>>183 それは難しいやつってことで。
0185デフォルトの名無しさん2007/10/08(月) 14:08:29
最近C++やったのだけど
ただクラスを作って使うだけでもCよりは使いやすいよね、これ。
0186デフォルトの名無しさん2007/10/08(月) 14:10:02
クラスを作らないで使わないでもCよりは使いやすい
0187デフォルトの名無しさん2007/10/08(月) 14:12:06
C+関数オーバーロード+テンプレートで作ると意外と強力
0188デフォルトの名無しさん2007/10/08(月) 14:14:40
BOOST_PPだけで作ると読めない。
0189デフォルトの名無しさん2007/10/08(月) 14:21:37
>>185
関数型や今時のLLの真似をしようとすると
すぐに泣くことになるけどな
0190デフォルトの名無しさん2007/10/08(月) 14:55:31
BjarneStroustrup様に感謝しなさい。
0191デフォルトの名無しさん2007/10/08(月) 16:51:26
以下のコードがsegmentation faultで落ちます。

#include <boost/regex.hpp>

int main()
{
　boost::regex re("^(..)*\\xA4");
}

（ひらがなを含むEUCコードの文字列の正規表現）


コンパイル/実行環境：
i686, linux-2.6, gcc-4.1.2, boost-1.34.0, -O3オプション

ia64、-O2オプションでも試しましたが、その場合は問題は発生しませんでした。

私はこれ以上調べる知恵を持たないのですが、GCCのバグなのでしょうか？
0192デフォルトの名無しさん2007/10/08(月) 17:17:20
ICE? 実行時のSEGV?
boostのバグかもしれんよね。
0193デフォルトの名無しさん2007/10/08(月) 17:43:33
とりあえず core から stack trace を見るんだ
01941912007/10/08(月) 18:07:48
GDBで覗いてみたら解決しました。
原因は恥ずかしくて言えません。あまりにも下らないミスでした。
スレを汚して申し訳ありません。
0195デフォルトの名無しさん2007/10/08(月) 21:55:59
いや、相談しに来たなら原因言ってから取り下げろって。
0196デフォルトの名無しさん2007/10/08(月) 22:02:02
>>194
恥ずかしがることないじゃないか、減るもんじゃなし。
このまま消えたらそれこそスレ汚し。質問に対して考えてくれた人に対して礼を欠く事になるぞ。
0197デフォルトの名無しさん2007/10/08(月) 22:17:26
おまえら恥ずかしい原因聞きたいだけだろと
01981912007/10/09(火) 00:44:29
自分でインストールしたboostとシステムの管理者がインストールしたboostがあって、
後者の存在はこの問題を解決するまでは知りませんでした。

自分のboostを使うときは-lboost_regex-gcc41としなければならないのですが、
-lboost_regexと間違えていました。
管理者の用意したboostと何事もなくリンクしてしまうのでミスに気付かなかった。

GDBの出力に /usr/lib... という文字列を見つけて始めてミスに気付きました。



あれ？　でもおかしいな。違うboostをリンクしたらそれはそれでうまく動くんじゃないんでしょうか？
0199デフォルトの名無しさん2007/10/09(火) 01:01:52
>>198
「違うboost」の何が違うのか調べないと、原因はわからんな。
0200デフォルトの名無しさん2007/10/09(火) 01:09:37
別に恥かしいことじゃなかったな。
しかし管理者か。
自分の視野外からバグが入り込むとはまるよな。
0201デフォルトの名無しさん2007/10/09(火) 01:29:34
boostって何者ですか？　どっかの誰かによって拡張されたものですか？

標準ライブラリではないとは思うのだけど、それなら、
boostを使って記述すると、環境依存（バージョン依存）物とか言って怒る人います？
0202デフォルトの名無しさん2007/10/09(火) 01:32:43
怒る人がいるかどうかは、お前の環境依存。会社とか。 >>201
0203デフォルトの名無しさん2007/10/09(火) 02:15:23
>>198
原因は措いておくとして。
自分がスーパユーザじゃなくて自前でインストールした
ライブラリとかを利用するときは、-I でインクルードパスを明示するのと、
リンク時には -L でライブラリパスを明示するのを習慣付けておいたほうが
良いで。
0204デフォルトの名無しさん2007/10/09(火) 02:22:30
>>198 >>203
実行時のLD_LIBRARY_PATHも忘れずに。

それが面倒なら、boostの場合は、.soでなく.aのほうをリンクしてしまうのも手だ。
-lを使わず、/home/mona/lib/libboost_regex.a とフルパスを書いてしまう。
0205デフォルトの名無しさん2007/10/09(火) 12:33:32
boost/regexで日本語扱うにはユニコードに変換しないと駄目なんじゃないの？
0206デフォルトの名無しさん2007/10/09(火) 17:23:06
namespaceで区切ってグローバル関数を使うのと
クラスを作ってメンバ関数として使うのと

どちらがパフォーマンスがいいのだろうか?
0207デフォルトの名無しさん2007/10/09(火) 17:32:11
>>206
どちらも同じコンパイル単位内に関数の実体があると仮定していいなら、後者の方がインライン展開されやすいので
パフォーマンスが高い可能性がある。但し、コンパイラによっては全く同じになる可能性も高い。
0208デフォルトの名無しさん2007/10/09(火) 17:48:35
>>207
ありがとう!
つまり、ソースの読みやすさを優先すればいいって事ですね?
0209デフォルトの名無しさん2007/10/09(火) 19:04:01
パフォーマンスは置いといて、こういうのって、
(自分流でも)オブジェクト指向に沿って考えたら自然と決まるもんじゃないの？
それともC++のクラスってオブジェクト指向以外の用途も一般的？
0210デフォルトの名無しさん2007/10/09(火) 19:33:22
test
0211デフォルトの名無しさん2007/10/09(火) 19:45:35
testy
0212デフォルトの名無しさん2007/10/09(火) 19:51:39
testest
0213デフォルトの名無しさん2007/10/09(火) 20:02:24
>>209
構造化にしろオブジェクト指向にしろ、ソースのメンテナンス性を上げるための物だと理解してます
グローバルな関数にした方が使い勝手が良ければグローバル関数で処理するし
クラス化した方が使い勝手が良ければクラスを使います

使い勝手というのが、ある場面ではパフォーマンスであったり、ある場面ではメンテナンス性であったりするわけですが
また、メンテナンス性は、ソースの可読性に大きく左右されるので、パフォーマンスが同等であるならば、ソースの可読性を優先するのは自然だと思います
0214デフォルトの名無しさん2007/10/09(火) 20:42:41
namespace hage{namespace hoge{
　　void func() {}
　　}}

struct hage2 {struct hoge2 {
　　static void func() {}
　　　　};};

int main() {
　　hage::hoge::func();
　　hage2::hoge2::func();
}

どちらでも階層を実現できるけど
class struct を使う方法ならアクセス指定もできる
よって選らぶなら後者？…なわけないな
0215デフォルトの名無しさん2007/10/09(火) 20:44:08
×選らぶ
○選ぶ

らぶ
0216デフォルトの名無しさん2007/10/09(火) 20:48:47
>>213
なるほど、C++初心者だけどOOPに慣れてるから、まずOOがあるものとして考えてたよ
ただ、
> ソースの可読性を優先するのは自然
って考えた時に、オブジェクトとして捉えられる物はクラス化した方がいい場合があるのは当然として、
そうでないものをクラスにまとめることもあるのかな？ってのを疑問に思ったの

名前空間とクラスのどっちを選ぶかは目的の持っている意味で分けられて、
それで結果的に可読性が向上すると思ってるから
0217デフォルトの名無しさん2007/10/09(火) 23:08:42
char hoge[5000*5000];
とか書いといて走らせると、hogeがちゃんと確保されないんだけど、
これって当然なんでしょうか。
100*100とかだと大丈夫。
アクセスするとseg faultしちゃう。
newしてやるとちゃんと確保される。

gcc + Linux or OS X
0218デフォルトの名無しさん2007/10/09(火) 23:11:37
コンパイラでスタックの量を24MB以上許容してくれるように設定しなさい。
0219デフォルトの名無しさん2007/10/09(火) 23:22:40
>>218
ああ、そういうのがあるんですか。
newしてポインタがNULLかを調べるほうが普通？
0220デフォルトの名無しさん2007/10/09(火) 23:27:35
とりあえずスタックとヒープの違いについて調べるのが普通
0221デフォルトの名無しさん2007/10/09(火) 23:29:53
C++の規格にスタックとかヒープなんてあったっけ？
0222デフォルトの名無しさん2007/10/09(火) 23:31:53
ないね
0223デフォルトの名無しさん2007/10/09(火) 23:35:58
>>219 標準 C++ で、ただの new がヌルを返すことはありません。
0224デフォルトの名無しさん2007/10/10(水) 01:55:15
まぁ規格になくても知っといた方がいいやな。
0225デフォルトの名無しさん2007/10/10(水) 21:01:39
Javaでスタックにオブジェクトおくにはどうすればいいの？
もちろん、スレちがいだかんね。
0226デフォルトの名無しさん2007/10/10(水) 21:13:13
SomeClass *p = new SomeClass();

SomeClassのコンストラクタの処理が凄い思いとする。
この重い処理中、p は NULL? 非NULL? どちら？？
処理系の実装依存なのかな。
0227デフォルトの名無しさん2007/10/10(水) 21:53:05
ごみ値。
0228デフォルトの名無しさん2007/10/10(水) 21:56:43
VC6やそれ以前を前提に話をしたいならそれ専用のスレに行ったほうがいい。
あれの動作は特殊だからねぇ〜
0229デフォルトの名無しさん2007/10/10(水) 22:01:04
スレチ杉てわらってしまった
0230デフォルトの名無しさん2007/10/11(木) 12:10:34
SomeClass *p = new(nowthrow) SomeClass();

ってやれば、一応失敗すればヌルポを返す
0231デフォルトの名無しさん2007/10/11(木) 13:19:46
そしてコンストラクタが例外を投げるとｗ
0232デフォルトの名無しさん2007/10/11(木) 15:03:47
＞nowthrow
0233デフォルトの名無しさん2007/10/11(木) 18:40:50
いま投げる？？
0234デフォルトの名無しさん2007/10/11(木) 19:52:03
ナウいな
0235デフォルトの名無しさん2007/10/11(木) 20:08:31
C++TESTって使ったことある人いる？

あれで構造体が「truncated」ってなって設定できないんだけど、何で？

教えてくださいエラい人。
0236デフォルトの名無しさん2007/10/11(木) 23:13:27
>>230
例外を使ったことない人が、例外を使いたくなくてひっかかる勘違いだな。
0237デフォルトの名無しさん2007/10/12(金) 05:59:42
ICUのUnicodeString
クラスのインスタンスの比較で
operator==
使ったんだけどおれは今まで
bool(最悪でもint)を想定してコードを書いてきたんだ。

そしたら、
返された型がUBool = signed char
だったんだ・・・
UBoolってboolっぽいから盲点だったよ。
pimplでラップしろとのお告げなのだろうか・・・

std::cout << o1 == o2 << std::endl;//で判明
0238デフォルトの名無しさん2007/10/12(金) 08:08:01
比較演算子はboolじゃなくてintが基準だよ。
02392372007/10/12(金) 09:12:42
>>237
冗談かと思ったら散々な結果・・・
比較演算子の型は不明？ｗ

std::cout << typeid(1.0==1.0).name() << std::endl;//VC6(int),VC7.1(int),VC8(bool),GCC3.4.4(bool)
std::cout << typeid(1==1).name() << std::endl; //VC6(long),VC7.1(bool),VC8(bool),GCC3.4.4(bool)

結論：boolは関数オーバーロードしない。または、明示的に呼び出す。
0240デフォルトの名無しさん2007/10/12(金) 09:22:22
>>239
これまじで？
もうVC6とかVC7.1は使わないから、いまさらどうでもいいんだけど。
0241デフォルトの名無しさん2007/10/12(金) 10:58:30
>>238-239
規格では組み込みの比較演算は全部 bool になる。
VC の比較演算か typeid がバグってるんだろ。
0242デフォルトの名無しさん2007/10/12(金) 18:07:19
#ifndef HOGE_H
#include "hoge.h"
#endif

と、hoge.h内で

#ifnedef HOGE_H
#define HOGE_H 1
class hoge{
};
#endif

ってするのはどっちにどういう長所短所があるんでしょうか。
0243デフォルトの名無しさん2007/10/12(金) 18:18:11
前者はISO-C以前のアナクロな手法。C++でそんなことやるのは馬鹿。
0244デフォルトの名無しさん2007/10/12(金) 18:22:11
>>243
あざっす。
数十種類の色んな環境でmakeできるソフト読んでたんで、
前者はそういうとこで念のために使う感じですね。
0245デフォルトの名無しさん2007/10/13(土) 15:06:26
>>242
コンパイル速度上げるための小細工。hoge.h の中で #ifndef してると、当然
hoge.h を読み込んでプリプロセッサが解析するコストがかかるが、前者だと
ファイル開く必要がない。

ちなみに #pragma once 使える環境なら、そっちの方が良い。
0246デフォルトの名無しさん2007/10/13(土) 15:27:50
#ifdef _MSC_VER
# pragma once
#else
# ifndef XXX_IS_INCLUDED
# define XXX_IS_INCLUDED
/* */
# endif
#endif

こうですか？わかりません＞＜
0247デフォルトの名無しさん2007/10/13(土) 15:34:47
>>245
gcc は #pragma once 使わなくてもインクルードガードのパターンを認識して
同等の処理をしてくれるらしい。

つまり #pragma once しか使えない環境なら付けといたほうがいいかも、って感じ。
0248デフォルトの名無しさん2007/10/13(土) 17:35:03
>>246
未知の#pragmaは無視してくれるんじゃなかったっけ?
0249デフォルトの名無しさん2007/10/13(土) 17:44:39
まぁでも#pragma once に別の意味があるコンパイラもあるかもしれん
0250デフォルトの名無しさん2007/10/13(土) 17:45:42
>>248
コンパイラによっては同じ名前でも違う意味だったりする可能性もあるから
#pragma はたちが悪い。
0251デフォルトの名無しさん2007/10/13(土) 22:36:50
インクルガドのパターンは標準的だしそれでいいんじゃねーの
0252デフォルトの名無しさん2007/10/14(日) 04:02:26

void fh() {
　try {
　　throw;
　} catch(int) {
　　printf("1\n");
　} catch(bool) {
　　printf("2\n");
　}
}

int main() {
　try {
　　throw true;
　} catch (...) {
　　fh();
　}
　return 1;
}

これってhack? これ許されるなら、TypeListの
要素全てをcatchするなんてのも出来そう。
■ このスレッドは過去ログ倉庫に格納されています