C言語なら俺に聞け 162
構造体変数の宣言の初期化のとき、ヌルポインタを,{ }でくくらないと、警告が出るのですが、なぜですか？ 例えばこんな具合にしないと警告が出ます
struct monster {
char name[80];
int HP, MP;
};
int main(void)
{
struct monster template = {{0}, 7, 4}; >>646
char name[80];に入るのはポインタではなくchar型の配列か文字列 >>647 よくわかりました ありがとうございます 構造体云々言う前に、配列の初期化方法についてまず調べろ >>621
Perlでメモリ不足になるってことは循環参照が発生してメモリが解放されない(PerlはリファレンスカウントGC)
もしくは深い再帰でPerl管理のVMスタックが枯渇したか
どちらにしろCで書いてもメモリをバカ食いするのは間違いないから
データ構造を見直すべき
循環参照を見直す、再帰をループに変えるなどを試してみてはどうか グラフ構造を使う場合は循環参照は容易に生まれるからな
PerlのScalar::Util::weakenで変数をラップしてやる
こうするとその変数は弱参照になる #include <stdio.h>
#include <string.h>
void main(void)
{
char c[32];
char *pc;
strcpy(c, "JAPAN-TOKYO-OSAKA");
pc = &c[0];
//for(int i=0; i<strlen(c); i++, *pc++){
for(int i=0; i<strlen(c); i++, pc++){
printf("%c", *pc);
}
printf("\n");
} コメントアウトしてる方のforにしても出力結果は同じになります
*付きポインタ変数は、中身へアクセスを意味するからめちゃくちゃな文字列が出力されるはずじゃ・・・？
どうしてなの？ このソースを何という名前で保存して、何というコンパイラでコンパイルしたかとか、色々 >>657
文句を行ってもしかたがない
そういうものとして納得するしかないんだろうけど、”おかしい”と思ってるCプログラマーは世界中に２億人くらいいると思う *も++も単項演算子で適用される優先順位がある
優先順位を意識してコーディングしないと痛い目に合う
a + b == cは想定通りだろうが、a & b == cは想定外の結果になるとかねw 足し算掛け算の掛け算をシフトに書き換えたら上手く動かなくなって焦った シフト演算子は加減算より優先度低いのにカッコで囲わなかったって事でしょ シフトは乗除っぽいイメージだから加減算よりも先でいいよなぁ
ビット演算子が比較よりも後なのは完全に仕様バグだろ… 冴えてないときの自分のためにも、他人のためにも、なるべくカッコはつけるかな いまさら言って仕方ない事をいちいち書くなよ
お前が次のC言語でも作って人生を棒に振ればいいだけだよ >>667
便所の落書きにぶちギレw
お前の人生はいつも焦燥感に満ちてんだろうなw >>655
後に現れたC++のiostreamがシフト演算子をオーバーロードし入出力演算子として流用するのに
好都合で、思わぬ役に立つことになったからまあ良いだろ。もしシフト演算子が四則演算子より
優先順位が高かったら、cout << 1 + 2 * 3 << endl を cout << (1 + 2 * 3) << endl と
書かなければならず面倒だった。（C++がシフト演算子を全く別の機能に流用したのは不適切
だったという意見もあるが…） >>669
シェルのリダイレクトと概念が一致してるから、最初見た時は天才かよと感心したな
でも、出力の整形が激ムズなんでやっぱり駄目じゃんと気付くまではそう思ってた >>656
*pc++ はまず *pc の処理をする。これで pc の差している先にある値を取り出すことになる。その次に pc を一つ分進ませる(実際に加算される値は sizeof(*pc))。
では最初に *pc で取り出した値はどこへ行ってしまうのか? それは何にも使われずにただ捨てられる。 *pc++の形はcやってたら所々で見るから否応なく慣れる
個人的にはケチくさい書き方で避けたい気持ちもあるがまぁそういう文化が根付いてるなら合わせざるを得ない >>665
初期のCでは||が無くて論理和も|使ってたためのはず
KかRのどっちかが「後悔してるけど今さら変えられないし」とか言ってた C言語の標準化委員はC++のほうも兼任してたりするから、ぶっちゃけC言語の改善にはやる気無しだから。 C++はRustと比較されて安全性に劣るとレッテルを貼られて、どうしたもんか考えあぐねてるところだろうw
言語の拡張に対して完全に方向転換を強いられてるのは間違いない
それはCも一緒だな パフォーマンスを損なわずにRustと同等の安全性を追加するか、もうこのままそっとしておくかw、の2択だろう >>674
もはやbetter Cでも何でもないのに、このスレでも繰り返しc++の話題出す奴居るし、やっぱユーザーも被ってるんだろな
まあCの設計の良否を他言語よりは比較的小さな差異から論じるのに有用だとは思う
おれみたいにC++は書かずともcpprefとか読んで式や文、宣言など局所的な構文知識だけちょっとある人は多かろう(ClassとかCに無い概念は読み飛ばしてて無知)
生まれた順序が逆だけど、FortranがC++とすればF言語/JuliaがCだね
大体サブセット+独自進化、標準化コミュニティ丸被り C++は好きじゃないからC言語はもっと改善していって欲しい。
nullptr型とか入るの遅すぎじゃね？ C++はCの機能を保ったまま、ありとあらゆるプログラミングパラダイムを突っ込んだもの
それがベターかどうかは人によるな
ただ、Cと互換性を保ったままそこまで進化したのは奇跡に近い でも、Rustが安全性と性能は両立出来ることを証明してしまってから、一気に旗色が悪くなったw
今まで性能を免罪符にして、多少(かなり？)の安全性を犠牲にしてきたけど、もはや通用しない時代になった
今後どう進化するか見物だな
Cだって対岸の火事ではない ちなみに、Rustは安全な代わりに書きたいコードを書けるとは思わない方がいいw
これは書いてみないと分からん感覚だ
書きやすくて安全な言語は存在しないことも証明されたw 必ず遠回りをさせられる感覚は非常にムズムズするよな
あれならgccでstack-protectorとかsanitizeとかガン盛りした方が
気分良く高効率に書けると思った 今日から戯れに数十年前のx86なGUIのソースをx64に移植し始めたんだが
とりあえずエラーになるGetWindowsLongだかをx64用に書き換えていったらそこそこ動いてしまって、後は文字列が関係する処理だけだ
俺が書いた過去のコードがよっぽど優秀だったようだ
やはり若い頃にソースを沢山書いといてよかった x64化でちょっとsize_tの扱いで躓いたので書いておこう
ポインタが64bitだから、その差を取る場合もあるsize_tも64bitなのは理屈では理解できるんだが
明らかに64bit幅が不要な箇所でsize_tに出くわすとおいおいと思ってしまう
これはbit数を明示した型を別に定義した方がよさそうだ
ああまいったまいった >>686
Windows1.0のexeもWindows10(32bit版)でも動くからな
64bit版は16bitコードの実行が廃止されたから無理
APIの方は割と変わってるけど、それでもちょっと直せばビルドできる
優秀なのはMicrosoftの方だなw Windows11は最初から32bit版が無いんだよな…
ポインターに64bitも必要ない
36bit(64GB)有れば十分
farとnearポインター復活しても良いよw win10使ってるけどOffice 97をバイナリコピーして使ってるぞ、とうとう11では動かんのか…？
主にExcel使うが関数の数は劣ってもヘルプは古い方がよく出来てて一般ユーザとしては好み、一々ブラウザ起動されてたらい回しは嫌だ Office97は32bitだから動くでしょ
駄目なのはWindows3.1までの16bitアプリ
じぶんもフリーソフトをいくつか64bit化したけどほとんど修正してない
早めにUnicodeにしてたおかげもあるかな 
