07/05/31 07:09:44
内容的には>>360>>364で既出ですが、URLﾘﾝｸ(herbsutter.spaces.live.com)より
New Language Features Voted Into (Draft) C++09
・Template aliases (aka typedef templates, generalized typedefs) [N2258]
・Variadic templates (aka "type varargs" for templates) [N2242; see N2087 for a more readable description and rationale]
・Unicode characters and strings [N2249]
・Rvalue references [N1952]
373:デフォルトの名無しさん
07/05/31 16:54:12
へー、N2249入るかもしれないんだ。
とうとうC++の世界でも明示的にユニコード文字列が扱えるようになるのか。
374:デフォルトの名無しさん
07/05/31 17:46:31
すると現実の実装では、事実上wchar_tがchar16_tまたはchar32_tと同じ大きさを持つ型
（当然整数型とwchar_tのようにtypedefではない）という扱いになるんだろうなと思う。
375:デフォルトの名無しさん
07/05/31 19:57:46
これですな
URLﾘﾝｸ(www.open-std.org)
そのうちstd::u16stringとかstd::u32stringとかもできるんだろか
376:373
07/06/01 00:57:02
入るかもしれないじゃないや。もう最新のドラフトに入ってるわ。
377:デフォルトの名無しさん
07/06/01 01:12:11
L"文字列" はどういう扱いになるん？
378:デフォルトの名無しさん
07/06/01 01:36:05
こんな感じかな？
wchar_t wc = L'あ'; // wcの値は実装依存 (今と同じ)
char16_t c16 = u'あ'; // c16は0x3042
char32_t c32 = U'あ'; // c32は0x00003042
379:デフォルトの名無しさん
07/06/01 01:39:40
UTF-8 は使えないの？
UTF-16BE と UTF-16LE （32も）の選択は環境依存？
380:デフォルトの名無しさん
07/06/01 01:40:47
あ、BE と LE はこのレベルでは関係ないか？
実用上面倒くさい事になりそうな気はするが。
381:デフォルトの名無しさん
07/06/01 01:44:07
UTF-8の型も用意するか、逆にUTF-32だけにするか
してほしい気もする
382:デフォルトの名無しさん
07/06/01 08:22:04
>>379
UTF-8は、
・ソースコードで使って、処理系が変換。例えばU'A'などを。(規格外)
・今後Unicode系mbsライブラリが充実させる。
って感じなんじゃないの?
383:デフォルトの名無しさん
07/06/01 08:22:49
>>376
もう規格の外に出ることはないでしょ。修正が入るだけで。
384:デフォルトの名無しさん
07/06/01 08:35:43
下地になったCのn1040には、utf-8はchar型を使ってどうのこうのって
書いてあるけど、charはビット数を保証してないよなあ
385:デフォルトの名無しさん
07/06/01 09:07:21
uint8_tと読み直せばいいんじゃない。
386:デフォルトの名無しさん
07/06/01 09:09:30
uint8_t って optional だったよね。
387:デフォルトの名無しさん
07/06/01 13:30:21
何年か経ったらwchar_tはいらない子扱いされてそうだ
388:デフォルトの名無しさん
07/06/01 15:19:52
tcharでいいじゃん
389:デフォルトの名無しさん
07/06/01 16:02:57
>>387
Unicode依存コードじゃなければ、wchar_t推奨でしょ。
>>384
char8_tのドラフトを書けw
390:デフォルトの名無しさん
07/06/01 16:43:08
>>386
つuint_least8_t
ちなみにchar16/32_tはそれぞれuint_least16/32_tと同じ大きさと規定される>>375
391:デフォルトの名無しさん
07/06/01 17:00:04
どうせウニコードなんか窓しか使わないのにイラネ
392:デフォルトの名無しさん
07/06/01 17:05:18
>>389
何年か経ってもUnicodeでないOSが残ってるかどうかｗ
393:デフォルトの名無しさん
07/06/01 17:14:12
LinuxもUTF-8なご時世になんて寝言を……
394:デフォルトの名無しさん
07/06/01 17:43:00
ふつーにEUC
395:デフォルトの名無しさん
07/06/01 18:46:06
Unicode関連のロケールが標準に入ると考えていいんだろうか・・
396:デフォルトの名無しさん
07/06/01 20:20:04
CHAR_BIT >= 8 だから、UTF-8 は char を使ったんで別にいいんでない？
397:デフォルトの名無しさん
07/06/01 20:53:50
8は保証されてるの？
398:デフォルトの名無しさん
07/06/01 21:14:54
下限が 8 なのは保証されている。
別に 9 だろうが 16 だろうが問題ないが、7 とかはない。
399:デフォルトの名無しさん
07/06/02 11:33:29
世の中のプログラマのほとんどが
>どうせウニコードなんか窓しか使わないのにイラネ
と思っていたはずなのに
>LinuxもUTF-8なご時世になんて寝言を……
になってしまったのはいつから？なぜ？
400:デフォルトの名無しさん
07/06/02 11:43:17
>>399
いつからかは知らんが、そうでもせんとまともな国際化対応できんだろうが。
401:デフォルトの名無しさん
07/06/02 11:44:01
そんなこと思ってもいませんでしたよ。
今も昔もUnicode onlyは早計すぎると思っているだけ。
なんだかんだ言ってもUnicode周辺には、
"Technical Notes", "Technical Reports"その他に、
ノウハウがたまってきているので、強力にサポートすべき。
wchar_tの実装をUnicode onlyにするなんてのには大反対。
n2249はGJ。
402:デフォルトの名無しさん
07/06/02 11:55:15
じゃぁ、wchar_t はTRON用ということでおｋ？
403:デフォルトの名無しさん
07/06/02 12:29:48
TRONはwwchar_tです。
404:デフォルトの名無しさん
07/06/02 13:10:56
でも、Windows は UTF-16 なんだよな？
405:デフォルトの名無しさん
07/06/02 13:31:23
>>404
Windows のは WCHAR であってその実装は wchar_t とは限らず unsigned short int の場合なんかもある。
406:デフォルトの名無しさん
07/06/02 13:41:47
どちらにしろ UTF-16 だろ？
407:デフォルトの名無しさん
07/06/02 15:39:01
つWM_UNICHAR
URLﾘﾝｸ(msdn2.microsoft.com)
408:デフォルトの名無しさん
07/06/02 18:51:20
char(16|32)_t用の関連関数のドラフトはc++0xに間に合うのかねえ。
is系とかprintfとかfacetとか、結構ありそうだが。
409:デフォルトの名無しさん
07/06/02 19:15:39
C95みたいに後から追補出せばいいよ
410:デフォルトの名無しさん
07/06/02 19:44:42
streamやfacetsは対応しないみたい
URLﾘﾝｸ(www2.open-std.org)
あとUTF-8の案もあった
今のところWDには含められていないけど
URLﾘﾝｸ(www2.open-std.org)
プリフィックスは E で、1バイト8ビット以上を保証すると
411:デフォルトの名無しさん
07/06/02 21:41:23
>streams of non-char types have not attracted wide usage, so it is not clear
>that there is a real need for
う～ん…8bit圏の人にとっちゃそうかもしれんけどさ。
412:デフォルトの名無しさん
07/06/02 22:39:06
まあその辺はゆっくりやって、後から補完でいいんじゃないの?
Primitive typeとして導入されたわけだから、
いろいろ実装してみるための最低限のことは決まるわけだからさ。
typedefやマクロに比べて出きることが多すぎるから、慎重になるんでしょ。
413:デフォルトの名無しさん
07/06/02 22:59:52
Windows が UTF-16 だし、
デフォで UTF-16 が扱えるなら
そういう意味であちらさんにも価値はあるように思うんだけどな。
414:デフォルトの名無しさん
07/06/02 23:14:12
WCHARあるからねー
415:デフォルトの名無しさん
07/06/03 00:28:53
>>413
意味が分からない。
どれに対するレス?
416:デフォルトの名無しさん
07/06/03 00:29:10
Windowsなんかうんこ
417:デフォルトの名無しさん
07/06/03 00:29:51
>>415
>>411
418:デフォルトの名無しさん
07/06/03 00:35:57
char16_tやchar32_tのストリームを実装するとしたら
現状のワイド文字ストリームのようにマルチバイトに／へ変換するようなもんだと思ったんだが
419:デフォルトの名無しさん
07/06/03 00:35:59
それはWindowsにはニュートラルな話。
420:デフォルトの名無しさん
07/06/03 00:37:38
Windowsとか持ち出してるのはただの馬鹿だろ
421:デフォルトの名無しさん
07/06/03 00:46:50
>>418
wifstream, wcin辺りができたばかりだし、
char16_tなら、ほとんどの処理系は(sizeof(wchar_t)>2だろうから )codecvtでなんとかなるし、
char16ifstreamとかchar16cinとか乱発する前に、ちょっと考えてみるだけでしょ。
急いで、うんこライブラリを標準に入れるわけにいかないし。
422:デフォルトの名無しさん
07/06/03 00:56:23
GCC だと wchar_t は 4 だったな。
423:デフォルトの名無しさん
07/06/03 01:00:45
>>422
現在ではプラットフォーム依存。たとえば Cygwin の wchar_t は2バイト。
あと、-fshort-wchar なんてオプションもあるので、gccだからという判定は危険。
424:デフォルトの名無しさん
07/06/03 01:27:10
char16_t, char32_tの入った処理系では、
typedef char16_t wchar_t か、typedef char32_t wchar_t で、
wchar_tなライブラリも使えるし、char*_tなライブラリも構築していけるし、
とりえあえずは問題ないんじゃない?
>>423
utf-32が扱える処理系では、
wchar_tが2 byteだと規格違反だけどね。
>Type wchar_t is a distinct type whose values can represent distinct codes for all members
>of the largest extended character set specified among the supported locales (22.1.1).
425:デフォルトの名無しさん
07/06/03 01:32:30
なるほど。その環境で扱える最大の文字セットも格納できる事が必要なんだ。
426:デフォルトの名無しさん
07/06/03 02:03:02
wchar_tがUnicodeじゃない処理系ってあるのかな？
427:デフォルトの名無しさん
07/06/03 02:10:30
>>426
*BSDやSolarisのi18nフレームワークがそうなんじゃないの?
428:デフォルトの名無しさん
07/06/03 04:26:58
GCC 4.3にC++0xの実験的サポート
URLﾘﾝｸ(gcc.gnu.org)
429:デフォルトの名無しさん
07/06/03 04:55:14
>>428
ﾜｸﾜｸﾃｶﾃｶしつつDLしてregexを見てみた。
@todo Implement this function.
@todo Document this function.
だらけだった。
430:デフォルトの名無しさん
07/06/03 05:36:10
w
431:デフォルトの名無しさん
07/06/04 22:53:08
MSも試験実装すればいいのに。
Cの_s系関数はフライングで取り入れたんだから。
432:デフォルトの名無しさん
07/06/05 01:37:14
C#.NET以外は捨てなんだろう
C++/CLIは後方互換性だけなんだろうし。
433:デフォルトの名無しさん
07/06/05 22:01:36
久しぶりにスレ伸びたな～
434:デフォルトの名無しさん
07/06/05 23:26:19
まあ全部俺の一人芝居なんだけどな
435:デフォルトの名無しさん
07/06/06 01:57:38
同感
436:デフォルトの名無しさん
07/06/06 10:51:13
全部俺の独り芝居だったら同感って思う必要も無かったかな、とちょっと反省してみた。
437:デフォルトの名無しさん
07/06/06 12:41:13
それがまさに独り芝居というものでは？
438:デフォルトの名無しさん
07/06/06 13:20:54
自問自答++
439:デフォルトの名無しさん
07/06/06 14:47:48
そうか、僕はここにいてもいいんだ！
440:デフォルトの名無しさん
07/06/06 16:22:24
おめでとう
441:デフォルトの名無しさん
07/06/06 16:54:37
>>431-432
まあでもC++0xに全く無関心でない様子は伺える
URLﾘﾝｸ(blogs.msdn.com)
442:デフォルトの名無しさん
07/06/06 17:40:42
そりゃSC22/WG21の中の人たちがやっているからなあ。
VC++はC++/CLIオンリーじゃないし。
443:デフォルトの名無しさん
07/06/06 17:56:40
struct S {
int m;
};
sizeof(S::m)
これが規格外だったなんて知らなかった。
そういえばこれは合法になるのかな？
template < typename T >
class Foo
{
friend T ;
}
444:デフォルトの名無しさん
07/06/06 18:38:36
>>443
nondirivableかなんかで話題にあがったが、確か違法だったと思う
445:デフォルトの名無しさん
07/06/06 18:48:08
いや、C++0xではどうなるかという話なんだけど。
446:デフォルトの名無しさん
07/06/06 22:03:04
friend のはこれ？ (PDF)
URLﾘﾝｸ(www.open-std.org)
447:デフォルトの名無しさん
07/06/07 03:54:58
443の上は通らないけど下が普通に通る…
マジ意味不明
しかもなまじ役に立ちそうなのが一層もどかしさを増幅させる
448:デフォルトの名無しさん
07/06/07 05:25:03
sizeof(S().m)みたいに一時インスタンス化すればおｋ？
449:デフォルトの名無しさん
07/06/08 12:09:52
OKでしょ。
450:デフォルトの名無しさん
07/06/17 22:03:19
ところで、wchar_tとい不細工なネーミングは、
どうにかならんのかね。
short charとか、long charとかの方が自然だ
ろうし、文法上追加の余地はあるだろうに。
451:デフォルトの名無しさん
07/06/17 22:07:28
いっそUnicode str;を入れようぜ
452:デフォルトの名無しさん
07/06/17 22:57:31
>>450
少なくとも極自然なネーミングなんだがね。
これが極自然なネーミングだとお前が思えないなら
それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。
453:デフォルトの名無しさん
07/06/17 22:58:22
>>451
そんな既存のソースコードと衝突しそうな新しい予約語は却下
454:デフォルトの名無しさん
07/06/17 23:00:08
じゃ、_Unicode str;
えーい、いっそのことソースコードもUTF8強制して
文字 str = L"こんちには世界";
って書けるようにしようぜ？
455:デフォルトの名無しさん
07/06/17 23:23:48
まあでも始めからCにワイド文字型が組込型として存在したら、
単にwcharという名前になっていたとは思う
456:デフォルトの名無しさん
07/06/17 23:30:08
>>455
俺はむしろいっそのこと、int_t, double_t, char_t てなネーミングで
統一されてたほうがよかったんじゃねぇかとすら思うけどなぁ。
457:デフォルトの名無しさん
07/06/17 23:34:21
ワイドな文字ってよく考えると意味不明だよね
458:デフォルトの名無しさん
07/06/17 23:37:11
仮にUnicode型があったとして、
UTF-16かUTF-32かはたまたUTF-8かなんてことが処理系定義になりそうだｗ
459:デフォルトの名無しさん
07/06/17 23:39:23
もうUTF8って名前に決めちゃえばいいよ
460:デフォルトの名無しさん
07/06/18 08:27:41
ちょっと上の話題ぐらい読もうや。
461:デフォルトの名無しさん
07/06/18 08:36:17
>>458
UTF-8はmbs、つまりchar[]だろ。
462:デフォルトの名無しさん
07/06/18 22:47:59
>>452
確かに、2Byte=WORDという意味でword char
をwcharとするなら、別に構わないが、wchat_tと
書くと、いかにも規格外で後からつけました感が
あって、気に入らんのだがねぇ。それより、
shortやlongといった元からあり、且つwordの様に
変数のサイズを2Byteとか具体的に意識させない型の方が、
自然な感じがするんだけどねぇ。
463:デフォルトの名無しさん
07/06/18 22:50:57
名前の衝突を避けるにはダサネーミングはある程度しかたない
_Boolとかunorderd_mapとかダサすぎるし
464:デフォルトの名無しさん
07/06/18 23:10:05
ライブラリならダサネーミングも仕方ないが、予約語としてはちょっと頂けないってことじゃね？
基本的には同感。（今さらしょうがないけど）
465:デフォルトの名無しさん
07/06/18 23:10:16
virtual void hogehoge() = 0
なんて文法を導入しちゃう言語に対していまさらだな・・・
466:デフォルトの名無しさん
07/06/18 23:25:01
>>462
wchar_tのwは、wideでは？
467:デフォルトの名無しさん
07/06/18 23:47:46
>>450のshort charとか、long charとかで思い出したけど、
昔、整数型のshort (int) - int - long (int)からの連想で、
浮動小数点数型も、short float - float - long floatにすれば良かったのにと考えたことがあった
468:デフォルトの名無しさん
07/06/19 00:32:15
そうすると、long floatの省略が不可能になる罠。
まあ、long doubleは今でも省略不可だけどサ。
469:デフォルトの名無しさん
07/06/19 01:35:30
>>464
C++では予約語だが、Cではそうではない。
470:デフォルトの名無しさん
07/06/19 01:41:38
_Bool は仕方がないとは思うが失笑したな。
471:デフォルトの名無しさん
07/06/19 02:37:05
wordが2バイト圏の人か
俺の国では2バイトはhalf wordなんだな
472:デフォルトの名無しさん
07/06/19 02:40:36
MASM 使ってたら word = 2 バイトで使ってしまうな。
科学計算やってると word = 8 バイト（double）なことも多いんだがな。
473:デフォルトの名無しさん
07/06/19 04:43:21
>>462
本当にモロ、
>それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。
で、ﾜﾛｽｗｗｗ
474:デフォルトの名無しさん
07/06/19 20:23:00
>>462
そうだね勉強するよ。
そういえば、1語長2語長なんて言葉もあったね。(敢えて言うが、
勿論1語長が1Byteなどと思っているわけではない。)
MSのAPIの影響(DWORDとかQWORDとか)でWORDを2byteと仮定して書いてしまった。
あと、wchar_tはwide charなのにword charと書いたのは、素で間違えた。
それはそうと、C++0xが実現するとObjective-C++やC++/CLIはどうなるんだ
ろうねぇ。三者三様の完全別言語路線に進むのか？0xに合わせてそれぞれ拡張
するのはは厳しい気がするが。実装的に。
475:474
07/06/19 20:25:01
訂正
× >>464
○ >>473
自分を指して何やってんだが…。
476:474
07/06/19 20:29:41
また間違えた...。欝だ。
× >>462
○ >>473
病院でも行ってくる。
477:デフォルトの名無しさん
07/06/19 20:30:02
もともとobj-cはC++とは全然別物だろうに
478:デフォルトの名無しさん
07/06/19 22:43:01
>>474
なんかまだ少し勘違いしてそうだから、念のために書いておくと
必ずしも sizeof(wchar_t)==2 じゃないぞ。 sizeof(wchar_t)==4 な環境・処理系もある。
まぁ、あんまり気を落とすな。
479:デフォルトの名無しさん
07/06/19 22:58:22
gccがsizeof(wchar_t)==4でいいんだったっけ
480:デフォルトの名無しさん
07/06/19 23:51:09
-fshort_wchar フラグを指定したら 2 になるけどな。
481:デフォルトの名無しさん
07/06/20 02:58:24
>>474
C++/CLIは、WG21の中のマイクロソフトの人がどうするかにかかっていると思う。
しかし純然たる研究者だったはずの二人が、
どうしてC++/CLIに必死なのか良くワカランネ。
契約になんか書かれているのかな。
482:デフォルトの名無しさん
07/06/20 08:40:01
C++0x実現まであと9年もあるから大丈夫
483:デフォルトの名無しさん
07/06/21 22:32:37
>479
cygwin 上だと gcc でも 2。
484:デフォルトの名無しさん
07/06/22 01:24:22
今は亡き、Windows版CodeWarriorでもsizeof(wchar_t)==4。
亡くなって当然ｗ
485:デフォルトの名無しさん
07/06/22 01:24:48
>477
Objective-C++ という Obj-C の C++ 拡張が存在する
C++/CLI はどうせコンパイラの開発部分は共通だから強引に組み込むでしょ
直接ぶつかるところは少ないし、そもそも普及に至っては・・・
486:デフォルトの名無しさん
07/06/22 01:44:27
後半二行、何を言っているのかわからん。
「組み込む」対象は何なんだ?
487:デフォルトの名無しさん
07/06/22 22:10:11
え、VC の cl にだけど
488:デフォルトの名無しさん
07/06/23 10:46:35
マイクロソフトは規格への追従遅いじゃん。
メジャー番号が変わるまで延々放置って事がよくある。
スイッチで切り替えて、細心の規格に追従した動作になるってこともあまりない。
489:デフォルトの名無しさん
07/06/24 21:02:05
C++1xに名前変えるか
490:デフォルトの名無しさん
07/06/25 06:03:52
何でこんなに時間掛かるんだろう？
491:デフォルトの名無しさん
07/06/25 09:41:11
やっつけでやられても困る。
492:デフォルトの名無しさん
07/06/25 13:37:16
>>490
天才のお前が傍観者だからだよ
493:デフォルトの名無しさん
07/06/25 17:37:29
Javaの初期のクラスライブラリみたいな不細工なのは困る。
iostreamだって今になってみれば、設計し直したいところ多数。
494:デフォルトの名無しさん
07/06/25 19:56:26
>>474
ObjC++はコンパイラがC++のバージョン選べるようにしてくれるでしょ。
495:デフォルトの名無しさん
07/06/26 03:02:50
News 2007-06-25: C++ Standard Core Language Issues List (Revision 48) is available
News 2007-06-25: The C++ Standard Library Issues List (Revision 49) is available
今までC++相談室に貼ってた JTC1/SC22/WG21 の更新情報は
今回からこっちに貼ることにしました。
496:デフォルトの名無しさん
07/06/26 03:12:13
C++X
の方が魚の骨っぽくて好き
497:デフォルトの名無しさん
07/06/26 13:38:12
もう規格なんてやめてBoost全部取り込んじゃえよ
498:デフォルトの名無しさん
07/06/26 17:06:10
それは行き過ぎだろうけど、ライブラリをほかとは別規格にするというのはありだと思う
499:デフォルトの名無しさん
07/06/26 17:57:38
古い Fortran みたいにいくつかのレベルに分ければよかったのに、と
時々思うわけさね。
500:デフォルトの名無しさん
07/06/26 18:18:06
C++はPL/Iを超える化け物言語になりつつあるな。
501:デフォルトの名無しさん
07/06/26 22:21:29
Javaほどじゃないけどな
502:デフォルトの名無しさん
07/06/26 22:24:57
は？
503:デフォルトの名無しさん
07/06/26 22:31:00
またジャバグラマか。
504:デフォルトの名無しさん
07/06/26 23:26:45
そろそろミーティング回数増やさねえとヤヴァくね？
最近あんま進展ないし、また議論不足で vector<bool> とか auto_ptr みたいな
半端者が生まれちまうぜ
505:デフォルトの名無しさん
07/06/26 23:27:57
禿が死ぬまでには出来てると思うから気長に待つよ
506:デフォルトの名無しさん
07/06/27 03:44:26
なぁに禿が死んだら誰かが代わりに永久脱毛すればいい話
507:デフォルトの名無しさん
07/06/27 09:25:40
>500
あのALGOL系とCOBOLを無理矢理繋げたような変態言語と比べられても…
…いや、的確か
508:デフォルトの名無しさん
07/06/27 09:29:07
PL/Iを馬鹿にするなー
本当に何でもできる言語なんだぞー
あ、でも糞言語だったけどね
消えたし
509:デフォルトの名無しさん
07/06/27 09:58:55
他の言語は要らなくなるから、Programming Language/1。
510:デフォルトの名無しさん
07/06/27 10:33:28
その C++ と Objective-C を無理矢理繋げた変態言語の立場は。
511:デフォルトの名無しさん
07/06/27 22:21:53
お前ら頭良いんだからサッサと立派な規格でまとめてくれよ
512:デフォルトの名無しさん
07/06/27 22:24:43
よしきた
513:デフォルトの名無しさん
07/06/27 22:27:55
標準ヘッダファイル2chを追加
514:デフォルトの名無しさん
07/06/27 22:30:20
boostをはじめとするライブラリが整備されている今でこそC++は「使える」言語だと思えるんだけど
それらがあんまり無かった時代になんであんなに流行ったのかがいまいちよく分からない
515:デフォルトの名無しさん
07/06/27 22:33:48
競争相手が無かったから
516:デフォルトの名無しさん
07/06/27 23:05:19
C++がもしなかったらと考えると興味深い。
JavaやLL言語のようなものはあっただろうか？
LISPやSmalltalkの影響はもっと大きかっただろうか？
517:デフォルトの名無しさん
07/06/27 23:09:41
>JavaやLL言語のようなものはあっただろうか？
普通にあったんじゃない？
518:デフォルトの名無しさん
07/06/27 23:18:46
ねーよ。
C++の影響は計り知れない
519:デフォルトの名無しさん
07/06/28 01:15:28
cfront最終版の頃には、
Modula-3, Oberon, CLU, Argus, Effiel, Ada 9X, Delhpi, Smalltalkあたりが軒並死亡宣告。
NEXTSTEP, Display PostscriptのおかげでObjective-Cが生き残っている程度だった。
520:デフォルトの名無しさん
07/06/28 01:34:50
その言語大絶滅は何か原因はあるの？
//まあマイナー言語の生成消滅は常に起きてるだろうけど。
521:デフォルトの名無しさん
07/06/28 09:02:38
勝手に言ってるだけだろ。もともとニッチなのもいくつかあるし
死んでないのもいくつかあるし。
要はC++が広まりすぎて、他の言語が相対的に影が薄くなったって
ことだと思う。
522:デフォルトの名無しさん
07/06/28 09:09:11
C++とJavaは、プログラミング言語の研究者をしゃぶりつくしているけどな。
こんなに人材が集まったことは今だかつてないんじゃないか?
C++に関して言えば、マクロ(特殊化当たり前)由来のtemplateが決定打だったな。
523:デフォルトの名無しさん
07/06/28 12:08:12
C++ってマクロなんでしょ？
524:デフォルトの名無しさん
07/06/28 12:11:46
???
525:デフォルトの名無しさん
07/06/28 14:00:51
っ MFC
526:デフォルトの名無しさん
07/06/28 14:14:36
MFCとVC6は大量のC++挫折者を生み出しました
527:デフォルトの名無しさん
07/06/28 17:52:57
>>522
C++がひろがってたのはtemplate以前からだけどね。
TMPがはいって地獄がより強固になった。
528:デフォルトの名無しさん
07/06/28 20:02:22
シェア90%のOSが推奨すれば広まって当然
529:デフォルトの名無しさん
07/06/28 21:26:08
じゃあこれからはドトネト天国だね
530:デフォルトの名無しさん
07/06/28 21:38:39
C#する気もしない気も～VMの性能にかかっているんだよ～
531:デフォルトの名無しさん
07/06/28 22:21:08
C++は滅びぬ！何度でもよみがえるさ。
ネイティブコードの力こそ人類の夢だからだ
532:デフォルトの名無しさん
07/06/28 22:22:00
D が完成しさえすれば・・・。
533:デフォルトの名無しさん
07/06/28 22:50:37
ネイティブでGC無しというところが、
C++の強さにして弱み。
534:デフォルトの名無しさん
07/06/28 22:52:36
し、C++/CLIとかどうですか・・
535:デフォルトの名無しさん
07/06/29 00:03:58
Dもキメラ過ぎる
536:デフォルトの名無しさん
07/06/29 23:28:16
Dがもっとリッチに色々揃えば良いけど。
537:デフォルトの名無しさん
07/06/29 23:32:38
やっぱC++は最高だな
538:デフォルトの名無しさん
07/06/30 19:25:36
C++0xになったらどんなステキな世界が待っているんだろう。
アスペクト志向取り入れないかな
539:デフォルトの名無しさん
07/06/30 19:46:15
>533
でも委員会で GC の話してるみたいよ？
540:デフォルトの名無しさん
07/06/30 20:31:26
今のところHans Boehmの提案が最有力候補かな？
541:デフォルトの名無しさん
07/06/30 20:32:07
GC ねえ。
GC なしで組めるモードもあるんだよね？
542:デフォルトの名無しさん
07/06/30 21:19:39
C99に合わせたりはしないのかな。
543:デフォルトの名無しさん
07/06/30 21:37:25
>>541
＞GC なしで組めるモードもあるんだよね？
C++(0x)的にほぼ採用のための必須条件とおもわれ
544:デフォルトの名無しさん
07/06/30 22:30:57
>>542
だいたいのところは取り込まれてるみたい。
545:デフォルトの名無しさん
07/07/01 11:32:07
URLﾘﾝｸ(www.open-std.org)
News 2007-06-30: The 2007-06-pre-Toronto mailing is available
546:デフォルトの名無しさん
07/07/01 11:33:18
>>543
えーーー！
いくらなんでもそれは無くね？
547:546
07/07/01 11:34:11
勘違いしてた
「GCなしでも組める」事が必須条件なのね
ごめんなさい
548:デフォルトの名無しさん
07/07/01 11:51:16
C++的には、使わなければ余分なコストはかからないというのは必須だろ。
549:デフォルトの名無しさん
07/07/01 11:53:34
そこでGCCですよ
550:デフォルトの名無しさん
07/07/01 11:57:17
GCを使うか使わないかを不具合無しで簡単に切り替えられるのがいい
例えばアロケータを差し替えるだけでとかそういうので
551:デフォルトの名無しさん
07/07/01 12:00:52
GC自体はあってもいいが破棄のコードが無いと対称性が崩れてキモチワルイな
552:デフォルトの名無しさん
07/07/01 12:02:25
>>551
現行の C++ でも delete はほとんど auto_ptr や shared_ptr 任せで
コードには無いだろ。
553:デフォルトの名無しさん
07/07/01 12:03:19
>>551
ではauto_ptrやshared_ptrについてどうお考えでしょうか？
554:デフォルトの名無しさん
07/07/01 12:05:59
shared_ptrとかは削除子指定できるからな
GCも同様に削除子が指定できれるならば生成子と対照が簡単に取れるから問題なし
555:デフォルトの名無しさん
07/07/01 12:07:50
なんだよかたそういう対照性か。
まさかソースコード上の対照性を言っているのかと思って心配になった。
556:デフォルトの名無しさん
07/07/01 12:11:55
>>554
メモリ管理専用にしないと GC によるメリットなんて得られないんじゃない？
削除子なんか入れたら実行タイミングに完全な規格を定義しないといけないでしょ。
557:556
07/07/01 12:16:45
うーんもうちょっと調べ物してから言えばよかったかな。
あんまりはっきりしたこともいえないんで、スルー推奨。
558:デフォルトの名無しさん
07/07/01 12:17:46
超基本的な質問なんだけど
GCありの場合でも自動変数がスコープ抜けた時とかにデストラクタは呼ばれるの？
その場合、そのクラスがフリーストアへのポインタを持っていた場合、
クラスのインスタンス自体は破棄されるけど、参照されていたメモリは
GCの場合はすぐに回収されないってことになるの？
559:デフォルトの名無しさん
07/07/01 12:21:51
GCってオンオフするもんなの？
当方C++/CLIのイメージが強いもんで、C++0xでどうなるのかわからないんだけどさ。
^とgcnewみたいなものじゃまずいのかなぁ。
560:デフォルトの名無しさん
07/07/01 12:38:43
すみません
int a[] = new int[10];
int *b = new int[10];
みたいに確保したときって
delete a;
delete a[];
delete b;
delete b[];
それぞれ解放の仕方で動作おかしくなりますか？
561:デフォルトの名無しさん
07/07/01 12:45:19
>>560 スレ違い。こっち逝け→ ｽﾚﾘﾝｸ(tech板)
562:デフォルトの名無しさん
07/07/01 15:35:28
>>560
とりあえず Effective C++ でも買ってこい
563:デフォルトの名無しさん
07/07/01 23:47:23
>>545
今回はいつもよりちと早めだね
小技系だが、N2332 がはげしく欲しい
564:デフォルトの名無しさん
07/07/02 07:35:17
やっぱSL73だろ
URLﾘﾝｸ(gradeup.blog39.fc2.com)
565:デフォルトの名無しさん
07/07/02 09:24:38
みんな好き勝手いいやがって……だれが実装すると思ってるんだ
566:デフォルトの名無しさん
07/07/02 12:50:56
>>563
make_*関数が要らなくなるのは確かに便利だな。
567:デフォルトの名無しさん
07/08/07 08:31:37
最近のSutterは完全にC++/CLI宣伝だな。
そういう契約なのかな…
568:デフォルトの名無しさん
07/08/09 21:18:40
最新のドラフトってこれでいいのかな？
# ISO/IEC 14882: Programming Language C++ - draft
URLﾘﾝｸ(www.open-std.org)
569:デフォルトの名無しさん
07/08/09 21:27:04
今日付けでn2369が出たみたい。
570:デフォルトの名無しさん
07/08/09 22:45:56
今日付けw 何とタイムリーな。
こいつかな？
URLﾘﾝｸ(www.open-std.org)
571:デフォルトの名無しさん
07/08/09 22:49:14
今日じゃないや、6日だ…
今月分のもろもろ。
URLﾘﾝｸ(www.open-std.org)
572:デフォルトの名無しさん
07/08/09 23:50:33
decltype 追加か。細かい仕様はともかく、追加は確定なのかな。
あと alignas, alignof, constexpr も追加。
そして、char16_t, char32_t も追加？ 色は変わってないけど。
constexpr は D のコンパイル時実行みたいなもんか。
メタプロの世界がまた１つ広がりそうだな。
alignas と alignof は構造体のアラインメント関連か。
alignas で指定して、alignof で取得する、といったところか。
char16_t と char32_t は UTF-16 と UTF-32 用の char だっけ？
何か前に話題に出てたよね。
573:デフォルトの名無しさん
07/08/10 00:01:26
しかし、結構ドラスティックな変更が多いと思うけど、
こんなんがあと二年でまとまるんだろうか
574:デフォルトの名無しさん
07/08/10 00:10:12
constexprは制限が強すぎて見た目ほど強力じゃなかったはず
575:デフォルトの名無しさん
07/08/10 06:15:42
URLﾘﾝｸ(www.open-std.org)
News 2007-08-09: The 2007-08-post-Toronto mailing is available
News 2007-08-09: C++ Standard Core Language Issues List (Revision 49) is available
News 2007-08-09: The C++ Standard Library Issues List (Revision 50) is available
576:デフォルトの名無しさん
07/08/10 09:46:56
FORTRESSに、禿の"Generalizing Operator for C++2000"風の演算子拡張があって、
気になって仕方がない。
577:デフォルトの名無しさん
07/08/11 06:43:14
= default と = delete がいまいち分かんないな。
= default はデフォルトで作られるメンバ関数を非 inline 化するためのもの・・・でいいのか？
いまいち使い道が分からんが。
= delete は関数を使えなくする・・・でいいのか？
こっちはまあ使い道あるだろうけど、
10.3p14 を見るに、基底クラスのメンバを殺すのには使えんのか？
578:デフォルトの名無しさん
07/08/11 08:08:25
うわあああ
もう予約語の使いまわしはやめてくれぇぇぇぇぇぇぇ
=0ですらキモすぎるのに=deleteとか=defaultとか
579:デフォルトの名無しさん
07/08/11 08:13:20
フフフ。そのキモさが C++ なのさ！
580:デフォルトの名無しさん
07/08/11 08:41:36
純粋仮想関数とかいいながら、構文が汚れてるよな
581:デフォルトの名無しさん
07/08/11 08:47:17
不純だわ
582:デフォルトの名無しさん
07/08/11 08:51:54
不接触の純粋さは当然のこと。
穢れに触れて、それでも尚純粋であることの方が素晴らしい。
583:デフォルトの名無しさん
07/08/11 09:01:36
それもこれもstaticが全ての始まりでした…
584:デフォルトの名無しさん
07/08/11 09:23:04
*じゃね？
585:デフォルトの名無しさん
07/08/11 09:24:11
& もなかなか
586:デフォルトの名無しさん
07/08/11 09:34:31
POD という表現がことごとく修正されてるのは、
やっぱ constexpr の影響？