C言語なら俺に聞け 141 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/07/17(月) 21:06:47.63

C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

前
http://mevius.2ch.net/test/read.cgi/tech/1494508803/
http://www.geocities.jp/c_cpp_cs/about_c/

**デフォルトの名無しさん** · 2017/07/23(日) 00:32:19.27

>>155
そう
作り方が下手なだけで言語やツールのせいする奴多すぎ
技術屋としてのレベル/精度が低いだけ

**デフォルトの名無しさん** · 2017/07/23(日) 01:06:53.41

ちょっと補足しておく。

俺が思うに、容量的に問題がないのであれば、
大体の場合はmallocではなくallocaで実装でき、当然、管理する必要もない。
だからCはもうちょっとalloca推奨でもいいとは思うし、
そのためにもうちょっとスタック領域に多めに割り当ててくれとも思う。
(コンパイラがallocaをmalloc+freeに分解し、呼んだ関数の末尾でfreeしてくれてもいい。
そうすれば容量の心配ないallocaが手に入るから。
てかこれやってるコンパイラないんか？誰でも思いつきそうだが)

**デフォルトの名無しさん** · 2017/07/23(日) 01:43:34.81

んー、イメージ的には、組み込み系が多そうだしcならヒープ使った方がいいきがする。

小メモリで済むのはc最大のアドバンテージだと思うんだ。

**デフォルトの名無しさん** · 2017/07/23(日) 02:13:19.95

>>155
なんでC with lambdaならスクリプト言語の方が手っ取り早いのか全くわからん

**デフォルトの名無しさん** · 2017/07/23(日) 08:51:27.89

> 構造化プログラミングだから同一関数内での確保＆解放が多いし。

このフワフワした一文だけで、今後こいつからは何の情報も得られないのが分かる

**デフォルトの名無しさん** · 2017/07/23(日) 11:07:58.09

>>155
生でもきちんと管理していれば問題は起きないが
いちいち気にしなければならないことが多いので
もうずっと付けてた方がいいよねという話ですよ

**デフォルトの名無しさん** · 2017/07/23(日) 15:05:48.85

>>153
designated initializerが使えないのでワースCだ

**デフォルトの名無しさん** · 2017/07/23(日) 16:32:54.76

>>162
これか。
https://stackoverflow.com/questions/18731707/why-does-c11-not-support-designated-initializer-list-as-c99
つか入れない理由ないし、ClangとVSでは使えるとも書いてあるが、
C++仕様自体は無駄に意識高くて無視しているといったところか。

一部C++がCの完全上位互換ではない部分があると聞いたが、これか。
他にあれば、キーワードだけでも教えてくれれば助かる。

**デフォルトの名無しさん** · 2017/07/23(日) 16:48:41.41

tentative
restrict
_Imaginal
_Thread_local
_Generic
_Bool
extern const
storage class "auto"
pointer to register

**デフォルトの名無しさん** · 2017/07/23(日) 17:18:38.88

>>164
サンクス。感想は以下。
俺には我慢できる範囲だな。

tentative <- 要らん、つか廃止の方がいい
restrict <- ねえのかよ！しかし自動並列化とかしない限り要らん
_Imaginal <- class があるから要らん
_Thread_local <- これはC++にあってもいいと思うが、、、
_Generic <- マクロがらみか？価値は俺にはよく分からん
_Bool <- boolが既に拡張済みだから要らん
extern const <- 個人的にはconst派ではないからいいや
storage class "auto" <- なんだこれ？いわゆる自動変数って全部これだと思うが、、、
pointer to register <- registerそのものが最早要らんし

**デフォルトの名無しさん** · 2017/07/23(日) 17:56:02.81

>>163
コンパウンドリテラル
(float[2]){1,2}

**デフォルトの名無しさん** · 2017/07/23(日) 19:12:51.83

>>166
designated initializerと同じに見えるが違うのか？
前者は初期化、後者はリテラルとして使ったときの呼称か？
http://seclan.dll.jp/dtdiary/1999/dt19991101.htm
http://d.hatena.ne.jp/taiyo/20080412/p1

**デフォルトの名無しさん** · 2017/07/23(日) 19:28:51.61

全く違う

**デフォルトの名無しさん** · 2017/07/23(日) 19:30:48.75

>>165
tentativeがないくせにテンプレート具現化の統合という
同じベクトルでもっと面倒くさいのがあるわけだが

**デフォルトの名無しさん** · 2017/07/23(日) 19:38:30.48

>>167
ファッションとして「ベターC」と言いたがってた事はよくわかった

**デフォルトの名無しさん** · 2017/07/23(日) 20:01:31.75

「ベターC」を名乗るのになんか条件ってあるのかね？
個人的には、K&Rは時代遅れのC、C89が普通のC、それより改善されているのがベターC、ってな感覚だが。

**デフォルトの名無しさん** · 2017/07/23(日) 20:09:09.26

>>171
俺の理解では、C99がC、
それにC++の機能(class等）をつまみ食いした「ほぼCだけど、、、」がbetterC。

**デフォルトの名無しさん** · 2017/07/23(日) 20:26:36.42

>>171
条件はない
"Cの後置増分"とは、"最初はC"でよいという意味だ
そこから段階的にソフトランディングで移行できることが
C++の売りなので、気まぐれにつまみ食いすることは
実はC++らしい使い方の1つといういことだ

**デフォルトの名無しさん** · 2017/07/23(日) 20:35:47.04

C99以降の機能を使いだすとC++でビルド通らなくなるし
Cを使わずベターCとしてC++使うなら、C99/C11を知るは必要ないでしょ
Cっぽいものが書ければ十分

**デフォルトの名無しさん** · 2017/07/23(日) 20:39:42.68

ベターな部分がないのに「ベターC」 w

**デフォルトの名無しさん** · 2017/07/23(日) 21:05:01.13

あぁなるほど、C99が基準だとC++は劣化Cに見えるわけか。
ただ、一般には「ベターC」という言い方がされたのはC++に対してだと思うがなぁ。

**デフォルトの名無しさん** · 2017/07/23(日) 21:06:32.74

ヒント：　煽り耐性

**デフォルトの名無しさん** · 2017/07/23(日) 21:14:20.95

>>175
よく分からんが君は生C派なのか？
正直俺はbetterC派とC++派しかもう居ない（生C派は絶滅済み）と思っていたのだが、
昨今のC++の暴走を見てると生C派が健在なのも分からんでもない。Linusもそのようだし。

ただ、classとかtemplateとかは「控えめに使っている限りは」便利だと思うぞ。
C++erは無理に活用しようとしておかしなことになっているが。

>>176
俺の理解では、
Cでは機能が足りないが、C++の機能は行き過ぎ（やりすぎ）、と思う人達が、
CとC++のちゃんぽんをbetterCと呼称している。

**デフォルトの名無しさん** · 2017/07/23(日) 21:17:33.70

>>175
関数オブジェクトとラムダ式

**デフォルトの名無しさん** · 2017/07/23(日) 21:25:32.16

>>176
あ、もしかしてそれ以前のことか？
それなら、Objective-CとC++の対比で使われ、以下wikiの通りだ。
> Objective-CはCを拡張してオブジェクト指向を可能にしたというよりは、
> Cで書かれたオブジェクト指向システムを制御しやすいようにマクロ的な拡張を施した言語である。
> したがって、「better C」に進んだC++とは異なり、「C & Object System」という考え方であり、
> ある意味2つの言語が混在した状態にある。
> https://ja.wikipedia.org/wiki/Objective-C

ただし、Objective-Cはかなり前から実質的に死亡していたので、
最近「betterC」って言われているのは「CとC++のちゃんぽん」のはず。
要するに「いいとこ取り」をしようとしているのがbetterC。
C++の流儀で全部書け、というのがC++。
うるせえC++なんて全部ゴミだ、というのがC。

**デフォルトの名無しさん** · 2017/07/23(日) 21:34:26.02

>>178
今のC++は、かつてのC++の暴走に対する反省でできているぞ
void func() throw(std::bad_exception); みたいな馬鹿げた話が
void func() noexcept(false); で済むとか
std::bind1stだのstd::bind2ndで3rdや4thがないなんて馬鹿げた話が
std::bindだけで済むだけでなくstd::mem_funとstd::mem_fun_tもクビ
char* port = (char*)0x40044000; みたいな二度手間も
auto port = (char*)0x40044000; で済む

**デフォルトの名無しさん** · 2017/07/23(日) 22:02:06.01

C++普及始めはベターCって言うとC++使いこなせなくてC++でもC文法を良く使うって意味だったみたいなんだが、今はオブジェクト指向も浸透して、その長所短所も洗い出されて来たからいいとこ取りって意味って理解。
でも、今も昔も両者が混在してるんだと思う。

**デフォルトの名無しさん** · 2017/07/23(日) 22:04:03.65

>>181
上2つはそれでも暴走中だとは思うがな。
GC無いと関数型は辛くね？
例外は俺は積極的には使ってないのでよく分からない。

下1つは、俺はC的記述、
> char* port = (char*)0x40044000;
の方が好きだな。
キャスト無しで書かせてくれとは思うが、型は左辺側に書きたい。
それとは別に、autoの価値も認める。リフレクションとかでマジで死ねる。(VC++/CLI)
だけと他言語と揃えてvarにしろよとは思うよ。なぜauto？

**デフォルトの名無しさん** · 2017/07/23(日) 23:15:19.12

Cじゃなくて全くの別物を「ベターC」と謀って何をしたいんだ?

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/23(日) 23:29:44.60

>>183
昔、autoというキーワードがあったが、あまり使われなかった。そこで新しいキーワードを作るよりも、
使われていないキーワードを再利用した方がいいと判断された、らしい。

**デフォルトの名無しさん** · 2017/07/23(日) 23:30:25.51

registerもそのうち使い回される

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/23(日) 23:35:53.82

キーワードが増えると、キーワードと同じ変数名や関数名はコンパイルできなくなるという問題がある。

**デフォルトの名無しさん** · 2017/07/23(日) 23:53:29.52

>>183
さあ？　俺はGCがないことにストレスを感じたことがない
あんなもんいらねえ、つーか却って迷惑
機械という奴隷は完全に支配したいんで

**デフォルトの名無しさん** · 2017/07/23(日) 23:58:37.14

>>185,187
> 記憶クラス指定子としての auto の使用が非常に少ないとの調査結果などから、当該用途は直ちに廃止となった。
> https://cpprefjp.github.io/lang/cpp11/auto.html
> storage class "auto" (>>164)
K&Rも確認して、なるほど状況は分かった。autoはまあ許せる範囲か。

しかしこれ、autoとregisterがあったということは、
元々のコンセプトのデフォはもっと遅い外部メモリかよ。（コアメモリとか？)

**デフォルトの名無しさん** · 2017/07/24(月) 00:18:45.69

>>189
autoは記憶クラスのデフォルト
省略可能で、むしろつける理由がなかったのでだれもつかわなかった

registerは変数をレジスタに置いたほうがいいというコンパイラへのヒント
しかし、コンパイラの改良が進みコンパイラに任せたほうが良くなった
人間による指定は不要なばかりか、むしろ最適化の邪魔になるのでコンパイラは無視するようになった

**デフォルトの名無しさん** · 2017/07/24(月) 00:28:47.24

betterCは明確な定義はないだろうけど、
http://www.kijineko.co.jp/tech/betterc/1
で言われてるのが大体の認識なんじゃない？

（ライブラリの内部だけとかではなく）クラスとかを使うならそれはもうC++でしょ
メモリ管理とかvtableの仕様とかもしっかり確認する必要があるので適当にクラスを使うのはおすすめしない

**デフォルトの名無しさん** · 2017/07/24(月) 01:07:47.78

>>188
君はおそらくbetterC派だよな？（ただしほぼC++の)
ちなみにどういう組み合わせで使ってる？

GC言語と非GC言語ではそもそも組み方が違う。これは全く>>156の指摘どおりで、
しかもその後3匹馬鹿が現れて(159-161)彼の言い分が証明されてしまったw

さて関数型だが、どれくらい使っている？
俺はマトモには関数型をやってはいないが、それでも分かる範囲で言うと、
関数型言語はGC+型なし（型推論）が多い。
これに対しC++で関数型的アプローチを取ると、
型が爆発してtemplateで書くにしても大変でウザい。マジでvarくれよ、になる。
そして決定的に異なるのは資源のライフタイム管理で、GC言語はこれをやらない。
C++は一応自分でやることになっているのだが、
上記の通り、他関数型言語はGC前提なので組み方が異なっており、本来は参考にならない。
そしてC++のラムダはスタック方式に強引に載せている、なんとも中途半端なものだ。
これは全く他関数型言語のスタイルにはフィットしない。

だからC++で関数型アプローチをする現実路線としては、
C++をGC言語側に寄せる手法、つまり、
・ラムダは完全に関数オブジェクト扱いで、クロージャ変数は主にヒープ上
・スマポ、RAII徹底
という、いわゆる今のC++erが目指しているものに近くないと辛いはず。
ほぼC++寄りのbetterCというべきか。

君のスタイルはこれで合ってるか？合ってたらGCイラネってのも納得だ。
合ってなければ、どの組み合わせで使っているのか教えて欲しい。参考にする。

**デフォルトの名無しさん** · 2017/07/24(月) 01:33:19.39

>>190
autoがデフォか。なるほど了解だ。

>>191
> クラスとかを使うならそれはもうC++でしょ
> メモリ管理とかvtableの仕様とかもしっかり確認する必要があるので
ここはちょっと微妙。
まずvtableはプログラミングモデルとしては見えないので知っておく必然性はない。
（もちろん知っておいたほうがいい）
次にメモリ管理だが、C++に関してはclassとstructがほぼ同一なので、
C的に自前classをnewして自分でdeleteするという使い方も出来る。(A)
そうではなくて、デストラクタとかやりだすとややこしくなってくるが、(B)
最終的なC++erの目標、コンテナ等にも問題なく載るように、となると、
ムーブコンストラクタ等のC++的お作法を全て実装しておかないといけない。(C)
俺は(A)ならC、(B)ならbetterC、(C)ならC++と呼ぶね。

多分CとC++のコンセプトの根本的な違いは、
Cは厳密に「書いてないことはやらない」なのに対し、
C++は「出来る限り全自動を目指す」だと思う。
だから、「どこまで自動化しようとしているか」で測ればよいと思う。

**デフォルトの名無しさん** · 2017/07/24(月) 02:16:26.89

>>193
うーん、その定義のbetterCは誰向けなんだ

初心者はC++の仕様（fwriteをvtableのあるクラスに使っちゃったり、newしたのをfreeしたりみたいな）にはまるだろうし
中級者はどこまでがbetterCなのかで混乱しそう（参照は？とかスマートポインタは？とかstringは？とか）
上級者はbetterにすることなく快適にCかC++で満足してそう

クラスとかデストラクタだけ使うみたいな方針で書かれてるソフトって何があるの？

**デフォルトの名無しさん** · 2017/07/24(月) 02:58:28.33

ベターperlのruby使おうぜとか言いだしそうだなアホか

**デフォルトの名無しさん** · 2017/07/24(月) 02:59:30.11

基本Cで行きたいけど、クロージャが作れないことだけはどうしようもないのでそこだけC++って考えるんだけど、上級C使いはクロージャいらんのだろうか？

**デフォルトの名無しさん** · 2017/07/24(月) 04:31:31.88

いらない

**デフォルトの名無しさん** · 2017/07/24(月) 05:34:01.73

>>192
あ？　俺はバリバリC++使いだよ
ベターCをやっている認識は全くない

GCの話に型推論が出てくるのは悪いが意味わからん
varが欲しいんならtemplateは関係ない（脇役にすぎない）し
typeidやvoid*で特注品を作ればいい（COMとかみたいに）
ラムダ式もGCには関係ない（脇役にすぎない）し
ステートレスラムダみたいにスタックを使わないのまである

クロージャ変数はヒープ上って何だ？
auto closure{[&]{}};
auto heap{std::make_shared<decltype(closure)>()};
みたいなことすんのか？
ちょっと変態すぎて俺はついていけないなあ

俺はスマポ使うが生ポも普通に使う
状況で使い分けだ

RAIIつまりunwindingはGCとは全く無関係

RAIIだとかpImplだとかは一応知ってるが
そういのの原理主義にとらわれて
自分の頭で考えるのをやめたらいかんと思っている

**デフォルトの名無しさん** · 2017/07/24(月) 07:34:15.05

RAII は便利なんだがなぁ‥

**デフォルトの名無しさん** · 2017/07/24(月) 10:04:09.53

>>189
ttp://zdnet2.cbsistatic.com/hub/i/r/2015/12/01/5e3590e7-725a-4d77-97cf-a64768d759a1/resize/1170x878/501ecb90884df8d47e13f80dffc6b0a7/42-53033264.jpg
水銀メモリ程度だろ

**デフォルトの名無しさん** · 2017/07/24(月) 11:30:39.90

>>189
今だってレジスタに比べればメモリは十分に遅い
キャッシュや最適化技術の進化で通常の利用では考慮する必要性が薄いだけ

**デフォルトの名無しさん** · 2017/07/24(月) 20:11:23.35

>>200
うわかっけぇ～～～～！！

**デフォルトの名無しさん** · 2017/07/24(月) 23:14:38.57

>>194
俺的には「C++へのかぶれ具合」でC/betterC/C++を判断しようとしてる。
もちろんclassだけではなく、他の機能でも同様に判断して、
どれが一番近いか（どう表現すると一番誤解が少ないか）という話だ。

classはC->C++時におそらく最初に使用する機能であり、
classを使った時点でC++ならbetterCってほぼなくなるよ。
文法でしか判断出来ない馬鹿も最近は多いけど、本質は組み方でしょ。

> クラスとかデストラクタだけ使うみたいな方針で書かれてるソフトって何があるの？
知らんよ。
では逆に聞くが、作者やその他大勢がbetterCだと認識している有名OSSってあるのか？
あるのなら、みんなでそれを見に行けば終わる話だ。
なお俺はこれも知らんよ。
V8のコードがC++流じゃないって言っている奴はいるが、俺は詳細確認してないし。
http://steps.dodgson.org/bn/2008/09/07/

**デフォルトの名無しさん** · 2017/07/24(月) 23:15:12.97

>>198
全面マニュアル派か。まあそういう使い方も出来るわな。
俺は嫌いではないよ。
というかＣ派からは割と賛同されるだろうね。C++派からは異端視されるだろうが。

> クロージャ変数はヒープ上って何だ？
ステートレスとか、キャプチャがなければどうでもいいし、
或いは糖衣とか、ローカル関数っぽく「その場で」使うのなら全く問題ないが、
一般の関数型と同様に可搬的に使おうとすると、生存期間はスタックとは独立にする必要があり、
スタック上の変数を参照キャプチャするのはまずい。
結果、クロージャ内変数の実体はスタック上ではなくヒープに置かれることになる。
これをそう表現した。関数オブジェクトは常にこうだろ。

> RAIIつまりunwindingはGCとは全く無関係
ユーザ側には無関係だが、システム側は密接な関係がある。
GCを効率化する場合、参照カウントというのは一つの代表的手段で、
この場合、ランタイム上で同じことをやるからだ。
だから「全面RAII+shared_ptr」ってのはよく出来たGCと実行効率は同じになる。
だったら最初からGC言語使えよC++erはアホなのか？ってのが俺の感覚だ。
効率ガーとか言いながら完全な二度手間してるのはテメーらだよ、ってこと。
ただし君はこれには該当しない。生ポも普通に使う派だからだ。

まあここら辺の「どうとでも書ける」という懐の広さもC++の魅力ではあるのだろうけども。
本来は君のような全面マニュアル派が正統C++派でもおかしくないんだが。
そういうコンセプトの言語ではあるから。
ただ最近おかしくなっている（気がする）のはやっぱり意識高い系の暴走なのかな？

**デフォルトの名無しさん** · 2017/07/24(月) 23:54:33.43

>>203
betterCの定義をしてる機関があるわけじゃないから人それぞれの定義で良いとは思う
俺の認識だとbetterCはC言語をC++モードでコンパイルする程度でもbetterCだと思ってる

#include <stdio.h>
int main(void){
int a = 1000000;
char *b = a;
}

Cだと(昔の寡黙なコンパイラは)そのまま通過。 C++だとエラーで停止。
今は警告出してくれるからこういう意味で使う理由はなくなったんだけどね
(ちなみに、VSで適当にプロジェクト作ると.cppファイルができてC++モードでコンパイルされる)

>classを使った時点でC++ならbetterCってほぼなくなるよ。
betterCってどういう意味合いにせよ現代だと初心者や趣味用で、もうほぼ存在しないってイメージだな

**デフォルトの名無しさん** · 2017/07/25(火) 00:58:02.32

void sendMessage(const char *message) {
char c;
for (const char * p = message ; c = *p; p++)
SPI.transfer(c);
}

このようなメソッドを実行する場合、他の単語のアドレスと繋がってバグが出る恐れはありますか？

--例--
const char *cd = "CD";
sendMessage("pen");

アドレス文字
1000000 p
1000001 e
1000002 n
1000003 C
1000004 D

**デフォルトの名無しさん** · 2017/07/25(火) 06:46:20.75

>>206
普通こうなるやろ

アドレス文字
1000000 p
1000001 e
1000002 n
1000003 \0
1000004 C
1000005 D
1000006 \0

**デフォルトの名無しさん** · 2017/07/25(火) 07:58:05.16

>>204
全面マニュアル派って何だ？

> スタック上の変数を参照キャプチャするのはまずい

え？　え？？
自動記憶域期間の変数以外の何をキャプチャするんだ？
クロージャ内変数がヒープ？？　いったい何を言っている？
struct closure{
int& reference_to_capture;
closure(int* capture) : reference_to_capture(*capture) { }
void operator()() {
int internal_variable_of_closure;
}
};
こうなってるだけだぜ？　どこにヒープが出てくるんだ？

**デフォルトの名無しさん** · 2017/07/25(火) 07:58:22.10

>>204

> システム側は密接な関係がある。

関係ねえって
some_class obj1;
jmp_buf jb1;
if(setjmp(jb1) == 0) {
obj1.construct(jb1);
some_class obj2;
jmp_buf jb2;
if(setjmp(jb2) == 0) {
obj2.construct(jb2);
obj2.destruct();
}
obj1.destruct();
}
こうなってるだけだぜ？　どこにヒープが出てくるんだ？

> 最近おかしくなっている

C++11以後は正気に戻る努力をしてるぞ

**デフォルトの名無しさん** · 2017/07/25(火) 08:31:48.45

知ったかクンの自己弁護ショーがはじまるよ

**デフォルトの名無しさん** · 2017/07/25(火) 16:02:02.91

全面マニュアル派って何だろう。
悪魔的＜＞全面マニュアル派　みたいなニュアンスなんだろうか。

あんまり聞いたことない言葉だな

**デフォルトの名無しさん** · 2017/07/25(火) 17:10:25.77

＜＞　ダイヤモンド演算子が出たぞ

**デフォルトの名無しさん** · 2017/07/25(火) 17:24:31.31

<>を何と読むかで、C++寄りかBASIC寄りかわかるな

**デフォルトの名無しさん** · 2017/07/25(火) 20:09:07.38

残念、perl でした！

**デフォルトの名無しさん** · 2017/07/25(火) 21:09:32.97

>>207
回答ありがとうございます
そのような仕組みになっているとは知りませんでした！
詳しく調べてみようと思います

**デフォルトの名無しさん** · 2017/07/26(水) 15:57:11.34

age

**デフォルトの名無しさん** · 2017/07/27(木) 03:13:21.18

>>206
ない。ダブルクォーテーションで括った場合は最後に \0 入るから。

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/27(木) 03:15:50.47

>>217
char s[3] = "123";
のときは'\0'が入らない。

**デフォルトの名無しさん** · 2017/07/27(木) 04:24:15.48

領域破壊で配列の直後のエリアに入ることは入る

**デフォルトの名無しさん** · 2017/07/27(木) 07:29:22.91

>>219
宣言時の初期化では入らんよ

**デフォルトの名無しさん** · 2017/07/27(木) 13:22:08.96

>>219
実名晒せよ、その下痢糞コンパイラ

**デフォルトの名無しさん** · 2017/07/27(木) 18:39:00.21

素朴な質問で悪いが、C言語ってなんで多くが挫折すんの？　JavaやC#なら、派遣でも生き延びていくのに・・・

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/27(木) 19:09:17.24

Cは、ポインターとかマクロとか落とし穴が多いんだよね。文字列を扱うのも難しいし。しかもセキュリティ上の欠陥がある。

**デフォルトの名無しさん** · 2017/07/27(木) 19:15:04.97

Cにセキュリティ上の欠陥？
使い方の問題でしょ？

**デフォルトの名無しさん** · 2017/07/27(木) 19:16:27.05

大昔に出来た低級言語なんだから、
多少の事は我慢

**デフォルトの名無しさん** · 2017/07/27(木) 19:17:38.76

Cは環境依存が激しくて、何やるにもめんどくさいからだと思うな。
コピペプログラマが生きていけない。

**デフォルトの名無しさん** · 2017/07/27(木) 19:24:01.58

ポインタとかもだけど、リストの使い方は知ってても作り方知らない子とか多そうだぬ。

**デフォルトの名無しさん** · 2017/07/27(木) 19:25:18.20

何のリスト？
初期化リスト？

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/27(木) 19:26:56.69

連結リストだろ、JK。

**デフォルトの名無しさん** · 2017/07/27(木) 19:41:55.89

いや連結リストの作り方知らない子はレアだから違うだろJK

**デフォルトの名無しさん** · 2017/07/27(木) 19:49:40.05

ごめん。
ただの偏見。
JavaやC#はListクラスで連結リスト使えるから、作り方知らない若者多そうって思ってた。
そうかレアか。
安心した。

**デフォルトの名無しさん** · 2017/07/27(木) 19:50:41.52

使い方
って書いてあるから
Cの機能にあるリストだと思ったのだが

**デフォルトの名無しさん** · 2017/07/27(木) 19:52:12.25

>>227が悪い

**デフォルトの名無しさん** · 2017/07/27(木) 19:55:40.06

>>232
Cにリストって有ったっけ？
ANSI C止まりだから、最近のは入ってるのかな。

>>233
ホントごめん。

**デフォルトの名無しさん** · 2017/07/27(木) 19:59:03.32

だから
初期化リスト？
って書いたんだけど

**デフォルトの名無しさん** · 2017/07/27(木) 20:11:05.11

初期化リストってなんだろ。。。

あれかな。

int a[] = {1,2,3};

みたいな奴か？
あんなん、数が100とか200になったらループで初期化とかになるから違うかな。
JavaやC#もその辺は変わらなかった気もするけど。

まあいいや。
迷惑かけたみたいだし、ROMるわ。

**デフォルトの名無しさん** · 2017/07/27(木) 20:28:21.83

>>222
C言語は同じことをするのにもいろんな書き方ができる。無駄に難しくも書ける。

**デフォルトの名無しさん** · 2017/07/27(木) 21:58:49.46

セキュリティ上の欠陥がある。
セキュリティ上の欠陥がある。
セキュリティ上の欠陥がある。

**デフォルトの名無しさん** · 2017/07/27(木) 22:01:29.56

>>238
株式会社メビウス(mob)
http://matsuri.2ch.net/test/read.cgi/infosys/1501121465/

**デフォルトの名無しさん** · 2017/07/27(木) 22:02:42.86

>>238
それ、欠陥じゃなくてそこまで理解して使用するものだから。本気で言ってんの？

**デフォルトの名無しさん** · 2017/07/27(木) 22:09:44.77

リーナス君ならどんな暴言吐いてくだろうかね

**デフォルトの名無しさん** · 2017/07/27(木) 22:10:30.95

リストの「作り方」って書いてあるのに初期化リストを持ってくる奴ってマジで近くにいてほしくないわ

**デフォルトの名無しさん** · 2017/07/27(木) 22:20:24.47

>>241
リーナスくんがメビウスに暴言？

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/27(木) 22:22:40.74

拳銃は危ないよなあ。原子炉の制御にC言語を使われたら、それは拳銃のように危ない。
Cを安全に使うには、安全装置とか哲学とか人工知能みたいなものが必要になる。
さもないとどこかの国みたいにハッキングされるだろう。

**デフォルトの名無しさん** · 2017/07/27(木) 22:31:06.10

>>244
原子炉の制御にC使ってるんじゃない？
むしろ、C以外の方が危ない気が。

**デフォルトの名無しさん** · 2017/07/27(木) 22:34:40.88

>>238
今時の言語の例外処理の相当する部分も自分で書くからねぇ。
安全じゃないと言えばそうだし、元々プロ向け言語って言われてたし。
そこに憧れて火傷する人は昔から多かった。
(自分含む)

**デフォルトの名無しさん** · 2017/07/27(木) 22:40:41.83

>>242
日本語読めないアホ

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/27(木) 22:41:49.10

あ、「C言語にセキュリティ上の欠陥がある」は、国家機密だからな。絶対に他のヤツに言うなよ。

**デフォルトの名無しさん** · 2017/07/27(木) 22:42:44.02

ツマンネ

**デフォルトの名無しさん** · 2017/07/27(木) 22:43:40.04

何がどう危ないのかわかってないやつが、ふわっと危機感もってるだけだろ

↓これと同じこと
http://zip.2chan.net/6/res/3050541.htm

**デフォルトの名無しさん** · 2017/07/27(木) 22:52:42.24

>>222
JavaやC#の方が簡単だから。

というか常識的に考えて分かるだろ。
世界は一旦Cで統一された。
その後出てきた言語はCの駄目なところを改善している。
それだけ。

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/27(木) 22:56:04.01

ダンディ坂野は危険。sprintfの代わりにsnprintf使え。セキュアバージョン(_s)を使え。とか色々あるよな。

**デフォルトの名無しさん** · 2017/07/27(木) 23:06:09.60

(σ・∀・)σｹﾞｯﾂ!!

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/27(木) 23:13:00.42

https://www.ipa.go.jp/security/awareness/vendor/programmingv1/b06_02.html

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/27(木) 23:41:43.77

標準文字列関数では安全に書けない、安全に書ける人がほとんど居ない。これ、完全にワナですから。