07/03/18 01:51:22
C言語は文脈自由文法だから正規表現で完璧にマッチさせるのは不可能
263:デフォルトの名無しさん
07/03/18 05:35:27
>>262 こういう話疎いので、初心者にも解るように解説してください。
264:デフォルトの名無しさん
07/03/18 07:02:14
>>263
コンパイラの本でも嫁
265:デフォルトの名無しさん
07/03/18 11:30:39
突然舞い上がったようなレスだな。>>262は
そもそもどのレスに依存するのだろう。
266:デフォルトの名無しさん
07/03/18 11:33:56
259のあたりだろ。
267:デフォルトの名無しさん
07/03/18 11:41:31
>>265が>>262を全く理解できなかったということだけはわかった。
268:デフォルトの名無しさん
07/03/18 11:50:27
まあ規約ガチガチなのはそのせいだしな
269:デフォルトの名無しさん
07/03/18 13:40:30
正規表現に疎い俺に>>173はどういう正規表現を書いているのか教えて欲しい。
270:デフォルトの名無しさん
07/03/18 13:49:32
そこらじゅうに未定義・未規定・処理系依存が
ぽっかり口をあけているC言語のどの辺がガチガチ？
271:デフォルトの名無しさん
07/03/18 14:23:15
コーディング規約でガチガチにするって意味だよ
272:263
07/03/18 18:26:20
そんな連関、聞いたこと無いけどな。
273:デフォルトの名無しさん
07/03/18 19:16:41
>>263
かっこが自由に無制限に入れ子に出来るパターンは
正規表現じゃ理論上無理らしいよ
274:デフォルトの名無しさん
07/03/18 20:28:25
正規文法と文脈自由文法でぐぐってみ
275:デフォルトの名無しさん
07/03/18 20:33:57
正規文法は a is b のルール．
線形構造しか表現できない．
A→B→C
A is B.
B is C.
文脈自由文法は a is b and c のルール．
木構造を表現できる．
A┬B
└C┬D
└E
A is B and C.
C is D and E.
そういうこっちゃ．
276:デフォルトの名無しさん
07/03/18 21:01:57
だかPerlとかの変態拡張性器表現ならきっと・・・
277:デフォルトの名無しさん
07/03/18 21:11:13
Perlのは正規表現の中でPerlのコードを評価できたりするからある意味万能
278:デフォルトの名無しさん
07/03/19 00:02:33
つまりゲストのお客さんが自由に参加すると収拾がつかなくなるので、
レギュラーのメンツだけでやってくれ、というわけですね。
279:デフォルトの名無しさん
07/03/19 05:52:30
結構前の話題だが
俺は例えば if なら
if(式) 文;
文が一行で、かつこの行が長くならない場合だけ { } を使わずに書くかなぁ。
if(式)
文;
と書くぐらいならブレースを使ってる。
280:デフォルトの名無しさん
07/03/19 07:18:05
条件文がすげー長かったら？
やっぱ１行でもブロックにする？
281:デフォルトの名無しさん
07/03/19 07:27:01
条件式を関数なりマクロなりに分けて良い感じの名前を付ければおけ。
そういう時ローカル関数使える言語だといいんだけどな。
282:デフォルトの名無しさん
07/03/19 08:29:05
ローカル関数は欲しいねえ・・
283:デフォルトの名無しさん
07/03/19 08:35:21
C++;なら関数内で定義したクラス/構造体のメソッドで代用出来るけどな
284:デフォルトの名無しさん
07/03/19 08:44:43
無理やりそんなことしても読みにくくなるだけだろ。
読みやすくすることが目的なのに。
285:279
07/03/19 20:21:25
>280
うん。条件が長い時もブレースにする。
もしくは条件式の閉じ括弧を実行文の行に持ってくる。
これなら俺は間違えない。集団ならやらんけど。
if(
条件式
) 実行文;
BASICで育ったんで一行IF／ブロックIFが基本、
長い時はブロック化するかこうしてたからなー。
IF ～ _
THEN 実行文
286:デフォルトの名無しさん
07/04/03 13:47:00
自分所のコーディングルールは、
if (式) 文1つ ;
if (式) {
複数の文
}
のいずれか片方のみ可。
287:デフォルトの名無しさん
07/04/03 14:34:40
ルール作るなら、常にブロック使えやコラにした方が良くね？
288:デフォルトの名無しさん
07/04/03 14:35:55
ガチガチだと読みにくくなるよ・・・
289:デフォルトの名無しさん
07/04/03 14:49:39
if (式)
{
・・・
}
これに統一すると美しい
290:デフォルトの名無しさん
07/04/03 14:58:54
主観
291:デフォルトの名無しさん
07/04/11 06:53:45
>>289
自分には美しく見えない。
変数のスコープのために、
{
何か
{
何か
}
何か
}
という書き方をする場合があるので、
if (式)
{
何か
}
という書き方を許してしまうと、{ が現われたとき、
if (式)
{
何か
}
という可能性を考えて、前方向をチェックしなくてはならない。
if (式) {
何か
}
というように同じ行に書くように強制すれば、見てすぐにわかる。
if (式) と { が生き別れになってしまうこともない。
292:デフォルトの名無しさん
07/04/11 11:19:49
そんなのは、常に整形ツール使えって事でいいじゃないか。
そのルールが気に入らない場合は、自分が読む時に整形しなおせばいい。
そして、読み終わったら元に戻すと。
293:デフォルトの名無しさん
07/04/11 11:36:07
よっぽどものすごい書き方してなきゃだいたい読めるし、
書くときはまわりに合わせりゃそれでいいじゃないの。
こんなのが原因でトラブるやつは他の原因でもっとトラブるよ。
294:デフォルトの名無しさん
07/04/11 12:55:21
>>291
つ[c++ or c99]
295:デフォルトの名無しさん
07/04/11 14:17:17
TCLではブレース次行じゃダメなんだよな
296:デフォルトの名無しさん
07/04/11 22:35:26
>>295
そうなのか。
あれは、それぞれがシェルコマンドみたいなもんだからな。
297:デフォルトの名無しさん
07/04/12 19:54:03
Tclは改行した時括弧の中じゃなかったら
そこでバッサリ文末になるからな
298:デフォルトの名無しさん
07/04/12 20:55:47
Rubyは、改行したところまでで文が成立する場合は次の行は別の文扱いだな。
二項演算式の途中とか対応するカッコを閉じる前のような、文が未完結である
ことがわかる場合は途中改行ができる。完結しているように見える場合は、
¥を付けて明示的に継続する必要がある。
299:デフォルトの名無しさん
07/04/12 23:55:43
セミコロンが文の終わり、にしときゃ良かったと思うんだけど
なんでそんなにも ; なくしたかったのかな？
300:デフォルトの名無しさん
07/04/13 00:57:43
毎回行末記号書くよりも、必要な時だけ継続記号使った方が手間がかからないという思想だろう。
301:デフォルトの名無しさん
07/04/13 01:16:58
>299
俺は逆に
何でわざわざ毎回行末を書かなきゃいけないんだ？
行末は普通文末だろ？
と思うぞ。
結局、普段使ってる言語の影響が強いんだと思う。
Lisperは文末どころか文の始まりまで毎回書くんだもんな…凄いと思う。
302:デフォルトの名無しさん
07/04/13 09:50:40
Ruby慣れると、C書くとき早速セミコロンを忘れる。
無いほうが自然なんだな、と実感する
303:デフォルトの名無しさん
07/04/13 10:13:04
文脈によらずに継続行書くときは常に\つける方が好み。
304:デフォルトの名無しさん
07/04/13 11:38:37
おまいらFORTRANやCOBOLの時代に逆戻りだな・・・
305:デフォルトの名無しさん
07/04/13 14:28:13
>304
むしろ、その時代はカラム制限があったから
セミコロン文末の方が利点が多かったろうに
ある程度のカラムが扱えるなら継続行のみ明示で良いと思うぞ
どうせそんな滅茶苦茶長い行書かないし
…ああ、C言語は使うAPIによっちゃ長い行が普通になるのか
306:デフォルトの名無しさん
07/04/13 19:18:25
>>301
Lisperにはカッコは見えていないし意識して入力もしてないｗ
307:デフォルトの名無しさん
07/04/13 19:56:09
>306
そういうモノなのかｗ
他言語の人（俺含）から見れば大量の括弧の方が目につくんだがな～
308:デフォルトの名無しさん
07/04/13 20:56:19
>>307
begin endが目につくpascalとか
:-が目につくprologとか
{}が目につくCとか
<>が目につくXMLとか
309:デフォルトの名無しさん
07/04/13 21:57:00
インデントしてたらそんなに目に付くもんでもないんじゃない？
310:デフォルトの名無しさん
07/04/14 01:53:45
セミコロンなしで行末で文末としてしまうと、
class hoge { どわーーー}
という具合に1行に書かないといけなくなりますぞ。
311:デフォルトの名無しさん
07/04/14 09:42:14
どわーーーでなぜか和んだ。
312:デフォルトの名無しさん
07/04/14 09:43:53
>310
そういう言語は
・閉じ括弧が少ない場合はブロックが継続する
・構文でブロックを示すからendが来るまでブロックが継続する
のどちらかを備えてるだろ普通。
Tclは前者。
BASICやCOBOLは後者。
Rubyは両方使ってるな。
Pythonはインデントでブロックを示すんだっけ？
313:デフォルトの名無しさん
07/04/14 12:12:36
Pythonはインデントでブロックを表してて、両方だな。
314:デフォルトの名無しさん
07/04/16 22:57:37
途中から良スレになってる気がした
315:デフォルトの名無しさん
07/04/17 04:31:02
気のせいだった
316:デフォルトの名無しさん
07/08/31 11:46:07
age
317:デフォルトの名無しさん
07/09/01 15:23:25
かの有名なカーニハン先生も省略するべきでないと仰っているよ。
318:デフォルトの名無しさん
07/09/01 15:33:26
蟹飯がナンボのもんじゃーい！
319:デフォルトの名無しさん
07/09/01 17:16:33
>>317
K&R、省略しまくりじゃん。
320:デフォルトの名無しさん
07/09/02 06:09:15
俺はC→JAVA→C++→C#と勉強してきたから
コードブロックよりもセミコロンがない言語が苦手だな
321:デフォルトの名無しさん
07/09/02 18:34:19
セミコロンは文の区切りです。
322:デフォルトの名無しさん
07/09/02 21:58:20
同じセミコロンでもデリミタとして使う言語とターミネータとして使う言語があるのよん。
323:デフォルトの名無しさん
07/09/02 23:07:25
Pascalは文の最後はピリオドだったな。
324:デフォルトの名無しさん
07/09/03 00:46:44
pascal は
○ if a then b else c;
× if a then b; else c; (コンパイルエラー)
Cはどっちも大丈夫
325:デフォルトの名無しさん
07/09/03 01:18:28
Cはどっちも怒られそうだぞ
326:デフォルトの名無しさん
07/09/03 13:06:03
カッコが付かないな
327:デフォルトの名無しさん
07/12/31 03:42:45
Pascalの場合、elseはif文の一部で
セミコロン付けると、そこでif文が終わるから
「文頭にelseはおかしい」って言われるんだよね。
328:デフォルトの名無しさん
08/03/05 17:00:17
c でも else は if 文の一部。
; が文同士のセパレータではなく文の終端記号でしかないから、
b; が 1 文となって問題にならない、ってこと。
329:デフォルトの名無しさん
08/03/15 16:13:12
>>323
プログラムの最後だろ？
330:デフォルトの名無しさん
08/05/04 13:30:52
>>1
COBOLのIF文の歴史を知らないんだな。
331:デフォルトの名無しさん
08/05/06 17:30:21
内容（意味）によらず形式だけで決める
>>1の考え方が危険なだけ
332:デフォルトの名無しさん
08/05/06 17:42:39
人いたんだ。
333:デフォルトの名無しさん
08/06/25 14:44:13
>>331
形式で決められるものは、決めればいい。
その分、考えないといけないことに頭のリソースを配分しようぜ。
334:デフォルトの名無しさん
08/06/29 01:35:51
ブラを付ける自由もあれば、付けない自由もある。
女性はブラジャーの着用を義務付けるという法律が
制定できないのと同じ。
ブラは時には非常に邪魔になる。
形式では決めることができないものは意外に多い。
335:デフォルトの名無しさん
08/06/29 02:50:06
そもそも、
Windowsのメモ帳にたくさん毛が生えたようなテキストエディタを使ってコードを書く
という時点で、おかしいだろ。
336:デフォルトの名無しさん
08/06/30 18:35:16
C#なら言語仕様で{}を強制してたとしても不思議ではないね
switch内のbreakは強制だっけ
337:デフォルトの名無しさん
08/06/30 22:41:09
{} を強制するなら elseif キーワードが必要
338:デフォルトの名無しさん
08/07/01 03:21:06
ブラを強制するのなら、elseの禁止も合わせてやったほうが良いかも？
よくね～よw。
なるべくブラ着用。elseの多用は可愛気がないぜ。といったところ。
339:デフォルトの名無しさん
08/07/01 04:43:44
コーディングするためのユーザインタフェースが、
事故を未然に防ぐべく何かするのが第一だろ
いつまでも
紙に鉛筆でプログラムを書くレベルに留まるな
340:デフォルトの名無しさん
08/07/27 00:00:15
>337
なぜに?
341:デフォルトの名無しさん
08/07/27 02:59:30
elseifがないと
if () {
} else {
if () {
} else {
if () {
} else {
if () {
} else {
}
}
}
}
みたいにどんどんネストが深くなる。
342:デフォルトの名無しさん
08/07/27 03:00:38
{} を省略できるなら
if () {
} else if () {
} else if () {
} else if () {
} else {
}
みたいに書けるんだけど
343:デフォルトの名無しさん
08/07/27 03:06:05
強制する←→省略不可だからそういうのも認めないって話じゃねーの。
344:デフォルトの名無しさん
08/07/27 03:27:46
というか、>>1の主張を強制するのならelse ifという慣用表現も禁止で
>>341みたいにきちんとif文をネストするような表現とすることを
強制するべき。
>>342式を禁止するというか非推奨にするのは、それなりに根拠がある。
多くの場合、>>342の形式の場合、ロジックが練れていなく、
バグが多い割に修正が難しいから。経験的に言って>>341式のほう
が、バグも少なくなり、バグが出ても修正しやすいような気がする。
結論的に言えば>>342式を禁止するのは一定の意味を持つが
>>1を強制するのはやり過ぎかも。
345:デフォルトの名無しさん
08/07/27 04:11:17
>>342禁止ですら、行き過ぎという感があるのに
>>1強制なんてあり得ない
346:デフォルトの名無しさん
08/07/27 13:36:09
なる。
それなら俺は {} 強制で else if 容認かな。
自分のバグ元としては {}なしのif より 比較に = 使っちゃう方が多いけど。
だから、エディタで[^><=]=[^=] を赤くなるようにしてる。
347:デフォルトの名無しさん
08/07/28 15:32:25
caseで
348:デフォルトの名無しさん
08/07/28 17:42:41
多くの場合、経験的に言って、根拠があると言っているわりに>>344は主観推論しか言っていない気がする。
349:デフォルトの名無しさん
08/07/28 21:13:28
case式が強力な言語ならいいんだけどCだと定数との比較しかできない
350:デフォルトの名無しさん
08/08/04 12:32:49
>>342のようなコードってさ、
if (A) { い
} else if (B) { ろ
} else if (C) { は
} else { に
}
ってさ、
if (A) { い }
if (!A && B) { ろ }
if (!A && !B && C) {は}
if (!A && !B && !C) {に}
ということなんだけど、その条件が分散して書かれているから、わかりにくいのよね。
ただのswitch-case的な使い方だと誤解して順序を変えてしまうと、意味が変ってしまう。
351:デフォルトの名無しさん
08/10/01 23:41:42
if(id == typeA && ){}
else if (id == typeB &&){}
って書く奴いるけどなんでswitch文使わないの
バカなのねぇバカなの？
352:デフォルトの名無しさん
08/10/02 09:16:07
>>351
妙な && が気になるが、if で書けば
・コードの行数が少なくて済むので見やすい
・スコープがしっかり認識できて良い
・シンタックスハイラトや自動インデントなど IDE によっては switch の対応が微妙
・if の方がコンパイラが最適化しやすい条件になっている
とかとか。分かってて書いている人なら、別に良いと思うけど？
353:デフォルトの名無しさん
08/10/02 22:17:54
if(id == typeA)
if(id == typeB)
と
if(id == typeA)
else if(id == typeB)
同じ意味だよね？
354:デフォルトの名無しさん
08/10/03 01:40:46
>>353
if (id == typeA) {
...
id = typeHoge;
}
の場合は？
355:デフォルトの名無しさん
08/10/06 12:06:12
>>353
idがconstなら同じ。そうでないなら、>354の可能性がある。
例えば、この関数では全く同じ。
void func(const int id)
{
if (id == typeA) {
funcA();
}
if (id == typeB) {
funcB();
}
}
356:デフォルトの名無しさん
08/10/06 12:18:01
つか、同じじゃないように見えるんだけど？
if(id == typeA)
if(id == typeB)
って、インデント付けると
if(id == typeA)
if(id == typeB)
だよな？ 更に括弧も付けると
if(id == typeA) {
if(id == typeB) {
}
}
だよな？
357:デフォルトの名無しさん
08/10/06 13:00:09
>>356
>353が>351を踏まえて書いたかどうかだな。
>353が>351を踏まえずに>356の意味で書いたのだとしたら、
if (id == typeA) if (id == typeB)
は(typeAとtypeBが等しいと言う無謀な前提を仮定しない限り)
if (0)と同じになってしまう。
358:デフォルトの名無しさん
08/10/07 18:07:30
べつに無謀な前提ではないんじゃないか
typeA != typeBでもid == typeAかつid == typeBだったりすると怖いけど
359:デフォルトの名無しさん
08/10/09 12:42:52
>>358
この流れでその前提は、余りに阿呆過ぎる。
最早>351も>353もいないから真意は不明だが。