【初心者歓迎】C/C++� ..
941:デフォルトの名無しさん
09/04/08 22:21:05
URLﾘﾝｸ(www.01-tec.com)
ここの、●バグその3「'\0'終端」
のサンプルプログラムの事なんですが、
#include <stdio.h> /* puts() */
#include <string.h> /* strcat() */
int main()
{
char buff[128] ;
strcat( buff, "ABC" ) ;
puts( buff ) ; /* ABCと表示したい */
return 0 ;
}
buffに終端NULLが入っていない為、putsの表示がうまくいかない事が
このプログラムの意図するところらしいのですが、"で囲まれた文字列には
暗黙的に'\0'が付加されるのでこのプログラムのように
strcat( buff, "ABC" ) ;
としても問題ないですよね？
942:デフォルトの名無しさん
09/04/08 22:25:00
構成：すべての構成
にするとまずいんで（WIN32やら_DEBUGが消えてしまう）
Debug Release それぞれに _SCL_SECURE_NO_WARNINGS を追加で
943:デフォルトの名無しさん
09/04/08 22:31:21
>>941
C言語の文字列では，終端記号があることを前提にしています。
しかし，charの配列を確保しただけでは文字列として初期化されているわけではないのです。
以下の例は，終端記号の存在（文字列としての初期化）を忘れたために失敗してしまった例です
#include <stdio.h> /* puts() */
#include <string.h> /* strcat() */
int main()
{
char buff[128] = ""; // こうすればおｋ
strcat( buff, "ABC" ) ;
puts( buff ) ; /* ABCと表示したい */
return 0 ;
}
944:デフォルトの名無しさん
09/04/08 22:32:38
>>941
ちゃんとそこ読んだのか？
strcat()の呼び出し時点でbuffは'\0'終端文字列でなければならないが、
buffに'\0'が入っている保証はどこにもない
945:デフォルトの名無しさん
09/04/08 22:42:19
＞プログラマの都合よく '\0' で初期化されているわけではないのです。
初期化されないのは仕様だしな（スタックポインタを加減するだけ）
高級アセンブラは使う人を選ぶ
946:デフォルトの名無しさん
09/04/08 22:47:38
>>944,943
ありがとうございます、
自分の環境(gcc4.2.4)で、普通にABCと表示されていたのは
たまたま、配列buffがプログラマの都合よく '\0' で初期化されていたのでうまく動作していた
という認識で良いでしょうか
947:デフォルトの名無しさん
09/04/08 22:49:25
C++ は「高度な抽象」とか「型安全」とかいうくせに
ライブラリからは「低レベルな詳細」や「型安全でない変換」が透けて見えるじゃないか。
どういうことなんだ。ぷんぷん。
948:デフォルトの名無しさん
09/04/08 22:50:19
どちらもできる柔軟な特性と前向きに捉えてみる
949:デフォルトの名無しさん
09/04/08 23:05:04
C++はbetterなC
オブジェクト思考したいならJavaをやれ
C#・・・何それ？
950:デフォルトの名無しさん
09/04/08 23:14:55
C#はVBみたいなもんだよな。
951:デフォルトの名無しさん
09/04/08 23:19:37
C#使うぐらいならVBのほうがいいよ
952:デフォルトの名無しさん
09/04/08 23:21:17
>933
ありがとうございます。
昔そんなことを習ったような気がします。
953:デフォルトの名無しさん
09/04/08 23:21:31
VBなんか死んでもやらない。理由は無い。
954:デフォルトの名無しさん
09/04/08 23:50:21
「無い」というのも立派な理由だよ
955:デフォルトの名無しさん
09/04/08 23:58:29
同じ.NET frameworkを使っているだけで、VBとC#を一緒にするのはないわ
956:デフォルトの名無しさん
09/04/09 00:04:13
似たようなもんだけどな。
957:デフォルトの名無しさん
09/04/09 00:41:18
VB.netとC#は似たようなもん。
958:デフォルトの名無しさん
09/04/09 02:11:18
>>947
言語のせいじゃないだろ。ライブラリの作者に文句言え。
959:デフォルトの名無しさん
09/04/09 07:52:07
困っています。
URLﾘﾝｸ(www.kattch.com)
fedoracore4でC言語とMySQLを接続しようとしているのですが、
実行するとセグメンテーションエラーが出ます。
record = mysql_fetch_row(result); の
mysql_fetch_row関数を使用しているところで落ちているのは
判ったのですが何が原因か判りません。
コンパイル時の指定が間違っているような気がしますが
わかる人がいたら教えてください。
関係ファイルのパス
/usr/include/mysql/mysql.h
/usr/lib/mysql/libmysqlclient.so
/usr/lib/mysql/libmysqlclient.a
コンパイル
gcc -o mysqlclient \
-I /usr/include/mysql/ \
-L /usr/lib/mysql/ \
-l mysqlclient \
mysqlclient.c
ソースファイル
mysqltest.c
960:959
09/04/09 07:53:41
追記。
count = mysql_num_rows(result); の部分でも落ちます。
961:959
09/04/09 08:02:44
ソースファイルは
mysqltest.cではなくmysqlclient.cの間違いです。
962:デフォルトの名無しさん
09/04/09 08:20:45
result = mysql_store_result(&mysql_buf); ← SQL回答領域ハンドルの取得
このハンドルでエラーになってる可能性が高いな
963:959
09/04/09 08:29:51
>>962
解決方法とか……何かあるでしょうか。。。
964:959
09/04/09 09:01:17
>>962
おっしゃる通り、取得に失敗していました。
if(result = mysql_store_result(&mysql_buf)){
}
else
{
printf("QUERY Error\n");
}
965:959
09/04/09 09:19:30
>>962
判った！！！！！！！！！！！！！！！！！！！！！！
ありです。ばかやってました。
966:デフォルトの名無しさん
09/04/09 09:30:25
>>963
ソースもなしで他人のデバッグなんかできませんが。
それとも、デバッグのノウハウを0から教えろと言うことでしょうか。
967:デフォルトの名無しさん
09/04/09 09:41:09
esp
968:デフォルトの名無しさん
09/04/09 10:08:03
関数の戻り値チェックはちゃんとしましょうということだろ
969:デフォルトの名無しさん
09/04/09 11:26:47
PHPからCをCからPHPを呼び出す、もとい実行する方法ってある？
970:デフォルトの名無しさん
09/04/09 11:40:46
>>969
systemやexec系の関数で出来るだろ
971:デフォルトの名無しさん
09/04/09 12:01:34
そろそろ1000か。ところで、このスレの過去ログを全部保存しているサイトとかってないのかな？
時々ググって引っかかったけどdat落ちしてたりとか、過去のこの辺で出てたよな、とかそういうの
あるんだけど。
972:デフォルトの名無しさん
09/04/09 12:03:17
過去ログ見ろとか言われても困るよなｗ
973:デフォルトの名無しさん
09/04/09 12:57:43
boost::shared_ptr<Test> MemberFunction();
boost::shared_ptr<Test>& MemberFunction();
あるクラスが、内部にTestのスマポを持っていて、それを返す関数があるとします。
(名前はMemberFunction)。
このとき、参照で返すのと、実体で返すのとは、どう違うでしょうか？
自分は、スマポを返す場合は参照以外はないと思ってたんですが、実体を
返すことに意味はあるでしょうか？
974:デフォルトの名無しさん
09/04/09 13:14:58
参照を返したら外部からインスタンス内部のポインタをresetできる。
コピーインスタンスを返したら、外部のスマポは外部のポインタだけ変更できる。
975:デフォルトの名無しさん
09/04/09 13:20:34
>>974
外部から触って欲しくない時にはコピーインスタンスを返すべきということですか？
でも、そうなると内部で保持しているスマポはboost::scoped_ptr<>を使うべきでは
ないですか？
976:デフォルトの名無しさん
09/04/09 14:42:25
scoped_ptrだと、呼び出し元がポインタを得た後、「あるクラス」のインスタンスが変更受けた場合に、
呼出し元が破棄されたポインタを持たされる危険がある。
というか内部実装にscoped_ptrを用いる場合はTestをコピーして返すべき。
そもそもスマポは、Testインスタンスを参照する手段であって、
MemberFunctionもTestを渡すのにスマポを用いてるだけで、Testの参照の参照を返すのは本来的に無意味。
977:デフォルトの名無しさん
09/04/09 20:46:08
スマポってセマンティクスはポインタだからな
Test*& MemberFunction();
と同じ事をしようとしてる
978:デフォルトの名無しさん
09/04/09 20:57:10
>>975
コピーをお前はTest自体のコピーと考えているように見えて、
974はshared_ptrのコピーのことを指しているように見えるぞ。
979:デフォルトの名無しさん
09/04/09 21:17:13
&じゃなくてconst&ならありなんじゃね？
値をコピーすると参照カウンタの操作が入って遅いだろうし。
980:975
09/04/09 22:10:14
でもスマポ(特にboost::shared_ptr<>)の参照を返すコードって結構ないですか？
スマポのコピーって本当に遅いし。測ったら普通のポインタのコピーより
30倍近く時間がかかってました。
でも本当は無意味で、979さんの言うとおりconst&の時だけ意味があるのかな？
981:デフォルトの名無しさん
09/04/09 23:02:14
速度を本当に気にするような場面ならそもそもスマポを使うな。
しかし、ほとんどの場合においてスマポのコピー程度の時間は全く問題にならない。
30倍と言うが、ポインタのコピーなんて機械語で一命令になるかならないかのレベルなんだから、
それが30倍になろうとも余程の大量コピーでない限り全く気にならない。
982:デフォルトの名無しさん
09/04/09 23:06:31
shared_ptrの参照を返すことなんてまず無いな。むしろコピーしてなんぼだ。
そもそもオブジェクトが何かの参照を返す事自体問題がある。
983:975
09/04/10 01:02:41
そうなんですか。。。
実は自分が今やってるプロジェクトでは、boost::shared_ptr<>&返し
(スマポの参照返し)を使いまくってて、自分もそれに合わせて書いてるんですが、
最初にスマポの参照返しを使い始めた人はもうプロジェクトにはいないし、
なんでかなとおもってたのですが。、。
984:デフォルトの名無しさん
09/04/10 01:24:38
スマポの参照返すくらいなら普通に参照返せばいいんじゃ？
985:デフォルトの名無しさん
09/04/10 01:37:00
ぬるりーは怖いぜよ
986:デフォルトの名無しさん
09/04/10 02:03:51
返ってきたスマポの参照が本当に有効なスマポを指してるのか
知らない間に外からいじくられないか
いつまで生きてることが保証されてるのか
そもそもスマポってこんなこといちいち気にしたくないから使うもんのはずだ
危ないことしたくないからわざわざ重いスマポ使ってるのにそんなことするなんて
ストーブ炊いて暑いからってクーラーかけるようなもの
馬鹿げてる
987:デフォルトの名無しさん
09/04/10 02:26:16
ぬるぽは怖いぜよ
988:975
09/04/10 06:56:20
じゃあやっぱり最初にスマポの参照返し使いまくりをはじめた人に聞いてみたほうがいいのかな。。。
ソースを見る限り、間違いなくC++の達人だと思ったので、そのやり方にしたがってれば間違いない
と思ったんだよな。
ちょっと聞いてみます。
989:デフォルトの名無しさん
09/04/10 07:25:22
30倍遅いっても怪しい感じだな
そんなに遅くなるか？
誰か試してくれ
990:デフォルトの名無しさん
09/04/10 07:28:34
991:デフォルトの名無しさん
09/04/10 08:19:19
shared_ptrなら、コピー時の参照数の管理コストを無視できない、かも。
最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5004日前に更新/258 KB
担当:undef