C++0x

0001デフォルトの名無しさん

2006/06/05(月) 02:04:07

どんな感じになるの？

0002デフォルトの名無しさん

2006/06/05(月) 02:08:28

2?

0003デフォルトの名無しさん

2006/06/05(月) 02:10:44

転載だけど、こうなるらしい。

--- C++98 Code ---
vector<int> v;
v.push_back(1);
v.push_back(2);
v.push_back(3);
vector<int>::iterator i = find(v.begin(), v.end(), 2);

--- C++0x Code ---
vector<int> v = { 1, 2, 3 };
auto i = find(v, 2);

STLヴァリヴァリな人にはとってもラクチンになる予感。

0004デフォルトの名無しさん

2006/06/05(月) 02:12:31

今まで出来なかったのが不思議

0005デフォルトの名無しさん

2006/06/05(月) 02:13:23

本当にあと2年半以内に出るのか？

0006デフォルトの名無しさん

2006/06/05(月) 02:14:26

標準C++に対してコンパイラの準拠レベルが低かったからでしょ。
規格だけ新しくしても実情が付いてこなけりゃどうにもならん。
実装してみて初めて分かることってのもあるし、様子を見てたんじゃないの？

0007デフォルトの名無しさん

2006/06/05(月) 02:15:11

>>5は算数を勉強しなおしたほうがいいと思う

0008デフォルトの名無しさん

2006/06/05(月) 02:15:27

コンパイル速度が速くなると良いな。Pascal 並みとは言わんけど、常識的な速度で plz.

0009デフォルトの名無しさん

2006/06/05(月) 02:17:19

またいろいろ肥大化するんだろうなあ。
こうしてC++は巨大言語の地位を不動のものとするのでありました。

0010デフォルトの名無しさん

2006/06/05(月) 04:25:24

標準化に関わってるメンバはインテルから金貰ってる。

0011デフォルトの名無しさん

2006/06/05(月) 12:08:10

さっさと右辺値参照と perfect forwarding よこしやがれこんちくしょー！！

0012デフォルトの名無しさん

2006/06/05(月) 14:18:42

2010年になってもまだ制定されてなかったら
0xは16進数のprefixだっていうことにならんかな

0013デフォルトの名無しさん

2006/06/05(月) 16:49:10

>>3
後者のfindは今のboost.range_ex相当だと思っていいんだよな？

0014デフォルトの名無しさん

2006/06/05(月) 17:38:27

>>11
C++ってもうプログラミング言語の実験室だな。

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
を見ていると欲しい機能が満載w

0015デフォルトの名無しさん

2006/06/05(月) 18:58:15

javaみたいに継承禁止を指定できるようになる？

0016デフォルトの名無しさん

2006/06/05(月) 20:43:59

>>3
Boostでほぼ実現されているところが怖いな

>>15
BoostのVaultになんかあったぞ

0017デフォルトの名無しさん

2006/06/05(月) 21:55:44

std::tr1を実装しているところてあるのかな

0018デフォルトの名無しさん

2006/06/05(月) 21:56:24

>vector<int> v = { 1, 2, 3 };
これCとの互換性なくならない？
配列のサイズどうする気なの？

0019デフォルトの名無しさん

2006/06/05(月) 21:59:29

libstdc++にあるよ

$ ls /usr/include/c++/4.1.1/tr1
array bind_iterate.h bind_repeat.h boost_shared_ptr.h
functional functional_iterate.h hashtable memory
mu_iterate.h ref_fwd.h ref_wrap_iterate.h repeat.h
tuple tuple_iterate.h type_traits type_traits_fwd.h
unordered_map unordered_set utility

http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespacestd_1_1tr1.html

0020デフォルトの名無しさん

2006/06/05(月) 22:03:35

>>18
> これCとの互換性なくならない？

どうなくなるの?

> 配列のサイズどうする気なの？

boost/preprocessor/array/*と同じ動作になるんじゃないの?

0021デフォルトの名無しさん

2006/06/07(水) 17:16:02

もしもBoost.LambdaがそのままC++に取り込まれたら世も末だな。

0022デフォルトの名無しさん

2006/06/07(水) 21:18:51

手続き、構造化、OOP、ジェネリック、さらに関数型の記述も混在できる！！

…確かに末だな。

0023デフォルトの名無しさん

2006/06/07(水) 21:23:41

え～，それが面白いんじゃんかー．ぶーぶーぶー

0024デフォルトの名無しさん

2006/06/07(水) 22:53:24

lambda記法は、新しい構文で提案されてますよ。

Lambda expressions and closures for C++
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf

002521

2006/06/07(水) 23:07:50

>>24
勿論それは知っている。
だからこそ21を書いた。

0026デフォルトの名無しさん

2006/06/08(木) 09:24:36

Boostのlambdaなんて繋ぎですよ

0027デフォルトの名無しさん

2006/06/08(木) 18:50:12

io,stream,国際化関係
を分かりやすくかつ高パフォーマンスにして欲しい。
今のは使いにくい。

0028デフォルトの名無しさん

2006/06/08(木) 20:33:34

名前がかっこいいから策定されても仕様名はC++0xのままにしてほしい

0029デフォルトの名無しさん

2006/06/08(木) 20:54:05

勧告された暁にはちゃんと年月にちなんでC++0xFFと呼ばれます。

0030デフォルトの名無しさん

2006/06/10(土) 07:30:18

せめて標準ライブラリの部分だけでも、5年に一度ぐらいの割合で
改訂してくれんかな。

0031デフォルトの名無しさん

2006/06/10(土) 10:36:15

一応そのくらいでやるつもりなんでしょ。

0032デフォルトの名無しさん

2006/06/11(日) 11:33:06

二進数表記ができるようになってほしい。

0033デフォルトの名無しさん

2006/06/11(日) 11:47:29

>>32
2進←→16進なんて簡単に脳内で変換できるんだから要らなくね？

0034デフォルトの名無しさん

2006/06/11(日) 12:02:14

>>32
10bitまでならherumiさんのtemplateで出来るぞ。

0035デフォルトの名無しさん

2006/06/11(日) 12:08:43

>>33
ソース中に記述できることには別の意義がある。

0036デフォルトの名無しさん

2006/06/11(日) 12:19:32

>>35
例えば？

0037デフォルトの名無しさん

2006/06/11(日) 12:24:39

プレフィクスつけて指定する形を取ってるからなあ…
0 → 8進
0x → 16進
じゃあ2進は？

後ろにhとかoとかの形式なら、bを増やせばいいだけなんだが…。

0038デフォルトの名無しさん

2006/06/11(日) 12:31:38

D言語とかでは0bをプレフィックスにしてたな。
ただ、2進表記は微妙と個人的には思う。

0b10101010101010101010101010101010
0x55555555

ソースコード上の2進表記を読み取るより、
16進表記を脳内で2進に変換するほうが個人的には圧倒的に楽

0039デフォルトの名無しさん

2006/06/11(日) 12:37:17

仕様が２進表記を使っている場合に
ソース上で１６進表記になっていると、
仕様を変更するときには変換しないといけないだろ？
ソース中に２進表記ができればコピペで済む所が
脳内変換を必要とするわけよ。これはよくない。

0040デフォルトの名無しさん

2006/06/11(日) 12:39:05

2進 <-> 16進で脳内変換できないようなカスは別の言語をどうぞ

0041デフォルトの名無しさん

2006/06/11(日) 13:10:33

ぶっちゃけ2進数表記は長くなる傾向が多くて使い辛い。
短い表記ならtemplateでも対処できるわけだし。

0042デフォルトの名無しさん

2006/06/11(日) 13:29:32

2進と16審の脳内変換・・・って・・・
手間はコピペするのと大差無いだろ。何が問題なのかわからん。

それともいちいち、2進の各桁に2のn乗かけて・・ってやらないと変換出来ないヘタレか？
10進数を介さないと変換できません、とか。

そんな低脳のために余計な仕様付ける方がどうかしてるわ。

0043デフォルトの名無しさん

2006/06/11(日) 13:37:19

２進データ１０００個のテーブルでも
コピペと脳内変換で大差ないと思うの？
少なくとも俺は面倒で嫌だな。
２進と１６進の変換は普通にできるけどね。

0044デフォルトの名無しさん

2006/06/11(日) 13:48:08

どうせ2進テーブルっつったって0bみたいなprefixがついてるわけじゃないだろう？
正規表現やら何やらを使って半自動で追加させるのも、
16進にコンバートするコンバータをちゃちゃっと書いてしまうのも大差ないと思うが。
どちらにせよそんな限られた状況のためだけに2進数定数を仕様に導入する価値はないと思う。

0045デフォルトの名無しさん

2006/06/11(日) 13:54:55

>>44
> 16進にコンバートするコンバータをちゃちゃっと書いてしまうのも大差ないと思うが。
十分メンドクセェよ。仕事頼める人が限られるのもウザイ。

限られた状況なのはわかってる。しかし一部には確実なニーズがあり、
仕様については実装も簡単だし互換性に影響しないこともあるんで、
追加してもいいだろうとは思う。

これ以上は水掛け論だろうねぇ。

0046デフォルトの名無しさん

2006/06/11(日) 14:02:00

バイナリリテラルは、エンディアンやらビット長の問題で解釈の仕方が実装依存だから
標準規格に入ってない（というか入れられない）だけじゃなかったか？
今後も入ることはないだろ。

0047デフォルトの名無しさん

2006/06/11(日) 14:08:15

えぇー。1バイトが8ビットじゃないマシンって話にしか聞いたことないけど、まだあるの？

0048デフォルトの名無しさん

2006/06/11(日) 14:09:37

>>46
そんな問題は１６進でも同じじゃないか？

0049デフォルトの名無しさん

2006/06/11(日) 14:11:41

2<->16変換なんて自前で書きゃいいだろ30秒もかからんぞ
#include<stdio.h>
#include<stdlib.h>
int main(){
    char s[80];
    while(gets(s))printf("0x%08lX\n",strtoul(s,0,2));
    return 0;
}

0050デフォルトの名無しさん

2006/06/11(日) 14:14:59

>>48
例えば
int i=0x10;
は、ビッグエンディアンなら10000、リトルエンディアンなら00001のビット列と解釈される（コンパイラが自動でやってくれる）ので
ソースコードを別マシンに移しても問題ないけれど、
int i=0b10000;
という表記を認めたら、それは0x10なのか、それとも0x1なのかの解釈がコンパイラによって変わってしまい、
ソースコードの移植性がなくなるって話だろ。

0051デフォルトの名無しさん

2006/06/11(日) 14:16:09

>>49
はいはい。スゲェスゲェ。

そのレベルで済ませられる奴が同じチームに何人居ると思う？
何人も居たとして、同じ（似たような）機能のツールを
世界中のプログラマが繰り返し実装するのを無駄だとは思わんかね？

0052デフォルトの名無しさん

2006/06/11(日) 14:17:54

10進数だけでいいじゃん

0053デフォルトの名無しさん

2006/06/11(日) 14:19:25

>>50
エンディアンはメモリなどのバイト列を考えたときの
バイトオーダーの話だから、数値の表現形式自体とは関係ないよ。
0x10 が 16 と定まるように、 0x10 は 0b10000 と定まる。

0054デフォルトの名無しさん

2006/06/11(日) 14:23:01

>>51
>そのレベルで済ませられる奴が同じチームに何人居ると思う？
>何人も居たとして、同じ（似たような）機能のツールを
>世界中のプログラマが繰り返し実装するのを無駄だとは思わんかね？
驚いたwwww
ひどい低能だな
お前にプログラミングは向いてない
やめたほうがいいと思われ

0055デフォルトの名無しさん

2006/06/11(日) 14:23:12

bitmapなんかをソースに埋め込みたいときに使えると便利だな

0056デフォルトの名無しさん

2006/06/11(日) 14:25:41

D&Eぐらい嫁。
C++標準委員会は既にバイナリリテラルへの対応を予備審査で却下してるんだから
これから実装されることはまずあり得ない。

0057デフォルトの名無しさん

2006/06/11(日) 14:25:58

>>54
質問には答えてほしかったんだが、まぁいい。
どうせ現実世界には影響の無い与太話だ。

0058デフォルトの名無しさん

2006/06/11(日) 14:35:53

今気づいたが、禿のC++Glossaryでは
　C++0x - the upcoming revision of the ISO C++ standard; 'x' is scheduled to be '9'. See my publicatons page.
2009年予定なのね…
ISOの改訂って5年ごとじゃなかったっけか？

0059デフォルトの名無しさん

2006/06/11(日) 15:11:00

個人的にはビットパターンを図示しやすくなるからバイナリリテラルはあってもいいと思う。
で、やるからには8or4ビットごとにセパレータを入れられればもっといい。
Ex. 0xdead → 0b1101_1110_1010_1101

0060デフォルトの名無しさん

2006/06/11(日) 15:51:52

http://www.illegal-immigration.com/Riv/boost/binary_literal.hpp
これか。いつ追加されるのだ
まーこんなのよく考えるもんだ

0061・∀・）っ-○◎● ◆toBASh....

2006/06/11(日) 18:00:21

_0b00000000～_0b11111111までとか定数定義して、あと16bitとか32bitとかマクロで連結する
ってことやってる会社は知ってる

0062デフォルトの名無しさん

2006/06/11(日) 18:03:11

全部マクロでやってるヘッダならboostで見た気がする

0063デフォルトの名無しさん

2006/06/11(日) 18:05:25

CでGUIアプリってつくれるの？
javaしかやったことないんで。
しかもさ、本にのってないよね？
よくわかるCとか、かんたんできるCとか
いろいろ本でてますけどCUIだよな。
どうしたらCでGUIアプリ作れるの？

0064デフォルトの名無しさん

2006/06/11(日) 18:08:20

スレ違いも甚だしい

0065デフォルトの名無しさん

2006/06/11(日) 18:10:25

Javaでネイティブアプリってつくれるの？
Cしかやったことないんで。
しかもさ、本にのってないよね？
よくわかるJavaとか、かんたんできるJavaとか
いろいろ本でてますけどVMだよな。
どうしたらJavaでネイティブアプリ作れるの？

0066デフォルトの名無しさん

2006/06/11(日) 18:22:05

GCJ

0067デフォルトの名無しさん

2006/06/11(日) 20:15:11

>>58
五年ごとって決まっているのは一部でしょ。
たとえばFORTRAN。

0068デフォルトの名無しさん

2006/06/12(月) 23:27:59

C++ Template Metaprogramming にはこんなのもあるよ。

template <unsigned long N>
struct binary
{
static unsigned const value
= binary<N/10>::value * 2 + N % 10;
}

0069デフォルトの名無しさん

2006/06/12(月) 23:31:13

>>68 assert(binary<0101>::value == 5);

0070デフォルトの名無しさん

2006/06/12(月) 23:39:28

59について思ったのだが、68で、テンプレート引数をいくつも取るようにしてやればいいと思った。

template<
    unsigned long Byte1, unsigned long Byte2,
    unsigned long Byte3, unsigned long Byte4>
struct binary4
{
    staic const unsigned long value =
        binary<Byte1>::value << 24 |
        binary<Byte2>::value << 16 |
        binary<Byte3>::value << 8 |
        binary<Byte4>::value << 0;
};

binary4<11110001, 11100010, 11010011, 11000100>::value == 0xf1e2d3e4

0071デフォルトの名無しさん

2006/06/12(月) 23:58:14

馬鹿には>>60が見えないのか？
templateはboostに却下された

0072デフォルトの名無しさん

2006/06/13(火) 00:03:22

Boostに入らなければ個人的に作って使えばよいだけ。

0073デフォルトの名無しさん

2006/06/13(火) 01:11:05

実用性ゼロの趣味テンプレート

0074デフォルトの名無しさん

2006/06/20(火) 19:53:27

保守

0075デフォルトの名無しさん

2006/06/24(土) 01:13:05

TR1の本ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

http://www.amazon.com/gp/product/0321412990/
http://www.aw-bc.com/catalog/academic/product/0,1144,0321412990,00.html

Pete Beckerﾊｧﾊｧ
http://www.petebecker.com/

0076デフォルトの名無しさん

2006/06/24(土) 01:37:47

>>75
本を出す意義がわからん。
↓のドラフトや boost の実装、ドキュメントで十分だろ。
http://www.open-std.org/jtc1/sc22/wg21/

0077デフォルトの名無しさん

2006/06/24(土) 02:37:21

EffectiveSTLのTR1に合わせた改訂予定はあるのかな

0078デフォルトの名無しさん

2006/06/24(土) 05:35:16

ライブラリもいいけど、早いとこ concept や rvalue reference
決めねえと間に合わなくなると思うんだがな。こいつら入ったら
ライブラリ大幅に書き直しじゃん？

0079デフォルトの名無しさん

2006/06/24(土) 09:49:39

>>75
Peteが出すんだから、出す意味のある内容なんじゃないのかね。
>>78
0xは2009らしいから、ライブラリも頑張って全面的に書き直すんじゃないのかね。
C++って本当、永遠に仕様が確定しそうにないよな。

0080デフォルトの名無しさん

2006/06/24(土) 13:02:27

C++は完璧ではないし、完璧になることはあり得ない。常に進化し続ける。
とは禿の言葉だっけか

0081デフォルトの名無しさん

2006/06/24(土) 14:31:54

常に進化し続けるのはいいが仕様が確定しないと処理系が出てこないわけで。

0082export

2006/06/24(土) 14:55:05

すみません。
私を知っている人はいますか？

0083・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6

2006/06/24(土) 15:14:38

仕様があるのにどの処理系でも未だサポートされないキーワードの典型ですな

0084デフォルトの名無しさん

2006/06/24(土) 15:42:03

name lookup ruleも永遠に定まらないだろうな。

0085・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6

2006/06/24(土) 15:46:48

ガベコレでも標準ライブラリに入れて欲しいと思うの俺だけ？

0086デフォルトの名無しさん

2006/06/24(土) 16:53:21

ガベコレが必要なのはCだろう...
shared_ptrは再帰デストラクタ失敗するのが弱点だよな。

0087デフォルトの名無しさん

2006/06/24(土) 17:23:13

>>86
> shared_ptrは再帰デストラクタ失敗するのが弱点だよな。
なんのこと？

0088デフォルトの名無しさん

2006/06/24(土) 17:30:52

循環参照のことでは？

0089デフォルトの名無しさん

2006/06/24(土) 18:50:37

>>82
concept の導入によりテンプレートの定義と実装を分けることが
可能になれば、あるいは再デビューできるかも試練よ

0090デフォルトの名無しさん

2006/06/24(土) 19:01:55

>>78
>0xは2009らしいから、ライブラリも頑張って全面的に書き直すんじゃないのかね。

現状の年２回のミーティングじゃ３年なんてあっと言う間だろう。

N2004より
>The following proposed changes will cause the C++0x schedule
>to slip if the committee does not commit to them by the end of
>the October, 2006 meeting, ...

0091デフォルトの名無しさん

2006/06/24(土) 20:46:20

200C年くらいに出れば御の字だよね

0092デフォルトの名無しさん

2006/06/24(土) 21:04:49

>>91
6198年後かよ

0093デフォルトの名無しさん

2006/06/24(土) 23:26:48

>>83
でも予約だけはされてんのな。

0094デフォルトの名無しさん

2006/06/25(日) 16:38:34

予約じゃないですよ。
既に規格の一部です。

0095デフォルトの名無しさん

2006/06/26(月) 08:09:14

予約だし、規格の一部だよ。

0096デフォルトの名無しさん

2006/06/29(木) 22:23:00

そういやどうして「予約語」っていうんだろう

0097デフォルトの名無しさん

2006/06/29(木) 23:45:12

>>96
字句は識別子としての要件を満たしているから。
だけど文法上特別な意味を持たすために、
識別子として使えないようコンパイラがその字句を「予約」している。

0098デフォルトの名無しさん

2006/06/30(金) 00:10:26

まあ「予約」語は誤訳みたいなもんで、(特に「予」め)
除外語がreserved workの訳には適当。

0099デフォルトの名無しさん

2006/06/30(金) 01:10:08

うはｗ　やべぇ concept_map 凶悪

concept_map InputIterator<int> {
　typedef int value_type;
　typedef int reference;
　typedef int* pointer;
　typedef int difference_type;
　int operator*(int x) { return x; }
};
copy(1, 17, ostream_iterator<int>(cout, " "));
　// prints: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

0100デフォルトの名無しさん

2006/06/30(金) 09:43:52

>98
「除外」のほうが違和感がある

0101デフォルトの名無しさん

2006/06/30(金) 12:53:14

「お客様、そこは除外席ですので、他の席をお使い下さい」

0102デフォルトの名無しさん

2006/06/30(金) 13:51:26

>>98
中学校からやり直せ。

いや、おまえは英語を読むな。

0103デフォルトの名無しさん

2006/06/30(金) 18:43:40

>>99
ヘタにガリガリ書くコーディングが減っていいんじゃないか？

0104デフォルトの名無しさん

2006/07/10(月) 12:59:49

　int operator*(int x) { return x; }
はやりすぎと思うが。

話題もないので張っときます。

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2051.htm

Strong candidates for TR2 include:
* Filesystem (accepted)
* Thread support
* Date and time
* Network file support
* Consistent system/OS error reporting
* Range-types, to complement iterators
* String algorithms
* Optional/Nullable values
* Range-checked numeric-casts
* 'Lexical' casts
* typesafe 'any' class
* interval arithmetic
* Unlimitted precision integer type

0105デフォルトの名無しさん

2006/07/10(月) 20:46:42

>>104
Thread単体でサポートしてもなぁ。
ACE見たく非同期関連のフレームワークと一緒でないとあんまり役に
たたない様な気がするけど。
(boost.)lexical_castはspiritがあるのでちっとも使わん。

0106デフォルトの名無しさん

2006/07/11(火) 03:12:35

>* typesafe 'any' class
　Boostにある、あれをそのまま盛り込むのだろうか。

>* Unlimitted precision integer type
　まあ、簡単につかえる標準ライブラリは欲しいかな。

0107デフォルトの名無しさん

2006/07/11(火) 06:56:10

基本的には同じ
Any Library Proposal for TR2
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1939.html

かなり強力
Proposal for an Infinite Precision Integer for Library Technical Report 2, Revision 1
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2020.pdf

0108デフォルトの名無しさん

2006/07/12(水) 22:26:27

>>105
でもC++に標準でスレッドサポートされる、というのは大きいんじゃまいか。
もしかしたら将来のCでもサポートされるかもしれんし。

0109デフォルトの名無しさん

2006/07/12(水) 22:42:35

tr2でXMLとかネットワークとかマジですか

実現したらかなり協力だなぁ

0110デフォルトの名無しさん

2006/07/12(水) 23:06:20

この調子で行けばC++ 2xにはGUI関連が標準ライブラリに入るに違いない。

0111デフォルトの名無しさん

2006/07/12(水) 23:28:26

Boostで便利なのが軒並み入ってるな。
それ以外の勢力は元気なくてさみしい。

0112デフォルトの名無しさん

2006/07/14(金) 02:28:31

C++0xに対応したMSのコンパイラはいつ出るんだろ。
規格が決まってから、実装するまで何年ぐらいかかるのかな。

0113デフォルトの名無しさん

2006/07/14(金) 03:00:55

過去の例から考えると１０年くらいか orz

0114デフォルトの名無しさん

2006/07/14(金) 13:30:29

boost 1.34 には tr1が入るみたいだから、
boostからtr1が使っている部分だけ抜き出してそれをVC++用に使うようにすればいい
といってみるテスト

0115デフォルトの名無しさん

2006/07/14(金) 16:02:33

そういえば、いまさらで馬鹿にされる質問かもしれないけど、
新しいライブラリの名前空間はどうなるんだろう。
まさか　tr1　などというかっこ悪い名前空間のままだったりはしないよね。
でも、stdに押し込むと、既存のライブラリと衝突したりしないのかな

0116デフォルトの名無しさん

2006/07/14(金) 16:06:59

>>115
衝突しないようにstdに入れるんじゃまいか？

0117デフォルトの名無しさん

2006/07/16(日) 01:56:20

今はstd::tr1みたいだけど、最終的にはどうなるんだろね。

0118デフォルトの名無しさん

2006/07/16(日) 09:12:22

stdにいれるに決まってるじゃん。
けどJavaみたいに階層構造になっているのもいいよな。

importってのは、#includeとusingをうまく組み合わせていると思う。

0119デフォルトの名無しさん

2006/07/16(日) 10:13:57

階層化する前に、名前空間の記述の簡易化をはやく標準化して欲しいよ

0120デフォルトの名無しさん

2006/07/16(日) 10:46:32

namespace com { namespace example { namespace myproj { /* */ } } }
ってめんどくさいから、例えば
namespace com::example::myproj { /* */ }
とかね。

ふと思ったんだけど、C++0xはライブラリ以外の部分はどう変わるんだろう。

0121デフォルトの名無しさん

2006/07/16(日) 12:06:35

draft October 2005
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf

0122デフォルトの名無しさん

2006/07/16(日) 15:01:35

TR1のMathematical special functionsに球面調和関数が入ってるのね・・・
昨今のPRT人気の影響なんだろうか

0123デフォルトの名無しさん

2006/07/17(月) 09:20:31

>>121
追加削除あるところはだいたい文字色変えてあるのね。わかりやすくていい。

そこだけざっと見たところ、C99互換以外では、static_assert が増えてるのと、
コンテナやイテレータにちょこっとメンバが増えてるのくらいだな。

0124デフォルトの名無しさん

2006/07/17(月) 11:47:30

>>121
ドラフトで800ページオーバーかよ・・・・orz

0125デフォルトの名無しさん

2006/07/17(月) 12:52:37

Conceptおもしろいのう…

Generic Programming in ConceptC++
http://www.generic-programming.org/languages/conceptcpp/

0126デフォルトの名無しさん

2006/07/19(水) 18:16:54

予約語 where がなにか違和感
この調子で5W1Hの予約語が追加されたらｵﾓﾛ

0127デフォルトの名無しさん

2006/07/19(水) 18:57:33

この調子では来世紀にはすべての英単語が予約語になってしまうのではないか...

0128デフォルトの名無しさん

2006/07/19(水) 21:58:13

今のところ私は来世紀までには死ぬ予定になっているからへっちゃらです

0129デフォルトの名無しさん

2006/07/19(水) 22:00:17

英単語はどんどん増えるから大丈夫です。
フランス語だとあぶないかもですが。

0130デフォルトの名無しさん

2006/07/20(木) 11:12:13

問題は既存の汎用英単語を新しく作る事だ。

0131デフォルトの名無しさん

2006/07/20(木) 12:22:07

文脈依存のキーワードになるから無問題

0132デフォルトの名無しさん

2006/07/20(木) 12:29:00

既存のものを新しく作るのはかなり難しいだろうな

0133デフォルトの名無しさん

2006/07/20(木) 13:55:34

132だけ読むと、所謂パクリにも技術が要るという風にも読み取れるな。

すみません、関係ないです。はい。

0134デフォルトの名無しさん

2006/07/20(木) 18:37:25

活用や接頭接尾語まで予約されたら悪夢

ってどんどん無関係な話題になってないか？

0135デフォルトの名無しさん

2006/07/20(木) 21:33:30

じゃぁ、「もしこの英単語がC++の予約語になったら」でいってみようか。

0136デフォルトの名無しさん

2006/07/20(木) 22:04:17

hage

0137デフォルトの名無しさん

2006/07/20(木) 22:10:03

a, i, j, k, m, n, p, q, r, s, t, u, v, w, x, y

0138C++/CLI

2006/07/21(金) 01:17:11

spaced keyword(藁

0139デフォルトの名無しさん

2006/07/21(金) 02:08:14

fp, argc, argv

0140デフォルトの名無しさん

2006/07/21(金) 02:26:37

C++0x

魚の骨かと

0141デフォルトの名無しさん

2006/07/21(金) 05:39:13

Boostてどんな物なん？

0142デフォルトの名無しさん

2006/07/21(金) 11:07:18

おまえにこのスレは早すぎる

0143デフォルトの名無しさん

2006/07/22(土) 18:56:00

>>135
http://www.linkage-club.co.jp/ExamInfo&Data/BNC%20lemma%20Web.txt

0144デフォルトの名無しさん

2006/08/12(土) 12:18:33

コンセプトとやらにテンポラリオブジェクトも含めて欲しい。
戻り値最適化が解決できるし。
STLコンテナやstringと相性いいと思うんだけどな。

T operator+(const T& lhs, const T& rhs)
T& operator+(temporary T& lhs, const T& rhs)
T& operator=(const T& t)
T& operator=(temporary T& t)

0145デフォルトの名無しさん

2006/08/12(土) 18:44:53

右辺値参照と違うの？

0146デフォルトの名無しさん

2006/08/12(土) 18:50:21

>>144
move semanticsがC++に導入されるのを期待しよう。

0147デフォルトの名無しさん

2006/08/12(土) 23:04:01

うわー、まったくもってそのものな仕様だなこれ。恥ずかし。
でも例えばこう書ければなぁ、と思ってたんだけど
move semanticsの仕様でも多分できるよね。

string&& operator+(string&& lhs, const string& rhs) {
return lhs += rhs;
}

boost::arrayあたりはこう書けないと困るのだけど。

0148デフォルトの名無しさん

2006/08/12(土) 23:42:19

と、思ったけどexpression templateとmove semanticsを組み合わせれば
いらないか・・

0149デフォルトの名無しさん

2006/08/13(日) 01:48:17

お前らそーいうネタはどこで勉強してるのですか。

0150デフォルトの名無しさん

2006/08/13(日) 07:49:40

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/

0151デフォルトの名無しさん

2006/09/07(木) 04:19:13

tr1::regexって、もっとも多機能なsyntax_option_typeでも
ECMAScript相当なんだな。
うーん、今時look-behindがないってのは見劣りするなあ。

0152デフォルトの名無しさん

2006/09/07(木) 14:25:14

boostにTR1が実装されたみたいだけど、使ってみようかな

0153デフォルトの名無しさん

2006/09/07(木) 15:22:21

>>3を見るまでautoの存在を忘れていた

0154デフォルトの名無しさん

2006/09/07(木) 16:44:13

C++0xの0xが16進プレフィクスではなく
2010年までには出すぞ、という願望の現われだと今日知った。

早く使いたいな。

0155デフォルトの名無しさん

2006/09/07(木) 17:52:59

対応コンパイラが出るのは5年後です

0156デフォルトの名無しさん

2006/09/07(木) 21:27:24

C++0xが世に出るのは2109年だよ。
ドラえもんはそれで書かれてる。

0157デフォルトの名無しさん

2006/09/07(木) 23:56:45

C++0xの実装は跳ばされる

0158デフォルトの名無しさん

2006/09/08(金) 09:56:08

そんなことはないと言いたいところだけど、
exportの例があるからな…

0159デフォルトの名無しさん

2006/09/08(金) 12:25:16

あれはどちらかというと、実装の手間を考えずに策定した側に
問題あるような。

0160デフォルトの名無しさん

2006/09/09(土) 00:22:06

実際問題、実装しろとか言われたら嫌な汗出てくるもんな。
C++全体に渡ってそんな感じではあるが。

0161デフォルトの名無しさん

2006/09/09(土) 02:41:12

こんなこといいな、できたらいいなと何でもかんでも詰め込んだまではよかったが
不思議なポッケでかなえてくれるドラえもんはいないという点にまで気が回らなかったと

0162デフォルトの名無しさん

2006/09/09(土) 03:24:51

exportは一応EDGが3人年かけてかなえてくれたけどな
誰も近寄らなくなったけどw

0163デフォルトの名無しさん

2006/09/09(土) 04:32:41

C++は夢いっぱい

0164デフォルトの名無しさん

2006/09/09(土) 09:46:54

VC2005で、リンク時のコード生成を行ってるけど、exportじゃ無いのかな？

0165デフォルトの名無しさん

2006/09/09(土) 12:19:22

>>164
それは最適化。
たとえば、リンク時にインライン展開するとか。

0166デフォルトの名無しさん

2006/09/09(土) 13:39:37

exportが駄目でした、なんてのはどうでもいいが
コンパイルは出来るのにそれがC++言語として
正しいかどうか調べ回らないといけないのがつらい
ガベージコレクタの*ない*Javaがモダンな言語とは全く思わないが
write once, compile anywhereなのはうらやましい

0167デフォルトの名無しさん

2006/09/09(土) 13:45:23

実際、Javaはwrite once、compile once、run anywhereだもんな。
失うものも多いが、楽なのは確かだ。

0168デフォルトの名無しさん

2006/09/09(土) 13:48:10

拡張機能を切ってコンパイルすれば、そこそこ正しくはなる。
ただ、それでも他のコンパイラでコンパイルすると
不完全だと分かる事もよくある話。
難しいもんですな。

0169デフォルトの名無しさん

2006/09/09(土) 14:54:45

>167
debug anywhere だけどな

0170デフォルトの名無しさん

2006/09/09(土) 18:08:44

Write Once, Run Anywhere, Debug Everywhere!

0171デフォルトの名無しさん

2006/09/09(土) 20:42:30

やっぱり、#ifdef は要るよ

0172デフォルトの名無しさん

2006/09/09(土) 23:32:00

そんなあなたにBoost MPL。

0173デフォルトの名無しさん

2006/09/11(月) 06:00:00

Debug Everyday!

0174デフォルトの名無しさん

2006/09/11(月) 21:11:16

char を UTF-8、wchar_t を UTF-16 として認識する標準ライブラリおよび
コンパイルオプションが欲しい。

0175デフォルトの名無しさん

2006/09/11(月) 21:55:25

>>174
そういうlocale（特にcodecvt）を作ればいいという話ではないのか？

0176デフォルトの名無しさん

2006/09/11(月) 22:11:50

STLのlocale周りは、はっきり言って無駄だから、
さっくり削除してほしいと思っているのは自分だけ？

0177デフォルトの名無しさん

2006/09/11(月) 22:13:38

実装の話？仕様の話？

0178デフォルトの名無しさん

2006/09/11(月) 22:16:05

>>174
> char を UTF-8

どういうこと?
charというか、mbsのこと?

0179デフォルトの名無しさん

2006/09/11(月) 22:17:32

>>174
> wchar_t を UTF-16 として

どういうこと?
UTF-16じゃなくて、UCS-4でなく?

0180デフォルトの名無しさん

2006/09/11(月) 22:18:43

>>176
君みたいな人は少ないと思う。

0181デフォルトの名無しさん

2006/09/12(火) 01:02:06

サロゲート無しのUCS-2じゃ、やっぱりそのうちUCS-4に駆逐されるというか
邪魔にされる日が来るのかね。
1文字2Bytesは呑めても、4Bytesは呑み込み辛い…様な。

0182デフォルトの名無しさん

2006/09/12(火) 01:24:19

しかし1文字2バイトを許容できるのは、日本人が元から2バイト文字に慣れ親しんでいたからであって、
欧米人は1文字2バイトも受け入れがたい存在なのではないかと考えたことがある。
実際のところどうなのかは知らないが。

ちなみに俺は仮名漢字がほとんどの場合、UTF-8でも受け入れ難い。

0183デフォルトの名無しさん

2006/09/12(火) 02:34:51

http://www.open-std.org/jtc1/sc22/wg21/
> News 2006-09-11: The 2006-09 mailing is available (4700 kb tar.gz, .zip 4700 kb) individual papers
> News 2006-09-11: The C++ Standard Library Issues List (Revision 44) is available (.tar.gz)
> News 2006-09-11: C++ Standard Core Language Issues List (Revision 43) is available, also committee version

0184デフォルトの名無しさん

2006/09/12(火) 13:22:39

>>183
(ﾟ∀ﾟ)ktkr
待ってたぜ。これで仕事中こっそり楽し(ry

0185デフォルトの名無しさん

2006/09/13(水) 05:22:20

>>182
> 欧米人は1文字2バイトも受け入れがたい存在なのではないかと考えたことがある。
だからこそUTF-8でしょ
> ちなみに俺は仮名漢字がほとんどの場合、UTF-8でも受け入れ難い。
日本人の都合なんか知ったこっちゃないし

0186デフォルトの名無しさん

2006/09/13(水) 06:41:57

ゴチョゴチョうるさいから、だから言語の規格では文字コード未定義扱いなの。

0187デフォルトの名無しさん

2006/09/13(水) 08:27:03

だからさ、char 型なんて廃止して、byte 型にしてほしいぜ
別個に string 型を用意して、string::char を定義して、あとは実装依存でいいと思うんだが

0188デフォルトの名無しさん

2006/09/13(水) 09:48:52

charが実装依存ですが?
basic_stringテンプレート知らない人ですか、ああそうですか

0189デフォルトの名無しさん

2006/09/13(水) 12:24:08

日本語も読めないのに皮肉を言おうとするとこうなる。

0190デフォルトの名無しさん

2006/09/13(水) 12:54:37

uint8_tで何が不満なんだ? > byte_t

0191デフォルトの名無しさん

2006/09/13(水) 18:51:23

8bitとは限らないから…とか？

0192デフォルトの名無しさん

2006/09/13(水) 21:24:18

uint8_t i = 32;
std::cout << i;

とやって、32じゃなくて、空白が出力されたるの嫌やん

0193デフォルトの名無しさん

2006/09/13(水) 21:26:02

1byteを表すchar
文字を表すchar
双方を別々に定義すべきだという主張かと

0194デフォルトの名無しさん

2006/09/13(水) 21:38:12

C++ でせっかく char と signed char と unsigned char に分かれたのに、
なんで cout << で全部文字になっちまうんだ？

0195デフォルトの名無しさん

2006/09/13(水) 21:54:36

実際問題、符号ないほうが都合がいいから
文字としてuchar使ってるケースあるし、その辺との兼ね合いでね？

0196デフォルトの名無しさん

2006/09/14(木) 08:34:29

>193
そう。バイト単位のデータを表す型と文字を表す型が同一であることが、本気で文字列を
なんとかしようという意志の無さの表れではないかと
実体が wchar_t であろうと char であろうと、１文字を１文字として扱えるなら関心はないよね
文字列の仕様なんてたぶんこの先もふらふらするんだから、ある程度距離を取っておいた
方がいいと思うんだな
string と encode をセットで別個にライブラリとして定義してもらった方が個人的には嬉しい

0197デフォルトの名無しさん

2006/09/14(木) 08:52:47

>>196
文字列(というか文字)を何とかした結果が今の形 char だと思う。

>string と encode をセットで別個にライブラリとして定義してもらった方が個人的には嬉しい
ができる柔軟性も、char, wchar_tのおかげと思えば・・

0198デフォルトの名無しさん

2006/09/14(木) 22:37:48

char は C との互換性のために残しておく程度でいい
std::string と std::wstring 間にろくな互換性無いだろ？
これを柔軟性というのか？

0199デフォルトの名無しさん

2006/09/14(木) 23:06:50

>>198 そういう意味だったのか。

0200デフォルトの名無しさん

2006/09/15(金) 00:54:03

>>198
互換性って例えばどういうこと?

0201デフォルトの名無しさん

2006/09/15(金) 01:44:55

>>200 もう血が止まってるんだから、変にいじったりしないの！

0202デフォルトの名無しさん

2006/09/15(金) 09:11:21

おねがいします。

自分のファイル名(x.exe)を読み込んで
xの部分がAすなわちA.exeだったらaを実行して
xの部分がBすなわちB.exeだったらbを実行する
っていうようなCのプログラムを教えてください。

0203デフォルトの名無しさん

2006/09/15(金) 09:26:00

なんでまた C++0x スレに？
もしかしてマルチ？

0204デフォルトの名無しさん

2006/09/15(金) 09:34:41

マルチだね
どこだか忘れたが別スレで見た

>202
あっちのスレに答えが書いてあったぞ

0205デフォルトの名無しさん

2006/09/17(日) 00:49:06

C++0xだと既存のC++とは比べ物にならないほどスマートにかけるとかそういう例題なんじゃね？

たぶんそんなことはないだろうが

0206デフォルトの名無しさん

2006/09/17(日) 11:10:37

おじいさんは、裏山に畑を耕しに行ったんじゃない？

たぶんそんなことはないだろうが

0207デフォルトの名無しさん

2006/09/17(日) 15:01:57

いいレス思いついた、と思ったら
書き込む前にまず他人に通じるかどうか考えようぜ。

0208デフォルトの名無しさん

2006/09/17(日) 20:43:56

>>207
そりゃ無理だ。読む奴が基地外だったら、どんな書き方をしても通じない。
とにかく書きゃいいんだって。

0209デフォルトの名無しさん

2006/09/17(日) 23:24:34

書かれたものがキチガイだと
本当に誰にも通じないけどな。

0210デフォルトの名無しさん

2006/11/24(金) 14:31:34

N2133 06-0203
Editor's ReportPete Becker
2006-11-03
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2133.html

N2134 06-0204
Working Draft, Standard for Programming Language C++Pete Becker
2006-11-03N2009=06-0079
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf
新規色分け版

N2135 06-0205
Programming Languages －C++ Pete Becker
2006-11-06 N2134=06-0204
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf
色分けなし版

0211デフォルトの名無しさん

2006/11/24(金) 18:16:23

ちなみにADLのところ、3.4.2のルールが書き変わっています。

stringとchar_traitsのところも結構。
"文字"じゃなくてPODなら入れられる。

0212デフォルトの名無しさん

2006/11/24(金) 18:56:53

色の違いだったのね

0213デフォルトの名無しさん

2006/11/24(金) 22:19:20

論文リスト、ちらほら C++09 という記述が出始めたな

0214デフォルトの名無しさん

2006/11/24(金) 22:21:19

2009かあ。もうちょいペース上げてほしいなあ。
これじゃ本格的に使えるのは2010年代半ばになりそうだ。

0215デフォルトの名無しさん

2006/11/28(火) 23:58:39

Rvalue referenceって本当に規格にはいるのかね?
STLも仕様決め直しだし、それよりなにより、C++はマニア向けの言語になっちゃう…
Move semantics、あれば便利なのは確かなんだけど。

0216デフォルトの名無しさん

2006/11/29(水) 01:24:10

一番ほしいのはTemplate aliasesかな

0217デフォルトの名無しさん

2006/11/29(水) 01:31:43

>215
標準ライブラリに対する rvalue reference の導入は
下位互換を完全に意識した設計が提案されているので
＞STLも仕様決め直しだし、
という見方は少し違うような気がします．
std::auto_ptr などは deprecated なだけで廃止されるわけでもないですし．

というよりか，現在の標準ライブラリにおける rvalue reference 対応の提案は，
(いつものことですが) 下位互換の維持のために非常に設計が汚い印象があります．
move に対応していない場合 copy に fallback する設計は，
たとえば例外送出時のときなどの仕様と動作が極めて煩雑になるのではないか，
など個人的には不満も多いです．
(この汚さは標準ライブラリにおける rvalue reference 対応がもたらす汚さで，
言語仕様として導入される rvalue reference の仕様とは独立です)

言語仕様としての rvalue reference は， move semantics の導入と同時に，
the forwarding problem と呼ばれる非常に重要な問題を同時解決しますし，
(この問題の解決も見た目に比してインパクトが極めて大きいと思います)
『便利』程度の恩恵ではなく『マニア向け』の機能でもないと思います．

今現在，そもそも rvalue reference / move semantics 自体が机上の空論ですから，
これについて今何を語っても "almost as much of a hoax as Artificial Intelligence"
でしかないですが，それを承知であえて， rvalue reference / move semantics は
OOP・汎用プログラミング・関数プログラミング・効率・リソース管理・例外安全性
スレッド安全性など，ほぼあらゆるプログラミングパラダイム・概念の全域，
あと特にこれらの概念が交錯する領域での貢献が極めて大きい，
C++0x における (C++98 以来) 最大の進化だと主張したいです．

0218デフォルトの名無しさん

2006/11/29(水) 01:42:23

とマニアが言っております

0219デフォルトの名無しさん

2006/11/29(水) 01:48:06

いっそのこと名前空間std0xに新しいライブラリを作って、名前空間stdごと非推奨にしてしまえ。

0220デフォルトの名無しさん

2006/11/29(水) 12:59:00

>>219
明暗！

0221デフォルトの名無しさん

2006/11/29(水) 16:09:12

言い得て妙な変換だなｗ

0222デフォルトの名無しさん

2006/11/29(水) 17:42:23

namespace std0x
{
using namespace std;
}

0223デフォルトの名無しさん

2006/11/30(木) 08:53:29

namespace std0x = std;

0224デフォルトの名無しさん

2006/11/30(木) 13:36:58

もうここはあれだ、Andrei Alexandrescu あたりに超変態的 template
テストケース書いてもらってさ、これにパスしないと C++0x 準拠とは
名乗らせないってのはどうよ。
もうさ、これまでみたいなコンパイラ毎の ifdef 分岐の嵐はさすがにもう
勘弁して暮れって感じ

0225デフォルトの名無しさん

2006/11/30(木) 13:50:21

>>224
テストケースには boost 使えばいいんじゃねーの。
mpl ができてから、それ使ってコーディングした部品も増えてるし。

0226デフォルトの名無しさん

2006/11/30(木) 14:41:25

>>224
Discriminated Unions みたいに変態的すぎて
すべてのコンパイラでコンパイルが通らないなんて
ことになりそうだなｗ

0227デフォルトの名無しさん

2006/11/30(木) 16:22:54

BOOST_FOREACHは実際そうなので
それぞれのコンパイラのバグでエミュレートしている
恐ろしい

0228デフォルトの名無しさん

2006/11/30(木) 16:52:46

"D&E"もC++0xに合わせて更新してくれ。
"Inside the C++ Object Model"でもいいけど、やつは既にC#の一味か…

0229デフォルトの名無しさん

2006/11/30(木) 20:58:15

>>217
その熱い主張に興味がわいてきた。
rvalue ref.とmove semanticsがどういうものか、もう少し語ってはくれまいか。

0230デフォルトの名無しさん

2006/11/30(木) 23:42:40

>>217
Cryoliteたん？

0231デフォルトの名無しさん

2006/12/05(火) 21:36:18

>>215です。

>>217さんのおっしゃることには技術的に白黒の付く部分については同意です。
けど、やっぱりそうなるとC++はどんどんマイナー言語になっていくと思います。
じゃあ拡張しなければいいのかというとそういうわけでもないんですが…
C++の前に萌えた言語(システム)がCLOSである私としては切ない気持ちです。> マイナー化

0232デフォルトの名無しさん

2006/12/05(火) 22:07:30

rvalue referenceってなんなのさ？

0233デフォルトの名無しさん

2006/12/05(火) 22:37:14

ここで。

A Brief Introduction to Rvalue References
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html

0234デフォルトの名無しさん

2006/12/05(火) 22:49:58

>>233
よく纏まっていてわかりやすいね。

0235デフォルトの名無しさん

2006/12/06(水) 09:50:22

auto_ptr とかホントは廃止したくてたまらないんだろうなあ＞委員会
とりあえず、Deleter 指定できる unique_ptr 使って std::move してね☆
とか言いつつ、Effective C++ で「shared_ptr 使え、以上」とか書かれそう

0236デフォルトの名無しさん

2006/12/06(水) 12:13:53

>>235
一度、標準に採用されたらベンダーの独自拡張じゃないから安心して使ってねっていう
意味を暗に含むから非推奨にはなっても廃止はまずありえんだろうな。

0237デフォルトの名無しさん

2006/12/07(木) 04:52:50

ていうか、その非推奨じたいをC++はもっとガンガンやるべき。
そこら辺のGURUな人々に無茶苦茶やらせるより先に
標準もっと仕事しやがれこんちくしょー、みたいな。

ストラスストラップのハゲの残り少ない髪の毛引き抜いて
クローンハゲを量産して、規格の策定に充てるとかすればいいんじゃないのかと思った。

0238デフォルトの名無しさん

2006/12/08(金) 18:26:39

その前にrvalue referenceが導入されるのか？って感じだが
かなり大部分のライブラリに変更が必要になるし

0239デフォルトの名無しさん

2006/12/09(土) 01:08:57

ここで>>217に戻る。

0240デフォルトの名無しさん

2006/12/09(土) 01:15:54

まあ導入されれば便利にはなるんだけどね。
便利なだけじゃなくパフォーマンスゲインも5倍以上になるし

0241デフォルトの名無しさん

2006/12/09(土) 05:11:42

>パフォーマンスゲインも5倍

なにその機動戦士ガンダム

0242デフォルトの名無しさん

2006/12/09(土) 09:13:34

こいつをお前のC++コンパイラに取り付けろ。
すごいぞぉ。
コンパイラの性能は5倍以上跳ね上がる。

0243デフォルトの名無しさん

2006/12/09(土) 12:42:51

コンパイル時間も5倍に…

0244デフォルトの名無しさん

2006/12/09(土) 12:56:47

>>243
そのコンパイラをコンパイルするときに５倍コンパイラを使えばへっちゃらですよ

0245デフォルトの名無しさん

2006/12/09(土) 16:56:31

父さん、言語拡張症にかかって…

0246デフォルトの名無しさん

2006/12/09(土) 22:35:18

これからは言語のモジュール化ですよ。

0247デフォルトの名無しさん

2006/12/10(日) 07:07:20

>>244
おまえマジで頭いいな
じゃあそのコンパイラをそのコンパイラでコンパイル
したらさらに5倍早くなるんじゃね？

0248デフォルトの名無しさん

2006/12/10(日) 08:50:22

>>247
お前マジ天才じゃね？

0249デフォルトの名無しさん

2006/12/10(日) 10:16:27

最終的には今日コンパイルすると昨日完了するようになる

0250デフォルトの名無しさん

2006/12/10(日) 10:20:32

そのコンパイラでコンパイラをコンパイルさせてください。

0251デフォルトの名無しさん

2006/12/10(日) 10:53:35

おまいらホント暇だなｗ

0252デフォルトの名無しさん

2006/12/10(日) 17:55:34

最新のドラフトに static_assert っていうキーワードがあったんだけど、
キーワード増えるのってこれだけかな？

0253デフォルトの名無しさん

2006/12/10(日) 19:57:26

ドラフトレベルならもっとがっつりあるぞ。
コンセプトだけでも concept,concept_map,where,axiom,late_check
他にも alignof とか decltype とか constexpr とか

0254デフォルトの名無しさん

2006/12/10(日) 20:04:18

autoはC++09に確実に入るんじゃないのかな?

0255デフォルトの名無しさん

2006/12/10(日) 20:17:08

標準委員会、キーワード追加症にかかって…

0256デフォルトの名無しさん

2006/12/10(日) 20:22:14

>>254 それはずっと前からキーワード。

0257デフォルトの名無しさん

2006/12/10(日) 20:56:19

意味が変更される予約語はautoだけかな

0258デフォルトの名無しさん

2006/12/14(木) 13:27:42

しかしautoはどうかと思う…
型の弱い言語みたいだ

0259デフォルトの名無しさん

2006/12/14(木) 13:32:51

初期化される時点で型が決まってしまうのに、どこが弱いんだか。

0260デフォルトの名無しさん

2006/12/14(木) 14:11:35

コンパイル時に型が決定するのだから、弱いわけがないわな。

0261デフォルトの名無しさん

2006/12/14(木) 14:17:45

しかしtemplate引数の省略はどうかと思う・・・
型の弱い言語みたいだ

0262デフォルトの名無しさん

2006/12/14(木) 14:19:49

しかしboost.Anyが実装できるのはどうかと思う。
型の弱（ｒｙ

0263デフォルトの名無しさん

2006/12/14(木) 19:08:59

キャス(ry

0264デフォルトの名無しさん

2006/12/14(木) 20:18:58

vo(ry

0265デフォルトの名無しさん

2006/12/14(木) 20:29:55

悲しいかな、reinterpret_castやvoid*などの存在で、
C++が弱い型付けと分類されていることを見かける。

0266デフォルトの名無しさん

2006/12/14(木) 20:44:04

まあ強い型付けされるとキーボードも痛みやすいからな…弱くていいんじゃないの

0267デフォルトの名無しさん

2006/12/14(木) 21:48:36

その理屈だと、アセンブラは弱い肩か？

0268デフォルトの名無しさん

2006/12/14(木) 23:04:19

アセンブラは弱すぎ。虚弱体質だな。

0269デフォルトの名無しさん

2006/12/14(木) 23:12:43

低級言語は型とかないだろ

0270デフォルトの名無しさん

2006/12/14(木) 23:31:02

>>265
まさにカタ無しだね

0271デフォルトの名無しさん

2006/12/15(金) 00:04:48

しかしこのスレの流れはどうかと思う。
頭の弱い……

0272デフォルトの名無しさん

2006/12/21(木) 11:30:13

JIS X3014:2003って、
ISO/IEC 14882:2003の逐語訳じゃないんですね。
省略されているところがあってびっくりしました。

13.3.1.2.3のnon-memberのところ。

0273デフォルトの名無しさん

2007/01/03(水) 19:15:16

>>272
JISチームのチョンボで抜けちゃったとかじゃなくて？
そういえば、JIS X3014:2003 って買った時期によってPDFの"しおり"があったりなかったり
するらしいね。なんか以前、cppll で金返せ的なことを愚痴ってたヤツがいた。

0274デフォルトの名無しさん

2007/01/12(金) 19:40:21

シンボルの undef とこっから先 const の機能がほしい
スレ違いか？

0275デフォルトの名無しさん

2007/01/12(金) 20:41:03

シンボルの undef というか、スコープ付の define がほしい。

ここから先 const はいらんなあ。値を変えるところと変えないところで
関数が分かれてないのは設計ミスだと思う。

0276デフォルトの名無しさん

2007/01/12(金) 22:21:49

派生の禁止はできるようにならんの？

0277デフォルトの名無しさん

2007/01/12(金) 22:29:27

ttp://article.gmane.org/gmane.comp.lib.boost.devel/101260

0278デフォルトの名無しさん

2007/01/12(金) 23:23:42

あーなるほどね、宣言は出来るけどインスタンスは作れない、と。

0279デフォルトの名無しさん

2007/01/12(金) 23:29:21

>>273
>JISチームのチョンボ
まことしやかにささやかれてるけど真実味あるなｗ

0280デフォルトの名無しさん

2007/01/13(土) 03:24:39

>>276
あと、派遣の禁止も欲しいよなぁ。

0281デフォルトの名無しさん

2007/01/13(土) 23:29:46

>>277
古い。illegal

noninheritableがどっかにあったな

0282デフォルトの名無しさん

2007/01/13(土) 23:44:57

boostはなんでこのての接頭辞が non なんだろう。 not や um だとなにがまずいんだろう。

0283デフォルトの名無しさん

2007/01/13(土) 23:47:38

-ableにnotは不味いだろ。

0284デフォルトの名無しさん

2007/01/13(土) 23:50:06

>>283
ttp://msdn2.microsoft.com/ja-jp/library/h278d2d4(VS.80).aspx

0285デフォルトの名無しさん

2007/01/13(土) 23:51:08

>>282
英語的にはunが正しい。
何故nonになっているのかは不明

0286デフォルトの名無しさん

2007/01/13(土) 23:56:44

im と un を混同したのではないか

0287デフォルトの名無しさん

2007/01/14(日) 08:33:30

Boostスレかどこかで非英語圏向けにあえてnon-にしていると聞いたことがある。

0288デフォルトの名無しさん

2007/01/14(日) 17:09:42

それは俺の戯言なので真に受けないように

0289デフォルトの名無しさん

2007/01/14(日) 22:53:43

Effectice C++ 3版でも突っ込まれてたような

0290デフォルトの名無しさん

2007/01/26(金) 20:55:16

http://en.wikipedia.org/wiki/C%2B%2B0x
右辺値参照についてここでは一言も触れていないけど、C++0xに入るんだよね？

0291デフォルトの名無しさん

2007/01/27(土) 09:21:41

未定

0292wankuma

2007/01/27(土) 19:20:53

わんくま加盟求む
http://blogs.wankuma.com/

0293デフォルトの名無しさん

2007/02/19(月) 19:49:16

ttp://herbsutter.spaces.live.com/Blog/cns!2D4327CC297151BB!159.entry
>we finish the document in 2009, but because ISO takes most of
>a year to approve and publish a standard, it would end up as
>"C++10" (or, one could uncomfortably imagine, "C++0a").

0294デフォルトの名無しさん

2007/02/19(月) 20:04:02

もうC++0fでいいよ。

0295デフォルトの名無しさん

2007/02/20(火) 03:31:04

どうせVC7.1であと10年がんばるんですよ

0296デフォルトの名無しさん

2007/02/20(火) 08:41:21

>>295
スレ違い。

0297デフォルトの名無しさん

2007/02/20(火) 12:48:39

>>157

0298デフォルトの名無しさん

2007/03/03(土) 09:39:19

vector<int> v;
auto var = v.begin();

と型推論？ぽい事ができる様になるらしいですが、
この時のvarの型は
vector<int>::iterator
になるんでしょうか　それとも
vector<int>::const_iterator?

0299デフォルトの名無しさん

2007/03/03(土) 10:30:49

前者でないと困る。
前者なら、後者はauto const varという宣言で済むと思うが。

0300デフォルトの名無しさん

2007/03/03(土) 10:34:50

そうすると、vector<int>::const_iteratorではなくて、
cont vector<int>::iteratorになりそうな

0301デフォルトの名無しさん

2007/03/03(土) 11:14:10

const_付きのが欲しかったらboost::refと似たようなものを
コンテナ側に被せればいいのかな。

0302デフォルトの名無しさん

2007/03/03(土) 11:19:20

ああboost::cref使えば良さそうな気がする

0303デフォルトの名無しさん

2007/03/03(土) 11:20:36

vector<int> v;
auto var = const_cast<const vector<int>&>(v).begin();
これでいいでしょ？

0304デフォルトの名無しさん

2007/03/03(土) 11:24:56

vをconstにしたいって話でcref？

0305デフォルトの名無しさん

2007/03/03(土) 11:27:11

>>303
それやるならstatic_castだろ。

型名書くのがめんどくさい場合はcrefじゃね？

0306デフォルトの名無しさん

2007/03/03(土) 11:28:58

C++0xを知らんけど
そんなことしてまでauto使う意味わかんね。

0307デフォルトの名無しさん

2007/03/03(土) 11:31:24

どっちかっていうと
そんなことまでしてconst_iteratorにする意味わかんね。

0308デフォルトの名無しさん

2007/03/03(土) 11:48:48

こういう手もある。まあかえって長ったらしくなっているけど。
boost::range_const_iterator<decltype(v)>::type var = v.begin();

0309デフォルトの名無しさん

2007/03/03(土) 11:57:47

アホが来た

0310デフォルトの名無しさん

2007/03/03(土) 12:03:54

>>301
cbegin(), cend(), crbegin(), crend() がイイんじゃね？
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1674.pdf

最新のドラフトには載ってるから、採用されたのかな？

0311デフォルトの名無しさん

2007/03/03(土) 12:23:44

boost::cref (std::tr1::cref) では無理なのでは？

template< class T >
T const &as_const( T &x )
{ return x; }

とか作って使うのではダメなん？

0312デフォルトの名無しさん

2007/03/03(土) 13:02:44

#include <iostream>
#include <vector>
#include <tr1/functional>

using namespace std;

int main(void)
{
    vector<int> v(10);
    cout << typeid(v.begin()).name() << endl;
    cout << typeid(tr1::cref(v).get().begin()).name() << endl;
    return 0;
}

0313デフォルトの名無しさん

2007/03/03(土) 13:16:55

boostにconst_beginってなかったっけ？

0314デフォルトの名無しさん

2007/03/03(土) 13:20:02

こんにちは、rvalueの型をconst_iteratorにすべく、華麗なるタイプ速度を披露する皆様。

0315デフォルトの名無しさん

2007/03/03(土) 13:27:28

>>312
get() 使うなら当然できるけれど，それなら311で良いのでは？

0316デフォルトの名無しさん

2007/03/03(土) 19:12:34

v.begin()じゃなくて、begin(v)を使う派なのだが
（これだと、配列にもbegin(a)とか使えるし、crbegin(v)なんかもできる）
こんな人にも、autoは役に立つのかしらん？

0317デフォルトの名無しさん

2007/03/03(土) 20:28:01

auto v = v.begin() const;
みたいな呼び出しができたらいいのにと思った

0318デフォルトの名無しさん

2007/03/03(土) 20:38:02

const audo v = v.begin()
の方がいいかも！？と思った

0319デフォルトの名無しさん

2007/03/03(土) 22:25:17

>>318
>>300
流れよめんのか

0320デフォルトの名無しさん

2007/03/05(月) 08:00:08

const_付きのが欲しかったらboost::refと似たようなものを
コンテナ側に被せればいいのかな。

0321デフォルトの名無しさん

2007/03/05(月) 09:26:00

containerの場合は、>>310のcbegin()で、今のところwファイナルアンサーです。
出典は、http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1865.pdf

二バージョンないケースでは、何か工夫する必要があるね。

0322デフォルトの名無しさん

2007/03/05(月) 10:13:24

一文字の接頭辞が複数続くのってなんかいやん
crend とかなにって感じー

0323デフォルトの名無しさん

2007/03/07(水) 00:05:13

何だかんだで、const auto& cv(v);
してから、cv.begin(), cv.end() が一番読みやすいかも

0324デフォルトの名無しさん

2007/03/07(水) 16:48:34

数学の関数とかみたいに
コンパイル時に式自体
を計算・展開できるような式関数導入して欲しい。

0325デフォルトの名無しさん

2007/03/07(水) 18:43:00

実装も添えて提案して頂かないとイメージが沸かない

0326デフォルトの名無しさん

2007/03/07(水) 20:01:57

>>324

つまり
int a = 5+1;
は、コンパイラが
int a = 6;
としてコードを生成してくれるってことか。

inline int func(int x) { return x*2; }
int c = func(5);
をコンパイラが
int c = 10;
にしてくれるとか。

sinはコンパイラではなくコンパイル後に
リンクするライブラリにある処理だから難しいな。

LUTを作るの面倒だから判らなくもない。

0327デフォルトの名無しさん

2007/03/07(水) 20:07:41

今時のコンパイラならそのくらいは最適化の範囲内でやるだろ。

0328デフォルトの名無しさん

2007/03/07(水) 20:43:12

>>326
少なくとも 5+1 を 6 にするほうは、コンパイラは必ずやらなければならない(must)と
規定されている。インライン関数のほうもほとんどのコンパイラがやると思う。

0329デフォルトの名無しさん

2007/03/07(水) 23:01:37

がんばってtemplateでsinを実装するんだ(w

0330デフォルトの名無しさん

2007/03/07(水) 23:04:59

整数演算だけでか？ｗ

0331デフォルトの名無しさん

2007/03/07(水) 23:15:43

前に、どこかのスレで、nontype templateのメタプログラミングで、浮動小数点数を実装したという猛者がいた気がする。

0332デフォルトの名無しさん

2007/03/07(水) 23:26:01

コンパイル時変数と実行時変数を明示的に区別して定義できるようにならないかなあ。
いっそのことプログラムの実行そのものをコンパイル時と実行時で分けて、
コンパイル時実行ではインタプリタ型で動いて、コンパイル時変数にのみアクセス可能で
JavaScriptばりにクラスのメンバ関数の追加や削除、関数の構成、evalができて、とか。

0333デフォルトの名無しさん

2007/03/07(水) 23:29:13

D 言語でいいよ、もう。

0334324

2007/03/08(木) 00:03:20

同様にmy_cos,my_tanを作って
my_tan:=my_sin/my_cos;
という関係を作っておく。

my_sin(x)/my_cos(x)という式を使ったときは左記の関数はCallされずに
my_tan(x)がCallされて計算されるといった感じのもの。

//いいかげんなmy_sinの例
template <typename T> T my_sin(T x)
where Type(T,Re) //T：実数
{
calc{return x(1-x*x/6);}//計算値
expr(T a){my_sin(a);}//計算式
}

0335デフォルトの名無しさん

2007/03/08(木) 00:05:30

スクリプトでも使ってジェネレートした方がはやくね？

0336デフォルトの名無しさん

2007/03/08(木) 00:40:01

プリプロセッサ強化だな。

0337デフォルトの名無しさん

2007/03/08(木) 01:35:03

ttp://video.google.com/videoplay?docid=-1790714981047186825
コンセプト今まで知らなかったけれど、かなりよさそう。
コンパイル時間が気になるけれど。

0338デフォルトの名無しさん

2007/03/08(木) 09:01:29

templateの処理をプリプロセッサの役割とする
↓
Cでもtemplateできるようにする。

0339デフォルトの名無しさん

2007/03/08(木) 09:50:31

Cfrontみたいだな

0340デフォルトの名無しさん

2007/03/08(木) 11:46:16

もう終わった言語なんだから、なるべく互換性保持に努めてくれたまえ　

0341デフォルトの名無しさん

2007/03/08(木) 16:12:16

>>340
「バカヤロウ、まだ始まってもいねえよ。」

0342デフォルトの名無しさん

2007/03/08(木) 16:34:10

互換性はあるんじゃないか？今までのが非推奨になる感じで

0343デフォルトの名無しさん

2007/03/08(木) 16:35:46

old style cast とかどうするんだろ

0344デフォルトの名無しさん

2007/03/08(木) 18:25:58

>>324
再帰はできないわ，まともな制御構文はないわ，で良ければ一応
C++0x に向けて active に動いているっぽい提案
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2116.pdf
いずれにしろ，元々が traits などに使われるのを想定した提案ですので非力極まりない

もっと抜本的な提案なら
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1471.pdf
ですけれど，こちらは C++0x には間に合わない様子

0345デフォルトの名無しさん

2007/03/14(水) 20:34:06

C++0a になりそうな気配が濃厚になってまいりました

0346デフォルトの名無しさん

2007/03/15(木) 00:49:43

C++0x2010でいいからもう

0347デフォルトの名無しさん

2007/03/15(木) 23:22:40

それは勘弁してw

0348デフォルトの名無しさん

2007/03/16(金) 00:23:13

C+(+0x2010)
→ 0x201C
いや、わかっているよ、こう解釈されないことくらい。

0349デフォルトの名無しさん

2007/03/16(金) 15:02:28

>>346
8208www

0350デフォルトの名無しさん

2007/03/26(月) 18:39:26

C++2008

0351デフォルトの名無しさん

2007/03/28(水) 02:06:06

可変個引数テンプレート(Variadic Templates)だけど、template の specialization を使って一つづつ取り出していくだけかと思ったらなかなかすごいことになってるのね。

こんな展開が可能だったり、
---
template<typename...> struct Tuple {};
template<typename T1, typename T2> struct Pair {};

template<typename... Args1> struct zip {
  template<typename... Args2> struct with {
    typedef Tuple<Pair<Args1, Args2>...> type;
};
};

typedef zip<short, int>::with<unsigned short, unsigned>::type T1;　// T1 is Tuple<Pair<short, unsigned short>, Pair<int, unsigned> >
---

これで任意引数個の perfect forwarding function になったり(rvalue reference利用)
---
template<typename T>
struct allocator {
  template<typename... Args>
  void construct(T* ptr, Args&&... args) { new (ptr)(static cast<Args&&>(args)...); }
};
---

Variadic Templates の概要は↓がわかりやすい
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2080.pdf
↓は規格の変更点について
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2152.pdf
GCC 4.3 の experimental c++0x mode で、また ConceptGCC では >217 で机上の空論と書かれていた rvalue reference、さらに decltype とともに実装されたそうで。
http://conceptgcc.wordpress.com/2007/02/15/decltype-and-rvalue-references-and-variadic-templates-oh-my/
おまいらもヒトバシラーしてみませんか？

0352デフォルトの名無しさん

2007/03/28(水) 08:47:26

Variadic Templates、入るかねえ?

0353デフォルトの名無しさん

2007/04/01(日) 22:08:44

>352
何か具体的な懸念が？
提案者自身は
>Variadic templates seem to be moving smoothly,
と言ってるけどね。
ttp://conceptgcc.wordpress.com/2007/02/15/decltype-and-rvalue-references-and-variadic-templates-oh-my/#comment-131

0354デフォルトの名無しさん

2007/04/12(木) 07:04:47

http://www.devsource.com/article2/0,1895,2061095,00.asp
によれば、template aliases が入ることになっているなあ。嬉しい。

0355デフォルトの名無しさん

2007/04/16(月) 20:57:47

nameof(type) とか nameof(value) で型名のリテラルが取れたら便利だと思うんだけど
そういうのはないんかな

0356デフォルトの名無しさん

2007/04/16(月) 21:18:55

#define nameof(x) typeid(x).name()

0357デフォルトの名無しさん

2007/04/16(月) 21:21:15

typeid(hoge).name()があるでしょ。
マングルされてたりいろいろ面倒だけど。

0358デフォルトの名無しさん

2007/04/16(月) 22:08:34

typeid().name()は正直使えない

0359デフォルトの名無しさん

2007/04/16(月) 22:13:47

まあ保証されている事と言えば同一の型のname()も同一である
という事だけだからな
リフレクションのような事は正直無理

0360デフォルトの名無しさん

2007/04/27(金) 00:24:43

>352
ttp://conceptgcc.wordpress.com/2007/04/24/variadic-templates-are-in-c0x/
だそうな。

0361デフォルトの名無しさん

2007/04/27(金) 07:28:21

まじか。
機能的にはC++0xに入る必然性があるけれど、
さらにデバックしにくくなりそう…

variadic templatesを直接使う人じゃなくて、
variadic templatesが使われたlibraryを使う人ね。
エラーメッセージがさらにハナモゲラ化w

0362デフォルトの名無しさん

2007/04/27(金) 12:49:13

>>361
現状でも Boost.Function とか Boost.Variant とか
BOOST__PP_* で T0,T1,T2,... を生成してるやつは
エラーメッセージがハナモゲラ化してるわけで

その部分が T0... みたいに可変長ぽく省略表示されるだけで
だいぶ見やすくなると思うんだが

0363デフォルトの名無しさん

2007/05/14(月) 14:22:20

concept が入ればエラーメッセージはかなりましになるのでは？

0364デフォルトの名無しさん

2007/05/14(月) 14:24:15

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-05

0365デフォルトの名無しさん

2007/05/28(月) 01:09:30

ほ

0366デフォルトの名無しさん

2007/05/31(木) 00:47:25

とりあえずC99準拠で

0367デフォルトの名無しさん

2007/05/31(木) 01:59:00

C99はC++の精神に反しているのに
実装にはC++の機能が必要というトンデモ言語

0368デフォルトの名無しさん

2007/05/31(木) 03:13:42

C++の精神自体がトンデモの塊だから問題ない

0369デフォルトの名無しさん

2007/05/31(木) 06:35:41

Javaのキャストみたいなもんだな

0370デフォルトの名無しさん

2007/05/31(木) 06:43:51

c99にc++の機能が必要とは初耳だな。

0371デフォルトの名無しさん

2007/05/31(木) 06:56:08

コードに1000個のバイナリを埋め込む行為自体に問題があるとは思わないかね？

0372デフォルトの名無しさん

2007/05/31(木) 07:09:44

内容的には>>360 >>364で既出ですが、http://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]

0373デフォルトの名無しさん

2007/05/31(木) 16:54:12

へー、N2249入るかもしれないんだ。
とうとうC++の世界でも明示的にユニコード文字列が扱えるようになるのか。

0374デフォルトの名無しさん

2007/05/31(木) 17:46:31

すると現実の実装では、事実上wchar_tがchar16_tまたはchar32_tと同じ大きさを持つ型
（当然整数型とwchar_tのようにtypedefではない）という扱いになるんだろうなと思う。

0375デフォルトの名無しさん

2007/05/31(木) 19:57:46

これですな
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2249.html

そのうちstd::u16stringとかstd::u32stringとかもできるんだろか

0376373

2007/06/01(金) 00:57:02

入るかもしれないじゃないや。もう最新のドラフトに入ってるわ。

0377デフォルトの名無しさん

2007/06/01(金) 01:12:11

L"文字列" はどういう扱いになるん？

0378デフォルトの名無しさん

2007/06/01(金) 01:36:05

こんな感じかな？

wchar_t wc = L'あ';　// wcの値は実装依存 (今と同じ)
char16_t c16 = u'あ';　// c16は0x3042
char32_t c32 = U'あ';　// c32は0x00003042

0379デフォルトの名無しさん

2007/06/01(金) 01:39:40

UTF-8 は使えないの？
UTF-16BE と UTF-16LE （32も）の選択は環境依存？

0380デフォルトの名無しさん

2007/06/01(金) 01:40:47

あ、BE と LE はこのレベルでは関係ないか？
実用上面倒くさい事になりそうな気はするが。

0381デフォルトの名無しさん

2007/06/01(金) 01:44:07

UTF-8の型も用意するか、逆にUTF-32だけにするか
してほしい気もする

0382デフォルトの名無しさん

2007/06/01(金) 08:22:04

>>379
UTF-8は、
・ソースコードで使って、処理系が変換。例えばU'A'などを。(規格外)
・今後Unicode系mbsライブラリが充実させる。
って感じなんじゃないの?

0383デフォルトの名無しさん

2007/06/01(金) 08:22:49

>>376
もう規格の外に出ることはないでしょ。修正が入るだけで。

0384デフォルトの名無しさん

2007/06/01(金) 08:35:43

下地になったCのn1040には、utf-8はchar型を使ってどうのこうのって
書いてあるけど、charはビット数を保証してないよなあ

0385デフォルトの名無しさん

2007/06/01(金) 09:07:21

uint8_tと読み直せばいいんじゃない。

0386デフォルトの名無しさん

2007/06/01(金) 09:09:30

uint8_t って optional だったよね。

0387デフォルトの名無しさん

2007/06/01(金) 13:30:21

何年か経ったらwchar_tはいらない子扱いされてそうだ

0388デフォルトの名無しさん

2007/06/01(金) 15:19:52

tcharでいいじゃん

0389デフォルトの名無しさん

2007/06/01(金) 16:02:57

>>387
Unicode依存コードじゃなければ、wchar_t推奨でしょ。
>>384
char8_tのドラフトを書けw

0390デフォルトの名無しさん

2007/06/01(金) 16:43:08

>>386
つuint_least8_t
ちなみにchar16/32_tはそれぞれuint_least16/32_tと同じ大きさと規定される>>375

0391デフォルトの名無しさん

2007/06/01(金) 17:00:04

どうせウニコードなんか窓しか使わないのにイラネ

0392デフォルトの名無しさん

2007/06/01(金) 17:05:18

>>389
何年か経ってもUnicodeでないOSが残ってるかどうかｗ

0393デフォルトの名無しさん

2007/06/01(金) 17:14:12

LinuxもUTF-8なご時世になんて寝言を……

0394デフォルトの名無しさん

2007/06/01(金) 17:43:00

ふつーにEUC

0395デフォルトの名無しさん

2007/06/01(金) 18:46:06

Unicode関連のロケールが標準に入ると考えていいんだろうか・・

0396デフォルトの名無しさん

2007/06/01(金) 20:20:04

CHAR_BIT >= 8 だから、UTF-8 は char を使ったんで別にいいんでない？

0397デフォルトの名無しさん

2007/06/01(金) 20:53:50

8は保証されてるの？

0398デフォルトの名無しさん

2007/06/01(金) 21:14:54

下限が 8 なのは保証されている。
別に 9 だろうが 16 だろうが問題ないが、7 とかはない。

0399デフォルトの名無しさん

2007/06/02(土) 11:33:29

世の中のプログラマのほとんどが

>どうせウニコードなんか窓しか使わないのにイラネ

と思っていたはずなのに

>LinuxもUTF-8なご時世になんて寝言を……

になってしまったのはいつから？なぜ？

0400デフォルトの名無しさん

2007/06/02(土) 11:43:17

>>399
いつからかは知らんが、そうでもせんとまともな国際化対応できんだろうが。

0401デフォルトの名無しさん

2007/06/02(土) 11:44:01

そんなこと思ってもいませんでしたよ。
今も昔もUnicode onlyは早計すぎると思っているだけ。

なんだかんだ言ってもUnicode周辺には、
"Technical Notes", "Technical Reports"その他に、
ノウハウがたまってきているので、強力にサポートすべき。

wchar_tの実装をUnicode onlyにするなんてのには大反対。
n2249はGJ。

0402デフォルトの名無しさん

2007/06/02(土) 11:55:15

じゃぁ、wchar_t はTRON用ということでおｋ？

0403デフォルトの名無しさん

2007/06/02(土) 12:29:48

TRONはwwchar_tです。

0404デフォルトの名無しさん

2007/06/02(土) 13:10:56

でも、Windows は UTF-16 なんだよな？

0405デフォルトの名無しさん

2007/06/02(土) 13:31:23

>>404
Windows のは WCHAR であってその実装は wchar_t とは限らず unsigned short int の場合なんかもある。

0406デフォルトの名無しさん

2007/06/02(土) 13:41:47

どちらにしろ UTF-16 だろ？

0407デフォルトの名無しさん

2007/06/02(土) 15:39:01

つWM_UNICHAR
http://msdn2.microsoft.com/en-us/library/ms646288.aspx

0408デフォルトの名無しさん

2007/06/02(土) 18:51:20

char(16|32)_t用の関連関数のドラフトはc++0xに間に合うのかねえ。
is系とかprintfとかfacetとか、結構ありそうだが。

0409デフォルトの名無しさん

2007/06/02(土) 19:15:39

C95みたいに後から追補出せばいいよ

0410デフォルトの名無しさん

2007/06/02(土) 19:44:42

streamやfacetsは対応しないみたい
ttp://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2238.html

あとUTF-8の案もあった
今のところWDには含められていないけど
ttp://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2209.html

プリフィックスは E で、1バイト8ビット以上を保証すると

0411デフォルトの名無しさん

2007/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圏の人にとっちゃそうかもしれんけどさ。

0412デフォルトの名無しさん

2007/06/02(土) 22:39:06

まあその辺はゆっくりやって、後から補完でいいんじゃないの?
Primitive typeとして導入されたわけだから、
いろいろ実装してみるための最低限のことは決まるわけだからさ。
typedefやマクロに比べて出きることが多すぎるから、慎重になるんでしょ。

0413デフォルトの名無しさん

2007/06/02(土) 22:59:52

Windows が UTF-16 だし、
デフォで UTF-16 が扱えるなら
そういう意味であちらさんにも価値はあるように思うんだけどな。

0414デフォルトの名無しさん

2007/06/02(土) 23:14:12

WCHARあるからねー

0415デフォルトの名無しさん

2007/06/03(日) 00:28:53

>>413
意味が分からない。
どれに対するレス?

0416デフォルトの名無しさん

2007/06/03(日) 00:29:10

Windowsなんかうんこ

0417デフォルトの名無しさん

2007/06/03(日) 00:29:51

>>415
>>411

0418デフォルトの名無しさん

2007/06/03(日) 00:35:57

char16_tやchar32_tのストリームを実装するとしたら
現状のワイド文字ストリームのようにマルチバイトに／へ変換するようなもんだと思ったんだが

0419デフォルトの名無しさん

2007/06/03(日) 00:35:59

それはWindowsにはニュートラルな話。

0420デフォルトの名無しさん

2007/06/03(日) 00:37:38

Windowsとか持ち出してるのはただの馬鹿だろ

0421デフォルトの名無しさん

2007/06/03(日) 00:46:50

>>418
wifstream, wcin辺りができたばかりだし、
char16_tなら、ほとんどの処理系は(sizeof(wchar_t)>2だろうから )codecvtでなんとかなるし、
char16ifstreamとかchar16cinとか乱発する前に、ちょっと考えてみるだけでしょ。
急いで、うんこライブラリを標準に入れるわけにいかないし。

0422デフォルトの名無しさん

2007/06/03(日) 00:56:23

GCC だと wchar_t は 4 だったな。

0423デフォルトの名無しさん

2007/06/03(日) 01:00:45

>>422
現在ではプラットフォーム依存。たとえば Cygwin の wchar_t は2バイト。
あと、-fshort-wchar なんてオプションもあるので、gccだからという判定は危険。

0424デフォルトの名無しさん

2007/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).

0425デフォルトの名無しさん

2007/06/03(日) 01:32:30

なるほど。その環境で扱える最大の文字セットも格納できる事が必要なんだ。

0426デフォルトの名無しさん

2007/06/03(日) 02:03:02

wchar_tがUnicodeじゃない処理系ってあるのかな？

0427デフォルトの名無しさん

2007/06/03(日) 02:10:30

>>426
*BSDやSolarisのi18nフレームワークがそうなんじゃないの?

0428デフォルトの名無しさん

2007/06/03(日) 04:26:58

GCC 4.3にC++0xの実験的サポート
http://gcc.gnu.org/gcc-4.3/cxx0x_status.html

0429デフォルトの名無しさん

2007/06/03(日) 04:55:14

>>428
ﾜｸﾜｸﾃｶﾃｶしつつDLしてregexを見てみた。

@todo Implement this function.
@todo Document this function.
だらけだった。

0430デフォルトの名無しさん

2007/06/03(日) 05:36:10

w

0431デフォルトの名無しさん

2007/06/04(月) 22:53:08

MSも試験実装すればいいのに。
Cの_s系関数はフライングで取り入れたんだから。

0432デフォルトの名無しさん

2007/06/05(火) 01:37:14

C#.NET以外は捨てなんだろう
C++/CLIは後方互換性だけなんだろうし。

0433デフォルトの名無しさん

2007/06/05(火) 22:01:36

久しぶりにスレ伸びたな～

0434デフォルトの名無しさん

2007/06/05(火) 23:26:19

まあ全部俺の一人芝居なんだけどな

0435デフォルトの名無しさん

2007/06/06(水) 01:57:38

同感

0436デフォルトの名無しさん

2007/06/06(水) 10:51:13

全部俺の独り芝居だったら同感って思う必要も無かったかな、とちょっと反省してみた。

0437デフォルトの名無しさん

2007/06/06(水) 12:41:13

それがまさに独り芝居というものでは？

0438デフォルトの名無しさん

2007/06/06(水) 13:20:54

自問自答++

0439デフォルトの名無しさん

2007/06/06(水) 14:47:48

そうか、僕はここにいてもいいんだ！

0440デフォルトの名無しさん

2007/06/06(水) 16:22:24

おめでとう

0441デフォルトの名無しさん

2007/06/06(水) 16:54:37

>>431-432
まあでもC++0xに全く無関心でない様子は伺える
http://blogs.msdn.com/vcblog/archive/2007/06/04/update-on-the-c-0x-language-standard.aspx

0442デフォルトの名無しさん

2007/06/06(水) 17:40:42

そりゃSC22/WG21の中の人たちがやっているからなあ。
VC++はC++/CLIオンリーじゃないし。

0443デフォルトの名無しさん

2007/06/06(水) 17:56:40

struct S {

　　int m;
};

sizeof(S::m)

これが規格外だったなんて知らなかった。
そういえばこれは合法になるのかな？

template < typename T >
class Foo
{
　　friend T ;
}

0444デフォルトの名無しさん

2007/06/06(水) 18:38:36

>>443
nondirivableかなんかで話題にあがったが、確か違法だったと思う

0445デフォルトの名無しさん

2007/06/06(水) 18:48:08

いや、C++0xではどうなるかという話なんだけど。

0446デフォルトの名無しさん

2007/06/06(水) 22:03:04

friend のはこれ？ (PDF)

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1791.pdf

0447デフォルトの名無しさん

2007/06/07(木) 03:54:58

443の上は通らないけど下が普通に通る…
マジ意味不明
しかもなまじ役に立ちそうなのが一層もどかしさを増幅させる

0448デフォルトの名無しさん

2007/06/07(木) 05:25:03

sizeof(S().m)みたいに一時インスタンス化すればおｋ？

0449デフォルトの名無しさん

2007/06/08(金) 12:09:52

OKでしょ。

0450デフォルトの名無しさん

2007/06/17(日) 22:03:19

ところで、wchar_tとい不細工なネーミングは、
どうにかならんのかね。
short charとか、long charとかの方が自然だ
ろうし、文法上追加の余地はあるだろうに。

0451デフォルトの名無しさん

2007/06/17(日) 22:07:28

いっそUnicode str;を入れようぜ

0452デフォルトの名無しさん

2007/06/17(日) 22:57:31

>>450
少なくとも極自然なネーミングなんだがね。
これが極自然なネーミングだとお前が思えないなら
それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。

0453デフォルトの名無しさん

2007/06/17(日) 22:58:22

>>451
そんな既存のソースコードと衝突しそうな新しい予約語は却下

0454デフォルトの名無しさん

2007/06/17(日) 23:00:08

じゃ、_Unicode str;

えーい、いっそのことソースコードもUTF8強制して

文字 str = L"こんちには世界";

って書けるようにしようぜ？

0455デフォルトの名無しさん

2007/06/17(日) 23:23:48

まあでも始めからCにワイド文字型が組込型として存在したら、
単にwcharという名前になっていたとは思う

0456デフォルトの名無しさん

2007/06/17(日) 23:30:08

>>455
俺はむしろいっそのこと、int_t, double_t, char_t てなネーミングで
統一されてたほうがよかったんじゃねぇかとすら思うけどなぁ。

0457デフォルトの名無しさん

2007/06/17(日) 23:34:21

ワイドな文字ってよく考えると意味不明だよね

0458デフォルトの名無しさん

2007/06/17(日) 23:37:11

仮にUnicode型があったとして、
UTF-16かUTF-32かはたまたUTF-8かなんてことが処理系定義になりそうだｗ

0459デフォルトの名無しさん

2007/06/17(日) 23:39:23

もうUTF8って名前に決めちゃえばいいよ

0460デフォルトの名無しさん

2007/06/18(月) 08:27:41

ちょっと上の話題ぐらい読もうや。

0461デフォルトの名無しさん

2007/06/18(月) 08:36:17

>>458
UTF-8はmbs、つまりchar[]だろ。

0462デフォルトの名無しさん

2007/06/18(月) 22:47:59

>>452
確かに、2Byte=WORDという意味でword char
をwcharとするなら、別に構わないが、wchat_tと
書くと、いかにも規格外で後からつけました感が
あって、気に入らんのだがねぇ。それより、
shortやlongといった元からあり、且つwordの様に
変数のサイズを2Byteとか具体的に意識させない型の方が、
自然な感じがするんだけどねぇ。

0463デフォルトの名無しさん

2007/06/18(月) 22:50:57

名前の衝突を避けるにはダサネーミングはある程度しかたない

_Boolとかunorderd_mapとかダサすぎるし

0464デフォルトの名無しさん

2007/06/18(月) 23:10:05

ライブラリならダサネーミングも仕方ないが、予約語としてはちょっと頂けないってことじゃね？
基本的には同感。（今さらしょうがないけど）

0465デフォルトの名無しさん

2007/06/18(月) 23:10:16

virtual void hogehoge() = 0
なんて文法を導入しちゃう言語に対していまさらだな・・・

0466デフォルトの名無しさん

2007/06/18(月) 23:25:01

>>462
wchar_tのwは、wideでは？

0467デフォルトの名無しさん

2007/06/18(月) 23:47:46

>>450のshort charとか、long charとかで思い出したけど、
昔、整数型のshort (int) - int - long (int)からの連想で、
浮動小数点数型も、short float - float - long floatにすれば良かったのにと考えたことがあった

0468デフォルトの名無しさん

2007/06/19(火) 00:32:15

そうすると、long floatの省略が不可能になる罠。
まあ、long doubleは今でも省略不可だけどサ。

0469デフォルトの名無しさん

2007/06/19(火) 01:35:30

>>464
C++では予約語だが、Cではそうではない。

0470デフォルトの名無しさん

2007/06/19(火) 01:41:38

_Bool は仕方がないとは思うが失笑したな。

0471デフォルトの名無しさん

2007/06/19(火) 02:37:05

wordが2バイト圏の人か
俺の国では2バイトはhalf wordなんだな

0472デフォルトの名無しさん

2007/06/19(火) 02:40:36

MASM 使ってたら word = 2 バイトで使ってしまうな。
科学計算やってると word = 8 バイト（double）なことも多いんだがな。

0473デフォルトの名無しさん

2007/06/19(火) 04:43:21

>>462
本当にモロ、
>それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。
で、ﾜﾛｽｗｗｗ

0474デフォルトの名無しさん

2007/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に合わせてそれぞれ拡張
するのはは厳しい気がするが。実装的に。

0475474

2007/06/19(火) 20:25:01

訂正

× >>464
○ >>473

自分を指して何やってんだが…。

0476474

2007/06/19(火) 20:29:41

また間違えた...。欝だ。
× >>462
○ >>473
病院でも行ってくる。

0477デフォルトの名無しさん

2007/06/19(火) 20:30:02

もともとobj-cはC++とは全然別物だろうに

0478デフォルトの名無しさん

2007/06/19(火) 22:43:01

>>474
なんかまだ少し勘違いしてそうだから、念のために書いておくと
必ずしも sizeof(wchar_t)==2 じゃないぞ。 sizeof(wchar_t)==4 な環境・処理系もある。

まぁ、あんまり気を落とすな。

0479デフォルトの名無しさん

2007/06/19(火) 22:58:22

gccがsizeof(wchar_t)==4でいいんだったっけ

0480デフォルトの名無しさん

2007/06/19(火) 23:51:09

-fshort_wchar フラグを指定したら 2 になるけどな。

0481デフォルトの名無しさん

2007/06/20(水) 02:58:24

>>474
C++/CLIは、WG21の中のマイクロソフトの人がどうするかにかかっていると思う。
しかし純然たる研究者だったはずの二人が、
どうしてC++/CLIに必死なのか良くワカランネ。
契約になんか書かれているのかな。

0482デフォルトの名無しさん

2007/06/20(水) 08:40:01

C++0x実現まであと9年もあるから大丈夫

0483デフォルトの名無しさん

2007/06/21(木) 22:32:37

>479
cygwin 上だと gcc でも 2。

0484デフォルトの名無しさん

2007/06/22(金) 01:24:22

今は亡き、Windows版CodeWarriorでもsizeof(wchar_t)==4。

亡くなって当然ｗ

0485デフォルトの名無しさん

2007/06/22(金) 01:24:48

>477
Objective-C++ という Obj-C の C++ 拡張が存在する
C++/CLI はどうせコンパイラの開発部分は共通だから強引に組み込むでしょ
直接ぶつかるところは少ないし、そもそも普及に至っては・・・

0486デフォルトの名無しさん

2007/06/22(金) 01:44:27

後半二行、何を言っているのかわからん。
「組み込む」対象は何なんだ?

0487デフォルトの名無しさん

2007/06/22(金) 22:10:11

え、VC の cl にだけど

0488デフォルトの名無しさん

2007/06/23(土) 10:46:35

マイクロソフトは規格への追従遅いじゃん。
メジャー番号が変わるまで延々放置って事がよくある。
スイッチで切り替えて、細心の規格に追従した動作になるってこともあまりない。

0489デフォルトの名無しさん

2007/06/24(日) 21:02:05

C++1xに名前変えるか

0490デフォルトの名無しさん

2007/06/25(月) 06:03:52

何でこんなに時間掛かるんだろう？

0491デフォルトの名無しさん

2007/06/25(月) 09:41:11

やっつけでやられても困る。

0492デフォルトの名無しさん

2007/06/25(月) 13:37:16

>>490
天才のお前が傍観者だからだよ

0493デフォルトの名無しさん

2007/06/25(月) 17:37:29

Javaの初期のクラスライブラリみたいな不細工なのは困る。
iostreamだって今になってみれば、設計し直したいところ多数。

0494デフォルトの名無しさん

2007/06/25(月) 19:56:26

>>474
ObjC++はコンパイラがC++のバージョン選べるようにしてくれるでしょ。

0495デフォルトの名無しさん

2007/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 の更新情報は
今回からこっちに貼ることにしました。

0496デフォルトの名無しさん

2007/06/26(火) 03:12:13

C++X
の方が魚の骨っぽくて好き

0497デフォルトの名無しさん

2007/06/26(火) 13:38:12

もう規格なんてやめてBoost全部取り込んじゃえよ

0498デフォルトの名無しさん

2007/06/26(火) 17:06:10

それは行き過ぎだろうけど、ライブラリをほかとは別規格にするというのはありだと思う

0499デフォルトの名無しさん

2007/06/26(火) 17:57:38

古い Fortran みたいにいくつかのレベルに分ければよかったのに、と
時々思うわけさね。

0500デフォルトの名無しさん

2007/06/26(火) 18:18:06

C++はPL/Iを超える化け物言語になりつつあるな。

0501デフォルトの名無しさん

2007/06/26(火) 22:21:29

Javaほどじゃないけどな

0502デフォルトの名無しさん

2007/06/26(火) 22:24:57

は？

0503デフォルトの名無しさん

2007/06/26(火) 22:31:00

またジャバグラマか。

0504デフォルトの名無しさん

2007/06/26(火) 23:26:45

そろそろミーティング回数増やさねえとヤヴァくね？
最近あんま進展ないし、また議論不足で vector<bool> とか auto_ptr みたいな
半端者が生まれちまうぜ

0505デフォルトの名無しさん

2007/06/26(火) 23:27:57

禿が死ぬまでには出来てると思うから気長に待つよ

0506デフォルトの名無しさん

2007/06/27(水) 03:44:26

なぁに禿が死んだら誰かが代わりに永久脱毛すればいい話

0507デフォルトの名無しさん

2007/06/27(水) 09:25:40

>500
あのALGOL系とCOBOLを無理矢理繋げたような変態言語と比べられても…

…いや、的確か

0508デフォルトの名無しさん

2007/06/27(水) 09:29:07

PL/Iを馬鹿にするなー
本当に何でもできる言語なんだぞー

あ、でも糞言語だったけどね
消えたし

0509デフォルトの名無しさん

2007/06/27(水) 09:58:55

他の言語は要らなくなるから、Programming Language/1。

0510デフォルトの名無しさん

2007/06/27(水) 10:33:28

その C++ と Objective-C を無理矢理繋げた変態言語の立場は。

0511デフォルトの名無しさん

2007/06/27(水) 22:21:53

お前ら頭良いんだからサッサと立派な規格でまとめてくれよ

0512デフォルトの名無しさん

2007/06/27(水) 22:24:43

よしきた

0513デフォルトの名無しさん

2007/06/27(水) 22:27:55

標準ヘッダファイル2chを追加

0514デフォルトの名無しさん

2007/06/27(水) 22:30:20

boostをはじめとするライブラリが整備されている今でこそC++は「使える」言語だと思えるんだけど
それらがあんまり無かった時代になんであんなに流行ったのかがいまいちよく分からない

0515デフォルトの名無しさん

2007/06/27(水) 22:33:48

競争相手が無かったから

0516デフォルトの名無しさん

2007/06/27(水) 23:05:19

C++がもしなかったらと考えると興味深い。
JavaやLL言語のようなものはあっただろうか？
LISPやSmalltalkの影響はもっと大きかっただろうか？

0517デフォルトの名無しさん

2007/06/27(水) 23:09:41

>JavaやLL言語のようなものはあっただろうか？

普通にあったんじゃない？

0518デフォルトの名無しさん

2007/06/27(水) 23:18:46

ねーよ。
C++の影響は計り知れない

0519デフォルトの名無しさん

2007/06/28(木) 01:15:28

cfront最終版の頃には、
Modula-3, Oberon, CLU, Argus, Effiel, Ada 9X, Delhpi, Smalltalkあたりが軒並死亡宣告。
NEXTSTEP, Display PostscriptのおかげでObjective-Cが生き残っている程度だった。

0520デフォルトの名無しさん

2007/06/28(木) 01:34:50

その言語大絶滅は何か原因はあるの？
//まあマイナー言語の生成消滅は常に起きてるだろうけど。

0521デフォルトの名無しさん

2007/06/28(木) 09:02:38

勝手に言ってるだけだろ。もともとニッチなのもいくつかあるし
死んでないのもいくつかあるし。
要はC++が広まりすぎて、他の言語が相対的に影が薄くなったって
ことだと思う。

0522デフォルトの名無しさん

2007/06/28(木) 09:09:11

C++とJavaは、プログラミング言語の研究者をしゃぶりつくしているけどな。
こんなに人材が集まったことは今だかつてないんじゃないか?
C++に関して言えば、マクロ(特殊化当たり前)由来のtemplateが決定打だったな。

0523デフォルトの名無しさん

2007/06/28(木) 12:08:12

C++ってマクロなんでしょ？

0524デフォルトの名無しさん

2007/06/28(木) 12:11:46

???

0525デフォルトの名無しさん

2007/06/28(木) 14:00:51

っ MFC

0526デフォルトの名無しさん

2007/06/28(木) 14:14:36

MFCとVC6は大量のC++挫折者を生み出しました

0527デフォルトの名無しさん

2007/06/28(木) 17:52:57

>>522
C++がひろがってたのはtemplate以前からだけどね。
TMPがはいって地獄がより強固になった。

0528デフォルトの名無しさん

2007/06/28(木) 20:02:22

シェア90%のOSが推奨すれば広まって当然

0529デフォルトの名無しさん

2007/06/28(木) 21:26:08

じゃあこれからはドトネト天国だね

0530デフォルトの名無しさん

2007/06/28(木) 21:38:39

C#する気もしない気も～VMの性能にかかっているんだよ～

0531デフォルトの名無しさん

2007/06/28(木) 22:21:08

C++は滅びぬ！何度でもよみがえるさ。
ネイティブコードの力こそ人類の夢だからだ

0532デフォルトの名無しさん

2007/06/28(木) 22:22:00

D が完成しさえすれば・・・。

0533デフォルトの名無しさん

2007/06/28(木) 22:50:37

ネイティブでGC無しというところが、
C++の強さにして弱み。

0534デフォルトの名無しさん

2007/06/28(木) 22:52:36

し、C++/CLIとかどうですか・・

0535デフォルトの名無しさん

2007/06/29(金) 00:03:58

Dもキメラ過ぎる

0536デフォルトの名無しさん

2007/06/29(金) 23:28:16

Dがもっとリッチに色々揃えば良いけど。

0537デフォルトの名無しさん

2007/06/29(金) 23:32:38

やっぱC++は最高だな

0538デフォルトの名無しさん

2007/06/30(土) 19:25:36

C++0xになったらどんなステキな世界が待っているんだろう。
アスペクト志向取り入れないかな

0539デフォルトの名無しさん

2007/06/30(土) 19:46:15

>533
でも委員会で GC の話してるみたいよ？

0540デフォルトの名無しさん

2007/06/30(土) 20:31:26

今のところHans Boehmの提案が最有力候補かな？

0541デフォルトの名無しさん

2007/06/30(土) 20:32:07

GC ねえ。
GC なしで組めるモードもあるんだよね？

0542デフォルトの名無しさん

2007/06/30(土) 21:19:39

C99に合わせたりはしないのかな。

0543デフォルトの名無しさん

2007/06/30(土) 21:37:25

>>541
＞GC なしで組めるモードもあるんだよね？
C++(0x)的にほぼ採用のための必須条件とおもわれ

0544デフォルトの名無しさん

2007/06/30(土) 22:30:57

>>542
だいたいのところは取り込まれてるみたい。

0545デフォルトの名無しさん

2007/07/01(日) 11:32:07

http://www.open-std.org/jtc1/sc22/wg21/
News 2007-06-30: The 2007-06-pre-Toronto mailing is available

0546デフォルトの名無しさん

2007/07/01(日) 11:33:18

>>543
えーーー！

いくらなんでもそれは無くね？

0547546

2007/07/01(日) 11:34:11

勘違いしてた

「GCなしでも組める」事が必須条件なのね

ごめんなさい

0548デフォルトの名無しさん

2007/07/01(日) 11:51:16

C++的には、使わなければ余分なコストはかからないというのは必須だろ。

0549デフォルトの名無しさん

2007/07/01(日) 11:53:34

そこでGCCですよ

0550デフォルトの名無しさん

2007/07/01(日) 11:57:17

GCを使うか使わないかを不具合無しで簡単に切り替えられるのがいい
例えばアロケータを差し替えるだけでとかそういうので

0551デフォルトの名無しさん

2007/07/01(日) 12:00:52

GC自体はあってもいいが破棄のコードが無いと対称性が崩れてキモチワルイな

0552デフォルトの名無しさん

2007/07/01(日) 12:02:25

>>551
現行の C++ でも delete はほとんど auto_ptr や shared_ptr 任せで
コードには無いだろ。

0553デフォルトの名無しさん

2007/07/01(日) 12:03:19

>>551
ではauto_ptrやshared_ptrについてどうお考えでしょうか？

0554デフォルトの名無しさん

2007/07/01(日) 12:05:59

shared_ptrとかは削除子指定できるからな
GCも同様に削除子が指定できれるならば生成子と対照が簡単に取れるから問題なし

0555デフォルトの名無しさん

2007/07/01(日) 12:07:50

なんだよかたそういう対照性か。
まさかソースコード上の対照性を言っているのかと思って心配になった。

0556デフォルトの名無しさん

2007/07/01(日) 12:11:55

>>554
メモリ管理専用にしないと GC によるメリットなんて得られないんじゃない？
削除子なんか入れたら実行タイミングに完全な規格を定義しないといけないでしょ。

0557556

2007/07/01(日) 12:16:45

うーんもうちょっと調べ物してから言えばよかったかな。
あんまりはっきりしたこともいえないんで、スルー推奨。

0558デフォルトの名無しさん

2007/07/01(日) 12:17:46

超基本的な質問なんだけど

GCありの場合でも自動変数がスコープ抜けた時とかにデストラクタは呼ばれるの？
その場合、そのクラスがフリーストアへのポインタを持っていた場合、
クラスのインスタンス自体は破棄されるけど、参照されていたメモリは
GCの場合はすぐに回収されないってことになるの？

0559デフォルトの名無しさん

2007/07/01(日) 12:21:51

GCってオンオフするもんなの？
当方C++/CLIのイメージが強いもんで、C++0xでどうなるのかわからないんだけどさ。
^とgcnewみたいなものじゃまずいのかなぁ。

0560デフォルトの名無しさん

2007/07/01(日) 12:38:43

すみません
int a[] = new int[10];
int *b = new int[10];
みたいに確保したときって
delete a;
delete a[];
delete b;
delete b[];
それぞれ解放の仕方で動作おかしくなりますか？

0561デフォルトの名無しさん

2007/07/01(日) 12:45:19

>>560 スレ違い。こっち逝け→ http://pc11.2ch.net/test/read.cgi/tech/1182740506/

0562デフォルトの名無しさん

2007/07/01(日) 15:35:28

>>560
とりあえず Effective C++ でも買ってこい

0563デフォルトの名無しさん

2007/07/01(日) 23:47:23

>>545
今回はいつもよりちと早めだね
小技系だが、N2332 がはげしく欲しい

0564デフォルトの名無しさん

2007/07/02(月) 07:35:17

やっぱSL73だろ
http://gradeup.blog39.fc2.com/blog-entry-31.html

0565デフォルトの名無しさん

2007/07/02(月) 09:24:38

みんな好き勝手いいやがって……だれが実装すると思ってるんだ

0566デフォルトの名無しさん

2007/07/02(月) 12:50:56

>>563
make_*関数が要らなくなるのは確かに便利だな。

0567デフォルトの名無しさん

2007/08/07(火) 08:31:37

最近のSutterは完全にC++/CLI宣伝だな。
そういう契約なのかな…

0568デフォルトの名無しさん

2007/08/09(木) 21:18:40

最新のドラフトってこれでいいのかな？

# ISO/IEC 14882: Programming Language C++ - draft
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2315.pdf

0569デフォルトの名無しさん

2007/08/09(木) 21:27:04

今日付けでn2369が出たみたい。

0570デフォルトの名無しさん

2007/08/09(木) 22:45:56

今日付けw　何とタイムリーな。
こいつかな？
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf

0571デフォルトの名無しさん

2007/08/09(木) 22:49:14

今日じゃないや、6日だ…

今月分のもろもろ。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-08

0572デフォルトの名無しさん

2007/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 だっけ？
何か前に話題に出てたよね。

0573デフォルトの名無しさん

2007/08/10(金) 00:01:26

しかし、結構ドラスティックな変更が多いと思うけど、
こんなんがあと二年でまとまるんだろうか

0574デフォルトの名無しさん

2007/08/10(金) 00:10:12

constexprは制限が強すぎて見た目ほど強力じゃなかったはず

0575デフォルトの名無しさん

2007/08/10(金) 06:15:42

http://www.open-std.org/jtc1/sc22/wg21/
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

0576デフォルトの名無しさん

2007/08/10(金) 09:46:56

FORTRESSに、禿の"Generalizing Operator for C++2000"風の演算子拡張があって、
気になって仕方がない。

0577デフォルトの名無しさん

2007/08/11(土) 06:43:14

= default と = delete がいまいち分かんないな。

= default はデフォルトで作られるメンバ関数を非 inline 化するためのもの・・・でいいのか？
いまいち使い道が分からんが。

= delete は関数を使えなくする・・・でいいのか？
こっちはまあ使い道あるだろうけど、
10.3p14 を見るに、基底クラスのメンバを殺すのには使えんのか？

0578デフォルトの名無しさん

2007/08/11(土) 08:08:25

うわあああ
もう予約語の使いまわしはやめてくれぇぇぇぇぇぇぇ
=0ですらキモすぎるのに=deleteとか=defaultとか

0579デフォルトの名無しさん

2007/08/11(土) 08:13:20

フフフ。そのキモさが C++ なのさ！

0580デフォルトの名無しさん

2007/08/11(土) 08:41:36

純粋仮想関数とかいいながら、構文が汚れてるよな

0581デフォルトの名無しさん

2007/08/11(土) 08:47:17

不純だわ

0582デフォルトの名無しさん

2007/08/11(土) 08:51:54

不接触の純粋さは当然のこと。
穢れに触れて、それでも尚純粋であることの方が素晴らしい。

0583デフォルトの名無しさん

2007/08/11(土) 09:01:36

それもこれもstaticが全ての始まりでした…

0584デフォルトの名無しさん

2007/08/11(土) 09:23:04

*じゃね？

0585デフォルトの名無しさん

2007/08/11(土) 09:24:11

& もなかなか

0586デフォルトの名無しさん

2007/08/11(土) 09:34:31

POD という表現がことごとく修正されてるのは、
やっぱ constexpr の影響？

0587デフォルトの名無しさん

2007/08/23(木) 18:52:57

>>577
デフォルトのコピーコンストラクタはビットコピーする。
だから、単純なコピーで済むクラスなら書かなくていい。
しかし宣言すら存在しないのは、
プログラマがクラスのコピーについて何も言及していないようで、
必要がなくて書かなかったのか、書き忘れてるのか分からない。
じゃあコメントで言及？
それは美学がない。
そういう訳で、=defaultを使う。

0588デフォルトの名無しさん

2007/08/23(木) 19:01:10

defaultをわざわざ指定するというのも可笑しい

0589デフォルトの名無しさん

2007/08/23(木) 19:02:33

default constructorをprivate宣言してというIDEOMともおさらばか。

0590デフォルトの名無しさん

2007/08/23(木) 19:04:07

.hと.cppを分けて書かせるのはいつになったらやめてくれるんだ

0591デフォルトの名無しさん

2007/08/23(木) 19:17:14

.hだけ書いて.cppの骨組みは自動生成するようにして、
関数の中身にタグジャンプとかすれば大して気にならんと思うけど

0592デフォルトの名無しさん

2007/08/23(木) 19:22:48

そんなん冗長にして無駄そのものじゃないか
現役言語でそんなことやってるのC++だけだぜ
存在することのメリットが一つもない

0593デフォルトの名無しさん

2007/08/23(木) 19:38:14

inline指定できないほど長い関数はアンチパターンだ
というのが委員会の非公式な見解（うそ）

0594デフォルトの名無しさん

2007/08/23(木) 19:47:39

.hを自動生成するg++へのpatch誰か作れ

0595デフォルトの名無しさん

2007/08/23(木) 19:49:23

>590
全部テンプレートで解決

0596デフォルトの名無しさん

2007/08/23(木) 19:52:47

>>587
= default は inline 化されないと書いてあるんだけど、
inline と = default の同時指定とかできるのかな？
同時指定できるならその目的に使えるとは思うけど。

0597デフォルトの名無しさん

2007/08/23(木) 20:01:59

ダメって書いてないから、出来るんじゃないの。
宣言は明示的だけど、実装はdefaultってのが、= defaultだから、
勝手にinline宣言したことにもしないって流儀じゃないかな。

0598デフォルトの名無しさん

2007/08/23(木) 20:33:39

.hが更新されてるかどうかで再コンパイルするかどうか決めるっていう
仕組みが前提だから.hが必要なんだろ
誰がこんなアホな仕組みにしたんだ

0599デフォルトの名無しさん

2007/08/23(木) 21:31:34

>>597
なるほど。それなら使い道あるやね。
protected にするとか使えそう。

0600デフォルトの名無しさん

2007/08/23(木) 22:13:27

>>598
それは別に問題ないよ。
.hを自動生成すればいいだけの話。

Javaは.classが.o(.obj)と.hを兼ねているけど、
あれはbyte codeだから.oサイドも共通にできる。
C++で.cpp, .h, .oに分かれているのは自然。

0601デフォルトの名無しさん

2007/08/23(木) 22:15:03

D とか .h と .d とに分かれてないけど

0602デフォルトの名無しさん

2007/08/23(木) 22:25:43

しかし.hが内容同じでも更新時間が変わってたら
再コンパイルされちまうぞ

0603デフォルトの名無しさん

2007/08/23(木) 22:31:54

それはC++0xの言語仕様じゃなくて、処理系の問題。

0604デフォルトの名無しさん

2007/08/23(木) 22:33:36

細かく差分みてコンパイルしてくれるような開発環境が必要だな

0605デフォルトの名無しさん

2007/08/23(木) 22:38:58

UMLでクラス図を書く→スケルトンとテストケース、make生成→あとは.cpp埋めてくだけ
ってのが欲しい

0606デフォルトの名無しさん

2007/08/23(木) 22:45:15

それはヘッダを生成するさいに、一時ファイル経由でdiffでもとって、
変更がなければ上書きしなければよいのでは

0607デフォルトの名無しさん

2007/08/23(木) 23:02:32

誰かヘッダ生成ツール作ってくれえ

0608デフォルトの名無しさん

2007/08/23(木) 23:08:19

欲しいと思ったときがプログラミング時です

0609デフォルトの名無しさん

2007/08/23(木) 23:08:59

いいこと言うなあ

0610デフォルトの名無しさん

2007/08/23(木) 23:16:44

たしかVC++もGCCもプロトタイプ生成の機能は持っているはず。
関数・変数だけだったらヘッダ生成に使えるだろうけど。

0611デフォルトの名無しさん

2007/08/23(木) 23:19:44

Cの現状はCとの互換性のためだからしょーがないだろ
C99があさっての方にいっちゃったけど、今更捨てる気もないだろし

0612デフォルトの名無しさん

2007/08/23(木) 23:20:27

C99でCﾊｼﾞﾏﾀと思ったのは俺だけじゃないはず

0613デフォルトの名無しさん

2007/08/23(木) 23:22:08

Cなんて代物を使うのは移植性と過去のしがらみのためだけで、
それ気にする必要も無いんならC++使うよ

C99なんて使いどころが全然無い

0614デフォルトの名無しさん

2007/08/23(木) 23:37:46

いいこと言うなあ

0615デフォルトの名無しさん

2007/08/23(木) 23:46:16

ObjC厨の俺に喧嘩売ってんのか

0616デフォルトの名無しさん

2007/08/23(木) 23:51:37

Objected-Cは今後どうなるの？

0617デフォルトの名無しさん

2007/08/23(木) 23:57:42

どうにもならないだろうな

0618デフォルトの名無しさん

2007/08/24(金) 00:03:12

Objected-Cってなんだよｗ

0619デフォルトの名無しさん

2007/08/24(金) 00:04:46

これから始めれば無問題

0620デフォルトの名無しさん

2007/08/24(金) 01:17:02

>>600
dはコンパイル時に.hに相当するものを生成するオプションがある
ライブラリ作成時には必須

0621デフォルトの名無しさん

2007/08/24(金) 02:13:11

つーか.hは.cppから生成しないと最適化に必要な情報をぼんぼん取りこぼすと思うけどなあ
だからって最適化のためにいちいちinline展開しなきゃいけないというのもおかしな話だし

0622デフォルトの名無しさん

2007/08/24(金) 02:29:04

クラスの定義もcppに書くのかい？

0623デフォルトの名無しさん

2007/08/24(金) 02:42:36

>>587
デフォルトのコピーコンストラクタは各基底クラスと各データメンバのコピーコンストラクタを
使う。ビットコピーじゃないよ。

0624デフォルトの名無しさん

2007/08/24(金) 02:46:17

つーか、IDE 使うんなら .h と .cpp というファイルを直接編集するんじゃなくて、
もっと抽象的な形で編集できていいと思うんだよ。

0625デフォルトの名無しさん

2007/08/24(金) 03:13:45

>>624
その「抽象的な形」で書くってことは、つまり C++ ではない別の言語を使うということに
なるのではないかな。

0626デフォルトの名無しさん

2007/08/24(金) 07:12:43

俺の書くクラスは、.hppのクラス定義の中に全てのメンバー関数定義がある。
inline指定ない関数も、毎回コンパイルされているが、気にしない。
.cppも.hもない。

0627デフォルトの名無しさん

2007/08/24(金) 08:24:18

export template を使っておりますよ

0628デフォルトの名無しさん

2007/08/24(金) 09:51:35

hppに書いたらinlineと書かなくてもinline展開しようとする、と
言語仕様で決まってるんじゃなかったっけ
hppに書いたらinline展開するか、再コンパイルするかなど
コンパイラがよきにはからう、という言語仕様にしてれば
今頃は誰も分割なんかしてないだろう

0629デフォルトの名無しさん

2007/08/24(金) 09:56:39

>>628
> hppに書いたらinlineと書かなくてもinline展開しようとする

クラス定義内の関数定義は、暗黙のinline宣言だね。

> inline展開するか、再コンパイルするかなど
> コンパイラがよきにはからう、という言語仕様にしてれば

そういう仕様だよ。inline宣言はコンパイラに対するヒントに過ぎない。
"prefered"ではあるんだけれど。

0630デフォルトの名無しさん

2007/08/24(金) 09:57:14

inlineを指定しなくても指定したかのように扱われるのは、
メンバ関数の定義をクラス定義内に書いたらの話。

0631デフォルトの名無しさん

2007/08/24(金) 10:15:36

しかしhppに全部書いたら関数に変更加えるだけで
依存するクラス全部再コンパイルされて、
それに依存するクラスも全部再コンパイルされて・・・
となってほぼ全クラス再コンパイルされちまうよな
なんでこんな糞仕様なんだ

0632デフォルトの名無しさん

2007/08/24(金) 10:20:36

>>631
Visual C++の簡易リビルドは、そういうときに
再コンパイルをしなくていいものはしないという機能ではないか？
仕様がアレでもコンパイラが頑張るとそんなこともできるという話。

0633デフォルトの名無しさん

2007/08/24(金) 10:32:04

>>631
つ pimpl

0634デフォルトの名無しさん

2007/08/24(金) 10:51:23

こうなったら
inline = default
も追加だ

0635デフォルトの名無しさん

2007/08/24(金) 10:54:29

>>633
pimplは.hと.cppをがっつり分けてもなお依存性がやばいことになるという
C++の仕様に対する対策じゃん
ポインタ越しの関数もinline展開されたらまるで対抗できない

>>632
簡易リビルドを指定すれば.hと.cppを分けなくてもいいという話は聞いたことがないぜ
.hが変更されていても再コンパイルする必要がない場合は有効だろうけど
inline展開されてたらどうしたって再コンパイルしなきゃならなくなるし
まあデバッグビルドならinline展開されないだろうから大丈夫なのかな

0636デフォルトの名無しさん

2007/08/24(金) 11:03:51

gccにもプリコンパイルドヘッダはありますが。

0637デフォルトの名無しさん

2007/08/24(金) 11:05:41

簡易リビルドは、ヘッダが変更されていても、
変更された部分に依存していなければ再コンパイルする必要がない場合を
うまく見分ける機能じゃないの？
gccにそんなんあるかい

0638デフォルトの名無しさん

2007/08/24(金) 11:29:08

>>635
> ポインタ越しの関数もinline展開されたらまるで対抗できない

ｵｲｵｲw

0639デフォルトの名無しさん

2007/08/24(金) 11:33:25

>>638
.hに実装を書いたらpimpl使ったって
virtualでない限り基本的にはinline展開されちまうだろ

0640デフォルトの名無しさん

2007/08/24(金) 17:32:10

いったいコンパイラは実装が別の翻訳単位にある
メソッドをどうやってインライン展開するというのだろうか。

0641デフォルトの名無しさん

2007/08/24(金) 17:33:08

リンク時にがんばればいい。

0642デフォルトの名無しさん

2007/08/24(金) 17:58:10

あれ、展開されないか
かなりおかしなことを言ってるな

0643デフォルトの名無しさん

2007/08/24(金) 18:46:25

>>640
cl.exe の /Og がまさにそれじゃなかったか？

0644デフォルトの名無しさん

2007/08/24(金) 18:51:29

そういえばVC++は最適化のために
.cppに書いてあるものも勝手にinline展開したりするんだよな

0645デフォルトの名無しさん

2007/08/24(金) 18:57:51

まあよくわからんけど、.hと.cppに分けないとpimplも使えないし
そもそも何もしなくてもデフォルトでpimplになってるべきだよな
その辺の仕様が古臭すぎる

0646デフォルトの名無しさん

2007/08/24(金) 19:24:17

>>644
gccもiccも当たり前のようにinline展開しますが何か。

0647デフォルトの名無しさん

2007/08/24(金) 19:30:47

毎日コンパイルしてテストせよという時代に
pimplなど笑止千万。

0648デフォルトの名無しさん

2007/08/24(金) 19:45:17

毎日コンパイルしてテストせなならんから
コンパイル速度を上げるpimplが必要なんだろ

0649デフォルトの名無しさん

2007/08/24(金) 19:59:58

>>647はpimplを何だと思ってるんだ？

0650デフォルトの名無しさん

2007/08/24(金) 20:04:01

にきび

0651デフォルトの名無しさん

2007/08/24(金) 20:04:26

>>644
それどころかDLL内の関数すらインライン展開できる。
http://msdn2.microsoft.com/ja-jp/library/feffc7b5(vs.80).aspx

0652デフォルトの名無しさん

2007/08/24(金) 22:12:58

VCの最適化能力は異常

0653デフォルトの名無しさん

2007/08/24(金) 22:27:32

>>639 がスルーされている件について

0654デフォルトの名無しさん

2007/08/24(金) 22:47:10

うまいことごまかしたと思ったんだが・・・

0655デフォルトの名無しさん

2007/08/24(金) 23:50:52

.cppが無理やりインライン展開されちまうんじゃ
.cppのちょっとした変更でも再コンパイルがわけわかんないとこまで広がりかねんな

0656デフォルトの名無しさん

2007/08/25(土) 00:15:18

そこでインライン展開は実行時JITに任せる方式が登場するわけです

0657デフォルトの名無しさん

2007/08/25(土) 00:43:06

おまえらここじゃなくて最適化スレを活用しろよ
0x++でそこらへんの仕様が変わるって言うなら別だが

0658デフォルトの名無しさん

2007/08/25(土) 00:53:15

そこらへんの仕様は変わらんのか
じゃあC++の今後には何の期待も出来んな

0659デフォルトの名無しさん

2007/08/25(土) 01:51:03

それはお前の勝手。

0660デフォルトの名無しさん

2007/08/25(土) 02:15:58

もっと声をあげていかなアカンと思うぜ
.hと.cppを分けなければならないのは冗長で腐った考え方だ
クロージャを導入する前にそこをまずなんとかしろ

テンプレートのメタプログラミングはわけわからんからまともなマクロを導入しろ
足元をまず見直せ

0661デフォルトの名無しさん

2007/08/25(土) 02:20:22

>>660
言語仕様を俺の頭の悪さに合わせろ！とはなんとも無茶な注文ですね

0662デフォルトの名無しさん

2007/08/25(土) 04:27:56

まじめな顔して書くが
>>660みたいなのはDやればと思ってしまう

0663デフォルトの名無しさん

2007/08/25(土) 08:25:25

そもそも規格自体は .h と .cpp をわけろとか一言も書いてないと思うけど...
標準のヘッダは .h というか拡張しなかったりするけど、それ以外は
プリプロセッサが処理したあとの話しか規定してないわけだし。

0664デフォルトの名無しさん

2007/08/25(土) 09:05:30

分けたくないなら全部.hに書けよ、一人で勝手にさぁ。

0665デフォルトの名無しさん

2007/08/25(土) 09:42:43

まあでも、ヘッダとcppファイル間の間には、
IDEの支援がもっとあってもいいと思う。

0666デフォルトの名無しさん

2007/08/25(土) 10:47:41

D言語はGCがあるからパフォーマンスが必要なプログラムが書けない
せっかくネイティブなのに

まあDelphi使えばいいんだけどな

0667デフォルトの名無しさん

2007/08/25(土) 10:51:29

.hに実装まで書いたらコンパイラは全部inline展開しようとする、と
言語仕様で決まってるんだよスカタン
なんだこの糞仕様

0668デフォルトの名無しさん

2007/08/25(土) 10:54:09

＞.hに実装まで書いたらコンパイラは全部inline展開しようとする、と
妄想乙。

0669デフォルトの名無しさん

2007/08/25(土) 11:00:46

妄想じゃねー
暗黙 inline とかでぐぐれ

0670デフォルトの名無しさん

2007/08/25(土) 11:13:39

>>667は文章が下手。
「全部inline展開しようとする」は、
「全部必ずinline展開しようとする」、
「全部inline展開の考慮対象とする」のどちらにも読める。

0671デフォルトの名無しさん

2007/08/25(土) 11:27:38

>>670
どっちも同じ意味だろ
どっちも間違ってない

0672デフォルトの名無しさん

2007/08/25(土) 11:27:45

>>669
それはクラス定義内での関数定義の話ではないのか？

0673デフォルトの名無しさん

2007/08/25(土) 11:31:32

>>672
定義と宣言というのは正しい用語だがわかりにくいから
俺は.hに実装を書けばという言い方をする
.hの中でクラス定義と関数定義を分ける意味がないから普通は
クラス定義内の関数定義のことだと分かってもらえると思うが

0674デフォルトの名無しさん

2007/08/25(土) 11:35:31

>>673
こんなスレでそんなわかりにくさを気にするような奴はいないから、
そんな気を使う必要はないよ。

0675デフォルトの名無しさん

2007/08/25(土) 11:38:04

でも気遣う努力は素晴らしいことだよ、とフォロー。

0676デフォルトの名無しさん

2007/08/25(土) 11:58:39

>>673
> .hの中でクラス定義と関数定義を分ける意味がないから、普通は
> クラス定義内の関数定義のことだと分かってもらえると思うが
俺はごく短いもの以外、inlineさせたいメンバ関数は、.hの中で分けて書いてinline付けてるよ。
class hoge { }; のひとカタマリは、できるだけインターフェースの全容を一望しやすい形にしておきたいんで。
俺みたいな好みを持たない人でも、クラステンプレートがかなりでかいメンバ関数を持つことになって、
それを.hの中で分けて書いた、なんてことは何度もあるんじゃないかと思う。

つまり、「.hの中でクラス定義と関数定義を分ける」ことは、割とある。
だから「.hに実装を書く」という表現で、一気に「クラス定義部に実装を書くこと」まで限定した会話が
できると考えるのは、ちょっと行き過ぎなんじゃないかと思う。

・・・でもそれはそれとして、クラス定義内の強制inlineに対する気持ちはわかるｗ

0677デフォルトの名無しさん

2007/08/25(土) 12:28:02

outline とか追加されねーかなあ

0678デフォルトの名無しさん

2007/08/25(土) 12:29:20

7.1.2 Function specifiers

A function declaration with an inline specifier declares an inline function.

インライン指定を備えた関数宣言はインライン関数を宣言します。

The inline specifier indicates to the implementation
that inline substitution of the function body at
the point of call is to be preferred to
the usual function call mechanism.

インライン指定は、呼び出し位置の関数本体のインライン置換が
通常の関数呼び出し機構より優先されることを実装に示します。

An implementation is not required to perform
this inline substitution at the point of call;

実装は呼び出し位置でこのインライン置換を実行することは要求されません。

0679デフォルトの名無しさん

2007/08/25(土) 12:36:45

実装隠したければ・リンク互換性保ちたければ
pimpl使えってことじゃないのC++的には
ただのイディオムではなく言語的にもっとサポートがあると楽でいいんだがな
いつもいつもいちいち委譲のコードなんて書きたくないし

0680デフォルトの名無しさん

2007/08/25(土) 12:44:01

#includeなんてソースコードほんとに読み込むしな
原始的すぎる
Packageみたいなものをサポートする予定はないのかね

0681デフォルトの名無しさん

2007/08/25(土) 14:08:32

ヘッダでインクルードガードを検出したら同じ翻訳単位内では以後無視する最適化はしてあるよね
pImpl は extern と export で撲滅できるし

0682デフォルトの名無しさん

2007/08/25(土) 14:23:56

>>666
GC使わないこともできるよ。

0683デフォルトの名無しさん

2007/08/25(土) 14:24:42

インクルードガードも、たとえばVCの#pragma onceみたいなものを規格化すべきだと思っているんだけど、
必要ないのかな？

0684デフォルトの名無しさん

2007/08/25(土) 14:28:03

>>681
むしろexportのほうが撲滅されそうないきおいジャマイカ

0685デフォルトの名無しさん

2007/08/25(土) 14:29:14

インクルードの仕組み自体全部作り直せよ
ソースを置き換えるっていうこと自体問題が多すぎる
パッケージ内のクラス定義を一気に導入して
実際に使っているクラス定義にしか依存しない、という機能があればいい

0686デフォルトの名無しさん

2007/08/25(土) 14:30:19

>>685
Cとの互換性を捨てていいんならいくらでもやりようはあるだろうけど
今更それは出来んだろ

0687デフォルトの名無しさん

2007/08/25(土) 14:32:45

includeはincludeで残して、
packageというのを作ればいいんじゃね
これ導入したらincludeまで壊れるか？

0688デフォルトの名無しさん

2007/08/25(土) 14:33:46

ああ、includeも互換性のために残したままでシンボルテーブルをインポートする
新しい仕組みを作るのか
それならいいかもな

0689デフォルトの名無しさん

2007/08/25(土) 15:21:21

それはどこの .net f(ry

0690デフォルトの名無しさん

2007/08/25(土) 15:46:32

>>667 は inline 関数は全部 inline 展開されるとでも思ってるのかね。

0691デフォルトの名無しさん

2007/08/25(土) 15:59:32

「しようとする」という書き方を見て、「されるとでも思ってるのかね」もないもんだと思うがなぁ。

0692デフォルトの名無しさん

2007/08/25(土) 16:05:57

頭大丈夫か?

0693デフォルトの名無しさん

2007/08/25(土) 16:19:37

>>692
お前の頭の話なら、ダメかも。

0694デフォルトの名無しさん

2007/08/25(土) 16:51:25

>>684
export を使うとコンパイルの挙動が異様におもしろくなるので
コード書きのモチベーションに変化があったりなかっ…なくはない

0695デフォルトの名無しさん

2007/08/25(土) 17:20:34

なんでexportでpimplがいらなくなるんだ？

0696デフォルトの名無しさん

2007/08/25(土) 17:41:12

>>678
"to be preferred"を"優先される"は強すぎるだろ。
これこそ「しようとする」だ。

0697デフォルトの名無しさん

2007/08/25(土) 19:39:43

C++0xに関する映像出てるね
びょーんすっぽすっぽサマの声が聞けて嬉しす。

0698デフォルトの名無しさん

2007/08/25(土) 22:04:39

>>686
C++は既にCとの互換性を失っていますが

0699デフォルトの名無しさん

2007/08/25(土) 23:07:46

C++をおかしくした禿げのことか

0700デフォルトの名無しさん

2007/08/29(水) 02:32:45

これは良スレ

0701デフォルトの名無しさん

2007/08/29(水) 18:31:03

もうJavaっぽいGCなしのネイティブ言語つくろうぜ

0702デフォルトの名無しさん

2007/08/29(水) 18:34:46

Qtをさわった感じがそんなんだった。＞GC無しJava

0703デフォルトの名無しさん

2007/08/29(水) 18:45:41

字句解析つきマクロがあれば何でもできる。

0704デフォルトの名無しさん

2007/08/29(水) 19:49:27

そこでNemerleですよ

0705デフォルトの名無しさん

2007/08/29(水) 21:06:18

boostを作った変態たちにまともなマクロを与えたら
とんでもない言語を作ってくれると思うんだけどなあ
templateだけじゃやっぱ弱いよ

0706デフォルトの名無しさん

2007/08/29(水) 21:20:25

今のところ成功してるマクロはLispのものしかないな
「何でもできる」ってのはやっぱ危険だよ。

0707デフォルトの名無しさん

2007/08/29(水) 21:21:09

なんでも出来るのがC++の強みだよ

0708デフォルトの名無しさん

2007/08/29(水) 21:50:44

SASのマクロもかなり強力でかなり凶悪ですよ。
知っている人ほとんどいないと思うけど･･･

0709デフォルトの名無しさん

2007/08/29(水) 22:06:29

>>701
D言語に謝れ

0710デフォルトの名無しさん

2007/08/29(水) 22:54:57

実際組んでると auto が便利すぎてﾜﾗﾀなんだこれ

0711デフォルトの名無しさん

2007/08/29(水) 22:57:17

autoってなに？
typeof(hoge) var;のこと？

0712デフォルトの名無しさん

2007/08/29(水) 23:00:05

>711
多分同じことを指してるだろうが auto i = c.begin(); みたいに書いた方がわかりやすくないか？

0713デフォルトの名無しさん

2007/08/29(水) 23:01:57

暗黙的な型推論はC#3.0は本決まりでJavaは検討段階だっけかな

0714710

2007/08/29(水) 23:34:19

auto 仕様

※ PDF ! PDF !

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf

0715デフォルトの名無しさん

2007/08/29(水) 23:40:21

記憶指定子のautoよさらば！
って感じだな。
で、ついでにデフォルトのintも廃止されるのかな。

0716デフォルトの名無しさん

2007/08/29(水) 23:41:31

デフォルトの int ってまだ有効なんだっけ？

0717デフォルトの名無しさん

2007/08/29(水) 23:49:25

少なくともISO C++98にはない。おそらくそれ以前になくなったはず。
ついでに言うとC99でもなくなった。

0718デフォルトの名無しさん

2007/08/30(木) 02:01:46

後生大事に auto を予約語に残しておいた甲斐があったなｗ

0719デフォルトの名無しさん

2007/08/30(木) 02:15:02

export…

0720デフォルトの名無しさん

2007/08/30(木) 09:53:48

C++ 0xを実験的に実装したコンパイラとかないのか

0721デフォルトの名無しさん

2007/08/30(木) 10:19:44

>>720
Comeauのv439β使ってる
コンパイラの実装制限による仕様抑制が全くないC++の開発効率の高さは異常

0722デフォルトの名無しさん

2007/08/30(木) 10:20:22

地味な変更に今更気づいたけど、
別のコンストラクタを呼ぶことができるようになったんだね。

struct C {
　C(int) { }
　C() : C(42) { }
};

0723デフォルトの名無しさん

2007/08/30(木) 10:20:59

Comeau ってことは、export が使えるやつか。いいなあ。

0724デフォルトの名無しさん

2007/08/30(木) 10:35:37

ConceptGCCもそれなりに0x実装しているんじゃないのかな

0725デフォルトの名無しさん

2007/08/30(木) 12:22:54

込め会うってどこで手にはいるの？

0726デフォルトの名無しさん

2007/08/30(木) 12:26:41

ここから買え→ http://www.comeaucomputing.com/

0727デフォルトの名無しさん

2007/08/30(木) 14:50:23

>>720 g++

0728デフォルトの名無しさん

2007/08/30(木) 23:32:23

補足。
ttp://gcc.gnu.org/gcc-4.3/cxx0x_status.html

0729デフォルトの名無しさん

2007/08/31(金) 00:01:53

>>726
下の方でチラチラしてるやつ胡散くせーなぁｗ

0730デフォルトの名無しさん

2007/08/31(金) 09:03:54

0xには結局GCは入るの？

0731デフォルトの名無しさん

2007/08/31(金) 09:30:59

gcnew

0732デフォルトの名無しさん

2007/08/31(金) 21:32:29

GCCでもexport使えるようにならんのかなぁ

0733デフォルトの名無しさん

2007/08/31(金) 22:32:47

>>726
広告ｳｻﾞｽｗｗｗｗｗ
どこぞのエロサイトかと

0734デフォルトの名無しさん

2007/08/31(金) 22:38:57

export早く消えねえかな

0735デフォルトの名無しさん

2007/08/31(金) 22:43:50

20年後位にautoみたいなすてきキーワードになって帰ってくるはずさ

0736デフォルトの名無しさん

2007/08/31(金) 23:23:33

たまにはregisterのことも思い出してやってください

0737デフォルトの名無しさん

2007/08/31(金) 23:31:22

完全に忘れてたｗ

0738デフォルトの名無しさん

2007/08/31(金) 23:43:15

覚えてるよ
しかし使ったのは４年くらい前が最後か

0739デフォルトの名無しさん

2007/08/31(金) 23:47:34

>>736
なつかしす。autoみたいに、いかす再利用法を考えてあげようぜ。

0740デフォルトの名無しさん

2007/08/31(金) 23:48:54

なんかregisterも、いつの日か再利用される日が来たりして。

0741デフォルトの名無しさん

2007/08/31(金) 23:50:22

単語の意味的に再利用する方法がおもいつかん…

autoは見事すぎる。現れる位置ももともとのautoに近いし

0742デフォルトの名無しさん

2007/09/01(土) 00:09:08

「登録する」とか系の意味で再利用できんかな

0743デフォルトの名無しさん

2007/09/01(土) 01:00:41

register obj

objのGCに抵抗する。

0744デフォルトの名無しさん

2007/09/01(土) 02:13:49

レジスタと同じ大きさの数値型とか。
intはCPU/OS依存ではなく処理系依存だしねぇ。

0745デフォルトの名無しさん

2007/09/01(土) 02:46:49

javaみたいに整数型のビット数は言語仕様で固定として、
浮動小数点数は strictfp で IEEE 仕様に変更できるとかがいいな。
その上でregisterが整数型として存在するならありがたい。

0746デフォルトの名無しさん

2007/09/01(土) 02:57:18

template引数でビット数とか浮動小数点の精度とか
数の特性を指定できるようにすりゃいいんだよ
型も作っちゃいますみたいな

0747デフォルトの名無しさん

2007/09/01(土) 03:48:58

>>743
分かって言ってるんだとは思うが、抵抗するはresist

0748デフォルトの名無しさん

2007/09/01(土) 04:01:33

re gist erをgoogle翻訳すると「再要点えー」

0749デフォルトの名無しさん

2007/09/01(土) 06:00:46

>745
strictfpって、遅くなる可能性がなかった？

0750デフォルトの名無しさん

2007/09/01(土) 10:28:48

不動小数点数の扱いを規格化作するから速度的にはね。
飽くまでCPUごとのFPUに依存したくないときに指定するものだし。

0751デフォルトの名無しさん

2007/09/01(土) 11:13:09

near,farが完全に忘れられてるんだが

0752デフォルトの名無しさん

2007/09/01(土) 11:17:20

DOSとその有害な子孫の16ビット処理系コンパイラにしか存在して無いだろ

0753デフォルトの名無しさん

2007/09/01(土) 11:19:42

ファーッ、こんな侮辱初めてだわ。

0754デフォルトの名無しさん

2007/09/01(土) 11:20:13

ニイヤー、それほどでもないよ。

0755デフォルトの名無しさん

2007/09/01(土) 12:26:44

美少女中学生のフラットなおっぱいの先端を仮想エクステンドさせで何度もコールするとにゃッとかふァァッとかいい声で鳴くわけですね

0756デフォルトの名無しさん

2007/09/01(土) 12:27:56

すごい勢いでクソスレ化している

0757デフォルトの名無しさん

2007/09/02(日) 09:01:11

near, far って既に規格から消去されてないか？

0758デフォルトの名無しさん

2007/09/02(日) 09:02:38

一度でも標準規格に載ったことがあったか？

0759デフォルトの名無しさん

2007/09/02(日) 09:06:26

もちろん参考扱いだったはずだが、
JIS X3014:2003を見ると、allocatorのところに、
farポインタ用のchar_traitsを定義する例が載っているんだ。

0760デフォルトの名無しさん

2007/09/02(日) 10:36:39

アロケータでnearとfarを隠蔽する試みって結局失敗したんじゃないか？

0761デフォルトの名無しさん

2007/09/02(日) 13:46:10

ISO/IEC 14882:2003 24.3.1.2

[Note: If there is an additional pointer type _ _far such that
the difference of two _ _far is of type long, an implementation may define

template<class T> struct iterator_traits<T _ _far*> {
　typedef long difference_type;
　typedef T value_type;
　typedef T _ _far* pointer;
　typedef T _ _far& reference;
　typedef random_access_iterator_tag iterator_category;
};

-end note]

0762デフォルトの名無しさん

2007/09/02(日) 14:10:30

C++0xって楽しそう！
使ってみたい！
あ

0763デフォルトの名無しさん

2007/09/02(日) 18:19:28

い

0764南米院 ◆QUsHlZHWHA

2007/09/02(日) 21:45:39

う

0765デフォルトの名無しさん

2007/09/03(月) 04:08:08

e

0766デフォルトの名無しさん

2007/09/03(月) 09:05:16

オスマン・サンコンですぅ～

0767デフォルトの名無しさん

2007/09/03(月) 11:32:23

だまれ

0768デフォルトの名無しさん

2007/09/03(月) 12:18:21

>>762->>766
つあ
http://pc11.2ch.net/test/read.cgi/tech/1186388884/

0769768

2007/09/03(月) 12:22:31

あれっなんか変だ…
○>>762-768

0770768

2007/09/03(月) 12:25:34

×>>769
○>>762-766
スレ汚してすまそん逝ってきます…orz

0771デフォルトの名無しさん

2007/09/03(月) 12:31:07

急に盛り上がってると思ったらゴミレスか

0772デフォルトの名無しさん

2007/09/03(月) 22:32:34

もう俺C++ 0xで開発するわ
autoのない世界に戻れそうにない

0773デフォルトの名無しさん

2007/09/04(火) 19:25:48

C++03なら既に入手可能だな

0774デフォルトの名無しさん

2007/09/04(火) 20:42:51

03は98とほぼ同じ代物だし

0775デフォルトの名無しさん

2007/09/04(火) 20:45:22

C++2.0とか命名しなかったセンスは褒めたい

0776デフォルトの名無しさん

2007/09/04(火) 21:51:29

あんな風潮に迎合できるほど彼らの髪は残ってないからな。

0777デフォルトの名無しさん

2007/09/04(火) 21:54:46

777

0778デフォルトの名無しさん

2007/09/04(火) 21:56:09

どうせすぐにC++1xの策定準備に入るつもりだからだろう

0779デフォルトの名無しさん

2007/09/04(火) 22:00:49

アメ公ならx使ったら次は360とかにするかも

0780デフォルトの名無しさん

2007/09/04(火) 23:24:49

++C++

0781デフォルトの名無しさん

2007/09/05(水) 00:24:27

C++ 2008 XP Professional

0782デフォルトの名無しさん

2007/09/05(水) 01:06:04

C++ Home Edition

0783デフォルトの名無しさん

2007/09/05(水) 01:07:59

C++ Ultimate

0784デフォルトの名無しさん

2007/09/05(水) 02:56:47

C++ Orz

0785デフォルトの名無しさん

2007/09/05(水) 02:59:32

>>784
C++にひざまずいてるように見えるな

0786デフォルトの名無しさん

2007/09/05(水) 09:48:16

Wirth先生、PASCALがヒットしたのに(Turbo Pascalがあったからね)
気をよくして第２？３弾としてMODULA２を作ったけどさっぱりだった。

C++0xもほどほどで公開した方がいい。あんまりもったいぶると、いざ
公開されたときには｢こんなのイラネ｣と誰も使わないかもしれんぞ。

ご存知のように、言語とかライブラリとかは技術的に優れているから
受け入れられるかというと必ずしもそうではない。アメリカの某団体
が強く推奨するとか、マイクロソフトが採用する、とか運みたいな
ものがあるから。

0787デフォルトの名無しさん

2007/09/05(水) 09:54:05

↑
ageてる割に中身が無く、
誰に言ってるのかわからない文章

0788デフォルトの名無しさん

2007/09/05(水) 10:06:41

　　ﾋﾞﾖ～ﾝ
～（＾Д＾）～

0789デフォルトの名無しさん

2007/09/05(水) 10:08:20

>>786
Modula-3, Oberon, Oberon-2も知らないのね。

0790デフォルトの名無しさん

2007/09/05(水) 10:38:40

>>789
知らんでもいい。
Ada-95を知っていれば十分。

0791デフォルトの名無しさん

2007/09/05(水) 15:11:27

C--
C>>
C<<
C==
C||
C&&

0792デフォルトの名無しさん

2007/09/05(水) 15:47:19

C
C++
C+=2
C+=3

0793デフォルトの名無しさん

2007/09/05(水) 15:59:14

Dを先にとられちゃったのが痛いな

0794デフォルトの名無しさん

2007/09/05(水) 16:27:20

C Abnormal

0795デフォルトの名無しさん

2007/09/05(水) 16:30:18

>>793
「元祖D」とか「総本家D」で桶

0796デフォルトの名無しさん

2007/09/05(水) 16:47:29

はじめてのC

0797デフォルトの名無しさん

2007/09/05(水) 18:24:19

やればできるC
いきなりのC

0798デフォルトの名無しさん

2007/09/05(水) 18:25:49

それは入門書の名前だろ

0799デフォルトの名無しさん

2007/09/05(水) 20:48:47

HOW TO 本だろ

0800デフォルトの名無しさん

2007/09/05(水) 21:24:49

はうはううううう

0801デフォルトの名無しさん

2007/09/05(水) 22:36:25

頭文字C

0802デフォルトの名無しさん

2007/09/05(水) 22:57:43

--D

0803デフォルトの名無しさん

2007/09/05(水) 23:06:24

~C

0804デフォルトの名無しさん

2007/09/05(水) 23:17:40

いつからC++の次期バージョンの名前を考えるスレに？

0805デフォルトの名無しさん

2007/09/05(水) 23:20:53

そろそろ、捨てるべきものを捨てて言語を整理するべき時期に来たんじゃないかな
だから、新しい名前が必要に・・・

0806デフォルトの名無しさん

2007/09/05(水) 23:24:12

もっとあぶないC++

0807デフォルトの名無しさん

2007/09/05(水) 23:49:05

C++フォーエヴァー TVスペシャル0x

0808デフォルトの名無しさん

2007/09/06(木) 00:17:09

C^2

0809デフォルトの名無しさん

2007/09/06(木) 09:19:00

JavaC++

0810デフォルトの名無しさん

2007/09/06(木) 10:42:56

C++ デンマークから愛をこめて
C++ C++は二度死ぬ
C++ わたしを愛したJava

0811デフォルトの名無しさん

2007/09/06(木) 12:34:26

愛をこぬて

0812デフォルトの名無しさん

2007/09/06(木) 12:55:55

C NEXT

0813デフォルトの名無しさん

2007/09/06(木) 18:11:21

After C

0814デフォルトの名無しさん

2007/09/06(木) 19:55:48

Alternate+C

0815デフォルトの名無しさん

2007/09/06(木) 20:13:50

CXX mkII

0816デフォルトの名無しさん

2007/09/06(木) 22:50:58

G

0817デフォルトの名無しさん

2007/09/06(木) 23:10:49

Cex

0818デフォルトの名無しさん

2007/09/07(金) 00:16:00

C++'s Counterattack

0819デフォルトの名無しさん

2007/09/07(金) 17:46:48

関数テンプレート構文がこんな感じに書けたら楽なのにな
auto func<int val>(auto arg) { return val * arg; }

0820デフォルトの名無しさん

2007/09/07(金) 18:43:45

それって
template <int val, typename T> T func(T arg) { return val * arg; };
だとなんかマズい？

0821デフォルトの名無しさん

2007/09/07(金) 18:46:31

あぁ、書き方の問題か。

0822デフォルトの名無しさん

2007/09/07(金) 22:04:11

>>819
それって、引数に与える型によって返値型がころころ変わるのがいやだなあ。

0823デフォルトの名無しさん

2007/09/07(金) 22:18:32

>>819
引数や返値にautoを使用したとすると、参照にしたい時とか面倒そうだなあ

0824デフォルトの名無しさん

2007/09/08(土) 00:08:47

きっと auto& を使うんだyo

0825auto

2007/09/08(土) 00:15:41

#include <auto.h>

int main()
{
auto ;//Do anything you want.
return 0 ;
}

0826デフォルトの名無しさん

2007/09/08(土) 00:16:50

>>822
template構文でも、こう書けば同様に戻り値の型が
ころころ変わることを表現できそう（実際これが可能かは知らない）。
template<int val, typename T>
decltype(val * T()) func(T arg);

Boost.Lambdaみたいなライブラリでは役に立つのかもしれないと思う。

0827デフォルトの名無しさん

2007/09/08(土) 19:16:25

auto func = <>(val) { <>(arg : val) { val * arg } };
auto func10 = func(10);

0828デフォルトの名無しさん

2007/09/08(土) 19:19:28

…というのはクロージャじゃないからダメかなやっぱ (N2329ね)

0829デフォルトの名無しさん

2007/09/08(土) 23:08:45

C++0xのコンパイラどこ？

0830デフォルトの名無しさん

2007/09/08(土) 23:12:37

ドクロが見つめる一本杉の根本に埋めてあるよ

0831デフォルトの名無しさん

2007/09/08(土) 23:18:24

>>830
ドラえもん乙

0832デフォルトの名無しさん

2007/09/09(日) 01:59:47

>>830
教えてくれてありがとう！

0833デフォルトの名無しさん

2007/09/09(日) 02:06:05

>>830
ぴぴるぴるぴる（略

0834デフォルトの名無しさん

2007/09/15(土) 10:51:47

9月分来てるね。

0835デフォルトの名無しさん

2007/09/19(水) 19:09:37

何が変わってる？

0836デフォルトの名無しさん

2007/09/20(木) 18:33:43

マルチメソッドなんて入るの？

0837デフォルトの名無しさん

2007/09/20(木) 21:59:39

C++に入れられない仕様など無い。

0838デフォルトの名無しさん

2007/09/20(木) 23:43:23

マルチメソッドって禿のお気に入りだったやつ？
D&Eでしつこいほどに言及してたけど。

0839デフォルトの名無しさん

2007/09/21(金) 08:45:21

>835
9 月分だと draft の変更はなし。concurrency 関連の paper が多め、といったところだと思う。

>826
簡単に T が Default constructible でなくても良く書く方法として
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1978.pdf
に、↓な書き方が提案されている。
template<int val, typename T>
auto func (T arg) -> decltype(val * arg);

0840デフォルトの名無しさん

2007/09/21(金) 08:52:53

正直Objective-C++0xに期待してまふ

0841デフォルトの名無しさん

2007/09/21(金) 12:34:23

げろげろ

0842デフォルトの名無しさん

2007/09/21(金) 15:30:53

俺はC++/CLI0xに期待だぜ

0843デフォルトの名無しさん

2007/09/21(金) 16:15:30

C++/CLI (笑)

0844デフォルトの名無しさん

2007/09/21(金) 16:26:56

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1978.pdf
を読んでて、ふと思ったんだけど 2.4.1 Variable and function names の所で
int foo(char);
decltype(&foo) // int(*)(char)
decltype(*&foo) // int(&)(char)
とグローバル関数については例が載ってるけど、メンバ関数については
class A {
int foo(char);
};
decltype(&A::foo) // int(Foo::*)(char)
と、メンバ関数ポインタについてのみ書いてある。
decltype(*&A::foo) // int(Foo::&)(char)
とかってのは駄目？

0845デフォルトの名無しさん

2007/09/21(金) 17:39:06

どんな型を持った変数に戻り値を入れるんだろうと
::&演算子?

0846デフォルトの名無しさん

2007/09/23(日) 06:58:20

あと2年半弱か..

0847デフォルトの名無しさん

2007/09/23(日) 08:24:34

やっぱり、2009年内に間に合わなかったら
そこからあと90年待つのかな。

0848デフォルトの名無しさん

2007/09/23(日) 10:34:44

>>844
現行のC++にもメンバへの参照はないな。

0849デフォルトの名無しさん

2007/09/23(日) 16:09:28

>>848
レスありがと。
そっか、別に必要と思う局面は思いつかないけど
なんで無いんだろうねぇ。

0850デフォルトの名無しさん

2007/09/23(日) 16:44:05

>>849
参照は必ず実体を指す、という制約がクラス継承によってさっくり破られるからな

0851デフォルトの名無しさん

2007/09/23(日) 18:48:13

>>850
おー！なるほど！
そういうことだったのか。
T& を T* const と思い込んでたから気付かなかったんだぜ。

0852デフォルトの名無しさん

2007/09/24(月) 14:39:56

C++0x　<-よーくみろ！これは数字じゃなくて16進定数のプレフィックスだ！
ってことは、ってことは！！

この動作は不定ってことだぁーーーーーーーーーーーー。

まさに外道。

0853デフォルトの名無しさん

2007/09/24(月) 14:49:53

C → C++ → C++0x → <<C++0x → <<C++0x() → <<C++0x(\->)

0854デフォルトの名無しさん

2007/09/24(月) 18:13:39

それなんて顔文字？

0855デフォルトの名無しさん

2007/09/25(火) 03:58:34

ほんとにC++09は間に合うのかね？
てか、g++は追従できるんだろうか・・・。

0856デフォルトの名無しさん

2007/09/25(火) 08:31:55

comeauならやってくれるさ

0857デフォルトの名無しさん

2007/09/25(火) 08:48:01

米屋ぁう

0858デフォルトの名無しさん

2007/09/25(火) 11:43:41

Ct

0859デフォルトの名無しさん

2007/09/25(火) 22:45:09

C++0x2009

0860デフォルトの名無しさん

2007/09/26(水) 12:27:55

>>859だと C+(+0x2009)になるのかな？

0861デフォルトの名無しさん

2007/09/27(木) 18:36:20

>>860

$ cat > a.cc
int main() {
int C = 0;
C++0x2009;
}
$ g++ a.cc
a.cc: In function `int main()':
a.cc:3: error: expected `;' before numeric constant
$ orz
bash: orz: command not found

0862デフォルトの名無しさん

2007/09/28(金) 00:31:01

VC8だとローカルクラスをテンプレートパラメータに渡せてしまったんだが、
これが標準になれば、lambda無くても良くね？

0863デフォルトの名無しさん

2007/09/28(金) 00:45:41

むしろローカル関数を

0864デフォルトの名無しさん

2007/09/28(金) 00:50:49

lambdaじゃなくて名前付きのローカル関数？

0865デフォルトの名無しさん

2007/09/28(金) 01:46:21

>>863
ローカルクラスのstaticメソッドで十分では。

0866デフォルトの名無しさん

2007/09/28(金) 02:07:00

>>865
めんどいしhackっぽいのが嫌じゃない？
クロージャも使えないし。

0867デフォルトの名無しさん

2007/09/28(金) 03:35:47

>>866
たしかに面倒というほかないが、
tr1::bindとstaticメソッドさえあればクロージャはできるよね。
まあ、lambda欲しいけど。

0868デフォルトの名無しさん

2007/09/28(金) 23:26:53

たのむ、0x0000_0000_0000って書ける様にしてくれ。64ビット時代になったらしむる。
そんな大それたお願いじゃないからさ

0869デフォルトの名無しさん

2007/09/29(土) 00:23:38

32進数を作ればいいじゃない

0870デフォルトの名無しさん

2007/09/29(土) 00:24:23

>>868
2進表記もほすい

0871デフォルトの名無しさん

2007/09/29(土) 01:27:17

template <unsigned long N>
struct Binary {
enum { value = (Binary<N / 10>::value << 1) + N % 10 };
};
template <>
struct Binary<0> {
enum { value = 0 };
};
で
Binary<1101>::value -> 13
あるいは
#define HEX_DIGIT_0000 0
#define HEX_DIGIT_0001 1
...
#define HEX_DIGIT_1111 f
#define HEX_DIGIT(a) HEX_DIGIT ## a

#define BINARY8H(a,b,c,d,e,f,g,h) (0x##a##b##c##d##e##f##g##h)
#define BINARY8I(a,b,c,d,e,f,g,h) BINARY8H(a,b,c,d,e,f,g,h)
#define BINARY8(a,b,c,d,e,f,g,h) BINARY8I(HEX_DIGIT(a), HEX_DIGIT(b), ..., HEX_DIGIT(h))
で
BINARY8(1010,0101,1010,0101,1010,0101,1010,0101) -> 0xa5a5a5a5

0872デフォルトの名無しさん

2007/09/29(土) 13:56:24

typeofはどうなるんだ

0873デフォルトの名無しさん

2007/09/29(土) 16:47:09

decltype が入るジャン？

0874デフォルトの名無しさん

2007/09/29(土) 19:23:05

どうせなら好きな基数で数を書けるようにして欲しい
3進法や5進法が欲しくなることもたまにあるし

0875デフォルトの名無しさん

2007/09/29(土) 20:01:52

アンダースコアによる数値の書式整理は欲しいね。Python がうらやましい

0876デフォルトの名無しさん

2007/09/30(日) 07:30:05

>>875
Pythonにアンスコ区切りないよ？
バイナリリテラルはあるかも知れないが

0877デフォルトの名無しさん

2007/09/30(日) 09:51:09

人気者のPythonがうらやましす

0878デフォルトの名無しさん

2007/09/30(日) 12:08:03

>876
あれ。違ったか。ごめん。ずっと Python だと覚えてた
12_000_000 って数値の書式を整理できるﾔｼ

0879デフォルトの名無しさん

2007/09/30(日) 12:46:51

_区切りは慣れると手放しがたくて困る。

0880デフォルトの名無しさん

2007/09/30(日) 14:33:48

perlは_区切りできる。
perlで出きるのを見てて、Cでも出来るものと勘違いしてたよ。
あると読みやすいね。

0881デフォルトの名無しさん

2007/09/30(日) 14:37:18

64bitが主流になったら検討されるかな

int64_t hoge = 0xFFFFFFFFFFFFFFFF;

とか書きたくないな

0882デフォルトの名無しさん

2007/09/30(日) 14:46:06

昔ながらのMAKEWORDの類のマクロまたはインライン関数でいいんじゃねぇの？
コンパイル時に定数として埋め込まれるでしょ

0883デフォルトの名無しさん

2007/09/30(日) 15:27:06

アンスコを数値に追加してパース時に読み飛ばしてくれるだけで対応できるんだけど
こういうちょっと便利な内容っていつでもできるからって議題に上がらなくて
結局、入らないんだよね

int64_t max_value = 3_764_000_000;
int64_t max_value = UNDERSCOUT_FORMAT(3_764_000_000);

可読性がぜんぜん違うっしょ

0884デフォルトの名無しさん

2007/09/30(日) 17:42:05

>>881
int64_t hoge = ~0;

0885デフォルトの名無しさん

2007/09/30(日) 17:46:30

>>871
ごめん。スレ違いだけどちょっと気になって・・・

template <bool B> struct static_assert;
template <> struct static_assert<true> {};

template <unsigned long N>
struct Binary {
static_assert<N % 10 == 0 || N % 10 == 1> illegal_bin_digit_found;
enum { value = (Binary<N / 10>::value << 1) + N % 10 };
};
template <>
struct Binary<0> {
enum { value = 0 };
};

0886デフォルトの名無しさん

2007/09/30(日) 18:50:56

>>871
Binary<0101>::value で static_assert 失敗するのはダメだろ。

0887デフォルトの名無しさん

2007/09/30(日) 19:07:45

>>886
8進数になるから無視していいのでは。

0888デフォルトの名無しさん

2007/09/30(日) 22:53:01

数値のカンマ区切りならoperator orverloadで現行でも何とかなりそうとか思ってみたりみなかったり

0889デフォルトの名無しさん

2007/09/30(日) 23:20:19

英語力に自信のある人、ドラフト投げてみてくれ。
今を逃すとc++1x送りになるだろし。

0890デフォルトの名無しさん

2007/09/30(日) 23:58:34

>>888
そりゃ難しくないかい？俺の頭では無理っぽい。
だって、何桁目のカンマか識別できないもん・・・(´・ω・｀)

0891デフォルトの名無しさん

2007/10/01(月) 00:00:56

return rhs*1000+lhs; すりゃいいわけだから、識別しなくていいんじゃね？

0892デフォルトの名無しさん

2007/10/01(月) 00:02:11

実行時評価ｗ

0893デフォルトの名無しさん

2007/10/01(月) 00:02:40

こういうのって可読性の問題だから「俺様定義すれば可能」より「標準の機能」であることが
好ましいように思うな。でも何十年も拒否してきた機能を今さら入れるだろうか？

0894デフォルトの名無しさん

2007/10/01(月) 00:03:46

>>891
lhsとrhsが逆じゃね？（普通の習慣では）

0895デフォルトの名無しさん

2007/10/01(月) 00:03:57

いま>>892がいいことを言った。

0896デフォルトの名無しさん

2007/10/01(月) 00:06:31

演算子オーバーロードってユーザ定義型じゃないとだめじゃん

0897デフォルトの名無しさん

2007/10/01(月) 00:18:29

orepp → cpp → cc → ar
これで解決
流用できないのでGPLも怖くないｗｗｗ

0898デフォルトの名無しさん

2007/10/01(月) 00:23:07

そんなQtみたいなソルーションは断る。

0899デフォルトの名無しさん

2007/10/01(月) 00:23:37

誰が使うの？

0900デフォルトの名無しさん

2007/10/01(月) 00:37:02

しゃーねーなぁ。一丁ドラフトでも書いてみるか。
0b10101010 とか 0xAA_BB_CC_DD とか 1,024 とか。

0901デフォルトの名無しさん

2007/10/01(月) 00:39:22

俺の英語力を駆使してみた。
I want to use >>900.

0902デフォルトの名無しさん

2007/10/01(月) 00:44:00

0bはすでに脚下済では？

0903デフォルトの名無しさん

2007/10/01(月) 00:46:59

>901
お前頭いいなぁ

0904デフォルトの名無しさん

2007/10/01(月) 00:50:41

0bは滅びぬ。何度でも蘇るさ。

0905デフォルトの名無しさん

2007/10/01(月) 01:07:50

こりゃ次スレが必要だね。

0906デフォルトの名無しさん

2007/10/01(月) 01:13:41

>>885
このstatic assert頭よくね？
コンパイルタイムでなくリンクタイムの失敗になるだろうけど。

0907デフォルトの名無しさん

2007/10/01(月) 01:23:41

>>906
コンパイルタイムに弾くよ。
だって、static_assert<false> は未定義になるから、
illegal_bin_digit_found のサイズがわからーんってなるもん。

0908デフォルトの名無しさん

2007/10/01(月) 01:24:09

>>906
失敗したらコンパイルエラーで止まるよ。

0909デフォルトの名無しさん

2007/10/01(月) 01:26:13

勘違い。ごめん。
boostのはもちっと複雑だよね？boostのも同じ原理だっけ?

0910デフォルトの名無しさん

2007/10/01(月) 08:24:02

>>900
>1,024

既存プログラムに非互換が出るから駄目だと思う。

0911デフォルトの名無しさん

2007/10/01(月) 08:33:10

0-Fを見て0000-1111が浮かばないのか？

0912デフォルトの名無しさん

2007/10/01(月) 08:46:56

だったら下線や空白なら平気ではないのか？

0913デフォルトの名無しさん

2007/10/01(月) 12:05:06

dead_beefという変数に誤爆する可能性はないか？いや、無いか

0914デフォルトの名無しさん

2007/10/01(月) 14:42:09

やべ、牛肉供給日の beef_feed も誤爆？いや、無いか

0915デフォルトの名無しさん

2007/10/01(月) 14:47:59

0xを先行させるルールを忘れたもうな。

0916デフォルトの名無しさん

2007/10/01(月) 15:04:47

(0x0)

0917デフォルトの名無しさん

2007/10/01(月) 15:11:13

XCは0b出来たよな、記憶違いか…？

0918デフォルトの名無しさん

2007/10/01(月) 15:13:34

独自に 0b をサポートしてるコンパイラは多い

0919デフォルトの名無しさん

2007/10/01(月) 16:06:56

$ cat > a.cc
int i = 0b1010;
$ g++ -c a.cc
a.cc:1:9: invalid suffix "b1010" on integer constant
$ orz
bash: orz: command not found

0920デフォルトの名無しさん

2007/10/01(月) 17:29:43

俺が慰めてやるよ

orz.c

#include <stdio.h>
main(){
printf("まあまあ\n");
}

コンパイルして使ってくれ。

0921デフォルトの名無しさん

2007/10/01(月) 17:32:17

↓mainの戻り値云々

0922デフォルトの名無しさん

2007/10/01(月) 17:33:41

こまけーこというなよ

0923919

2007/10/01(月) 17:34:25

>>920
(TдT)ｱﾘｶﾞﾄｳ

0924デフォルトの名無しさん

2007/10/01(月) 17:41:28

$ cat > orz.cc
#include <iostream>
int main() {
std::cout << "orz===3 ﾌﾟｽｰ" << std::endl;
}
$ g++ -o orz orz.cc
$ orz
orz===3 ﾌﾟｽｰ
$ w
17:39:23 up 25 days, 23:16, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
yy tty1 - 17:40 0.00s 0.09s 0.01s w

0925デフォルトの名無しさん

2007/10/01(月) 17:45:42

>>921
orzの戻り値に依存してコード組んだら文字通りorzな結果になるんだから、
それはそれでいい。

0926デフォルトの名無しさん

2007/10/01(月) 18:03:04

そろそろ次スレのことも視野に入れることが必要にもかかわらず
だんだんと低俗になってゆく悪寒。

0927デフォルトの名無しさん

2007/10/01(月) 18:06:08

alias orz="echo '(´･ω･｀)'"

0928デフォルトの名無しさん

2007/10/01(月) 18:28:25

>>919
ttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479

0929デフォルトの名無しさん

2007/10/01(月) 21:12:13

>>928
情報ありが豚。

0930デフォルトの名無しさん

2007/10/01(月) 21:43:54

リトルエンディアンとビッグエンディアンで二通りのルール作っていいから、
ビットフィールドの上がLSBって規格にしてくれないかな。

ビットフィールドに限らないけど、構造体で新しいメンバを下に書き足したら、
既存のメンバの位置がずれるなんて馬鹿かと。（そんなのに依存する書き方を
するなとか言うのはまた今度。言語としてルールが決まってても困らんだろうし）

0931デフォルトの名無しさん

2007/10/02(火) 02:08:13

最適化の機会を奪うな！なーんてな。

0932デフォルトの名無しさん

2007/10/02(火) 02:50:04

メンバポインタ使えばいいのに

0933デフォルトの名無しさん

2007/10/02(火) 04:08:44

残念ながら世の中にはリトルでもビッグでもない変態エンディアンのアーキテクチャが存在します

0934デフォルトの名無しさん

2007/10/02(火) 06:07:59

ttp://ml.tietew.jp/cppll/cppll/article/12789
こういうのかw
これは正直ワロタ

0935デフォルトの名無しさん

2007/10/02(火) 08:04:39

>>930
やれやれ
初心者スレ行ってくれ

0936デフォルトの名無しさん

2007/10/02(火) 08:14:32

0bってなんで却下されたの？

0937デフォルトの名無しさん

2007/10/02(火) 10:07:15

>>935
自分がさも玄人のように上から見下ろした書き方をしているが、
実際にはお前だって大した人間じゃないだろう

0938デフォルトの名無しさん

2007/10/02(火) 10:34:53

目くそ鼻くそ。

0939デフォルトの名無しさん

2007/10/02(火) 10:48:05

大違いってことだな。

0940デフォルトの名無しさん

2007/10/02(火) 13:22:29

しかし今さら非互換が出る構造体配置規定はないでしょう

0941デフォルトの名無しさん

2007/10/02(火) 13:53:26

boostがsmart_struct作ってくれるよきっと

0942デフォルトの名無しさん

2007/10/02(火) 14:51:09

>>940
現状特に規定が無いのだから、今さら非互換ってのにはあたらない
と思うが。あと0xは現状との互換性を完全に踏襲しようとしてるの？

0943デフォルトの名無しさん

2007/10/02(火) 14:57:37

アーキテクチャによってはメンバーポインタがかなり複雑な実装になりそう。

0944デフォルトの名無しさん

2007/10/03(水) 00:19:55

>>943
そのこころは？

0945デフォルトの名無しさん

2007/10/06(土) 21:38:02

なんか、DがC++とリンク可能になったらしい…
クラスオブジェクトも相互利用できるらしい…
C++0xの優位性って何…？

0946デフォルトの名無しさん

2007/10/06(土) 21:42:21

>>945
そうなの？C++ってABIぐちゃぐちゃなのに
g++の出力した*.oとはリンクできるとか、そういう話か？

どっちみち現在のC++はテンプレートベースのライブラリが多いから、
*.oとリンクできたところで何が嬉しいんだかよくわからん
それだけじゃ、STLもboostも使えないだろ

0947デフォルトの名無しさん

2007/10/06(土) 21:47:56

そういえば、var って戻り値として宣言できるの？

0948デフォルトの名無しさん

2007/10/06(土) 21:52:21

>>945
そもそも名前マングリングさえ統一されてないのに
どうやってリンクすんの？
特定の環境限定？

0949デフォルトの名無しさん

2007/10/06(土) 23:03:14

というかDに何の興味もない

0950デフォルトの名無しさん

2007/10/06(土) 23:27:19

>>945
boostが使えねーyo

0951デフォルトの名無しさん

2007/10/06(土) 23:32:25

boostスレのこのコードは0xでは通る?
enum{ value = "a"[0] };

0952デフォルトの名無しさん

2007/10/06(土) 23:33:56

ぱっと見では通りそうに見えるけど…
（キャストしなくてもいいのかは気になるが）
なんか問題あるコードなんだっけ？

0953デフォルトの名無しさん

2007/10/06(土) 23:37:14

>>952
Boostスレ見れ

0954デフォルトの名無しさん

2007/10/06(土) 23:48:08

C++0xが試せるコンパイラってあんの？
GCC4.3とか?

0955デフォルトの名無しさん

2007/10/07(日) 00:28:14

>>954

Status of Experimental C++0x Support in GCC 4.3
http://gcc.gnu.org/gcc-4.3/cxx0x_status.html

0956デフォルトの名無しさん

2007/10/07(日) 00:47:32

>>948
どうせDMC限定でしょ？

0957デフォルトの名無しさん

2007/10/07(日) 10:41:44

0xが出るおかげでD涙目ｗｗｗ

0958デフォルトの名無しさん

2007/10/07(日) 10:54:37

どうせ両方とも変態言語なんだから方向性を尊重しつつ影響を与えあいつつ仲良くやってきゃいいと思うんだけどね。

0959デフォルトの名無しさん

2007/10/07(日) 13:04:32

0b の話を蒸し返すけど
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2378.pdf
が通れば同じようなことはできるようになるはず。prefix じゃなくて suffix だけど。
ユーザーが拡張可能になるからものすごい変態的機能が実現できそうな気がする。

0960デフォルトの名無しさん

2007/10/07(日) 13:30:32

これ大真面目に議論されているのかな。
C++ってどんな言語だったっけ。

0961デフォルトの名無しさん

2007/10/07(日) 13:43:39

C with classes

0962デフォルトの名無しさん

2007/10/07(日) 13:54:34

「何でもあり」
とWikipediaに書き込んだのは俺

0963デフォルトの名無しさん

2007/10/07(日) 14:35:58

>>962
おまのせいでこんな言語になったのか！

0964デフォルトの名無しさん

2007/10/07(日) 14:57:54

perlより読みにくいコードになりそうだな

0965デフォルトの名無しさん

2007/10/07(日) 16:44:18

perlが読みにくいとか（笑）

0966デフォルトの名無しさん

2007/10/07(日) 18:07:33

読みにくく書けちゃう、が正しいな。

0967デフォルトの名無しさん

2007/10/07(日) 18:43:49

いあほんとにperlは糞だと思うよ
あの読み難さはビギナーにはかなりの苦痛。
C++も同じ方向に向かってると思うと悲しくてならん。

0968デフォルトの名無しさん

2007/10/07(日) 18:44:55

次スレ・・・要らん、か。

0969デフォルトの名無しさん

2007/10/07(日) 18:47:24

常考的に考えて必要。

0970デフォルトの名無しさん

2007/10/07(日) 18:52:47

糞スレだから要らない

0971デフォルトの名無しさん

2007/10/07(日) 18:54:46

次スレタイトルを>>959の記法で考えてみてくれ。

0972デフォルトの名無しさん

2007/10/07(日) 18:59:20

C++0x2でいいのでは

0973デフォルトの名無しさん

2007/10/07(日) 19:37:14

C++0xの国際化対応の文字列ってどうなるの？

今のC++のワイド文字はOS、コンパイラ変えると
仕様が変わるからメンドクサイんだけど・・・

0974デフォルトの名無しさん

2007/10/07(日) 19:38:49

仕様とは？

0975デフォルトの名無しさん

2007/10/07(日) 19:45:31

文字セット？

0976デフォルトの名無しさん

2007/10/07(日) 19:54:26

conceptはいいな。早く使いたい。

0977デフォルトの名無しさん

2007/10/07(日) 19:59:11

C++0x Part2
http://pc11.2ch.net/test/read.cgi/tech/1191754720/

0978デフォルトの名無しさん

2007/10/07(日) 20:01:36

糞ｽﾚ乙

0979デフォルトの名無しさん

2007/10/07(日) 20:13:20

ええぇー

0980デフォルトの名無しさん

2007/10/07(日) 20:32:31

>>973
つ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2149.html

0981デフォルトの名無しさん

2007/10/07(日) 21:36:38

U"こういうことか"

0982デフォルトの名無しさん

2007/10/08(月) 02:12:51

C++ 2.0 とかでよくね

0983デフォルトの名無しさん

2007/10/08(月) 03:43:17

だせ

0984デフォルトの名無しさん

2007/10/08(月) 14:17:41

ぶっちゃけ++を継続する必要もないんじゃね

0985デフォルトの名無しさん

2007/10/08(月) 14:45:40

No longer C++に一票。

0986デフォルトの名無しさん

2007/10/08(月) 15:02:14

Cとのソースレベルの互換性を捨てて
NLC (No Longer C)とするのか。

0987デフォルトの名無しさん

2007/10/08(月) 16:05:35

Nurupo Language C

0988デフォルトの名無しさん

2007/10/08(月) 16:38:47

NULLをさっさと予約語にしてほしい

0989デフォルトの名無しさん

2007/10/08(月) 16:41:45

予約語使い回しの現状を鑑みるに、ありえないだろうな。

0990デフォルトの名無しさん

2007/10/08(月) 17:05:44

C++への開発リソースを、D1.0系のライブラリや開発環境への開発リソースに・・・

0991デフォルトの名無しさん

2007/10/08(月) 17:19:29

>>988-989
残念、nullptr というのが与薬後になるよ。

0992デフォルトの名無しさん

2007/10/08(月) 17:46:57

0993デフォルトの名無しさん

2007/10/08(月) 17:47:29

testy

0994デフォルトの名無しさん

2007/10/08(月) 17:48:05

this is a pen!

0995デフォルトの名無しさん

2007/10/08(月) 17:48:47

asdf

0996デフォルトの名無しさん

2007/10/08(月) 17:49:52

fuck you

0997デフォルトの名無しさん

2007/10/08(月) 18:18:11

1000

0998デフォルトの名無しさん

2007/10/08(月) 18:20:07

1000ならC++2015。

0999デフォルトの名無しさん

2007/10/08(月) 18:22:40

あぽ

1000デフォルトの名無しさん

2007/10/08(月) 18:23:14

１０００なら次スレ>>1死亡

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。