「Cでプログラミングするには人生は短すぎる」か？

Javaはもともとは組み込み向け。

あんな遅くででかい言語のどこが組み込み向けかと

ブルーレイやケータイに乗ってるの知らんのか

てんでバラバラな仕様のため、互換性がまるで無い組み込み界で
相互の移植がしやすい言語を、と開発されたんだっけ？

>>84
ライブラリがでかいだけでVM自体は小さくできる。
カードにも組み込まれたこともある。

VMって言っても元祖MS-BASICのパクリみたいなもんだからな。
MS-BASICでさえROMに格納されてたくらいだし、今となってサイズなんて知れてるわな。
http://ja.wikipedia.org/wiki/Microsoft_BASIC

組み込み系とかほざいてるバカがいるな
Javaでの組み込みなんて全体の１割にも満たないだろ

>>89
そもそもどこまでを組み込み系って言ってるのかわからんし、
ソースコードの量なのか組み込まれている実行コードベースの
話かも示さずに１割云々と語ってるやつのほうがバカに見える。

>>89
組込ライセンスと意味なら、Java使ったサーバーサイドのシステムが1つ売れる間に数千数万のケータイが売れてると思うよ

>>88
MS-BASICよりもっと古いp-codeのパクリ。
p-codeになったのは、Visual Basicになってから。
というか、スタックマシンをパクリって言うやつまでいるのか。

>>92
なにを言ってるんだお前は？
無知にもほどがある

>>93
何を言いたいのか分からない。
JavaのVMとMS BASICのインタプリタは似ていない。

>>93>>94
MS BASICはエミュレータ+インタプリタだからな。
JavaのVMに似てはいるが、Javaそのものと言うよりはJRubyなんかに近い。

Java VMはMS BASICなんてパクってないだろ
どう考えてもSmalltalk-80のVMのパクりw

MS BASICのi8008エミュはVMはVMでもVMwareとかのノリだし、
単語は同じでも「仮想マシン」の意味が違うだろ。

Javaが目指したJavaチップを順序は逆だが実現していたという
意味では先進的だが。

>>96
俺もそう思うけど、世の中の若人は Smalltalk なんて知らないのかもね...

もし若人でないのに知らないなら目も当てられないけど...

>>97
MS BASICのi8008エミュっていったい何のことを言いたいのか？

Javaはコレクションのクラス設計が、Smalltalkに似てた気がする。

>>100
Smalltalk-80のCollectionをJavaのヘッポコCollectionsやArraysと一緒にすんなやw

ただの中間コード+インタプリタを'Java仮想マシン'と言い張ったJavaの営業戦略は大したもの

>>102はかわいそうな人ですね
技術センスゼロだから転職したほうがいいよ
さようなら

>>103
技術センスゼロの人にもわかるように違いを説明できるの？

今は、インタプリタではないJava VMが主流ではないか。
ネイティブで実行するCPUもあるし。

VMはインタプリタだろ。少なくともネイティブコンパイラではないし、ネイティブコードを実行するものでもない。
Java CPUはほとんど使われてないだろうし、一般的でもない。

「ランタイム」と言えば角が立たない

>>106
Java VMをインタプリタで実装するならわかる。

JavaチップだのJITコンパイラだのは後付けのだからねぇ。
インタプリタ高速化技法のひとつとして考えた方がいいと思うぞ。
とくにJavaのJITは起動時ではなくインタプリタで実行中に裏でコンパイルするというものだし。

PHP3まではインタプリタ、PHP4からはPHP仮想マシン
ok?

仮想マシンとインタプリタの違いは何？

BASICとの比較のコンテキストでインタプリタといったら、ソースコードと中間コードが同値という意味か、コンパイラの反対語か。

予め用意されたマシン語の命令セットを実行するのと、その場でソースをマシン語に翻訳して実行するのの違いじゃない？

>>111
中間言語をネイティブに変換してから実行するのが仮想マシン
インタプリタは、中間言語を使わず、ソースコードのまま
毎回命令を解釈してから実行するもの

とすると、>>103 の言い分がよくわからんな

>>114
じゃあ、Java VM はどちらでもないの？

中間言語は使うが、実行中に必要な部分だけ
（ロードされた部分だけ）ネイティブに変換する

>>114
ハズレw

仮想機械は仕様
インタプリタは実装

ﾌﾟ

>>114
その定義だと、やはりPHPはPHP仮想マシンだなw

>>117が一番しっくりくるな

Pコードインタプリタって仕様をもらって、自分でコンパイルしたプログラムを手で実行したことがあったなぁ。

仮想機械の仕様さえ満たせば
インタプリタ実装しようが
コンパイラ実装しようが
ハードウェア実装しようが
同じバイトコードが動く。

インタプリタ実装するにしても、
ベタなインタプリタでもいいし、
JITコンパイラ使ってもいいし、
複数の仮想機械で分散処理してもいい。
あくまで仮想機械の仕様さえ満たせば
コードを動かせる。

それが仮想機械じゃねえの？

N88BASICのDOS版ってたしかPコードとJITコンパイラだったはず。
今みたいにインストールなんて概念がなく、
EXEファイルにJITコンパイラを埋め込む仕様で
ファイルサイズが絶望的なほどでかかった記憶がある。

>>123
今使えば信じられないほど小さくて速いだろうなw

マシン語でプログラミングするには人生は長すぎる
その前に精神が壊れる

>>125
人間なんだから少しは工夫しよう。今ならマクロ使えばCに近い書き方ができるし、
使いやすいライブラリを多く用意してそれらを活用すればだいぶ見やすく書ける。

>>126
昔は実際そうだったな。
今なら、そんなことするぐらいならC使って、パフォーマンスいるところだけグリグリやるところだけ。

「Cでプログラミングするには人生は短すぎる」と言いつつアセンブラ技術者募集の求人を出すミゲルさんｗ
http://twitter.com/migueldeicaza/status/9631116499615744
http://d.hatena.ne.jp/atsushieno/20101201/p1

おぉ、迷える子羊よ。彼は犠牲になったのだ
多くの人たちがCでプログラミングしないために

>>1
プログラミングをソフトウェアを生み出す為のプロセスとして捉えたらその通りだけど、
プログラミング自体が楽しいなら言語は何でも良いし、どれだけ時間が掛かっても良い。
なぜならプログラムを書く事自体が目的だから。

>>130
納期に追われ、デスマで死にそうな奴にそんなこと言ったら刺されるぞ。

間に合わせなければいいのに。
そうすれば自然と仕事を適切な規模のところに持っていってくれるし
死にそうな目には遭わずに済むのに。

間に合わせないと無能扱いされて会社を追い出される。追い出されても死にはしないが
金がなくなればやってけなくなる。

本当は俺プログラマになりたかったのに、そういう怖い話ばかり聞かされるから
結局ならんかったよ・・・

一日中コーディング出来るってちょっと羨ましい

コーディングって本当に楽しいか？

コーディング前の、どうやって実現しようかとか、
コーディング後の、なんで動かないんだろ、
と考えてる時の方が圧倒的に楽しくないか？

まぁ、そういうのも含めてコーディングって言ってるのかも知れんが

俺は設計よりコーディングの方が好き、
ステップ数が少なく機能的なコードを書くのが楽しい。

まぁ現状は理想論になりつつあるけど。。

LispやPerlはコード書くこと自体が楽しい

俺はPerlの記号だらけのソースは大嫌いなので見たくもないんだが

Perlは書きたくなることはあるが読みたくはないな
なので矛盾はしていない

俺の中でコーディングというのは感覚的には清書作業に近いな

Perlが好きな奴は三ヶ月後の自分への愛が足りない人

俺はコーディングしながら考えるタイプだから清書って感覚はないなあ
むしろ俺言語でいいからコードっぽいものに起こさないと
思考が遮られてはかどらないや

Haskell ではコーディングしながら考えてると死ぬ

そんなものは使ってはいけない。自分の時間を無駄に捨ててるようなもんだ。

そして時間は次から次へやってくる

あと少しで人生の終点。

だから時間を無駄に使うのはやめろということ。使いやすく、開発効率のいい言語を使え。

そんなものはない

ないと思うなら自分で作れ

言語とか開発環境の変化について行くだけの人生とかありえない
生産性(笑)

>>149
1.よし！作ろう
2.作るために、「使いやすく、開発効率のいい言語」を探す
3.「そんなものはない」事に気が付く
4.1へ

1.よし！作ろう
2.作るために、「使いやすく、開発効率のいい言語」を探す
3.何とか使えるのを探して作り始める
4.出来上がったら、不満があるところを改良していく
5.最初の目的が達成されたら公開する
だろ

Cが駄目なら、C++があるじゃないか

何とか使えるんならそれ使ってりゃいいやん

不便で生産性が悪いから改良するんだろ。
日本人は器用だから使いにくい道具をなんとか使いこなしてしまうが、西洋人は先に使いやすい道具を作る。
道具がいいと生産性が高くなるし誰でも使えるから生産コストがうんと下がる。
器用なことが必ずしもいい結果にならない。

Cで書かれている現役ソフトウェアは大量にある。

全てをJavaで置き換えられると錯覚しそして破滅する。

Cでダメな場面があまりないな

相当慣れないと面倒なだけで

Cで正規表現で置換。

POSIX正規表現 regex.h

検索はできても、置換は実装する必要があるのだよ。

え？まさかその程度のこともできないなんてことはないよな？

置換が必要なアプリだと、簡易的でもGCか賢いコンテナがないと
ヒープメモリがズタズタになってメモリリークしまくりとか。

>>163 クソコードだけど。
#include <stdio.h>
#include <stdlib.h>
#include <regex.h>

#define BUFSIZE 1024
#define NUMBER_OF_BRANKETS 10 /* 0の方が高速 */

/*
*dst : 置換後の文字列を書き込む領域確保済みのバッファ
*src : 置換前の文字列
*st_string : 置き換える文字列
re : コンパイル済み正規表現
*/
int replace(unsigned char *dst,
const unsigned char *src, unsigned char *st_string, regex_t re);


main()
{
regex_t re; /* 正規表現コンパイル結果を格納する構造体 */
unsigned char *re_string = "[0-9]+"; /* 正規表現 */
unsigned char *st_string = "[number]"; /* 置換後の文字列 */
unsigned char *dst, *src, *emsg;
unsigned int ecode; /* エラーコード */

/* 正規表現をコンパイルする */
if(0 < (ecode = regcomp(&re, re_string, REG_EXTENDED))){
// コンパイル失敗時はエラーメッセージを出して終了
emsg = malloc(BUFSIZE);
regerror(ecode, &re, emsg, BUFSIZE);
fprintf(stderr, "%s\n", emsg);

fprintf(stderr, "%s\n", emsg);
free(emsg);
exit(-1);
}

/* メモリーを取得 */
src = malloc(BUFSIZE);
dst = malloc(BUFSIZE);

while(!feof(stdin)){
/* 標準入力から1行入力 */
if(NULL==fgets(src, BUFSIZE, stdin))
continue;
/* 置換を実行 */
replace(dst, src, st_string, re);
/* 置換した文字列を標準出力へ出力 */
printf("%s", dst);
}

/* メモリーを開放 */
free(src);
free(dst);

/* 構造体を開放 */
regfree(&re);

return 0;
}

int replace(unsigned char *dst,
const unsigned char *src, unsigned char *st_string, regex_t re)
{
unsigned char *p, *q;
unsigned int i; /* 入力文字列のための添字 */
regmatch_t *pmatch = NULL; /* 一致データの格納先 */
unsigned int ecode; /* エラーコード */

pmatch = calloc(NUMBER_OF_BRANKETS + 1, sizeof(regmatch_t));

/* パターン・マッチング */
if(REG_NOMATCH == (ecode = regexec(&re, src, NUMBER_OF_BRANKETS + 1, pmatch, 0))){
pmatch[0].rm_so = -1;
}
/* 置換処理用のポインターをセット */
q = dst; i=0;
/* コピーと置換処理 */
while('\0' != src[i]){
/* 正規表現とマッチする位置に来たときの処理 */
/* pmatch[0]が一致文字列全体、pmatch[1]以降が括弧内の部分一致部分の情報 */

if(i == pmatch[0].rm_so){
/* q - dst < BUFSIZE - 2 はバッファー・オーバーフロー対策 */
for(p = st_string; '\0'!=*p && q - dst < BUFSIZE - 2; p++){
*q++ = *p;
}
/* 入力文字列の文字位置を表す添字に加算 */
i += pmatch[0].rm_eo - pmatch[0].rm_so;
/* 再帰でグローバル・マッチングにする */
q += replace(q, src + i, st_string, re);
/* 再帰先で処理が終了しているのでループを抜ける */
break;

} else if(q - dst < BUFSIZE - 2){
/* 1文字コピー */
*q++ = src[i++];
}
}
/* NULL文字をつけ足す */
*q = '\0';

free(pmatch);

/* 置換後の文字数を戻す */
return q - dst;
}

http://uncorrelated.no-ip.com/20101023.shtml からコピペ

Perlだと一行で正規表現で置換できるんだが、POSIX Cだとこんな感じらしい。

これは…人生が短く感じるな
ちなみに、Perlで言うところのどんな操作なんだ？

>>170
こんな処理
while(<>){
s/[0-9]+/[number]/g;
print;
}

つまり数字が連続している文字列を [number] という文字列に変換するってことか？
PerlやRubyでも-peとかやったら1行になりそうだ
sedならむしろ2行以上に伸ばすほうが面倒だな…w

正規表現だけではなく、Cではリストやハッシュ等のコンテナがないので、せっせと実装することになる。

ハッシュ関数も自前で用意する事になるが、数学的に周期が短い関数になると、値が偏るので注意しないといけない。

ANSIには浮動小数点を文字列に変換する関数もない。
printfを使うと速度的に遅いため、高速な変換関数を用意する必要がある。

ANSIのソート関数は、比較関数のオーバーヘッドが大きいため、クイックソートやマージソートを必要に応じて実装する。

ANSI Cには標準的な機能が定義されていない。スレッドや排他処理、共有メモリ、GUIなどの現在のOSでは当然に使えるものの大半が、機種依存コードになる。

Cには、メモリ開放を忘れるリスクと同時に、解放後のポインタにアクセスしてしまうリスクがある。
ポインタが適切な位置を指しているかは、コンパイラはチェックしない。

>>165-168 >>174-178 の問題はJavaやスクリプト言語では解決済み。

そういう時はC++使うんじゃないの

ANSIの仕様にある物もない物も、実装済みである確率はさほど変わらない

最近はJavaからスクリプトを実行できるから面白い。
ある種開き直ったテンプレートエンジンとして使えるな。

なんつうか、どうでもいい部分ばかりだな。

>>1のGLib作者みたいな人と一般PGでは認識が違うのは当然

スクリプトやJava等は、結局環境に応じた実行環境をネイティブ言語で書いておかなければならない。
所詮他の言語が存在しないと役立たずの分際で、デカイ顔してるんじゃないよ。

UI自体が言語だった時代には、Cとshなど複数言語が存在するのが当然だった。
GUIのせいで単一の言語にこだわる人間が増えた。

Cでプログラミングするのは何の問題もない。
問題は単一の言語にこだわることだ。
Cをよく知っている人はむしろこだわらない人の方が多い。

iPadみたいなキーボードレスなのが主流になったら、プログラミングも変わるのだろうかね。

MacBookにはキーボードが付いてるだろ?

>>187
iPad のソフトウェアキーボードを触らせてもらった事あるけど、使い易かったよ

ガシガシ入力するなら Bluetooth のキーボードを使うんじゃないかな
文字を入力する必要があるのはプログラマだけじゃないし

>>189
寝言は

むにゃむにゃ

もう食べられないよお

>>189
スマホよりは使いやすいわな。

Macの超絶クソなアイソレートキーボードより、iPadのソフトキーボードの方が使いやすいくらいだしなｗ

ねーよ

>>3
そもそもcはランタイム支援のない環境でインフラを
構築するために作られた言語。
基礎が整った環境でcを使うなとk&rやlinusも
言っている。
目的を達成できるならshellやら
出来るだけ抽象的なものを使うべき

昔は crt って無かったのかな

C は C で進化してるんだよね
次のスペックではマルチスレッドも採用されるみたいだし

>>28
C++の肩持つ訳じゃないが4%ってどっから出てきた数字だ？
テンプレ関数+スタック変数 (C++)
vs
オーバーライド+new (C#)

だと10倍近く差が出たんだがな。

まぁアプリ全体でずっとnewしてるわけじゃないから

>>66
vb6何て死んだも同然だけど
いまだに使われてるよな。
32bitのサポートが終わったら完全にしぬだろうけど。

Microsoftは潰れてないじゃん。比較にもなってない

>>199
ベクトル(線形幾何)演算やってると悲惨だぞ。
使うであろう座標、ベクトル、行列をstaticにするなり、
配列に集めるなりしてあらかじめ確保しとかにゃならん。

マルチスレッドが普及してから15年以上経って、仕様に取り込むところがC。

軽佻浮薄に流行を追いかけるチャラ男よりも、一本芯が通った時代遅れ。
それでいいじゃないか。

爺にウケるわけだ

C++ の仕様にスレッドって入ってたっけ?

最近入ったかも

>>202
スタックフレームを自作するとかな。
ベクトル用スタックフレーム
行列用スタックフレーム
四元数様用スタックフレームと。
それぞれあらかじめ30個位インスタンスぶちこんどくんだ。
あれ？これってC++の方が楽じゃね？

C++0xで入る

でもまあ、Cでのマルチスレッドとか、ずいぶん前から、APIとしてほぼすべての環境にあったし。
というか、マルチスレッドを言語の機能にする方が間違ってると思うんだが。俺としては。
あくまで、OSが提供する機能だろう？ならばやっぱり、APIとして提供される形こそが理想だと思う。

なんでも言語の機能にすればいいというものではないと思うな。

>>210
言語の機能と API という区分がよく分からないけど、
C1x のスレッドはライブラリなんじゃないの?

>>210
言語仕様と言う意味では、その言語のコア機能だけで実装出来ない機能は
言語仕様に入れて良いと思う。C のコア機能だけではスレッドは実装する事が
出来ないので、スレッドを言語仕様に入れるのは問題無いでしょう。

それ以外にも、よく使用される機能が何度も繰り返し再実装されるのを避ける為に
言語仕様を定めるのも理に適っていると思う。昨今の CPU 実装の変化を考えると
スレッドはますます使用頻度が増えて行くのは確実で、言語仕様に入れるのは
正しいと思う。

標準仕様に含める事で、ポータビリティが上がるという利点もある。統一的な
仕様を決めておく事で、色々なプラットフォームで動作するプログラムを
効率よく実装する事が出来る。移植性の高いマルチスレッドのコードが書ける
様になるのは歓迎すべき事だと思う。

副次的な効果として、C の教科書でスレッドを教えるのが容易になるという点も
意外と重要じゃないかと思う。標準仕様で定まっていれば、初学者が学習する際に
迷う事が少なくなり、マルチスレッドプログラミングの普及がより進むと思う。

Programming languages should be designed not by piling feature on top of feature...
という一節が有名だけど、今の時代、スレッドは言語に含まれてしかるべき
機能だと思うよ。

>>211
言語の機能として実装する場合、その言語を実装する環境すべてでその機能が無いといけない。
つまりOSが無い環境へのコンパイラでも、マルチスレッドを実装するコードを生成しなければならなくなる。

>>213
実際は、freestanding の環境では複数のスレッドを起動しなくても良い事になってる。
C1x の 2010/12 のドラフトの 5.1.2.4 に書いてあるよ。

はて？ C言語ってOSがない環境で
ファイル読み書きできたっけ？

>>215
それ、C言語とかんけいない。

まぁ普通OSが無くてもFW経由で読み書きできるんでないかい

>>216
標準ライブラリはISOのC言語仕様の一部ですよ
勿論ファイル入出力はそれに含まれています

>>218
言語の仕様には入っていない。

>>212
昨今の変化を考えるというなら
簡単に変化できないような堅苦しい仕様書を作ってはいけない

JavaのThreadは1994年から、ほとんど使い方に変化が無い。

>>220
今度の仕様で策定される様な部分はスレッドの本当に基本的な部分で
長年の実績に基づいた機能だから簡単に変化する様な物ではないと思われ

むしろ基本の部分の仕様が固まる事で、その上に様々なライブラリを
構築する事が容易になって、言語の発展に大いに寄与する事と思われる

>>221
Thread Classがあまり変わっていないだけで、それの使い方は大いに変わっている。

Class を変えずに色んな使い方が出来るなら結構な事じゃない
どう転んでも新しい技術の脚を引っ張らないって事でしょ

>>222
長年の実績で固まった機能が言語の発展に寄与した。
これは過去の話だ。
まともな人間なら「固まる事で、寄与する事と思われる」なんて言わない。

普通に言うだろ。
まともな人間は本筋に関係無い所で無意味な難癖をつけたりはしない物だよ。

だな

>>221
んなこたーない。
例えばスレッドの止め方一つ取っても当時と今じゃ全く違うだろ。

>>228
詳しく。

deprecateされてるだろ

>>226
難癖つけるやつがいないなら、厳密な仕様書も要らない

そいつは結構、好都合

昔からスレッドはkillすると、システムが不安定になるもんです。API的には用意されているけどね。

>>215
I/Oの機械語コード並べた配列を関数ポインターにぶちこんで呼ぶか、
あればメモリマップドI/Oを使えばいい。
でも、これ物理デバイスを制御できるだけでファイルシステムは自前で
作らなきゃならん。

「Cでプログラミングするには人生は短すぎる」か？
http://hibari.2ch.net/test/read.cgi/tech/1296486174/

工学や理学の問題を解きたくてプログラム勉強し始めたのに、
プログラミング技術の果てしない探求に取り付かれて
プログラムは手段である事をすっかり忘れちゃうよね。
解決したい問題をさっさと解ける可能な限りの高級言語を使うのがいいと思った。

手段が目的になっちゃうね

手段が目的になる。大いに結構。
目的が感嘆には達成されないからこそ人類の発展があったんだよ。
そうじゃなきゃメシ食ってSEXして寝るだけの存在になってただろう。

「今こそAndroidはJavaを捨ててMonoを採用する時です」
http://twitter.com/#!/migueldeicaza/status/81755106231599104

>>238
気持ち悪いんだよ　氏ねゴミ


マジレスすると、Ｃはもうそんなに使えなくても良い
ＪＡＶＡ以外をやれよｋｓが

>>239
つ Go

>>241
Go(笑

>>242
楽しそうだなw

ｗｗｗ#

u(o#www#o)y

>>245
かわいい

てｓｔ

>>240
Javaはオワコン

cが重厚プログラムだと思ってるやつが馬鹿。

>>236
そんなこと言ってる研究室のハゲは、
ポインタを理解していないどころか、構造体の意味も理解していない、
随所にマジックナンバーを埋め込んで、
数値計算ライブラリの利用方法も知らずに
逆行列を求める自作のプログラムをよこしてきて、
極めつけにはループ用変数のi,j,kをグローバルにしている

そんなヤツにソースコードが汚いと言われる日々
地底の情報系研究室は地雷だらけだぜ

こんなのを見た日には、Cが嫌いになる。

a+++++b;

そうか？頭の中で違和感なく一瞬で
a++ + ++b;
に変換されたんだけど。

じゃあ最初からそう書けば良い。

そんな書き方するやついないし

c+++++love

int orz=3;

IOCCC(The International Obfuscated C Code Contest
国際邪悪なCコードコンテスト)のコードは凄まじいな。仕事で似たような
コードをやられたらたまらん。

トリッキーなコード書きたくてしょうがない人のガス抜きになっているという説もある＞IOCCC

教えてあげないよ雀

トリッキー　→　ポ●ンキー　かw

トリッキー　トリッキー　錯覚系の秘密はね

ﾎｼｭ

俺も次が最後のプログラム

C++でプログラミングするには人生は短すぎる

結論：Cでプログラミングをすると人生が短くなる

わらたｗ

c#すら面倒なんで、pythonつかうよ

Cは、それ自体が目的と化してしまう。

Cでプログラミングしてると、プログラムをそもそもつくろうとした目的を忘れてしまう
脳の容量がたくさんないとやってられない

高速化、最適化（自分の思い込みが多分）が
目的になってしまうことがあるな

つまりホントの目的が達成できないと

それは苦Cな

>>272

たいていのプログラムは20年もあれば完成するよ

80人月のプログラムを一人で作るとか泣きたくなるな

Ｃじゃなきゃできないこと以外ではＣは使いたくないな
めんどくさい

デバイス屋は、C(もしくは、C++)しか使わないという噂は本当か?

x 使わない
o 使えない

ついでに言うと C++ も所謂 better C としての使い方しか出来ない

っていうかC++でプログラミングしててなんかいいことあったの？
自己満足以外で

Cのほうがよかったね

STLには、お世話になった。boostは使ってなかったから、auto_Ptr止まりだけど、メモリ管理からの解放になれると、Cには戻れない。

今はもう使ってないけど

今は使わなくなった理由は？

.NETやってるとレガシーモジュールをラップするのにC++/CLI使わざるを得ないよ

>>282
その頃使ってたフレームワークが廃れてしまったのと、Javaやスクリプト言語に流れたから。

よりメモリ管理から解放されたのが大きい。
最高のパフォーマンスを求めるのであれば、C / C++になるのだろうけど、現状そこまで必要としてないから。

アプリなんてメモリ管理しなくても
終了時にOSが捨ててくれるだろ

Cをやることが目的になってしまう

プログラミング言語にはレイヤーがあるからな。
どの言語も同じレイヤではない。
�@OSやさらに上級のプログラミング言語、仮想環境をつくる言語：C,Go
�A上記の言語でつくられた環境でプログラミングするための言語：Java、C#
�B簡単にコンピュータに対し命令を指示する言語（スクリプト）：Perl,Python,Ruby,PHP,Javascript

�BをやるためにCで書くのは確かに時間がない
�Aを目的としても同じ。
ただし、�@をやるためには、Cくらいしか適した言語はないだろう。

おまえの理論ならJavascriptはレイヤ4だ

弘法筆を選ばず

うすうすそうなんじゃないかなって思い始めてたよ

>>287
もちろんそうなんだけど、
Ｃで�Aや�Bをやろうとしてた時代があったんじゃないの

そのころはＣプログラマの寿命はもっと長かった

寿命が延びたんじゃなくて納期が短くなった
リーナスがＬｉｎｕｘ作ったみたいに、納期気にしなければ作れるわけで

同意

大半の自称プログラマにはいくら時間があっても無理

自称ってどこまでの範囲

サンプル見ながら打ち込んでコンパイルして実行出来ます(ｷﾘｯ)

くらい

>>293 みたいのだろ

時間が無限にあれば作れるのは自分がつくったフリーソフトを今誰かが使ってありがとうって言ってくれてるレベルだろ

リーヌスは苦しょっぱい青春しながら+学生としての勉強しながら作ったんだろうから、時間が無限にあった訳じゃない。もっと上だな。

俺？無料に決まってんじゃん

アホか俺
無料じゃねえ無理だろ(鬱

まあ無限は言い過ぎだな
0×∞
を定義しようとしているようなもんだ

プログラミングするには人生は短すぎるお

http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

Cだろうが何だろうが、完成させなきゃ何を使おうが変わらん。
生産性がどうのと語ろうが、現実完成した成果物を出せてないならなんの意味もない。

>>287
名無しにしては随分マシなレスをかくなと思った
入門書の最初にレイヤーについては書くべきだね
そうしないと1個の言語で何もかもやろうとする奴が絶えない

本職でプログラマやる奴は、1,2,3のレイヤークリアして無いとカスだわ
趣味でやるにしてもレイヤー3だけはクリアしてないと正直見てて可愛そう

Rubyは必死にレイヤー2に干渉しようとしてるけど
もっと並列化が進んで速度上がらないと無茶かなぁ

>>304
何を言いたいのか分かりません

>>1
C++も仲間に入れてやってください。

【消しゴム】MONOを使ってみるスレ4【じゃない】
http://toro.2ch.net/test/read.cgi/tech/1329023778/

>>307
この人、C++を拒絶しまくってたからな。

Webコミック「21日でC++を習得する方法」
http://gihyo.jp/dev/clip/01/orangenews/vol56/0009

これでお前らでもC++が使えるようになる！

言語の基礎部分だけなら1週間もあれば充分かもな。
実際VC++の昔のチュートリアル本なんて、びっくりするくらい薄かったし。

何がLinuxデスクトップを殺したか
著者： Miguel de Icaza
日本語訳： yomoyomo
http://www.yamdas.org/column/technique/linuxdesktopj.html

このひと、相変わらずだぜｗ

よく1週間とか日にちで習得日数いう奴いるけど、
てめーは1日何時間なんだよ

って思う
1日1時間しか集中できないごみ化すなら市ね

エンペツ方面がコケそうだからかね、この兄ちゃんのいいたい事って

>>13
>>14
ヘイ! おまえたちラッパーを馬鹿にするなYO!

>>23
♪闘う君の歌を〜闘わない女が歌うんだろ〜

>>274
プログラムとソフトウェアを混同する人おおいよね

>>279
実験用の書き捨てコードに便利。
javaやc#じゃネストが深いし、ファイル数とタイプ数が多くて嫌

効率もとめて新しいものいちいち追ってる間に
Cで書いたほうがはるかに早いことを悟った
もう新しい言語はいらない

Cの標準ライブラリに連想配列はありますか？

>>319
ありません。

なんかそのへんに転がってないっすかね

ggrks

MONOで作るって人生を賭けて作るようなモノじゃないから。
２、３日後の明方には既に腐ってるようなモノだから。

カスｗ

>>3
Objective-CやれObjective-C

彼らはBASICから得られた体験を ” タブー視 ” しなければいけないため、常に孤立を要求される。

ゲーム業界ではいまだにアセンブリゴリゴリ書くらしくて驚いた

隅から隅までって訳じゃあるまいし
キモのところでアセンブリ書いててもおかしくない
柔軟さが要求される部分ではLua とか使ったりもするらしいし

Cはいくらライブラリ作っても何も蓄積されない感がある。
オブジェクト指向を駆使してもC++じゃ今一歩だめだ。
javaくらいの簡易さでやっとライブラリに価値が生まれるレベル。

Cは詰めが甘いから早く絶滅させるべき

Cでプログラミングするには人生は長すぎるんじゃないか？

人生を記述し切っているCソースを見てみたい