トップページ⇒tech
1001コメント327KB

【初心者歓迎】C/C++室 Ver.64【環境依存OK】

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2009/02/10(火) 00:25:51
エスケープシーケンスやWin32APIなどの環境依存なものでもOK。
ただしその場合、質問者は必ず環境を書きましょう。
※sage禁止です(と代々スレに書いてありますが自己判断で)。

【前スレ】
【初心者歓迎】C/C++室 Ver.63【環境依存OK】
http://pc11.2ch.net/test/read.cgi/tech/1231499251/

【アップローダー】(質問が長い時はココ使うと便利)
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/joyful.htm

◆ソースのインデントについて
半角やTABでのインデントはスレに貼ると無くなります。
そのため、アップローダーに上げるのが最も良いですが、
直接貼るのであれば、全角空白か に置換しておくことをお勧めします。
0951デフォルトの名無しさん2009/04/08(水) 23:19:37
C#使うぐらいならVBのほうがいいよ
0952デフォルトの名無しさん2009/04/08(水) 23:21:17
>933
ありがとうございます。
昔そんなことを習ったような気がします。
0953デフォルトの名無しさん2009/04/08(水) 23:21:31
VBなんか死んでもやらない。理由は無い。
0954デフォルトの名無しさん2009/04/08(水) 23:50:21
「無い」というのも立派な理由だよ
0955デフォルトの名無しさん2009/04/08(水) 23:58:29
同じ.NET frameworkを使っているだけで、VBとC#を一緒にするのはないわ
0956デフォルトの名無しさん2009/04/09(木) 00:04:13
似たようなもんだけどな。
0957デフォルトの名無しさん2009/04/09(木) 00:41:18
VB.netとC#は似たようなもん。
0958デフォルトの名無しさん2009/04/09(木) 02:11:18
>>947
言語のせいじゃないだろ。ライブラリの作者に文句言え。
0959デフォルトの名無しさん2009/04/09(木) 07:52:07

困っています。
http://www.kattch.com/~kattch/MySQL/06_3.html
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

09609592009/04/09(木) 07:53:41
追記。
count = mysql_num_rows(result); の部分でも落ちます。
09619592009/04/09(木) 08:02:44
ソースファイルは
mysqltest.cではなくmysqlclient.cの間違いです。
0962デフォルトの名無しさん2009/04/09(木) 08:20:45
result = mysql_store_result(&mysql_buf); ← SQL回答領域ハンドルの取得
このハンドルでエラーになってる可能性が高いな
09639592009/04/09(木) 08:29:51
>>962
解決方法とか……何かあるでしょうか。。。
09649592009/04/09(木) 09:01:17
>>962
おっしゃる通り、取得に失敗していました。

if(result = mysql_store_result(&mysql_buf)){
}
else
{
　printf("QUERY Error\n");
}
09659592009/04/09(木) 09:19:30
>>962
判った！！！！！！！！！！！！！！！！！！！！！！
ありです。ばかやってました。
0966デフォルトの名無しさん2009/04/09(木) 09:30:25
>>963
ソースもなしで他人のデバッグなんかできませんが。
それとも、デバッグのノウハウを0から教えろと言うことでしょうか。
0967デフォルトの名無しさん2009/04/09(木) 09:41:09
esp
0968デフォルトの名無しさん2009/04/09(木) 10:08:03
関数の戻り値チェックはちゃんとしましょうということだろ
0969デフォルトの名無しさん2009/04/09(木) 11:26:47
PHPからCをCからPHPを呼び出す、もとい実行する方法ってある？
0970デフォルトの名無しさん2009/04/09(木) 11:40:46
>>969
systemやexec系の関数で出来るだろ
0971デフォルトの名無しさん2009/04/09(木) 12:01:34
そろそろ1000か。ところで、このスレの過去ログを全部保存しているサイトとかってないのかな？
時々ググって引っかかったけどdat落ちしてたりとか、過去のこの辺で出てたよな、とかそういうの
あるんだけど。
0972デフォルトの名無しさん2009/04/09(木) 12:03:17
過去ログ見ろとか言われても困るよなｗ
0973デフォルトの名無しさん2009/04/09(木) 12:57:43
boost::shared_ptr<Test> MemberFunction();
boost::shared_ptr<Test>& MemberFunction();
あるクラスが、内部にTestのスマポを持っていて、それを返す関数があるとします。
(名前はMemberFunction)。
このとき、参照で返すのと、実体で返すのとは、どう違うでしょうか？
自分は、スマポを返す場合は参照以外はないと思ってたんですが、実体を
返すことに意味はあるでしょうか？
0974デフォルトの名無しさん2009/04/09(木) 13:14:58
参照を返したら外部からインスタンス内部のポインタをresetできる。
コピーインスタンスを返したら、外部のスマポは外部のポインタだけ変更できる。
0975デフォルトの名無しさん2009/04/09(木) 13:20:34
>>974
外部から触って欲しくない時にはコピーインスタンスを返すべきということですか？
でも、そうなると内部で保持しているスマポはboost::scoped_ptr<>を使うべきでは
ないですか？
0976デフォルトの名無しさん2009/04/09(木) 14:42:25
scoped_ptrだと、呼び出し元がポインタを得た後、「あるクラス」のインスタンスが変更受けた場合に、
呼出し元が破棄されたポインタを持たされる危険がある。
というか内部実装にscoped_ptrを用いる場合はTestをコピーして返すべき。

そもそもスマポは、Testインスタンスを参照する手段であって、
MemberFunctionもTestを渡すのにスマポを用いてるだけで、Testの参照の参照を返すのは本来的に無意味。
0977デフォルトの名無しさん2009/04/09(木) 20:46:08
スマポってセマンティクスはポインタだからな
Test*& MemberFunction();
と同じ事をしようとしてる
0978デフォルトの名無しさん2009/04/09(木) 20:57:10
>>975
コピーをお前はTest自体のコピーと考えているように見えて、
974はshared_ptrのコピーのことを指しているように見えるぞ。
0979デフォルトの名無しさん2009/04/09(木) 21:17:13
&じゃなくてconst&ならありなんじゃね？
値をコピーすると参照カウンタの操作が入って遅いだろうし。
09809752009/04/09(木) 22:10:14
でもスマポ(特にboost::shared_ptr<>)の参照を返すコードって結構ないですか？
スマポのコピーって本当に遅いし。測ったら普通のポインタのコピーより
30倍近く時間がかかってました。
でも本当は無意味で、979さんの言うとおりconst&の時だけ意味があるのかな？


0981デフォルトの名無しさん2009/04/09(木) 23:02:14
速度を本当に気にするような場面ならそもそもスマポを使うな。

しかし、ほとんどの場合においてスマポのコピー程度の時間は全く問題にならない。
30倍と言うが、ポインタのコピーなんて機械語で一命令になるかならないかのレベルなんだから、
それが30倍になろうとも余程の大量コピーでない限り全く気にならない。
0982デフォルトの名無しさん2009/04/09(木) 23:06:31
shared_ptrの参照を返すことなんてまず無いな。むしろコピーしてなんぼだ。
そもそもオブジェクトが何かの参照を返す事自体問題がある。
09839752009/04/10(金) 01:02:41
そうなんですか。。。
実は自分が今やってるプロジェクトでは、boost::shared_ptr<>&返し
(スマポの参照返し)を使いまくってて、自分もそれに合わせて書いてるんですが、
最初にスマポの参照返しを使い始めた人はもうプロジェクトにはいないし、
なんでかなとおもってたのですが。、。
0984デフォルトの名無しさん2009/04/10(金) 01:24:38
スマポの参照返すくらいなら普通に参照返せばいいんじゃ？
0985デフォルトの名無しさん2009/04/10(金) 01:37:00
ぬるりーは怖いぜよ
0986デフォルトの名無しさん2009/04/10(金) 02:03:51
返ってきたスマポの参照が本当に有効なスマポを指してるのか
知らない間に外からいじくられないか
いつまで生きてることが保証されてるのか
そもそもスマポってこんなこといちいち気にしたくないから使うもんのはずだ

危ないことしたくないからわざわざ重いスマポ使ってるのにそんなことするなんて
ストーブ炊いて暑いからってクーラーかけるようなもの
馬鹿げてる
0987デフォルトの名無しさん2009/04/10(金) 02:26:16
ぬるぽは怖いぜよ
09889752009/04/10(金) 06:56:20
じゃあやっぱり最初にスマポの参照返し使いまくりをはじめた人に聞いてみたほうがいいのかな。。。
ソースを見る限り、間違いなくC++の達人だと思ったので、そのやり方にしたがってれば間違いない
と思ったんだよな。
ちょっと聞いてみます。
0989デフォルトの名無しさん2009/04/10(金) 07:25:22
30倍遅いっても怪しい感じだな
そんなに遅くなるか？

誰か試してくれ
0990デフォルトの名無しさん2009/04/10(金) 07:28:34
0991デフォルトの名無しさん2009/04/10(金) 08:19:19
shared_ptrなら、コピー時の参照数の管理コストを無視できない、かも。
09929752009/04/10(金) 09:00:38
この前30倍近く遅かったと書いたけど、こんなコードでやってました。
Forループの中を入れ替えて時間計ったら、素のポインタだと2秒、
スマポだと70秒だった。（最適化は無し）
ちなみに自分の環境は、VistaでCPUはT8100の2.1Ghz

#include <iostream>
#include <ctime>
#include <boost/shared_ptr.hpp>
class Test {
public:
Test() {}
~Test() {}
};
int main() {
boost::shared_ptr<Test> sp1(new Test());
Test* p1(new Test());
time_t t1,t2;
time(&t1);
for (int i = 0; i < 300000000; ++i) {
boost::shared_ptr<Test> sp2(sp1);
// Test* p2(p1);
}
time(&t2);
std::cout << t2-t1 << std::endl;
return 0;
}
0993デフォルトの名無しさん2009/04/10(金) 09:08:36
ume
0994デフォルトの名無しさん2009/04/10(金) 09:16:24
最適化なしで較べるなよ。JK
09959752009/04/10(金) 09:53:52
だって最適化してもポインタのコピーがちゃんと行われるように書くの
面倒じゃないですか？
最適化しないとだめですか？
0996デフォルトの名無しさん2009/04/10(金) 09:57:16
実際のソフトで時間計らないと意味がない。
1ms秒が30msかかった所で、もし同じ頻度で呼ばれる関数が1秒かかっていたら
初めの差は無視できる。
0997デフォルトの名無しさん2009/04/10(金) 10:00:57
自分の場合は、スマートポインタやGCなどは使わない。使いこなせない。
STLの変数生成速度でも気になるから、グローバルに定義してしまうなどする。
全てではなく多く回数使うやつなどね。
0998デフォルトの名無しさん2009/04/10(金) 10:07:03
気になるからとか気分じゃなくて実測して、
それが本当にボトルネックになってるか確認してからにしようぜ。
意味の無い自己満足な最適化はコードを読みにくくするだけで、
何のメリットないからな。
0999デフォルトの名無しさん2009/04/10(金) 10:12:36
gotoは除外すべきという説があるが、多重ifの方を無くすべきだ。
if else を続けるとかなり難解になってしまう。
1000デフォルトの名無しさん2009/04/10(金) 10:15:53
>>998
実際にstringを使うアルゴリズムで実測してみた経験から。
string、resizeを頻繁にするとcopyや生成でかなり食っている。
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。