アカウント名:
パスワード:
古臭い言語だと思う。土台が言語仕様貧弱なC言語なのに、無理して増築した感がある。土台から変えた言語を使うべき。
古臭いC言語ですがコーディングの仕方によって、例えば文章のような関数名と構造体を巧くインスタンスとして使えばC++以上のオブジェクト指向な綺麗なコードが仕上がると思います。昔、C言語の関数名制限に８文字以下というのがあったときは、相当苦労していたでしょうね。
C++では、練りきれない仕様での無意味なクラス化とか、IDEと連携しないとメンバ関数を見失うとか、何でもかんでも標準化してみるとか、そんなことばかりやっていれば構造化プログラミング世代以下の汚いコードになるでしょうね。
# ファイル拡張子をｃｐｐと書いて内部ではCで書いている私です# ガンプラはどう作ろうと自由だ
C言語でも、C89で書かれたコードは微妙ですね。GNU拡張の一部が取り入れられたC99は綺麗なコードが多いですが、長年Microsoftが未対応を貫いていてC99普及の障害となっていました。
# 最近やっっっっっっっっっっっとC99に対応しました>Microsoft
C99 には失望した
微妙な部分もありますが、それでも指示付き初期化指定子(Designated Initializer)は現代に於いて不可欠です。
それと逆の立場でして、初期化の糖衣構文を増やすのもどうかと、この言語に初期化と代入を区別する必要はなく、すべての初期化は代入で代用できる。まあ一番抵抗を感じたのは、alloca 絡みを見えなくしたこと
> 古臭いC言語ですがコーディングの仕方によって、例えば文章のような関数名と構造体を巧くインスタンスとして使えばC++以上のオブジェクト指向な綺麗なコードが仕上がると思います。
C言語で書いオブジェクト指向のコードって、関数ポインタだらけなイメージなんですが、C言語で書いたC++以上のオブジェクト指向な綺麗なコードっていうのが、どんな感じなのか、参考になるURLとか教えてもらえると嬉しいです。
> C++では、練りきれない仕様での無意味なクラス化とか、IDEと連携しないとメンバ関数を見失うとか、何でもかんでも標準化してみるとか、そんなことばかりやっていれば構造化プログラミング世代以下の汚いコードになるでしょうね。
コードが汚い云々は言語仕様よりも設計、コーディングする人次第っしょ。
AC(#2777520)です。
> C言語で書いオブジェクト指向のコードって、関数ポインタだらけなイメージなんですが、まあ確かにそうですね。 constやrestruct修飾子を巧く使えば、最近のコンパイラがある程度のミスを見つけてくれるのは助かります。ポインタを使うことによる危険性も確かにありますが、コンパイラに全て任せて良いのかとの懐疑的であったりします。まぁ、任せたほうがコーディング的に楽ですが。バッファとかをSTLで確保した場合、いつ開放されるかはSTLの実装次第なので、やはりある程度はプログラマも認識は必要だと思いますね。あ、C++11では開放タイミングが指定できるようになったんでしたっけ。
昔、こんな提唱もありましたね。結構気に入ってます。C-language's Object Oriented Languagehttp://www.sage-p.com/process/cool.htm [sage-p.com]
> C言語で書いたC++以上のオブジェクト指向な綺麗なコードっていうのが、どんな感じなのか、参考になるURLとか教えてもらえると嬉しいです。組み込み系でよいか解かりませんが、OpenBSDのIntelのデバイスドライバなんかは巧いことやっています。純潔LinuxやFreeBSDだとフレームワーク化されているので、かゆいところが見えないところがありますね。http://ftp.cc.uoc.gr/mirrors/OpenBSD/src/sys/dev/pci/ixgbe.c [cc.uoc.gr]http://ftp.cc.uoc.gr/mirrors/OpenBSD/src/sys/dev/pci/ixgbe_x540.c [cc.uoc.gr]※ 実際はいくつかのデバイスを切り替えているので、さらに数ファイルで構成されています。関数宣言とか書き方が微妙なのはデバイスドライバということでご理解ください。
> コードが汚い云々は言語仕様よりも設計、コーディングする人次第っしょまさにそうですね。
# ガンプラはどう作ろうと自由だ
ありがとうございます、C-language's Object Oriented Language はかなり前に見た記憶があるような、ないような。デバイスドライバの方は、ビルド中にチラ見してましたが後でゆっくり見てみます。
リソース解放タイミングの指定はもともと出来ていると思ってますが、多分自分が思ってることと、AC(#2777520)さんが言ってることに違いがありそうな気がするな。
土台から変えた言語を使うべき。
具体的には？
別ACですが、Rust [rust-lang.org]が最右翼じゃないでしょうか。
C++を部品とり程度に扱い、現代の知見をもとにCの精神をそのまま残して発展させたのがRustです。
Rustは「自分の足を撃てないC」です。正しい進化だと思う。もっとも、敷居は高いです。
敷居が高いか…そうか…
ハードルでしょ、と書かなきゃ間違えている人への適切な指摘になりませんよ。適切な指摘により学んだ者より :-)
そういうことだったのか。別のACですが、ようやく「敷居が高いか…そうか…」「どんな不義理を働いたんでしょうねえ…」の意味が分かりました。ありがとうございます。
「敷居が高い」の本来の意味と誤用 ～レベルが高い、自分には合わないという意味ではない [kotobano.jp]
どんな不義理を働いたんでしょうねえ…
ブートローダとかカーネルが書けない時点で、彼の話の文脈と同じ土俵にはないんじゃないかな。
ググってみるとすぐわかるように、カーネルやブートローダーはRustで書けます。
D言語もそうだけどさ。こういう言語はC++に比べてライブラリが貧弱、特にGUIとか速度が欲しいグラフィック関連とか、速度が欲しいならC++で書いたほうがいいし、外部からライブラリ呼び出すならもっと分かりやすいスクリプト言語でいいとなって、普及しない。
数千行規模のコードをいくつか書いた程度で話をするのはふさわしいか分からないのだが、参考までに。
Rustは確かに書いていても素晴らしい言語だと実感するが、制約が多すぎて、多くのプログラマにとって美しくシンプルに書こうとする努力が報われない上に、後からの仕様変更やリファクタリングに全く対応できない 印象を持った。メンテナンスを想定しているプロジェクトや、中規模以上のグループによる開発は難しいのではないか。
＃「なぜそれができないか」の理屈ばかりが立派で、「ではエレガントにそうしたければどうすればいいか」の話が全くない。
Cは行間が読めない言語C#は行間が読める言語
Cの仕様を引きずるC++、Objective-Cは前者。Javaはどちらかといえば後者だが冗長的な記述が多くなる傾向がある。PHPなんかも型の扱いが大らかすぎて前者。
SwiftやScaleはまだ触ったこと無いので除外
但しC#でもクエリ式はダメ
そのまえに「行間が読める」の意味を教えてよ
冗長な記述は面倒だと思うけど、察しろと言われるより幾分楽に感じる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
ひどい言語というより (スコア:1)
古臭い言語だと思う。
土台が言語仕様貧弱なC言語なのに、無理して増築した感がある。
土台から変えた言語を使うべき。
Re:ひどい言語というより (スコア:1)
古臭いC言語ですがコーディングの仕方によって、例えば文章のような関数名と構造体を巧くインスタンスとして使えばC++以上のオブジェクト指向な綺麗なコードが仕上がると思います。
昔、C言語の関数名制限に８文字以下というのがあったときは、相当苦労していたでしょうね。
C++では、練りきれない仕様での無意味なクラス化とか、IDEと連携しないとメンバ関数を見失うとか、何でもかんでも標準化してみるとか、そんなことばかりやっていれば構造化プログラミング世代以下の汚いコードになるでしょうね。
# ファイル拡張子をｃｐｐと書いて内部ではCで書いている私です
# ガンプラはどう作ろうと自由だ
Re: (スコア:0)
C言語でも、C89で書かれたコードは微妙ですね。GNU拡張の一部が取り入れられたC99は綺麗なコードが多いですが、長年Microsoftが未対応を貫いていてC99普及の障害となっていました。
# 最近やっっっっっっっっっっっとC99に対応しました>Microsoft
Re: (スコア:0)
C99 には失望した
Re: (スコア:0)
微妙な部分もありますが、それでも指示付き初期化指定子(Designated Initializer)は現代に於いて不可欠です。
Re: (スコア:0)
それと逆の立場でして、初期化の糖衣構文を増やすのもどうかと、この言語に初期化と代入を区別する必要はなく、すべての初期化は代入で代用できる。
まあ一番抵抗を感じたのは、alloca 絡みを見えなくしたこと
Re: (スコア:0)
> 古臭いC言語ですがコーディングの仕方によって、例えば文章のような関数名と構造体を巧くインスタンスとして使えばC++以上のオブジェクト指向な綺麗なコードが仕上がると思います。
C言語で書いオブジェクト指向のコードって、関数ポインタだらけなイメージなんですが、
C言語で書いたC++以上のオブジェクト指向な綺麗なコードっていうのが、
どんな感じなのか、参考になるURLとか教えてもらえると嬉しいです。
> C++では、練りきれない仕様での無意味なクラス化とか、IDEと連携しないとメンバ関数を見失うとか、何でもかんでも標準化してみるとか、そんなことばかりやっていれば構造化プログラミング世代以下の汚いコードになるでしょうね。
コードが汚い云々は言語仕様よりも設計、コーディングする人次第っしょ。
Re:ひどい言語というより (スコア:2, 参考になる)
AC(#2777520)です。
> C言語で書いオブジェクト指向のコードって、関数ポインタだらけなイメージなんですが、
まあ確かにそうですね。 constやrestruct修飾子を巧く使えば、最近のコンパイラがある程度のミスを見つけてくれるのは助かります。
ポインタを使うことによる危険性も確かにありますが、コンパイラに全て任せて良いのかとの懐疑的であったりします。まぁ、任せたほうがコーディング的に楽ですが。バッファとかをSTLで確保した場合、いつ開放されるかはSTLの実装次第なので、やはりある程度はプログラマも認識は必要だと思いますね。あ、C++11では開放タイミングが指定できるようになったんでしたっけ。
昔、こんな提唱もありましたね。結構気に入ってます。
C-language's Object Oriented Language
http://www.sage-p.com/process/cool.htm [sage-p.com]
> C言語で書いたC++以上のオブジェクト指向な綺麗なコードっていうのが、どんな感じなのか、参考になるURLとか教えてもらえると嬉しいです。
組み込み系でよいか解かりませんが、OpenBSDのIntelのデバイスドライバなんかは巧いことやっています。純潔LinuxやFreeBSDだとフレームワーク化されているので、かゆいところが見えないところがありますね。
http://ftp.cc.uoc.gr/mirrors/OpenBSD/src/sys/dev/pci/ixgbe.c [cc.uoc.gr]
http://ftp.cc.uoc.gr/mirrors/OpenBSD/src/sys/dev/pci/ixgbe_x540.c [cc.uoc.gr]
※ 実際はいくつかのデバイスを切り替えているので、さらに数ファイルで構成されています。
関数宣言とか書き方が微妙なのはデバイスドライバということでご理解ください。
> コードが汚い云々は言語仕様よりも設計、コーディングする人次第っしょ
まさにそうですね。
# ガンプラはどう作ろうと自由だ
Re: (スコア:0)
ありがとうございます、C-language's Object Oriented Language はかなり前に見た記憶があるような、ないような。
デバイスドライバの方は、ビルド中にチラ見してましたが後でゆっくり見てみます。
リソース解放タイミングの指定はもともと出来ていると思ってますが、多分自分が思ってることと、
AC(#2777520)さんが言ってることに違いがありそうな気がするな。
Re: (スコア:0)
土台から変えた言語を使うべき。
具体的には？
Re:ひどい言語というより (スコア:2, 参考になる)
別ACですが、Rust [rust-lang.org]が最右翼じゃないでしょうか。
C++を部品とり程度に扱い、現代の知見をもとにCの精神をそのまま残して発展させたのがRustです。
Rustは「自分の足を撃てないC」です。正しい進化だと思う。
もっとも、敷居は高いです。
Re: (スコア:0)
敷居が高いか…そうか…
敷居ではなく (スコア:2)
ハードルでしょ、と書かなきゃ間違えている人への適切な指摘になりませんよ。
適切な指摘により学んだ者より :-)
Re: (スコア:0)
そういうことだったのか。
別のACですが、ようやく「敷居が高いか…そうか…」「どんな不義理を働いたんでしょうねえ…」の意味が分かりました。
ありがとうございます。
「敷居が高い」の本来の意味と誤用 ～レベルが高い、自分には合わないという意味ではない [kotobano.jp]
Re:ひどい言語というより (スコア:1)
どんな不義理を働いたんでしょうねえ…
Re: (スコア:0)
ブートローダとかカーネルが書けない時点で、彼の話の文脈と同じ土俵にはないんじゃないかな。
Re: (スコア:0)
ググってみるとすぐわかるように、カーネルやブートローダーはRustで書けます。
Re: (スコア:0)
D言語もそうだけどさ。こういう言語はC++に比べてライブラリが貧弱、特にGUIとか速度が欲しいグラフィック関連とか、
速度が欲しいならC++で書いたほうがいいし、外部からライブラリ呼び出すならもっと分かりやすいスクリプト言語でいいとなって、普及しない。
Rustは確かに素晴らしい。しかし。(Re:ひどい言語というより) (スコア:0)
数千行規模のコードをいくつか書いた程度で話をするのはふさわしいか分からないのだが、参考までに。
Rustは確かに書いていても素晴らしい言語だと実感するが、
制約が多すぎて、多くのプログラマにとって美しくシンプルに書こうとする努力が報われない上に、
後からの仕様変更やリファクタリングに全く対応できない 印象を持った。
メンテナンスを想定しているプロジェクトや、中規模以上のグループによる開発は難しいのではないか。
＃「なぜそれができないか」の理屈ばかりが立派で、「ではエレガントにそうしたければどうすればいいか」の話が全くない。
Re: (スコア:0)
Cは行間が読めない言語
C#は行間が読める言語
Cの仕様を引きずるC++、Objective-Cは前者。
Javaはどちらかといえば後者だが冗長的な記述が多くなる傾向がある。
PHPなんかも型の扱いが大らかすぎて前者。
SwiftやScaleはまだ触ったこと無いので除外
但しC#でもクエリ式はダメ
Re: (スコア:0)
そのまえに「行間が読める」の意味を教えてよ
Re: (スコア:0)
冗長な記述は面倒だと思うけど、察しろと言われるより幾分楽に感じる。