08/05/05 19:14:44
>>561
begin(i),end(i) で local_iterator を取得できたような。
ハッシュの分散結果をどう使うかってことなので、カスタムハッシュ関数次第
じゃないか？ まあ通常はあまり使わないかも
563:デフォルトの名無しさん
08/05/05 19:23:03
どっかのbucketにばっかり入っちゃうようなデータで、そのせいで遅くなるようなときに
調査するためじゃねえの
564:デフォルトの名無しさん
08/05/05 19:27:20
>>561
詳しいドキュメント読んでないから分からんけど、たぶん同一 hash 値だったら
同一の bucket に入ることが保証されるはずだから、次のような使い方ができる。
次の問題を考える：
二次元平面上の点が大量に与えられる。これを前処理して
新たな点 p が与えられたときに p に最も近い点を求めよ。
こんなときに、最初の二次元平面上の点に対して、ハッシュ関数を
(x座標値/1000)×(y座標値/1000) なんかに設定したコンテナを用意すると
元のデータが結構ばらけていたら、「同一 bucket 内に入るデータを全部調べる」
みたいなアルゴリズムで結構効率的に解ける。
565:デフォルトの名無しさん
08/05/05 19:59:38
おもろい
566:デフォルトの名無しさん
08/05/05 20:46:02
>>562
本当だ。
引数を取るb.begin(b), b.end(b)があったのか。
local_iteratorは、あるbucket内の要素のイテレータとは。
しかし、>>564には疑問だな。
例えば、その点pのハッシュ値が、ちょうどbucket単位の境にあった場合、
点pに最も近い点は、別のbucketに入るんじゃない？
すると、隣接するbucketも調べないといけないよね？
少なくとも二つ、大抵の場合は三つ。
それに、規格にあるのは、
>Keys with the same hash code appear in the same bucket.
だけで、似たようなハッシュ値が同じbucketに入るとは規定してないし。
隣接するbucketに入るとも規定されてないよね。
あくまでハッシュという名称を使っているだけで、実装じゃないし。
567:デフォルトの名無しさん
08/05/05 21:01:51
境界の違うハッシュを2つ使えば？
(x/1000)*(y/1000) と ((x+500)/1000)*((y+500)/1000) みたいな
568:564
08/05/05 21:33:30
>>566
bucket の番号を用いる例のためだけに、アルゴリズムの細かなことを書くのは
面倒だったから、本当に方針だけを書いたつもりなんだけどなあ。
まず、点を含む領域以外も見ないといけないのはそのとおりで、
ちゃんとやるには、点を含む領域から近い順に探索することになる。
（それまでに見つけた最も近い点までの距離を覚えておき、
見る必要のある領域を限定していく）
見る領域に対応する bucket の番号は、領域の座標値が分かっているのだから
領域座標 → ハッシュ を計算してやった後に ハッシュ → bucket 番号と取得する。
このとき、隣接領域で bucket 番号が隣接している必要はない。
詳しいことは、適当な計算幾何学の本を読んで欲しいところ。
こういうのはバケット法などの名前で知られている割と標準的な技法。
569:デフォルトの名無しさん
08/05/05 21:36:55
えぴが陰毛茫々じゃないから
進みが遅いと思う
570:デフォルトの名無しさん
08/05/05 21:40:38
>>566
いや、だから規格では、同じハッシュ値のキーが同じbucketに入ってるって事ぐらいしか、
規定されてないような気がするんだけど。
似たようなハッシュ値が同じ、あるいは近いオフセットのbucketに入っているかもしれないとは書いてない。
そりゃ、大抵の実装はそうなるだろうけど。
571:デフォルトの名無しさん
08/05/05 21:40:59
間違えた、>>568
572:デフォルトの名無しさん
08/05/05 22:01:44
>>561
URLﾘﾝｸ(cpplover.blogspot.com)
573:デフォルトの名無しさん
08/05/05 22:05:07
>>570
似たような点を同じハッシュにするって話じゃないの？
574:564
08/05/05 22:10:03
>>570
なんで似たようなハッシュ値が近いbucketに入る必要があると思うの？
そういう必要は無いですよ、と588で
> このとき、隣接領域で bucket 番号が隣接している必要はない。
と明記したつもりなんだけどなあ。
具体例で説明すると、たとえば 1000×1000 のメッシュに切って、
(x/1000)×(y/1000) % 100 をハッシュ関数として設定したとしよう。
ここに (10000,10000) の点 p が与えられたとしよう。
この点を含む領域に対応するハッシュ関数値は (10×10) % 100 = 0 だから、
ハッシュ関数値 0 に対応する bucket を持ってくればいい。
(点 p に対して bucket(p) を実行することが、この操作に対応する）
次に、この点を含む領域の左側の領域を調べることにしよう。
左側の領域の座標に対応するハッシュ関数値は (9×10) % 100 = 90
だから、ハッシュ関数値 90 に対応する bucket を持ってくればいい。
（p を左に 1000 だけ平行移動した点 q に対して
bucket(q) を実行することがこの操作に対応する）
575:デフォルトの名無しさん
08/05/05 22:34:13
で、0x関係あんのか
576:デフォルトの名無しさん
08/05/05 22:41:03
>>574
関係ねーだろ10000回染んで来い
577:デフォルトの名無しさん
08/05/05 23:41:50
そんなにdelete thisできないな
578:デフォルトの名無しさん
08/05/06 00:17:58
>>570
つうか、一体何が疑問なんだ
同じハッシュ値のキーが同じbucketに入ってるって事が規定されてりゃ十分だろう
同じハッシュ値になるようにハッシュ関数を作れば同じbucketに分類されるんだから
579:デフォルトの名無しさん
08/05/06 05:45:07
ああ、なるほど。
似たようなキーを同じハッシュにするのか。
それで(x座標値/1000)×(y座標値/1000)だったのか。
580:デフォルトの名無しさん
08/05/06 21:04:03
レベルが高すぎてよくわからん
581:デフォルトの名無しさん
08/05/06 21:05:26
そんなに高くないよ
情報系の学校入れば絶対習う程度
582:デフォルトの名無しさん
08/05/06 21:26:48
学無くても考えれば分かりそうな。
583:デフォルトの名無しさん
08/05/06 22:06:41
修学旅行での温泉の脱衣場の洗濯カゴみたいなもんだ
一つのカゴで一人の美少女中学生をイテレートできる
美少女中学生は控えめだから棚の下の方にハッシュされてるという寸法さベイベ♪
584:デフォルトの名無しさん
08/05/06 22:08:43
下着がなくなってたりするんだな
585:デフォルトの名無しさん
08/05/06 22:54:27
露骨なエロで興奮するあたり、それらが控えられた萌えに欲情する若者とは違うという部分がみえみえなスレだな。
勢力の足りないおっさんが無理にネタ振らなくても良いんだぜ？つまらないだけだから。
586:デフォルトの名無しさん
08/05/07 02:20:45
age
587:デフォルトの名無しさん
08/05/09 03:27:54
>>585
つまらない。
588:デフォルトの名無しさん
08/05/09 09:42:13
どうでもいいよ
589:デフォルトの名無しさん
08/05/14 03:55:48
ここんとこ寒いね
590:デフォルトの名無しさん
08/05/14 04:05:16
うんそうだね
591:デフォルトの名無しさん
08/05/14 04:34:23
今までが暑くて相対的に寒く感じるだけ。
平年並みだろ。
592:デフォルトの名無しさん
08/05/14 21:41:35
それだけ暑いのが続けば「平年並み」の気温も底上げされててもいいんだがなあ。
593:デフォルトの名無しさん
08/05/17 18:02:04
平均気温は過去20年のデータで計算するから、20年間で急激に気候が変動してると追いつかない。
そんだけ温暖化が深刻ってこったな。
594:デフォルトの名無しさん
08/05/17 18:45:41
strong typedef って入るんだったっけ？
595:デフォルトの名無しさん
08/05/17 19:32:54
URLﾘﾝｸ(www.open-std.org)
これか？
入る見込みは無さそうだねぇ。
URLﾘﾝｸ(www.open-std.org)
>Not ready for C++0x, but open to resubmit in future
BOOST_STRONG_TYPEDEFでもつかっておけば。
596:デフォルトの名無しさん
08/05/17 20:20:55
strong typedefってどういう物？
usingとかとは違くて？
597:デフォルトの名無しさん
08/05/17 20:41:23
typedef元とtypedef先が別の型として扱われるというtypedef。
598:デフォルトの名無しさん
08/05/17 20:43:10
C++09 になってんのか、もう。
599:デフォルトの名無しさん
08/05/17 20:58:14
え、まじ？
600:デフォルトの名無しさん
08/05/17 21:12:18
あ、いや、ちゃうわ。ごめん。
601:デフォルトの名無しさん
08/05/17 22:19:45
>>597
それあったらテンプレートがまたワクワクするものになりそうだな
602:デフォルトの名無しさん
08/05/17 22:38:47
数値型の暗黙の変換はC/C++の型システムの穴だから
strong typedef でまずその穴をふさぎたい
603:デフォルトの名無しさん
08/05/17 22:43:14
そんなもん別に機能にしなくてもこれでいいんじゃないの
class AnotherType : public Type{
private:
operator Type(); //実装しない
}
604:デフォルトの名無しさん
08/05/17 22:44:25
そんなこともできるのか。それは欲しい
605:デフォルトの名無しさん
08/05/17 23:11:50
intとかでもやりたいんでは
606:デフォルトの名無しさん
08/05/18 22:50:15
実装あるもんなw
607:デフォルトの名無しさん
08/05/18 23:24:53
もう#define int nanikaしろよ
608:デフォルトの名無しさん
08/05/19 00:05:38
要するにこういうの作ればいいんだろ？
#include <iostream>
#define STRONG_TYPEDEF(base, name) \
template <typename Dummy = void> class name##_ { \
public: \
name##_() { } \
explicit name##_(const base& value) : m_value(value) { } \
base& get() { return m_value; } \
const base& get() const { return m_value; } \
name##_& operator=(const name##_& rhs) { m_value = rhs.m_value; return *this; } \
friend name##_ operator+(const name##_& lhs, const name##_& rhs) { return name##_(lhs.m_value + rhs.m_value); } \
private: \
base m_value; \
}; \
typedef name##_<> name
struct TestBase { void show() { std::cout << "Test" << std::endl; } };
STRONG_TYPEDEF(int, Hoge);
STRONG_TYPEDEF(TestBase, Test);
int main() {
Hoge a(1), b;
b = Hoge(2);
std::cout << (a + b).get() << std::endl;
Test t;
t.get().show();
}
609:デフォルトの名無しさん
08/05/19 07:37:07
手抜きをするためのものなのに、メンバがコピーされないようじゃ意味がない。
610:デフォルトの名無しさん
08/05/21 10:29:55
mailing 2008-05 きてるお
611:デフォルトの名無しさん
08/05/21 11:09:49
^ω^
612:デフォルトの名無しさん
08/05/21 12:32:56
>>610
乙
613:デフォルトの名無しさん
08/05/21 12:37:34
コンテナとかSTLがみんなconcept化されてる！
614:デフォルトの名無しさん
08/05/21 12:42:31
ドラフトは N2606
615:デフォルトの名無しさん
08/05/21 12:48:01
URLﾘﾝｸ(www.open-std.org)
がスゲイ
616:デフォルトの名無しさん
08/05/21 18:04:02
C99と同じ感じになったりしないの？
現行のC++から、この仕様のC++にキレイに置き換わってしまう？
また、複雑難解怪奇な文法を覚え直さなければいけないの？
617:デフォルトの名無しさん
08/05/21 18:49:37
>>616
GCCだけでなくVC++も実装してくると思う、現にTR1も対応しているし。
C99よりは広まると思う。
文法はどうしようもないな。現在でも複雑怪奇なんだから
今さら少しくらい増えたってどうってことないって構えをしたほうがいいかも。
618:デフォルトの名無しさん
08/05/21 18:50:26
better C++03 として使う人が多そうな予感。
auto とかは使うけど・・・って感じ。
619:デフォルトの名無しさん
08/05/21 20:38:48
ぶっちゃけC++が廃れる要因になるだけな気がしないでもない
620:デフォルトの名無しさん
08/05/21 20:49:42
化粧を覚えたてでちょっと厚塗りしてみた美少女中学生のような感じだな
化粧のナイステクを見つけるのが先かこっちが見慣れるのが先かというところか
621:デフォルトの名無しさん
08/05/21 21:21:56
今はネイティブで代わりがないから C++ 一択だけど、ObjCを綺麗にしたようなクラスベースの
言語があれば、もう C++ にこだわる気になれないなぁ。うんざりする
622:デフォルトの名無しさん
08/05/21 21:36:41
Cに速度的な最適化を期待したのが間違いだったんだ。
やるならfortranを++すれば良かったのに。
623:デフォルトの名無しさん
08/05/21 21:38:00
>>622
そこで Fortress ですよ
624:デフォルトの名無しさん
08/05/21 22:35:21
>>621
だからD言語を使えと(ry
625:デフォルトの名無しさん
08/05/21 22:36:59
>>623
あれは数値計算用途以外では使いたい文法でもないけど・・・
それ以前に、なかなか開発進んでなくね？
626:デフォルトの名無しさん
08/05/21 22:40:30
>624
GC がいらない
627:デフォルトの名無しさん
08/05/21 23:09:24
>>616
(ほぼ)今のままのコードで動く。
628:デフォルトの名無しさん
08/05/21 23:10:26
>>626
GCありというか明示的メモリ管理なしのC++ってもの使ってみたい。
DとかJavaじゃなくて、まっとうなC++で。
629:デフォルトの名無しさん
08/05/22 00:25:00
>628
だが、リソース管理は結局自前だろ
ファイナライザは入れないんだよな
630:デフォルトの名無しさん
08/05/22 20:45:13
>>618
現行でC++03としても使えてない奴の方が多いからな
その辺はしゃーない
631:デフォルトの名無しさん
08/05/22 22:04:12
サブセットでヘッダの要らない仕様を作ってくれないかな。
どうせ、プリコンパイルヘッダみたいな事やるんだから、
.cppをプリコンパイルして参照解決したっていいじゃん。
632:デフォルトの名無しさん
08/05/22 22:09:22
そうやってサブセットのスーパーセットを考えてるうちに C# になってしまいました
633:デフォルトの名無しさん
08/05/22 22:12:52
>>631
モジュールシステムを設計しなおすことになると思う
634:デフォルトの名無しさん
08/05/22 22:49:18
仕様を作るのはいいけどさ、
とりあえずその前にほとんどのコンパイラベンダに言いたいんだが
export を実装してくれよ！
Comeau 以外どこか実装してんの？
635:デフォルトの名無しさん
08/05/22 22:51:43
実装が大変な割に大したメリットがないからじゃないの
636:デフォルトの名無しさん
08/05/22 22:54:50
exportの実装がめんどうになった時点で分割コンパイルなんてあきらめればよかったのだ
637:デフォルトの名無しさん
08/05/22 22:59:03
extern inline なんかどこも完全実装できてないしな
Comeauでさえ
638:デフォルトの名無しさん
08/05/22 23:51:17
>>615
提案しているのが Lawrence Crowl だし，ほんの一瞬とはいえ
本気にして「なんだ！？とち狂ったのか！？」とか思った俺涙目ｗｗｗ
639:デフォルトの名無しさん
08/05/23 05:58:24
>>638
ｗ
ま、いつか入るかもな。競合は大丈夫そうだし。
16進浮動小数点数リテラルとか知名度低いのもあるし、こっそり紛れてても誰も騒がないでしょｗ
640:デフォルトの名無しさん
08/05/23 18:12:45
ASCII外の字をプログラム本文に持ち込むことをあっちの国の人らが許すはずがない
641:デフォルトの名無しさん
08/05/23 19:20:22
コメント文字列をプログラム本文とみなすかどうかだが
普通にやってるとチェコ語だかでパース失敗しなかったか？
642:デフォルトの名無しさん
08/05/23 19:26:27
なんだそりゃ。
まさかチェコ語は、スラッシュやアスタリスクにまで独自の文字を割り当てているのか？
643:デフォルトの名無しさん
08/05/23 20:05:42
チェコ語ということはutf-8か？
-Ku は当然付けてるよね。
644:デフォルトの名無しさん
08/05/23 21:06:45
コメントに??付けるだけでおかしくなります
645:デフォルトの名無しさん
08/05/23 22:02:47
もう APL になったつもりで変な字いっぱい使おうぜ
646:デフォルトの名無しさん
08/05/23 22:46:19
トリグラフも迂闊に追加できないこんな世の中じゃ。
647:デフォルトの名無しさん
08/05/23 23:01:50
つまりクアッドグラフが求められる時代になったということですね
648:デフォルトの名無しさん
08/05/23 23:42:00
concept 使った for_each がこう提案されてる
auto がこんな使い方できるんだ
template<InputIterator Iter, Callable<auto, Iter::reference> Function>
Function for_each(Iter first , Iter last , Function f );
役立たずだった auto が大人気だ
649:デフォルトの名無しさん
08/05/23 23:46:41
大人気で広まる
↓
恐ろしい副作用が見つかる
↓
カオス
の黄金パターンですね、わかります
650:デフォルトの名無しさん
08/05/24 00:04:34
>>639
十六進浮動小数点数は、C99由来だから知名度低くても余裕で入るだろ、たぶん。
651:デフォルトの名無しさん
08/05/24 01:17:23
concept のようなメタタイプを持つ言語がほかにあるんでしょうか？
Haskellのほかに
静的型付言語で
652:デフォルトの名無しさん
08/05/24 03:58:02
>>651
conceptの型理論を書いた人たちがGってのを作ったよ。
他にはない。concept_mapみたいなglueがあるのは。
653:デフォルトの名無しさん
08/05/24 11:43:16
conceptの一番の利点はコンパイル時のエラーメッセージ
654:デフォルトの名無しさん
08/05/24 12:39:46
>>653
concept_mapを理解してないね。
655:デフォルトの名無しさん
08/05/24 12:41:52
今度はコンセプトメタプログラミングの時代ですか
656:デフォルトの名無しさん
08/05/24 12:44:38
自然な流れじゃないかな
ジェネリックス系としては
657:デフォルトの名無しさん
08/05/24 14:23:27
そしてC++1xでは
コンセプトの型を規定するスーパーコンセプトが目玉機能になるんですね
わかりました
658:デフォルトの名無しさん
08/05/24 14:32:03
滅多metaな超言語それがC++1x
659:デフォルトの名無しさん
08/05/24 15:10:08
C++ 捨てて別言語使った方がいいんじゃね？
と、マジで思う今日このごろ
660:デフォルトの名無しさん
08/05/24 15:11:07
そんなあなたにC++0x。 もはや別言語だから。
661:デフォルトの名無しさん
08/05/24 15:12:28
まともなC++0x処理系ができるまでは暫く離れるのもいいだろうな
662:デフォルトの名無しさん
08/05/24 15:18:31
C++3xで会いましょう
663:デフォルトの名無しさん
08/05/24 16:09:52
namespaceスコープでアクセス制御が出来たらいいと思わね？
namespace hoge {
private: void priv();
public: void pub() { priv(); }
}
hoge::priv(); // error
664:デフォルトの名無しさん
08/05/24 16:20:34
>>663
入れ子にした無名 namespace で代用できない？
665:デフォルトの名無しさん
08/05/24 16:44:37
>>657
concept はコンセプトをパラメータにとることが出来るのでメタコンセプトは必要ないと思う
666:デフォルトの名無しさん
08/05/24 16:46:20
無名にしなくても、boostの
namespace detail {
はそういうことやってるんだわな。
>>663はスロット単位でやりたいんだろうけど。
667:デフォルトの名無しさん
08/05/24 17:02:23
>>654
「自尊心はあっても自信が無い」から、衝動で突っ込むけど説明添える勇気は無いんですね、わかります。
668:デフォルトの名無しさん
08/05/24 17:51:48
整数のイタレータのサンプルコード見ればいいんじゃない？ > concept_map
669:デフォルトの名無しさん
08/05/24 18:01:51
autoとcenceptでC++も分かりやすい言語になるかなあ。
670:デフォルトの名無しさん
08/05/24 18:04:22
ならんね
671:デフォルトの名無しさん
08/05/24 18:13:27
そもそも、現行C++も分かりやすい言語にするために
突っ走ってきたという面が多かったと思う、D&E読んだ直後の感想。
しかし、現実はと言うと……。
0xも同じ道を辿るに違いない。
672:デフォルトの名無しさん
08/05/24 18:17:27
>>671
> 分かりやすい言語にするために
皮肉とかじゃなく、そうは思えません。
やはりCとの互換性を抑えた上での、実行効率をメインに考えてきたと思います。
673:デフォルトの名無しさん
08/05/24 18:21:59
>>665
ｋｗｓｋ
674:デフォルトの名無しさん
08/05/24 18:42:42
Perl6 の二の舞になる、なんてことはないよな。あはは
675:デフォルトの名無しさん
08/05/24 18:42:58
>>673
やっぱ出来ねえや
勘違い
676:デフォルトの名無しさん
08/05/24 20:09:08
最近は使う人にやさしくなってきてるよね
つらいのはコンパイラベンダやライブラリベンダ
677:デフォルトの名無しさん
08/05/24 20:21:53
ここまで巨大仕様になるともう新規参入とか不可能だよな
678:デフォルトの名無しさん
08/05/27 08:48:19
GCCからforkすればいい。
679:デフォルトの名無しさん
08/05/27 16:55:43
現行の auto って型名のかわりに
auto i = v.begin();
みたいな書き方をする以外に使い方ありますか？
680:デフォルトの名無しさん
08/05/27 19:07:49
型名の現れうる場所全てに現れて
福音と混沌をもたらします
681:デフォルトの名無しさん
08/05/27 20:05:28
>648
682:デフォルトの名無しさん
08/05/27 20:13:09
自動変数の宣言
683:デフォルトの名無しさん
08/05/27 20:13:47
使うだけの人間としては規格の議論より処理系がいつできるかの方に興味がある
684:デフォルトの名無しさん
08/05/27 21:57:30
規格書いてる奴らが作る訳じゃないからな
2020 ぐらいじゃね？
685:デフォルトの名無しさん
08/05/28 09:04:38
だが実装可能性ぐらいは考えて欲しいんだぜ。
686:デフォルトの名無しさん
08/05/28 15:41:55
もう委員会が「完全準拠のコンパイラを最初に作ったチームに賞金」でいいだろ。
商用コンパイラとかだとその賞金が売り上げを下回るっていう可能性もあるから、
MSの無償配布してるものと同じ様なライセンスでなければいけないとかいう条件をつけてさ。
そうすれば販売方法を確立できない個人でも目指す事ができるし、万が一先を越されてしまっても
その場合は販売すれば良い。
687:デフォルトの名無しさん
08/05/28 15:53:55
C++03の下位互換性から考えると、exportも必須なわけか？
そんな非現実的で理想を追求した完全準拠のコンパイラは、まず実用にはならないと思われる。
688:デフォルトの名無しさん
08/05/28 18:07:34
外部テンプレートなんかさっさと規格からぶち殺して
貴重な予約語exportをもっと他の有意義なことに使えるように努力すべき
689:デフォルトの名無しさん
08/05/28 19:47:46
>>686
個人でやれるような範囲の話ではない
690:デフォルトの名無しさん
08/05/28 20:16:07
MSがバイナリインデックスの並び順で特許取っててそこをCOMに使ってるから無理
テーブルを先頭に持ってくるんだったか程度のもの
691:デフォルトの名無しさん
08/05/28 20:22:03
特許なんてそのうち切れるさ
692:デフォルトの名無しさん
08/05/28 22:23:11
vtblを頭に持ってくるって話？
ABIだと思ってたが、特許なのか？
693:デフォルトの名無しさん
08/05/28 23:46:26
>>684
Conceptは、Douglas Gregorが規格も処理系(ConceptGCC)も書いてるよー。
694:デフォルトの名無しさん
08/05/29 00:25:18
そのGCCではあのクソ気持ち悪いラムダ式とかもコンパイルできるのかい
だったらちょっと試してみたい
695:デフォルトの名無しさん
08/05/29 06:43:01
これはconcept branchだから、
他の新標準機能は入ってないよ。
URLﾘﾝｸ(gcc.gnu.org)
lambdaはgcc headで実装始まってるはず。
696:デフォルトの名無しさん
08/05/29 08:49:35
>>686
2100頃までC++は生き残るわけですね分かります
697:デフォルトの名無しさん
08/05/29 11:46:02
std::*Integralが、
std::*IntegralLikeになってやがる。
FloatingPointLikeってなんだよ
// Revision 1の頃から変わっていたのか
698:デフォルトの名無しさん
08/06/04 13:39:48
C++0xはそろそろJavaの時のような誇大広告を始めて盛り上げるべき。
699:デフォルトの名無しさん
08/06/04 13:52:25
どんだけ人集めてもmove semantics見たらみんな引くって。
大衆には見向きもせずプログラミング言語の実験室として頑張っていただきたい。
700:デフォルトの名無しさん
08/06/04 14:03:10
もはや C++ 自体が大衆向けじゃないよな。
でも、必要としている一部の人間のために頑張って頂きたい。ｗ
701:デフォルトの名無しさん
08/06/04 14:05:12
まずはまともな処理系を、話はそれからだ
702:デフォルトの名無しさん
08/06/04 14:11:26
Move SemanticsとかVariable TemplateとかConceptとか、
ライブラリを書く奴のための機能だから、
一般ピーポーが覚える必要は無いんじゃない？
とは言ったものの、どうやって実装しているか分からないと、
俺としては、使う気にならなかったりするから微妙だ。
STLヤベー、超便利ー。
↓
イテレータとか関数オブジェクトとか分からん。勉強するか。
↓
いわゆる、STLの解説本とかではまともに説明されてねー。何コレ。
↓
テンプレート解説本なら詳しく載ってる。やっべ、スゲー詳しい。面白れー。
↓
Boostたのしー。
↓
あれ、当初の目的って何だっけ？
STL？ デザインが貧弱すぎじゃね？ あれって。
703:デフォルトの名無しさん
08/06/04 16:25:03
素人の人たちに受けのいい機能も少し追加されたんじゃない。
auto とか。
704:デフォルトの名無しさん
08/06/04 16:26:10
conceptだってコンパイル・エラー見やすくなるしね。
705:デフォルトの名無しさん
08/06/05 04:01:49
今回は入門者のためにもなる改良がたくさんあるとどこかで聞きました
706:デフォルトの名無しさん
08/06/05 14:58:46
c++であと１０年は持つのかな
すでにフォートラン化しはじめてる？
707:デフォルトの名無しさん
08/06/05 16:44:53
当分、いろんな意味でC++を越える言語は出てこないだろうな。
708:デフォルトの名無しさん
08/06/05 20:08:45
export イラネ
予約語から外してほしい
709:デフォルトの名無しさん
08/06/05 20:23:20
export の実装って結局二度以上同じソースをコンパイルしてるだけだからな
prelink 工程というのがあってそこで全部解決するまで再帰的にコンパイルしつづける
関数がインラインにならないという効果はあるがそれ以上の利益はない気がする
710:デフォルトの名無しさん
08/06/05 21:53:24
>>706
FORTRAN 77とは全然違う。
FORTRAN 77は数値計算の世界では現役のまま陳腐化した。
C++0xは現役のまま最先端を走り続け、プログラマを置き去りにし続けてる。
711:デフォルトの名無しさん
08/06/05 21:55:37
置き去りかよｗ
712:デフォルトの名無しさん
08/06/05 22:04:19
道を踏み誤りつつあるマッドサイエンティストみたいなもんだな
713:デフォルトの名無しさん
08/06/05 22:04:26
exportは後々autoみたいに役に立つ日がくるのでほっといてやってください
714:デフォルトの名無しさん
08/06/05 22:53:05
>>710
> C++0xは現役のまま最先端を走り続け
「他言語に出来ることが出来ないので悔しい」
って、入れた機能がほとんどじゃないかい？
715:デフォルトの名無しさん
08/06/05 22:53:25
>710
Fortran2008は結構強烈だぞ？
716:デフォルトの名無しさん
08/06/05 23:00:35
>>714
conceptはHaskellだけじゃない、似てる機能があるのは。
しかもそれは後から分かったことだし。
traitsを置き換えるために生まれた。
move semanticsだってかなり狂ってるしね。
明示的なメモリ管理がある言語で導入するとは。
717:デフォルトの名無しさん
08/06/05 23:50:13
C++ はあまりお作法がない言語だったと思っていたんだが、今は作法が大杉って困る
718:デフォルトの名無しさん
08/06/06 00:03:11
意味が不明瞭だ
お作法って具体的にはどういうこと？
719:デフォルトの名無しさん
08/06/06 13:01:23
>>713
registerもいつか役に立つ日が来るのでしょうか?
720:デフォルトの名無しさん
08/06/06 13:06:07
>>715
Fortran2008のco-Arrayなんて、
Crayの実装の後追いじゃないですか。
C++0xなんて規格が独走状態ですよ。
一緒にしないでください、失礼です。
721:デフォルトの名無しさん
08/06/06 13:45:38
>>718
俺のエスパー能力を駆使すると、パラダイムをお作法と訳してるんじゃねーの。
禿げ曰く「C++はマルチパラダイム言語だ」と。
パラダイムがないつーか、ひとつに縛らない言語だがな。
パラダイムが何も無いのがすばらしいなら、ifとgotoだけでいいじゃねーかと。
722:デフォルトの名無しさん
08/06/06 16:09:13
規格を崇拝するお前らに楽しい問題。
class string {
public:
string(const char*);
};
void f(string, string, bool = false); // 1
void f(string, bool = false); // 2
void g() {
// どちらの関数が呼ばれるか。
f(“Hello”, “Goodbye”);
}
俺はできなかった。
まあ、Overload Resolutionの厳密なルールを暗記してるわけじゃないし。
答え：URLﾘﾝｸ(blogs.msdn.com)
これをもうちょっと人間的にするために、
なにかプログラマが優先順位を指定できるような機能はつくれないのかな。
723:デフォルトの名無しさん
08/06/06 16:39:20
暗黙的に呼ばれる変換コンストラクタに依存するのはよくないってのは有名な話じゃね。
だれしも一回は引っかかる罠だけどね。
724:デフォルトの名無しさん
08/06/06 17:49:35
その辺いじくるとスマートポインタが軒並みぶっ壊れるから
触れないし触らない方がいい
725:デフォルトの名無しさん
08/06/06 17:52:57
つ f(string("Hello"), string("Goodbye"));
726:デフォルトの名無しさん
08/06/06 18:45:45
正直ついていけてません。すみません orz
727:デフォルトの名無しさん
08/06/06 19:38:40
>>719
もしかしたら、&の使用を制限する目的に使えるかもしれない。
例えば、register int foo して func(& foo) したらエラーになるとか。
で、参照渡しができるのなら、ポインタの使用を禁止できることになる。
# 意味が違いすぎるなw
728:デフォルトの名無しさん
08/06/06 20:37:33
俺も最近まで register に & を付けれないと思ってたけど、
C++ では付けれるらしいよ。
729:デフォルトの名無しさん
08/06/06 20:42:27
もうラムダ式のキーワードにregister使ったらいいじゃん
どうせ予約語の意味なんてメチャクチャなんだから
730:デフォルトの名無しさん
08/06/06 20:42:58
何度も言うようだが inline がいいと思うお
731:デフォルトの名無しさん
08/06/06 20:45:01
却下されたんだろそれ
732:デフォルトの名無しさん
08/06/06 20:47:45
やっぱり解析が凶悪になるからか。
733:デフォルトの名無しさん
08/06/06 22:20:43
>>731
だれか提案したの？
734:デフォルトの名無しさん
08/06/06 22:45:36
ここの誰かが突撃してはいはいﾜﾛｽﾜﾛｽされた
735:デフォルトの名無しさん
08/06/06 22:57:33
キチガイ度で言えば現状もどっこいどっこいだと思うだけどな。
736:デフォルトの名無しさん
08/06/06 23:32:07
最初から頭の使い方が足りなくて狂ってるとしか思えないのと
考えに考えた末に発狂するのとでは筋が違うと思う。
737:デフォルトの名無しさん
08/06/06 23:42:24
オーバーロードは罠が多いから・・
特に特殊化と混じったりするとわけわからん
738:デフォルトの名無しさん
08/06/06 23:54:55
>>734
それどこで？
comp.std.c++ と comp.lang.c++ と流し読みしてるけど、とりあえず見覚えが無い。
739:デフォルトの名無しさん
08/06/07 01:11:13
inlineも規格化前に勝手な独自拡張でｸﾁｬｸﾁｬに使われてきた経緯があるから
あまり触れたくないよな
740:デフォルトの名無しさん
08/06/07 19:41:12
inlineってどうするの?
m = inline (auto x, auto y) { return x > y ? x : y; } (10, 20);
とか?
741:デフォルトの名無しさん
08/06/07 20:23:44
無名関数をinlineと呼ぶのはすげえ違和感がある
742:デフォルトの名無しさん
08/06/07 20:35:49
__lambdaとか_Lambdaでいいからキーワード追加してくれよ。
適当に#defineして使うからさあ
743:デフォルトの名無しさん
08/06/07 21:21:55
別に _Lambda だろうが [&] だろうがいいけど
とりあえず #include <lambda> をくれ。
744:デフォルトの名無しさん
08/06/08 20:07:30
C++03 の extern inline って C++0x にまだ残ってる？
745:デフォルトの名無しさん
08/06/09 15:24:25
>>722
でどっちが呼ばれるの？
ふつーに考えて1でしょ？
(ブーッという音が聞こえてるようだ)
746:デフォルトの名無しさん
08/06/09 15:31:18
失礼、答えつけててくれたんだね。。。
んで、pointer-to-boolなんて知らなかったので、さらに調査中。
昔はほんとにC++好きだったんだけどな。今は規格がぎしぎししてるね。
747:デフォルトの名無しさん
08/06/09 18:31:18
その馬鹿げた変換を何とかするためのnullptrだが
全然何ともなってないといういつものパターンなんだろ
748:デフォルトの名無しさん
08/06/09 19:25:05
もうポインタと整数
整数とbool
は互換禁止にすべきだな
やりたきゃ明示的にキャストしれと
749:デフォルトの名無しさん
08/06/09 19:27:18
if(smart_ptr)が出来なくなるとブーたれる奴らが強硬に反対するので無理です
750:デフォルトの名無しさん
08/06/09 20:17:32
それは暗黙的変換とは関係なくね？
751:デフォルトの名無しさん
08/06/09 20:18:01
NULL と比較しろよ・・・。
ただ、if (T* p = dynamic_cast<T*>(q)) { ... } がやりたいので
無くなると困る。
752:デフォルトの名無しさん
08/06/09 20:47:28
「さらば、式の中でも変数を定義できるようにして進ぜよう！」
753:デフォルトの名無しさん
08/06/09 21:45:57
なんでよりカオスな方向に解決するんだよw
754:デフォルトの名無しさん
08/06/09 22:27:43
オカス！？美少女中学生を！？
755:デフォルトの名無しさん
08/06/09 23:42:09
>>751
は？C++でNULLなんて使うなよ。0を使え。
756:デフォルトの名無しさん
08/06/09 23:48:56
これからはnullptrだろ常考
757:デフォルトの名無しさん
08/06/10 00:34:52
nullptrなんて意味ないよなぁ
どうせ変数に入れたら0と区別付かないからやりたい放題なのに
758:デフォルトの名無しさん
08/06/10 01:41:26
>>755
NULL をどう定義するかは処理系定義で、
整数変数に代入しようとした時に警告出してくれるように
定義してくれてるかもしれないというのに
何で 0 なんて使わないといけないのか。
759:デフォルトの名無しさん
08/06/10 01:42:55
>>758
Effective C++ を100回読め
760:デフォルトの名無しさん
08/06/10 01:49:27
NULLを0以外でdefineしてるC++の処理系なんてものがあったとしたら
今すぐ叩き壊した方がいいよ
761:デフォルトの名無しさん
08/06/10 01:58:26
C++では、マクロを使わない事を推奨されている。なのでNULLよりも0を使う方が綺麗。
もちろん、C++はある程度「綺麗」なスタイルを提示しながらも、そうじゃないスタイルを拒絶することはしない。
better Cとして、例外を使わなかったり、templateを使わなかったり、NULLを使っても良い。
ただし、それが推奨されているわけではないことは覚えておくべき。
762:デフォルトの名無しさん
08/06/10 02:08:51
>>760
g++ は __null で定義されているが・・・。
763:デフォルトの名無しさん
08/06/10 02:35:32
NULL 使ってる人は毎回 cstddef あたりを #include してるのか？
764:デフォルトの名無しさん
08/06/10 03:00:50
>>761
enum{NULL = 0};
765:デフォルトの名無しさん
08/06/10 03:03:49
<template T>
T *NULL(){
return 0;
}
766:デフォルトの名無しさん
08/06/10 07:04:54
NULLより0ってのは、
Effective C++以前のC++ FAQの時代からの常識。
>>759
情けない…このスレに来るのは十年早いよ。
767:デフォルトの名無しさん
08/06/10 07:20:10
>>763
NULL は結構色んなヘッダファイルで定義されてるので
cstddef をインクルードするまでもないことが殆ど。
768:デフォルトの名無しさん
08/06/10 07:24:44
Effective C++ と C++ FAQ の説明内容に違いはあるの？お爺様
769:デフォルトの名無しさん
08/06/10 07:28:50
相変わらず破綻してる言語だな
770:デフォルトの名無しさん
08/06/10 07:29:45
>>765
それだとメンバへのポインタに対応できない気がする。
771:デフォルトの名無しさん
08/06/10 08:42:09
定期的に低レベルの話題で荒れるな
772:デフォルトの名無しさん
08/06/10 08:50:23
>>767
実際のコンパイルでエラーになるまで対応するヘッダをインクルードしないってこと？
ライブラリの実装に依存してそうでイヤじゃない？
773:デフォルトの名無しさん
08/06/10 09:37:26
>>771
低レベルの質問にはよく答えられる低の高くらいのレベルの人が多いんですよ。
おいらも含めて。ｗ
774:デフォルトの名無しさん
08/06/10 10:47:54
低の高っていうと
エントリーモデルの中で頭一つ出た商品みたいで所謂人気商品ってイメージ
775:デフォルトの名無しさん
08/06/10 11:16:08
ある意味正しいな。
今は、プレミアム系商品の人気が高くなっている辺りも含めて。
776:デフォルトの名無しさん
08/06/10 14:01:46
C--
777:デフォルトの名無しさん
08/06/10 15:27:35
>>776
廃れたね。
JVMもCLRもなければ主流になったかも知れないのに。
778:デフォルトの名無しさん
08/06/10 16:32:19
>>772
規格でどのヘッダがNULLを定義してるか決めてあるでしょ。
779:デフォルトの名無しさん
08/06/10 17:05:26
>>772の言っているのは、
使うなら、定義されてるヘッダを必ず明示的にインクルードしないと、
コンパイル通っても、実装依存なコードだってことでしょ。
実際多いよね、そういうコードは。
実装上の都合による孫インクルードに依存しているコード。
780:デフォルトの名無しさん
08/06/10 17:37:45
>>779
多いね。
うっかりやることもあるので、ちゃんと警告するシステムが欲しい。
（あるのかな？）
781:デフォルトの名無しさん
08/06/10 17:43:48
NULLはプリプロセッサマクロだから使うなと言う舌の根も乾かぬうちに
#includeの話題で盛り上がってるあたりC++の病巣がよく表れている
782:デフォルトの名無しさん
08/06/10 17:45:27
#include を使わずに済むしかけを入れて欲しかったな＞C++0x
783:デフォルトの名無しさん
08/06/10 17:50:06
シンボルだけを読み込む機能は確かに欲しいが、
いまさらC++に入れるくらいなら俺はDを使うわ。
784:デフォルトの名無しさん
08/06/10 17:52:09
標準ヘッダーファイルの拡張子を無くしたときにやるべきだったな
785:デフォルトの名無しさん
08/06/10 18:46:50
>>784
標準の拡張子無しのヤツはヘッダっていうんじゃなかった？
自分で作ったらヘッダーファイルだっけね。
786:デフォルトの名無しさん
08/06/10 20:53:48
ヘッダはファイルである必要は必ずしもないという実装者を挑発するルールです
787:デフォルトの名無しさん
08/06/10 21:00:08
Windows使っている俺は、実際のファイル名をヘッダ名と同じにしないでくれと思っている。
具体的に言うとファイル名に拡張子ほしい。<ios>でios.hppを探しに行くような感じで。
拡張子のないファイルは扱いが面倒臭い。
関連付け以外にも、色分けなどのために拡張子で種類を判別するエディタの多いこと。
788:デフォルトの名無しさん
08/06/10 21:19:21
ヘッダファイルにエディタへのヒントとして、ファイルタイプを書くか、
副次ストリームに書く。
エディタはそれを読んで判断。
789:デフォルトの名無しさん
08/06/10 21:41:22
ハードリンクでも張っとけばいいんじゃない？
790:デフォルトの名無しさん
08/06/10 23:15:03
副ストリームって最近冷遇されてる気がするなあ
791:デフォルトの名無しさん
08/06/10 23:17:46
><ios>でios.hppを探しに行くような感じで
でも結局iosのファイルの中身は
#include <ios.hpp>
だけだったりするんだよね
792:デフォルトの名無しさん
08/06/10 23:29:30
0xが正式に導入されたら、今ある入門書って買い換えなきゃいけない？
793:デフォルトの名無しさん
08/06/10 23:31:43
入門レベルなら大して変わらないかと
794:デフォルトの名無しさん
08/06/10 23:38:16
「対して変わらない入門書」なんてものは悪書としか言いようが無い。
C++標準化後にどれだけ旧態然とした入門書が悪影響を与えたか。
795:デフォルトの名無しさん
08/06/10 23:54:23
正式導入されたとしても、
結局 VC++ が無視したら広まらないんだろうな。
C99 みたいに。
796:デフォルトの名無しさん
08/06/10 23:56:17
既にTR1入れてるぐらいだし、比較的早めに0x対応するのではないかと楽観視している
797:デフォルトの名無しさん
08/06/10 23:58:18
STLの書き換えがダルそうだよな
俺らは使うだけだけど
798:デフォルトの名無しさん
08/06/11 00:00:01
どうせ書くのはdinkumwareだろ
MSじゃなくてさ
799:デフォルトの名無しさん
08/06/11 00:00:45
まあ TR1 くらいなら特にコンパイラいじる必要もないから簡単に入れれるけど、
言語仕様に手を入れるのはどうなんだろうね。
VCEE の C++ の力の入れ具合が 2005 で微妙だったのが（デフォでは Platform SDK なし）
2008 で微妙に改善されたので（デフォで Windows SDK あり）
もしかしたらやる気があるのかもしれない。
800:デフォルトの名無しさん
08/06/11 00:16:03
>>799
TR1だってispodとかコンパイラに手を入れないと無理なのもある。
ところで、もしVC++がExpressだと0x使えないって言われたら
喜んでStandard買いそうな気がしてならない。
そんときゃg++で我慢すればいいはずなのに。
801:デフォルトの名無しさん
08/06/11 00:16:59
で、結局入門書は買いなおしたほうがいいんだな？
802:デフォルトの名無しさん
08/06/11 00:19:50
しばらくは取って付けたような入門書ばかり出るんだろうけどね。
803:デフォルトの名無しさん
08/06/11 00:20:53
入門書なんてvarとshared_ptrあたりをさわるので精一杯じゃね
804:デフォルトの名無しさん
08/06/11 00:22:39
var じゃなくて auto じゃね
805:デフォルトの名無しさん
08/06/11 00:23:59
autoとヌルポは絶対教えるだろ。
あとはinitializerでのコンテナ初期化と範囲forとか
806:デフォルトの名無しさん
08/06/11 00:27:12
どうせ数ページ書き直しただけで「C++0x対応・全面改訂版」とかって帯付けて売るんだぜｗ
807:デフォルトの名無しさん
08/06/11 00:29:05
欄外に「新しいC++の規格ではこのように書くことも出来るようになりました」って注釈つけて終わりにしたりな
808:デフォルトの名無しさん
08/06/11 00:31:26
D&E 2015年版が出るなら絶対買う。
809:デフォルトの名無しさん
08/06/11 00:43:26
地味だけどlong longは間違いなくとり上げられる。
810:デフォルトの名無しさん
08/06/11 00:48:09
>>799
けどC++/CLI蹴られたし、ISO C++からは離れるかもね。
811:デフォルトの名無しさん
08/06/11 00:53:26
>>809
型の種類と値の範囲の表をちょっと増やすだけだもんなｗ
個人的にはUTF文字列をまともに扱って欲しい
812:デフォルトの名無しさん
08/06/11 18:58:03
美少女中学生にしてみれば下着の種類が増えるだけだからな
外に出るときの見た目は変わらない
813:デフォルトの名無しさん
08/06/11 19:48:21
対応したコンパイラって、すぐ出るのかな？
814:デフォルトの名無しさん
08/06/11 19:49:30
gccとか既に一部対応してるから、規格になることには全部対応してるんじゃね？
815:デフォルトの名無しさん
08/06/11 19:53:42
ふむ。
gccぶち込んでみるかな。
816:デフォルトの名無しさん
08/06/11 20:54:49
139 名前：デフォルトの名無しさん[sage] 投稿日：2008/06/11(水) 20:50:38
どうでも良いが個人的にまつもと氏に0xに改善されても尚C++が問題外かどうかを訊ねたい。
817:デフォルトの名無しさん
08/06/11 21:31:56
>>816
もっとだめと言うに100万ペリカ
ところで初心者向けと言えば、やっぱりテンプレート絡みの
エラーメッセージがまともになるという1点においてコンセプトが
一番簡単にアピールできる機能だと思う。
コンセプト自体は、入門書で取り上げられるような内容ではないだろうけど。
818:デフォルトの名無しさん
08/06/12 08:16:26
禿は0xむけに第4版出すんだろうか
819:デフォルトの名無しさん
08/06/12 10:28:13
第4版よりD&Eの第2版がほしい
820:デフォルトの名無しさん
08/06/12 14:25:24
D&Eの続編書いて欲しいな。別の本で。
>>693のGregorとか。
一人で大幅な改訂してる暇はたぶんないだろ。
WG21 papers、かなり名前出てくてるからな。
821:デフォルトの名無しさん
08/06/12 14:26:54
Wikiを読んでいると、「うざくなって？」って、思えてきたのですが、
そんなことない？
822:デフォルトの名無しさん
08/06/12 14:32:27
日本語でおｋ
823:デフォルトの名無しさん
08/06/12 16:20:39
美少女中学生が携帯で書き込んでいるようだな
824:デフォルトの名無しさん
08/06/12 17:13:20
>>823
ぼっぼくと付き合ってくださいっ！
825:デフォルトの名無しさん
08/06/12 18:01:42
>>824
文脈的には>>821が美少女中学生だと思う
TC++PLやD&Eの続編って書く予定ないのかな と思って禿のページ見に行ったら
なんかいまC++の入門書書いてるみたいだね
826:デフォルトの名無しさん
08/06/12 18:30:15
VCって、どこまで対応させるのかな～？
827:デフォルトの名無しさん
08/06/12 20:21:40
>>825
おお、それは期待したい
828:デフォルトの名無しさん
08/06/12 20:21:56
テンプレートだって未だにまともになってないのに
そこにコンセプトなんか追加したらどうなることやら
829:デフォルトの名無しさん
08/06/12 22:22:58
「もう美少女中学生とかどうでもいいだろC++0xの話をしろよ」と書き込もうとしたけどやめた。
830:デフォルトの名無しさん
08/06/12 22:24:03
やめろよ
831:デフォルトの名無しさん
08/06/12 22:31:25
「もう美少女中学生とかどうでもいいだろC++0xの話をしろよ」っていう書き込みを見て「やめろよ」と書き込もうとしたけどやめた。
832:デフォルトの名無しさん
08/06/12 22:33:18
C++0xは美少女中学生萌え言語ですよ？
833:デフォルトの名無しさん
08/06/12 22:35:17
C++0xと美少女中学生には全く関連性がありません！
両者が結びついているかのような書き込みは控えてください！迷惑です！
ここはC++0xのスレッドです！C++0xの話をしてください！
美少女中学生の話がしたければどこかよそでやってください！
834:デフォルトの名無しさん
08/06/12 22:39:31
えぇーまじでぇー
835:デフォルトの名無しさん
08/06/12 22:55:11
C++0xなら美少女中学生なんてコンパイル時にゲットできる
836:デフォルトの名無しさん
08/06/12 22:56:41
NGワード : 少女
837:デフォルトの名無しさん
08/06/12 22:57:56
>>835
コンパイルに何年かかるんだ？
838:デフォルトの名無しさん
08/06/12 22:58:14
>>828
コンセプトが追加されてはじめてまともになるんじゃないか。何を言ってるんだ
839:デフォルトの名無しさん
08/06/12 23:37:42
>>838
紫の上のコンパイルはたった４年です。
840:デフォルトの名無しさん
08/06/13 21:31:21
>>784
拡張子をなくした理由ってなんだろ？
841:デフォルトの名無しさん
08/06/13 21:32:15
>>792
いつまで入門者でいるつもりなのかなー
842:デフォルトの名無しさん
08/06/13 21:38:19
>>840
ヘッダはファイルである必要は無い
とか言えるようにするため。
843:デフォルトの名無しさん
08/06/14 00:34:50
.hまで含めて名前です。とかでもよかったじゃん。
844:デフォルトの名無しさん
08/06/14 00:36:53
互換性を失う変更を導入するための苦肉の策だったのだと思う
845:デフォルトの名無しさん
08/06/14 00:37:26
名前空間の無い時代に
#include <iostream.h>
int main() {
cout << "hoge" << endl;
return 0;
}
とか書かれたプログラムが大量にあってだな・・・。
それとの互換性を考えると名前を変えざるを
846:デフォルトの名無しさん
08/06/14 10:06:58
ほんっとしがらみいっぱい過ぎだよな。
847:デフォルトの名無しさん
08/06/14 10:11:18
互換性無視してしがらみ全部捨てたC++欲しいよな。
特に暗黙の型変換辺り。
ちなみにDなら不要だよ。
848:デフォルトの名無しさん
08/06/14 10:12:46
Dは自分でしがらみ作りまくったりしてるからな・・・
時には思い切って捨てたりしてるけど（信者を）それが逆にしがらみになってる。
849:デフォルトの名無しさん
08/06/14 10:25:48
>>847
仕様だけでも作ってくれ
850:デフォルトの名無しさん
08/06/14 10:28:12
>>847
暗黙関係はトラブルの元だからどうにかしたいな。暗黙関係は警告を出すオプションが欲しい。
デフォルトのコピーコンストラクタが作成できませんなんて余計な警告はあるのになんでないんだ？＞ＶＣ８
851:デフォルトの名無しさん
08/06/14 10:52:11
明示的なメモリ管理ができないC++とか
その場合でもmove semanticsは面白いこと出来ると思う。
852:デフォルトの名無しさん
08/06/14 14:27:37
暗黙の型変換を全部禁止したらどうなるのかな
double d = 1;
とか
Base *b = new Derived();
とかが全部エラーになるんだよな
853:デフォルトの名無しさん
08/06/14 14:29:42
アップキャストは安全なキャストだから禁止する必要もあるまい。
854:デフォルトの名無しさん
08/06/14 14:33:28
安全だろうと何だろうと、何かの暗黙の変換を認めたら
あれも認めろこれも認めろと言うキチガイが出てくるので全て禁止です
そういう思想で作られてる言語ねえのかな
855:デフォルトの名無しさん
08/06/14 14:42:53
OCaml は結構型に厳しかったと思う
856:デフォルトの名無しさん
08/06/14 15:20:30
double d = 1;
は実質
double d( 1 );
と同じだから明示的な変換を表しているんじゃないか?
857:デフォルトの名無しさん
08/06/14 15:22:16
暗黙的なコピーコンストラクタの実行をやめてくれって話じゃなかったのか
858:デフォルトの名無しさん
08/06/14 15:29:26
explicit でおkだっしょ
859:デフォルトの名無しさん
08/06/14 15:41:09
デフォルトのコピーコンストラクタはどうかなあ。
860:デフォルトの名無しさん
08/06/14 15:42:31
ああ、コピーコンストラクタの話か。
0x 的には = delete してくれってことじゃないのかな。
861:デフォルトの名無しさん
08/06/14 15:44:38
組み込み型の暗黙の型変換が結構うざいんだよな。
特にポインタ、文字型、論理型が整数様型と絡むと。
862:デフォルトの名無しさん
08/06/14 15:46:08
explicit をデフォルトにしてほしかった。
863:デフォルトの名無しさん
08/06/14 15:47:36
schemeみたいに簡単に方言作れるkitがあればいいのにな。
864:デフォルトの名無しさん
08/06/14 15:55:09
>>862
それはよく思う。
でも、今更変えらんないんだろうなあ。
865:デフォルトの名無しさん
08/06/14 15:57:43
Javaはreflection APIがあるから、
言語拡張＆コンパイラ実装の研究がどんどん進んでいるね。
866:デフォルトの名無しさん
08/06/14 23:38:08
セックスプリプリシット？
867:デフォルトの名無しさん
08/06/15 09:46:35
虚しいオッサンの虚しい書き込みが続いております
868:デフォルトの名無しさん
08/06/16 13:47:36
>>865
OpenC++の中の人も今はOpenJavaやってるね。
869:デフォルトの名無しさん
08/06/17 06:06:45
クラスの内部ポインタを交換するような例外安全な swap を書くとき
それを std 空間に template <> swap( .. ) と逐一定義しないと std::swap から呼ばれない。
理屈はわかるんですけど、なんとかならないですかね。
一々 namespace std { template <> swap( うんたらかんたらと書くのが面倒くさいです。
870:デフォルトの名無しさん
08/06/17 06:50:04
クラステンプレートならどうにもならない
871:デフォルトの名無しさん
08/06/17 12:24:39
自分の場合は using std::swap してから swap() を呼び出しているので
クラスと同じ名前空間に swap() を定義している。
872:デフォルトの名無しさん
08/06/17 21:01:32
swapなんか使わない設計にしなさい
873:デフォルトの名無しさん
08/06/17 21:08:06
そうですね。
これからは右辺値参照の時代ですもんね。
874:デフォルトの名無しさん
08/06/17 23:41:59
swapを使おうとする前に、一度立ち止まって
自分が値をあべこべに格納していないか考え直しなさい
Bjarne Stroustrup
875:デフォルトの名無しさん
08/06/18 00:38:14
>>869
恐らくどうしようもないかと思います．
さらに， std 名前空間以外の名前空間で定義された関数テンプレート
(クラステンプレート内で定義されてた非テンプレート関数もこれに準じますが)
において， unqualified call で swap が呼ばれる場合にも対応しようとすると
クラスと同じ名前空間にも swap を定義しなければいけなくなります．
現時点において，規格として std 名前空間で定義された関数テンプレート内で
>>871 さんの提言する実装 (using std::swap;) が行われている保証が無いことが
本質的な問題だと思います．ただ，ここに文句を言っても現時点での問題は
何も解決されませんので，とりあえずの次善策として， std::swap の特殊化と
associated namespace に swap を定義することの両方を実施することを
個人的には勧めておきます．「面倒くさい」という問題の解決にまったくなっていませんが．
さらに >>870 さんの言うように，クラステンプレートの場合には
根本的な解決策はないです．
>>873
move できるかどうかは， swap できるかどうかとは本質的には独立で，
特に move が可能になるためには，オブジェクトに valid resourceless state が
存在することが必要になり，これはやや強い制限だと思いますから，
move はできないけれども swap はできるという状況は比較的容易に起こりえると思います．
なので， move さえあれば良いということは必ずしも言えないかと思います．
876:デフォルトの名無しさん
08/06/18 00:51:43
concept HasSwapFunction<typename T> { T& swap(T&) throw (); }
template <typename T> requires HasSwapFunction<T>
inline void swap(T& x, T& y) throw () { x.swap(y); }
template <typename T>
inline void swap(T& x, T& y) throw () { std::swap(x, y); }
↑ こういう感じのってダメなの？よくわからんけど…
877:デフォルトの名無しさん
08/06/18 01:00:17
>>876
template<HasSwapFunction T>
concept_map Swappable<T> { void swap(T &x, T &y){ x.swap(y); } }
多分，こんな感じで concept_map で差異を吸収したほうが楽なのではないかと．
878:デフォルトの名無しさん
08/06/18 02:03:49
交換も、コピーコンストラクタや代入演算子と同じように扱えばシンプルになると思うんだけど
・デフォルトはクラスが定義するswapを実行する
・swapが実装されていなければ、言語側で一時オブジェクトを作り処理する
とできないのかな
実装で埋めようとして複雑になっている印象がありますが
879:デフォルトの名無しさん
08/06/18 04:23:08
Namespace issue with specialized swap
URLﾘﾝｸ(groups.google.ca)
880:デフォルトの名無しさん
08/06/18 10:07:18
for文の改良ってしないの？
881:デフォルトの名無しさん
08/06/18 11:18:58
foreachってC++0xになかったっけ？
882:デフォルトの名無しさん
08/06/18 16:00:02
入ったよ。
for (int &entry: aContainer) { ... }
Javaのクロージャを引数に取る拡張に比べるとつまらない。>>48
C++的には最悪のセンスだと思う。
883:デフォルトの名無しさん
08/06/18 17:41:05
Javaから構文パクるなんてC++も地に墜ちたもんだな
884:デフォルトの名無しさん
08/06/18 17:58:22
まあでもC++にeachとかinとかのキーワードを入れるのも有り得ないだろうし、
これくらいしか書きようがないと思う。
885:デフォルトの名無しさん
08/06/18 18:00:07
ところでこのループ変数は参照なの？
参照が指す先変えながらグルグル回るの？
キモッ
886:デフォルトの名無しさん
08/06/18 18:21:35
別にキモくはないだろ。
従来の、for無いのスコープで参照変数を宣言してるようなもの。
887:デフォルトの名無しさん
08/06/18 18:29:26
for (int &&entry: aContainer) { ... } はあり?
888:デフォルトの名無しさん
08/06/18 18:55:18
ぅん・・・
889:1/2
08/06/18 19:11:15
昔々、Sunにとある厨が居た。
彼はＣ言語の研修でポインターでつまづくような無能で、無論Ｃ＋＋など理解出来なかった。
プログラマーとしては全く使い物にならんということでネットワークエンジニアとして使われていた。当然役には立たなかったが、サーバー運びや配線や小間使いぐらいは出来た。
この世にポインターがあるから自分がそんな境遇に陥ったのだと不満を募らせた彼はポインターを憎悪し、ポインターの無い言語があればいいのに、と夢想するようになった。
彼はその夢想言語をJAVAと名付け陳腐な企画書を出したが、すべて無視された。
そんなある日、どうせ役には立たないんだからと、しつこいNetscape社の営業を追い払う仕事を任された。もちろん権限は一切なく、ただNetscape社の営業の話相手をし、すべてを断るだけの仕事だ。
彼は毎日のようにNetscape社の営業と無駄話をした。彼にとってそれは、愚痴や不平不満をこぼす絶好の機会だった。
Netscape社の営業は当然のように彼に同意した。彼の境遇に同情し、彼の才能を認め、褒め称えた。
そして誰も耳を傾けなかった夢想言語JAVAの話になるとNetscape社の営業は強い興味を持ち、ブラウザーに搭載したいと言い出した。当時のNetscape社は、動きのあるページを作る案を求めていた。
夢想言語JAVAが現実のものになる。彼は天にも昇る気持ちになり、全面的に協力を申し出た。が、やはり何の役にも立たなかった。すべての設計、策定、実装はNetscape社によって行われた。
Netscape社は、夢想言語JAVAを「何処でも全く同じに動く言語」としてブラウザーに搭載しようとしたのだ。
これを聞いて驚いたのはSunの役員達だ。直ちにNetscape社と交渉し、JAVAはそもそもSunのものであることを主張し始めた。
交渉の結果夢想言語JAVAの最初の実装はJavaScriptと改名することになり、SunのJAVAとは独立したNetscape社の言語となった。
890:1/2
08/06/18 19:11:45
Sunは直ちに「何処でも全く同じに動く言語」の現実性を調査し、仮想マシンを使うことで可能であることを検証した。
また夢想言語JAVAの詳細を厨に尋ね、規格をまとめ……ようとした。というのは、厨の頭の中には「ポインターを使わない」の他には支離滅裂な妄想以外何も無かったからだ。
役に立たない彼を「夢想言語JAVAを広める為の広報」に追い出し、夢想言語JAVAではなく現実的なJAVA言語の設計が行われた。
だが現実的設計にはいろいろと難があった。その度に開発部は厨に尋ね、その意向を可能な限り反映する努力を行った。しかし無能な厨の意向を反映することは困難を極めた。
その中で最も大きな障害となったのが、多重継承の禁止である。
未だにSunは公式に認めていないが、JAVAが多重継承を禁止する決断をさせたのは、実はMicrosoftの寄与するところが大きかった。
Microsoftは既にMFCとCOMによって多重継承が抱える問題を解決していたからである。
その後も厨は（何度出入り禁止を喰らっても）設計に口を出し、そして開発部はその意向を可能な限り反映する努力を行ない続けた。
特に厨が主張するコーディング規約は支離滅裂を極め、ゴスリンは「それまでに書かれたコードを書き直す量が最も少なくなるコーディング規約」をまとめる必要に迫られた。
この時にまとめられた何の意味も無いコーディング規約は後に、それを知らなかった企画部によって改めてまとめられJAVAの標準のコーディング規約として発表された。
ゴスリンはこの時の心境を「JAVAが最高だと生涯言い張り続ける覚悟を決めた」と述懐している。
厨は熱心に広報活動を行っていたが、役に立ったのは最初だけだった。すごい言語が出来る、ということを印象付けた後は、何の役にも立たなかった。
開発には近寄ることすら許されず、広報からは役立たずの烙印を押された。彼は再びネットワークエンジニアとして保守管理部に戻った。
今では彼は毎日何百ものＬＥＤを見張って、消えたらそれに対応するハードディスクドライブを交換する仕事をしていると言われている。名前は記録されていない。
891:デフォルトの名無しさん
08/06/18 19:12:40
ついに参照の指し変えが認められてしまったのか…
892:デフォルトの名無しさん
08/06/18 20:18:37
>>875
valid resourceless state てなーに？
893:デフォルトの名無しさん
08/06/18 22:24:14
Java の参照型はまさにポインタだろうが・・・。
894:デフォルトの名無しさん
08/06/18 22:26:03
NullPointerExceptionがあるしな
895:デフォルトの名無しさん
08/06/18 22:26:50
Javaの参照型はインクリメントできる？
896:デフォルトの名無しさん
08/06/18 22:28:34
>>893-895
ネタにマジレスｗ
897:デフォルトの名無しさん
08/06/18 22:29:56
マジレスもできない奴は板を替えたほうがいい
898:デフォルトの名無しさん
08/06/18 22:30:34
ネタにマジレスするのが最近のトレンドなんだぜ
899:デフォルトの名無しさん
08/06/18 22:37:47
ネタに、というよりホラにマジレスだな
900:デフォルトの名無しさん
08/06/18 22:38:24
>>892
d = std::move(s);
という構文が実行された直後の s の状態が明確に定義されていなければならないですが，
この状態は有効な状態でなければならず，かつ，
いかなるリソースの所有権も保持していないような状態でなければならないです．
これを valid resourceless state と表現していました．
有効な状態 (valid) でなければならないというのは，
move された直後の s に対しての操作が
well-defined でなければならないという要請を表現したものです．
少なくとも最低限かつ自明の要求として，いかなるタイミングでも
デストラクタの発動は有効に機能しなければならない，という意味で
有効な状態でなければならないことは分かるかと思います．
また， move は no-fail，つまり失敗しない操作であることが要求されます．
ここで仮に move 直後の s が何らかのリソースの所有権を保持した状態であるとすると
s が保持するリソースの確保において失敗が発生する可能性があり，
move が no-fail であるという要求と矛盾します．
従って， s はいかなるリソースの所有権も保持していない状態
(resourceless) である必要が出てきます．
一般に，オブジェクトが常に何らかのリソースを確保している状態であることが自然な場合，
このようなオブジェクトに move の操作が行えることを要求すると，
オブジェクトの構築は完了しているがリソースの確保が完了していない
オブジェクトの状態を有効な状態としてユーザに暴露しなければならなくなり，
RAII の観点から見てやや大きな弱点を生じるように思います．