07/07/21 18:29:25
D言語で
3:デフォルトの名無しさん
07/07/21 18:58:52
>>1
この素人め
お前には無理
削除依頼出しとけ
4:デフォルトの名無しさん
07/07/21 19:39:27
コンパイラ誰が作ってくれるんだよ
5:デフォルトの名無しさん
07/07/21 19:44:57
変数は文字列型と実数型のみで。
6:デフォルトの名無しさん
07/07/21 19:45:29
実数は誤差なしで
7:デフォルトの名無しさん
07/07/21 19:51:49
インタプリタで。
8:デフォルトの名無しさん
07/07/21 19:57:18
Interpreter C言語
9:デフォルトの名無しさん
07/07/21 20:20:15
>>1
それなんてC++
10:デフォルトの名無しさん
07/07/21 20:24:42
ぐぐらずに質問。
C++ってjavaみたいにnew演算子で動的にオブジェクト生成できるけど、
あれってC++にもガーベージコレクションがついてるってこと？
ＶＭでもないのにどうなってるの？
コンパイル時にコンパイラが
スコープとか計算してメモリ開放処理を付け加えてるの？
11:デフォルトの名無しさん
07/07/21 20:26:06
>>10
newしたらdeleteしなきゃならん。
mallocしたらfreeするのと同じ。
12:デフォルトの名無しさん
07/07/21 20:27:43
>コンパイル時にコンパイラが
>スコープとか計算してメモリ開放処理を付け加えてるの？
じゃあこの機能欲しいね。
13:デフォルトの名無しさん
07/07/21 20:29:58
最近の小学校は夏休みの宿題にC言語を作らせるのか
14:デフォルトの名無しさん
07/07/21 20:32:27
コンパイラは作らない。
機能内容と実装方法の提案だけ。
15:デフォルトの名無しさん
07/07/21 20:34:23
といっても、JavaとかC++とかC#とか他ruby、関数型言語の
後追いをしても仕方がないので
あくまでもC言語をベースに革新的な言語を作る
16:デフォルトの名無しさん
07/07/21 20:57:49
>>10
> コンパイル時にコンパイラが
> スコープとか計算してメモリ開放処理を付け加えてるの？
scoped_ptrやshared_ptrならまさにそんなことをやってくれる。
17:デフォルトの名無しさん
07/07/21 21:06:29
言語仕様はそのままでDirectXかopenGLのプログラムしかつくれないC言語は？
C+ライブラリの開発環境だとめんどくさいことが多い。
最初から3Dを意識した仕様にしてみては？
18:デフォルトの名無しさん
07/07/21 21:23:37
>>17
言語仕様がそのままなら、一体何をするっての？バカだろ
19:デフォルトの名無しさん
07/07/21 21:42:32
C++やObjective-Cに秋田から
Cでいいや
20:デフォルトの名無しさん
07/07/21 21:51:41
だが、今更Cに戻る気にもなれない。
21:デフォルトの名無しさん
07/07/21 22:01:38
言語使用って言ったのが悪かった。
構文はそのままって意味。
22:デフォルトの名無しさん
07/07/21 22:08:39
>>21
nara
Java
demo
yookune?
23:デフォルトの名無しさん
07/07/21 22:16:42
重箱の隅
24:デフォルトの名無しさん
07/07/21 23:04:04
Objective-C
C++
D
好きなのを選ぶﾖﾛｼ。
25:デフォルトの名無しさん
07/07/21 23:16:14
車輪の再発明スレか
26:デフォルトの名無しさん
07/07/21 23:34:21
D言語改良するんだったら期待するのに。
27:デフォルトの名無しさん
07/07/22 07:32:34
C系の言語にはまだ型推論の導入された言語ってないんじゃね？
28:デフォルトの名無しさん
07/07/22 09:01:12
でもさ、ラムダ式ベースの構文じゃないのに
型推論って導入できるの？
あ、構文木をラムダ式に変換すればいいだけなのかな
29:デフォルトの名無しさん
07/07/22 09:03:09
C++0xでどうなるか期待
30:デフォルトの名無しさん
07/07/22 09:06:35
>>27
DとかC# 3.0とか
31:デフォルトの名無しさん
07/07/22 09:18:10
ところでＣ++の例外処理ってどうなってるの？
ＶＭもないのにどうやって検出されるの？
32:デフォルトの名無しさん
07/07/22 09:38:08
setjump/longjumpを応用したり、 (g++のsjlj eh)
OSが例外処理を持っていたり。（WindowsのSEH）
33:デフォルトの名無しさん
07/07/22 09:57:23
>>32
１つめのはコンパイル時に自動挿入ですか？（setjump/longjump）
34:デフォルトの名無しさん
07/07/22 10:00:15
どう見てもバグであろう部分を、自動的に補正してくれるバグ推論ができたら、是非宜しくお願い致します
35:デフォルトの名無しさん
07/07/22 10:10:37
>>33
それは当然。
例外処理なんてようするに関数を越えたジャンプにデストラクタの後片付けを入れただけ。
検出するなんてものではないと思う。
36:デフォルトの名無しさん
07/07/22 11:36:08
>>34
もっと酷いバグ作りこむかもしれないけど、それでいい？
37:デフォルトの名無しさん
07/07/23 23:19:17
変数名や関数名に日本語が使えるようにしてほしい。
プログラムの保守性が絶対に上がるよ。
38:デフォルトの名無しさん
07/07/23 23:28:02
使えたとしても使わないのが多数じゃないか？
Javaは使えたよな？C++も使えるんだっけ？
ジョークプログラムでたまに見るが、？が頭を駆け巡る。
慣れの問題で済む程度じゃないと思う。
39:デフォルトの名無しさん
07/07/23 23:42:28
変換とかさせる言語はクソ
ひ○わり
なで○こ
40:デフォルトの名無しさん
07/07/24 01:48:24
C にクラス「だけ」を追加した言語が欲しい
それ以外の、C の素朴さを損なう様な追加機能は要らない
カプセル化はオブジェクト指向の本質ではないので要らない
テンプレートでメタプログラミングとかも要らない
総称関数も要らない
GC も要らない
クロージャはあったら嬉しいけど、動的クロージャなら何の役にも立たない
本来の意味の C w/ Class が欲しい
GLib とかじゃなくて
みたいな事を考えてた事もあった
41:デフォルトの名無しさん
07/07/24 02:51:47
C って素朴か……？
42:デフォルトの名無しさん
07/07/24 05:38:49
とりあえずC言語に足りないものを全て列挙してみようか
43:デフォルトの名無しさん
07/07/24 13:17:34
処理系依存
44:デフォルトの名無しさん
07/07/24 13:20:01
排他的再帰
45:デフォルトの名無しさん
07/07/24 16:59:44
マンコ
46:デフォルトの名無しさん
07/07/24 19:20:20
自動コーディング
47:デフォルトの名無しさん
07/07/24 19:58:38
型推論と例外処理とクラスだけのオブジェクト指向とnew演算子
48:デフォルトの名無しさん
07/07/24 20:04:38
逆にプリプロセッサ要らない。
何らかの代替機能を用意した上で廃止してくれ。
49:デフォルトの名無しさん
07/07/24 20:18:16
java 使ってると C のマクロが非常に恋しくなる。マクロは残してもらいたいなぁ。
50:デフォルトの名無しさん
07/07/24 20:45:39
むしろlisp級にまでマクロ強化
51:デフォルトの名無しさん
07/07/24 21:00:44
結局C++が出来上がる気がするな
52:sage
07/07/24 21:09:48
Ｃ+++
53:デフォルトの名無しさん
07/07/24 21:38:12
C--
54:デフォルトの名無しさん
07/07/24 21:39:30
>>50ではないが、俺もマクロの強化を望む。
lisp の defmacro の強力さを知らんのだよ。
Symbolics の FORTRAN はマクロによって lisp に展開されていた。
餓鬼どもには想像も出来んだろうがな（ｗ
55:デフォルトの名無しさん
07/07/24 21:39:40
実はC言語はこんなこともできないのです。
int f(int n) { return n + 1; }
int g(int n)
{ int x = f(n);
{ int x = f(x);
{ int x = f(x);
return x;
}
}
}
int main() {
printf("g()=%d\n", g(1));
return 0;
}
さて、g(1)はいくつを返すでしょう？
このコードに対してエラーも警告も出さなかったコンパイラがあったら要注意です。
C言語は { int x = f(x); ～} を期待通り処理しません。
初期化式中のxは変数宣言xによって既に親を上書きしています。
つまりこの規則は変数のアドレスを再帰的に初期化式に
適用したいというかなり特殊な状況以外に全く役に立ちません。
h() {
struct _tag {
struct _tag *next, *prev;
} a = {&a, &a};
printf("&a=%d a.next=%d a.prev=%d\n", &a, a.next, a.prev);
}
変数のアドレス限定なのは、初期化式中に変数の値を参照しても
何の意味もないからです。もし参照してたらエラーにすべきでしょう。
56:デフォルトの名無しさん
07/07/24 21:42:19
?
57:デフォルトの名無しさん
07/07/24 21:47:19
int g(int x)
{ int x = f(x);
{ int x = f(x);
{ int x = f(x);
return x;
}
}
}
だとエラーになった
: error C2082: 仮引数 'x' が再定義されました。
int g(int n)
だと警告
: warning C4700: 値が割り当てられていないﾛｰｶﾙな変数 'x' に対して参照が行われました。
(VC6SP4)
58:デフォルトの名無しさん
07/07/24 21:47:59
>>55
で、お前はそれがどうなったらいいと思う？
初期化式では、初期化対象の変数がまだ見えないようにするのか、
そもそもコンパイルエラーになるようにするのか、
はたまたそれ以外の方法があるというのか。
59:デフォルトの名無しさん
07/07/24 21:48:56
では、この辺の規則がしっかりしてるSchemeだとどうなるでしょう。
(define (f x) (+ x 1))
(define (g x)
(let ((x (f x))) (let ((x (f x))) (let ((x (f x))) x))))
(g 1)
=>4
まさに期待通りです。
まったくSchemeは素晴らしいですね。
60:デフォルトの名無しさん
07/07/24 21:51:18
>>55
そんなの当たり前のじゃん…
61:48
07/07/24 21:51:33
>>50
LISPみたいなのだったらありだ。
Cプロセッサは、C自体の字句解析と独立しているから、
IDEの入力支援機能なんかと相性が悪いはず。俺はそれが嫌なんだ。
62:デフォルトの名無しさん
07/07/24 21:53:26
>>57
いきなり関数の引き数と同じ名前で自動変数宣言すんなｗ
63:デフォルトの名無しさん
07/07/24 21:55:39
むしろ何を期待すれば>>55になるの？
64:デフォルトの名無しさん
07/07/24 22:02:49
>>55-59
そりゃ、変数に対する考え方が違うから当然だろ。
Cの変数つうか識別子は、つまるところ名前付きメモリ領域だからな。
ん、むしろ、これで当然（そしてSchemeも当然）と思える
俺の方がどうかしてるのか？
何か悩んだり面白がったりするものなのか？
65:デフォルトの名無しさん
07/07/24 22:25:36
>>64
どうかしてる。
>>57相当の事をしたいとなると、わざわざ別名を考える必要が
出てきて思考の妨げになるじゃん。
66:デフォルトの名無しさん
07/07/24 22:30:22
変数の初期化式中にその変数自身が含まれるべき、
なんて普通は考えないからな。違うスコープにある方が自然だろ。
C言語が一般的になりすぎたとか、そういう言語に慣れすぎたとかで、
その違和感に気付かないのかもしれないな。
67:デフォルトの名無しさん
07/07/24 22:33:17
変数でどうにかしようと考えるからだ。
C系言語的には、そういうときは変数名じゃなく型名を定義する事を考える。
つまりクラスにする。
あ、Cではクラス無理かw
68:デフォルトの名無しさん
07/07/24 22:37:20
C言語だとマクロに変数が入る時とかで困るんでは。
#define G(n) do { int x = f(n); return x; } while(0)
int g(int n)
{ int m = f(n);
{ int x = f(m);
G(x);
}
}
: warning C4700: 値が割り当てられていないﾛｰｶﾙな変数 'x' に対して参照が行われました。
69:デフォルトの名無しさん
07/07/24 22:45:27
その例なら、C99やC++でインライン関数使えばいいよ。
70:デフォルトの名無しさん
07/07/24 22:45:58
すまんこれはマクロでないと無理だなorz
71:デフォルトの名無しさん
07/07/24 22:47:58
>>59のgは
(define (g x) ((lambda (x) ((lambda (x) ((lambda (x) x) (f x))) (f x))) (f x)))
と等価という考え方であり、つまり初期化式は関数適用と同じスコープで
評価されるので、xは親を参照するという事が自然と自明になり、
文脈上のあいまいさもありません。Schemeにはletの他にlet*やletrecもあり、
こういった束縛規則をコントロールできます。
Schemeの変数束縛はとても理に適った設計なのです。
72:デフォルトの名無しさん
07/07/24 22:50:08
何か似たような問題を（もっと実用的な例で）解けるデザパタがあったような。
TMPという手もあるけど、それは今の流れ的にお呼びでなさそうだな
73:デフォルトの名無しさん
07/07/24 22:54:15
>>71
だから変数の考え方が違うと何度言えば
74:デフォルトの名無しさん
07/07/24 22:58:30
つまりboost::lambdaがあるC++最強だな
75:デフォルトの名無しさん
07/07/24 22:59:37
> struct _tag {
> struct _tag *next, *prev;
> } a = {&a, &a};
おれもこれは最初ｷﾓｲなーと思ったけど、必要悪かな。
グローバル変数のテーブルの初期化とかでちょっとイイ思いができるとか。
(初期化でコードを書かなくて済む)
書き忘れさせないとか、消極的な理由。
今の言語にはコンストラクタがあるから、そういう事気にするのは減ったけど。
76:デフォルトの名無しさん
07/07/24 23:04:40
>>73
そのｵﾒｴの考え方がそもそもｷﾓｲんだよ、というお話では
77:デフォルトの名無しさん
07/07/24 23:08:10
>>74違うw
78:デフォルトの名無しさん
07/07/24 23:09:27
新しいC言語には
classical int x = f(x) ; // エラー
int x = f(x) ; // OK
という風にclassicalキーワードを用意してみては
struct _tag {
struct _tag *next, *prev;
} a = {&a, &a}; // えらー 無効なaを参照した
79:デフォルトの名無しさん
07/07/24 23:14:31
>>78そのfに渡す初期値はどう決めるのよ？
>>74
boost::scheme…いや何でもない。冗談。
80:デフォルトの名無しさん
07/07/24 23:16:15
ヘッダファイルをやめようぜ
81:デフォルトの名無しさん
07/07/24 23:18:36
同意。
コンポーネント単位でインクルード出来てもいい。
82:デフォルトの名無しさん
07/07/24 23:23:10
確かに>>55は見ただけだと問題なく通りそうではあるし、
移植を繰り返して警告沢山出る様な引継ぎコードの一部だったりして、
しかもテスト環境がたまたまxが普通の値をとったりして、
とんでもない間違いにそのまま気付かないでデスマーチ突入とか
ありそうで笑える。
83:デフォルトの名無しさん
07/07/24 23:30:02
俺ならこんなの発見したら、
即消して書き直すかな…
84:デフォルトの名無しさん
07/07/24 23:41:32
つーか
int x = f(x);
と書いている時点で相当キモイ
こういうキモイ書き方を右辺のｘがより広いスコープのxだと思って書く奴はもっとキモイ
そしてそれを期待する奴はどうしようもなくキモイ
そうなる様に言語仕様を変えろという奴は氏んでくれ
85:デフォルトの名無しさん
07/07/24 23:50:26
lisperは害悪ということだけは分かった
86:デフォルトの名無しさん
07/07/25 00:01:30
>>84
お前が子ねカス
87:デフォルトの名無しさん
07/07/25 00:10:35
>>84
DとかC#とかだとコンパイルエラーになったような気がする。
88:デフォルトの名無しさん
07/07/25 00:38:45
階層的なデータ構造をコードで記述していく場合、
同じ名前の変数を宣言したい事がよくある。
例えばこういう画面レイアウトの構造を定義したい時、
--------------------------
[button1] (空き) [button2]
--------------------------
[button3]
(空き)
[button4]
-------------------------
こんな感じの定義方法を思いついた。
{ void *resource; lay_t lay = layout_create();
{ lay_t vert = layout_push_vertical(lay);
{ lay_t vert2 = layout_push_vertical(vert);
layout_push_control(vert2, "button1");
layout_push_blank(vert2);
layout_push_control(vert2, "button2"); }
{ lay_t horiz = layout_push_horizontal(vert);
layout_push_control(horiz, "button3");
layout_push_blank(horiz);
layout_push_control(horiz, "button4"); }}
resource = layout_make_resource(lay);
layout_destroy(lay);
return resource;
}
この時、vert2の箇所をそのままvertとしてしまったり、
さらに階層が必要になった時、その変更を元に戻したくなった時、
定義した構造ブロックを他で使いまわしたい時、
などで修正が面倒になる。
まあ適当な構造記述言語でも作ればいいんだけど。
89:デフォルトの名無しさん
07/07/25 00:42:52
ごめん、上で定義した構造は↓の間違い。
--------------------------
[button1]
(空き)
[button2]
--------------------------
[button3] (空き) [button4]
--------------------------
90:デフォルトの名無しさん
07/07/25 00:54:31
もうね、関数内でも名前空間を定義できるようにしたら万事解決だよ。
int g(int n)
{
namespace n1
{
int x = f(n);
namespace n2
{
int x = f(n1::x);
namespace n3
{
int x = f(n1::n2::x); //C++的名前空間ならn2::xでもいけると思う
return x;
}
}
}
}
俺はこんなの欲しくないけど。
91:デフォルトの名無しさん
07/07/25 08:56:14
Perlだと理屈の上ではpackageでそれができる。
しかしそういうキモイ書き方使い方は見たことない。
92:デフォルトの名無しさん
07/07/25 09:23:20
話がズレ始めてるんで一応書いておきますが、
特別な事をしなくとも
#define letend }}
#define let1(type, var, init) \
{ type let_tmp = init; \
{ type var = let_tmp;
#define let2(type, var, init, type2, var2, init2) \
{ type let_tmp = init; type2 let_tmp2 = init2; \
{ type var = let_tmp; type2 var2 = let_tmp2;
実はこれだけでschemeのlet束縛を再現できます。(>>72おしい)
int f(int n) { return n + 1; }
int g(int x)
let2(int, x, f(x), int, y, x)
printf("x=%d, y=%d\n", x, y);
let1(int, x, f(x))
let1(int, x, f(x))
return x;
letend
letend
letend
ここでyの初期化式として使われるxはgの引数のままであり、
f(x)の影響を受けません。g(1)を実行するとx=2, y=1と
表示されることから、Schemeのletと同じ動作だと確認できます。
93:デフォルトの名無しさん
07/07/25 14:06:47
あーブロック2重にするのか。思いつかんかった。
94:デフォルトの名無しさん
07/07/25 19:17:15
コンパイラの実装の手間も考えようぜ。
95:デフォルトの名無しさん
07/07/25 21:52:01
標準Ｃコンパイラのソースってどこかに無料であったりするの？
それを拡張していけばいいのでは
96:デフォルトの名無しさん
07/07/25 21:54:00
GCCは？
すでに拡張されてるけど
97:デフォルトの名無しさん
07/07/25 22:01:02
tccとか
98:デフォルトの名無しさん
07/07/25 22:05:24
なぜ今更C言語を拡張?
D言語(gdc)やC++0x(g++)をベースに改良すればいいのに。
99:デフォルトの名無しさん
07/07/25 22:28:07
D言語w
100:デフォルトの名無しさん
07/07/26 02:15:52
>>98
D や C++ は太り過ぎだから
101:デフォルトの名無しさん
07/07/26 04:32:28
Cがガンダム、初期C++がゼータ、テンプレ付きC++がダブルゼータだとしたら、
百式ぐらいのをきぼんぬ
つーかシャアが乗ってそうなやつ
102:デフォルトの名無しさん
07/07/26 10:01:54
#include <stdio.h>
int main() {
printf("Hello, World!\n");
return 0;
}
とりあえず、これの拡張版はどんな感じになる？
103:デフォルトの名無しさん
07/07/26 12:14:30
#using <mscorlib.dll>
int main()
{
System::Console::WriteLine("Hello, World!");
}
104:デフォルトの名無しさん
07/07/26 21:36:19
List x = [1,2,3,4,5];
List y = [];
for (int i=0; i < x.length; i++) {
y = x.drop(i)::y;
}
// y = [5,4,3,2,1]
105:デフォルトの名無しさん
07/07/26 21:47:01
import std.stdio;
void main(){
"Hello, World".writefln();
}
106:デフォルトの名無しさん
07/07/28 10:20:53
おい、おまいらもっと一瞬見ただけで「それは使ってみたい」と思わせるような提案してください
107:デフォルトの名無しさん
07/07/28 10:23:20
#pragmaで切り替えることで新CとC++のコードを混在できる。
108:デフォルトの名無しさん
07/07/28 12:09:34
>>1
は夏休みに入った中学生かなんかだろ
もしかして本当に新C言語ができちゃうかも
そうしたら俺の名前って有名にならね？とか
109:デフォルトの名無しさん
07/07/28 17:11:00
拡張からはじめたほうがいい。
拡張しやすいフリーのコンパイラは？
gccはなんかね・・。
Ｃ言語のコアの部分だけひっぱってきて。
110:デフォルトの名無しさん
07/07/28 18:05:58
前方参照が欲しいなぁ。
111:デフォルトの名無しさん
07/07/28 18:34:53
とりあえず今までスレで出たのまとめてみた。
重要なもの
-クラス・テンプレートの追加(>>1)
-型推論と例外処理(>>47)
-マクロ強化(>>50,>>54)
-ヘッダファイルをやめる(>>80-81)
-#pragmaで新CとC++を切り替えられる(>>107)
-前方参照(>>110)
あまり重要じゃないもの
-変数名・関数名で日本語が使えるように(>>37)
-関数内でも名前空間が使えるように(>>90)
矛盾しそうなもの
-言語仕様をDやC++より軽く(>>100)
ああ、それとC言語+クラスだけでいいならObjective-Cで十分な気ガス。
あと、これらを実装するならg++かgdcをベースに要らない機能を削ってってそれを基にした方が良いと思う。
112:デフォルトの名無しさん
07/07/28 21:17:35
> -変数名・関数名で日本語が使えるように(>>37)
これ今の仕様でもできるっしょ。
113:デフォルトの名無しさん
07/07/28 21:28:12
>>112
Cで出来たっけ？C99ではできるのか？
114:デフォルトの名無しさん
07/07/28 21:28:59
日本語見ると、どうしても文字列リテラル内と勘違いするんだよな……
115:デフォルトの名無しさん
07/07/28 21:32:37
自分C#もやってるけど日本語識別子は使ったこと無いな
116:デフォルトの名無しさん
07/07/28 21:58:19
ＶＢＡでたまに使う＞日本語
使う理由は英語スキルが低いので名前考えるのが面倒ってだけ。
117:デフォルトの名無しさん
07/07/28 23:03:47
>>113
少なくとも処理系依存の範疇で可能なはず。
つまり、やれるようにしたところで規格違反にはならないということ。
それよりも個人的には全角空白を空白類文字として使用可能にしてほしい。
（もっと一般にUnicodeの空白系の文字全般を対象にすればいい）
掲示板で全角空白使ったコードをそのままコンパイルできないのは不便。
118:デフォルトの名無しさん
07/07/28 23:36:45
URLﾘﾝｸ(seclan.dll.jp)
119:名無しさん＠そうだ選挙に行こう
07/07/29 01:23:18
XML 2.0 で要素名にいろんな言語が利用できるようになったけど、これって互換性の維持や
他か国語の環境での可読性とかで酷評されてたと思う。
やっぱり日本語変数とかは勘弁して欲しいと思う。
日本国内の環境でも
enum SMAP {中居, ...};
とかで「草薙」が表示できるかできないかとかで悩まなければならないのはまずいと思うし。
120:名無しさん＠そうだ選挙に行こう
07/07/29 02:14:11
>>111
>ああ、それとC言語+クラスだけでいいならObjective-Cで十分な気ガス。
残念ながら ObjC は動的型付けなので、十分とは言えない人間も居るのです。
121:名無しさん＠そうだ選挙に行こう
07/07/29 06:08:46
>-前方参照(>>110)
これってどういうの？
122:名無しさん＠そうだ選挙に行こう
07/07/29 11:38:52
とりあえず、クラスだけ追加してみては。
その際に、C++よりjavaを基にしてほしい。
多重継承なし。とか、
C++のクラス定義はきもい。スコープ演算子::とか？
123:名無しさん＠そうだ選挙に行こう
07/07/29 12:10:39
C++の設計と進化 (D&E)によれば、最初は::ではなく . を使っていたんだが、
class X X;のようにクラス名と同名の変数が作られたときに曖昧さが起こるから、
これを回避するために::を導入したとある (§3.11.3)。
124:110じゃないけど
07/07/29 18:02:20
>>121
後ろで宣言したものでも使える。後方参照とも言う。
Dの例(前方参照あり):
void foo(){
bar();
}
void bar(){
}
Cの例(前方参照無し):
void bar(void);
void foo(void){
bar();
}
void bar(void){
}
125:名無しさん＠そうだ選挙に行こう
07/07/29 18:34:48
>>121 じゃないけど、後方参照は知ってるが、後方参照の事を前方参照と呼ぶ人もいたのか
どっちが一般的なんだろ
126:名無しさん＠そうだ選挙に行こう
07/07/29 18:54:23
「前”から”参照」 か 「前”を”参照」 かのどっちかなんだから、あまり気にしないほうが良いと思う。
127:名無しさん＠そうだ選挙に行こう
07/07/29 18:58:49
forward referenceとback referenceが区別できないのは困ると思うけど。
128:名無しさん＠そうだ選挙に行こう
07/07/29 19:17:20
前方参照 後方参照
前方宣言 後方宣言
129:デフォルトの名無しさん
07/07/29 21:11:10
>>124
「後ろで宣言した」と言うのが間違い。
コンパイラは「ソースを読み進めて行く」んだから、
ソースの下のほうが「前方」だよ。
勘違いしている人が多いので、後方参照とか書いてあるバカ本があったりする。
130:デフォルトの名無しさん
07/07/29 21:58:02
なるほろ
視点はあくまでコンパイラ…と
131:デフォルトの名無しさん
07/07/30 00:29:29
へー、そういう解釈の一派もあるんだ…
132:デフォルトの名無しさん
07/07/30 21:29:18
先読みって言い方はするね
133:デフォルトの名無しさん
07/07/30 22:13:52
>>131 バカ本著者乙 (w
134:デフォルトの名無しさん
07/07/31 00:32:44
>>133
誤爆？
135:デフォルトの名無しさん
07/07/31 01:22:21
まともに(？）煽っていて誤爆に見えないが。
136:デフォルトの名無しさん
07/07/31 01:42:48
まともには見えないが。
137:デフォルトの名無しさん
07/07/31 07:11:23
それはあなたが無知だからです。
138:デフォルトの名無しさん
07/07/31 11:44:19
>>133 を読むのに知識が必要とは思えないが。
139:デフォルトの名無しさん
07/07/31 12:40:00
>>135を読み取る知識が無かったということです。
140:デフォルトの名無しさん
07/07/31 12:51:57
>>135 が言っているのはこういう事でしょ。
1. >>133 は煽っている
2. >>133 の煽りは煽りとしては特に不可解な所は無い
3. よって >>133 は誤爆ではない
俺は >>133 は煽りとして不可解だと感じたから、誤爆だろうと思った。
あまり知性も感じられない書き込みだし、よく誤爆する人間なんだろうと。
141:デフォルトの名無しさん
07/07/31 14:16:52
知力のない人間が知性のない人間に突っ込んだわけだ
142:デフォルトの名無しさん
07/07/31 14:43:20
単に136が135の「まとも」の使い方を誤読しただけ
143:デフォルトの名無しさん
07/07/31 20:38:33
>>142
>>140 が >>135 の意図した事と異なるのであれば、
>>135 がまともな日本語でないのが原因だよ。
まともに相手してあげた俺がバカだったみたいだね。
144:デフォルトの名無しさん
07/07/31 21:31:49
なぜか140の話を始める阿呆がいる
145:デフォルトの名無しさん
07/07/31 21:36:34
いちいち阿呆とか馬鹿とか付けないと文章書けない人か
146:デフォルトの名無しさん
07/07/31 22:05:24
C言語はハードに近い部分を記述することができますが
最近の言語では、それは無くなってきていますね。
良いことか分かりませんが。
147:デフォルトの名無しさん
07/07/31 22:20:59
>>131=>>134=>>136=>>138=>>140=>>143=>>145 自演乙
148:デフォルトの名無しさん
07/07/31 22:23:57
>>146
> 最近の言語では、それは無くなってきていますね。
FORTRAN の時代からハードに近い部分は高級言語では書けなかったけど？
149:デフォルトの名無しさん
07/07/31 22:26:56
>>147
自演つーか、明らかに全部俺だけど…
もしかして今まで気付いてなかったのか？
大丈夫？
150:デフォルトの名無しさん
07/07/31 22:44:19
>>146
148という訳で、むしろCのほうが異例とさえ言える。
151:デフォルトの名無しさん
07/07/31 22:49:24
>>147は自分が正しいと思ったら絶対曲げないタイプでしょ？
152:デフォルトの名無しさん
07/07/31 23:37:04
OS が書ける言語ならハードに近い部分も書けるんじゃないのかな。
Pascal, Oberon, Lisp, Smalltalk, C++, etc...
153:デフォルトの名無しさん
07/07/31 23:53:30
c言語+gcc拡張で書き直されたosのsetup codeの例
URLﾘﾝｸ(kerneltrap.org)
URLﾘﾝｸ(lkml.org)
それでもまだアセンブラ(*.S)な部分があるのがなんだかなぁだが。
154:デフォルトの名無しさん
07/08/01 00:06:47
個人的には、コンパイラに強く依存するくらいならアセンブラで書いた方が良いな
155:デフォルトの名無しさん
07/08/01 00:09:57
アセンブラはＣＰＵに強く依存しないか？
156:デフォルトの名無しさん
07/08/01 00:19:19
それがアセンブラで書くべき局面なら躊躇無くアセンブラで書くよ
157:デフォルトの名無しさん
07/08/01 00:42:40
移植性がなくても、可読性や保守性の点で高級言語を使う利点もあるでしょ。
158:デフォルトの名無しさん
07/08/01 07:06:38
コンサバじゃないGC
159:デフォルトの名無しさん
07/08/01 21:49:59
>>151
間違ってると言うなら、ソースつきで反論どうぞ。
バカ本はダメだよ。(w
>>152
Pascal と Lisp には標準ではハードを直接触る機能はないと思ったけど。
Oberon, Smalltalk は使ってことないからよくわからんが。
160:デフォルトの名無しさん
07/08/01 23:22:13
頭固い奴だな
OSのアセンブラコードを吐くプログラム書けばいいじゃん
161:デフォルトの名無しさん
07/08/01 23:27:30
それを実行時にやるというなら、生成したコードを実行するために、
任意のアドレスへジャンプもしくは関数呼出などができる機能を
持っている必要があるという制約が生じるね。
162:デフォルトの名無しさん
07/08/01 23:35:31
頭固い奴だな
実行ファイル吐く(略
163:デフォルトの名無しさん
07/08/01 23:42:03
ようするにブートストラップという概念を知らんのね。
164:デフォルトの名無しさん
07/08/01 23:48:23
Lisp も弄った事無いで話してそうだな
165:デフォルトの名無しさん
07/08/01 23:49:53
>>163
ブートキャンプしか知りません。
166:デフォルトの名無しさん
07/08/02 15:00:59
>>159
本云々じゃなくて、お前の人間性な
167:デフォルトの名無しさん
07/08/04 00:49:02
>>160
ＯＳのアセンブラコードってなんだ？
自分用語は、ご自身のブログだけにしといてくれ。
>>166
反論できないから、人格攻撃か。
わかりやすい奴だな。(w
168:デフォルトの名無しさん
07/08/04 01:00:32
>>147に対する「ソース付きの反論」って
どんなのを想定してたんだろう、この子。
169:デフォルトの名無しさん
07/08/04 01:43:29
恐らく本人も良く分かってないのではないかな
脊髄反射で何となく汚い言葉を並べているだけでしょう
だいぶ前から会話が成立していない様ですし
170:デフォルトの名無しさん
07/08/04 06:58:50
>>167
じゃあさ、お前1冊でも本書いてみろよ
俺様が添削してやるから
171:pp
07/08/04 22:15:25
>>168-169
反論できないから、人格攻撃か。
わかりやすい奴だな。(w
# 夜中まで乙。
>>170
指摘されたぐらいでそんなに熱くなるな。
172:デフォルトの名無しさん
07/08/04 22:25:25
以上、言い負けてから先が威勢の良い典型的な厨房でした。
173:デフォルトの名無しさん
07/08/04 22:32:12
簡単な技術の話も出来ないなら他所へ行ったら良いのにな。
それはさておき、C に機能を追加する話題ばかりだったけど、
C から取り除いた方が良いと思われる機能は無いのかな。
174:デフォルトの名無しさん
07/08/05 10:43:00
>>172-173
> 典型的な厨房でした。
反論できないから、人格攻撃か。
わかりやすい奴だな。
> 簡単な技術の話も出来ないなら他所へ行ったら良いのにな。
で、おまえ等 (一人かも知れんが) のレスのどこに技術の話があるんだ？
反論したければ、単に >>129 の解釈に対する反例をあげれば済む話なのに
できないからうだうだ言ってるんだろ？
175:デフォルトの名無しさん
07/08/05 11:17:42
そんな下らない事で息巻いてたのか…
176:デフォルトの名無しさん
07/08/05 11:26:58
>>174
>で、おまえ等 (一人かも知れんが) のレスのどこに技術の話があるんだ？
俺じゃなくてさ、>>159 の書いてる事が素人っぽかったからね。
「Oberon, Smalltalk は使ってことない」らしいけど、Pascal と Lisp も
殆ど知らないんだろうなと思って。
177:デフォルトの名無しさん
07/08/05 12:26:28
>>175
へ～、君はもっと凄いことについてレスしてるつもりだったんだ。
詳しく説明してくれるかな？
>>176
> Pascal と Lisp も殆ど知らないんだろうなと思って。
そう思うなら、どこか素人っぽいか指摘すればいいだけ。
指摘もできないから、「知らないんだろうな」とか言う技術的じゃ
ないことしか書けないんだろ？
# まさか、「OSのアセンブラコードを吐く」なんて言うわけわかめ
# のことを言ってた奴が絡んでるのかなぁ...。(w
178:デフォルトの名無しさん
07/08/05 12:54:10
この人、リアルでは孤独なんだろうな。。
179:デフォルトの名無しさん
07/08/05 12:57:02
おやまあ
180:デフォルトの名無しさん
07/08/05 12:59:30
シャープマンはそろそろおとなしくしてね
181:デフォルトの名無しさん
07/08/05 13:02:52
"ハードに近い"の定義がされてないのに何この荒れよう。
人によってリアルモードのことだったり割り込みのことだったりしそう。
#リンカスクリプトを言語に統合まだー?
182:デフォルトの名無しさん
07/08/05 13:08:05
自分でやれよｗｗｗｗｗｗｗｗｗ
183:160
07/08/05 13:15:35
>>177
「OSの」は余計って事か。ごめんね。
書いたときは>>152以前は読んでなかったから、OSでも書くつもりなのかと思ってたよ。
>>161には話通じてるみたいだし、スルーされたと思って放置してた。
どのみちファイルに出力できる言語なら何でもできるだろ、
って事を>>148みたいな人へ言いたかったんだけど。
184:デフォルトの名無しさん
07/08/05 13:24:18
ホントにどんな事にでも噛み付いてくる奴は居るもんだな
185:デフォルトの名無しさん
07/08/05 13:41:40
夏だからな
186:デフォルトの名無しさん
07/08/05 13:50:23
>>178-180, >>184-185
「技術的に指摘して」って言ったらこの様ですか...。
まあ、>>185 が言う通り 夏 なんだろうな。
>>181
> "ハードに近い"の定義がされてないのに何この荒れよう。
まあ、最低限として任意のメモリの読み書きができないとダメだろうな。
て言うか、リアルモードとか割り込みなんて事まで言い出すと特定プロセサ
シリーズ専用の言語になるから「標準」でと言うのはないだろうな。
>>183
単に茶化しただけだ、気にしないくれ。
そもそも、>>160 の書き込み自体洒落 (=原理的には可能だけど、実施が
大変面倒なので実際的じゃないという意味) だろ？
て言うか、このスレ自体がネタスレだし...。
> どのみちファイルに出力できる言語なら何でもできるだろ、
>>161 が指摘してる通りそのファイルを実行する手段が必要。
標準の言語仕様としてその機能を持ってる言語ってそんなに多くないよ。
187:デフォルトの名無しさん
07/08/05 14:00:54
>>186
餌欲しい？
188:デフォルトの名無しさん
07/08/05 14:09:42
>>186
各arch毎に言語拡張すれば良くね?
189:デフォルトの名無しさん
07/08/05 14:37:07
>>186
言語仕様に含まれてなくとも、大抵は処理系毎にFFIとかが整備されてるもんだよ。
C言語にしてもasmは標準ではないし、C言語で適当なバイト列を関数アドレスとして
キャストして実行できたりするのも処理系が「たまたま」許してるだけ。
そんな所を君がごちゃ混ぜに語っているのが、分かってないのでは
と言われる理由かと。
190:デフォルトの名無しさん
07/08/05 15:05:34
>186
>そもそも、>>160 の書き込み自体洒落 (=原理的には可能だけど、実施が
>大変面倒なので実際的じゃないという意味) だろ？
大変面倒というのは君の主観でしかないよね。
そういうのは一度作ってしまえばその環境で使いまわせるし、
やることも極めて単純な変換作業だよ。
エミュレータやコンパイラ作ったりする人なら普通に思いつく発想。
で、
>て言うか、このスレ自体がネタスレだし...。
このスレは仮にも「新C言語を作ろう」なんだから、その程度を、
大変面倒と言ってしまうレベルの人間の横槍は遠慮してもらいたい。
191:デフォルトの名無しさん
07/08/05 15:10:02
>>173
ないわけではないよ>>48-61。
>>188
似たようなこととして、DがCPU毎にインラインアセンブリを定めていたはず。
192:デフォルトの名無しさん
07/08/05 15:16:30
>>191
D言語のインラインアセンブラはx86しか(ry
gdcは他のarchの為にasm(gasの文字列);に対応してるけど。
193:>>187 かわいそう...
07/08/05 15:51:36
>>188
そう、実用的には処理系毎の定義と、何らかの言語拡張がなされているのが普通。
特に、ハード周りとかファイル関連はアーキテクチャやシステム毎の差異が大きいので
標準の言語仕様では定義してない方が多い。
Ｃ言語は、PDP + Unix と言うある意味特定環境用の言語として作られたから生い立ちと
して他の言語に比べてそこら辺の定義が比較的されていたんだ。
>>189 の言うキャストなんかも、アーキテクチャが決まっていたから許されていたが、
8086 + DOS みたいにメモリモデルによっては関数へのポインタとデータへのポインタで
ビット幅が違うなんて言う変態的なアーキテクチャだと破綻するので言語仕様からはず
されただけ。
>>189
そういう突込みを避けるために、わざわざ゛>>159 に「標準では」って
言う言葉を入れてあるんだが。
> そんな所を君がごちゃ混ぜに語っている
具体的に指摘よろしく。
>>190
まあ、ちょっと落ち着け。
そういう仕組みを作るのが面倒じゃなくて、単に「ハードに触る」だけで、ファイル作っ
てそれを実行して (必要に応じて結果を) 得るって言うことが面倒だ言ってるんだけど、
理解できてる？
194:デフォルトの名無しさん
07/08/05 15:55:05
もっと毒吐けよｗｗｗｗ
195:デフォルトの名無しさん
07/08/05 16:19:14
>>193
処理系毎じゃなくてarch毎に拡張の標準を決めるべきでね?
196:デフォルトの名無しさん
07/08/05 17:22:27
>>193
>理解できてる？
何を言ってるのかさっぱりわかりませんがその前に、
「君の主観でしかないよね」って言葉は理解してるのかな？
ともかく、何が面倒なのかを焦点に議論するのは無駄でしょう。
重要なのはどういった手法であれ、目的が達成できるかどうか。
よりベターな方法なんて後からいくらでも考えればいい。
>具体的に指摘よろしく。
自覚がないなら遠慮しておきます。
それこそ「面倒」なんで。
197:デフォルトの名無しさん
07/08/05 17:24:43
ANSI Common Lispという本の導入、クロージャを紹介する所でこんなのがある。
(defun addn (n) #'(lambda (x) (+ x n)))
「Cではaddnはどうなるだろう？ちょっとすぐには書けないだろう。
もっとも読者はこんなふうに思うかもしれない。大体こんなことをしたいなどと考え
たりするだろうか、と。しかし、そう考えたりしないのは、プログラミング言語が、それで
できないようなことは、やりたいと思わないように利用者を仕向けているからである。
プログラムを書く言語で考えなければならないのだから、それで書けないことをやり
たいとは考えにくい。私が初めてプログラムを書き始めたころ、それはBasicで書いて
いたのだが、再帰を使いたいなどとは考えなかった。そんなものがあることも知らな
かったのだ。私はBasicで考えていたのだ。
（中略）
(Lispを学習していく)努力の報酬として、上級のC++プログラマがBasicでの
プログラミングに感じるようなやりにくさを、C++に対して感じるようになるだろう。」
198:デフォルトの名無しさん
07/08/05 18:11:01
>>195
例えば、86系用だと io 命令を拡張の標準にするとか？
ちょっとおもしろいかもしれない。
>>196
> 何を言ってるのかさっぱりわかりませんが
ああ、理解できてないなら別にもういいよ。
別に君の意見に反対する気はないし、そういう人に何を言っても無駄だ
と言うことも知ってるから。
> 自覚がないなら遠慮しておきます。
> それこそ「面倒」なんで。
# 指摘できない言い訳を２行も書くのは面倒じゃないんだ...。(w
199:デフォルトの名無しさん
07/08/05 18:13:34
「俺はまともなんだが、どうにも馬鹿が多くて話が進まないなぁ」
と思ってるそこのキミ。それはつまりキミが馬鹿なんです。
200:デフォルトの名無しさん
07/08/05 18:17:02
>>198
> > 自覚がないなら遠慮しておきます。
> > それこそ「面倒」なんで。
> # 指摘できない言い訳を２行も書くのは面倒じゃないんだ...。(w
>>196のこの部分は、
「ああ、理解できてないなら別にもういいよ。
別に君の意見に反対する気はないし、そういう人に何を言っても無駄だ
と言うことも知ってるから。」
という意味のことを、それよりは少し短く言ってるだけだと思うよ。
201:デフォルトの名無しさん
07/08/05 18:17:51
その典型的な例がシャープ
202:デフォルトの名無しさん
07/08/05 18:28:03
できない言い訳に、他人の無能さを持ち出す人って饒舌だからね
203:デフォルトの名無しさん
07/08/05 19:21:10
>>200
はいはい、言い訳はもう結構です。
204:デフォルトの名無しさん
07/08/05 20:37:33
何を話してるのかはさっぱりわからんが、誰が痛いかはよくわかる。
205:デフォルトの名無しさん
07/08/05 20:48:27
>>204
だな。主観で話してるお前が一番痛い。
206:デフォルトの名無しさん
07/08/05 20:57:42
いや、そいつは二番目だ。
一番は俺だからな。
207:デフォルトの名無しさん
07/08/05 21:10:31
いやいや俺だ
208:デフォルトの名無しさん
07/08/19 18:24:44
>>207
そうだな
209:デフォルトの名無しさん
07/08/19 19:23:20
ここは誰が一番痛いか競うスレですかそうですか。
210:デフォルトの名無しさん
07/08/19 19:32:53
そうだよ
君もエントリーするかい
211:209
07/08/19 19:43:53
よろしくお願いします。
一応下記の至らぬスレの主です。
おら！Nをオトメに見つけて++Nを得るムを作らん？！
ｽﾚﾘﾝｸ(tech板)l50
212:デフォルトの名無しさん
07/08/19 20:05:21
ﾜﾛﾀｗ
213:デフォルトの名無しさん
07/08/19 20:10:54
>>211
糞スレ立てるな
214:209
07/08/19 20:21:58
>>212-213
何も成果物を作れないかもしれませんが、
気長に見てやってください。
スレ違い及び売名行為失礼しました。
逝ってきます。
215:デフォルトの名無しさん
07/08/20 18:32:13
酷いスレだな
216:デフォルトの名無しさん
07/08/25 12:46:57
・変数スコープをなくし、全てグローバルとする。
スコープとはいわば開発者に脳内スタックの確保を一段
強要する機能であり、開発の邪魔である。
変数は全て設計者が関数一覧表とそれに付随する変数一覧表にて管理する。
ローカルだからと適当に変数を作り捨てるようなことをするから
ゴミ変数が増え、バグとなる。
・ポインタの廃止。ポインタは労多くして功少なしの典型機能。
・キーワードを全て大文字化する。小文字は小さく目に悪い。
217:デフォルトの名無しさん
07/08/25 12:48:11
全部ボツ
218:デフォルトの名無しさん
07/08/25 15:13:41
>>216
COBOL でも弄ってろ無能。
219:デフォルトの名無しさん
07/08/26 17:08:28
>>216
要約するとガベージコレクションを付けろってことだな
220:デフォルトの名無しさん
07/08/27 02:45:42
>>216
異論の余地がないほど同意
ｃなんかよりBASICのほうが1億光年優れてるよな
221:デフォルトの名無しさん
07/08/27 18:09:12
>>220
>異論の余地がないほど同意
本人だからか？
222:デフォルトの名無しさん
07/09/06 17:28:11
小学校でローマ字を習うまでは大文字しか読めなかったから
BASICはできてもCはできなかった
223:デフォルトの名無しさん
07/09/06 17:39:30
自分は小学校でローマ字を習う以前に公文で英語やってたから小文字も読めた
でもプログラミングはやってなかった
つかPC自体が珍しい時代だった
224:デフォルトの名無しさん
07/09/20 10:00:55
C言語にGCとデリゲートとコルーチンっていうか、ファイバーっていうんだっけ？中断できるやつ。があれば割とすごいことになりそうな感じ。
あ、あとエクスポート可能なテンプレートかジェネリックスもね。
はっきり言ってクラスはなくても何とかなる。thisコールが結構べんりっちゃーべんりだけど。
225:デフォルトの名無しさん
07/09/20 10:25:33
>>216
ローカル変数は無いと再帰処理が出来なくて悲惨だぞ。その再帰も深くなるとばぐっちゃうけどね。
ポインタはローレベル叩くとき必要だけど、普段はあんまり恩恵ないな。イテレータにしても実用上は問題ないかもね。
キーワードは、色つきエディタ使えば解決。え！？もってないの？？？VCが無料だって言うのに。
226:デフォルトの名無しさん
07/09/20 11:41:51
>>216
int i; とかをグローバルにする知り合いがいたんだが、
void g(void) {
for (i = 0; i < Y; i++) 何かする;
}
void f(void) {
for (i = 0; i < X; i++) g();
}
みたいなことやってバグってハマってたな
227:デフォルトの名無しさん
07/09/20 13:09:15
>>216
異論の余地がないほど同意
ｃなんかよりBASICのほうが1億光年優れてるよな
228:デフォルトの名無しさん
07/09/20 13:22:00
同意するなら異論に反論してからにすれば
229:デフォルトの名無しさん
07/09/20 14:06:23
B A S I C
230:デフォルトの名無しさん
07/09/20 15:20:03
俺の専ブラが>>216をグロ判定したんだけど
231:デフォルトの名無しさん
07/09/20 22:53:59
暇があったら俺のじゃんけんプログラム倒してくれ。
＊N８８互換BASICを使っている人・・・・
ｽﾚﾘﾝｸ(tech板)l50 の 24 参照
232:デフォルトの名無しさん
07/09/21 18:11:30
タートルグラフィックを準標準に入れてくれないかねぇ。
任意で実装って感じでさ。
あれこそ、コンピュータグラフィックスだよ。
233:デフォルトの名無しさん
07/09/23 21:37:44
ただのタートルグラフィックじゃだめだな。
3次元に拡張して、タートルがグリグリ動く奴でヨロ。
234:デフォルトの名無しさん
07/12/24 02:30:36
よし、ゲーム向け言語
#include<game.h>
int main()
{
CreateGame(CG_SHOOTING)
return 0;
}
これでシューティングゲームができる言語を作ってみそ
235:デフォルトの名無しさん
08/01/27 17:24:03
無理だろうけど
#iconfile iconfilename
と書くと作成される実行ファイルにiconfilenameで指定したアイコンファイルが関連付けられる機能
236:デフォルトの名無しさん
08/01/28 18:42:16
break+数字で複数のループを抜ける。
while(1) { /* ループ１ */
while(1) { /* ループ２ */
break2;
}
}
237:デフォルトの名無しさん
08/01/28 18:45:05
gotoでいいじゃん。
238:デフォルトの名無しさん
08/01/28 19:09:53
>>236
ＵＷＳＣで使えるけど便利だよね。
あと、forループで規定回数で抜けるのと途中で抜けるのとをスイッチするオプションがあれば・・・
あ、普通にフラグとスイッチ使えばいっか。
239:デフォルトの名無しさん
08/01/28 21:36:08
>>236
数字はやだ、ラベルにしてくれ。
Loop:
while(1) { /* ループ１ */
while(1) { /* ループ２ */
break Loop;
}
}
240:デフォルトの名無しさん
08/01/28 21:37:48
それ gotoって言うんだよ
241:デフォルトの名無しさん
08/01/28 22:57:11
そんなこと言い出したから、while だって、if + goto なわけだが。
242:デフォルトの名無しさん
08/01/29 17:27:37
>>239
まんまD言語な件。いや、Javaでもあったかな。
243:デフォルトの名無しさん
08/02/17 19:38:46
int main(int argc, char *argv[]) {
switch(VersionComparison(argv[1], argv[2])) {
case 1:
printf("%sの方がバージョンが新しいです｡\n", argv[1]);
break;
case 2:
printf("%sの方がバージョンが新しいです｡\n", argv[2]);
break;
default:
printf("%s, %sのいずれもバージョン情報を含んでおりません｡\n", argv[1], argv[2]);
break;
}
return 0;
}
244:デフォルトの名無しさん
08/04/09 20:32:13
あげもかねてＣ言語ネタ投稿 実際にはコンパイルできないソースファイル
#include "Windows.h"
extern "C" __declspec (dllexport) int isosmode(void);
int _tmain() {
switch(isosmode()) {
csae 0:
MessageBox(NULL, "現在のモードは、アドバンスモードです｡", "モード判定", MB_ICONINFORMATION);
break;
case 1:
MessageBox(NULL, "現在のモードは、セーフモードです｡", "モード判定", MB_ICONINFORMATION);
break;
case 2:
MessageBox(NULL, "現在のモードは、デバックモードです｡", "モード判定", MB_ICONINFORMATION);
break;
default:
MessageBox(NULL, "CHKMODE.DLLは存在しません｡", "ファイルの欠落によるエラー", MB_STOP);
break;
}
MessageBox(NULL, "なんちゃって、isosmode()もCHKMODE.DLLも実際には存在しません｡", "注意", MB_ICONINFORMATION);
return 0;
}
245:デフォルトの名無しさん
08/04/09 20:36:34
printf("私は弱者を愛し、守っていきます。");
紳士言語
246:デフォルトの名無しさん
08/04/09 21:05:21
>>245
ここではスレ違いの内容だよ
そういう書き込みは“適当に作ったC言語の関数を貼っていくスレ”の方で。
247:デフォルトの名無しさん
08/06/19 18:33:34
>>225
関数の引数を増やしてそれをローカル変数代りにすればOK。
216が関数の引数もなくせ、と言っているなら知らんが...。
248:デフォルトの名無しさん
08/06/19 21:27:03
>>241
if + goto + goto だと思うが。
249:デフォルトの名無しさん
08/06/19 21:52:07
>>248
大抵のコンパイラは
goto L1
L2:
...
if(...) goto L2
に展開するから、goto + if + goto が正しいな。
って言うか、５ヵ月近く前のレスにレスするほどの内容か？
250:>>249
08/06/19 21:53:13
ラベル付け忘れた... orz
goto L1
L2:
...
L1:
if(...) goto L2
251:デフォルトの名無しさん
08/06/20 22:40:22
>>249
どうしてもレスつけたかったんです、勘弁してください。
252:デフォルトの名無しさん
08/07/24 01:36:50
>>1
やる気があるなら、予約語を全部排除して、
全部自前で定義できるようにしてくれ。
そういう仕様なら乗ってやる。
253:デフォルトの名無しさん
09/01/29 00:57:56
>>252
予約語を自前で定義して何の得があるんだよｗｗｗｗｗ
254:デフォルトの名無しさん
09/01/29 01:56:38
>>252
PL/I思い出した
255:デフォルトの名無しさん
09/01/30 21:43:19
>>252
俺様専用の俺言語が定義できる。
256:デフォルトの名無しさん
09/01/30 23:44:01
schemeでいいよ
257:デフォルトの名無しさん
09/01/30 23:47:48
D言語でいいよ
258:デフォルトの名無しさん
09/02/01 05:23:02
boolは欲しいな。あれ、追加されてたんだっけか。
あと、複素数型とか、HLSLみたいにベクトル扱いやすくする機能も欲しい。
数値計算に特化すれば需要あるんじゃね？
259:デフォルトの名無しさん
09/02/01 05:48:44
そんなのよりステータスレジスタを抽象化して見れるようにしてほしい
わざわざアセンブラで書く手間を減らすために
260:デフォルトの名無しさん
09/02/01 07:48:44
>258
_Bool と _Complex は C99 で追加されている。
261:デフォルトの名無しさん
09/02/01 11:35:51
>>259 無いプロセッサはどうすんだよw
262:デフォルトの名無しさん
09/02/03 22:31:14
URLﾘﾝｸ(d.hatena.ne.jp)
こんなのもあるんだな
1つ目のリンクは切れてるみたいだけど
263:デフォルトの名無しさん
09/02/03 22:47:48
Ｃ++のように無秩序に機能を増やすのではなく、
Cの良さを守りつつ、Cと同じ次元でより使いやすいCを作りたい。
名づけてC+
・オブジェクト指向（クラスその他）は導入せず。
・当然ガベコレなんてついてない。
・標準関数ライブラリは古くなってしまったので全面改訂。
・文字列を扱うstring型の追加。文字列の扱いに関しては全面強化。
・配列・ポインタは当然維持。ただし分かりにくい構文は改訂する。
（配列は int[] array; のように宣言を行うようにする。ポインタも long* x, y; だと*は型名に付いているとする。）
・malloc関数, free関数のキーワード昇格。
・namespace導入。
・ヘッダファイルは不要に。関数プロトタイプ宣言不要。
264:デフォルトの名無しさん
09/02/03 23:27:09
> 名づけてC+
+ は単項演算子じゃないから文法エラーとか
265:デフォルトの名無しさん
09/02/04 02:01:50
互換性は捨てるのね…。
266:デフォルトの名無しさん
09/02/04 12:20:40
>>263
>・当然ガベコレなんてついてない。
けど
>・文字列を扱うstring型の追加。
なのか。遅そうだな。
267:デフォルトの名無しさん
09/02/04 21:58:46
>263
なんかCycloneのサブセットな気が。
268:デフォルトの名無しさん
09/02/15 10:30:52
cycloneってこれ？
URLﾘﾝｸ(cyclone.thelanguage.org)
269:デフォルトの名無しさん
09/02/15 13:36:48
GCと境界チェックさえつけてくれればおｋ
270:デフォルトの名無しさん
09/03/03 01:54:47
>>263 に型周りの強化(強力な型推論、総称型)が入れば十分かなと思う。
271:デフォルトの名無しさん
09/03/03 09:57:34
いろんな言語混在できる言語で。
272:デフォルトの名無しさん
09/03/03 20:25:41
いろいろつけるから、ごちゃごちゃして、使いづらくバグの温床になる。
いっそのこと、ばっさり機能を削ぎ落とすのがよろしい。でも低レベルな操作は行いたい。
というわけで、新仕様を次のようにする。
--
void main()
{
asm文の繰り返しのみ;
}
--
以上。変数も条件文もgoto文も制御構造も何も無いので、覚えやすい。
273:デフォルトの名無しさん
09/03/03 22:51:49
null終端文字列じゃなくて、文字数で管理するようにしようぜ
いや現状のCでも文字数で管理は可能だけど、標準ライブラリがnull終端前提じゃん
274:>>249
09/03/03 23:16:41
標準ライブラリ以前に、文字列定数が文字数で管理するような形になら
ないから、現状のＣでそういうことやるのは激しく困難だと思う。
275:デフォルトの名無しさん
09/03/04 11:56:02
>>273
Pascalでよくね？
276:デフォルトの名無しさん
09/03/04 12:04:03
>>272
各種ジャンプがあるだろ。
277:デフォルトの名無しさん
09/03/04 21:56:44
perlのコードが混ざっててもエラーにならないように作ってくれ
278:デフォルトの名無しさん
09/03/05 00:24:05
>>273
pascal キーワードを導入すればいい。
string cstr = "This is a C string." ; // ヌル終端の標準C文字列型
pascal string pastr = P"This is a Pascal string."; // 先頭がバイト数のPascal文字列型
279:デフォルトの名無しさん
09/03/05 01:22:45
いっそのことコンパイラ作りに特化した仕様にしちゃえYO
その後は各自自分仕様の言語を作ると
280:デフォルトの名無しさん
09/03/05 01:41:25
これからの時代は予約語オーバーロードですよ
281:デフォルトの名無しさん
09/03/05 19:05:08
>>280
それは凶悪すぎるだろうｗｗ
282:デフォルトの名無しさん
09/03/05 20:34:09
C#からもってこれそうなのある？
283:デフォルトの名無しさん
09/03/06 01:17:52
予約語オーバーロード
284:デフォルトの名無しさん
09/03/06 04:22:43
組み込み型に対する演算子オーバーロード
285:デフォルトの名無しさん
09/03/09 11:45:37
匿名メソッド (関数ポインタ)
286:デフォルトの名無しさん
09/03/10 23:55:37
型水路
287:デフォルトの名無しさん
09/03/11 14:03:58
CMカット
288:デフォルトの名無しさん
09/03/11 16:23:26
既存のCのソースを利用したりCへ必ず変換できる言語にしたい。
文法はCと非互換でよい。
現状のマクロをなんとかしたい。
短い記述で濃い内容を書きたい。
289:デフォルトの名無しさん
09/03/11 16:25:42
スクリプトっぽく書けるようにしたい。
グローバルに
puts("hoge");
って書けば
int main(){
puts("hoge");
}
と同じ意味にしたい。
290:デフォルトの名無しさん
09/03/11 16:28:34
do-whileって判定を後ろに書くのが人気無いよね。
前に書けるようにするか。
他言語ではbefore until after untilの構文どうなってるかな。
291:デフォルトの名無しさん
09/03/11 16:31:05
for(int i=0;i<n;++i)
は定型化してるから、もっと単純化できる。
いい構文ある？
292:デフォルトの名無しさん
09/03/11 16:34:28
JavaScriptっぽく;(セミコロン)の省略できたっていいよな。
Pythonっぽくインデントでブロック作れてもいいよな。
いずれも問題点や文句言う奴がいるがうまく丸く収まんないかな。
293:デフォルトの名無しさん
09/03/11 16:41:24
>>285
qsort,signalなんかで使えたらうれしいよね。
294:デフォルトの名無しさん
09/03/11 17:38:55
GCとかの実行時のサポートに頼らない範囲で、出来る限り高水準な言語を作るというのが面白そう
強力な型システムやメタプログラミング能力を用意して、少なくとも無名関数くらいはGCのある言語に近い気楽さで書けるように
一番の問題はたぶんメモリ管理だけど、線形型を使ってなんとかできないだろうか
295:デフォルトの名無しさん
09/03/14 01:08:44
>>283
予約語オーバーライドができる言語なら知ってるんだが
296:デフォルトの名無しさん
09/03/14 04:46:04
#define ですね、わかります
297:デフォルトの名無しさん
09/03/14 04:49:47
#define内で#defineや#ifとかが使えればいいのに
298:デフォルトの名無しさん
09/04/16 00:38:30
そうかなあ
299:デフォルトの名無しさん
09/05/31 20:27:15
いろんなとこから仕様はいただいて、テキトーに短くしたらこうなった
c/Hello{
static v/main(str[] args) >> pub{
printw("Hello,World!");
}
}
300:デフォルトの名無しさん
09/06/04 18:49:17
いじくるつくーるなら for(0,i<n) { (命令文) }; という構文がある。
たぶんＣ言語では無理。
301:デフォルトの名無しさん
09/06/04 21:57:33
D言語ならforeach(i;0..n)でおk
302:デフォルトの名無しさん
09/06/04 22:00:26
指定したハンドルのレジストリキーに関する情報をlpc構造体に渡すRegQueryInfoKey
LPC lpc;
char n[100];
RegQueryInfoKey(HKEY_CLASSES_ROOT, lpc);
wsprintf(n, "HKEY_CLASSES_ROOTの１つ下には%i個のサブキーがあります。", lpc.Subkeys);
MessageBox(NULL, n, "関数RegQueryInfoKey", MB_OK);
303:デフォルトの名無しさん
09/06/18 22:48:47
というかOSがかける程度に強力であり、
かつ高尚で可読性に優れたものが書けるならいうことなしだ
そうするとおもいっきりModula-2になるわけだが。
だからあのｷﾓｲbegin～end構文を｛～｝の構文にして、
コンパイラの実装がしやすく、またプログラミング初心者も覚えやすいような
簡潔な文法があればいい。
あとこれは個人的意見だけど、できるだけソースコードは短く書けたほうがいい。
じぶんのキーボードの打ち方が間違ってるのだろうけど、腱鞘炎になりかけたことがあるから。
304:303
09/06/19 18:52:46
>>291
ちなみにこれについてちょいと思い付いたので書いておく。
型宣言した時点でその型の初期値に初期化されるとして…
for((int i)++ < 5){
//....
}
305:デフォルトの名無しさん
09/06/19 22:13:54
Inferno って OS で使われてる limboo はどう?
306:デフォルトの名無しさん
09/06/20 21:50:33
>>305
後でちょいと調べてみる。
ついでに>>236>>239について思いついたので書いておく。
nest(1)://"nest"とは入れ子という意味。
while(..){
nest(2):
while(..){
break(1);//nest(1)のループを抜ける
}
}
307:303 ◆pFphp4Ej4w
09/06/24 19:28:40
>>278
これについては、
C言語文字列
nullStr
Pascal文字列
byteStr
とすればいい。
この用途のみでPascalキーワードが存在するのは許せない。
あと、306は私だ。
308:303 ◆pFphp4Ej4w
09/06/29 08:17:32
取りあえず考えてみた。
１.変数宣言
変数宣言はC言語のそれとは全く逆。
例)x int;
これは英語の文法にあわせて読みやすくしたため。
２.ポインタ
ポインタは次のように宣言。
例)p: point(int);
or
p: int:;
続きは家に帰ってから。
309:303 ◆pFphp4Ej4w
09/06/30 08:05:49
３.代入演算子
代入演算子には
:=
を使用する。
例)
a int:=5;
３.比較演算子
比較演算子には
=
を使用する。
例)
if(x=0){
...
}
310:デフォルトの名無しさん
09/06/30 23:13:46
C言語への不満ってそういうところじゃねーと思うが。
例えば実行時のコンテキストとソースコード上のlexicalなコンテキストが同一で
あるところとかそういうモデルな部分に革新が必要なんじゃないか？
読みやすさも大事だと思うがそういうのはおれスクリプト言語でやってればよし。
311:303 ◆pFphp4Ej4w
09/07/01 07:45:40
>>310
なるほどねぇ…
確かにそうかもしれない。
その抜本的な改革についてちょっと考えてみるよ。
それと、ポインタ型の宣言について、
p: point(int);
よりも
p point(int);
こっちの方がいいかな？
ただこうするとpがポインタ型と言うことが分かりにくくなってミスが増えるかも。
312:303 ◆pFphp4Ej4w
09/07/01 08:18:08
あと一つ質問。
匿名メソッドは必要かね？と言うかデリゲートは必要か？
313:デフォルトの名無しさん
09/07/01 13:13:15
今からなら新C言語はC言語をベースにするよりD言語からクラス抜いたものをベースにした方が良いと思われ。それにビットフィールドとかC99とかgccの拡張部分とか足してきゃいいよ。
ポインタの実体化はDelphiのがいい。
関数の戻り値の型の書き方はC++0xやEMACScript4で提案されているような後置も特殊化用引数(テンプレート/ジェネリックパラメタ)を戻り値の型より前に持ってくるという点で一理あるが、読みやすさという点では従来の方が高い。まぁ難しい所だね。
314:303 ◆pFphp4Ej4w
09/07/01 16:16:39
>>313
わし的には、
ベースはC言語
クラス、インタフェース、また必要であればデリゲートなどの匿名メソッドの導入(個人的にアレは嫌いだ)
強力な型推論の導入
メモリ管理にはガベージコレクタは用いず、malloc/new･free/delete演算子を使用
ポインタは廃止しない(廃止すると複雑なデータ構造がつくれなくなる。)
文法の抜本的な変更
nullchar/bytechar型の導入
を考えていたのだが…(ついでに名前はシーキューブ。C3またはCqbと書く)
D言語かぁ…
それもありだね。
そしたら名前はD++かな？
315:デフォルトの名無しさん
09/07/01 16:48:50
>>314
D言語は
-class、interface、delegate全てある
-変数初期化時・関数の戻り値の型推論がある
-ポインタも当然ある。
-invariant(char)* (C言語の文字列)とinvariant(char)[] (Pascalの文字列)がある
まぁ違う所は
-メモリ管理はGC基本でマニュアル管理はカスタムアロケータがある
-文法はC言語由来が多い。
って所か。
316:303 ◆pFphp4Ej4w
09/07/01 18:28:42
>>315
となるとD言語からGCを取り外しただけの言語になるわな。
なんか「これがほしい！」って言うのはないの？
317:デフォルトの名無しさん
09/07/01 18:52:26
D言語は細かい所がなおざりだから、改善すべき点は文法も含め多いと思うよ。
318:303 ◆pFphp4Ej4w
09/07/04 20:53:44
そういえば、マクロのこと書きそびれてた。
マクロは#～で定義され複数行をサポートする。
例)
#hoge
...
#hoge end
319:デフォルトの名無しさん
09/07/12 23:56:48
303 はもういないの？
320:303 ◆pFphp4Ej4w
09/07/13 18:50:34
ごめん。この間まで期末テストで今は風邪でダウン中。
321:303 ◆pFphp4Ej4w
09/07/13 21:45:52
追記:
明日から4日ぐらいはずっと学校が休みなのでこのスレに張り付いていられると思います。
322:デフォルトの名無しさん
09/07/14 00:21:22
とりあえず現状どうなってんのか、まとめみたいなのがほしいかな
323:デフォルトの名無しさん
09/07/14 05:29:59
構文変えるなら利点と欠点まとめてほしい。
忘れないで欲しいのが、パーサによる解析しやすさ、IDEによる入力支援の効きやすさ、他人による読みやすさ、データの流れの追いやすさ、書きやすさ。
324:デフォルトの名無しさん
09/07/14 12:29:10
>パーサによる解析しやすさ
こんなこと考えるから C の宣言は判り難くなったんだ。
325:303 ◆pFphp4Ej4w
09/07/14 16:17:01
>>322
了解です。今から書きます。
>>323
>>303でも書いたように
> コンパイラの実装がしやすい
言語にしたいと思ってはいるのでできれば解析はしやすくしたいと思っています。
しかし>>324さんが述べているように構文の読みやすさ、書きやすさなんかを
犠牲にするのはちょっとカンベン･･･
というわけでもしかしたらその点は犠牲になる可能性があります。
とりあえず今のところ(私の中で)決まっている言語仕様:
1.変数宣言
変数は次のようにして宣言される
x int;
利点:英語に従った文法なので初心者が読みやすくなる。
欠点:Cに慣れた人は確実に間違えてエラーを多発させる要因になる。
2.クラス・関数の定義
クラス・関数は次のようにして定義
c/hoge{
void hogehoge(){
...
}
}
クラスに内包されない関数も定義可能。
void hoge(){
...
}
int hogehoge(){
...
}
続く
326:303 ◆pFphp4Ej4w
09/07/14 17:06:23
続き
利点:c/～とやると若干短くなる。
欠点:c/～じゃ最初見た人は何かと思うかもしれない。
また実行時に実行される関数は
int main(){
...
returrn 0;
}
でOK。
3.演算子について
代入演算子
:=
比較演算子
=
!=
<
>
<=
>=
とする。(代入演算子にほんとうは<=を使いたいのだがこれじゃ間違える人が続出すると思うので今のところはこれで。今後変更の可能性大。)
利点:"==”は比較演算子ではないのでで初心者のミスが減る(一人よがりかなぁ？)
欠点:確実に間違えられる。
今日のところはここまで。
327:デフォルトの名無しさん
09/07/14 18:58:54
int foo[][] vs. int[][] fooな論争があるが、foo int[][] (foo is int of array of array)にしちゃうのかぁ。パーサに先読みが必要になるのでかなり速度が低下するのと、IDEの補完的にマイナス…いやこれは既に定義された名前を避けるという意味では問題ないか。
クラス定義は、"c/"を識別子にするってことかな。そうだとすると変数でcを宣言した場合に厄介なことになる。識別子にしないとなるとlexerで分離できないので速度が低下する。
演算子についてはDelphi的なので言うことは無いかな。
328:デフォルトの名無しさん
09/07/14 19:08:55
それと、識別子に使える記号の数は少ないので、アルファベット+記号を識別子にすること自体は賛成かな。
329:303 ◆pFphp4Ej4w
09/07/14 19:41:05
追記:
これはやだ･これを追加しろ･この構文はやだ等ご意見があればご自由に。
と書こうと思っていたら>>327さんがもう書いていらっしゃいました。素早い…
それはさておき、ご意見ありがとうございます。
パーサの速度にしたがってコンパイル速度も落ちるので、これは重大な問題です。しかもこれを解消するには構文を捨てないといけないという…
これについては今後なるべく早く議論して解決策を決定すべきでしょう。(この過疎スレで人が集まるかどうか…)
解決策の一つとしてはこの言語のみに特化したパーサを開発することですが、これじゃ焼け石に水です。
どうしましょうかねぇ…
330:デフォルトの名無しさん
09/07/14 19:45:55
幾つか意見を言わせて貰うね。
----
"c/" は、俺は否定的。
"c" + "/" として扱っても、"c/" としてまとめて扱っても、どちらにせよ 『 b := c/a; 』 が書きにくくなる。
トップレベルに書いた "c/" のみを特別扱いすれば問題ないとは思うけど、CP が悪いわな。
そんなに 100 も 200 もクラス定義するわけじゃないんだから、得られるものは少ないと思うよ。
----
変数宣言と関数宣言の型指定が正反対なのが気になるところ。
変数にあわせるならば 『 hoge() void { ～ } 』 になるんじゃないかな。
C に慣れたひとも、VB or Pascal に慣れた人も、どちらも間違えると思うよ。
どちらかに統一すべきだと思う。
----
代入演算子、"<-" を使ってみたらどうかな。打ちにくいけど。
----
比較演算子で気になるのは、= と != の文字数が違うところかな。
細かいことだけど。
331:303 ◆pFphp4Ej4w
09/07/14 19:50:44
追記:
>>329というわけでこの過疎スレに議論のために人を呼び込まねばなりません。ですから、これからはage進行で行きましょう。
ってなわけでage!
332:303 ◆pFphp4Ej4w
09/07/14 19:57:26
>>330
すびません、リロードし忘れてましたorz
いま外出中で携帯から書き込んでるので家に帰りつくまでお待ちください。
333:デフォルトの名無しさん
09/07/14 20:16:45
>代入演算子、"<-"
a<-5とかそれなりに使う気がするので止めてほしい。
:=も条件演算子との兼ね合いで(識別子として扱えば問題は無いものの)読みにくくなりそう。
334:デフォルトの名無しさん
09/07/14 20:18:42
個人的な案。
c -> newC
= :=
== = or !!=
!= !=
< < or !>=
<= <= or !>
> > or !<=
>= >= or !<
要は、!に否定と言う意味を持たせるなら演算子そのものも否定できたらどうかな、と。
# !の多重を認め出すと、!!!!!!!!!!=なんて書けてしまうのは実は問題かもしれないw
335:334
09/07/14 20:21:18
失礼。醜かったので書き直し。
--
c → newC
= → :=
== → = or !!=
!= → !=
< → < or !>=
<= → <= or !>
> → > or !<=
>= → >= or !<
336:デフォルトの名無しさん
09/07/14 20:22:21
>>334
D言語には!>=とか普通にあるが<とは意味が違う(浮動小数点のNAN的な意味で)。
337:336
09/07/14 20:25:50
これな。
URLﾘﾝｸ(www.digitalmars.com)
<>とか<>=とか!<>=とかもある
338:303 ◆pFphp4Ej4w
09/07/14 20:46:16
今家に帰り着きました。
･･･つついてみれば意外と人がいるもんですね。
>>330
については、そこまで頭回ってなかった私の問題です。申し訳ない。
というわけで改訂版。
2.クラス・関数の定義
クラス・関数は次のようにして定義
c/hoge{
hogehoge void(){
...
}
}
クラスに内包されない関数も定義可能。
hoge void(){
...
}
hogehoge int(){
...
}
あと"c/"について。
そうですか･･･。やっぱりclass{...}にしたほうがいいですかね？
ここは議論の余地があるようです。
>>334さんのは全面採用したいですね･･･
まぁ"!"は2文字以下でという限定をつければいいと思うので。
339:デフォルトの名無しさん
09/07/14 20:51:10
>>338
hoge int() { ... }
って表記はどうなのかな。
変数宣言と合わせると LALR なら問題ないだろうけど、LL なら 3 くらいは欲しいよね。
340:303 ◆pFphp4Ej4w
09/07/14 21:42:41
>>339
なんだか考えるべきことが大量に増えてきましたね…
私はそろそろ寝たいと思います。(風邪も治したいので。)では、おやすみなさい。
341:デフォルトの名無しさん
09/07/14 22:02:02
>>1
C++の何が不満なのかまず説明してくれ
それが説明出来ないなら議論する価値もない
342:デフォルトの名無しさん
09/07/14 22:50:14
a = a + b を a += b と書けるように、
別の書き方をしたら記述量が減るなら意味があるけど、
>>334 みたいなのにどういう利点があるのかいまいちわからない。
343:デフォルトの名無しさん
09/07/14 22:54:15
まあでも代入と比較が:=と=なのは趣味の問題、別に構わないと思う。
Cっぽくない構文の言語なら珍しくはない。
344:デフォルトの名無しさん
09/07/15 01:43:31
ちょっと視野が狭すぎやしないか？
その程度の違いならC言語でいいじゃんと思ってしまう。
参考までに303 ◆pFphp4Ej4wが使えるプログラミング言語は何だい？
345:デフォルトの名無しさん
09/07/15 03:30:46
GNOME 用の C 言語拡張みたい
Valaについて語りませんか
ｽﾚﾘﾝｸ(linux板)
346:303 ◆pFphp4Ej4w
09/07/15 09:11:34
>>344
私が使えるのですか？
ObjectPascal
Java
C言語
C++
D言語は現在勉強中。
347:デフォルトの名無しさん
09/07/15 21:09:58
>>341
たしかにそこは聞きたいな。C++でなくてもいいけど。
今あるCの後継的な雰囲気の言語のどこがまずいと考えていて、
どう直そうとしているのか。それによって何が良くなるのか。
誰（言語ユーザ、コンパイラ制作者、ライブラリ制作者、IDE、etc）が得するのかなどなど……。
348:デフォルトの名無しさん
09/07/15 21:26:49
代入演算子変えるなら、もはや「新C言語」じゃないのでは？
349:303 ◆pFphp4Ej4w
09/07/15 22:01:26
>>348
それいっちゃオシマイです…
それと、>>305についていまさらながら調べてみました。
LimbooというのはC言語の作者が設計したPascalライクなC言語のようです。
やはりC言語をつくった人にも思うとこがあったのですかねぇ…
350:デフォルトの名無しさん
09/07/15 22:25:00
演算子なんてjavascript程度が用意してるので十分だと思うんだよね。
そんなに既存のcやその他追随してる言語に不都合な点があるのかな。
351:デフォルトの名無しさん
09/07/15 22:28:42
>>350
Perlまで増やせとは言わんが、ECMAScript 3程度じゃ全然足りん。
352:デフォルトの名無しさん
09/07/15 22:33:24
演算子いらね, 結局 (+ x y) の 2 引数関数じゃん
353:デフォルトの名無しさん
09/07/15 22:36:33
もっと三項演算子を増やせとな?
354:デフォルトの名無しさん
09/07/15 22:39:24
宣言以外の文を無くして全部式にしようぜ
355:303 ◆pFphp4Ej4w
09/07/15 23:18:57
>>354
それじゃ関数型言語そっくりに…
どうもわたしは規制に巻き込まれたようです。
何もしてないんだけどな…
こういうもんなんですかね？
356:デフォルトの名無しさん
09/07/15 23:25:40
そういうもんです。
ぶっちゃけ、既存の言語を超えようとしたり、改善しようとしたりするのが間違ってると思う。
自分が作りたいものを作りたいように作ればいいんじゃないかな。俺はそれで満足する。
357:デフォルトの名無しさん
09/07/15 23:35:13
>>356
目的が自分が満足するためならそれでいいのだろうけど。
358:303 ◆pFphp4Ej4w
09/07/15 23:56:47
>>356
確かに。それの見本がC++ですね。
359:デフォルトの名無しさん
09/07/16 06:25:30
>>349
LimbooじゃなくてLimboだよ。w
Limbo は並行計算が目玉と思われ。Erlangよりずっと分かりやすい。
C言語の悪評極まる宣言についてはリッチー先生さすがに反省したようで
Pascal風に直してあるね。
Limboに先行してAlefという言語もある。
360:303 ◆pFphp4Ej4w
09/07/16 10:25:19
>>359
すいません。おっちょこちょいなもんで…
361:303 ◆pFphp4Ej4w
09/07/17 22:43:22
なんか規制解除されてるかわかんないので携帯から書き込みます。
４.基本構文
４.１for構文
for構文とは指定した回数だけその命令を繰り返す構文である。
for構文は次のように定義する。
(とりあえず3回繰り返す場合。)
for((i int)++ < 3){
...
}
362:303 ◆pFphp4Ej4w
09/07/17 22:47:18
>>361
ま、間違えた…
４じゃなくて３だった…
あと、言いそびれてましたが変数は定義したときにその変数の初期値に初期化されます。
363:デフォルトの名無しさん
09/07/17 23:02:05
指定した回数繰り返すと言うのなら、<演算子を使う必要はないのでは？
<が出て来るということは、今のCのforみたいにwhileのような自由な条件指定を許すように思える。
それなのに、361の文章では、「指定した回数繰り返す」と言い切っている点が気になる。
単に、今のCのforみたいに、主に指定回数の繰り返しに使われるというのなら理解できるけど。
364:363
09/07/17 23:05:40
例えば、BasicのFor i = 0 To 2やRubyの3.timesなんかが
比較演算子を使わずに繰り返しの構文を実現している。
（もちろん、どっちもwhileが別にある）
365:デフォルトの名無しさん
09/07/17 23:11:08
MATLABの構文もそんな感じだったな
for i = 1 : 1 :10
1ずつ増やしながら1～10まで繰り返すみたいな
366:デフォルトの名無しさん
09/07/17 23:13:17
fortranっぽい配列使えるようにしてくれ
367:303 ◆pFphp4Ej4w
09/07/17 23:31:12
>>363
ぬわぁ…
すみません。
毎回毎回勉強になるなぁ…
とりあえずここでは「主に指定した回数だけ繰り返される」とします。
これを踏まえて一つ質問を。
ある命令を指定した回数のみ実行するのみの構文は必要でしょうか？
368:デフォルトの名無しさん
09/07/18 00:11:15
どういう方向性か知らないけど、foreachがあればforなんてなくてもなんとかなるよ。Pythonのforがそう。
#リストlsの各要素を順に出力
ls = ["hoge", "foo", "bar"]
for x in ls:
print x
#0から2までを順に出力
for x in xrange(3):
print x
でもまあ、こんなところCのままでいいじゃないと思うけどね。
配列（のようなもの）の各要素に～するって系統の関数を充実させれば、for/foreachの出番なんてぐっと少なくなるし。
369:デフォルトの名無しさん
09/07/18 00:11:39
逆に何でそれがいるのかが聞きたい
370:デフォルトの名無しさん
09/07/18 02:15:20
>>346
やはり似たような言語ばっかりだね。
limboがでてたけど、そんな感じの根本的に違う思想の
言語を一度勉強した方が参考になると思うよ。
特に関数プログラミング系は必須といっていいと思う。
listかschemeは当然だし、また実行効率の良さはMLとその派生も勉強になるものが多い。
C言語の拡張でいうとcycloneとかも見てみるといい。
あれはCの実行効率の良さを維持しつつ型安全性を組み入れてる。
そういうのみるとはっきり言って俺for文とかどうでもいい話に思えるよ。
バカにするつもりはないけどもう少し見聞を広げるべき。
371:デフォルトの名無しさん
09/07/18 02:37:16
・C/C++
・Pascal
・Smalltalk
・Self
・Io
・Lisp, Scheme
・Haskell
・Prolog
・Erlang
・ConcurrentClean
・GHC/KL1
・BrainF*ck, Unlambda
・SKI combinator
これくらい見聞きすれば新しい世界が開けるよ
372:デフォルトの名無しさん
09/07/18 02:50:21
>>371
その中で一つ選ぶならやっぱり Lisp だね。
常用する気にはなれないけど、学ぶ事は多かった。
373:デフォルトの名無しさん
09/07/18 02:56:43
やっぱり並列プログラミングが安全で簡潔に書ける言語がほしいね。
単純なスレッドむき出しじゃないやつで。
374:デフォルトの名無しさん
09/07/18 03:00:23
>>371
D(メタプログラミング・関数乗っ取り対抗策など)とかC#(LINQ)とかCω(スレッド周り)とかECMAScript3/ECMAScript4(プロトタイプ思考)とかJava(命名規則など)とかも必要。
誰か言語の良い所・悪い所をまとめてほしいかも。んで良いとこ取りすればおk。
375:デフォルトの名無しさん
09/07/18 03:05:48
つーかC言語の後継であるなら、OSが書ける、デバドラが書ける、
とかそういうのが目的の言語であってほしい。
なんでもあり言語はPL/Iみたくなってうまくいかないでしょ。
376:デフォルトの名無しさん
09/07/18 03:12:26
>>374
自分は、客観的な各言語の評価よりも、
303自身の主観でのCとその後に続く言語（>>346の中ではC++/Java/Dの）の評価を聞きたいな。
377:デフォルトの名無しさん
09/07/18 05:17:21
>>375
PL/Iが普及しなかった理由はそういうことでは無いけど(MulticsはPL/Iで書かれている)、整理はされてて欲しいね。
378:303 ◆pFphp4Ej4w
09/07/18 07:28:01
>>376
そうですねぇ…
Java
一番最初に使ったオブジェクト指向の言語です。
はっきり言ってしまうとかなりわかりやすく、簡単･便利で初心者に最適な言語だったと思います。
ただ、プログラマのもつ能力に足かせをはかせてるような感じがします。あと、私は結構パフォーマンスを気にするたちなので(ただの貧乏性)VMを使うせいで速度が遅い･メモリを触れないJavaはなんだか性にあいません。
C++
ポインタを理解するまでかなり時間を食いました。(C言語を始める前だった)
Javaだとそこら辺は巧妙にかくされてます。
ただ、C言語のようにプログラマのもつ能力を最大限生かせる点と速度がかなり速い点については最高だと思います。(これでコンパイルが速ければ…)
D言語
まだまだ学んでる途中なので細かいことは言えませんが、C++とJavaを足して2で割ったような言語です。
GCがついている以外に不満な点は特にありません。
つまりまとめちゃうと取りあえず私は、今あるC言語系の構文にこれといった不満をもっていません。
はっきりいうとこれまでだしてきた変数宣言や様々な構文は私が本心から考えているものではありません。ただ初心者に優しいであろうと思うもののみをあげているだけです。
ぶっちゃけJavaみたいに初心者に優しくて、Dみたくコンパイルが速くて、C++みたく柔軟な使い方ができて実行速度が速い言語なら私はそれでいいのです。
379:デフォルトの名無しさん
09/07/18 10:05:40
とりあえず、「新C言語」という名前をやめてほしい。
こういう名前をつければ、スレッドの客寄せにはいいだろうが、
構想はまったくCと違う方向に進んでいる。
世の中で、C言語の改良版が欲しい人たちは、
Cとまったく違う変な構文なんて望んでいないはずだ。
まったく別の名前でまったく別の理念でやってくれ。
380:デフォルトの名無しさん
09/07/18 10:16:35
Ｇ言語
381:デフォルトの名無しさん
09/07/18 10:51:15
新C言語としてOCamlを開発すればよい
382:デフォルトの名無しさん
09/07/18 12:23:13
>>380
自慰言語ですね。わかります
383:デフォルトの名無しさん
09/07/18 12:42:19
コンパイル速度まで評価対象になるのなら、実装方法もコミで考えてかないと。
単にこんな機能が欲しい！だけじゃダメだろ。
384:デフォルトの名無しさん
09/07/18 12:47:25
つーか、Cでのちょっとした不満とか良くないところの改善っていう目的を忘れたらあかん。
385:デフォルトの名無しさん
09/07/18 18:45:24
コンパイラ屋さんの俺が来ましたよ。
専門は最適化なのでそっちしか興味ないんだけど、簡単なCへのトランスレータくらいだったら作ってみようかな～
386:303 ◆pFphp4Ej4w
09/07/18 20:27:00
>>384
ってなわけでじゃんじゃかC言語の悪いところを書き出してってください
>>385
ぜひともお願いします(まだ言語仕様さえも決まってませんが･･･)
387:デフォルトの名無しさん
09/07/18 20:41:33
とりあえず文法を FIX しよう。話はそれからだ。
388:デフォルトの名無しさん
09/07/18 20:43:12
あと、名称も FIX しないとね。
389:デフォルトの名無しさん
09/07/18 21:00:07
はじめてきたんだけど
ちょっとここまでの進捗を3行でまとめて
390:デフォルトの名無しさん
09/07/18 21:02:45
す
す
んでない
391:385
09/07/18 21:17:44
>>386
とりあえずただＣをパースしてＣを吐くだけのやつを明日作ってみようか。でそのパーサなり何なりをいじって文法を修正していくと。
言語ががらっと変わるなら仕様を先に練る必要があるけど
392:デフォルトの名無しさん
09/07/18 21:24:31
進んでないのか
また来るね
ヘッダファイルを編集するだけの簡単なお仕事です
393:303 ◆pFphp4Ej4w
09/07/18 23:43:39
>>391
どうもありがとうございます。よろしくお願いします。
明日は模試があるので顔をだせないかもしれませんが…
394:デフォルトの名無しさん
09/07/19 00:45:11
Java に乗っけたいね。JSR223 対応させて。
けど 303 にその気が無いようで残念。
395:デフォルトの名無しさん
09/07/19 00:47:10
Javaにのせたい気持ちがわからない
396:デフォルトの名無しさん
09/07/19 01:23:40
わかんない？
そいつは残念だ。
397:デフォルトの名無しさん
09/07/19 01:26:42
それはC言語の役割ではない
398:デフォルトの名無しさん
09/07/19 01:49:26
むしろJavaScriptで作ってブラウザ上に、というほうがまだ分かる。
それはともかく、やりたい人間が自分で作ればいいじゃないか、JRubyのように。
399:394
09/07/19 02:03:01
いや、作る気が無いわけじゃないんだけど、
ポインタをサポートするなら JVM の上にさらに独自の VM 乗せることになって
そこまですることになるなら俺の能力を超えるなぁ、って考えていたところ。
Java じゃなくて、JavaScript でも似たようなことが起きるはず。
400:デフォルトの名無しさん
09/07/19 03:21:48
Cくらい軽量で低水準な関数型言語が使いたいなー
401:デフォルトの名無しさん
09/07/19 04:25:40
それなら、とりあえず全変数は読み取り専用、書き換え可能な変数はmutable修飾子を付けるという方向にしよう。
402:デフォルトの名無しさん
09/07/19 10:51:16
>>400
runtimeなしで関数型言語作るのはかなり難しいだろう。
純粋関数型言語ならある程度可能だが。
403:303 ◆pFphp4Ej4w
09/07/19 16:24:49
どうも。やっと模試が終わりました。死んだ…
>>401
なるほど。
それはprivate,public修飾子を残した上で付け加えるということでよいでしょうか？
この他「これがいやだからこうしてほしい」等要望をなんなりと。
それから、取りあえず「新C言語」の名前を決めたいのですが、なんかありませんか？(時期尚早と言うなら取り下げます。)
404:デフォルトの名無しさん
09/07/19 16:51:31
「Ｃ」という文字を入れるか入れないか、それが問題だ。
入れなくてもいいなら、「 Zig 」とかをさっきふと思いついたり。
あと、こうしたいああしたいっていう要望聞くのは良いんだけど、
上手く舵取りして取捨選択しないと、汚い言語ができるよ。
ちゃんと設計理念ってものを自分なりに考えていかなきゃねー
405:401
09/07/19 16:52:12
>>403
いや、構文的にはCのconst/volatileの位置を考えている。
406:デフォルトの名無しさん
09/07/19 16:56:05
C言語のautoやregisterはキーワードとして再利用しても大丈夫だろう
407:デフォルトの名無しさん
09/07/19 17:00:55
const int x = 123;
mutable int x = 123;
みたいな感じか。
408:デフォルトの名無しさん
09/07/19 17:02:24
ここでふと聞いてみたい。
俺言語を作ろうと思ったことがある奴、実際に作ったことがある奴、どのくらいいるんだ？
ノ
409:デフォルトの名無しさん
09/07/19 17:03:42
>>406
とりあえずautoはC++0x同様の型推論で決定だな。
410:デフォルトの名無しさん
09/07/19 17:03:57
言語ってか、ＡＤＶツクールみたいなの作ろうとしたら、
どんどん言語っぽくなっていった。
411:デフォルトの名無しさん
09/07/19 17:19:11
Cの実行モデル的にmutablは無駄にコードを長くするだけだと思うな…
412:デフォルトの名無しさん
09/07/19 17:21:31
mutableね タイポ
413:385
09/07/19 18:36:40
そんじゃ夜から何か作り始めるよ。
実装言語はバリアントがあるOCamlとかの方が楽だけど誰でも改造しやすいようにJavaとかにしたほうがいいのかな？
>>403
とりあえず名前だけでも決めてくれると嬉しい。
414:デフォルトの名無しさん
09/07/19 18:46:18
>>413
いや、是非385自身が一番使いたい言語で実装してほしい。そっちに俺は1票を投じるぞ。
415:デフォルトの名無しさん
09/07/19 18:49:21
新C言語だから・・・
SINCL: SINCL Is New C Language
416:デフォルトの名無しさん
09/07/19 18:58:36
QINC Is Not C-language.
417:303 ◆pFphp4Ej4w
09/07/19 19:47:12
>>405
なるほど。いいですね。
>>413
よろしくお願いします。私はそっち方面は全くわからないのですごく助かります。
>>415
>>416
GNUですかww
他に名前の候補ありませんか？
418:デフォルトの名無しさん
09/07/19 19:52:56
開発コードネームはLouiseがいいです
419:デフォルトの名無しさん
09/07/19 20:00:19
>>418
して、その心は？
420:デフォルトの名無しさん
09/07/19 20:02:35
だって可愛いらしくて素敵な名前じゃないですか
421:デフォルトの名無しさん
09/07/19 20:10:30
Lowrise?
422:デフォルトの名無しさん
09/07/19 20:19:00
省略記法をたくさん作ってくれ
void引数の関数の()を省略できるとか
423:デフォルトの名無しさん
09/07/19 20:43:27
>>422
関数ポインタとの区別をどうする？
という問題は置いといて、それは何が嬉しくなるの？
424:デフォルトの名無しさん
09/07/19 20:54:06
省略が多いほうがタイプ楽でええやん
425:デフォルトの名無しさん
09/07/19 20:54:25
構文糖は、劇的にコード量が変わったり新たな意味が付与されるものでない限り、
あると逆に邪魔になるものが多いよ。
Java の拡張 for とか Haskell の do とかなら存在意義があるけど、
単に省略できるようにしたいだけなら、
引数 0 個の関数呼び出しでは、() を書いてはいけない
という仕様にしたほうが、まだ収まりが良いよね。
426:385
09/07/19 21:39:24
帰宅したので今から作ります。
>>414 に甘えてOCamlで実装することにしました。
名前が決まっていないみたいだから、とりあえず一番早かったSINCLで書いとく。
427:デフォルトの名無しさん
09/07/19 22:22:33
新Cを作るのなら
以下2点が希望かな
関数のファーストクラス化
プリプロセッサの廃止とその代替機能の追加
プラスアルファするとしたら
名前空間またはモジュール機構
並列処理の考慮(メモリモデル等)
機能追加は最小限でいい
比較的小さなのがCの良いところ
428:385
09/07/19 23:05:03
Cは識別子の管理が激しくめんどい。
誰かに改良案考えてほしいな～。
429:デフォルトの名無しさん
09/07/19 23:08:27
識別子の管理ってどこが面倒なんだっけか。
430:385
09/07/19 23:14:49
識別子の意味が文脈で変わるんだよ。
URLﾘﾝｸ(www.syuhitu.org)
がとても分かりやすい。
とりあえずここのとおりに実装してる。
431:デフォルトの名無しさん
09/07/19 23:26:23
typedef 周りか。解決策といったら……
その１：typedef なんて無くせばいいよ！
その２：型名は大文字から始まることにすればいいよ！
その３：AST 作ってから識別子を解析すればいいよ！
くらいじゃないのかな。
文法に注意すれば、それが型名なのか変数名なのかが一意に決まるから、
とりあえず構文木作っちゃえば良いんじゃないかと思う。
432:303 ◆pFphp4Ej4w
09/07/19 23:47:33
>>426
頑張ってください！
>>431
typedefの消滅はちょっと…(私的には。)
だから現実的にはその2かその3が解決策だと思います。
その他ご希望をなんなりと。新C言語の名称も引き続き受け付けます。
433:デフォルトの名無しさん
09/07/19 23:47:43
識別子が型名か変数名か分からないとASTが作れないのが問題なんじゃないのか？
434:385
09/07/19 23:56:13
typedefの問題は構文を修正する事で解決できると思う。
typedefがstaticやexternなどと文法規則が同じだというがややこしい原因のようだ。
435:デフォルトの名無しさん
09/07/19 23:56:36
>>430を斜め読みもしていなくて済まないけど、
typedefの宣言そのものが面倒のか、それともtypedefされた名前を使うのが面倒なのかどっち？
前者なら、typedefを別文法で実現すればいいはず（C#/C++0xのusingなど）。
後者は、Cっぽい文法を維持する限りどうしようもないよなあ。typedef禁止にしても
C++/Java/C#みたいにclass量産できれば同じような状況になるだろうし。