C言語なら俺に聞け 162
レス数が900を超えています。1000を超えると表示できなくなるよ。
いまどきPlain Cが使われる状況なんて限定的なんだから
高級アセンブラとして堂々としてればいいんですよ リモートワーク制度が削減・廃止されたら「転職や別案件を探す」が4割--
「Offers」登録者調査
ITエンジニア/デザイナーの副業・転職サービス「Offers」を提供するoverflowは、
同社が運営する「Offersデジタル人材総研」にて「リモートワーク実態調査2023」
を公表した。
これによると、リモートワークになり、5人に1人が引っ越したと回答した。そのうち、
現職でリモートワーク制度が削減・廃止された場合、「転職や別案件を探す」という
回答が44.0%にものぼった。一方「会社と交渉する」という回答は40.0%、
「引っ越さず受け入れる」が12.0%となった。
さらにリモートワークを希望している理由として「通勤時間が無駄だと感じている」が
87.7%でトップとなった。このほか「個人の時間ができる」(62.3%)、「副業を続け
やすいから」(39.6%)、「子育てができる」(35.8%)と続いた。 前スレではちみつさんが書いてくれたリンク見ました。thx
https://go.dev/tour/flowcontrol/13
曰くGOの defer は
deferred function calls 遅延関数呼び出し で、関数脱出時にlast-in-fast 順で呼ぶもの
とすると、C言語でdeferの仕様追加要求は却下すべきです。リンクリスト1個作れば済む話で、実際そうしてる人も多数いるだろうに、既存プログラムでdeferというシンボルを使ってるのをコンパイル通らなくしてまで仕様追加するのは利益が小さすぎる。
エラー処理で使うかは、直接関係ないですね。そうしたきゃすればいいけど、私は読みやすいコードとは思わない、です >>8
>関数脱出時にlast-in-fast 順で呼ぶもの
>
>とすると、C言語でdeferの仕様追加要求は却下すべきです。
この「とすると」からの繋がりが意味不明。
>リンクリスト1個作れば済む話で、
だから何?
「却下 *すべき*」の理由になってない。
採用するほどでない、なら理解できる。
> 既存プログラムでdeferというシンボルを使ってるのをコンパイル通らなくしてまで仕様追加するのは利益が小さすぎる。
ここでのdeferは機能についての名称として使ってるだけで、そのままの文言じゃないことを理解できてないみたいだ。 >>9
話が通じてないと思います
C言語の建設的な議論なら応じたいけど >>8
どうせコンパイルオプションで無効にすれば使えるだろ >>10
おまえの感想 >>8 のどこが建設的な議論よ? deferは(素のものをじゃなくてもう少し高機能な)プリプロセッサで対応出来る
breakやreturnの直前にdeferの内容を全部コピーしとけばいいだけ
まぁそれ言い出すと、C++をCに変換するプリプロセッサが有れば全て解決だがなw ただのどこかのオッサンの意見が気に食わんなら別にそれでもいいよ…
各自自分の考えを語ればいいじゃん、そんな食いつくくらいならなんか一つくらいは「自分のアイデア」あるんでしょ?何もないの? >>13
既存の「正しいプログラム」が「正しいプログラムであり続ける」
そんなにおかしいことかね 既に進行中の「建設的な議論」をご用意しました
以降の議論はこれを前提として積み重ねていただくようお願い申し上げます
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htm 既に進行中の「建設的な議論」をご用意しました
以降の議論はこれを前提として積み重ねていただくようお願い申し上げます
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htm >>19
なんか、機能はともかく見た目はだいぶ汚いコードになるね >>17
全然おかしく無いよ。
互換性は非常に重要。
でもおまえは新しい機能は追加するなって言ってるだけだよね。
おまえの言い分だとプロトタイプ宣言必須になるのは、過去の「正しいプログラム」が正しくあり続けることできないから「却下すべき」案なんだよな。 >>21
プロトタイプ宣言とK&Rスタイルの関数定義がごっちゃになってるわ。
>>21 は回線切って首吊れば。 >>19
俺はGOで組んだことないからそこに書かれてる処理系依存のtry/finallyのが馴染みがあるしスマートに見えるわ
キモい輩って世界中に居るんだな 21 と 22 のワッチョイとIDが同じで表現が口汚いのはどう解釈したらいいの?私には難しくて分かりませぬ いつもの復オジωωω
スルー決定ωωωωωωωωω 容認→警告→禁止推奨
となった仕様が幾つあったか・・・。 言語の設計思想と立ち位置考えれば手を入れる必要ないでしょ
細かいのはあるにしても関数プロトタイプの導入、データ型の追加、stdioのセキュリティ強化くらいでCとしては充分
構文追加とかバカすぎてANSI Cもまず取り込まんよw >>28
>細かいのはあるにしても関数プロトタイプの導入、データ型の追加、stdioのセキュリティ強化くらいでCとしては充分
その挙げ句MISRA-Cみたいなのがでてくる。
>構文追加とかバカすぎてANSI Cもまず取り込まんよw
C23の属性とか知らんの? c23だと属性以外にも
enum Colour : char {
Red,
Green,
Blue
};
とか
auto i = 123L;
とかも構文変更になる
constexprもコンパイラにとってはかなり大きい
文字列のハッシュ値の計算とか、コンパイル時にCのコードを実行できる clangとかはconstexprを使わなくても、最適化で勝手に整数に置き換わってるとか普通に有るけどねw
constexprはそれを確実に保証出来るので、精神衛生上良い >>30
C23 の constexpr は関数には付けられない。
高度なコンパイル時計算をするものではない。 >>32
なるほど!ちょっと中途半端な状態なんだな… C++ の const 指定は初期化子が定数 (定数式) なら指定が付けられた変数も定数になるという規則なんだが
C の const は単に書き換えが禁止されるだけで定数になることはない。
(処理系の拡張によって一部の状況で定数扱いされることはある。)
C で定数を作ろうとすると #define を使うか enum を使うかしかなかったので
定数を定義するための直接的な方法として constexpr を導入しようという判断は納得できる。
定数を定義するまともな方法がないってのは C の明らかな欠陥なので
それを改善するという話でしかなくて、
コンパイル時計算を推進する野心の始まりってわけではないと思う。
なので constexpr については (遠い将来はともかく現時点では) これで完了。
中途半端ってこたぁないというのが私の感覚だな。 書き換えが禁止されても定数ではないとはこれいかに…
ここでいう定数はコードに直接埋め込まれる値ということだろう
ただ、C++もstatic constにしないと定数にならないと思ったけど、 constだけだとちゃんとメモリが確保されてると認識してたな 言語仕様上の用語としては定数は定数が要求される箇所に書くことが出来るもののことだよ。
単純な例で言えば、↓これは C++ ではアリだが C ではダメ。 (clang のデフォルトだと通してしまったりもするようだが……。)
const int foo = 1;
enum bar {baz = foo};
int main(void){}
もちろん最適化によって効率的な扱いがされやすくなることも多いにせよ、直接には求められてない。
定数であってもアドレス演算子は適用が可能だし、あくまでも変数なので見かけ上はメモリ上にある。
C++ で static const にしないと定数にならないというのはデータメンバのとき。
普通のデータメンバはオブジェクトを生成するときまで初期化されていないことになっているので
コンパイル時には確定できない。 const int foo = 1;
char hoge[foo];
int main(void){} 2-pass コンパイルを実装してほしい
struct Fuga;
struct Hoge {
struct Fuga *fuga;
};
struct Fuga {
...
こんなのとはおさらばしたい そういう配列宣言でdefine使わないとどういうメリットがあるの? もしかしてそれって、C言語の仕様じゃなくてデバッガとかビルドシステム側の機能改善でできそうって気がしませんか?
デバッガが読んで参考にできるかもしれない情報の豊富さの、なんとなくの並び
↓
■実行形式にシンボル情報がない
■実行形式にシンボル情報がある
■ソースコードがあるけどデバッガはビルド情報知らない
■ソースコードがありデバッガがビルドの情報も知ってる
clang とかLLVM界隈ってそういう情報(どういう?ビルド時しか分からん情報というか?)をうまく使おうぜ方向を目指してる気がします、知らんけど その例だとデバッグ時に数字で表示されたほうが安全じゃないか >ソースコードがありデバッガがビルドの情報も知ってる
両方持ってるのは本物のプロと練習集の初心者素人と両極端に分かれそう >>42
当然だけど規格の話じゃないよ
気がしませんかっていうかコンパイラとデバッガは何十年も前からそうやって連携してる >>43
数字で表示されないと具体的に何が非安全だと心配してるの? 次に実行するコード
>hoge[2] = 0;
となった時に
char hoge[foo];
と表示されてると次にfooの値を探すので二度手間
char hoge[1];
と表示されてれば一度ですむ >>49
何のためにシンボル使うのかわかってないな。
実際の値と値の持つ意味について考えたほうがいいぞ。 哲学には興味ない
なんのためにデバッガ使うかわかっているので充分だ >>51
なんだ実際のデバッガ使ったことないのか。
普通はシンボルだけじゃなくて値も表示するんだが。 ずいぶん安い煽りに転じたな
表示される情報は最小限のほうがいいんだよ
仕事で使っていればそうなる 自分はデバッガ使う段階なら定数は具体値が出てくれた方がいいです
クロスコンパイル環境の構築からとか、Cならではの現場を辿って来た人と、今どきのGUIのデバッガが前提の人では話は合わなそう
マウスかざせば済むじゃんと思ってるのでは >>43にアンカうったら>>49で手間がどうこうって返ってきたんだがそういうのを安全って言うのか??
個人的には>>52と同感でマクロにしてもenumにしてもシンボル・値両方確認出来るもんだと思ってたから
どんな環境を想定して言ってるのかちょっとよく話が掴めないな gdbなどのデバッガー使っていれば変数名と型と値は全て表示される
必要であれば配列は全ての要素を展開して表示も出来るけどな シンボルの方が意味が判って良いけどな
「マウスかざせば良い」はその通り
場合によっては watch 式 デバッガもその設計思想によるだろう。
ソースレベルデバッグなら言語の評価モデルに一致するのが自然だと思う。
そうなるとシンボルのほうが主役で、評価されれば値になるし一部は事前にわかる場合もある。
バイナリ寄りのデバッガなら
シンボル情報 (デバッグ情報) を扱えるものであってもまずそこにあるのは具体的な値であって、
値のほうをメインに見せる (シンボルは補助的な情報) のが筋に思える。 >>53
お前はアドレスさえわかれば関数名も変数名も不要なんだろうな。
俺はソースレベルデバッグを想定してたけどお前は違うの? >>54
Cのソースレベルデバッガはgdbとそのラッパー(dddとかKDEのkdebug)しか使ったこと無いな。
お前は何使うの?gdb以外のデバッガにはちょっと興味あるかも。
あと、いつのまにかデバッグの話にすり変わってるけど、元は >>40 で *コード書くとき* の話だからな。
>>41 のせいだな。 Cは単純だからぽいんた辺りで躓かない限り特に疑問は生まれずスーっと大脳皮質に浸透していく
それに比べて自称モダン言語の気持ち悪さよ
Cが無かったらプログラミングなんてやってなかったろうな Cの関数ポインタはそれ以上でもそれ以下でもない
セキュリティが緩い頃は関数ポインタを駆使すれば関数型言語で言う所の関数のファーストクラスも実現できた
この時やはりコードとデータは分かれているべきと判りみ
と同時にオブジェクト指向は間違った思想と気付く C++になると更にきしょいメンバ関数ポインタがあるが #include <iostream>
using namespace std;
struct Hoge {
int hage_;
int mage () const {return hage_;}
};
void func (const Hoge &obj, int (Hoge::*func) () const) {
cout << (obj.*func) () << '\n';
}
int main () {
void (*f) (const Hoge &, int (Hoge::*) () const) {&func};
Hoge hoge {10};
(*f) (hoge, &Hoge::mage);
return 0;
}
きめぇ >>59 とか
>>60 の後者の人とかは
ゲーマーか逆アセか改造チートでもしてんのかなと思う 定数はともかく変数の値の変化を監視するとなれば話は変わりますよ >>66
単に機種依存なくしてユニバーサル化したアセンブラだからキモいも何もない
感覚的に受け付けないという方はもうすぐAIで自然言語でプログラムできるようになるからそれまで待てばいいじゃん >>70
こう描けばそこまでキモくない
#include <iostream>
using namespace std;
struct Hoge {
int hage_;
int mage () const {return hage_;}
};
void func (const Hoge &obj, int (Hoge::*p) () const) {
cout << (obj.*p)() << '\n';
}
int main () {
void (*f) (const Hoge &obj, int (Hoge::*p) () const) = func;
Hoge hoge {10};
f(hoge, &Hoge::mage);
return 0;
} >>80
アホ!
1レスくらい間にはさまないとリアリティが出ないだろw >はじめてのC
数十年前からの定番ネタだよね・・・今の中年向けの・・・。 >>94
音階に倣って「イロハ」だったりするのかな。
プログラミング言語ハとか、ハ++とか、ハ長調とか。 Cの関数ポインタに慣れてしまってたんなに奇天烈に見えてたのに今じゃ可愛く見える ∧__∧
(´∀`)
(⊃⌒*⌒⊂)
/_ノωヽ_) 左辺値と右辺値のことがよくわからない
char *cp = "abcdefgの"abcdefg"は値を変更できないのに、
char cp[] = "abcdefg"の"abcdefg"は値を変更できる >>100
それは左辺値/右辺値とは関係ない。
「リテラルを書き換えようとしたら未定義」というルールが関与してる。
前者の場合は文字列の場所を示すアドレスが cp に格納されているので
cp が指す先というのは文字列リテラルだが
後者の場合は確保された配列を初期化子の文字列で初期化するという理屈なので
配列と文字列リテラルとは別の実体を持ち、リテラルではない配列を書き換えることは問題にならない。
初期化子として文字列が出てくるときは初期化の文法としてちょっと特例があるのと
(文字列を含む) 配列は暗黙の型変換で勝手にポインタに変換される特例があって
そういう変則的なルールの積み重ねが分かり難い要因だと思う。
リテラルは書き換えたら駄目なのに型の上では文字列リテラルに const はつかない (C++ では const が付く) ので
ごく単純な場合を除くと書き換えをコンパイラがコンパイル時にエラーとして検出できないこともある。
なるべく (前後の事情によっては出来ないこともあるけど) 変数には const を付けておくのが良い作法だと思う。
const char *cp = "abcdefg"; char *cpa = "abcdefg;
char cpb[] = cpa; // 出来ない
char cpc[] = "abcdefg";
char *cpd = cpc; // 出来る & abcdefgの中身も描き替え出来る 「大前提で文字列リテラルは書き換えたらダメ」があって
初期化と代入が同じ記号の = で行われてる
配列での代入操作は暗黙で先頭のポインタを渡す一方で
配列の初期化はあたかも複製をとったような形になる
ここらへんにややこしさがあってめぐりめぐって1行目にヒットする >>101 ご親切にありがとうございます。標準的な本にもかいてあることを聞いてしまいました。 ポインタと配列(の先頭番地)は同じように使えるがまったく別のもの
>>102の例だとsizeof(cpc)は8で
sizeof(cpa)はポインターサイズ "abcdefg"[2] = 'C'; これがNG >ポインタと配列(の先頭番地)は同じように使えるがまったく別のもの
まったく別と言い切ってしまうのはちょっと語弊があるように思う
言い換えれば配列はアドレスが変更できないポインタとみなせる
後は参照先のメモリ領域が書き換え可能かそうでないかの違いでしかない 配列名は単に文字列が格納されている場所に付けられたラベル >>108
上で触れられているようにサイズ情報も持ってる >>109
それは別に配列だからってわけじゃない。 配列の型は配列型だ。
char cpc[] = "abcdefg";
とあればこのときの cpc の型は char[8] をもつ。
式中に配列型の式が現れた場合には sizeof か & のオペランドであった場合を除いてその配列の先頭要素を指すポインタ (この場合は char*) に暗黙に型変換される。
変換が適用されればポインタだし、適用されない場面では配列。
配列自体は左辺値だが変更できる左辺値 (modifiable lvalue) ではないので代入演算子の左辺に現れることはできない。
配列を型変換を適用して出来るポインタは左辺値ではないのでやっぱり代入することは出来ない。 型の話って、実は結構難しいというか深いよね…
型を認識するプログラム作ってみるとわかるんだけど
「~のポインタである」と
「~の配列である」を同じ情報量では扱えなくて
「~の配列(要素数n)である」としないとだめなの
ポインタである ことは1ビットで保持できるのに、配列である は要素数があるから必要なビット数がやたら多いのよ ((char*)cpc)++ で cpc[0] が 'b' を指すように移動できるの?
これがポインタが左辺値になってるって意味の理解でOK? アセンブラで考えるとよくわかる
cpa:
.dw cpa_static
cpa_static:
.db 'abcdef',0
cpc:
db 'abcdef',0
こんな感じになるだろう
cpaをインクリメントするのが可能だがcpcをインクリメントするのは無理なのがわかるだろう
cpcはアセンブル後には値がなくなる固定値でcpaは領域が確保されてる変数だから >((char*)cpc)++
こんな風な事をしたいなら、
*(char*)cpc+i
これでどうだろうか
cpcは固定値で、加算も減算も出来ないが、その位置からのオフセットならとれる
でも、ふつうの人は cpc[i] こうするだろう >>114
代入可能であるためには左辺値であることは必要条件なのだけれど十分条件ではない。
配列が代入の対象になりえないにも関わらず
(modifiable という概念を導入してまで) 左辺値という扱いにしていることからもわかるように、
代入できるかどうかで左辺値かどうかは語れない。
左辺値でも代入できないことはある。
右辺値はどこかに代入しない限り捨てられる (その式を超える寿命を持つことはない) という性質があるので
逆にそうでないものは左辺値という扱いにしないと辻褄が合わないからこうなってるんだと思う。 >>112
>>118で「配列が代入の対象になりえないにも関わらず」なんて言い方してるくらいだから
多分左辺値とか右辺値がなんなのかよく分かってないんだろう
まあいつも規約をだらだら載せてるだけだけのコテだしね 左辺値かどうかの簡単な切り分けだと思っただけで
そういう欲求はない >>111 正確には、配列名のことをいっているんでしょ? 何を言ってるのだかわからん。
代入演算子の左辺に配列が現れることは出来ないという説明
に納得いかない (できる状況があると思っている) ということ? 代入可能な左辺値一覧
○…代入可能な左辺値
×…代入可能な左辺値ではない
1 変数に代入 v=x ○
2 変数のアドレスに代入 &v=x ×
3 配列に代入 a[i]=x ○
4 配列の名前に代入(2に相当) a=x ×
5 ポインタ変数に代入 p=x ○
5 ポインタ変数のアドレスに代入 &p=x ×
7 ポインタ変数の参照先に代入 *p=x ○ ただし参照先が書き込み可能でなければランタイムエラー
理解できたかね? >>126 まだまだ浅学な者で、3と4の違いが分かれば十分です char ss[5];
char *p;
p = ss; 〇
p = &ss[0]; 〇
ss = p; ×
p = ss + 2; 〇
p = &ss[2]; 〇 配列 a があるとき
a[i]=x
という式の左辺は配列に添字演算子を適用したもの (配列の要素) であって
これのことを「配列に代入」と呼ぶと語弊がある。 しかし、食べたらまずそうなコテハンですね('_') 最初はSCHEME餃子と名乗ってたけどSCHEMEスレが過疎ってて暇だから
CスレC++スレにも書く機会が多くて途中で変えた。
私としてはあり得なさそうな組み合わせの語を選んだつもりだったのだけど
はちみつを使った餃子のレシピはあるみたいだよ。 配列には確かに構造体のようにごっそり代入できませんね 126 の表現を借りるなら
3 は配列の要素に代入
4 が配列に代入
こういう意識だわ 結局てめーの日本語が気に食わないって話かよ
長文は読む気が失せるわー 「配列は」という話をしているときに配列でなくする操作 (要素に対するアクセス) をすれば出来るみたいな話と混同されると困る。 初心者のころ
char text[] = "Answer is _";
text[10] = 'A' + ans;
とか書こうとしてうろおぼえで
char *text = "Answer is _";
text[10] = 'A' + ans;
としたらエラーかワーニングになって
なんでできないんだよ!とずっと悩んでいたことがあるが
そういう話じゃないの? char a[] = "A";
char *p = a;
は別物(同じだと説明している入門書があるならクソ本)
&a[0] を a と省略出来るだけ
もちろん sizeof p と sizeof a[0] と sizeof a は違う >>139
もう少しで完全に理解できそうなので
ガンダムで例えてくれ > &a[0] を a と省略出来るだけ
意味が同じなわけなので記法の上では省略と言えるんだけど
a が &a[0] のことを意味しているというわけではなく、
言語仕様上の理屈としては a のほうにプリミティブな定義があって &a[0] のほうが構文糖という扱い。
@ E1[E2] は (*((E1)+(E2))) と等価である
A & のオペランドが単項*演算子の結果の場合,*演算子も&演算子も評価せずに両演算子とも取り除いた場合と同じ
(添字演算子の適用結果をオペランドとする場合も同様)
B 配列 (結果が配列型となるような式) は sizeof か & のオペランドであるときを除いて先頭要素を指すポインタに変換される
つまり &a[0] の場合を順番に当てはめるとまず &*(a+0) と同等と見做され、
&* は無かったことにされるので a+0 となり、 0 を足しても内容は変化しないから無視できて a と同じ。
そして a は配列の先頭要素を指すポインタに変換される。 (順序から言うと配列がポインタに変換されるほうが先だな……。 すまぬ) 配列 a は a と書くだけで先頭要素を指すポインタなので
&a[0] と書くってのは 0 を足すという要らんことをしているという扱いってこと。 >>140
pがザビ家でaがジオン公国そのものと言ったら判りやすいだろうか
ジオンはザビ家にNTRれたけど元のジオン・ダイクンが掲げた思想(長さとか)はNTRが完了した時点で失われた
その後出てきたアクシズ(ネオ・ジオン)はもっと酷くてジオンと言える部分はNTRしたザビ家の跡取りとその傀儡だけでジオンとは一体何だったのか語れる人物は一人もいない >>143
そっちのほうが余計なギミックじゃない?
a[]のアドレスが欲しければ&aと書くだけでいいのに
aが自動的にa[]の先頭番地になってしまうからややこしい
ちなみにBASICだと配列と同名の単純変数が作れてしまいこれも今思うと無茶苦茶だった 完全に理解した!!!
↓
https://ideone.com/g2912A
#include <stdio.h>
#define N 3
int main(int argc, char **argv)
{
char *hoge[] = {"abcd", "efg"};
char **hige = hoge;
char hage[][N] = {"ab", "cd", "ef", "gh"};
char (*fuga)[N] = hage;
char (*moga)[N] = {"ab", "cd", "ef", "gh"};
printf("%zd %s %s\n", sizeof(hoge), hoge[0], hoge[1]);
printf("%zd %s %s\n", sizeof(hige), hige[0], hige[1]);
printf("%zd %s %s %s %s\n", sizeof(hage), hage[0], hage[1], hage[2], hage[3]);
printf("%zd %s %s %s %s\n", sizeof(fuga), fuga[0], fuga[1], fuga[2], fuga[3]);
printf("%zd %s %s %s %s\n", sizeof(moga), moga[0], moga[1], moga[2], moga[3]);
return 0;
}
↓
説明してみ >>145
あくまでも言語仕様の理屈で言えばこうだという説明なのでその言語仕様が良いかどうかの意見は含んでないよ。
色々とアレな部分も多いってのは文句つけても仕方がないいまさらな話だし。 いやいや何を言っとんの?
利便性のためにそういう仕様にしてるんだよ
C書いてりゃさすがに分かんだろうよw 感覚的にはそんなに不自然には感じないんだけど
仕様の規則が変則的なのも確かなので
つまりは人間の感覚は不合理なものってことだ。 >>147
%zd は知らなかったわ。 勉強になった sizeof の結果の型は size_t で、
size_t は符号なし整数というだけしか規定されていない処理系定義なんだけど
unsigned int や unsigned long int の別名として定義されていることが多いせいで
それをあてにした形で説明している資料は割とある。 >>145
> a[]のアドレスが欲しければ&aと書くだけでいいのに
俺はそっちのほうがややこしいと思うけどな
むしろ*(a+10) を [] で表現するなら *a[10] みたいな書き方になるほうが、理解する上ではややこしくなかったかなとは思うけど(使う上では不便)
[] って箱(マス)に見えるし、まあ直接箱の中身を示すものなのだなって覚えたけど 誰が誰なのかよく分からんけど、キッズが来て荒れた、という話ですか
インデックスアドレッシングを [ ] 記号に当てただけと思うけど、そんなに難しいかね 型の話かと思ってたら、いつの間にか 入門者がポインタを理解できない話 になった印象 >>145
配列 a に &a としたときに得られるのは配列を指すポインタであって配列の先頭要素を指すポインタではない。
(型が違う。 アドレスを数値として見たら同じはずだけど。)
多次元配列にアクセスするとき (添字演算子を重ねて適用するとき) に仕様の通りに解釈していくと配列と先頭要素が都合よく切り替わって最終的にポインタ演算になるのが実に上手いこと出来てる。
配列の要素にアクセスするときの記法を現状のような形にするという前提でならなんだかんだでよく出来ている。
配列に & を付けたら配列を指すポインタになるというのは例外的ではない普通の挙動だからそこに別の意味を割り当てるならそれもやっぱり変則的なややこしい挙動ってことになってしまうよ。 >>157
ポインタ完全制覇でよーく理解できました。
20年以上やってきて配列へのポインタは一度だけ出番がありました。 >>158
プログラマが直接的に書く機会はあんまりないだろうけど、
暗黙には頻繁に表れていてこのルールがないと上手いこと機能しないって話。
#include <stdio.h>
int main(void) {
int foo[2][3] = {
{1, 2, 3},
{4, 5, 6}};
printf("%d\n", foo[1][2]); // ふたつの座標みたいに見えるけど
// 式を各段階に分解すると……
int(*bar)[3] = foo; // 配列を指すポインタは出てきてる!
int *baz = bar[1];
int qux = baz[2];
printf("%d\n", qux);
} c言語初心者です
質問させてください
FILE *fpという宣言の「FILE」にどういった役割があるのでしょうか
*fpは関数によってどこを読み書きするかを指定するためにアドレスを格納することは分かるのですが
それならばint型のポインタで良いような気もします
プログラムを書く上でどうでもいい内容なのですが教えていただければ今日の寝付きが良くなる気がします >>160
stdio.h の中身を見れば FILE がどう宣言されているか分かるのでは? >>160 FILE構造体っていうことだけは、どの本にも書いてある。 実際UNIXのfile descriptorはintでWindowsのファイルハンドルHANDLEはvoid*だ。
こいつらはシステムコールによってカーネルモードで操作されるから中身が完全に見えないようになってる
それとは違って標準Cライブラリはユーザモードで動作するから
処理系依存で中身を操作してもいいように作ったのかもしれない >>160
確かに構造体の中身を使わないかぎり何のポインタでもいいんだけど
間違えて他のタイプへのポインタと混同した時にエラーが出るから気づきやすい
それはけっこう重要だよ >>160です
普通の構造体の宣言とは異なり要素の記述はありませんが
「FILE」とは「ファイル構造体を使うよ」と宣言しているという意味で
そうしてstdio.h上のFILE構造体の要素に開いたファイルの情報が代入されていくということでしょうか?
「FILE」を記述せずにfopenで開こうとした場合構造体メンバのptrに代入されている数値が使えないのでfopenから戻り値が受け取れず正しく*fpに座標が代入されない
みたいな
そして開くだけならfopenでも開けてしまうとか 言語仕様的に見れば FILE はストリームを制御するのに十分な情報が入ったオブジェクト型であることと、
アドレス (FILE 型のオブジェクトがある場所) に意味がある場合もあるから
オブジェクトをコピーして機能するとは限らないという程度のことしか書いてない。
FILE にどのような情報が格納されているのかといったことや
詳細な仕組みはホスト環境の事情に合わせて処理系の裁量で決めてよい部分なので、
具体的にどうなっているのかは各実行環境・開発環境ごとに違う。
特に環境依存の細かい部分に立ち入って制御をしたい事情があるのでない限りは
fopen が「なんらかの方法」で FILE 構造体を構築してそのアドレスを返すものであるということだけ知っていれば
普通のプログラマにとって十分なように出来ている。 >>165
3行目から4行目の理解で大体あってるよ
それ以降は何言ってんのか分かんねーから全部アタマの中から破棄していいよ
正確にはFILEってのは抽象データ型であんたは構造体って言ってるけど構造体かどうかは分からんし使う側は知る必要もない
提供者がわざわざ抽象型にして使い手側の負荷を下げてくれるとこを中身がどうとか役割がどうとかさぐんのは筋が悪いんだよ
使えって言われてんだから何も考えずにだまって使えばいいよ FILE構造体ってOS毎に変わるし、コンパイラ実装でも又変わってた様な気がする FILE*経由だとバッファリングされるから、バッファーのポインタとそこに含まれてるデータサイズも含んでいるだろう
そもそもファイルのシーク位置も含まれてる
まとめると
・ファイルディスクリプターやファイルハンドル
・シーク位置
・バッファー(ポインタ、サイズ、含まれてるデータサイズ)
となるかね >>160
void *hoge = (void *)fopen("hoge", "wb");
fprintf((FILE *)hoge, "hoge\n");
fclose((FILE *)hoge); FILE*互換の自前のストリームを実装できれば便利なんだがなぁ
継承が無いから、構造体に自前の関数をセットして、何らかの登録関数に渡す感じになるだろう パイプのインターフェイスをストリームとして開くことが出来るから
適当なスレッドを開いてパイプの受け取り口で受け取った情報を好きなように加工するようにすれば、
パイプに書込む側ではストリームに書き込んだらいい感じに処理してくれるように見える。
というのを Windows でやっているのをどっかで見た。 >>165
開くだけで何が楽しいんだ?
読み取りも書き込みもクローズもできない
exitで自動的にクローズはされるけど…
>>163
HANDLEはポインタではなくただの整理券番号で実体は整数値だ
しかしWindows SDKでは「架空の構造体へのポインタ」として定義されているので例えばウィンドウハンドルをファイルハンドルと混同するとType mismatchエラーになる
これはかなり有用な仕組みでC言語が仕様に組み込んでほしいくらい ソケットディスクリプタってファイルポインタに転生できる? >>160です
皆さん大変参考になりました
今日はよく眠れそうです free(NULL) は許されるのに
fclose(NULL) は許されないんよな >>180
さらにfflush(NULL)は許されるという一貫性の無さ fflush の場合は全てのストリームを対象とするという特別なフラグとして NULL を活用しているので無効なポインタとしての NULL とは事情が違う気がするね。
それにしたってNULL を多義的に使っているという意味では一貫性はないけど。 free(NULL)は、おバカなマの為に特別に許容したんだろ 以前ネットでおすすめされていた「苦しんで学ぶc言語」の内容をしっかり理解する段階まできたのですが、次は何をすれば良いのでしょう。
猫でも分かるプログラミングも読んでみたのですが仕様が古すぎてトレースできないのと、私には作者さんの文章の作りが合わず困っています。
まずは簡単なソフトを作りながら学べればと思います。
入門書の次に読めるような本と、そこからアプリケーション開発のイロハが分かる本やサイトを教えていただけないでしょうか。 ↑みたいなのって目的ないのかね
今後C言語で特に何かやりたい事がないなら別に何もする必要ないよ Cで現実的なアプリケーションを作るならホスト環境 (OS など) の事情は無視できないし、具体的な目標なく道筋は決まらないと私も思う。
何の情報もない他人に何かを勧めるというのはしづらい。
目標があるならその分野の既存のコードを「読む」という体験はためになるかもしれない。
実際のコードを見て意味がわからない部分があれば学習が必要な部分だというとっかかりになる。 >>184
> 「苦しんで学ぶc言語」
というのは、これ↓ ?
https://9cguide.appspot.com/index.html
> 苦しんで覚えるC言語
であれば文法解説のようなので、ファイル操作をしてはどう?
cat コマンドを作るとか。 >>186
Windowsソフトを制作して当方の業務を効率化できればと考えています。
「既存コード」を読むですか、なんだか英語学酒のようで気が滅入りますね>
>>187
失礼しました。「覚える」でしたか。
ファイル操作がどこまでを指すのかわかりませんが高低水準入出力はすでに可能です。 業務効率の向上が目的ならC言語は回り道すぎる
他の言語選んだ方がいい気がする ファイル操作の課題出してあげようか
指定した二つのDirにあるファイルを同期させる
単にコピーするのではなく、タイムスタンプの新しいものだけをコピーする
新しいSubdirできていたら、中味があればDirごとコピーする
とりあえずは、新しく作られてファイルの同期まで、
削除については考慮しなくて良い >>188
>Windowsソフトを制作して当方の業務を効率化できればと考えています。
早速これに取り組んだ方が良い
実用するものを作る方がモチベになる C言語のスレッドで言う事じゃないがC言語以外の生産性の高い言語を学んだほうがよさそう >>184
CはOSのAPIを直接叩けることがメリットでもあるので、Linuxのプログラミング本を読んでコード書いてみるのが一番良いだろう
マルチプロセス、マルチスレッド、ソケットとか覚えるべき事は沢山ある
Cでやれば根本から理解出来る (事務作業などの?) 業務効率化が目的なら Power Automate Desktop の活用を考えた方がいいと思う。
効率化の最初の段階は解決すべき問題を見つけることで、これをきちんと一度で洗い出すのは大抵の場合に出来ない。
雑に作って運用しながら改善するという手順をとるのがのぞましいが、 C で書くとそういう柔軟な体制がとりづらい。 「なにを作りたいのかが大事」ってのは良く分かるんだけど、普通の人が作りたいものって大抵Cじゃない方が…ってなっちゃうんだよな >>90
そういった事もできるんですねー
>>191
取り組みたいのは山々なのですがuiの作り方からわからないので入手できるバーションで解説されている書籍が欲しいところです。
>>192
基礎を大切にしたいのでcをはじめのうちは使っていきたいと考えています。
>>193
仰る通り根本を理解できればと思います。Linux本ですね。可能であれば簡単なものでおすすめを添えていただけないでしょうか。
>>194
グラフィック系のソフトを使う上で不便なところを楽したい、と言いますか
とにかく画像表示や文字列表示から進めていきたいと考えています。
前述の通り基礎を理解したいので可能であればcで作成したいのです。 WindowsアプリならCじゃくて、せめてC++にしておけ Cで全部書いてると大変だと思うよ
機能全部使わんでも良いからC++の方が現実的だよ >>196
自分はUNIX Cプログラミング(いわゆるライオン本)で勉強して、めちゃくちゃ為になったけど、さすがにこれは古すぎる
詳解UNIXプログラミング 第3版は間違いのない名著
ふつうのLinuxプログラミング 第2版はLinux向けだし初心者向け
Cで仕事をするようにはならないかもだけど、「ふつうの~」を理解出来て自分のものにすることがCを学ぶ意義だな >グラフィック系のソフトを使う上で不便なところを楽したい
ソフト側でスクリプト等がサポートされてなければ
できることは連続するショートカットを 1プッシュでまとめて出す
キーロガー&再生系とか Joy2Key みたいなキーコード送出系ぐらいしか思い浮かばん >>196
具体的に対象になってるソフトの名前は言える?
モダンな設計の Windows 用ソフトが外部から制御するために公開するインターフェイスは
Component Object Model の技術をベースにしていることが多くて、
高度な開発環境の補助を得ながら使う分には便利なんだが
C から使おうとするとすごく面倒くさい。 (出来なくはないけど。)
ソフトが外部に対してインターフェイスを公開するのではなく
制御用のスクリプト言語を内蔵している場合もあるので
C でのプログラミングに詳しくなってもあまり役に立たないこともある。
もしも外部に対してインターフェイスを用意していないなら
ボタン操作のイベントを発生させるとかして制御する (つまりまさに人がする操作を代行させる) ということも可能だが、
それを可能にするような基礎技術というか Windows の動作モデルを理解したいのなら
「猫でもわかるWindowsプログラミング」はそれなりに有用だと思うよ。
私は書籍を読んだことは無いけどウェブ版は Windows がイベントを伝播させて操作させる構造を理解するのに十分な記述はある。
だけど、人が操作するときに Windows の中で何が起こっているのかを
初心者が根本から理解してきちんと使いこなせるまでになるハードルは割と高めなんだよ……。
Power Automate Desktop なら技術の根本を理解せずともそれが出来るようになってるし、
マイクロソフトが直接に提供していてしかも無料という神ソフトなのでオススメした次第。
UWSC とか AutoIt なんかも人気があるね。 関数のサイズというのは、関数の引数のサイズと同じと考えて良いのでしょうか?
中身に1万行使ってる関数があるとして、その1万行は関数のサイズとは全然関係ないんでしょうか?
構造体はなんとなく変数のバイト数の足し算なんだなってわかるけど、関数がピンとこないです・・・ プリプロセッサメタプログラミングを覚えてからc言語の開発は楽になったわ
前は同じようなデータ構造でたくさんモジュール作ってたからな >>206
関数をデータとして扱うことはないので「大きさ」は定義されない。
C の言語仕様的には「関数はオブジェクトではない」という扱い。
関数に対して呼び出し以外の操作をする方法はない。
関数ポインタで関数の場所を指すということは出来るが、
型システム的にちょっと特殊な扱いになっていて関数ポインタ経由で値を取り出したりも出来ない。
もちろん実際にはなんらかの形でメモリ上には存在するし、
長いプログラムは大きい可能性が高いけど。
実際にどうなってるのかは生成された機械語を見ればいいんでね。 >>206
質問文が謎すぎて、何を聞きたいのか解釈できない
関数のサイズって言ってるのがビルドしてできた実行ファイルのファイルサイズの事なら、コードの量が多ければ当然サイズは大きくなる >>208
ポインタのアクセス条件でメモリのサイズ・型が明確になっていること
とあったので、関数ポインタもサイズや型が明確でないといけないなら
ちゃんとわかっとかないといけないと思ったのですが、関数の扱いはわかってる人から見ても特殊なんですね
ありがとうございます >>206
あなたはどういう文脈で「関数のサイズ」が気になった・話題になったの?プアな組み込みとか?
俺は「関数のサイズ」が気になった・話題になった覚えがない
まぁコンパイル後のコード量かなぁ、関数の行数は大きく関係する
引数はスタックに積むけど「関数のサイズ」とは言わない気がする サイズ云々は
インクリメントしたときにどんだけ(何バイト)進むのかが確定してる型でないとポインタにならない
→ じゃ関数ポインタって 関数のサイズ(≒ コンパイル後の機械語化されたバイナリのサイズ) を知ってるのか?
こういう思考の流れかな? >>212
まさにそれです!
関数ポインタを配列に格納した時インクリメントしたら何バイト進むのか分かってないといけないのではと >>213
その状況で必要になるのは関数のサイズじゃなくて関数ポインタのサイズや
それは他のポインタと同じ、64bitPCなら8バイト
仮定の話として、もし「関数ポインタの配列」ではなく「関数の配列」が作成できるような言語仕様にするなら、関数のサイズも決めないといけなかっただろうね >>214
言われてみたらたしかにそうですねなんでポインタなのに普通の変数のように考えてしまってたんだろう・・・ >>203
ありがとうございます。
>>204
メインのソフト除いて二窓三窓しているので欲しい機能だけ載せたソフトを自作したいなと。
>>205
204へのレスと同じです。
猫でも分かるは説明していない単語が出てきたり、UI作成の手順をトレースできなかったり
わからない人向けではなく分かる人向けの解説のようで個人的には合いませんでした。 >>216
関数ポインタは void* に格納可能であると保証してないし、関数ポインタがオブジェクトを指すポインタより大きかったり表現が異なっていたりする環境はある。
出来る環境でなら使うのが悪いわけではないけど移植性は犠牲になる。 >>218
>関数ポインタは void* に格納可能であると保証してないし
そんなことありえるの? near ポインタモデル?だったかの
変数のアドレッシングサイズと
プログラムカウンタのアドレッシングサイズが違うやつ ミディアムモデルとかコンパクトモデルとか
まぁ過去の話だわな 関数のサイズは関数のポインタをアドレス順にソートすれば求められる
そのサイズ分を実行可能領域にコピーすれば当然実行もできるよ
dllインジェクションとかでたまに使われる >>217
業務で使ってるような信頼性のソフトを自作するつもりなのか
一人で?予算は?期間は?
まあ無理だろ
単純にメモリの大きなPCに買い替えればいいんじゃない >>217
マイクロソフトが出している公式のチュートリアルは C++ が基礎だけど
考え方としては C でも同じなのでそのへんは適当に読み替えながら……
https://learn.microsoft.com/ja-jp/windows/win32/
Win32 API は C で使ってもそんなに不便ではないように出来てる。
特に最も基礎のこのへんの例示のコードは (C++ とは書いてあるが) たぶん C としてコンパイルさせても通る。
https://learn.microsoft.com/ja-jp/windows/win32/learnwin32/your-first-windows-program
必要な知識の分量は初心者が想像するよりずっと多いと思う。
分かりやすいドキュメントがあったとしても (そして無いこともしばしばある!) 分量は減らないので
分量というハードルをクリアするのは単純に学習量しかないし、
学習量をこなすには時間をかけるしかしょうがない。
やりたいことを自由に出来るようになるまで何も生産しない時間 (業務なら人件費に換算されるだろう) をかける余裕があるの?
というところを不安に思っちゃうわけだよ。
ここは C スレだから C プログラミングを支援したい気持ちはあるがそれがしんどい場合も多いってことも知ってる。
個人事業なら趣味と兼ねるのもアリかもしんないけど。 >>224
Cコンパイラに、C++ -> C トランスレート機能あるの? API はほとんど C インターフェースで
C++をベターCとして利用してて C++のクラスの機構はほぼ使ってない
(GDI+ とかAPIがはなっから C++ インターフェースの奴は別) >>228
あれ Cインターフェース居るのか 最終的にはCOMになってるんやっけ? >>229
gdiplus.dll 自体は関数群を置いてあるだけっぽい。
それをラッパークラスで覆って C++ から使いやすくしているだけ。 >>224
兼任ですが個人事業主でお金と時間はそれなりに自由に使えます。
3〜5ヶ月くらいはまとまった時間を取ることも可能です。
公式チュートリアルは参考にはなりますが読みやすいかと言われると微妙ですね。
知識はもちろん身につけたいのですが、そこまでの道筋は他人のコードを読む方がやはり良いのでしょうか?
書籍やサイトなどでアプリの形になるまでのチュートリアルなどは無いのでしょうか。 Win32APIというよりそれ以前の
C言語の知識が足りてないんじゃないのかな >>233
何を学べば良いかすらわからないときのとっかかりとして
他人のコードを読む (何がわかってないかはわかる) ことを勧めたまでで、
良い資料があるならそれを読むにこしたことはないよ。
良い資料がないことも多いという現実はあるけど。
私は公式チュートリアルは良いほうだと思う。
知らないことを書いてあるんだからある程度は読みづらいこともあるのは当たり前のことで、
どれを読んだって似たようなもんじゃないかな。
専門的な内容をスラスラ読めるほうがおかしいでしょ。 さてはオメー
ふらっとC#スレで他人のコードの読み方とか延々聞いてたヤツだな? >>206
関数もメモリにロードされるのわからず?
関数はただのマシンコードなんだからここから始まりますよ、というラベルがついてるだけだぞ
そして呼ばれた時はそこへジャンプするだけ
関数ポインタはそのマシンコードのラベルのアドレスを保持しているだけ
ポインタ以前にコンピュータの仕組みからやった方が良さそう
プログラム格納方式とか聞いたことない? >>236
なんちゃらGPTがここでこっそり質問してたら笑う >>219>>227
ググってみたらどうも>>218が正しいらしい だからねえよ
そいつが勘違いしてるか、使い方が悪いかだろ >>206
構造体もプログラムからしたらただのメモリ領域の塊だぞ
そこに変数とかいう概念はない
構造体のメンバのオフセットでその位置を指定して書き込んだり読み込んだりするだけ
その時のオフセットの計算に利用されるのが型
変数宣言すると構造体全体サイズのメモリ領域がスタックに確保される
mallocで確保されるとヒープに確保されてそのアドレスが返る
ただそれだけ 関数を malloc で確保するにはどうすれば良いですか?って言いそう ちなみにメモリにロードされた関数の領域は現代のOSならば当然ながらアクセス不可能
昔はプログラム領域にアクセスできてその中のコードを動的に書き換えるという荒技をやってた人もいるらしいが ちなみにメモリ領域にマシンコードを生成してそのメモリ領域のマシンコードを即時実行するということはできる
これをJITという
最近のスクリプト言語ではこの手法がかなり用いられている
やり方は普通にメモリにマシンコードを生成して実行可能属性を付加、各種CPUキャッシュをクリアしてから
関数ポインタにキャストして実行するだけ メモリ保護機構が動いて実行できないと思う
16ビットリアルモードOSだったらできたと思うが mprotectとかVirtualProtectで実行可能にすればできる しかし、それだと任意のコード実行が自由自在ってことになって・・・
まずくない? >>247
許可を与えないと実行できないから問題にならないよ。
許可を与えられる前には実行できないんだから
外から注入されたものが自分で許可を出すということは出来ない。 >>247
許可を与えないと実行できないから問題にならないよ。
許可を与えられる前には実行できないんだから
外から注入されたものが自分で許可を出すということは出来ない。 >>250
その理屈はOSすら信じられずPC使うなって発想にしかならん
信じた者が信じる者は正しい、セキュリティの基本やろ 企業でもそうなんですか?
管理者が望んでいないプログラムが動かせたら困るでしょう
管理者自身がやるってならちょっと違いますが >>252
それはつまり「身内じゃないから動かない」なわけで身内も信じちゃまずいにはならんわけよ
>>249ではちみつ先輩が言っているのは「許可されたものは動く」なわけで
管理者が許可したものは動くし許可しなければ動かない
たぶん「許可したプログラムが許可してないコードを実行したらどうすんの?」ってことだと思うけど
そんなプログラムを許可した時点で間違ってる ???
私の理解だと >>247 は「機械語をその場で生成して即時実行するのって危なくないの?」という話だと思ってたんだけど違うの?
そういう理解だったから実行の許可を出す (メモリの実行可能属性を ON にする API を呼び出す) ことなく実行できない、
プログラマの意図しない実行は防がれるということを応えたつもりだったんだけど、運用の話なの???
「身内」ってのは「プログラムの中での機械語生成にミスったらめっちゃ暴走するやん?」という意味かと思ったけど
運用にかかわる人物という意味? >>225
C++黎明期はC++トランスレーター付きのCを普通に使わされたもんだよ >>250
それなら自作のプログラムをコンパイルして実行できる環境がすでにまずいだろw
パソコンをゲーム機みたいにしたいのかい
読み書きできるメモリを実行可能属性にできるというだけで
書き込み不可能なシステムメモリに書き込めるようにできるわけではない 本日のWebは、
・帝乃三姉妹は案外、チョロい。 → 本誌で既読
・レッドブルー → 本誌で既読
・からかい上手の高木さん → ゲッサンで既読
どうにかしてよ、A立。たとえば響5巻無料Webでもとか。
そういえば、高木さんの人の将棋のやつ、マガポケでも終わったね。 いわゆるroot権限が必要な行為は実行出来ないね
でも、mprotectの説明によると
> 注意
Linux では、(カーネル vsyscall 領域以外の) 任意のプロセスアドレス空間において mprotect ()を呼び出すことが、常に許されている。
となってるから、Node.js(node)とかJITを行うプログラムがユーザー権限で動くのだろう
単に利便性の為だろう staticグローバル変数を含んだ動的ライブラリーを動的リンクをする場合はグローバル変数が初期化されるのはmain実行前の認識です。
同じプロセス内で再度初期化したい場合は別途初期化の関数を用意してないと不可能でしょうか?
動的ロード(dlopen)を使用した場合はdlcloseして再度dlopenした場合は初期化されますか? >>259
>動的ロード(dlopen)を使用した場合はdlcloseして再度dlopenした場合は初期化されますか?
Linuxの場合には初期化されたけど環境依存かも?
$ cat hoge.c hage.c
#include <stdio.h>
static int a = 100;
void increament_a () {++ a;}
void print_a () {printf ("%d\n", a);}
#include <dlfcn.h>
typedef void (*Func) ();
int main () {
void *handle;
Func func;
handle = dlopen ("libhoge.so", RTLD_LAZY);
func = (Func)dlsym (handle, "print_a");
(*func) ();
func = (Func)dlsym (handle, "increament_a");
(*func) ();
func = (Func)dlsym (handle, "print_a");
(*func) ();
dlclose (handle);
handle = dlopen ("libhoge.so", RTLD_LAZY);
func = (Func)dlsym (handle, "print_a");
(*func) ();
return 0;
}
$ gcc -shared -fPIC -o libhoge.so hoge.c
$ gcc -o hage hage.c
$ LD_LIBRARY_PATH=.; ./hage
100
101
100 >>261
ですよねぇ
数十万のレガシーコードで、リセットするにはプロセスのキルが前提なんだけど、移植対象のシステムはプロセスをキルできないので、なんとかリセットする方法はないかと… 初期値代入くらい書くだろ普通
処理系によっちゃ不定な値から始まったりするのを防ぐ為にさ >>262
検証ありがとう
自分の環境でも試してみます >>259
RTLD_NODELETE フラグで再初期化を止められる(というよりアンロードを妨げるのだけど)ので逆に言えば特に指定しなければ再初期化はされるのが通常動作という解釈でいいと思う。
>>263
わかってるだろうけどレガシーコードをそうやって延命させるとますますワヤになるでよ。 >>264
言語仕様的にはグローバル変数 (記憶域期間が static) が不定になったりはしないことになっている (初期化子がなければゼロで初期化する) のでまともな開発環境があるところではそんな心配はしないよ。
心配が必要になるほど不確かな処理系しかない (または初期化処理も自分でかかなきゃいけないような低レイヤ) 分野もあるのは知ってるけどそれが普通ってことはない。 >>267
言語仕様ではなく2度目のdlopenの初期化の話なんだからドキュメント化されてないなら何の保証もないでしょ >>268
そういう意味で言ってたのならわかる。
「どうして元から代入する処理を入れてなかった?それが普通だろ?」というニュアンスで受け取ってたから元は dlopen しなおしで対処する想定ではなかったからそういうことを心配してなかった (する必要がなかった) という反応になった。 ポインタ変数にアドレスを代入するのはシャローコピーと言えると思いますか?
char s[] = "abc";
char *p = s; // shallow copy シャローコピーはディープコピーと並べて語るときに区別するための用語であって、
代入は普通に代入と呼ぶのが、コミュニケーションにおいて適切だ、
と、自分が聞かれた場合なら答えるし、レビュー依頼された場合なら指摘します シャローコピーでしょ
2つのポインタが同じ内容になってる訳だから
ちなみに、変数定義時の代入文はバインド(束縛する)と言った方が適切だな シャローコピーの要件からすると
ポインタ変数にアドレスを代入するだけでは成立せずに
リファレンス可能なオブジェクトを指してるポインタでないとまずい気がする
char *p = (char *)0x000; /* アドレスを代入してるぞ */ 意見分かれますね
ではstrdupはディープコピーだと言えますか? C言語にはオブジェクトと言う概念がないからなあ
お気持ちとしてどうかと聞かれれば、人それぞれで >>281
ファイルシステムや仮想記憶とか、コピーオンライトといって、書き込みが発生するまでは単なる参照先のコピーだけでコピー完了としてしまう
要するに何をもってコピーかを、先ずは定義してくれ C++ の 参照だったら概念含めてそのまんまだったんだろうな
int a;
int& b = a; >>276
「言わない」
代入をシャローコピーだとか言ってなにか騒いでる人があなたの周りにいるという話?なら、そいつバカだからあなたは相手にしなくていいよ。あなたはもっと大事な問題に取り組むべき 代入元の配列がスタック上なのかどうか、そちらの方がC言語的には重要 関数内の自動変数へのポインタを関数の外へ持ち出したりすると… >>289
代入はコピーじゃないのか?
代入とコピーの本質的な違いは何だ? コピーには違いないけどディープとかシャローとか区別できるものじゃないってことだろ >>293
代入は演算の種類
コピーは演算した結果起こる作用
用語を論理的に整理できてないとお話にならないだろう
RustvsC++スレ辺りでまともな議論ができてないのはこれのせい >>295
そういうコトなら、>>271は
アドレスを代入演算した結果を、シャローコピーと言えるか、
という質問じゃないの? シャローコピーとかディープコピーとかはもともとPythonの概念ですよね? >>297
C++やJavaあたりが元だと思うけど そういうことで、
Cにはシャローコピーとかディープコピーとかの概念はない 少し前までスマートな人がたくさんいたのにいつの間にかバカしか居なくなった >>301
LISPじゃね?深いコピーは演習なんかの定番だった気がする >>305
比較の手段が参照と値と構造とで数種類あるしそうだろうね
この手の大抵の起源はLispだよ Pythonの解説書には大概、ディープコピーとシャローコピーが載ってますよ >>305
もちろんそういう状況を扱っている事例は数多くある。
ただ、ざっと見た感じでは古いマニュアルでは「再帰的」とか「共有」とかいった語で説明するのが普通っぽい。
深い/浅いといった言い方が発生したのはもっと新しい言語でのことだと思う。 つか、Cは書いてる人にしか型が分からないからそんな器用な事は出来ないよな?
どっちのコピーも自前でちまちま作るしか無い 呼称にこだわってる限りCなんて使えない
お上品な他の言語使ってりゃいいじゃん >>310
その通りですよ
私はユーザが定義する集成型(structみたいなもの)を、PCをまたいでリモートコンピュータ上にコピーするもの(WindowsのC#とHP-UXのC)、を仕事で作った事があるのだけど、それをやるには型定義からガッツリ関わる仕組みを構築しないと無理なのよ。
自分はエクセルでやった(そして完璧にはできず特例処理だらけになった)けど、普通はDDLとか独自に作るでしょ
上の方で最初に話題出したヒトは多分、どういう問題空間でディープコピーとかシャローコピーを話題にする必要が生じるのか【すら】分かってないよ
そうだね 複オジ とか言われてた人の雰囲気と似てるね UPLIFT プレミアム・サービスのお知らせ
https://uplift.5ch.net/
UPLIFT 主な特典
・連続投稿の規制を緩和します。
・スレッド作成時の規制を緩和します。
・5ch.netのスレッド表示画面に表示される広告を除去します。
・5ch.net専用ブラウザで5ch.netの過去ログを閲覧できるようになります。
・海外からのアクセス・ホスト経由からでも書き込みができるようになります。
・書き込みが規制されているプロバイダーからでも書き込みができるようになります。
・5ch.netを安定して利用できるように運営を支援できます。
5ちゃんねるを存続させるためには、皆様のご協力が必要です。
最後まで御精読いただきありがとうございました。 >>297
もちろん概念としてはCの時代からある
しかし明確に言葉として定義したのはsmalltalkのはず
shallowCopyメソッドとかがある smalltalk、凄いな!私はバートランド・メイヤーさん、すごく尊敬してます
javadocとかdoxygenみたいなシステムも、もうあの時代に彼はすでに形にして世に出してるんですよね
例外の説明とか、プログラムを契約の履行に例える話とかもそうだし、あとコメント論とかもイケてるんですよ
頭良すぎて周りが付いてくのに何年もかかってる気がする てかまあ、Cのスレだね
でもCで構造体リモートコピーするにはさ、みたいな話をしても、多分誰も乗ってきてくれないよね そーゆーのに憧れてる層には土方言語のCはいらんだろw だからさ、C言語の変数や構造体内の型宣言なんてイイカゲンなんだからそう言う話ははなから無理なんだよ メッセージというか伝送パケットを作る話とかはどうですかね(皆さん興味ありますか)
タグ・レングス・バリュー形式がー、とか
バイナリvs文字列とか
(文字列にして伝送するのって遅いと思うでしょ、意外と速度okだったりします)
あと、message pack とか 経路によっては7ビット+パリティに解釈されるからバイナリは無理 結局、デバイスとかハードの特性を理解する必要があるんだよね メッセージの受け渡しでハードの特性まで理解する必要はないだろう だっていまどきC言語使ってる人なんて、デバイス寄りのハードウェアコントロールとか、チープなCPUに搭載するソフトとかだろ? >>321
おっと、反応サンキュー
0x00をデータとして送るのってあるある話題ですよねw
確かに「通信全部が」文字列で、nul文字終端だとすると無理。
でも、アタマにデータサイズがあって、それからデータがある形式ならば、仮に文字列が続いてると見える中に、まるでゴミ文字みたいに0x00が入っててもokなのよ
実は今のHTTPもそうなってたはず >>326
途中のコードに文字列操作を一切使わないならいいが
改修はいって文字列操作する人が居たらアウトだよね? 最初からunsignd charのポインタとサイズを構造体にして扱えば良いだけ 大昔は7ビットしか通らない経路あったねw
5baseとかの時代でしょうか
今は、8ビットを8ビットで伝送するほうが稀でしょうね
8ビットを10ビットで符号化することで、ゼロやイチが連続する数が少なくなるようにすることで、データ自体でタイミングを取れる方法をIBMが発明したとかで
だからこんなに速くなったそうです >>327
多分あなたの危惧が伝わってないです
改修案件でバグを作り込んだのに動作確認せずリリースしてしまうっていう事なら、工程管理ができてないって話でプロとしてダメ
メッセージ形式の仕様とは関係ないですね やっぱりめんどくさい奴だったかw
あんたにレスがもらえないのはテーマのせいじゃないとわかれ >>330
安易に文字列を使う仕様にしてるとバイナリ通らないの忘れるし思わぬバグを生む原因になるから、最初からバイナリ配列にするか文字列操作関数を一切使わない様にしないとな Perlとかで利用している設定ファイルがあるのですが、
Cで書いたプログラムでも同じファイルを設定ファイルとして読み込みたいです
設定ファイルですが、このような感じです
val = abc
str1 = $val/AAA
Perlでは「$val」を展開し、str1に「abc/AAA」と設定してくれるのですが、
Cから読み込む場合は、自分で展開する必要があると思ってます
それをやってくれるライブラリや関数等、ありますでしょうか >>335
そういうのをどう解決するかを自分が考えて実現するのが楽しいのに…
自分なら
設定ファイルを「環境変数を設定する」に変更して、perlもCも環境変数から設定項目を読む に変更する。
そのために
perl側を変更する権利を得る
OSに依存して良い条件
を確保する様に、喫煙所に通う >>335
別の解決案
・Cに優しい形式(右辺を全部展開した形で、イコール前後のスペースもなし)で吐き直すツールを、perlで作る
・自分で全部Cで作る
・lex/yacc を使って軽言語解釈ルーチンを作る
それぞれデメリットがあって、質問に直接答える「そういったライブラリはあるか」に一番合ってるのが、最後のlex/yaccだけど、それは一番バカらしい答えでもある。お好きに >>335
その説明では何をやりたいのか伝わってないので仕様書を書いてみて。
理想的なライブラリがあったとして、そのテストケースという形式でもいい。
曖昧模糊な要望だと説明が下手なだけでなく説明しようとしている内容が見当違いな可能性を疑う。
(いわゆるXY問題) Cのソースでその展開もどきを行いたいのか
Cで書いてるプログラムがとあるファイル食って文字処理するんだけど、同じことを実現したいのか >>335
これは実装するとなると簡易言語になっちゃうな
でも変数と変数参照だけだから大して難しくないよ
たぶん1000行ぐらいに収まる どうしても既存の設定ファイルをそのまま使いたい、それを処理できるようなものが欲しいということなら
そんな都合の良いものがあるわけない。 自分で書くしかしょうがない。
完璧にそのままのフォーマットでなくおおよそ似た機能があればよいなら
TOML とか JSON とか YAML とかの広く使われているフォーマットを採用したほうが面倒が少ない。
Perl でも C でも処理できるライブラリがいくつもあるし。
これらには変数展開のような機能はないが、
設定ファイルで動的な操作を可能にするのは問題を引き起こしやすいと考えられていて、
アプリケーション側でやるかプリプロセッサでなんとかしたほうがよい。
(強いて言えば YAML のエイリアス機能は変数のようなものとも言えるけど文字列を結合したりは出来ない。)
逆に設定どころではなくユーザーによるカスタマイズをどんどんやってもらうようなものなら
Lua とかのアプリケーション拡張言語を埋め込んでしまうという方法もとれる。 Cは遅延評価を積極的にやるための言語ではないからなあ
C++やC#ならあるんだけどね
lex/yacc はちょっと古くて
今なら flex/byson ですね $ の変数展開しかやらないなら複雑な構文解析にはならないから全部自作した方が楽なのでは?
少し楽したいなら perl に読ませて $ 展開させた文字列に変換して出力したのを C の側で読むとかね。そうすると少し楽ができる。
これの問題は perl が使えない環境では動かないことかな。 設定ファイルのデータ構造が key/value の組だけ、 value は単なる文字列という程度なら
パーサジェネレータはかえって邪魔じゃないのかな。 lex/yaccは使った事ない人にはハードル高いだろうね。逆に、使い方が分かると何でもそれでやりたがる時期が来る。どんなツールや言語でもそうだろうけど BNF書いても大した量にならないだろうし俺ならフルスクラッチで書いちゃうな で、設定ファイル、shで環境変数を設定すりゃ済む、という案に誰も反応してもらえないんだが、どうだい? windows ならcmdだろうけど
設定項目ってのは、パス文字列とか、メモリサイズとか、ほぼ固定だけどあとから変えたい場合もあろう、っていう定数だよね。環境変数ってまさにその目的だと思ってる。
ドル記号で一時値の展開もできる。Cからも簡単に読める。 shで、設定ファイル兼、実行ファイル起動ラッパを書いて、利用者には直接実行ファイルじゃなくラッパを起動せよと説明して
export XXX_ROOT=/var/xxx
export XXX_INPUT_DIR=${XXX_ROOT}/in
export XXX_OUTPUT_DIR=${XXX_ROOT}/out
export XXX_READBUF_SIZE=32768
exec ${XXX_ROOT}/bin/xxx
Cで読む処理は
get_conf_str(...) //文字列項目用
get_conf_i64(...) //整数項目用
どっちもパラメータに
(環境変数名, 環境変数が未設定時の具体値)
って指定する。これが、ソース上の1箇所でズラッと並ぶと「設定項目名とハードコード値の、一覧表」風になるの。分かる? get_conf_str() と get_conf_i64() の中身は
getenv() を使って簡単に実装できる、のは分かるよね? struct conf_t {
char* input_dir
char* output_dir;
int64_t readbuf_size;
} g_conf;
文字列項目はC++だとstd::string にする所だが、Cだとstrdup(的なもの)で実装しても良いんじゃないかい。
g_conf.inputdir = get_conf_str(
"XXX_INPUT_DIR", "/var/xxx/in");
g_conf.outputdir = get_conf_str(
"XXX_OUTPUT_DIR", "/var/xxx/out");
g_conf.readbuf_size = get_conf_i64(
"XXX_READBUF_SIZE", 32768);
とかってするとソース上で一覧表風になるでしょ。タブ文字も入れて桁そろえて。 まあ落ち着けよ 質問者はそんなこと聞いとらんだろうよ for(;;){
if((result = fgets(line, MAX_LEN, stream)) != NULL){
p1=result;
p3=p1+strlen(line);
p2=strtok(p1, "=");
}
}
これで、p1とp2から左辺、p2とp3から右辺が取り出せる。
$の展開は、マクロ展開処理の要領で
右辺に$があるかチェックして、あったら定義値に置き換えるという
10ステップ程度の処理でできるだろ。 >>335
>Cから読み込む場合は、自分で展開する必要があると思ってます
その通りです
>それをやってくれるライブラリや関数等、ありますでしょうか
ありません
自作する必要があります
>>363
p2=strtok(p1, "=");
スペースやタブの処理が必要 せめて既存の気の利いた言語のstring型のメソッドやらを参考にしろよ
ここで再発明しても誰も使わんだろ >>335
>それをやってくれるライブラリや関数等、ありますでしょうか
perlはCで書かれてるけどね 動かすCプログラムをperlに書き直す方が簡単そう こんな方法もある。しかし $ の変数展開しかしないなら無駄な感じはするね。それだけのためにここまでするのかという。
perlembed - C プログラムへの Perl の埋め込み方
https://perldoc.jp/docs/perl/5.10.0/perlembed.pod $がリテラルとして入ってた時はどうするかとか、結構面倒そう >>370
そうなんだよー、真面目にやるとバカみたいに面倒なのよ
文字列リテラルの中に $ やコメント開始終了記号が入る事もあるし
コメントの中に $ や文字列開始終了記号が入る事もある
# "#"
$aaa = /* $コメント " */ "文字列/**/値";
なので、頭から読み始めて、状態を追いながら(現在の場所が 文を書く所か、コメント内か、文字列内か)読まないと、正しいファイルを正しく読めない
んで、つまんないバグを作り込んだりするの。その、もういない誰かが作り込んだつまんないバグを、別の誰かが直すはめになる。そんなの嫌じゃね? でも本当に、質問者はもうトンズラしたと思うよ。次の話をしよう >>327
どっちにしろ質問者のためにやってるわけじゃないからいいんだよ >>371
そこまでのコメント機能はいらんやろ
シェルスクリプトの設定ファイル程度のことができればいいんだろうから
#が来たら改行までをコメントとするぐらいで ちなみにCの識別子に$を使える
少なくともgcc, clang, msvcで使える
int $val = 0;
とか >>375
環境変数設定で「十分」どころか、それがかなりきちんと対応している。
シェルは(shもcmdも)「改行までコメントとみなす」なんていういい加減な実装じゃないよ パーサー実装の現実的な話がまともにできるニキはここにはいないねw >>377
いやだからそんな本格的に作る必要ないって話
労力の投入場所を選定するのもプログラマの能力 >>371みたいなので悩むならさくっと正規表現ライブラリやパーサージェネレータ使うな。
学習のために自分でパーサー書いてみたいってんなら別だが。 >>379
仕様が曖昧なのに実装の話をしても無意味だろ。
新しい情報が提示されないなら回答すべきこともない。 C言語からJSON読み書きにオススメのライブラリやDLL教えてくれさい。
UTF-8↔ANSI変換はAPIでやれそうです。 以下はmalloc()で割り当てた領域を開放してポインタをヌルポインタにするマクロである
#define MYFREE(p) do {free(p); p = 0;} while(0)
このマクロに不備があるかないか、ある場合はどんな不備か答えよ
ただし処理系はANCI C準拠とし、stdlib.hがインクルードされていることとpが左辺値かつmallocで割り当てた領域を指す有効なポインタであることの2点は呼び出し側によって保障されているものとする >>394
2つ以上の文をマクロ関数の形にするときに、C言語の仕様において最も合法安全とされるイディオムだよ >>394
たとえば
#define MYFREE(p) free(p); p = 0
と定義すると
if( 条件 ) MYFREE( p );
と書くと
if( 条件 ) free(p); p = 0;
と展開されてしまいp = 0;は条件に関わらず実行されてしまう
またこの後にelse節が続くとエラーになってしまうなど不具合の原因になる >>396,398,399
全然知らなかった
アリガト >>392
その条件下ならない
でもpが左辺値という前提がなかったら変なコトになるコードが書けるね >>400
396はゼンゼン関係ないんだけどホントに分かってんのか?w >>402
396 と 399 は異口同音と読んでいたが、主旨違うの? >>402
ブロックではなく do / while にする理由としては関係がある。 二つの文が分かれてしまわないようにするだけならブロックで包めばよくて
#define MYFREE(p) {free(p); p = 0;}
と定義しておけば
if( 条件 ) MYFREE( p );
というような使い方で意図通り動作する。 問題になるのは else が付くときで、
if( 条件 ) MYFREE( p );
else foo();
みたいなことをすると
if( 条件 ) {free(p); p = 0;};
else foo();
というように余計なセミコロンが if と else の対応付けを壊してしまう。
かといって MYFREE にはセミコロンを付けない使い方をせよというのも不格好なので do / while で囲むといい感じって話。 はちみつ餃子はいい加減改名しろよ、はちみつ先生によ
どんだけタメになる話すりゃ気が済むんだ
目からウロボロスだぜまったく >>392
「せよ」ってなんだよ。何様のつもりだ? #define MYFREE(p) (free(p), p = 0)
のほうが単純 今どきのCならマクロじゃないといけない場合以外はinline使え。 >>409
C の関数は多相化できない。
void* と他のポインタは相互に変換可能なんだが
void* 自体の表現や境界調整要求は環境依存なので
#include <stddef.h>
#include <stdlib.h>
inline void my_free(void** x) {
free(*x);
*x=NULL;
}
int main(void) {
int *x = malloc(sizeof(int));
my_free((void**)&x);
}
みたいなことをして正しく動作する保証はないはず。
この場合は「マクロじゃないといけない場合」だと思うよ。 mallocが返すのはvoid*だし、freeが受け取るのもvoid*なのに??
保証が無かったら俺達はこれからどうすればいいんだw >>411
void* の話じゃなくて void** の話をしてる。 printf("Konyanyachiwa, Sekai no Kuni kara!"); void**とvoid*は相互に変換可能じゃないのか? 変換が可能だということと同じ表現を持つことは別という話。
int* から void* への変換は変換に関するルールだが
int** から void** への変換によって int* を void* として読もうとするのは type punning の問題。 そうなると、
int** a = malloc(sizeof(int*) * 3);
は、保証無いことになるな
俺達はどうすればいいんだw void** a = malloc(sizeof(void*) * 3);
の方が適切だったか
これで、a[0]の読み書きが保証されないのは困るよ >>417
繰り返すが変換の話と表現の話は異なる。
void* は全てのオブジェクトを指すポインタと相互に変は可能であることは保証され、
「malloc が返すポインタに限っては」いかなる型とも適合するように境界調整されていることが保証される。 【AI】Googleの医療面接特化AI「AMIE」は人間よりも正確な診断が可能&患者への印象に優れるという研究結果 [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583722/l50
【AI】Google DeepMindが数学オリンピックレベルの幾何学問題を解けるAIを発表、人間の金メダリストに近い性能を発揮 [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583476/l50
【AI】大学入試共通テスト、3つのチャットAIに解かせてみたら? GPT-4はバケモノだった [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705585402/l50
【ナゾロジー】「株価の変動を粒子の振動として理解」量子力学で株式市場の法則を読む! [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583580/l50
【AI】NTT、自分の分身AIを低コストで作る技術。自分の合成音声を簡単に作れる技術も [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583313/l50
ボイス・トォ・スカルのコアプログラムの一部は上記を統合している 何を言ってるんだお前は案件
ポインタの中身は指す対象によってアラインが変わるが
ポインタ自体のアラインは原則一種類しかない >>421
ポインタは型ごとに異なる表現・境界調整要求を持つ可能性がある。
適合する型へのポインタ同士の場合など同じ表現・境界調整要求を持つ条件が定められているが
最後に「これ以外の型へのポインタは、同じ表現又は同じ境界調整要求をもつ必要はない」と仕様に明記されてる。
具体的な部分は処理系定義なので全部が同じ表現であることをあてにしていい環境ならそうすることは否定しなけど、
常にあてにできるわけでもない。 そうは言っても、
void* p = 0;
と直接生成出来るわけで、void*は値としての意味もちゃんとある
それがvoid**にすると元に戻せる保証が無いのは仕様の不備だろw >>422
それは「ポインタが指す対象」についての記述で
ポインタ自体にはどんな適当な値を書き込むことも可能(そのポインタを使ってアクセスすると何が起こるかわからないというだけ)
ただポインタにNULLを書き込むだけの関数になんの危険もない >>424
> それは「ポインタが指す対象」についての記述で
この (>>410) 場合はポインタが指す対象に書き込もうとしている話だが。 >>425
そのポインタは関数への引数であり
すでにvoid*を表すものだと型は決まってるではないか
それとは別に
インライン関数で書いた場合はその場で展開されるから
void* p = 0;と書いた場合と同様にコンパイラが適切な0を書き込んでくれるんじゃないの
つまり(void**)をつけると逆に危険
my_free(&x);
でよい ポインタで0リテラルだけは特殊でNULLと同義だったのではなかったっけ >>426
> (void**)をつけると逆に危険
これは暗黙に型変換されることが保証される文脈ではないので付けなければコンパイルが通らないだけ。
(コンパイラによっては黙って通すことはあるのかもしれない。)
> インライン関数で書いた場合はその場で展開されるから
言語の意味論としてはインライン関数は
・ 同じ定義なら (翻訳単位を跨いだ場合でも) 複数回定義してもよい (定義が一回の場合と同じ挙動)
・ なるべく高速に呼び出して欲しいことを期待するヒントである (実現方法は規定しない)
ということになってる。
インライン関数がインライン関数ではない関数と異なる動作にはならない。 >>427
せやで。
厳密に言えばリテラルだけじゃなくて「整数の 0 であるような定数 (定数式) をポインタに型変換したときは空ポインタ」というルール。
これも変換に関するルールであって表現に関するルールではないよね。
実際に空ポインタの内部表現が整数の 0 というわけではない環境は存在するが、
型が正しければ適切に変換される。 >>429
それ規格書に書いてあんの?知らんかったわ
でも
if (!ptr)
みたいなポインタがゼロであることを期待するような式は処理系依存になるでしょ? >>430
いや、それがよく出来てて、ポインタをそういう形で条件に使うのは問題ない。
単項演算子 ! について「式!Eは,(0==E)と等価とする」というルールになっていて
等価演算子 (==) はポインタと空ポインタ定数を比較したときの結果を規定してる。
空ポインタ定数のほうをもう一方のオペランドの型に合う空ポインタに型変換するルール。 >>431
規格書読んできたけど
6.3.2.3 値0をもつ整数定数式は空ポインタになる
6.5.3.1 式!Eは,(0==E)と等価
6.5.9 ==は空ポインタ定数をポインタの型へ型変換する
ってことか
なるほど、規格を解釈すれば!ptrは空ポインタと比較されることになるから問題ないのか
勉強になったわ void*の値は作成出来るけど、表現や境界調整要求は未定義とか、おかしいだろ
Cは現実に則した言語だと思ってたけど、妙な未定義だな
ちなみに、インタープリター型言語を作ったら、オブジェクトはみんなvoid*になる
void*の配列を作成したりとか普通に行われる
もはや規格とか無意味
実装がどうなってるかだけが重要だ > 実装がどうなってるかだけが重要だ
もちろんその通りだけど規格上未定義なわけだから実装がすべて統一されているとは限らないわけで
その実装における「限らない」が問題なわけでしょ 各OS毎にABI(Application Binary Interface)が定義されてて、Cの規格で定義されてないところが明確に定義されてる
2つを合わせて現実のC言語なんだよな
だから、JIS X 3010だけを取り上げてどうこう言っても混乱させるだけ >>434
実際には void* と int* (などのポインタ) が同じ表現なことは多いので
あまり問題 (type punning) にならないと考えるならそうかも。
ただ、表現が同じである環境ならかまわないのかというとそうでもない。
aliasing rules が絡んでくる。
言語仕様上で適合するとされる以外の読み書きをプログラマはやらない (やったら未定義だから) という仮定の元に最適化されることがある。
>>438
ABI はその名の通りインターフェイスを一貫させるための規定であって、
外部に公開しない (外部リンケージを持たない) 部分ではコンパイラは最適化するし、オブジェクトを除去することもある。
私は >>422 で「あてにしていい環境ならそうすることは否定しない」と述べたが、
あてになる確証を得るのは割とめんどい。
言語仕様を調べて分かる範囲で済むならそうする。
少なくとも >>392 をインライン関数にするために手間をかけるなんてことはしない。 だから、その環境が不明瞭なこういう場所で問題になるわけでしょ?
実際>>392では「処理系はANCI C準拠」としか言っていないわけだし 未定義とは規格遊びには便利な言葉だなw
正解はconfigureスクリプトがやってるように、事前に環境を調査して前提にしていい事を明確にして最適な実装をする事だな
なので、言語仕様のみで判断を下す事は不正解と言える
その為にconfigureスクリプトがある
他の言語ではあまり必要ない
Rustとか最近の言語は言語仕様に不明瞭な点は残さないのがトレンドだろう
じゃなきゃそこが脆弱性を生んでしまう >>392のマクロは、副作用のある式を渡したりするとおかしな事が起きる
全くもって脆弱なものだ
そのままで良いのか?
マクロのままにしておくとか、そっちの方が脆弱性を生む事になる
ちゃんと関数化すべきだろ
その為にすべき事は何だ?
それを議論することが正解と言っている C言語で今更議論することなんてないよ
気に入る要らないはモダン言語とかでやってなさい 使用済みのポインタ変数を変なやり方でクリアするとかクソどうでもいい >>446
え?本気でいってんの?
関数で書けば副作用(例えば++p)は1回で済む
当然副作用がある式を書くのはアホだと思うが、少なくとも書いた通りには動く 例えば、(uint8_t)malloc(...) + sizeof(int)を返す関数もあり得る
これは前の方にデータを隠すテクニックだ
実はC++のコンパイラで普通に使われている
これを解放する時は、free(p -= sizeof(int))とやらない事もない
まぁ普通はp - sizeof(int)だろうから屁理屈だけどねw >>450
解決したい問題はそれだけでいいのか。
それなら意図はわかる。
ただ現実に C の関数を多相化できないのは変えられない前提としてある。
異なる型で扱う必要があるんだから異なる関数を用意するしかないのはどうしようもなくない? 多相?
仮にポインタ変数のアドレス を引数で渡したい場合であってもvoid ** じゃなくvoid * を使って、
人間同士がドキュメントだろうが喫煙所だろうがで問題解決しろよってのが規画と整合する答えなんじゃないの
どうせキャストするんでしょうに
バカですか void* に変換したなら元の型にキャストしなおさないと保証された動作はほとんどない。
(逆に元の型に変換したときは変換前の値と一致することは保証される。)
元の型を知っているプログラマがキャストすることを期待できる qsort のような使い方なら問題にならないけど、
void* の形で受け取るだけでは関数が出来ることはほとんどない。
文字列を指すポインタに変換してバイト列として読み書きすることはアリなので
オブジェクトの内容はどうでもいいメモリブロック操作系の関数 (memmove など) だとかでも問題はないかな。 簡単な問題だったんだけど答えられる人ほとんどいないのか
相変わらず本題とは関係ない問答しだすアホらもいるし 答えられる人はいるだろうけど、宿題丸投げするやつにエサを与えたくなくて
敢えて書かない人もいるだろう。 >>445
free(p++);
p++=0; ←ここで文法エラーになるから Cに引数の参照渡しってあったっけ?
ないとしたら>>392のMYFREE(p)をマクロではなく関数として書き
その中でp=0としても呼び出した側の変数は変えられないわけで
関数にすることで動作が変わってしまうことになるはずだけど そんなこんなでp++マクロには問題が多いからC++が出来たってわけ mallocとcallocの引数の指定の仕方が違うのが気になる
これ別であることに理由あるの? >>467
言語仕様上は calloc が返すポインタ (によって表されるメモリ領域) は
malloc が返すものと同じようにあらゆる型に対して適切に境界調整されることになっているし、
ゼロクリアするという違いも「全てのビットがゼロ」という意味なので型の性質を考慮しない。
つまりふたつの引数として指定することによって得られる恩恵はない。
実装がまともなら calloc(a, b) としたときの a*b が size_t の大きさを超えてしまうようなときでも
ラップアラウンドして小さな領域を確保するのではなくエラーにしてくれることは期待できる
(間違いを検出しやすい) が、それを理由として引数ふたつにしているというわけではなさそう。
最初に言語仕様をまとめたときに主要な処理系がだいたい準拠ということになるようにしたはずなので
その頃の処理系でなんか理由はわからんがそうなってたって程度の話だと思う。 あまり意味ない。 統一したらゼロクリアするかしないかだけの違いにならん? callocはmallocのゼロクリア版として *も* 使えるがそもそもの使い方が違う。 ちなみに C には厳密にいうと価渡し(call by value)しかない
値としてアドレスを渡すので結果として参照渡し(call by reference)
ができることになる 参照って言うと色々誤解を受けるから
Cの場合はアドレス渡しで良いと思う ヘンな用語作るのやめて
ポインタで渡しても値渡しのまま
foo(int x) {int y = 0;x = y;}
bar(int *p) {int *q = 0;p = q;}
呼び出し元の変数に作用が無いのは同じ
両者は等しく値渡しのまま
baz(int *p) {int y = 0;*p = y;}
これについては値渡しされたものがポインタ型だったため
ポインタ型が持つデリファレンス機能によってポイント先に代入できただけ
*** 値として渡し ***て、デリファレンスして、代入しただけ
qux(ref int x) {int y = 0;x = y} // ウソ文法
みたいなことして呼び出し元に代入できるものが
これのみが参照渡し
参照渡しがある言語ならこんな誤解はしなくてすむ
https://www.gnu-pascal.de/gpc/Subroutine-Parameter-List-Declaration.html#Subroutine-Parameter-List-Declaration
> procedure DoIt (x: SomeType);
> Technical: The actual parameter is passed by value or reference, but if passed by reference, it is then copied to a local copy on the stack.
> What it means: you can modify x inside the routine, but your changes will not affect the actual parameter (and vice versa).
> procedure DoIt (var x: SomeType);
> Technical: The actual parameter is passed by reference.
> What it means: modifications to x inside the routine will change the actual parameter passed in.
ポインタを含むあらゆる型に対して、値渡し/参照渡しが存在する JIS の用語集やそのもとになった ISO 規格によれば call by address の定義はパラメタの場所を渡すこと。 ポインタの形であっても場所を渡しているには違いないからあてはまるし、勝手な創作用語というわけではない。
言語の理屈ではポインタもポインタという型の値だがそれの活用方法に名前が付いて悪いってこともない。
言語仕様の話をしているときに混ざってくると「んっ?」とは思うが。 ポインタなのに値渡しとか言ってる奴まだいるのかw
そういうのはポインタ渡しで良いんだよ
アドレスを値渡し→ポインタ渡しでいいんだよ >>478
>アドレスを値渡し→ポインタ渡しでいいんだよ
だよな。 >>481
>Cの文法規則がいいかげんなんだよ
だよな アドレスと言う値を渡してるのだからどちらも同じ事だろ アセンブラまんどくさいから作ったのがC
だから型がイイカゲンなのはアセンブラやってる人が対象だから イイカゲンにしてるとコンパイラの最適化を有効にしたときに破綻するぞ >>483
構造体は値渡しとアドレスの値渡しがある
どっちも値渡しというと訳が分からなくなる
なので、構造体は値渡しとポインタ渡しが出来ると言えば便利だ
そうすれば、配列は値渡しが出来ないとも言うことが出来る C++で参照が登場したので「アドレスの値渡し」とか言っている訳で
C++を知らんと意味不明だし違和感あるだろうな C++ とは関係ないと私も思う。
仮引数と実引数の関係は (型がポインタかどうかに関係なく) 値の代入であるということになっている。
繰り返すが言語仕様上の理屈では解釈の余地なく全ての引数は値呼びのメカニズムで規定されているよ。
C++ の参照と区別するための言い回しではなく仕様上の理屈通りに言えばそうなるってだけ。 それで結局
&var
の値はポインタなの?アドレスなの?
どっちでもいいんだよね? 「アドレス」と「ポインタ」の使い分けはイマイチわからないんだよなー。どっちでもいいと思う。
単項演算子の & にはアドレス演算子という名前がついていてアドレスを返すとも書いてあるのでこれについてはアドレスと言っていいのは間違いない。
ポインタは型の種類のように使われてることもあるし、ポインタ型の値のことを指しているように見える箇所もある。
個人的感想としてはアドレスのほうが低レイヤ寄りの概念でポインタは型で意味付けしているような雰囲気を感じてるんだけどあまりはっきりしない。 参照渡しと実体渡しかw
あれも、アドレス渡しとコピー渡しって言えばいいのにね アドレスは、数値が主体でそれが何を示しているかの説明の為の単語。
ポインタは変数の一つで *p や p->a 等の動作も含めての設計思想。
などと意味不明な(ry アドレスは値
ポインタは型だよ
正確にはintのポインタ型とか言うけど アドレスは値で右辺値、ポインタは変数でオブジェクトで左辺値
こんな基本的なこと、頼むよ >>498 正しくない。ポインタ型の変数 int* p に対して p + 1 もポインタだけど、変数でも左辺値でもない。 ある時はメモリーのサラリーマン、ある時はレジスターの探偵 規格上はどうなってるか知らんが
ポインタでいいじゃん統一しろよ
変数へのポインタを取る時アドレスと言いたくなるんやろな
分からんでもないが使い分ける必要はないと思う
アドレスといいつつ結局ポインタでしかないやろ?
場所だけじゃなくて型のサイズも持ってるでしょ?
アドレスと聞くと番地だけってイメージだけど
ポインタっつうのはそれに加えてサイズも持ってるのがミソ
だから不必要にアドレスと言い直す必要はない
だって実際にポインタしか扱わないんだから アドレスっていう言葉は規格には出てこないと予想してた。
規格にはポインタだけあればよくて、アドレスは実装の仕方のイメージがある。アドレスは多くの場合整数になるが、文字や文字列でもいいというような。 バイナリエディタのはアドレス違うよなぁ
メモリーエディタはアドレスだからいいけど int a[4] = {0}, (*b)[4] = &a, *c = &a[0];
printf("%p %p\n", b, b + 1);
printf("%p %p\n", c, c + 1);
0x7ffc2026d710 0x7ffc2026d720
0x7ffc2026d710 0x7ffc2026d714
アドレスと捉えると同じ番地だけど
+1の結果が違う番地になるのは
ポインタが大きさを知っているから
これが単なる整数とは違うところ アドレスと言えるのは直接ハードウェアにアクセスするものだけだよな 規格書の加減算のとこにはp + 1の結果が何になるか書いてある? 規格ちょっと読んだけど加減算のところには結果がアドレスになるかポインタになるか書いてなくね? だから、アドレスは値で、ポインタは型なんだ
p + 1はpの型によって結果が決まる
intかintのポインタ型かで結果が変わる >>514
>だから、アドレスは値で、ポインタは型なんだ
>p + 1はpの型によって結果が決まる
>intかintのポインタ型かで結果が変わる
だよな >>514
規格読み直したら加算の結果はポインタになるって書いてあったわ (int)(p+1)-(int )(p) == sizeof (*p)
だっけ? >>518
intは32bitのLP64環境ではどうなるんだい? コンパイルエラーか警告でて下位32bitのみ取得じゃね?
sizeof (*p)がint_max超える設定でもなけりゃ目的は果たせそうだけど。 ポインタは整数に型変換できるけどその値がどうなるかは処理系定義。
変換結果がその整数型で表現できなかったときは未定義。
gcc や clang だとポインタをより小さい整数型に変換しようとしたらエラーになった。
intptr_t や uintptr_t に限っては正しい void* はこれらの整数に変換可能、かつ
void* に再び変換したら元の値と等しいことが保証される。
オブジェクトを指すポインタは void* に変換可能なので
オブジェクトを指すポインタは intptr_t や uintptr_t に (情報の欠落なく、可逆な形で) 変換できる。
しかしポインタが整数でどのような表現を持つかは規定されていないし、
intptr_t や uintptr_t は提供されないこともありうる。
オブジェクトを指すポインタは文字型を指すポインタに型変換してバイト列としてアクセスできることは保証されているので
オブジェクトの大きさを知るためにポインタ操作をするのであれば ↓ のような形にするのはアリなはず。
#include <assert.h>
int main(void) {
int obj;
int *p=&obj;
assert((char*)(p+1)-(char*)(p) == sizeof(*p));
} はちみつの説明はちっとも頭に入ってこん
3行にまとめてから貼れ >>522
関連する規則は関連する規則の数より減ることはない。
根拠不明でいいなら削るけどそんな説明を見たいのか? 3行しか文章解読できないなら、コード書くのは辛いだろう >>517
「加算」でページ内検索すればすぐ見つかる errno ってどうしてスレッドごとに別々につかえるの? >>527
「どうして」というのはそういう仕様になっている理由?
それともそれを実現している方法のこと? >>528
方法のほうですね
__thread ?とかってgcc固有?って聞いたけど
gcc以外とか大昔とかどうやってんのかなーって >>529
errno は型 int を持つ変更可能な左辺値に展開されるならマクロで定義されてもよいことになっている。
昔の C には記憶域期間の分類にスレッドは無かったが
#define errno *__foo()
みたいな感じで定義しておいて、
この関数がスレッドごとに適切な場所を返すように作っておけば辻褄は合う。 >>530
これでerrnoの初期化とかできるのか? なるほどできるのか。よくできてるね 結局、スレッド処理がいい具合にリンクしてくれてるって事だね >>529
別にTLSの文法がなくてもコンパイラにTLS相当の非公開機能があれば実現可能。 TLSと言えばゲームの方やね
バタ語を略したスレッドローカルストレージではないんや
このスレの世代的にも半数以上がそう思って口に言わずとも突っ込んだ経験があるはずや 「TLS ゲーム」でググったらトゥルー・ラブストーリーが出てきた。
タイトルは聞いたことがあるけどやったことないし、 TLS なんて略称にはなじみがないわ。
Transport Layer Security と被っとるやないけというツッコミはしたくなったことはあるが。
バタ語ってなんや? ここの人は並列計算についても答えるの?
それともスレ違い? >>537
一応は C の名前を冠したスレだからその質問が言語仕様に関わる質問ならこのスレでいい。
C を使ったロジックの組み立てかたみたいなのもある程度は許容されると思う。
環境に固有の事情が絡むならそれぞれのスレのほうがいいこともある。
Win32api スレとか Unix スレとか。 tlsって毎回アクセスする度に初期化済みかどうかチェックされるんか?
もしそうなら未初期化上等のc言語では特殊だな 【AI】Stable Diffusion 3発表、Soraで話題の拡散トランスフォーマーを採用 [すらいむ★]
http://egg.5ch.net/test/read.cgi/scienceplus/1708865670/l50
ボイス・トォ・スカるしている者も攻撃を受けるようになりました こんな Web ページを作りました。ぜひどうぞ。
http://www7b.biglobe.ne.jp/~river_r/chs/ >>543 ごめんなさい。言葉足らずでした。
「数値計算結果の画像化など」 という Web ページを作りました。
プログラミング、数値計算、カオス、画像作成と表示
などに興味がある方は、ぜひどうぞ。
http://www7b.biglobe.ne.jp/~river_r/chs/ 空白のBMPなんて簡単に作れると思うよ
起動したときに自分で作ったら良いと思った >>546
ここは C スレなんだから C で書いたほうが親切じゃないかな。
まあ実質的にはほとんど C みたいな書き方だけども…… >>0548
>546 です。C++ に特有な機能は、
全くと言っていいほど、使っていませんよ。
pow(x, y) というのは目新しいけど。 >>549
C++ の機能をほとんど使ってないことはわかってるしそう言ってるじゃないの。
使わないのに C++ の形式をとって C スレに投下するのはちょっと不親切かもねという話をしてるんだよ。
pow (べき乗関数の総称版) は C にもあるし、 C の仕様に入ったのは C99 から。
それを知らなくて (しかし使いたくて?) C++ にしたという意味なのかな? pow()なんてx^y(yが変数)したい時だけでいい
pow(x,2), pow(x,0.5)は、(x*x), sqrt(x)と書いた方がいい
…まさか今時のコンパイラはこれも最適化したりする? しらんけど、今どきだと最適化されるかもしれんね
1+2+・・・+99+100
こんな計算も(1+100)x 50で最適化される記事が昔あったような こんな計算って、そのレベルでコンパイラ任せにしてるのか >>554
知らんけど、今は定数は先に計算しちゃうから、その式は1発答えだけになるような > 1+2+・・・+99+100
最適化というか、畳み込みで 5050に置き換えられるかと 例が悪かった、もちろん定数は一発計算してメモリに固定されるけど、
変数を含んでても、冗長計算を変形してくれるコンパイラが出て、gccもそのアルゴリズムを採用したことが昔あったような。 数値計算関連の関数はコンパイラによる最適化がなくても関数の内部が複雑な場合分けで対処してることが多いと思う。
GNU のやつとかだいぶんごちゃごちゃしてる。 人間が思いも付かなかったアルゴリズムで解いて見せたりして
人間が解析しても何故正しいかが分からなくなる floatが絡むと誤差の出方が変わって結果が変わるから、式を変形するような最適化は不要だ
変形しても良いよというのが-ffast-mathだな typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t sighandler);
signal関数の第1引数のシグナル番号(signum)と第2引数のハンドラ関数が実際に呼ばれたときに引数に入るシグナル番号(1行目の引数のint)は必ず一致する認識ですがあっていますか?
その場合はハンドラ関数では引数に入るシグナル番号は最初から分かっているはずですが、わざわざ引数にシグナル番号を取っている理由はなんでしょうか。シグナル番号によって処理を分岐するデカいハンドラ関数を作るくらいしか思いつきませんでした。 時間の無駄だからsignalのことは忘れなさい
時代遅れのCランタイムで本当に役立つものはごく少数しかない
そんな化石はスルーしてOSに用意された目的に合うAPIを直接使いなさい
Cランタイムのソースコードがある処理系なら読んでみると良い signalの代替は無理だろ
ランタイム自作しろとか言うのか?
sigalrm使うなぐらいならわかるが >>565
今は環境に合わせて移植するのではなく、環境を移植するのが主流だよ >>562
> 必ず一致する認識ですがあっていますか?
正しい。
> わざわざ引数にシグナル番号を取っている理由
Rationale に書かれていないのではっきりしたことはわからない。
おそらく Unix でそうなってたのを追認しただけだと思う。 >>565
シグナルまわりはどうせほとんど移植性はない。
言語仕様の範囲内だけで可能なものなら不必要に移植性を損なう必要もないけど大抵の場合に無理だと思う。 構造体やポインターを理解できたら、C言語をマスターしたと言えますか? >>569
練習用の題材ではなく (自分なりに) 意味があるプログラムを書けたあたりが
一応のマスター (あくまで最低限の出発点だが!) だろうと個人的には思ってる。
プログラミング言語は道具なんだから道具として使えることが重要で、
言語の要素を何個理解したなんてのはたいした指標にならない。 1000行程度のプログラムがすらすら一日で書けたら卒業 三行半で済む処理をダラダラ1万行ぐらいに増やすのは、得意なんだけどなあ。 >>562
番号を渡す理由はその方が柔軟性があるから
柔軟性の中には>>562で挙げてる理由も含まれる
なおsignal()は時代遅れなのでsignal.hにある別の関数を使うこと >>564
signal()なんて使わず、せめてsigaction()にしろということでは? >>562
デカいハンドラ関数を作る意図はなくても
同じようで異なる処理(複数のsigal番号の処理をする場合とか)をする時に
入口は一つにしておいて入力パラメータで処理を振り分けるとか普通の設計だと思うが。
わかりやすい例がWIN32APIのWindowProc。
あれがメッセージ番号毎に関数エントリを登録する形式だったら煩雑なことこの上ないだろ。 Windowってそんなsignalの使い方しないでしょう >>570
>>571
ありがとうございます
とりあえず何か作ってみます もうC言語は一旦終わりでいいから別の事やりなよ
結局Cだけの知識じゃ何もできんのよ
Cの知識はいざ何か作ろうとなった時に活きてくるよ プログラマ目指して挫折する人は、別に作りたいものがなくて文法ばかりを勉強するタイプかも。
文法は大事だけど、それ自体はあんまり役に立たないし調べれば済むことに時間をかけるのは程々に
合理的なアルゴリズムを瞬時に思いついて言語に落とし込めるかが大事で、これは経験。 質問サイトとかで「どうすればいいですか?」みたいなのはちょくちょくあるけど「どうなればいいの?」と返したらまともにこたえられないのもよくある。
問題の解法を構築してプログラムの形に落とし込むのが大事だというのはそりゃそうなんだけど、大前提として解決すべき問題が何であるかを認識 (発見) しなきゃならなくて、そこんところで躓いてたら助けるのも難しい。 >>582
相手はその質問で問題提起してるんだろ、なのにお前からは、どうなればいいのって "
解答" を質問者に聞いてたら、そりゃ質問者だって混乱するだろよ。
問題把握以前にお前は国語からやり直すべき。 >>583
目指すべき形がわからないのにどうすればいいかなんて答えようがないんだから訊くのはあたりまえじゃないの。
(ちなみに質問が不明瞭な場合などのために回答とは別にコメントを付ける機能が stackoverflow や teratail にはある) Pythonから来たんですけど
C言語では関数だけじゃなくifやforのブロック内部もローカルスコープって聞いて驚愕してます
ループが終わった後のカウンター変数を後続処理で気軽に利用できないって困りませんか そうしたいときはスコープの外で宣言すれば値は保持されるので
int i;
for (i=0 ; i<10 ; i++)
{
} >>592
マジっすか
ChatGPTに聞いたら、そのやり方だと外のiと中のiはスコープが別って言われて混乱しとります
---
一方で、ループの外で事前に同名の変数が宣言されている場合、
forループの仮引数として宣言された変数と同名の変数は別のものとして扱われます。
この場合、forループの仮引数として宣言された変数がローカル変数として扱われ、ループの外で宣言された変数がグローバル変数として扱われます。
これは、C言語において名前の衝突を回避するための仕組みです。 ChatGPTあってもバカはバカのままってのがよくわかる >>593
int i;
for (int i=0 ; i<10 ; i++) {...}
と書くとそうなる
宣言すると新しい変数ができる
ChatGPTって、機械が自然な応答をすることが目的で、辞書のように使うものではないんじゃないの?
ChatGPTは得た情報がどの程度正しそうなのか重みづけできないんじゃないかな >>595
ありがとう
AIの回答をよく見返したらfor(int i = 0...の解説だった
サンプルコードを示してくれるのはいいけど、自分のような丸々素人だとその意図を理解できないでこういう誤解が生まれる余地はあるね
先生が優秀過ぎて学生がついていけない構図だわこれ >>597
昔の C++ だとその書き方でも i のスコープは for 文の外側のブロックがスコープになる仕様だった。 (ISO で規格化される前のやつ。)
その頃の C の仕様ではそもそもそこで変数の宣言を出来なかったが処理系の拡張として C++ 風のやりかたをできるようにしているものもあった。
後に C++ の仕様は変更されて、 C には C++ の変更後のやり方で導入されることになったんだが、しばらくはスコープの仕様に混乱があった。
数十年前の一時期の混乱に過ぎないからそれ自体は今では気にする必要はないんだけど言語仕様は変更されることもあるし、色々と歴史的事情もある。
古い仕様を根拠にした解説もあるから AI が区別せずに学習したら辻褄の合わないことも起こると思う。
まあ人間が書いた解説も変なのは少なからずあるから AI を批判するわけじゃないけど……まあ一番最初くらいは入門書を読んだほうがいいんじゃないかと個人的には思ってる。 カウンター変数を気軽に使うのが間違い
そういう時は何かが間違ってると思った方が良い
俺がGPTならそう回答するw >>597
ChatGPTは嘘言うので使うのやめたわ。
どこかの大学の調査で学生だか生徒だかが、ChatGPTの嘘情報で間違ったまま覚えてる弊害が出始めてるとか言ってたわ。 あれは創作小説を生成する装置なのに
なんで実用性あるんだと思うんだろ? 実用性はあるけどな
使い方の問題
現役でいたかったらgithub copilotぐらいさわっとけ >>603
自転車だってパンクするかも知れん
ChatGPTも嘘言うことあるかも知れん
わきまえて使えばどちらも強力なツールだ
自転車で転んだからって乗るのをやめるかい? 嘘って言うのは人間が評価した上での話
ChatGPTに取っては与えらた入力データから
もっともらしいものを出力しただけ
ChatGPTに嘘をつかせるってのは、難しい
仮に知性というものが芽生えて、自意識が発生し
そのことを人間に隠さないといけないと判断して
そうするなら、それは初めて嘘をついたとなる >>604
創作小説を生成することが「実用」ではないと?
君にとっての実用性とは何なのかね? ChatGPT の言語能力は高いがプログラミング教育を受けてるわけじゃないからなぁ。
頭のよい素人がググりながら要約したくらいの正確さだと思う。
根拠になる仕様の項目を問うたときにまるでデタラメを返したりするのはかなりあかんとこ。 >>610
Windowsの電卓で嘘をつくバグが有ったなw >>601
ループ変数を後から参照する状況は、ループがbreakで中断したかを確認したい時だろう
そういうのは別の関数に切り分けて、ループ内でbreakじゃなくreturn trueで返すようにすべきだな(関数の最後はreturn false)
C++で言うstd::any_ofみたいな事が出来ないから、関数に切り分けるしかない 小さい関数ならちまちま切り出さなくていい
読みにくいだけ 最短経路問題で perl5 で書いたのがOut of memory!
こんな時はC言語などで書き直すのが選択肢だけど
みんなはいきなりC言語などで書きますか?
それとも、最初は書きやすい言語で処理速度以外の所を決めてからC言語などで書きますか? perlの実装があるならそれを使って色々検討するんじゃないか ここの人たちなら習わぬ Perlで下書きするより勝手知ったる Cで書くんじゃないの。
Perl開発上の問題はPerlスレで訊ねた方が、実情に即したレスが反りそう。 問題文と、組み立てたであろうアルゴリズム聞かないと、何とも言えない Perlスレ見てみたが、相談できそうな所が無かった
回答あるか分からないが、お題スレに問題文投げて解いてもらう
いろんな言語に精通している猛者が多い(Perl達人もいたはず)
PerlではなくC言語でと言うなら、ここで相談できるかもしれない 最短経路・グラフ理論・ダイクストラとか?
アルゴリズム系は、Python でしょ。Ruby も
有名な蟻本「プログラミング・コンテスト・チャレンジブック」は、C++
C は知らない Pythonは、アルゴリズムって言うより
マトリックス計算機 Perlは最短経路問題のライブラリもなく、速度が欲しければCで自分で書くしかない…ってコト!?
辞めたら? その言語で最短経路問題解こうとするの perlスレでやれよ
このスレは老害しかいないからperlの話しても通じんよ perlの歴史は結構古いぞ
年寄りしか扱えないと思ってた >>616 は C のコードを書く前に他の言語でプロトタイプを書くことがあるかという質問していて Perl についての質問ではないぞ。
Perl の話は例というか前振りだろ。 そいう話か。1行目しか読んでないわ
最近は大体OS標準のpowershellでざっくり書いて必要なら一部C#だな
pinvokeで恐らくC/C++製のDLLを利用することはあってもCコードを書く機会なんてなくなった いきなりperlで書くのと
いきなりCで書くのと何が違うんだろ?
つか、俺は最初に日本語で手順を書くが まずはBASICで書いて、速度が欲しいとこだけマシン語に置き換える感じ >>631
いきなり perlで書いたソースは既にあって、実行するとメモリ不足になるのでしょ。なので、
いきなり(perl以外の)書きやすい言語で書くのと
いきなりCで書くのと何が違うんだろ?
と訊くべき。 昔MZシリーズなんていう8ビットPCがあって、
そのマニュアルにペントミノを解くというプログラムが載っていた
しかし実行しても1日掛かっても回答が出ない
16ビットPC用のCで書き直したら、5分で終わった
ついでにアセンブラにしたら、1分だった Perlでアルゴリズムのプロトタイプ書くおじいちゃん、まだ生きていたのか
普通の若者はプロトタイプはPythonで書くんだよな。何故ならネットにダイクストラでもなんでも落ちているから
このおじいちゃんは新しい言語を勉強出来ない人間だし、かといってプロトタイプなしで初手Cで書けるような積み上げのある猛者というわけでもない
引退した方が良いのでは? やるならせめてc++でやれよ
わざわざcでやる意味ない 翻訳先が Cなら、
Perl より Python の方がコスト(手間)高で、いっぱい損な気ガス
# ダジャレに気付かないのはダレジャ 計算量や使用メモリがネックになるのわかってたら最初からc++かcuda
インタラクティブかつビジュアライズして試行錯誤するときはpython(Jupyter) 構造体変数の宣言の初期化のとき、ヌルポインタを,{ }でくくらないと、警告が出るのですが、なぜですか? 例えばこんな具合にしないと警告が出ます
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プログラマーは世界中に2億人くらいいると思う *も++も単項演算子で適用される優先順位がある
優先順位を意識してコーディングしないと痛い目に合う
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にしてたおかげもあるかな あえて使う人もあんまりいないだろうけど、メンテナンスが止まってる(32bit 化、64bit 化されない)ようなソフトを使いたいってことはそれなりにあることじゃないの。
メーカーがつぶれて消えたりするのもよくあることだしな。 アプリは32bitだがインストーラが16bitなのが結構あるらしい もしもそんなのがあったら、メチャクチャ話題になってると思うよ 知り合いにエミュレータ入れたりして凄く苦労してロータス123を動かして業務で使っている人が居る。 使うのに手間はあるとはいえエミュレータが成熟してしまったので
かなり古いソフトウェアを動かしたいならそっちでやれと言えてしまうようになったとも言える。
Windows の互換性維持システムも結局はエミュレータをサブシステムとして
組み込んでるようなもんだしな。 >>697
ファーレントゥーガとかそのパターンだね プリプロセッサでモジュール作れるようになるとC++使わなくてもCで十分だな
もっと早めにマスターするべきだった CでCOMやれって言われても困るし
逆にC++のがマシってのはその程度か cでもできるってのと、c++使ったほうが楽ってのでは全然意味違う
チームで混乱を招くという理由以外でのc++ディスりは、大抵理解不足によるアレルギーから来るヒスのことが多い
まあ、そういうヒス起こす人が多いからチームでは使用禁止とかになっちゃうわけだから、り繋がってはいるんだけど >>708
なわけ無いだろ
我慢ができないのはただのガキだぞ >>711
そうやって我慢できずに突っかかってきてるのもどうかと思うけどな… linuxカーネル縛りと趣味以外でc言語使うってどういうプロジェクト?
実際仕事でそういう人いる?
組み込みでも今時c++使えるだろ メモリ構成が非常に小さいシステムの場合Cじゃない?
8bitのPICとか こういうの考えたんだけどどうだろう?
実用性無いだろうか
#include <stdio.h>
typedef void (*exception_handler)(void);
void register_exception_handler(exception_handler handler)
{
handler();
}
void exception_occurred()
{
printf("例外が発生しました。\n");
}
void may_throw_exception(int condition)
{
if (condition) {
register_exception_handler(exception_occurred);
}
}
int main()
{
may_throw_exception(1);
return 0;
} >>716
例外でもなくでもなくて草
Cで例外起こしたいならsetjmp/longjmpでやると決まってる >>716
「こういうの」とは何であるか説明が必要。
提示されたコードは関数 exception_occurred の呼び出しを回りくどくやっているだけで、
途中のメカニズムに意味がない。
(このコードでの使い方の範囲では。)
言葉で説明しづらいならこれが有用になるような使い方の例を示して欲しい。 >>722
C の言語仕様の範囲内でやる方法は setjmp/longjmp のみ。
setjmp/longjmp を自分で書きたいってことなら
アセンブラ (またはインラインアセンブラや intrinsic 関数) を使って
スタックポインタ操作したりレジスタの待避・復旧などをやる必要があるが……。
モダンな処理系だと最適化だのなんだのの都合でスタックフレームを省略したりだとかもあるので
それらと協調しないとまともに動作しない。
たとえば gcc だと setjmp/longjmp の実体は
組み込み関数の __builtin_setjmp/__builtin_longjmp として提供されてる。
処理系自体の機能として持たないとちゃんと動作させられんのだ……。 >>713
九州大学の人工衛星・イザナミ/イザナギは、mruby だから、C 言語
ベンチャーで上場したらしい Windows処理系の場合SEHがあるからsetjmp/longjmpをわざわざ使う事ないよ
というか外部ライブラリ等から例外を受ける場合SEH必須だよ 名古屋にスターキャットというケーブル会社があるんですが、この名前もしや もとはstringなのは置いておいて
英語の発音だとストラの方が近い
まスチョラって感じだが
スターは無理だな >>731
英語はラテン語系じゃないから、最後にaの発音は付けないよ? >>732
敢えて「らりるれろ」で表現すると、どれに近いの。 C言語を256倍使う本にコードを音読せよと書いてあっただろ 会社などで開発してれば「ここのストラレンが~」とか言うだろ 俺はstrをストロと読んでる
ストロレン
ボッチナノデモンダイナイ 「そのすたーちゃー(strchr)使うのやめろよ言うまでもなくすたーあーちゃー(strrchr)もな」って言うかも
今更C言語の話なんてしないけどストラ云々なんていっても伝わらんのは判ってる 普通に
エスティーアールレン
エスティーアールキャット
エスティアールエスティーアール
って言ってる
stdioは
エスティディーアイオー ぶっちゃけローマ字でもバンドの名前でもstrをスターなんて読むこと無いだろ KAT-TUN かっつん
ONE OK ROCK おねぇオッケーロック
正しく読むのむずすぎだろ わかったアールだからアーって発音するのか
そんなん聞いたことないな
どこの界隈で言ってるんだ
それにstrならエスティアーになるはずではw strlen ストリング レン
strcat ストリング キャット
strstr …
stdio スタンダード アイオー
strcspn 使い方すら分からない >>748
つうかrはアーって発音すんだよ
まさかvをブイとか言わないよなw
vはヴィーだよ >>748
で、partyをパーリーと発音するように、tでアーと続くからラと発音してると思われる
ググるとフラップTと言うらしいな >フラップT は、 t が前後を母音に挟まれており、かつ、t を含む音節にアクセントが置かれていない場合に起こります。
全然ちゃうやんw
母音に挟まれてないしアクセントはターにあるだろ 英語を自分ルール作って勝手に読んでる奴は暗黙の合意をわかる能力が低いということ
これはコンピュータ言語でも同じだ
自分で標準ライブラリ作り直すくらいの覚悟ならいいが中途半端に自分流突き通す奴は上達しない >>756
突然どうしたw
tはラと発音される事が多々ある
適当にググったからルールの呼称を間違えたようだ
それだけの事だろ r の発音が難しいのであーる
と語尾を整えて欲しかった。 Let it ... DIE!
ttps://letitdie.jp/common/age-verification/index.html 今夜は Beat It ビレー
今夜は Eat It イレー 静的記憶域期間をもつ、文字列リテラルの正体をおしえてください。 文字列リテラルは、アドレス(ポインタ)でもあるんですよね? >静的記憶域期間
この表現って誰に教えて貰いました? >>767
文字列リテラルの型は文字の配列。 つまり型名で言えば char[ほにゃらら] ってこと。
配列がその先頭要素を指すポインタに (一部の例外を除いて) 暗黙に型変換されるルールによって
式の中ではポインタとして使えるけど文字列リテラルというオブジェクトの実体は配列。
配列と関数はちょっと変則的な暗黙の変換があるので
そのあたりはルールを丸暗記してもらうしかしょうがない。 i386の
msg: db "hello"
と
ary: dd 65, 66, 67
はどっちも配列!
故に文字列リテラルも配列か char moji[]="HELLO";
はBASICの
100 RESTORE DATA_HELLO:READ MOJI$
110 *DATA_HELLO
120 DATA "HELLO"
ってイメージ・・・などと意味不明な(ry 友達が二分探索のアルゴリズムを組んでコードがコンパイルを通ったんだけど、実行するたびに、ターミナルの画面が真っ白になるらしい。原因として考えられるのは?やはりメモリ関連のミスですか? これだけの説明で原因を特定出来たら、そいつは神かもしれない >ターミナルの画面が真っ白になる
プログラムの動作結果でこういう現象は起きるものなのか?
動作環境はなんだろう。 とうせバイナリ表示してansiエスケープになってんだろ >>778ですけど、ネットで知り合った外国人なので、詳しい開発環境やら聞いているんですが、返信がないんですよ。きっと半狂乱になって格闘してますよ >>784
外国人このスレに呼べよ
英語に自信がある猛者が揃ってるぞ 英語に自信のある猛者がスターキャットやスタジオヘッダーと言っているスレなのか。 >>787 🤣
>>786 was trying to write a binary search algorithm in C using functios..
The compiler was okay but whenever I tried to run it, the terminal was just blank
上記のチャットを受信してから、コード、コンパイラ、OSを教えてくれ、って送信しても返事がないんですよ そりゃネットで知り合ったやつにパソコンの情報教えるってリスキーだからな
聞いてるお前もリテラシーないよ 情報経って、個人情報ではないぞ
リスキーなら、そもそもそんな話をネットで言うなよ このスレ老人の集いみたいなとこあるからな
実名住所晒してたインターネット黎明期までのリテラシーしかないんだろ 質問です。
現在書籍の方の苦CでC言語の基礎を勉強しているのですが、なかなか基礎が身についた感じがしません。
どのように勉強すれば、C言語の基礎が身につけられるのでしょうか? 今更C言語を勉強する意味について、俯瞰的な視点で考える必要がある
さてあなたはどこで道を間違えたのだろうか 昔恋しい下町の 夢が花咲くC言語
よってらっしゃい よってらっしゃいお兄さん >>795
基礎は反復練習が必要
つまらないけど
筋トレだと思って毎日十分、コードを暗記するつもりで写経すると良い
おすすめはデータ構造とアルゴリズムのコード >>798
お返事ありがとうございます。
組み込みはとりあえずArduinoをやれば良いのでしょうか? >>799
お返事ありがとうございます。
反復練習の部分についてなのですが、苦Cには各章ごとに練習問題がありますが、それを繰り返しやるのでも良いのでしょうか? >>801
それでもいい
飽きたらネットで初心者向けのサンプルコード探してそれを写経すると良い
おすすめは文字列処理 まさにその通りで、勉強するものでなく、練習するものだと思います
まぁ、学問全体そういうものかもしれませんが 身に付くまでやれば身に付くという話だわな。
技能を身に付けている人は自分なりに小さなコツをたくさん発見したりはしてるかもしれんけど
この通りやれば簡単に身に付く!みたいな道筋をたどってるわけではない。
たくさんの本やコードを読んでたくさん書いてみるしか仕方ない。 意外と覚えるのは、間違えて、その間違いを見つけたとき
だから、数多く間違える事はとっても大事 つーかなんか作れよ
でないと身につく訳ねーじゃん
何で本ばっか読んでるんだ C は間違ったコードを書いてもエラーとして検出されない (そしてわけのわからんことになる) ことがよくあるから
あまり極端に知識が不足する状態でいきなりコードを書き始めるというのは良くないと思うが、
ある程度に知識を入れたら自分で考えて書かんと身につかんというのは確かにそう。
たとえばこうやって日本語の文章を書くときに日本語の文法を意識しないでしょ。
言語は当たり前のように使えるスタートラインなのでそこでいちいち考えない。
(引っかかりを感じて仕様を確認することもそれなりにはあるけど。)
考えなくてもスッと出てくる程度に身に付けるには実際に使って訓練するしかない。 Aiに聞きながら作る
アホな俺でもjaascriptでたくさんスクリプト作れるようになったぞ 枝ぶりの良い木に紐をかけ、首でぶら下がると、背が伸びるとか。
昔は、誰かの思いついた最強の仕様書に苦しむと、背を伸ばしたそう。 やりたいことがあって、その手段としてC言語を選んで学んだので。
けど今の環境だと手段が山ほどあるからCでなきゃいけないって理由が無いとすぐグダりそう・・・。 >>795
>書籍の苦Cで、C言語の基礎を勉強しているのですが
この本はやってみた系の本でしょ。
学ぶ内容が薄い
Ruby の女神・池澤あやかが言ってるけど、
大学のC の授業は、99% 挫折する。
Ruby on Rails みたいに、すぐウェブアプリ・データベースが動かないでしょ。
正常に動くまでに、ポインターで数年以上無駄にする
だから初心者はRails一択。
筑波大学も使っている、Railsチュートリアルのサイトで、
古いバージョンのRails 5 なら、無料で読める
まずこれでウェブアプリの作り方や必要な技術を学ぶ。
まずアプリの最終形を知っておく事が大事
文法やポインターが難しいCなどは、
アプリの作り方を知っている香具師がやるべきもの。
初心者じゃ、数年経ってもアプリを作る所までたどり着けないから。
だから挫折率99%
プログラミング学習は難しくて無駄だったという印象だけが残る。
機械語・アセンブリがそう。
こういう機械的な事を人間が学んでも無駄でしょ プログラミングは文学じゃないからw
機械と会話するのがプログラミング
何を馬鹿な事言ってんだと思うかもしれないが、それは先人が道を切り開いたから、ただ歩くだけで済んでる
で、そういう奴に限ってローコードやノーコードを馬鹿にすんだよなw
いや、行き着く先はそこだから
でも、悲観することは無い
本物のプログラマーはそのシステムを作る側になれるから キチガイに便乗するのは嫌だけど初心者にいきなりCはあかんやろ… >>802
ID:PhbAFJr0です。
お返事ありがとうございます。
分かりました。とりあえず、まずは練習問題を繰り返しやってみようと思います。
アルゴリズムとデータ構造のコードについてはネットで調べてみたところ少し興味を持ったので、練習問題が完璧になってきたタイミングで取り組んでみます。
ありがとうございました。 >>814
お返事ありがとうございます。
苦Cはやってみた系なのでしょうか?
一応ネットで調べてみたところ入門書であると書かれていたため、自分には丁度良いかなと思っていたのですが。
Railsについてはよくわからないので調べてみます。
ありがとうございます。 >>819
「苦しんで覚えるC言語」は仕様の細部を積み上げて理解しようとする本。
十分に解説しきれているかどうかはともかくコンセプトとしてはそういう感じ。
「やってみよう」タイプの本ではなく、プログラミングを始めるまでが長いところが苦しいんだ。
苦しい分だけ深い理解はできる。
よくある「簡単にわかる」系の本に対するアンチテーゼだと思う。
実践は実践してみりゃいいんだから本は理屈で支えるべきと私は考えていて、
その点からは好ましい入門書だと思う。
でも読むだけでは出来るようにはならない。 厳しいことをいうと、Cで嫌悪してるなら、業界に向いてないから 練習問題を繰り返す意味がわからんな
プログラム言語なんて所詮レゴブロックみたいなもん
ルール覚えたら後は自分で何作るかだろ Cはマニュアルトランスミッションと言える
今はスポーツカーですらオートマで運転出来るが、Cを知らないというのは、プロのレーサーがオートマしか扱えないと言ってるに等しい
オートマ限定の自称プロがコードを書いてるのが現状 解きたい問題に対して適切な言語選ぶだけの話
cはマニュアル車とか的はずれ マニュアル車は的外れだと思うけど、コンピューターでメシ食おうとしてる人間がCと言うかコンピューターの仕組み知らないのはどうなんだ >>827
コンピューターの仕組みって言っても幅広いし全部知ってる必要なんてない
自称C言語使えますってやつでもキャッシュ最適化なんてできないやつがほとんどだろ 別にCPUやらOSやら設計できるレベルの知識持てとは言わんけどポインタ理解できないのでC使えませんとか言うレベルの人に仕事任せたいとは思えん 本題と関係のないところで評価してしまうのは日本人の悪いところだな 流行りのPythonやJavAでも良いけどさ
Cのイロハくらいは理解しておいた方が良いよな
色んな言語のベースになってるし
何よりメモリアドレスやらの理解が深まる Cは純粋にコンピュータの知識でイケるけど
最近流行りの高級言語は余計な概念まで覚える必要があるからなぁ Cがマニュアルというのは的外れ言ってんのは知ったか野郎だろ
Javaや比較的Cに近いGoと根本的に違うのはメモリ管理だろ
Cはオブジェクト指向をサポートしてないからそれは除外するとして、それ以外の違いはメモリ管理って事
手動でするか自動(ガベージコレクション)でするかの違い
手動ですれば効率が良くなる所も同じだ >>818
Cはメモリ管理が自前だからマニュアル車だな
俺はオートマ限定だけど gccで、今風のアトミックな変数処理って何を使うの?
テストアンドセットとかインクリメントとか >>838
C11 以降には _Atomic キーワードがあって型指定子もしくは型修飾子として使える。
stdatomic.h には関連した型やら関数やらがある。
仕様としてはオプショナルなので提供していない処理系はあるが GCC はサポートしてる。
実体を辿るとビルトイン関数だからそれを直接使ってもいいけど
言語仕様にある範囲で書けるならそのほうが現代的なんじゃないかな。 >>809
プログラマ最上階級の形式言語屋は言語を学ぶ事自体が目的だけどめっちゃ伸びるだろ >>818
アルゴリズムとデータ構造とか、
プログラミングのお題スレの問題などは、
それこそRuby で学ぶ・作るべき
ガベージコレクションがあるから、ポインターでメモリの事を考えなくてよい。
C/C++, Rust など、メモリを特別に扱う言語は、
仕事で給料をもらいながら仕方なくやるもの
趣味でやるものじゃない。時間の無駄。
特に初心者には言語の文法よりも、
アプリを作る時に、どういう手順・技術が必要なのかとか、全体像が大切。
細部を勉強しても、その言語の仕事をやらなければ意味ないから
全てのシステム・アプリに共通する事を勉強する方が、知識を転用できる。
それがRuby on Rails。
最も有名な基礎となるフレームワーク
ループ処理であるEnumerable の所を見れば、どういう感じでアルゴリズムを書くか分かる >>842
お返事ありがとうございます。
ID:dWGmqWr20です。
現在はC言語をやっているのですが、いずれC++をやりたいと思っているのでRubyは興味が持てたら試してみたいと思います。
ありがとうございます。 Ruby の構文解析器が巨大なのは有名な話だろう。
素朴な C コンパイラの三倍くらいの大きさはある。
それだけ複雑な文法ということだ。
Ruby が言語の細部を学ばずに扱えるものであるかのような意見に対しては受け入れがたい。
メモリ管理については (入門者が) 後回しにするというのはそれなりに納得のいく意見だけれど。
人によっては元々の感性に上手くはまれば少しばかり複雑でも楽に自然に使えることもあるし、
Ruby が多くの人にそうなのかもしれないけど客観的には比較的複雑な文法を持ってるよ。
そういった合うかどうかを脇に置けば理解の助けになるのは単純に知識の分量で、
分量に圧倒されずに学習し続けるのはモチベーションによるところが大きい。
やりたいことやりなよ。 プログラム板で一番嫌われているのが Ruby
その理由をよく考えてから人に勧めて下さい Matzは言語オタクかもしれんがCSの教養が感じられない
だいたいPerlの命名真似てRubyとか発想がクソダサい そりゃ、Ruby はオブジェクト指向でクラスもある。
だから、クラスを派生させるだけで、シンプルに書ける。
つまり、コンパイラが頑張っているから、開発者は簡単に書ける
C では、そんな短時間で動くアプリは作れない。
開発時間のほとんどが、ポインターとメモリ確保・解放でバグる言語
既に、慶応卒のRubyの女神・池澤あやかが言ってる。
大学でのCの授業は、99% 挫折すると
授業料を損した挙句、プログラミングが嫌いになるだけ。
授業を受けた生徒が言ってる
結局、彼女は山陰地方の合宿で、Ruby on Rails を学んだ。
筑波大学もRails チュートリアルを使っている 95年あたりに大学の情報工学科入ったら
Pascal、C言語、Fortranの授業が必須科目だったわ。
OSはDOS(Win3.1インストール済み)とUnixだった。 ちなみにRubyはほとんどCで書かれてるぞ
だとするとRubyはバグだらけってことだなw そんなにメモリを管理したくなければ、Boehm GC使えば良いだろ
malloc→GC_MALLOCに置き換えるだけ
RubyもGCを使ってるからCで書いてるコードにメモリを管理するコードはほとんど無い >>849
B言語とC言語は誰が作ったか調べろよアホ 数百行程度のC言語プログラムだと、いきなり書き始めることがあって
書いてる途中で、「あ、いけね、これも」って直しが入ったりしていた
そうすると、エリア不足でメモリ破壊したり、初期化忘れで値が不正になったり
それはそれで楽しかったな >>862
人類ではなく、バカ犬共だよ
世の中、とんでもないバカ犬がいるからな かきを最新AIに重箱の隅をつつく用意尋ねましょう
全ての電磁波は強い低周波も高周波も被爆する?
電磁かいが強い場所は20Hzと55Hzは磁気閃光これも被爆している.?
音波も強い場合は被爆する?
※自然界の化学科学の観測結果論文と人間の人工物で可能な化学と科学論文を読み込ませておく
是者と校舎を別々で回答する用意する
さらに制度を挙げるなら
グレーゾーンの論文をできるともいえるしできないともいえる用意認識させる
現在の科学が正しいのならなら電磁波攻撃はこのグレーゾーンの論文を使用しているので逃亡できている?
統合失調症電磁は音波なら周囲の者被爆している!?
寿命が短いのと免疫力低下起きて当然 GPT4-Vの100分の1のサイズで同等の性能を誇るマルチモーダルモデル「Llama 3-V」が登場、トレーニング費用はたった8万円
2024年05月29日 14時00分
OpenAIがサム・アルトマンCEOを含む「安全・セキュリティ委員会」を設置、さらにGPT-4後継モデルのトレーニングを開始
2024年05月29日
「毒杯飲む直前どんな気持ちだった?」ソクラテスと対話できるAIを開発!
2024.06.04
※対象者【被害者】そっくりの返答が可能
たった数秒の音声データから音声合成が可能な「VoiceCraft」
2024年04月16日 07時00分
OpenAIがわずか15秒の音声からクローン音声を生成できるAIモデル「Voice Engine」をリリース
2024年04月01日
会話相手を数秒見つめて声を登録するだけでその人の声だけを聞くことができるAIヘッドホンシステムが開発される
2024年05月30日
※対象者の声を個別に録音 C-- (マイナス) ってあるのかな? とググると、あった。
ttps://github.com/tctsigemura/C--
C-1.0 (マイナス1.0) は当たらなかった。 グーグル、資料のわからないところを最新AIに質問できる「NotebookLM」日本版公開
https://ascii.jp/elem/000/004/202/4202481/ 「毒杯飲む直前どんな気持ちだった?」ソクラテスと対話できるAIを開発!
2024.06.04
リコーと理研、技術の実用化の“兆し”を察知するアルゴリズムを開発
2024/06/05
グーグル、資料のわからないところを最新AIに質問できる「NotebookLM」日本版公開
2024年06月06日 認知するから、住所氏名連絡先電話番号をここに書いて >>888
モーターが回ってぐるぐるアームが動いたりカパカパ蓋が開いたりするギミック作りたいんだけどArduinoの延長線上にありますかね? >>889
モーター扱ったことないですけど、モーターを動かすサンプルはarduinoにあったと思いますよ。 制御対象の特性を理解してないとマイコンに詳しくなってもちゃんと制御できないからなぁ……
電子工作の経験があって Arduino を導入しようと考えてるならやればいいんじゃないのと思うがこれから入門という段階なら初手で Arduino からってのは変な学習ルートに思える。
でもやりやすさは人によるので興味をもったらどこからでもやってみればいいんじゃないの、たいして高級品ってわけでもないし。 全ての波【電磁波】で下記の症状が起きる
理由は電磁波が強いために起こるか電磁波が通過すれば磁気が生じて鉄分が振動して間接的に鼓膜などが振動する
マイクロ波聴覚効果を用いた音声伝送に関する検討
2018/03/05
https://www.bookpark.ne.jp/cm/ieej/detail/IEEJ-ZT181039-PDF/
マイクロ波聴覚効果 Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E6%B3%A2%E8%81%B4%E8%A6%9A%E5%8A%B9%E6%9E%9C
>>マイクロ波を照射された被験者は、クリック音やブザーのようなうなり音が聞こえる
早大、物質中の創発磁気モノポールに起こる集団振動現象を理論的に発見
2024/06/04
https://news.mynavi.jp/techplus/article/20240604-2958879/
理研、電子ビームの電子回折をアト秒で制御できる技術を開発
2024/06/06
https://news.mynavi.jp/techplus/article/20240606-2960578/
※電磁波も振動させれると記載あり
最低でも下記ノ電磁波の威力が必要なら行っている者全員補足されている
GPSの電波は超微弱
https://gigazine.net/news/20240421-gypsum-gps-receiver/
[22]米国特許5868100号
【GPS位置情報を使用した動物コントロール・システム】
一例ですが年々受信機の感度は向上している
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
https://news.mynavi.jp/techplus/article/20240607-2961238/
電磁波音波攻撃をされている部位ごとにホルモンや異常物質などの観測
パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
https://www.asahi.com/articles/ASS652V7RS65ULBH00GM.html AIの性能が上がれば世界情勢が見えてくる
にゅーーすで話していることもそれらしきことを話すようになる
まづボイス・トォ・スカルが存在している場合としていない場合を問う
そのあとに人間の行動をどのように行動するかを問う
交友関係全てわかる範囲で入力しておく
社会っ情勢を知るにはさらにどういった役職等も調べておく
自分が使用しているボイス・トォ・スカルを本物か偽物化も割り出せる ボイス・トォ・スカル
電磁波音波攻撃が判明する
人間は電磁界を発生させている
※被害者の身体に痕跡あり
パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
名市大、頭蓋内全体の脳脊髄液の動態をマクロ的に観測する手法の開発に成功
2024/06/07
早大、物質中の創発磁気モノポールに起こる集団振動現象を理論的に発見
2024/06/04
理研、電子ビームの電子回折をアト秒で制御できる技術を開発
2024/06/06
分子研など、金ナノ粒子が円偏光の左右選択性を70倍に高めることを発見
2024/06/06
弾性乱流と古典的なニュートン乱流との共通点を発見――弾性乱流を記述する数学的理論の開発に寄与 OISTら
2024-5-29
京大、テラヘルツ波の照射で超伝導体の臨界電流を制御できることを実証
2024/05/28
産総研など、1000個以上の量子ビットを制御可能な超伝導回路の原理実証に成功
2024/06/05
名大など、水素原子の約1/20の超高精度で収差補正できるX線顕微鏡を開発
2024/05/09 細胞の内部を鮮明に観察できる蛍光顕微鏡技術を開発 阪大など
2024/05/07
OIST、有機電気化学トランジスタのON時に生じるタイムラグの原因を解明
2024/05/07
並行世界でタイムリープを繰り返す!?効率的な新しいシミュレーション技術
2024.05.22
東大、電子回折パターンの減少とエントロピー増加の対応を実証
2024/06/03
理研など、「スキルミオンひも」の観察とその詳細な融解過程の記録に成功
2024/05/23 19:29
東大など、金属3Dプリント中の2D画像から3D多孔質構造を予測する手法を開発
2024/06/03 >>885
A チュー
B モミモミ
C パンパン
D オギャー 日常的な蓋内全体の脳脊髄液の動態をマクロ的に観測する手法の開発に成功
2024/06/07
https://news.mynavi.jp/techplus/article/20240607-2961214/
細胞の内部を鮮明に観察できる蛍光顕微鏡技術を開発 阪大など
2024/05/07
https://news.mynavi.jp/techplus/article/20240507-2941335/
脳が鮮明に見える!世界最強の磁束密度で脳をスキャンするMRI「イズールト」
2024.04.05
https://nazology.net/archives/148090
※5分で全身スキャン完了するのかな 電磁波兵器の特許情報/Google検索で下記が判明
電磁波過敏症 低周波騒音被害 の症状が出現
設立 1998年 テクノロジー犯罪の撲滅
Https://media.toriaez.jp/s2972/32686.pdf
P77-身体・運動機能が遠隔から操作される P78-五感が遠隔から操作される
ギャングストーキングと電磁攻撃 - 広島修道大学学術リポジトリ
https://shudo-u.repo.nii.ac.jp/record/3395/files/SG63205.pdf
下記を頭部などで再現
人間の「第六感」 磁気を感じる能力発見
2019/03/19
https://www.sankei.com/article/20190319-6UGPQVLP4BLEDJYGVSX3WW6A4A/
髪の毛ほど薄いのに音を75%カット!MIT開発の「革新的防音カーテン」
2024.05.13
https://nazology.net/archives/149896
言葉に出さずとも内なる声を解読する、脳の読み取り装置が解発される
2024.05.20
https://karapaia.com/archives/52331884.html >>900
じゃあ、D はウギャー?(遊びで抱いた女が妊娠したのが分かったときの男の悲鳴) 標準ライブラリとランタイムライブラリ
前者は普段お前らが呼び出して使うやつ
後者はコンパイラが実行時に呼び出すように仕込んでるやつ printf( "あぼん続きで未読がマークが外れんのじゃ!" ); レス数が900を超えています。1000を超えると表示できなくなるよ。