C++相談室 part145

**デフォルトの名無しさん** · 2019/09/13(金) 17:13:24.60

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part144
https://mevius.5ch.net/test/read.cgi/tech/1563769115/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----

**デフォルトの名無しさん** · 2019/11/02(土) 22:57:09.83

2chのゴミスレ＝C++界隈

**デフォルトの名無しさん** · 2019/11/02(土) 23:15:11.30

>>876
そこに涌く小バエ

**デフォルトの名無しさん** · 2019/11/02(土) 23:38:30.50

>>876 >>877
場所そのものを馬鹿にするのはよくない。
それは差別や権威主義を生み易い。

**デフォルトの名無しさん** · 2019/11/03(日) 00:27:38.19

>>875
一応フリースタンディング処理系っていう分類があるのでそれはもうされてる

◆QZaw55cn4c · 2019/11/03(日) 21:55:47.13

>>732
一つ教えてください、pimpl とか何べん読み返しても「利益の源泉」がわからないのですが、一つ一言で言い切っていただけませんか？

◆QZaw55cn4c · 2019/11/03(日) 21:58:20.86

>>775
＞マングリングって知ってるか？
＞そもそもC++のクラスライブラリを簡単にリンク

私は Java も ruby も触っていますが、お手軽に java のライブラリを c++ から使いたいと、ふつふつ、と、思っているのです…

**デフォルトの名無しさん** · 2019/11/04(月) 00:16:08.68

>>880 （732じゃないけど）
クラス実装の変更に対する再コンパイルの必要性の削減。

これが利益とならない環境では用はない。これが利益となる環境はある。

個人的には同じ目的ならインターフェースクラス＋生成関数のほうが手間が少なくて好み。
公開済みのクラス（具象クラス）に後付けでも適用できるのが pimpl の強みじゃないかな。

**デフォルトの名無しさん** · 2019/11/04(月) 00:45:00.04

>>833
>>821は、>>802からの流れなのでヨロ

そうした上で、
>ライブラリ使用者に無関係で見せたくないからpimplで隠す
それがpimpl固有の特質である根拠とは…
構造体の詳細を見せる必要が無いなら
別にハンドルでも良いじゃん？Cだと昔からそうしてきたわけやし…

>>834
構造体の詳細を見せる必要が無いなら
別にハンドルでも良いじゃん？Cだと昔からそうしてきたわけやし…

pimplとかC++で実装する側がソースコードを整理したい目的で使うものであって、
ライブラリの公開インターフェースがpimplであるべきという論こそ勘違い甚だしい

**デフォルトの名無しさん** · 2019/11/04(月) 00:50:27.63

>>881
お前の老害頭では無理だと思う

**デフォルトの名無しさん** · 2019/11/04(月) 01:01:50.05

コンパイル時にリフレクションできたらC++にはもう何も望まないんだけどな

**デフォルトの名無しさん** · 2019/11/04(月) 01:16:04.50

リフレクションしたいとか実行時にあれだとかこれだとかしたいとか
もっと安全性を高めたいとかいう人はC#にいったらいいとおもうんだが
なぜいかないのか

**デフォルトの名無しさん** · 2019/11/04(月) 04:20:27.81

マングリングとかも規格で決めてほしいよね
そうすればクラスのエクスポートなんかも簡単になるのに

**デフォルトの名無しさん** · 2019/11/04(月) 06:09:25.96

動的はともかく静的リフレクションはあって困る場面は無いだろ

冗長な記述や変なマクロを使わずに、enumを文字列化したりしたいだろ

**デフォルトの名無しさん** · 2019/11/04(月) 06:17:29.31

名前マングリングの方法がコンパイラ毎に違うおかげで
互換性のないオブジェクトファイル同士がリンクされる事故を防げる、って
『More Effective C++』に出てたな。

便利さも欲しいが安全性も保ちたい、という要求のせめぎあいだな。

**デフォルトの名無しさん** · 2019/11/04(月) 06:59:32.99

今生き残ってるC++のコンパイラってどのくらい種類あんの
特定ハード向けのもgccの派生なんでしょ？

**デフォルトの名無しさん** · 2019/11/04(月) 09:40:11.27

>>833
>>883とｵﾓﾀがちょっち訂正しておき鯛、
publicなメンバ関数だけでprivateを一切含まずに事を済ますクラス定義を広義のpimplとみなすなら
ライブラリの公開インターフェースとしてpimpl最高じゃな

ハンドルだけだとユーザーが間違った呼び出しをしかねない
これをpimpl式にクラスでwrapするのはｽｹﾞｰ有効

**デフォルトの名無しさん** · 2019/11/04(月) 10:05:11.25

つーかハンドルで渡して使う時にキャストするって面倒だからさ
privateだからいいでしょとかいう問題じゃない

**デフォルトの名無しさん** · 2019/11/04(月) 12:16:24.53

記述の煩雑さはもう諦めるけどインラインPimplでゼロオーバーヘッドにしてほしい

**デフォルトの名無しさん** · 2019/11/04(月) 12:22:24.34

煩雑さを許容できるならやれるでしょ
pointerでなくバイト配列にしておいて中でcastするやつ
気を付けないところいろいろあるけど

**デフォルトの名無しさん** · 2019/11/04(月) 12:35:35.98

オーバーヘッドを気にしている人の大半は、気にする必要のあるものを作っていない

**デフォルトの名無しさん** · 2019/11/04(月) 12:35:45.49

実装をpimplに押し込めて公開インターフェース上の変数メンバの増減を無くすのが肝なんだから
pimplのデリファレンスのオーバーヘッドは避けようがないだろう。

**デフォルトの名無しさん** · 2019/11/04(月) 12:41:44.84

そもそもprivateな関数宣言をpublicなヘッダに
書かないといけないというC++言語仕様の欠陥

publicヘッダとprivateヘッダの二つに分けて
クラス宣言できればよかった

ちなみにC#ではpartialクラスといって
複数のファイルにまたがってクラスの定義ができる

**デフォルトの名無しさん** · 2019/11/04(月) 13:33:20.96

>>896
こういうの
https://ideone.com/EB36N2
pointerじゃないからpimplではない

**デフォルトの名無しさん** · 2019/11/04(月) 13:45:03.05

まあ欠陥って言われてもprivateメンバー変数変更されたらインスタンスのサイズ変わったりするから
1) 参照してるソースも含めてリコンパイルする
2) ポインタで持つ（pimpl）
しかないからねぇ
C++的には現状の言語仕様でIDEでprivateは見せないようにもできるとかでいいと思う

**デフォルトの名無しさん** · 2019/11/04(月) 13:47:25.16

>>898
パズルとしてはいいけど真顔で書いてたらちょっと引くわw

**デフォルトの名無しさん** · 2019/11/04(月) 13:59:48.02

>>898
その場合でも任意の変数メンバの拡張性は結局 Hide::a の存在で保証されているわけだろう。
impl[32] と予約された範囲まで拡張できるというのもあるのかもしれんが。

**デフォルトの名無しさん** · 2019/11/04(月) 14:00:47.43

結局低レイヤーを考慮しないでバカが文句言ってるだけで
そんなことに付き合う必要はないんだよ。

**デフォルトの名無しさん** · 2019/11/04(月) 14:16:11.73

>>901
バイナリ境界にしたときの拡張性のこと言ってる？
それはまさに配列のサイズでリザーブだね
溢れたら終わり

目的がヘッダー依存を切ることなら必要に応じて配列サイズ増やせばいいだけ
めんどいけどassertかけてあるからミスることはない
あとpimplは中でnewされるのがいやな場合あるからそれを避けられるってのも大きいね

**デフォルトの名無しさん** · 2019/11/04(月) 14:34:36.07

>>897
（使う側が）、CPerson person[10]; や、new CPerson[10] のように書いたと
すると、C++は高速化のため、CPersonのバイトサイズを定数値として
静的にコンパイルして、スタックや Heapからそれらのオブジェクトの領域を
確保する。
なので、たとえC++でCPersonのprivateメンバがC#のpartialの様に分けて宣言できた
としても、それらを全て合わせた全体のバイトサイズが分からないと静的に処理できない。
故に結局、partialの一部であっても全体のサイズに影響のあるような変更が行われた
場合には、上記の様な形でCPersonを使うプログラムは再コンパイルが必要となる。

**デフォルトの名無しさん** · 2019/11/04(月) 14:57:14.11

プリコンパイルドヘッダが標準化されればなんとかなるかも

◆QZaw55cn4c · 2019/11/04(月) 16:01:14.23

>>905
そういうのはやめてほしいです…

**デフォルトの名無しさん** · 2019/11/04(月) 16:31:03.20

>>906
良いか悪いかは仕様次第なんじゃないの？
コンパイルされてたら無条件でアウト？

**デフォルトの名無しさん** · 2019/11/04(月) 16:35:25.90

差分とりづらいってのはあるか

**デフォルトの名無しさん** · 2019/11/04(月) 20:26:00.54

>>897
構造体データメンバのメモリ配置を正確に定義したいという目的を捨てない限り
privateなデータメンバをprivateヘッダに分けて定義できるようにしたところで
pimplが目指すような解決にはならない
ほとんど意味が無い

**デフォルトの名無しさん** · 2019/11/04(月) 20:31:52.81

pimplが目指すような解決というのは筆が滑ったorz

とにかくprivateなデータメンバをprivateヘッダに分けて定義できるようにしたところで
実装の隠蔽にはやっぱハンドル経由とかポインタ経由（pimpl）な間接参照が必要なままである
構造体データメンバの追加や削除や順序変更が
publicなヘッダに定義されたインターフェース仕様に影響しなくなりはしない

**デフォルトの名無しさん** · 2019/11/04(月) 21:34:38.56

>>900
言うてもplacement newしたオブジェクトに移譲してるだけだからたいしたことやってない
まぁこれが規格的にセーフかどうかは知らんけどな

**デフォルトの名無しさん** · 2019/11/04(月) 21:53:48.72

>>911
> uint8_t impl[32];
固定サイズで確保してる時点であり得んわ

**デフォルトの名無しさん** · 2019/11/04(月) 22:09:21.71

そこはどうにもならんな
他にいい方法あるなら知りたい
上で触れてるけど、逆にバイナリ互換とるときはそういうリザーブが役立つこともある

**デフォルトの名無しさん** · 2019/11/04(月) 22:38:30.89

>>913
> 他にいい方法あるなら知りたい
ないからpimplとかなんだろ
だからと言ってテキトーに領域定義とかあり得んだろ

**デフォルトの名無しさん** · 2019/11/04(月) 22:40:59.70

そもそもポインタ参照ごときのオーバーヘッドをも許さないほどリアルタイム性を要求するもの作ってんの？

**デフォルトの名無しさん** · 2019/11/04(月) 22:51:45.72

>>914
適当がいやなら同じサイズにすりゃいいじゃん
static_asserの条件を==にすればいい
手間はかかるが、それが許容できる前提の案ね

**デフォルトの名無しさん** · 2019/11/04(月) 22:58:08.77

>>916
バカなの？
ちょっとサイズ変更されたら使えない
かと言ってどんだけ余裕持てばいいかは未来予知能力でもないと無理
要するに常人には使いどころがないってことな

**デフォルトの名無しさん** · 2019/11/04(月) 23:05:23.77

>>915
C++の用途として可能な限りオーバーヘッドをゼロとすることが要求されるケースがあるのは当然の話であるが、別に議論に参加するものがそういう物を作っている必要性はないだろうに、何でこだわってるんだ？

**デフォルトの名無しさん** · 2019/11/04(月) 23:12:26.97

>>917
だから手間がかかると言ってるわけ
やる気になれば自動化できるスクリプトは作れるだろうけどね
バカと思うかもしれないけどreserveフィールドでバイナリ互換を保つってのは実際やるんだよ
未来を予測できないのはそのとおり
適当に決める
まぁお前の知らない世界の話だから気にするな

**デフォルトの名無しさん** · 2019/11/04(月) 23:25:59.73

外部からはデストラクタもコピーコンストラクタも動かせないのにあえてインラインにする
理由がよくわからないな。
よっぽど特殊でピンポイントな要件なのかもしれないが。

**デフォルトの名無しさん** · 2019/11/05(火) 01:47:52.32

placement new を使った
char* ptr = (char *)malloc(sizeof(CPerson));
CPerson *pPerson = new(ptr) CPerson;
という書き方、実は、「コンストラクタの明示的呼び出し」なるものを使って、
CPerson *pPerson = (CPerson *)malloc(sizeof(CPerson));
pPerson->CPerson::CPerson();　　// コンストラクタの明示的呼び出し
と書くことも出来るらしいことを最近知った。

**デフォルトの名無しさん** · 2019/11/05(火) 06:17:56.31

ああそうそれは良かったね～

**デフォルトの名無しさん** · 2019/11/05(火) 07:19:41.62

>>919
手間の問題じゃないよ
せっかく変更に強くするためにやってるのに
> 適当がいやなら同じサイズにすりゃいいじゃん
なんてやったら本末転倒だろ

> やる気になれば自動化できるスクリプトは作れるだろうけどね
未来予知機能付きのスクリプトができたらいいねw

> バカと思うかもしれないけどreserveフィールドでバイナリ互換を保つってのは実際やるんだよ
ああ、昔のコボラー爺の発想ねw
ファイルとか通信とかで外部とやり取りするようなものだと今でも普通にあるけどメモリーレイアウトでやるのは流石に悪手でしかない

> まぁお前の知らない世界の話だから気にするな
時代遅れのお前の妄想に閉じ込めといてくれw

**デフォルトの名無しさん** · 2019/11/05(火) 07:51:55.68

>>780
cygwinで配布してるwxwidgitはgcc3時代のabiでバイナリ作られてるが当然gcc8でもabiオプションで変えてリンクできる

**デフォルトの名無しさん** · 2019/11/05(火) 07:55:46.59

>>921 何を見て「出来るらしい」と言ってるのかな？

**デフォルトの名無しさん** · 2019/11/05(火) 08:36:03.93

解放も自前でやるんなら別にいんじゃね？

**デフォルトの名無しさん** · 2019/11/05(火) 08:47:49.22

>>819
pimplが理想だなんて頓珍漢なレスで
ひっ絡んで来たのそっちだろうが
何がそういう返しだ
冗談は顔だけにしろ奇形チンパンジーめ

**デフォルトの名無しさん** · 2019/11/05(火) 12:36:38.02

>>927
まさかと思うが
> 目指す理想がpimpl?
って理想がpimplって言ってるとでも思ったのか？
デザインパターンの前に日本語の勉強しろよw

**デフォルトの名無しさん** · 2019/11/05(火) 12:48:20.10

日本人じゃないんじゃない？

**デフォルトの名無しさん** · 2019/11/05(火) 16:03:35.45

>>928
安心しろ
あからさまにラリッてる廃人の戯言など
どうとも取ってねえよ
そんな価値があるとでも思っているなら
とんだナルシストだw

**デフォルトの名無しさん** · 2019/11/05(火) 17:28:48.96

>>923
pimplの目的が変更に強いことってはお前の見方にすぎない
コンパイル時に検知できるんだから特別手間ではないし、
呼び出しコストを下げる目的は達している
技術的な話したいなら物事をフェアに見ような

**デフォルトの名無しさん** · 2019/11/05(火) 18:57:55.00

手間はあるけど（俺は）手間だと感じないだから、変更に強いとは思わない

って言ってるの？

**デフォルトの名無しさん** · 2019/11/05(火) 19:21:00.26

>>894

**デフォルトの名無しさん** · 2019/11/05(火) 19:48:59.34

実装側のサイズが想定をオーバーしたら互換性無くなって再コンパイルになるんでしょ
それが許容される環境ならインターフェース切る意味が薄れるんじゃないの？

まぁ実際はオーバーしないようにするんだろうけど

**デフォルトの名無しさん** · 2019/11/05(火) 19:52:57.91

>>930
どうとも取ってないのに顔真っ赤にしてレスするとか珍しいなw

**デフォルトの名無しさん** · 2019/11/05(火) 19:54:47.54

>>931
ごめん、お前なんのために>>898みたいなことやるの？
説明できる？w

**デフォルトの名無しさん** · 2019/11/05(火) 20:04:16.17

>>936
pimplの説明ならこのスレで何度も出てると思うが？
それにしたいして、お前の反論は「俺はそうは思わない」という感想でしょ？

技術的な話したいなら物事をフェアに見ような

**デフォルトの名無しさん** · 2019/11/05(火) 20:18:38.99

>>893 というお題な対して出した案が >>898
privateは隠蔽できて、かつ呼び出しコストは低い
配列サイズ増やしたらバイナリ互換がとれないのは承知してる
しかしそれはI/Fにする構造体一般の話であってこの件に限ったことではない

もう十分説明したつもり

**デフォルトの名無しさん** · 2019/11/05(火) 20:37:36.25

>>937
>>898がpimplに見えるならちょっと黙っててもらっていいかな？
邪魔なだけだし

>>938
なるほどね
とにかくprivateは見せたくないって事ならそれでいいんじゃね？
俺はやりたくないけどw

**デフォルトの名無しさん** · 2019/11/05(火) 20:51:01.63

>>935
とID真っ赤にしてレスするやつ
別に珍しくもねえ　どこにでもいる虫けらめ

**デフォルトの名無しさん** · 2019/11/05(火) 21:09:19.41

可愛そうなやつ…

**デフォルトの名無しさん** · 2019/11/05(火) 21:15:13.47

事務職だけど、C++使ってる　
こんな便利なプログラミング言語があるとは

**蟻人間** ◆T6xkBnTXz7B0 · 2019/11/05(火) 21:19:49.70

pimplesが顔に出たのは中学・高校時代だったか。

**蟻人間** ◆T6xkBnTXz7B0 · 2019/11/05(火) 21:23:07.90

pointer to implementation

**デフォルトの名無しさん** · 2019/11/05(火) 22:48:13.18

結局のところ、>>893の言う「インラインPimpl」なるものの解釈なんだよな。

「そんなものありえない」>>896
「こうすればできるよ」>>898

俺は「ありえない」派だが。

**デフォルトの名無しさん** · 2019/11/05(火) 22:54:52.19

ピンプルはシンプルじゃないとダメでしょ

**デフォルトの名無しさん** · 2019/11/05(火) 23:19:34.53

他の言語ではprivateを隠すための努力なんてしなくていいよね
あくまでc++特有のパターンとしてpimplがある
pimplの肝は、ポインタだけなら前方宣言すればincludeしなくてOKっていう
抜け穴的なところからきていてポインタであることは妥協の産物
implクラスを変更しても互換性が保たれるというのはあくまで副次的
ゼロコストじゃないわけでc++の思想からも外れている

**デフォルトの名無しさん** · 2019/11/05(火) 23:26:17.64

何をもって思想から外れていると？
C++の設計思想は最速を目指すことじゃないからな

**デフォルトの名無しさん** · 2019/11/05(火) 23:41:22.87

Bjarne Stroustrupがそう言ってる

**デフォルトの名無しさん** · 2019/11/05(火) 23:55:16.05

始まりはそうだったかも知れんが、現在の規格の設計思想は明らかに違う

**デフォルトの名無しさん** · 2019/11/05(火) 23:58:36.99

最速を目指すって言うと少し外れてるけど、速度を重視するという所は変わってない

**デフォルトの名無しさん** · 2019/11/06(水) 00:01:20.76

それ以上に集団での開発効率を重視したもの
>>898のような奇怪なものよりpImplの方がモダンC++の設計思想に合っているのは間違いない

**デフォルトの名無しさん** · 2019/11/06(水) 00:04:55.89

別に抜け穴でも何でもないだろ
なきゃこまるじゃん

**デフォルトの名無しさん** · 2019/11/06(水) 00:12:17.42

>>950
明らかに～
説明できないときにつかう常套句だよね
少なくともc++17まではその設計ポリシーが挙げられてるよ

**デフォルトの名無しさん** · 2019/11/06(水) 00:18:49.38

>>952
はぁ？
pimplのどこがモダンなの？
最低限delegateを手で書かなくてもいいようにしてから言ってくれよ
スマートポインタ以下だから

**デフォルトの名無しさん** · 2019/11/06(水) 00:32:45.47

設計の方針は曖昧なものではなく明文化されてるから調べてきてね

**デフォルトの名無しさん** · 2019/11/06(水) 01:17:04.07

ピンプルってピンポンみたいだね

**デフォルトの名無しさん** · 2019/11/06(水) 01:37:31.84

ハリソン・フォード主演映画「逃亡者」(1993年)の主人公の名前は、キンブルだったね。
この映画はサントラが良い。ジェームズ・ニュートン・ハワードが音楽担当。
このサントラの「Helicopter Chase」という曲は、「タクティクスオウガ」(1995年)というテレビゲームの「VENDETTA!」という曲によく似ている。

**デフォルトの名無しさん** · 2019/11/06(水) 05:47:10.84

pimpl使ったことないからスルーしてたけど
>>947=>>949
ゼロオーバーヘッドの原則は言語が掲げるもので言語利用者を縛るものじゃねーよ

実際それが便利でコストが問題にならない使い方ならどう使ってもいいだろ

**デフォルトの名無しさん** · 2019/11/06(水) 05:56:01.23

>>954
君もなんか勘違いしてない？
最速を目指すなんて厨二病みたいなことを挙げていたというソースは？

**デフォルトの名無しさん** · 2019/11/06(水) 06:54:13.33

>>959
> ゼロオーバーヘッドの原則は言語が掲げるもので言語利用者を縛るものじゃねーよ
そうだよ、だからこの手の機能は言語仕様には含まれないってことな

> 実際それが便利でコストが問題にならない使い方ならどう使ってもいいだろ
誰もお前に使うななんて言ってないから使いたいなら勝手に使ってろよw

**デフォルトの名無しさん** · 2019/11/06(水) 07:21:04.31

>>947
その主張にincludeは関係ないぞ

**デフォルトの名無しさん** · 2019/11/06(水) 07:24:02.54

質問です。
サンプルプログラムで割り込み処理の一文で

ISR(TIMER1_CAPT_vect) {}でサブルーチンを呼び出してたんだけど、()内の意味わかりますか？

**デフォルトの名無しさん** · 2019/11/06(水) 07:41:29.30

>>961
＞そうだよ、だからこの手の機能は言語仕様には含まれないってことな
誰か言語仕様に含めろなんて言ってたか？
さすがに隠したいメンバをポインタ経由で隠して無駄にコストかかる言語なら俺もお断りだが
ちな俺はplmpl使いたいなどと書いてない、人の主張を勝手に捏造するな

**デフォルトの名無しさん** · 2019/11/06(水) 08:14:41.32

あと>>961=947と想定してもう一つ言っておくと
ポインタ変数の宣言に型(クラス)の実際の定義が必要ないのは抜け穴じゃない
必要ないから要求されないだけだ
どうもC++に対する認識がおかしい気がする
D&Eでも読んでこい

**デフォルトの名無しさん** · 2019/11/06(水) 08:16:11.65

>>964
> 誰か言語仕様に含めろなんて言ってたか？
誰もお前が言語仕様に含めろと言ってるなんて言ってないぞ
自意識過剰すぎだろ

> ちな俺はplmpl使いたいなどと書いてない、人の主張を勝手に捏造するな
使いたい「なら」な
C++の前に日本語やり直してこいw

**デフォルトの名無しさん** · 2019/11/06(水) 08:17:38.83

>>965
> あと>>961=947と想定して
バカほどこういう想定をしたがるw

**デフォルトの名無しさん** · 2019/11/06(水) 08:21:27.02

ただの荒らしなら出てけ

**デフォルトの名無しさん** · 2019/11/06(水) 08:31:26.58

>>963
コンパイラが分からんけど、割り込みベクタテープルのシンボルだと思う。
タイマ1キャプチャ割り込みのハンドラを今から定義しますよ、みたいな。

**デフォルトの名無しさん** · 2019/11/06(水) 09:33:53.63

サイズの違うコンテナ同士で代入を試みたらセグメンテーション違反になったんだが、リサイズしつつ代入って簡単にできないの？

**デフォルトの名無しさん** · 2019/11/06(水) 09:54:01.45

>>970 できるよ。
#include <vector>
#include <cassert>
int main()
{
std::vector v1{1}, v2{1,2};
v1 = v2;
assert(v1 == v2);
}

**デフォルトの名無しさん** · 2019/11/06(水) 10:35:41.19

>>971
普通できるのか
boostの「STLコンテナらしく振る舞う」というある多次元配列コンテナでできなかったから一般的にできないんだと思っちゃった
スマン

**デフォルトの名無しさん** · 2019/11/06(水) 10:42:41.76

そのためのstd::vectorのメンバ関数operator=だしな

**デフォルトの名無しさん** · 2019/11/06(水) 12:22:15.65

>>968
頓珍漢な想定でくだらんことしか言えないお前が出て行けよw

**デフォルトの名無しさん** · 2019/11/06(水) 15:11:24.10

今事務職であいてる時間C++やってるんだけど、事務職に特化したライブラリとかってない？