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/28(金) 22:53:05.56

>>310
> 拡張モジュールをサポートするため、Python API (Application Programmer’s Interface) では
> 一連の関数、マクロおよび変数を提供していて、
> Python ランタイムシステムのほとんどの側面へのアクセス手段を提供しています。
> Python API は、ヘッダ "Python.h" をインクルードして C ソースに取り込みます。
お前は日本語が読めないということが分かった。

それで、お前はいつ>>286みたいな記述が必要なんだ？
普通はPyxxxを使ってPython側から読み出して、
C側の演算高速化用フォーマット（通常はただの配列）に最初から変換するんだよ。
お前はC側でもリストを実装してPythonと同じ事をするアホのようだが。

**デフォルトの名無しさん** · 2017/07/28(金) 22:57:00.44

またパイソンの話してんのか

**デフォルトの名無しさん** · 2017/07/28(金) 22:59:57.49

>>309
本気で言ってるのか？日本語ドキュメントなんて限られてるから技術者はググるときは英語だろう。
しかもwikipの日本語のIT用語の項目なんてほとんどないぞ。日本はIT後進国だから。中国語のほうが充実してる。
その中にあってLLだけば日本語版だけが異常に充実してるという。
まぁ、日本語でググったけどLL言ってるのはWEB2.0、クラウド、AI言ってる輩だね。
C言語使わない、使えない輩だからおれには接点はないわ。どっちがズレてるかよく考えてほしいね。

**デフォルトの名無しさん** · 2017/07/28(金) 23:05:09.92

とりあえずお前は「無知でごめんなさい」から始めようか w
> LL言語側のリスト等の物理配置は公開されてないんだから、これは無理だろ。
> 仮に公開するにしても当然アクセス用API関数であって、内部構造は隠蔽されるだろ

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

>>313
面倒な奴
よほど恥ずかしかったんだろうな

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

>>314
> 仮に公開するにしても当然アクセス用API関数であって、内部構造は隠蔽されるだろ
お前マジで日本語読めないのな。Python.hってまさにこれなんだが。
日本語読めない奴と議論するのは無理だからもう諦めるが。

>>313
LLって海外でも普通に通じるよ。

**デフォルトの名無しさん** · 2017/07/28(金) 23:13:42.45

>>316
隠蔽の意味も理解してない奴に言われてもなぁ w

**デフォルトの名無しさん** · 2017/07/28(金) 23:16:01.92

スレチ

**デフォルトの名無しさん** · 2017/07/28(金) 23:20:19.95

>>315
そうなんだよ。聞いてくれよ。怒り心頭だよ。
日本語のwikipのLLの内容はマジで恥ずかしい。こんなアホ議論してるのは世界で日本だけ。

> この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。
> この節には独自研究が含まれているおそれがあります。
> 日本独自の用語・分類への批判
> 比較対象がないことへの批判
> 誤解を招く用語であるという批判

なんだこれ。こんな完全なバズワードを偉そうにLLすら知らないのかって言われたんだよ。

こんな用語使ってる輩の脳がLightWeightなのに。

**デフォルトの名無しさん** · 2017/07/28(金) 23:26:08.74

まあ俺が突っ込みたかったのは、

> 連結リストを一から作れるってそんなにいないんじゃないかな (>>277)
これはLL言語（＝習得が簡単な言語＝馬鹿用言語）ならそうだが、
Cなら作れない奴は殺される。ただしそれ以前に、

> 苦CとやさしいCには載ってなかったな。　(>>283)
のように、そもそもCではリストを使う機会はあまり無い。
だから載ってないのも妥当。

**デフォルトの名無しさん** · 2017/07/28(金) 23:32:35.71

仮にバズワードとしてもわざわざ2chで知らないアピールせずに黙ってググれば馬鹿にされることもなかったろうに

**デフォルトの名無しさん** · 2017/07/28(金) 23:42:53.57

確かにLL知らないで馬鹿にされた。だが今はもう違う。おれが馬鹿にする番。

LLなどという日本限定バズワードを使う胡散臭い輩がC言語スレで能書き垂れてんじゃねーよ、
英語もできんLightWeigt脳の低スキル技術者どもが。

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

>>322
「LL（言語）」ってのは通じる言葉だ。だから使う事自体は悪くない。
（正確にはLL言語だと「言語」が被るのだが、俺は「言語」付けた方が通じやすいと思う）

ただし通じる界隈は違っていて、LL言語と纏めて呼ばれるのは通常、
Perl/Python/Ruby/JavaScript等だから、ここら辺のユーザーなら確実に通じる。
実際、Perl/Python/Rubyなんて使用範囲もできることも同じで、区別する必要ないだろ。
だから纏めてLL言語と呼ばれるし、彼らもそれに慣れている。
C/C++/Java/C#等はこれらとは全く違うため、
この界隈では「LL言語」という言葉が使われることは少ない。
それだけ。

**デフォルトの名無しさん** · 2017/07/29(土) 00:02:27.03

スクリプト系言語でいいだろ。昔からそう言ってる。

**デフォルトの名無しさん** · 2017/07/29(土) 00:07:34.47

lol

**デフォルトの名無しさん** · 2017/07/29(土) 00:16:53.64

(lol)

こうすると顔文字のようだ。

**デフォルトの名無しさん** · 2017/07/29(土) 00:22:54.09

>>324
いやそれはちょっと違う。日本語版Wikiはちょっと広めに取りすぎている。
https://ja.wikipedia.org/wiki/%E8%BB%BD%E9%87%8F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E
実際のところ、俺の感覚では、以下だ。
Perl/Python/Ruby/JavaScript <-100%LL言語に含まれる
PHP/Lua <- LL言語に含める奴もいる。割合は50%位か？
AWK/bash <- LL言語に入れる奴はいない。これらはスクリプト言語と呼ばれる。

旧来の「スクリプト言語」はフルセットの機能を持っていなかった。
ところがPerl以降はプログラミング言語としても遜色なくなってきている。
とはいえC++やJavaとは明らかに違う。
ということでこれらを呼ぶために生まれた言葉が「LL言語」だ。（と思う）
よく分からなければ「Perl/Python/Ruby/JavaScript/その他」の理解で問題ない。

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

LLという日本語だと思えば別に恥ずかしくないだろうに。

**デフォルトの名無しさん** · 2017/07/29(土) 00:29:11.14

これからは BASIC

10 PRINT "ぷ"

**デフォルトの名無しさん** · 2017/07/29(土) 00:31:57.73

C#だろうとJavaだろうとFotranだろうと多くのライブラリはC、C++で書かれてる。
スクリプト系言語に限定して議論する理由は？

**デフォルトの名無しさん** · 2017/07/29(土) 00:33:28.06

>>327
Basicはどの辺に分類されるの？

**デフォルトの名無しさん** · 2017/07/29(土) 00:36:55.90

bashがスクリプト言語になるなら、Emacsもそうなるかな

**デフォルトの名無しさん** · 2017/07/29(土) 00:37:55.49

で、結局リスト実装出来ない雑魚はおんのか？

**デフォルトの名無しさん** · 2017/07/29(土) 00:48:16.16

>>330
何が言いたいのか分からんが、エスパーするとこれで答えになるか？

LL言語 ⊂ （君の言う超広義の）スクリプト言語

C#/Java/FortranをLL言語と呼ぶ奴はいない。
つか、知らない言語の話なんてしないんだし、
自分の知っている言語のどれがLL言語と呼ばれるかフラグ立てておけば済む話だぞ。
出現頻度だけで言えば、LL言語≒Perl/Python/Ruby/JavaScriptでいい。

**デフォルトの名無しさん** · 2017/07/29(土) 01:53:34.44

LL言語という物の中身は分かりましたが
そのように分類する事で、
得るものがあるようには感じませんでした

**デフォルトの名無しさん** · 2017/07/29(土) 04:02:19.23

>>294
ソートが楽になるだろう？

**デフォルトの名無しさん** · 2017/07/29(土) 04:04:40.21

>>295
バーカ C言語すれだから初期化リストだと思ったとか寝言ほざいてるID:tCxrViSfのバカさを指摘するために
他の文法要素でリストばたくさんあるぞと指摘してやったんだろ

死ねバーカ

**デフォルトの名無しさん** · 2017/07/29(土) 05:24:03.96

既存のCのコードをUnicode対応に書き直したいんだけど、
char を wchar_t に置換したり、文字列リテラルにプレフィックス付けてくれたり、
関数を wchar.h 版にしてくれる便利なツールは無いですか？

もしくは予約毎と文字列リテラルだけを対象にしたいので、
パースして品詞情報を出してくれるスクリプトなんかあれば改造するかも。

**デフォルトの名無しさん** · 2017/07/29(土) 05:31:19.12

>>336
double とか int でもそう思ってるなら単なるアホだぞ

**デフォルトの名無しさん** · 2017/07/29(土) 05:34:46.32

>>337
> 他の文法要素でリストばたくさんあるぞと指摘してやったんだろ
そんなもんは既に>>267で指摘されてるのに周回遅れでなにドヤッてんだよ w

**デフォルトの名無しさん** · 2017/07/29(土) 05:39:01.00

>>335
まあLL知らなかったアホが悔し紛れにマウンティングしようとして自爆してるだけだから w

**デフォルトの名無しさん** · 2017/07/29(土) 05:47:56.72

>>338
そういうツール作ればいいじゃん。

**デフォルトの名無しさん** · 2017/07/29(土) 07:17:17.25

>>338
全自動は厳しそう
文字のchatと文字以外のcharの区別が出来ない

**デフォルトの名無しさん** · 2017/07/29(土) 07:28:56.29

>>337
その指摘の意図が不明
他にあるから何？

**デフォルトの名無しさん** · 2017/07/29(土) 07:55:34.60

>>340
バーカそれもオレなんだが
往生際悪く日が変わってID変わったID:WViVOgsqが絡んできたから止めを刺してやったに過ぎないが
バカには理解できないようださすが救いようのないバカ

**デフォルトの名無しさん** · 2017/07/29(土) 08:00:46.31

>>339
くさるほど連結リストを作るのに、いちいち特定の型に対応させてられないよ

**デフォルトの名無しさん** · 2017/07/29(土) 08:04:41.41

>>345
で結局何のリストなの？

**デフォルトの名無しさん** · 2017/07/29(土) 08:09:17.20

ていうか、
>>228の書き込み自体が皮肉なわけだけど
C言語自体にリスト構造なんて物はないっていう
本気で初期化リストだと主張してると思ったわけじゃ無いよな？
「初期化リスト？」だし

**デフォルトの名無しさん** · 2017/07/29(土) 08:10:22.22

皮肉に対してトンチンカンな指摘をしてるアホが
一人いるみたいだけど

**デフォルトの名無しさん** · 2017/07/29(土) 08:11:51.02

>>346
腐るほど連結リストを作るプログラムって何だ？

**デフォルトの名無しさん** · 2017/07/29(土) 08:15:35.54

>>345
ひょっとして同じこと繰り返してるバカって言われてることに気づいてないのか？
>>265 と >>280 でわざと同じように指摘してやったのに w

**デフォルトの名無しさん** · 2017/07/29(土) 08:17:38.69

>>346
>>290

**デフォルトの名無しさん** · 2017/07/29(土) 08:25:35.65

>>289
使う側でいちいちメモリ確保、解放をするの？
それとも、Data自体が実体でキャストして使う？

いずれにしろ使いにく過ぎる

**デフォルトの名無しさん** · 2017/07/29(土) 08:25:56.47

>>352
連結リストの型ごとにアルゴリズムを生成するの？それこそミスの元じゃない？

**デフォルトの名無しさん** · 2017/07/29(土) 08:26:55.49

>>353
いちいちmalloc()/free() するんだよ
malloc()/free() でミスするようでは仕事にならん、というか検査用ラッパぐらい手持ちでもっとけよ

**デフォルトの名無しさん** · 2017/07/29(土) 08:29:08.33

使いにく過ぎる

>>354
型ごとに同じコードを何度も記述する必要はないぞ
そのためのマクロだ

**デフォルトの名無しさん** · 2017/07/29(土) 08:31:19.71

連結リストの中に連結リストとか自由にやりたいのだったら void *data 一択だよ

**デフォルトの名無しさん** · 2017/07/29(土) 08:31:57.23

構造体名と型をdefineしてからインクルード

**デフォルトの名無しさん** · 2017/07/29(土) 08:33:04.08

>>354
> まあいろんな型が必要だとテンプレートが欲しくなるけど
マクロでもそこそこ行けるしね
￣￣￣￣￣￣￣￣￣￣￣￣￣￣

**デフォルトの名無しさん** · 2017/07/29(土) 08:35:18.93

どっちが書きやすいか試せば一発だが‥これは二分木でも一緒
誰か三重の連結リストなり二分木なりを自分のやりかたで書いてくれないか？

**デフォルトの名無しさん** · 2017/07/29(土) 08:36:09.59

リストのノードとは別にメモリ確保が必要なら、パフォーマンスにも影響するし

**デフォルトの名無しさん** · 2017/07/29(土) 08:40:17.35

腐るほど使うなら使いやすくないと

メモリ確保、解放を自分でやれ？
あり得ない

**デフォルトの名無しさん** · 2017/07/29(土) 08:41:10.70

>>362
それはCの基本だよ、お前さんC++に慣れきっているんじゃない？

**タグもいるかな** · 2017/07/29(土) 08:41:31.77

>>357
せっかくの静的型付を安易に捨てるのはバカにありがちな行動
struct List_t {
struct List_t *Previous;
struct List_t *Next;
union {
struct List_t *Child;
double Double;
} Data;
};

**デフォルトの名無しさん** · 2017/07/29(土) 08:44:54.55

>>363
使いにくくてバグの元でパフォーマンスも悪いモジュールを強要する

お前とは仕事をしたくない

**デフォルトの名無しさん** · 2017/07/29(土) 08:52:21.05

>>364
出た！union 野郎が出た！
そんなところで共用体をつかってコードを一本化できるのか？続きを書いてみろよ

**デフォルトの名無しさん** · 2017/07/29(土) 08:53:25.58

>>365
ふん、それはCを知らないといっているようなものだよ‥
>>360を書けばわかる

**デフォルトの名無しさん** · 2017/07/29(土) 08:54:11.31

> そこそこ行けるしね
と書くとアンダーラインになるのか?

**デフォルトの名無しさん** · 2017/07/29(土) 08:55:16.84

マクロでもそこそこ行けるしね

そこそこ行けるしね

行けるしね

**デフォルトの名無しさん** · 2017/07/29(土) 09:20:46.96

>>366
続きってなんだよ w
２分木なら双方向リストと同じだぞ w
struct List_t {
struct List_t *Left;
struct List_t *Right;
double Data;
};

**デフォルトの名無しさん** · 2017/07/29(土) 09:21:39.47

>>368
アンダーライン w

**デフォルトの名無しさん** · 2017/07/29(土) 09:28:06.03

ん？
二分木なら３個とつながってるから、
普通３個リンクを張る

**デフォルトの名無しさん** · 2017/07/29(土) 09:29:28.03

>>364
お、標準ライブラリのソート全否定か？
Cではちょいちょい捨てるよちょいちょいね
常に型を保存したかったらC++使うしかない

**デフォルトの名無しさん** · 2017/07/29(土) 09:29:42.67

あと、色情報も普通はつける

**デフォルトの名無しさん** · 2017/07/29(土) 09:43:22.80

>>364 も >>370 も、何の構造？

親をたどれないとポインタを一個進めることも出来ない

C++でいうsetの話をしたわけじゃないの？

**デフォルトの名無しさん** · 2017/07/29(土) 09:43:31.26

>>372, >>374
赤黒とかの前に２分木の基礎からやり直せ

**デフォルトの名無しさん** · 2017/07/29(土) 09:45:52.74

>>373
> お、標準ライブラリのソート全否定か？
>> 安易に捨てるのは
の意味もわからないアホ w

**デフォルトの名無しさん** · 2017/07/29(土) 09:49:09.48

>>375
>>364 に対して親とか知ったかが背伸びするなよ w
根や親を各ノードに持つか別に管理するかは要件次第

**デフォルトの名無しさん** · 2017/07/29(土) 09:54:12.77

ポインタを進めたり戻したりする必要がなければ
親にリンクを張らなくてもいいけどさ

std::setと同等なものをイメージしたけど、
まったく違うものが突然出てきたわけね

**デフォルトの名無しさん** · 2017/07/29(土) 09:59:21.62

>>364はそもそも二分木では無いのか

>>357のリストの中にリストっていうのはそういう意味なのか？

**デフォルトの名無しさん** · 2017/07/29(土) 09:59:54.86

おれの読解力が無さすぎるのか、
説明がなさすぎるのか、

**デフォルトの名無しさん** · 2017/07/29(土) 10:08:25.24

>>381
>>286　>>287　にある通り、previousとnextと書いてると、大抵は双方向リストを意味してるものだと取る
ここがleftとrightと書いてると、意味上は全く同じなんだけれども、単語の上からはまずは二分木を連想する
next一つだけだと、一番単純な連結リストであることを期待する

**デフォルトの名無しさん** · 2017/07/29(土) 10:11:31.61

>>377
それいうならリストの中身void*にするのもそこまで安易な選択ってわけでもあるまいに

**デフォルトの名無しさん** · 2017/07/29(土) 10:14:10.31

>>379
君以外はみんな「リスト」の話をしている。
君もそうだったのだがなぜか勝手に君だけsetだと言い出してる。

>>380
「リストの中のリスト」ってのは、配列で言うとジャグ配列、
つまりジャグリスト。（という言い方は普通しないが）

>>381
君の頭が悪すぎるだけ。
君以外はみんな噛み合っている。つまり、必要十分な説明はなされている。
つか、>>364,370を読めない奴が議論参加するな、という話でしかないが。

個人的には>>364でunionは使わない。マクロで量産だね。（手動テンプレート）

**デフォルトの名無しさん** · 2017/07/29(土) 10:17:23.70

>>286は、
双方向を利用して作ったから名前が変なのかと思った
でも、追加したのが Child なのはどっちみち変だな
２分木だとしたら

>>370は２分木だろうけど、
これで何をしたいのかわからん
双方向と２分木が同じ発言の意味も不明

**デフォルトの名無しさん** · 2017/07/29(土) 10:20:56.53

>>370で二分木の話が出た
もっと上ではsetの話が出ている

**デフォルトの名無しさん** · 2017/07/29(土) 10:22:31.80

>>357の
リストの中のリストって
list < list < int > >
こういう意味かと思ったけどこれも違うのね

**デフォルトの名無しさん** · 2017/07/29(土) 10:26:44.77

まあいずれにしろ、>>289 は無いな

**デフォルトの名無しさん** · 2017/07/29(土) 10:31:03.43

>>383
ソート使うのにmalloc/freeは要らんだろ

**デフォルトの名無しさん** · 2017/07/29(土) 10:35:15.55

>>389
リストなんてどうせmalloc/free使って運用するし別によくね？

**デフォルトの名無しさん** · 2017/07/29(土) 10:36:49.65

>>385
>>286は「双方向リスト」だぞ。名前もかなり妥当。
つか、君だけまったく付いて来れてないが。

> 双方向と２分木が同じ発言の意味も不明
抽象化して「ポインタの数」という意味で捉えると同じ、ってことだよ。
これについてこれてないのは、「抽象思考出来ない馬鹿」だね。最近はよく見かけるが。

>>387
いや、そういう意味だぞ。

ふむ、なるほど、君は「リスト」を作れない馬鹿のようだ。君は何言語使いなんだ？
C言語使いなら、ド頭>>230でも否定されている通り、普通はリスト程度ならサクッと作れる。
(ただしそもそもリストなんて使わないが)

**デフォルトの名無しさん** · 2017/07/29(土) 10:37:38.60

>>384
> 個人的には>>364でunionは使わない。マクロで量産だね。（手動テンプレート）
ん？
ノードに値とリストのどちらかを入れられるリストと言う要件だと思ったが？

**デフォルトの名無しさん** · 2017/07/29(土) 10:37:49.78

>>289
intのリストに1, 2, 3, ... , 10 を追加
するだけでもイヤになる

**デフォルトの名無しさん** · 2017/07/29(土) 10:39:22.96

>>392
なんだ、結局おれ以外も会話が通じてないんじゃん

**デフォルトの名無しさん** · 2017/07/29(土) 10:40:24.22

>>390
まあお前がいいと思うならそうすればいいんじゃね？

**デフォルトの名無しさん** · 2017/07/29(土) 10:41:41.06

>>391
あ、ごめん
>>385の一行目は >>364 の間違い

**デフォルトの名無しさん** · 2017/07/29(土) 10:42:46.56

>>391の真ん中
>>364のコードはそうなってない

**デフォルトの名無しさん** · 2017/07/29(土) 10:47:50.62

>>391の上半分

トポロジーがまったく違う
よって必要な処理もまったく違う
ポインタの数も、普通は２分木は3方向にリンクを張る

**デフォルトの名無しさん** · 2017/07/29(土) 10:48:39.76

「普通は」とか書くと反論がくるのかな
「多くは」くらいにしておくか

**デフォルトの名無しさん** · 2017/07/29(土) 10:58:06.68

>>370
結局これで何をしたいのかわからん

親へのリンクが無い、色が無い
って時点で汎用化とは程遠い

**デフォルトの名無しさん** · 2017/07/29(土) 11:00:17.42

>>392
> ノードに値とリストのどちらかを入れられるリストと言う要件だと思ったが？
いや、そう明示されているわけではないよな？
次に、それが要件だったとして、或いは汎用化するために void* だろってのが皆の意見だ。
ここについては俺はいちいちキャストがウザいからデータはめ込み派（君と同じ）だが。

**デフォルトの名無しさん** · 2017/07/29(土) 11:09:28.10

Cばかり使っていると頭がこんなんなっちゃいます。

**デフォルトの名無しさん** · 2017/07/29(土) 11:11:38.53

void* の問題はキャストもそうだけど
外部でメモリを管理する必要があるってところが大きいかと

多重リストだろうがunionだろうが
マクロでどうにでもなるんで
わざわざ不便な作りにする必要は無いかと

**デフォルトの名無しさん** · 2017/07/29(土) 11:13:16.21

>>402
C++が使える環境なら素直にC++を使えって話だけど
いまだにCしか使えない環境ってのもあってね

**デフォルトの名無しさん** · 2017/07/29(土) 11:14:41.46

(単方向)リストは先頭から終端の方向へ順にポインタを辿る、逆方向のポインタは無くても可(逆方向があるのは双方向リスト)
二分木は根から葉の方向へ再帰でポインタを辿る、親方向のポインタは無くても可(むしろ無いのが普通)

**デフォルトの名無しさん** · 2017/07/29(土) 11:16:39.02

>>398
何度も言っているが君だけ付いて来れてない。いちいち全部なので端折るが、

> ポインタの数も、普通は２分木は3方向にリンクを張る
これについては既に回答済みで、引用すると、
> 根や親を各ノードに持つか別に管理するかは要件次第 (>>378)
で、全くその通りだ。

俺は君が何故これを理解出来ないのかもわかるが、
君は俺の質問に答える気がないようだから、教えてやらないことにする。
馬鹿のままで死ね。

**デフォルトの名無しさん** · 2017/07/29(土) 11:16:58.24

Cってパフォーマンスを落としてまで汎用化するような使い方ってあまりしないしね
基本組み込み用

リストも片方向で済むなら片方向にするし、
そもそもリスト構造自体頻繁に使うようなものじゃない

**デフォルトの名無しさん** · 2017/07/29(土) 11:18:34.04

だから、
Cで挫折する理由が「リスト」とかいう主張、
まったくチンプンカンプンで

**デフォルトの名無しさん** · 2017/07/29(土) 11:19:32.62

>>401
> いや、そう明示されているわけではないよな？
で、君は
> 連結リストの中に連結リストとか自由にやりたい
をどう解釈してマクロでやるって言ってるの？

> 次に、それが要件だったとして、或いは汎用化するために void* だろってのが皆の意見だ。
皆の意見？ w

**デフォルトの名無しさん** · 2017/07/29(土) 11:21:33.18

>>406
要件次第で変わるのに「同じ」と言ってしまう