トップページ⇒tech
1002コメント443KB

オブジェクト指向システムの設計 [無断転載禁止]©5ch.io

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2016/05/19(木) 22:07:47.87ID:9fCVrsOw
手順とかノウハウとか語りたい
0002デフォルトの名無しさん2016/05/19(木) 22:30:15.79ID:7RT/6RIS
まず服を脱ぎます
0003デフォルトの名無しさん2016/05/19(木) 23:11:13.52ID:DISKdlQR
パンツを脱いだプログラマ
0004デフォルトの名無しさん2016/05/19(木) 23:13:39.91ID:QjLNgnwx
>>1
ノウハウや成果物は20年前と比べて随分と公開されていると思うが。
スモールオブジェクトプログラミングとかGRASPとかエクササイズ等等。
0005デフォルトの名無しさん2016/05/19(木) 23:14:14.30ID:P4wIeaTA
デザインパターンを研究しろ。

■■■■ 糸冬　了 ■■■■
0006デフォルトの名無しさん2016/05/19(木) 23:19:53.32ID:QjLNgnwx
今の時代、冗談抜きで語る事はないよ。国内の有識者がまとめた資料(SlideShare等)を
読むだけ。
0007デフォルトの名無しさん2016/05/20(金) 01:27:57.35ID:0eowHHkD
実務での設計・構築経験がある奴はいないのか？
誰かがこう言ってるじゃなくて、経験談を語り合いたい。
0008デフォルトの名無しさん2016/05/20(金) 06:37:23.45ID:A9KUpz/E
経験談を語る＝有識者がこう言ったという事を蒸し返すだけだけど。
0009デフォルトの名無しさん2016/05/20(金) 06:46:44.02ID:A9KUpz/E
後、今はこの手の話題はTwitterの方が向いている。
2chは発言の質が玉石混合であんまり参考にならない。昔は
いろいろスレが立っていたが。
　
　ちなみにドメインモデル周りの成果物は機密保持の関係上、
あまり表に出てこないかな。
0010デフォルトの名無しさん2016/05/20(金) 08:18:55.59ID:fT3/H/UL
ドメインモデルの進化系がマイクロサービスだと思っている
0011デフォルトの名無しさん2016/05/20(金) 09:38:37.61ID:ezy2NA/m
>>10
進化系というかDDDでいうところの境界づけられたうんちゃらをマイクロサービスとして分離する基準にするとちょうどいいってだけだよね。
最近の小規模プロジェクトでもマイクロサービスを気軽に導入しちゃう雰囲気は謎。マイクロサービスをOOPとかと同列のソフトウェアデザインと考えている人が多いからなのか。
0012デフォルトの名無しさん2016/05/20(金) 11:45:46.78ID:0eowHHkD
本に書いてある指針に沿ってやってみても役に立つ部分と足りない部分がある。
実体験と本を読んだだけとは大きな違い。

例えば、オブジェクトの抽出はどうやってる？
仕様書から名詞を洗い出すとか言われることが多いけど、
すべての名詞がオブジェクトに対応する訳じゃない。
オブジェクトとする基準とかレベルとかどんな感じでやってる？
0013デフォルトの名無しさん2016/05/20(金) 12:59:06.12ID:tPlPBHxz
分かりやすい名前をつければ、後は大した問題ではない
0014デフォルトの名無しさん2016/05/20(金) 13:01:40.82ID:0eowHHkD
そんなんでシステムが構築できると思ってるのか？
0015デフォルトの名無しさん2016/05/20(金) 13:42:47.84ID:jCV1qcCq
確かに

全ての変数に分かりにくい名前をつける事を強要された挙句
その名前をデータベースと言う名の紙の辞書に登録しなきゃならないっていう環境で起こる問題に比べたら
大した問題じゃないよな
0016デフォルトの名無しさん2016/05/20(金) 13:42:47.94ID:xL1EKSbm
サルでも解るように教えてくれ
0017デフォルトの名無しさん2016/05/20(金) 13:44:27.63ID:jCV1qcCq
>>16
考えるな、感じろ

直感と経験からオブジェクトにするものとクロージャにするものとを区別していけば
大きく間違えることはそんなに無い
0018デフォルトの名無しさん2016/05/20(金) 13:47:05.45ID:0eowHHkD
直感と経験って説明できないときに都合よく使う言葉だよなあ。
そんなんじゃ判断はばらばらになって品質が安定しない。
だからプロセスとか指針が重要なんだが。
0019デフォルトの名無しさん2016/05/20(金) 13:54:08.42ID:jCV1qcCq
例えば飛行機の制御プログラムを組むとして、
そのプロセスやら指針やらはサルでも分かるようにきちんと説明できるの？
0020デフォルトの名無しさん2016/05/20(金) 13:55:31.32ID:0eowHHkD
サルでも分かるようにってのは俺の書き込みじゃないから知らんけど
ある程度の知識がある奴が理解できる指針は提示する必要があるだろ。
0021デフォルトの名無しさん2016/05/20(金) 13:57:21.26ID:jCV1qcCq
もう一点。
複数のプロダクトの設計段階での判断がプロダクト毎に異なる事と、
それらプロダクトの品質とは関係あるの？
0022デフォルトの名無しさん2016/05/20(金) 13:59:42.00ID:jCV1qcCq
>>20
うん、必要があるか、無いか、で言ったら必要あるよね。
それが実行可能かどうかについて訊いたんだけどね。
0023デフォルトの名無しさん2016/05/20(金) 14:03:06.56ID:0eowHHkD
お前が指針を提示できないことは分かったからいいよ。
まともな本を読んでりゃ指針が書かれていることくらい分かるから。
0024デフォルトの名無しさん2016/05/20(金) 14:07:35.14ID:6MfCjgLg
>>13
正解。設計と同じぐらい大事。
現場ではエンジニアが自由に名前決めすぎ。
0025デフォルトの名無しさん2016/05/20(金) 14:08:53.28ID:jCV1qcCq
君が「本に書かれてるから絶対に正しいんだ」って姿勢を見せるのは結構な事だけど
質問に対する答えとして不適切な事を言っておきながら答えたことにするのは人間としてどうかと思うよ。

ちなみに
直感と経験、を具体的に言うと
動作の主体になって、状態を持つものはオブジェクト
動作の客体にしかならないものはクロージャ
みたいな感じに分けてるよ。
直感的でしょ？
0026デフォルトの名無しさん2016/05/20(金) 14:14:49.64ID:0eowHHkD
>>25
本に書かれている指針を理解したうえで、実際のプロジェクトに適用したときの
経験について語ってくれってこと。どうして分からないかなあ…。

オブジェクトとクロージャの区別に拘るのは違和感があるんだけど開発言語は何？
言語によってはその区別が重要なんだろうか。
0027デフォルトの名無しさん2016/05/20(金) 14:19:58.58ID:jCV1qcCq
>>26
まずその本とやらの題名なりamazonのurlなりを具体的に示して欲しいかな？
本によって言ってることまちまちだしね。

趣味でx86_64アセンブリとLispを少々
0028デフォルトの名無しさん2016/05/20(金) 14:24:17.23ID:0eowHHkD
本によってまちまちだからこそ、実際に使ってみてどうだった？って感想が
聞きたいんだけど。
趣味レベルってことで納得。

Lispだとクロージャの役割が大きいのかなあ。

業務システムの設計・構築経験がある人の体験談を聞きたい。
0029デフォルトの名無しさん2016/05/20(金) 14:28:12.35ID:jCV1qcCq
> Lispだとクロージャの役割が大きいのかなあ。
というかクロージャを拡張したら割と簡単にオブジェクトが作れるから
そこまでする必要があるかどうかで自然とオブジェクトにするかどうかが決まる感じ

ところでこれ設計の話？それとも実装の話？
0030デフォルトの名無しさん2016/05/20(金) 14:31:52.11ID:0eowHHkD
設計の話だけど、構築するために設計するんだから構築段階で設計の品質が実体化するとも言える。
実装を無視した設計はあり得ないから、実装も設計に関係する。
0031デフォルトの名無しさん2016/05/20(金) 14:32:58.18ID:wXLR68d1
>>1
おれもそもそもOOPのメリットが分からん
OOPでうまくつくっていける奴は関数型でも
手続き型言語でもそれなれにやっていけそうだが
0032デフォルトの名無しさん2016/05/20(金) 14:41:33.00ID:0eowHHkD
>>31
どの設計手法を使うにしても基礎は共通してるからある手法できれいな設計ができれば
他の手法を使うときも正しい使い方ができると思う。

手続き型よりもオブジェクト指向のほうが構成要素の区切りが明確になりやすいのがメリットだと思う。
関数型の設計手法はどんなものか分からないや。
0033デフォルトの名無しさん2016/05/20(金) 14:42:40.60ID:jCV1qcCq
OOPって要するに分割統治をアグレッシブにやってるだけと違うの？
0034デフォルトの名無しさん2016/05/20(金) 15:06:25.53ID:xWTkKLUb
OOPスパゲッテー依存で後で泣く
インターフェース
クラス
ウーーーーー
もう少しいい言語設計を
0035デフォルトの名無しさん2016/05/20(金) 15:42:04.87ID:0eowHHkD
>>34
それは設計が悪い。
0036デフォルトの名無しさん2016/05/20(金) 15:42:33.48ID:0eowHHkD
言語設計じゃなくてシステム設計が悪い。
0037デフォルトの名無しさん2016/05/20(金) 17:57:03.05ID:xL1EKSbm
OOPダメみたいな流れはどうして？
JavaやC#どっぷりのオレは、生きていけないの？
0038デフォルトの名無しさん2016/05/20(金) 18:03:59.50ID:JTjd3aWK
OOPはモジュール作成者にメリットはあっても
利用者にはメリットはないんだよ
0039デフォルトの名無しさん2016/05/20(金) 20:52:17.59ID:0eowHHkD
>>37
オブジェクト指向をきちんと活用するのは難しいからじゃね。
素人には理解できない。
まちがった使い方をする。
間違ってるのは素人の俺じゃなくてオブジェクト指向だ。
って流れだと思う。
0040デフォルトの名無しさん2016/05/20(金) 20:55:01.79ID:0eowHHkD
>>38
システムの改修が容易だというのは利用者にとってもメリットだな。
システムの改修を容易にできるだけの洗練された設計が実現できていることは少ないから
オブジェクト指向のメリットを実感できない設計が多いのかもしれないけど。
オブジェクト指向が悪いんじゃなくて、設計者が要求されるレベルに達していないことが多いだけ。
0041デフォルトの名無しさん2016/05/20(金) 21:00:29.42ID:fT3/H/UL
利用者にメリットがないとか言ってるやつに限って
OCPすら満たしてないシステム作ってそう
0042デフォルトの名無しさん2016/05/20(金) 21:13:45.60ID:JHcTy9r/
関数型の匿名関数に積極的に名前を付けていくとOOPになる感じ
0043デフォルトの名無しさん2016/05/20(金) 21:49:33.16ID:lJQ06Hkz
OOPは悪くはないけどメリット少ない
親クラスを継承する必要性も少ないし
DBのSELECT結果をオブジェクトに入れる必要もない
0044デフォルトの名無しさん2016/05/20(金) 21:52:47.80ID:0eowHHkD
>>43
継承を推奨してる設計指針なんて見たことないけど。
オブジェクト指向設計について語りたいならまともな本を読んでからにしようぜ。
0045デフォルトの名無しさん2016/05/20(金) 21:54:23.51ID:fT3/H/UL
>>43
継承と移譲について理解しようね
0046デフォルトの名無しさん2016/05/20(金) 22:19:45.27ID:5OAEQxQd
継承はアンチパターン
0047デフォルトの名無しさん2016/05/20(金) 22:39:20.85ID:lJQ06Hkz
>>44
推奨とか知らんけど実際の現場では継承されまくってるだろ

>>45
理解してるから言ってる。基本継承は不要。移譲だけでいいぐらい
0048デフォルトの名無しさん2016/05/20(金) 22:43:46.88ID:0eowHHkD
>>47
継承を利用すべきじゃない場面でも継承が利用されているのは問題であるってほとんどの本に書いてあるぞ。
まともな本すら読まずに間違った設計をしているからメリットを実感できないだけで設計者のレベルが低いだけ。
0049デフォルトの名無しさん2016/05/20(金) 22:48:17.41ID:lJQ06Hkz
>>48
じゃああんたが言ってることと俺が言ってることは同じじゃんか
何で俺は噛み付かれたんだ
0050デフォルトの名無しさん2016/05/20(金) 22:50:13.54ID:0eowHHkD
>>47
継承を利用すべきじゃない場面でも継承が利用されているのは問題であるってほとんどの本に書いてあるぞ。
まともな本すら読まずに間違った設計をしているからメリットを実感できないだけで設計者のレベルが低いだけ。
0051デフォルトの名無しさん2016/05/20(金) 22:51:14.89ID:0eowHHkD
>>49
×OOPはメリット少ない
○バカな設計者が設計するシステムはダメ

全然違う。
0052デフォルトの名無しさん2016/05/20(金) 22:53:29.65ID:ALiU1X8u
こういう展開は今まで何度も何度も見たが
「OOPのメリットはこれとこれとこれだ！」
という歯切れのいい意見を一度として聞いたことが無い
0053デフォルトの名無しさん2016/05/20(金) 22:54:45.09ID:0eowHHkD
>>52
>>32
ほとんどの本にこういったことが書かれているし、実感としても合ってる。
0054デフォルトの名無しさん2016/05/20(金) 22:59:42.47ID:5OAEQxQd
SOLIDしやすいのがメリット
0055デフォルトの名無しさん2016/05/20(金) 23:17:55.91ID:Zd4GCHrY
継承はアンチパターンと思うのはまだ恵まれている方だ。俺は継承をしてくれなくて困ることの方が多い。コピペの嵐ぱない。
0056デフォルトの名無しさん2016/05/20(金) 23:23:18.18ID:Ykc02+7p
それはオブジェクト指向とか以前の話だわ
0057デフォルトの名無しさん2016/05/20(金) 23:25:43.35ID:5OAEQxQd
コピペと継承関係ねえぞ
0058デフォルトの名無しさん2016/05/20(金) 23:27:16.59ID:0eowHHkD
>>57
親クラスに一回記述すれば済むのに
別々のクラスの両方に同じコードが書かれているってことだろ。
0059デフォルトの名無しさん2016/05/20(金) 23:48:05.55ID:5OAEQxQd
いやだからそれ継承どうこうじゃねえよ
0060デフォルトの名無しさん2016/05/20(金) 23:52:47.17ID:0eowHHkD
>>59
お前が言いたいことはみんな分かってるだろうから会話の流れも読もうぜ。
0061デフォルトの名無しさん2016/05/21(土) 00:07:02.79ID:q2Zh6d9K
>>49
> 何で俺は噛み付かれたんだ

そこにお前がいるから（名言）
0062デフォルトの名無しさん2016/05/21(土) 00:07:37.44ID:RrD1FkH/
>>59
お前の存在自体がアンチパターンだなｗｗｗ
0063デフォルトの名無しさん2016/05/21(土) 00:09:06.75ID:hclWowah
>>58
親クラスは便利物置場じゃないからな
0064デフォルトの名無しさん2016/05/21(土) 00:14:14.80ID:Dey5A/Jl
オブジェクト指向設計の経験がある奴はおらんのか？
0065デフォルトの名無しさん2016/05/21(土) 00:17:03.45ID:hclWowah
実装レベルの設計なんか必要ないでしょ。
設計が必要なのは業務ロジックまで。
実装レベルの設計が必要なのは
相当プログラマーのレベルが低い場合のみ。
0066デフォルトの名無しさん2016/05/21(土) 00:24:35.47ID:Dey5A/Jl
実装レベルの設計って曖昧だけど
クラスと公開されたメソッドは決める必要がある。
で、それを決めるためにはクラス間の関連を考える必要がある。
ってなるとそれなりに詳細に設計することになるが。
0067デフォルトの名無しさん2016/05/21(土) 00:27:38.10ID:pCEMwj0Q
個人で開発してるならいらんかも知らんけど
チームで実装する場合はクラス図とシーケンス図ぐらいは必要じゃね
まぁ個人でやる場合も10年後にメンテする人のために残しといた方がいいけどな
10年もたてば実装した本人も忘れてるだろ
0068デフォルトの名無しさん2016/05/21(土) 00:27:53.71ID:q2Zh6d9K
>>65
> 設計が必要なのは業務ロジックまで。

業務ロジックの設計って
具体的にどんなことや？
0069デフォルトの名無しさん2016/05/21(土) 00:34:44.35ID:sajHzwwt
そこらへんはシステムの特性やエンジニアの質など様々な要因で変わるから永遠に議論が終わらない話題だね。
0070デフォルトの名無しさん2016/05/21(土) 00:36:09.71ID:Dey5A/Jl
>>68
>>65がどういう意味で書いたのかは知らんが、要件定義的な作業は必要だろ。
UMLで言えばスイムレーンに分けたアクティビティ図を書くとか。
0071デフォルトの名無しさん2016/05/21(土) 01:06:07.75ID:Dey5A/Jl
>>69
しかし、実際のプロジェクトでは何らかの基準で決める訳でルールは必要。
ルールもなしに場当たり的に決めているならお話にならない。
0072デフォルトの名無しさん2016/05/21(土) 09:34:19.36ID:4qmWB+Wj
>>71
お前は何がしたいんだ？
研究したいなら大学に行くといいよ

現実では直感と経験でだいたい全部決めてる。
実装する時には例えばGoogleのスタイルガイドに合わせるとか、
既存のコードから空気読むとか、
何らかのルールがあるのは確かだけど
設計の段階でそんなこと言ってたらプロジェクトは進まない。
0073デフォルトの名無しさん2016/05/21(土) 09:51:01.31ID:zSvCOHYP
>>67
資料より対話の方が大事
図や文章はあくまで補助のメモ書きだね
0074デフォルトの名無しさん2016/05/21(土) 10:22:35.74ID:hclWowah
>>67
シーケンス図は業務で必要だね
クラス図は今まで一度も必要になったことがない
クラス図が必要なほど複雑なクラス構成にすること自体間違ってると思う

>>72
直感と経験で決めるやつがリーダーで
チーム内の統一までやってくれればいいんだけどね
1メンバーがマイルールで直感と経験で独断で決めるのはどうかと思う
チーム内にルールは必要だし、大学とか研究とかは関係ない
0075デフォルトの名無しさん2016/05/21(土) 10:28:49.34ID:Dey5A/Jl
>>72
だから、実際のプロジェクトでは決めるんだから何らかの基準で判断してるんだろ。
0076デフォルトの名無しさん2016/05/21(土) 10:30:45.98ID:Dey5A/Jl
>>73
資料がないと改修で泣くよ。
0077デフォルトの名無しさん2016/05/21(土) 10:31:01.96ID:4qmWB+Wj
>>74
誰が一人で設計すると言ったね
要件と要求を元に設計は成される物だから、当然複数人で話し合って物事は決まっていく。
その中で、経験上これはこうした方が良い気がする、とか
直感的にこれはまずいんじゃねーかと思う、とか
そういう話なんだが。

もしかして君は複数人で設計した事が一度も無いの？
0078デフォルトの名無しさん2016/05/21(土) 10:32:32.20ID:4qmWB+Wj
>>75
実際のプロジェクト毎にその基準が変わるから
ある一つのプロジェクトについて「これはこうだったあれはああだった」って言っても
意味が無いんだよ。
0079デフォルトの名無しさん2016/05/21(土) 10:32:37.55ID:Dey5A/Jl
>>74
クラス図が必要なほど複雑なクラス構成にすること自体間違ってると思うってのは
簡単なシステムしか作ってないからそんなこと言うんだろな。
0080デフォルトの名無しさん2016/05/21(土) 10:34:45.75ID:Dey5A/Jl
>>78
説明できるだけの経験がない、しっかりした基準がないてきとーな判断をしてる。
どっちかだろ？
0081デフォルトの名無しさん2016/05/21(土) 10:37:30.66ID:4qmWB+Wj
>>80
そこまで他人をこき下ろす以上は、君はそういった経験が豊富なんだよね？
ちょっと語ってくれないか。
君が経験したプロジェクトに基づいて、どういう手法を採用し、どういう問題が起きたか。
0082デフォルトの名無しさん2016/05/21(土) 10:38:13.47ID:q2Zh6d9K
どういう手法？

人海戦術とノミニケーションだろｗｗｗｗ
0083デフォルトの名無しさん2016/05/21(土) 10:42:52.87ID:Dey5A/Jl
>>81
会話の内容からしてお前よりははるかにあるだろう。

俺の経験はちょっとずつ出してる。
他の人の経験を聞きたいから、自分の考えを一方的に語りたくない。
0084デフォルトの名無しさん2016/05/21(土) 10:45:22.63ID:4qmWB+Wj
>>83
そうともさ
俺は20代なんだから君のほうが経験が豊富かも知れないけど、それが何だと言うんだ

で、俺は君の経験を聞きたいんだけど？
どんどん語ってくれよ。
0085デフォルトの名無しさん2016/05/21(土) 10:47:07.78ID:q2Zh6d9K
>>84
お前も少ない経験でいいから語れよｗ

お前がどこの誰か特定できるように
細かくな。
0086デフォルトの名無しさん2016/05/21(土) 10:48:18.26ID:Dey5A/Jl
>>84
プロジェクトを進めるためには決めなければいけないんだから
そのときにどいうい基準で決めるのがいいんだろうか？って考える癖を付けると実力が上がる。
実際、決めなきゃ進まないんだから決めているのにある選択をした理由をちゃんと考えて記録しないのは
だめなプロジェクトで良くみる。
0087デフォルトの名無しさん2016/05/21(土) 11:08:42.80ID:zSvCOHYP
>>76
資料無いと泣くようなシステムから脱却したいね
0088デフォルトの名無しさん2016/05/21(土) 11:09:50.85ID:Dey5A/Jl
>>87
どうやって？
0089デフォルトの名無しさん2016/05/21(土) 11:12:20.08ID:4qmWB+Wj
>>85
おーけい。
ある会社のインターンでの話なんだが

Google Chromeって名前のWebブラウザあるだろ？
あいつがメモリをバカ食いするのは当時でも有名でね。
どのモジュールがどのくらいメモリを食っていて、どれだけ無駄が出ているかってのを調べるために
コンパイラを改造する仕事を割り当てて貰ったんだ。
コンパイラを改造して、コンパイル時に適切なコードを差し込むことによって
Chrome自体のコードを改変せずにメモリの詳細な統計データを得ることが出来るようになる事が目的だった。
実際にはChromeじゃなくてオープンソースのChromiumの方だけどな。

果たして、それは上手く行かなかった。
というのも、オブジェクト間に参照のループがあったり
同じクラスから別の意味を持つクラスが派生してたりして
Chromium全体が密結合になっており、
「どのクラスのインスタンスがどれだけメモリを食っているか」という情報はあまり役に立たなかったんだ。

結論：オブジェクト指向設計を下手に導入すると、メンテナンス性が下がる
0090デフォルトの名無しさん2016/05/21(土) 11:12:22.49ID:zSvCOHYP
>>88
美しいコードを書けってこと
結局のところそれだけなんだよね
0091デフォルトの名無しさん2016/05/21(土) 11:14:11.26ID:Dey5A/Jl
>>89
Javaで書かれてる？
0092デフォルトの名無しさん2016/05/21(土) 11:15:01.57ID:Dey5A/Jl
>>90
コメントは書く？
0093デフォルトの名無しさん2016/05/21(土) 11:16:06.62ID:hclWowah
ここにいるやつらは2chでまで設計議論するような勤勉なやつらだから
書くコードはみんな美しいだろうな
それをチーム内に統一するのがなかなか難しいんだよ
ルール作っても守らないやつは守らないし
そもそも勤勉なやつのほうが少ないから勤勉なやつにいつも負荷かかる
0094デフォルトの名無しさん2016/05/21(土) 11:16:39.20ID:4qmWB+Wj
>>91
c++03で書かれてた
0095デフォルトの名無しさん2016/05/21(土) 11:18:54.32ID:Dey5A/Jl
>>94
C++は知らないけどメモリの状態を出力する機能くらいあるだろ？
それ使えば一発だったな。
0096デフォルトの名無しさん2016/05/21(土) 11:20:45.55ID:4qmWB+Wj
>>93
うちの場合、c++なら
Makefileにcpplint.pyによるチェックが書かれてて
Googleのスタイルガイドから逸脱したコードはそもそもコンパイルできないようにしてる。
0097デフォルトの名無しさん2016/05/21(土) 11:22:33.52ID:zSvCOHYP
>>92
コードで意図を表明出来ない場合にのみ書く
0098デフォルトの名無しさん2016/05/21(土) 11:22:43.32ID:4qmWB+Wj
>>95
そんな機能無かったよ？
精々がdlmallocをtcmallocに置き換えて、いつどれだけメモリが確保されたか調べれる程度。
0099デフォルトの名無しさん2016/05/21(土) 11:25:54.47ID:Dey5A/Jl
>>98
その機能がC++にないとは思えないけどなあ。
Javaにはある。
0100デフォルトの名無しさん2016/05/21(土) 11:26:55.23ID:zSvCOHYP
c++ってメタデータ無いのにそんな分析できるのか
0101デフォルトの名無しさん2016/05/21(土) 11:27:47.25ID:Dey5A/Jl
>>97
言語の標準ライブラリにもマニュアルが添付されてるけどそれについては？
■ このスレッドは過去ログ倉庫に格納されています