C言語なら俺に聞け 142 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
ただmsvcrtを使うということはvcがサポートするC規格に引きずられるのを留意しておくこと
最新のmsvcrtでもたしかC99止まりでinttypes.hをインクルードしてもPRId64とか使えない
C11の機能が欲しければ素直にlinux+gcc|clangの環境をオススメする 最適化かけないと通るけど、最適化かけるとセグフォ
プリントデバッグしたらプリント文置いたり減らしたりするだけで最後に表示されるものが変わる
なんだこれ >>185
一切使ってないっす……
引数で配列の大きさ渡してるのがまずいのかもしれない 配列の代入とは関係ないところで死んでるっぽいこともあるんだけど、それでも配列の範囲外アクセスとかあるものかなあ…… >>188
そこそこ依存ファイルあるし、一応研究室の研究で書いているので、失礼ながらソースは上げられないです よく考えたらそんな状態で相談することが間違いか
やっぱり撤回します。スレ汚しすいませんでした 最適化の有無で変わった事と言うと、この前こんなことがあった。
(以下の A, B は typedef された構造体)
A *p = NULL;
B *q = NULL;
if (...) {
A x;
/* x の初期化などをする。 */
p = &x;
}
if (...) {
B y;
/* y の初期化などをする。 */
q = &y;
}
この後で p が NULL でなければ p の指す先を使おうとして死亡。
まあ、ブロック(というかスコープ)から外れた所で使ってるんだから当然と言えば当然ではあるが、
最適化しない場合は x, y はその他のブロック外の自動変数と同じようにスタックに領域が取られ
ていて変化する事がなかった。そのため内容は保たれた。
しかし最適化したら A の領域は A のあるブロックから外に出たら破棄されたと解釈され、そして
B のあるブロックの B の領域として上の A の領域を使用するようになっていた。そのため x と y
の指す先は union のように重なってしまっておかしくなったと。 >>179
いや、もっと単純に、APIの仕様変更で取得できる情報や型が変化したけど、エラー処理とか偶然うまく見える場合とかは目視では見落としがあるよねということ
テストを書く前に簡単に修正箇所がわかれば便利みたいな話だけど、まぁ、やり方やライブラリによって違うのかもね
少なくともAngularとかはTypeScript採用だし、型あったほうが便利派は少なからずいるよとだけ >>180,181
C#でも同じようにラムダ式やローカル関数で変数をキャプチャできるぞ
というかC++でもできるはず
コールバックは階層が増えたりエラーや例外処理、分岐などが生じるとどんどん複雑になって単純には行かなくなる
それを解決するのがPromiseで、それを更に単純に記述するのがasync/await
新しいライブラリとかはPromiseで返すのが当たり前になって来てるし、今後の言語もasyncに舵をきるんじゃないかな
>関数ポインタを差し込む時にいちいち考える必要がない
C++でどうやって実現すんの？
char *を受け取る関数ポインタにとconst char*で受ける関数ポインタを入れてエラーにしなかったらややこしくて危険なだけでしょ
コンパイルエラーじゃなくてテストで保証するとになればなおさら変 >>181
>最初から(A)(C)(B)の順に処理しろ
何言ってんだBとかCに副作用があるなら入れ替えちいかんだろ
コードは適当だけど、
void test(a,b)
{
hoge(&a,&b);
piyo(a+b);
}
test(1,2)
みたいに静的に確定するなら、piyoの引数をコンパイル時に計算してpiyo(3)みたいなコードをはいてくれたりもする スタックフレームの破壊は明白なんだから関数内で宣言してる配列全部の
範囲チェック入れてみな やりそうなこと
□ 要素数 n=10 の配列 int array[10];
アクセス可能なのは array[0] 〜 array[n-1] まで
なのに array[n] を利用してる
□ 文字列による配列の初期化で 終端記号(\0)含んだ分の領域を用意してない
× char text[3] = "123"; // 終端記号含めると 4要素の空間が必要なのに 3要素にしてる
○ char text[] = "123"; // コンパイラにおまかせで
□ 要素数を求めるのに sizeof(a) / sizeof(a[0]) を使ってるけど
そもそも論で a が配列ではなくポインタだった為
処理したい要素数が渡っていない >>183
研究室から出せない秘伝のソース、
なら特殊なハードウェアで、実はvolatileが欠かせない、とかじゃねえの
ソースの向こうのハードウェアが実は核分裂制御装置でした！……とかでももう驚かねえよ 半分使って、半分継ぎ足しを繰り返すと79回目あたりで
アボガドロ定数の逆数くらいに薄まるよね 何か、酵母とか菌糸とか入ってて熟成されるんよ。ただ混ざるだけじゃないんよ。 >>194
> 型あったほうが便利派
半分くらいはインテリセンス目当てだと思うぞ。
そして俺自身も型を否定はしないが、C++の型検査も過剰気味だと感じている。
だからconstは使ってないし、関数ポインタの型検査もウザイ。
つーか、型を間違えること自体がほぼ無いだろ？
引数の順番を間違えたりした場合に型検査で引っかかるってだけで。 >>195
> ローカル関数で変数をキャプチャできるぞ
ローカル変数しかできんだろ。しかも明示しなければならない。(全指定も出来るが）
JavaScriptの場合は上位関数の変数をどこまでも辿れるので、（レキシカルスコープ）
入れ子になっていても破綻せずに分解して展開出来るんだよ。
C++方式の場合はawait内にawaitが入れ子になっていると、展開出来ないだろ。
> コールバックは階層が増えたりエラーや例外処理、分岐などが生じるとどんどん複雑になって単純には行かなくなる
> それを解決するのがPromiseで、それを更に単純に記述するのがasync/await
これは通説だが、俺はこれが嘘だと思ってるんだよね。
JavaScriptで言われているcallback地獄ってのは、非同期処理をその場で入れ子で書いている。
それよりawaitの方が見やすいってのは、上から順に読める形式だから。
でも>>180に書いたとおり、JavaScriptの文法ではcallbackを常に展開して書けるので、
その気になればawaitと同じ順で処理を書けるんだよ。（非同期がネストしない）
つまり、レキシカルスコープ＋クロージャなら、awaitが無くてもawaitと同じ順で処理を書けるわけ。
C#やC++はレキシカルスコープがないからawaitが必要なだけ。
だからここら辺は実は文法との相性もあるんだよ。
C++はそんなのお構いなしに何でもかんでも入れてる感じだが。
（とはいえ、選択肢が増えること自体は悪いことではない）
> char *を受け取る関数ポインタにとconst char*で受ける関数ポインタを入れてエラーにしなかったらややこしくて危険なだけでしょ
そりゃconstの有無をテストで落とすのは無理だろうさ。
まあ、俺はconst自体が意味無い（無駄な手間が増えるだけ）という認識だが。
（ただし本当の意味でのconst（「定数」）の場合は使う。Cならマクロで与えていたケースとか）
そもそも君はどこまでconstを使っているんだ？
C++のconstは「定数」ではなく「再代入禁止」だ。
現実的には無駄に再代入することもないので、ローカル変数の大半にconstを付けられるはず。
これをやっているのか？
やっていないのなら、君自身も「過剰な型検査」が存在することを認めていることになるが。 >>196
コードを流用するとね、
void test(a,b)
{
// (A)
hoge(&a,&b); // (B)
piyo(a+b); // (C)
}
で、(B)をconst指定にした時のみ(C)で大胆な最適化を行えるケースは、
・(B)が(C)に影響する副作用を持っていないと「const指定した時のみ」分かる
場合だけだが、これはconst指定ではどうにもならんだろ。
これはプログラマが上位の仕様（test関数の仕様）として規定するものであって。
例えば構造体配列で、(B)は[i]への書き込み、（C)は[j]からの読み出しで、i!=jが上位で保証されているとか。
この場合は、プログラマが最初から(A)(C)(B)の順に書けるんだよ。
そうではなくて、(B)が（C）に対しての副作用を持つ可能性がある場合、つまりi!=jが保証されていない場合、
当然(B)(C)の順にする必要があるけど、
これをconst指定で最適化(=(B)が(C)に対しての副作用を持たないことを保証）することは出来ないでしょ。 >>204
ん、C++のconstは、Cのconstよりも「定数」だぞ
int const a = 1;
switch(1) [
case a: ; //valid in C++, invalid in C
} case ラベルに const な変数の変数名
C++ ならばリテラルと等価となりセーフ
C は変数のままの扱いでアウト C++は使える範囲を広くしただけでconstの意味はCといっしょ
constによる最適化の話には関係しない 違う
constはもともとC++発祥のもので、
Cでパクるにあたり微妙に改変した
constは最適化に関係するが
今この流れでは最適化とは全く無関係の話をしている ttps://regmedia.co.uk/2011/02/18/dennis-richie-and-brian-kernighan-pdp-11.jpg
こういう時代の揮発性のメモリ
揮発しないメモリもあるんですよ コード中の文意では変わってなくても、他の要因で変わる可能性あるような
割り込みやマルチスレッド等で共有してる変数とか > C++のconstは「定数」ではなく「再代入禁止」だ
代入と初期化を混同してませんか 外からは見えないように、そして、なくさないようにするエロ本 一口にstaticと言っても、そのキーワードは用法で意味が変わるからなあ static に背負わせすぎな気がする
関数内変数の static
関数スコープ外の static
C++ ならばクラスメソッドのstatic
クラス変数の static もあったかな‥多すぎだ‥ ポインタ関連で*と&の記号を使っているのも
初心者を遠ざけているよな
素直にpointerとかrefとかの予約語作ればよかったのに >>225
もともと高級アセンブラとして生まれた経緯を考えたら、ポインタ関連の基本的な記述のためにはくどいキーワードではなく最もシンプルな演算子が割り当てられるのは自然なことだと思う。 >>225
C# の ref 宣言のように，宣言だけでなく呼び出し側でも ref が必要だという文法はあってもよかったかな >>228
ISO/IEC9899:1999
6.7.5.3 Function declarators (including prototypes)
21 EXAMPLE 5
void f(double a[restrict static 3][5]); 以下の三つの操作に違いはありますか
NはMと比べて十分大きいとします
char s[M];
wchar_t ws[N];
mbstate_t state = {0};
// 1
scanf("%s", s);
wbsrtowcs(ws, &s, N, &state);
// 2
scanf("%ls", ws);
// 3
wscanf(L"%ls", ws); >>231
1のscanf()はchar型で文字列を受け取ろうとするのでエンコードによっては複数バイト文字が全て読めない可能性がある。
例えば2バイトづつのUnicodeの0xff以下のコードがそのまま来た場合、ビッグエンディアンならすぐに0x00が1バイト目に来てしまう。 兄貴すいません
アロー演算子の使い方を学びたいのですがどこを直せば動くのか教えてください
#include <stdio.h>
struct User {
char name[5];
int age;
};
int main()
{
struct User *u = { "hoge", 10 };
if (u->hoge != NULL) {
printf("%d\n", 1);
} else {
printf("%d\n", 0);
}
return 0;
} >>233
*uじゃなくてsにてもしてuに&sを入れてhogeをnameに変えれば動くけど
これnameが実体だから100% 1が出るよね struct User {
char *name;
int age;
};
int main()
{
struct User st = { "hoge", 10 };
struct User *u = &st;
if (u->name != NULL) {
...... >>233
mallocして中身を詰める
#include <stdio.h>
#include <stdlib.h>
typedef struct{
char name[5];
int age;
}User;
User* new_user(const char* const name, const int age){
User* u = (User*)malloc(sizeof(User));
strcpy(u->name, name);
u->age = age;
return u;
}
int main(){
User* u = new_user("hoge", 10);
if (u->name != NULL) {
printf("%d\n", 1);
} else {
printf("%d\n", 0);
}
return 0;
} >>232
なるほど
ありがとうございます
fgets(s, M, stdin);
const char *p = s;
mbsrtowcs(ws, &p, N, &state);
でも1と同様の問題が起こりますか
>>231は関数名と実引数の型を間違えてました >233
int main(){
return !printf("%d\n",strlen( (&(struct User){.[0]name=0, .age=10, .name={'h','o','g','e'}})->name) 1: 0), 0;
}
char[5] nameとNULLの比較じゃ意味ねーと思うんだわ >>238
>>233のような初学者にそんな解読しにくいコードを提示しても意味ねーと思うんだわ 暇すぎたので昨日からC言語の勉強始めましたプログラミング初心者です。
これって趣味にできる？ 今本屋なんだけどどの本で学ぶのがいい？
てかphytonとか他の言語の方が良かったりする？ ちなみに本職は監査法人の公認会計士で監査してるんだけど仕事に役立つならそれに越したことはない 幅広くエロエロやると上達早いで
もしノイマン型コンピュータの基本知識が
無いのならどこかで学習する必要がある
メモリ、アキュムレーター、インデックスレジスタ…etc >>246
公認会計士の仕事にはなかなか結びつかないだろうけれども…ｶﾞﾝﾊﾞﾚ
C/C++ はどちらかというと原始的
python AI/機械学習で今はやり
ゴルフでもなんでも最初は大変だから一定の覚悟が必要 あんま知識は無い。
じゃあC言語とphytonを並行して学ぼうかしら。 会計ねえ。Excelとかの本のほうがいいかも知れんな。その方が仕事に結び付けられる事が多くて覚えは早いのではないかと思う。
マクロも一応プログラムだしな。Excelにくっついた形のものではあるが結構色々な事ができる。
で、それがある程度できるようになったらプログラムというものがだいたいどういうものかわかるようになってるだろうから次はVBのように似ているものをやる。
似ているのでこれの習得はかなり早いと思う。それから他の言語を色々やって幅を広げる。 Excelマクロ…
組むと疲れる、悪い癖が付く等良い所が無い言語 見易さではいまだ紙媒体の方が上だと思うし、惜しむほどの額でもないだろう 受信したメールの中身を理解して必要なメールと不必要なメールを分け、必要なメールの情報を分かりやすい文章に要約して表示するプログラムC言語で作れる？
ついでに簡単な返信なら自動でしてくれたらありがたいんだが。 返信が必要なメールと判断した場合は、返信メール本文の例を1万種類ぐらい自動で作成して、その中からより最適なものを3種類ぐらい提示してきてこっちはそれを選ぶだけで良いという機能も欲しいぞ >>257
それがついこの間デザインがリニューアルされたんだよ
内容は同じだけどｗ
前よりは見やすくなったかな りんなとやり取りするプログラム作って、りんなに判断してもらえ。返信内容も一緒に SMTP, POP3などのメールプロトコルで、メールサーバとソケット通信。
メールを分類するなら、自然言語処理とベイズ推定が必要。 単純な分類なら、振り分けルールが使えるメーラーを使えば簡単。 ヘッダーに書いてあるエンコードが嘘いってて中身は別コードを
なんとか帳尻合わして可視化する部分が厄介 （nkf で大分楽にはなるらしいけど） >>259
「必要なメール」とそれ以外の境界を
おまえさんが明確化できるか否かにかかっている
何言語を使おうが同じことだ
Cは推論エンジンそのものを作れる言語で
通信アプリやドライバを作れる言語でもあるので
諦めねばならないアイディアはまずないはず >>267
「必要なメール」とそれ以外の境界線はこれまで私自身が行ってきたメールへの対応を見てプログラム自ら学習して欲しい。
また分類や要約は高度な文脈、ニュアンス判断も伴うレベルで行わせたい。
それも様々な小説や文献を通してコンピュータ自ら学習して欲しい。
ちなみにこれ外注したらいくらぐらい？
10万円ぐらいするかな？ linuxでpop/smtpサーバー立てればよくね
スクリプトで特定のワードが見つかったら処理すればいいし
送信はmailコマンドがあるし >>268
自ら学習するにしても、教師なしでは低品質になる。効率よく学習するためには、コンピュータとの対話(ダイアログ)が必要になる。 深層学習させるにしても、タグ付けの作業が必要になる。 >>268
267だが、Cは推論エンジンを作れると言ったはず
おまえさん自身はそこから学習しなかったのか？
10万ねえ
支那の国家プロジェクトがどうなっているか知っているか？
支那からのSPAMに「天安門」と書いて返信すると我々にとって
ありがたい動作をしてくれるというアレだ
国家ではないが大企業のAIが共産党は無能とか言い出して
ひと騒ぎにもなったよなあ
おまえさんの10万円のソフトはおまえさんを無能とか
言い出さないか？ あとC言語でタイムマシン作れる？
といっても未来のインターネット閲覧できる程度でいいんだが。
作れる人いたら10万円までなら出すぜ。 >>274
予測・予想が届く範囲でないと、予知はできない。できたとしても、競馬の予想や天気予報くらいだ。物理法則を超えることはできない。 アホなことを書いてしまったと気付いて、ネタだったことにしてごまかそうとしている？ 物理法則なんて人間が考えたものに過ぎないからどうせ間違いだらけでしょ？ 深層学習で美少女の画像を大量に生成するという技術はある。未来の人が書きそうな絵を生成することはできる。 div B = 0
rot E = -(∂B/∂t)
div D = ρ
rot H = ∂D/∂t + j ■ このスレッドは過去ログ倉庫に格納されています
