C++相談室 part131 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part130
http://mevius.2ch.net/test/read.cgi/tech/1490917669/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.100【環境依存OK】
http://echo.2ch.net/test/read.cgi/tech/1478440682/
■長いソースを貼るときはここへ。■
http://codepad.org/
https://ideone.com/
[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
-
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured C/C++室のURLはこちらが正しいです。ごめんなさい。
【初心者歓迎】C/C++室 Ver.101【環境依存OK】 [無断転載禁止]©2ch.net
http://mevius.2ch.net/test/read.cgi/tech/1500329247/ 2 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ bf54-lR6P)[sage] 投稿日：2017/03/31(金) 16:52:18.52 ID:CoeIAoH10
STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
---- テンプレ ここまで ---- 日付がミスリーディングなクソレスを貼る>>3は無能 >>1乙
CからC++の学習に進もうと思ってるんだけど、皆さんオススメの書籍とかWebとか有ったら教えてちょ やめとけやめとけ
Cでリスト構造あたりがすらすら書けるようになったならC#にしとけ。
生産性あがらずそっぽ向かれてるのに、
ムーブコンストラクタとか、コード増えて、さらに生産性低下。
完全にオナニー規格で、自分でとどめ刺した。
まるで民進党の蓮ポ ツンデレID:qWNYkf/a0さんありがとw
だがしかし、原文のまま進めるには10倍くらい労力使いそうなんで、出来たら日本語でお願いします！ ＣプログラマのためのC++入門って本が解りやすかった プログラミング言語C++と言いたいところだが、C++11で止まってるとこらがもうね。
vol3まで原書と邦訳つきあってきたけど、もう気力も失せたわ。
可能性を期待してたの90年代前半 ANSI時代までだな。
電話帳より分厚い言語解説本て。多分完全理解した頃エンジニア生命終わってるわ 最新の情報はテメェで調べりゃいいんでねぇの？
まず基本という基礎固めが重要だろ
Ｃプログラマでやってきた奴に総てを全うさせるのは荷がおもすぎるだろ 今から学ぼうとする人に規格のドラフトとかどんな苦行だよ
やっぱりロベールしかないな http://www.saiensu.co.jp/?page=book_details&;ISBN=ISBN4-7819-0649-4
みっけた。コレだわ。
コレ読んだあとにSTLの分厚いの読むと解りやすかった。 コピーライト表記が SAIENSU-SHA Co., Ltd. だからね 正しい綴りにすると、別の企業サイトに行ってしまった >>7
「詳説C++ 第2版」がオススメ
http://amzn.asia/fb29pvT
ただ、 C++03 を前提にした範囲のことしか書いてない (出版年が 2005 年だから仕方がないけど) ので、
差分はウェブ上のリファレンスで補うと良し。
https://cpprefjp.github.io/ >>17
>>21
なるほど。
どちらも古そうな本ですが、参考にさせていただきます。有難う御座いました。 >>17
一から勉強する初心者に、
使いにくいだけの過去規格の遺物勧めて何したいんだ。
C++1xとANSI時代のC++は別物だ でもC/C++は互換性をかなり重視してくれているから、時系列に沿って勉強しても無駄ではない気がする。
っていうか、いきなりC++14勉強するのは辛いんじゃねって気がする。 便利機能無しで学習するのはストレス溜まる｡
わざわざそんな縛りプレーすることないわ。 Effective C++ 第3版持っている人に質問
33項に書いてある「仕事を送る関数」なんだが
private継承しているのに、なんで派生クラスで基底クラスの関数を呼び出せるの？
inline関数ってところが関係しているのだろうか ごめん補足
質問の箇所は33項 p.169ね
よろしくお願いします なんでもなにもprivate継承した基底クラスのpublicメンバは
派生クラスのprivateメンバ的扱いになるので
派生クラスの中では自由にアクセスできる >>30
マジか……恥ずかしながらそんな基本的なこともわかってなかった
ありがとうございます private基底とメンバ変数、機能的な違いはあるのかしらん？ 俺もprivateとpublicって積的関係かと思ってた
private継承とか使わんからな >>34
private 継承している場合は基底にキャストできない。
スライシングを起こしたくない場合には private 継承した上で
一部のメンバを using で公開するというようなテクニックもある。 おお、スライシング問題抱える訳ですな。使わないのが無難か…… あ、キャストできないが正解か。
private基底は実装を楽する手段かね。 つまり例えばstd::vectorクラスを継承したクラスを作って
間違ってアップキャスト扠せたくない場合なんかに使うイメージか vector自身をprivateにしたい場合はprivate継承
vectorのメンバを露出させたい場合はprotected継承 セマンティクス的には、
public継承はis-a関係
private継承はhas-a関係 リンゴとパイナップルとペンが入ったフルーツバスケットは
リンゴクラスとパイナップルクラスとペンクラスの多重private継承なんや 「private継承」とい言葉を見るとC++17ドラフトのUNKOなライブラリ設計しか思い浮かばない メンバも含めてprivateなものの用途を詮索してもしょうがない 誰か個人資産をpublicで公開してくれないかなぁ 2000年頃貯めた資産なので引き出せる紙幣はコピーだがよいか？ >>46
あなたのその文字も立派な個人資産。
ここに書いた瞬間2chに帰属するが。 このスレのレスで資産と呼べるのは
PostMessageでメモリ不足を検知するノウハウと
プライベートメンバーをアクセスする技くらいのものだ >>49
＞プライベートメンバーをアクセスする技くらいのものだ
え，それって private メンバのアドレスを返して外からアクセスするってやつ？ >>50
privateをpublicでdefineするやつじゃ？ >>50
微妙に違うような
アクセス制御が適用されない文脈でメンバーへのポインターやstatic変数のポインターを取得してアクセスする手法 privateをpublicでdefineするのは潔くてカッコいいが
>>54は全てが糞すぎる >>57
うむ、こんなところだろう
1.既存のクラスに普通に手入れている
2.それは違うと>>53で言っているのに投下されるアスペなレス
3.privateな変数にアクセスするかと思いきや、privateな変数を出力するprivateな関数を呼び出すという意味の無い構成
4.deleteを使用するUNKOなコード
5.newを使用する残念なコード
6.コードへのリンクを投下するのでなくクソスレを経由するクソレス
7.例外安全でない
8.非staticにする必要性が感じられない
9.「(hoge->*(hoge->g()))();」というブザマな呼び出し方 >>58
https://ideone.com/Y4LPCV
改善：3, 4, 5, 6, 7
保留：1, 2, 8, 9 いやそこは無視するだろ普通
>hoge.get()->*(hoge->g2()) = 54321;
もう何が何だか… 読んでないけどg()は関数ポインタを返す関数？
設計からしてダメだろ 既存のクラスに手を入れてる時点でキモイ。
それならもっとやりようあるでしょ。 >>61
メンバのオフセット（たぶん） ->* ::* 使用前提のやつ
>>59 は一箇所どうにもこうにもならないので放置している部分がある
ともかく笑いのネタというより他にない >>63
遠慮せずともじゃんじゃんプライベートにアクセスしてよいぞ
http://ideone.com/BJHsgK >>63
オフセットして実装するのが普通だと思うけど、メンバ変数へのポインタがオフセットで実装されるとは決まってないんじゃないの？ C++の場合クラス（およびその基底クラス）内のメンバは全部ヘッダファイルを辿っていけばﾜｶﾙのだから
まず全く同じ内容のヘッダファイルのコピーを作り、
ファイル名を適当に変えて、多重インクルード箇所もコピーしたもので閉じるように変更して、
privateやprotectedを全部publicにして、
クラスの名前をFoo→Foo2とか改変して、
仮想関数は適当に空の定義でもつけて、
((Foo2*)p)->(Fooのデータメンバ)
式にキャストしてアクセスすればデータメンバと仮想関数については問題なくアクセスできる
（ODR違反は都市伝説なので事実上これで動く
だいたいprivate破りを意図している時点で実コードレベルで影響しない規約とか気にしても仕方が無い Foo2の仮想関数が空ではないか、というのは動作上問題にならない
vtableのしくみがわかっているならﾜｶﾙ以下略
一方非仮想関数の方はちょっとうまい方法が思いつかない…
private属性のメンバ関数のアドレスがとれれば勝つるのだが class Base {
public:
Base() {};
virtual void func() {};
};
class Sub: public Base {
public:
Sub() {};
virtual void func() {};
};
Sub a();
std::vector<Base> b;
b.push_back(a);
b[0].func();
これだと継承前のBaseのfuncが実行されてSubのfuncが実行されないんですが
Subのfuncを実行するにはどうしたらいいですか そりゃpushするときにBaseへの暗黙の型変換かかるからダメっしょ
ポインタつかえよBaseの >>68
そのコード本当に動く？
本質じゃなくて申し訳ないが、そのまま追試出来るコードじゃないと…
ちなみに質問の回答はスライスな。 おかしいな、確かに
コピーコンストラクタもないのにコンパイラ通るのかコレ >>69
ありがとうございます
ポインタにすることで解決しました
>>70-71
動かしてるコードを簡略化したのでもしかしたら動かないかもしれないです 「本当に動く？ (中略) そのまま追試出来るコードじゃないと…」
↓
「もしかしたら動かないかもしれない」
これがアスペというやつだな この言語はどこの業務で使われてるの？
組み込み・制御はC++使ってますとか言いながら大体これCじゃん！だから論外として gcc が c++ で書き直された、という話はあったな >>76
https://github.com/search?utf8=%E2%9C%93&;q=language%3AC%2B%2B+stars%3A%3E%3D1000&type=Repositories >>76
Better C として使ってもええんやで 質問です。
宣言は、全ての要素に対して必要なのですか？
n = a+b:
という行があるとすると、
#include <n>
#include <a>
#include <b>
が必要なのですか？
とても初心者なので、なにとぞ教えてください。
お願いします。 意図がわかりにくいがその場合だったら#include <n> だけあればいいんじゃないの？
そうでないとしたらinclude順は#include <a>と#include <b>を先に書くべき。 >>84
#include は宣言じゃない
多分
int n;
int a:;
int b;
のことじゃないかな？ ＞84
#include
というのは、外部にあるファイルを読み込め
という命令なので、変数の宣言ではありません。
#include <a>
というのは、aというファイルを読み込めという
命令です。
n=a+b
という場合には、この式の前に、n, a, bという
変数の型を宣言する必要があります。
全てが整数ならば、
int a, b, n;
単精度実数ならば
float a, b, n;
と、倍精度実数ならば、
double a, b, n;
と書きます。
と変数の型を宣言します。
このことは、基本の基本なので、解説書の最初に書いてあるはずです。
解説書をよく読んで、その上で分からないことを
質問しましょう >>85-87様
googleだけの独学なので、とても勉強になりました。
とても、ありがとうございました。 >#include <a>
>というのは、aというファイルを読み込めという命令です。
んなこたーない >>87
>この式の前に、n, a, bという変数の型を宣言する必要があります
それは規格のどこに書いてあるのですか？ DEFINEもincludeも本質的にやってることは同じだしファイルを読み込めは間違ってるな includeがファイルをその位置に展開しろっていうのはあってると思うけど、何が不満なんだ？
defineはただの文字列置換。 × #include <a>というのは、aというファイルを読み込めという命令
○ #include <a>というのは、aというヘッダーを読み込めという命令
○ #include <a>というのは、#include <a>をaというヘッダーの内容で置き換えろという命令 >>84のレベルの人に説明するのに、厳密な用語をどうこういうより、>>87レベルの説明の方が適切だろう 仕様だとヘッダーとソースファイルは区別されてるみたいだけど
#includeはヘッダーとソースファイルのどちらも扱うから
二つを纏めてファイルと呼称しているとしたら>>94は間違いじゃないの？ 「C++の#includeがファイルを読み込むとは限らない」
という説明を何かで読んだ記憶がある。
例えばソースに #include <hoge.h> と書いてあっても
hoge.h というファイルの実体は存在しなくて、
コンパイラが内部的なスイッチとして使っても構わない、みたいな話。
実際にそういう動作をするコンパイラは知らんけど。 >>97
もとの>>87は#includeでなく#include <>なのだが
>二つを纏めてファイルと呼称しているとしたら
いきなり自分の結論を大前提に置かれても
まあこのへんはC++17で少し変わるだろう CSVファイルを読み込むときに#include使うことある てか、学ぶなら1冊くらい本買えよ
Googleで独学とか効率悪すぎる 軸がわからないと自分が何をわかってないかすらわからないからクソみてぇな思い込みで検索して見当違いの方向に突っ込んでしまうから、
そうなってから質問しても質問が見当違いすぎて回答しようがないことはよくある。 >>102
いっちょコンパイラを書いてやろうと思っているんだが何をやっていいかわからない…
手元の教科書は必死に正規表現やらチューリングマシンやらを追求している…
これってコンパイラ本だと思って買ったのだが、どうも本を間違えてしまったらしい
軸がわからないと悲惨ですね http://ideone.com/RcWgQx
これ、C++17でできるようになるんだっけ？どうだっけ？ 少なくとも似たケースを支援する機能は追加されるがそのままでは通らない
[*this] と思ってよく読んだら関係無かったしTは生存期間内だった
つまりC++17では無理 そうなんだ。ありがとう。
またウインドウを出せないのか。
綺麗なウインドウクラスを書く日は遠い・・・。 >>103
LLVMのtutorialでもやってみたら? (↓の一番上)
https://llvm.org/docs/tutorial/
たしか日本語訳もあったと思うけど、内容が古いので注意。 >>103
yacc, lex (または bison, flex) とかは知ってる？
使うと構文解析が楽になるよ。 >>108
単にstd::function使えって話じゃねーの？ >>111
WindowsのウィンドウをWin32APIで出すときは、Cのインターフェースに渡さないといけない。
なので、デフォルトキャプチャにthisのアドレスコピーが入ってくれないと厳しい。 >>112
typedef bool(*Fun)();
にキャプチャしたデータを置いとく場所が無いんだからいつまでまっても実現しないよ
そういうC言語のAPIにはvoid*でユーザーデータ渡せて引数で取得できるようになってるはずなんだからそれに規則性があるのなら(例えば最初の引数がユーザーデータになってるとか)テンプレートでラッパー書くの簡単でしょ >>105
できるも何も型が違うからエラーでしょ。
ラムダ型のオブジェクトはautoでしか受けられない。 >>113
クロージャって知らない？
>>114
条件を限定することで関数ポインタに束縛できるようになりました。
まぁ今回書いたのは願望ですけど。 >>115
キャプチャしないラムダ式は関数ポインタに変換出来るだけ。束縛じゃない。 クロージャがどのように実装されているか調べてみることを勧める。
そしてそれをC言語の関数ポインタと互換性がある形で実装可能か考えてみるといい。 >>117だよ。
駄々っ子みたいになってるが、
スレッドローカルみたいな変数を持たせれば持てないことも無いと思う。
まぁ、もうできないことはわかったので抜けます。 もういない宣言出てるけど、スレッドローカルでやられても困るだけだと思う。 >そしてそれをC言語の関数ポインタと互換性がある形で実装可能か考えてみるといい。
もともとC言語はλ式とか、（束縛変数がクラスのこともありえるが）クラスを構文でサポートしていないのだから
「C言語の関数ポインタと互換性がある形」と逝っただけでは何を指しているのか不明確にならざるおえない
呼び出し側がいかに煩雑な記述になろうとも、動けば互換性があるという立場をとってみるﾃｽﾄ、
束縛変数も毎回引数渡しすればC言語の関数ポインタと互換にできるのでは…
もはやクロージャでも何でも無いが一応動く >>121
>もはやクロージャでも何でも無いが一応動く
ちなみにどうでもいいことだがラムダ式から取得した関数ポインターはC++リンケージ型なのでC関数に渡してコンパイルが通る保証が無い >>122
関数ポインタ経由の関数呼び出しに関数名のマングルは関係無いのでは… >>123
関数名だけではない
extern "C" using CF = void(); と
using CPPF = void(); は似て非なる関数型
この二つはオーバーロード可能で互換性も無い
恐らくマングリのみならず関数呼び出し規約の違いを許容する思想
ただこれを正しく実装したコンパイラーを見たことは無い a = 0
2.times do
b = 1
3.times do
p a, b
end
end
「Rubyのしくみ」に書いてあるけど、Rubyは、Cで作ってあり、
do ～ end のブロックは、クロージャの実装。
ラムダ・Proc も、ほとんど同じ
子のブロック内で、変数が見つからなければ、
外のスコープ(先祖の方向)へ遡って、探しに行く >>125
そのとおり
規格では別の型と規定されている
atexitなど関数ポインターを渡す関数ではCリンケージの関数ポインターを渡すかC++リンケージの関数ポインターを渡すかで
C版atexitとC++版atexitのオーバーロード呼び分けができることになっている
clang/G++は意図的に規格に従っていないというのが痛説
Visual C++は規格より自分が正しいという意味不明な見解 や、互換性がない→別の型 は真でも 別の型→互換性がない はそうじゃないような。 そのとおりだ
暗黙の変換は禁止されていない
ただ暗黙の変換が可能というルールも存在しないので「コンパイルが通る保証が無い」と書いた なるほど。
上の方で原理的に無理みたいなことが書いてあった気がしたので念のため。 そういうCのインタフェースにはたいてい関数ポインタの他にユーザデータを指定できるようになっててそこにthisなんかを入れておくものだが、 >>105 は関数オブジェクトを関数ポインタだけに変換したいと言っているわけか……
コードを動的に生成すれば不可能ではないだろうけど、色々トレードオフがあるから言語の機能にするのはどうだろうね。
ライブラリを作っても良いんだろうけど、おとなしく定石に従っておいた方が良いよ >>132
動的にコードを生成したとしてもどこにその生成したコードを置くのか、それをどうやって解放するのかが問題になるね。だったらコード生成してもしなくても同じ事。 >>133
> 動的にコードを生成したとしてもどこにその生成したコードを置くのか、それをどうやって解放するのかが問題になるね。
そうだね。
> だったらコード生成してもしなくても同じ事。
同じではないね。 >>134
言い方が悪かったかな？
「どこにその生成したコードを置くのか、それをどうやって解放するのか」が解決するのであれば、コードを動的に生成しなくてもキャプチャしたデータ自体をそこに置けばいいだけ。 >>135
キャプチャしたデータ(またはそれへのポインタ)をコード以外のどこかに置くとして、それは関数ポインタ一つ(コードへのポインタをとるCのAPIにそのまま渡せる形)にはならないだろ。
何の話をしてるんだ？ MS は mfc の頃から動的コード生成でやってだ記憶がある。
this をロードして jmp みたいな小さいコードを生成して Window Proc として使う。 >>139
コードだっつーの
関数ポインタ一つしか渡せないwindowprocにthisを渡すためにそうやってるんだよ。
なんで知らんのに反論するかなー >>140
ひょっとして各インスタンスにコードが含まれてるとか思ってる？ w >>138
そのサンクらしきものはどこのセグメントに置くの？ >>143
MFCのどのクラスに動的コード生成の実装が書いてんの？ >>145
なんで急にキレるんですか？
あなたがソース読めとアドバイスしたからMFCのどのソースか聞いただけなのに。 理解しようという気持ちも理解する力もないのに質問すんなよ…
mfc ではやってたっけ？やってないんじゃないの？
というツッコミならともかく、
>>141>>142なんて思考力が虫以下だろ…どこのセグメントとかアホか
Win32 は古来よりフラットなリニアアドレスモデルだろ。
VirtualAlloc も知らなそうだし。 質問だと思ってる時点で低能確定やん w
まあセグメントと聞いてセグメントレジスタしか頭に思い浮かばない低能はROMってろ >古来よりフラットなリニアアドレスモデル
まさかそっちのセグメントに反応するとは予想外だった >>148
だいたいあなたがMFCの頃から動的コード生成でやってたって言い出したんですよ。
だから私はMFCにあるのはインスタンスの動的生成だという指摘をしたんですよ。
そしたら、再度あなたがATLのような実装があるんだと言ったんですよ。
ソース見ろとか言う人までいるから、どのソースか聞いたらキレて、なんで言い出したおまえまでキレんだよ。アル中か？
ここは相談室だぞ。 C++を身に着けたいと思いつつも、自分でC++で何かを作るモチベーションが湧かなくって、数千行程度のC++プログラムの写経でもしようかと思ってるのですがおすすめありませんか？
SDLを使ったゲームとか興味を持ちやすくて写経しやすいかと思ってgithubとか漁ってるのですがなかなかいいのが見つからなくて悩み中です
QtみたいなC++を拡張してるのは勘弁です あなたが何に興味を持つかなんてわかりません
C++以外の技能は？ てんそるふろーでも読んでみるとか。
今を時めくフレームワークだよ。 クソだと思うやつを俺が叩き直してやるってやっていればそのうち上達してる >>156
思いっきり叩いてやるからまず自分が書いたソースをどこかにアップしろ 他人に使わせる気のないコードなんていくら書いても意味ない
ソフトウェアとして公開して叩かれろ >>159
＞他人に使わせる気のないコード
どうすれば他人に使わせる気満々のコードになるのでしょうか？
ソースを公開する以外に何かしないといけないのでしょうか？ 使いたくなるか否か、それを判定するソースコードを見せてくれれば一番早い
そしてそのソフトウェア自体をその判定にかけると得点はMAXになるのは当然 >>160
・OSSライセンスを適用する
・有名処のOSSホスティングサービスで公開する
・ソフトウェアの目的と利用方法を理解しやすいようにドキュメント化する
・CPUやメモリなどのリソースを効率よく使用する
・汎用性が考慮された作りにする
・特殊化も考慮された作りにする
・バクが無いようにする
・こまめに更新し継続して改善されている事をアピールする
このくらいやれば他人に使わせる気満々のコードに見える >>163
なるほど
でも >>158 をやる気満々で公開しようと思ってもアピール点が見つからないんです
「C++ だけで簡潔する多桁演算」というのは訴求ポイントとしてはどうなんでしょうか
誰かやってるかどうかはさておき、魅力的がどうかは気になります 右辺値参照がやっぱりわからん
template<class T>
void test(T&& t) {
f(std::forward<T>(t))
}
このstd::forward<T>(t)は左辺値なの？
名前持つt(左辺値)を転送してるから左辺値でいい？
f()はf(T&)を呼ぶであってる？ C++11,14を勉強するのにいい本おしぇーてください。 >>166
forward<T>(t)はtをTの右辺値参照にキャストして返すんだから
f()はT&& tを受け取る(f(T&&)が呼ばれる)んじゃね？ >>166
それはforwarding referenceという機能を使ったperfect forwardingというテクニックで
右辺値参照を理解した先にあるものだ
右辺値参照の勉強中なら今は気にせず忘れておくもので
右辺値参照を理解してるなら右辺値参照とは別物として新たに勉強しなくてはならないものだ >>170
やっぱり右辺値参照へのキャストか
左辺値参照ぽい動きなんで質問してみた。ありがと
>>171
俺にはforwardはまだ早いってことスね
まずforwardなしでもう少し考えてみるわ >>166
もとの test という関数が右辺値、左辺値どっちでも引数に取れる、そして std::forward でそのまま転送している
f がとる引数の型は test がとった引数と同じ。
つまり答えは実引数次第だ。 死んだ？
むしろ他の提案が出ておちつきそうだったのに
自尊心を傷つけられたと感じたハゲがゴネだして蒸し返えされたような >>175
あんた詳しそうだな。今どうなってるの？？
猛烈にほしいんだけど、サクッと入らんかな？
詳しいリンクとかあったらいただけないでしょうか。 >>176
すまんが別の提案と間違えた。忘れて
open-std.orgのWG21のpapersの2016のP0251R0が最新ではないだろうか
何の動きもなくC++20ドラフトN4687にも入っていない 3年毎に膨らんでいく仕様とか嫌だな
そらリナスさんもブチキレますわｗ >>177
あぁ、情報ありがとう。やっぱ死んだままか。
手間かけさせてゴメンね。
やっぱコンセプト無いとコードサジェスト爆発するから気に入らないんだろうなぁ。。。 トーバル君は単に自分のニーズに最適な言語はCと言っているだけで
他の言語がどうなろうと知ったこっちゃないでしょ
それを周りのアフォどもが色々押しつけに来ることに時折ブチキレるだけで スキルの差によって読める、読めないの差がありすぎてもはや言語としての体をなしていない。
コンパイラによってもコンパイルできる、できないの差も激しい。大きなプロジェクトを管理する側はキレて当然。
癌のように誰も望んでない仕様拡張が続けられている。 メイヤーズがこっそりc++とバイナリ互換の新言語を開発している…と信じたい そのバイナリ互換ってなに？
C++11 以降で、役に立つ仕様とどーでもいい仕様とをわけるとすれば、何？ >>181
誰も望んでいない仕様拡張？
autoは？ range-based-forは？ R"リテラルは？
initializer_listは？ ラムダ式は？ template parameter packは？
<random>は？ shared_ptrは？ <regex>は？ <system_error>は？ >>181
ふつう、どの規格を使うかとか、場合によってはどの開発環境のどのバージョンを使うかまで
プロジェクトで規定するものだろう。
決めたことと違うコードを混ぜようとするメンバーがいたりしたらキレてもいいが。 少なくとも個別の提案はプログラムが読みやすくなるし楽になる方向なんよね。
だからまぁ、 >>181 の言い分にある「誰も望んでない」という言説には違和感があるな。
嫌だという人がいるのはわからんでもないが、
勝手にユーザ全体の意見を代表してしまうやつは単にクズなので、
誰も耳をかさないよ。 >>181
> スキルの差によって読める、読めないの差がありすぎてもはや言語としての体をなしていない。
日本語(自然言語）でも同じだろ。
馬鹿と天才でおなじ結果（コード）にしかならない、という方が問題だ。
それが天才側に揃っていれば理想的だが、実際は馬鹿側に揃うわけだし。
>>186
> 少なくとも個別の提案はプログラムが読みやすくなるし楽になる方向なんよね。
これは同意だが、問題は一部が本質的なところ（骨組み）まで変えられる程な点だろ。
現実的には>>185のようにプロジェクトリーダーが何を使うか厳密に決めればいい話で、
Linuxの場合はCだ、って言うんだから他の奴が布教しなければ丸く収まる話だ。
とはいえ通常製品の場合は「何でも出来る＝何にも使えない」ではあるのだが、
C++の場合は半製品（製品を作る道具）ではあるし、
実際、機能はあった方が便利だったりするので、（使う側がどこまで使うか決めればいいだけ)
プロジェクトリーダーがしっかりしていれば、現在の貪欲な拡張方向も悪くない。
「全部の機能を使わないといけない」と信じている馬鹿と初心者は混乱するだろうけどね。 >>188
>「全部の機能を使わないといけない」と信じている馬鹿と初心者は混乱するだろうけどね。
残念ながらこういう人たちは少数派ではないのだよ。。 >>188
馬鹿側に揃えるポリシーを見事なまでにやってのけた言語と言えば。。。
IDENTIFICATION DIVISION.
再帰できない、ダミーセクションできない、動的記憶ない、オラこんな村いやだ♪
で、その結果なにが起きたか。。。
エロパブの嬢がどこかで見覚えのある顔だと思ったら、うわあ（ｋｗｓｋはガン無視します） >>190
COBOLの事か？だとするとあれは試行錯誤の結果だ。非難されるべき物でもない。
そもそもあの時代の言語は再帰出来ないのも多かった。Fortran77もBASICもそうだろ。
俺が思うに、第一世代言語(C以前）は「プログラミングとはこうあるべき」、
つまり、プログラミング自体を規定しようとしている。
COBOL：自然言語の仕様書がそのままソースになるべき
C：所詮アセンブラ
smalltalk：オブジェクト間のメッセージングこそが真の未来
Lisp：ラムダこそ真理
BASIC：馬鹿でも使えることが重要
Fortran：所詮計算機だろ
で、C以外が全部糞だったのでCで統一された。
当然第二世代言語はCの後継で、C++/Java/C#のような面子になる。
とはいえ、COBOLの方向性は間違いでもないよ。
ソース自体が可読性のあるドキュメントであるべき、ってのは今でも理想だろ。 >>191
BASICは再帰できたぞ
FORTRANを実装できないマシン用に作られた縮小版で、
でもFORTRANより新しく作られた分、改良が図られていた
そのうちの、すべての行に行番号というのが賛否両論だった
当時初心者だった俺にとってはあれがラベルの概念の入り口になってくれたが
１桁KBのパーコンで構造化などという寝ぼけた老害たちがGOTOがどうたら言ってた
あ、嫁が呼んでるｗ じゃあな >>192
BASIC で再帰ができるのは，ハドソン系ベーシック等，マイクロソフト以外の BASIC ではないか？ メインフレーム用の一部の言語が再帰できないのは
当時のS/370がスタックのないアーキテクチャだったからだ
逆にBASICが実装された多くのPCではCPがにスタックを持っていた
なので全変数がグローバルなのでやりにくいができるにはできた
俺もBASICでの再帰は大道芸の域を出ることがなく
実用上の手の内に入ったのはCからだった >>194
> 全変数がグローバルなのでやりにくいができるにはできた
これは一般的には出来るとは言わない。
再帰が出来る＝関数ローカルの変数が定義出来る、だよ。
変数共通で突っ込むのは今なら「再入」と呼ばれる物に近く、
これは言語として云々ではなく、対応する構造にするかどうかだけ。
また、CPUのスタック操作命令は高速化に寄与するだけであって、
無ければエミュレートすればいいだけだろ。
その論法だとスタック操作命令がないCPUではC言語を実装出来ないことになるが、
これはないだろ。
(S/370上のC言語実装も無いとは思えないし) >>196
そこは俺とは見解が違うね
再帰の定義はサブルーチンの中からそのサブルーチンを呼び出すことで、
それをやりやすく補助する存在は本質じゃない
なのでスタックですら再帰の本質ではない
マシンによってはサブルーチンのネストが6層までとか限定されていて
それは何かというとリンクレジスタの個数でありスタックじゃない
再入は共通変数なんか使わないし、使ったらRENTじゃなくなる
メインフレームの流儀ではいちいちGETMAINとかね
メインフレーム上のCの実装は、俺が目撃したのはS/370じゃなく
ESA/370だったけどいちいちGETMAINはしてなかった 秀和の解析本にはBASICのくせにunwindがあるぞってなのが載ってたね >>197
> 再帰の定義はサブルーチンの中からそのサブルーチンを呼び出すことで、
> それをやりやすく補助する存在は本質じゃない
これは屁理屈だ。
なぜならこの定義では、「再帰出来ない」言語なんて無いから。
再帰出来る/出来ない『言語』を議論している時点で、この定義は無意味で、
「普通に再帰を記述した時に問題なく動くか」が議論用の定義になる。
これは当然であり、自明だ。
つか、君は何が言いたかったんだ？
君の定義ならCOBOLだって再帰出来るだろ？ 再帰アルゴリズムを繰り返し（ループ）アルゴリズムに変換することは普通のアーキテクチャー上では常に可能、
再帰回数に応じて新規のメモ化用領域を本質的に必要とするという重症なケースでも、最悪配列が使えればどうとでもなる、
>>197
メインフレームってグローバル変数として配列とか確保できなくて
いちいちGETMAINするしかないのｽｹﾞｰ
>>199
System/370で動くGCCの実装があったと聞いたわ（ただし今はSystem/390が動作下限とのこと）
再帰ができるかどうかはしらんｗｗｗｗｗｗｗ >>199
> 君の定義ならCOBOLだって再帰出来るだろ？
（当然だが当時のCOBOLは）できないよ
戻り番地を１つしか覚えてないのでネストしたら戻れなくなる C++17ドラフトのguaranteed copy-elisionが難しい
しかも規格が約50カ所修正されている
A a = A{}; と A a = f(); のムーブ無くすだけでどんだけ根本概念に手を入れてんだ >>199
だから見解が違っているねと言ったろ
アセンブラは再帰できるのか、できないのかという問いと、
COBOLは再帰できるのか、できないのかという問いに、
同じバックボーンで答えることが俺には出来ないが
おまえさんには出来るということだろ？
>>200
bfdではi370だね 犯人扱いしておいて違ったら知らん顔という制度そのものが間違ってる
捜査協力した人には謝礼だろうが
にせ伝票で架空の謝礼費を着服なんかしてないで
やるべきことをやれっての！ 架空の謝礼費を内部告発した仙波さん、えらい扱い受けたよね C++の最新仕様を追い続けられる人ってのはやっぱどこかちょっと変わり者というか
ふわふわしたものが許せないというか、なんとなく動いてるからいいや的な緩さが
許せないというか、白黒はっきりつけようぜ的な性格なのかな？って思ったｗ たったの千円でも知らん顔とは次元が違う
謝礼の対象でないという取り決めがあるばかりに
警察官の横柄な態度を誘発しているんだよ >>208
たかだか3年に１度の更新がそんなにしんどいのかよ
追い続けるもクソもねえ
重箱の隅をつついても１冊程度にまとめられる量しかないのに 最近は生ポインタ撲滅されそうと聞いたが
今までのメソッドとかどうしてるん
混在してるだろ プロパティーいつ実装されるのやら
getsetくっそマンドクサ >>208
ほとんどが待ってた機能だぜ？
言語仕様だけでなくライブラリまで
おまえろくすっぽC++使ってねえだろ VSのインテリセンスさんだって
いまだについていけず
ポンコツなエラー吐きまくってるわけだし
まだまだ大丈夫！ >>210
＞重箱の隅をつついても１冊程度にまとめられる量しかないのに
お前は本を出したことないから「１冊程度にまとめ」るのがどれだけ大変か分からないだけ それが本当なら恥ずかしい見積もりミスしてんぜおまえさん >>217
本を読む、理解する側の分量の話をしてるんだから、まとめる側の労力が大きいかどうかはどうでもいいのでは？ 雑誌ってエロ本か何かだろどーせ
技術系の雑誌やっててあーゆーバカ言っちゃ自殺もんの恥だぜ >重箱の隅をつついても１冊程度にまとめられる量しかないのに
その一冊程度の更新にclang/gcc/vc++すべてが追従出来ていないというのに >>205
情熱があるんだね，うらやましい‥
ガス欠状態から脱却した あいたた、本にまとめることも、実装とテストも、
とにかく量的な感覚がどこにもないのか >>213
なら、publicにしちゃえばいいじゃんといってみる。
関数は振る舞いを書くべきだと思うし、変数の代わりに使うものじゃないと思うんだ。
あと、オブジェクト指向的にクラス変数は基本悪である、ということも考えるべきではないだろうか。 >>227
横からだけど俺もそれに同意だ
余分な抽象化は単に工数が増えるだけ
しかしなんで"貪欲"な標準化委員会はプロパティは入れないんだろな >>229
変数そのものがバッキングフィールドにカプセル化されることで、変数へのアクセスを必ずメソッド経由にできる >>231
バッキングフィールドってメンバ変数をprivateにすれば今でも同じことできるんじゃね？ 地味に嬉しいのは既存のパブリックメンバ変数にアクセスしてるコードを変更せずに処理を追加できること >>232
privateな変数はclass内からアクセスし放題だけど、バッキングフィールドはアクセッサ経由以外では絶対に触れない c++erは厳しくしつけられているので、既存のpublicメンバがそもそも存在しない >>233
逆にそれが入らない原因なのでは？
軽い処理(public変数）なのか重いかもしれない処理（関数呼び出し）なのか、
見た目分かるようにしろってのがC++の流儀なんだろ。
俺はあった方がいいと思うけどね。
速度チューニングでこの手のマイクロマネージメントは全く意味がないから。 publicなメンバが一つもなかったらそもそもインスタンスを構築できないのでは… >>238
メンバ変数の公開よりもアクセサーを設けてインライン展開してもらう方がC++の思想的に望ましいのでは… >軽い処理(public変数）なのか重いかもしれない処理（関数呼び出し）なのか、
>見た目分かるようにしろってのがC++の流儀なんだろ。
C++って、それを判断するのが最も困難な部類の言語だと思うが。 set/get用のデータメンバをちまちま用意するという
狭い考えに限定してきやがる思考妨害アイテムは無用 >>240
それはオブジェクト指向の理想。C++はそっちを向いていない。
>>242
いや簡単な部類の言語だ。 ほう、ではこのプログラムがC++17で何回ムーブが行われるかわかるかね？
auto f() {
struct C{int m;};
return C{};
}
auto c = f(); 残念
0回または1回
因みに確認のためにムーブコンストラクターを追加すると0回に変わる ということで、見た目で判断することは難しいのではないかと つかお前ら他言語使ってないだろ。
逆に言えばC++はその程度の精度での見積もりが出来る、ということなんだよ。
GC言語なんてGCがどこで走るか予測不能だから、実行時間の保証なんて全く出来ないし、
JIT言語はJIT側にその最適化が入っているかどうかで全く速度が変わってしまう。
つまりJava/C#/JavaScript等はその精度での見積もりはそもそも不可能なんだよ。
それとは別に、C++はその辺の仕組みがかなり複雑になっているのは認めるが、
それでも他言語と比べたら精度高く見積もれる方だよ。
getterを使った場合の問題は、それが見積もりにくくなることと、
あまりに多用するとどこで処理しているのか分かりにくくなる点だが、
まあ、適切に使っている限りはかなり使える機能だから、有った方が便利なんだけどね。
だから普通に考えれば「貪欲」なら当然入れるべきだし、
むしろラムダより先に入れるべきだが、入れないんだから何か引っかかってんでしょ多分。 getter がただの変数アクセスに被せてあるだけならまともなコンパイラなら最適化で消えるから速度的なペナルティはゼロだよ。 a = 1;
こんなコード片で、aの型がプリミティブ型かconstr(int)/operator=(int)を持つクラスなのかによって
実際に実行される処理内容が違う時点で
>軽い処理(public変数）なのか重いかもしれない処理（関数呼び出し）なのか、
>見た目分かるようにしろってのがC++の流儀なんだろ。
そんなものないとわかるだろう。
それににしても、そこからGCのオーバーヘッドに話が飛ぶのはさすがにアクロバティックすぎるw
実実行時間の話なら、マルチスレッドの非リアルタイムOS上のプログラムはどれも正確な見積もりなどできん。 プリミティブ型？ ああJava訛りね、C++用語はISO/IEC14882:2011 3.9.1に規定あるから
a = 1; がビルトインの代入か、トリビアルのoperator=か、
ユーザー定義のoperator=か、コンストラクタを呼び出すか、
コピーかムーブか、読めない人はC++には向いてないので無理しなくていいよ
要するにアセンブラ苦手なんだろ
マルチスレッドでもタイムクリティカルとか割り込みマスクとかあるしね
別にRTOSに限ったことじゃなく >>254
オメーは何が言いてえんだw
無意味に反論するんじゃねえよ
だからアホだって言われるんだよ C++を批判するには
おまえ足んねーものが
多すぎつってんだよ C++ 標準委員会のドワンゴ江添は、職務質問の手荷物検査を拒否したら、
警官10人に、現場で1時間半以上、拘束されたらしい
捜査でもない、任意の行政処分なのにw
それで東京都を訴えた >>254
> a = 1; がビルトインの代入か、トリビアルのoperator=か、
> ユーザー定義のoperator=か、コンストラクタを呼び出すか、
> コピーかムーブか、読めない人
それがわかったからと言ってなんになるんだ？
定義が常に読めるとは限らんだろ
> 要するにアセンブラ苦手なんだろ
逆アセしてでも読めとか言ってるなら単なる老害のアホ >>258
ほーお、おまえさんは定義が読めないと判断できないのか
普通の人は宣言まで読めれば判断できるんだがｗ
逆汗読まないほうがバカガキ
バカガキからみて普通の人は老害というだけ IDEがやれば済むこと
わざわざ言語に入れる必要なし！ メンバ変数と関数の呼び出し統一化。
いらんというのは同意。 オブジェクトの状態と操作の区別
関数でも代用できてしまうけど、変数のように扱えるってのが大きい
変数のような使い方で処理を挟める、これはPublicなメンバ変数では出来ない できるよバーカ
C++98より前、ARM C++の時代から たしかに、operator()とoperator=があればできそうではある ARMだとテンプレートないから、メンバ変数にしたい型ごとにラッパークラス作らないいけないから大変そう 質問ですが
std::string str("abcdefghi"); // (*1)
str.resize(8); // (*2)
size_t len = strlen(str.c_str()); // <-- "abcdefgh\0"の長さが返る (*3)
となるのですが、(*3)の時点でできる終端NUL文字"\0"って、
いつのタイミングでどこの領域に確保されるのですか、 訂正
×：、(*3)の時点でできる
○：、(*3)の時点でできている >>270
そのスマートオブジェクトをメンバ変数にした場合、一々親へのポインタをそのスマートオブジェクトに記憶してやらんといけないからすごく面倒なのだよ
プロパティはその点何の束縛もないから良いのだ >>272
アフォｗｗｗ
template と try catch それと typeid はARMで新設されたんだよ
おまえ多重継承だけだと思ってんだろ >>273
(*2)の時点で 'i' があった場所に置かれる、
と素朴に思ってた >>273
(*2) の時点で新規領域に abcdefgh をコピーしてその後に \0 を置く コピーが生じないんだとしたら、
std::string::size()はいつも1バイトだけサバを読んだ値を返すってこと？ Windows Phoneの開発で使うC++/CXにはpropertyが構文でサポートされているで
ていうかpropertyがあることが存在意義な感じ？（ネイティブなC++は別にあってそれはそれで利用可能 データメンバ直アクセスでなくてpropertyにすると良いことがあるというのは
マーシャリングを裏で勝手にやって来る点 ｜
｜ ('A`) .oO（名前考えるのﾏﾝﾄﾞｸｾ
／￣ﾉ( ﾍﾍ￣￣￣
／ 0変数:getter, 1変数:setter, 尻尾付き:メンバ変数
とかは良くやるな >>287
それ以前のVC++/CLIからサポートされてる。
>>286
駄目。
propertyは新規機能ではなく、見た目だけの問題だから、
逆に言えば、見た目がpropertyで書いた時より分かりにくいようなら駄目なんだ。
ほぼ同じ事はラムダとファンクタでもそうだけど。 >>268
オペレーターのオーバーライドとにたような感じになると思うけど、その挟み込む処理の重さが隠蔽されてしまうという問題があって、一般には、非推奨だとおもうのだけど今はかわってきてるのかね？
たとえば、代入しているだけだとおもったら、実はファイルアクセスまでしてたとかかな。 >>293
>258理論によれば、老害じゃなければ一目で処理の重さがわかるんじゃね
もっとも処理の重さに関するC++の不透明さに警戒を抱くことを老害とするならば、
カーニハンやリッチーも老害にカテゴライズされてしまうが >>294
K&Rというか生Cが嫌っている理由は「余計なことをするな」だ。
適切に使っている限りC++は不透明ではない。それでも彼等は嫌うだろ。
>>293
横だが結局は使い方次第だよ。C++はいくらでも読みにくいコードを書けるから。
ただ、きちんと使えば有用な機能だよ。
演算子オーバーロードについてはgoogleは「慎重にやれ」だね。
https://ttsuki.github.io/styleguide/cppguide.ja.html#Operator_Overloading
どうでもいいが、何故演算子は「オーバーロード」なんだ？
言われてみれば「オーバーライド」の方が適切な気がする。 >>293
それは言語機能の問題じゃなく実装の問題じゃない？
propertyってメンバ変数がどうなっているかに関わらずオブジェクトの状態を表すもの
言語機能の話をしているのであって
既存の機能をやりくりして似たことは出来るって言われてもって感じ 「処理の重さを隠蔽するな」なんて思想がそもそもあるのかね？ >>295
オーバーロードは新設で、たいていのoperatorがこっち
オーバーライドは変更で、代入やnewが本当はこっち property ってパブリック変数とどう違うの？ >>294
> >258理論によれば、老害じゃなければ一目で処理の重さがわかるんじゃね
どこにも「わかる」って書いてないのにどんなアホ解釈したらそんな結論になるんだよ w >>295
> どうでもいいが、何故演算子は「オーバーロード」なんだ？
> 言われてみれば「オーバーライド」の方が適切な気がする。
オーバーロードとオーバーライドの違いもわかってないの？
まあ>>298も色々おかしいが >>300
>>254～>>258の流れをa=1;の実行速度が一目見てわかるのかどうかという問題提起の意味に解釈すた、
パフォーマンスを読みきるには何の言語であれボトルネック（ループ回数×1回の実行時間が最大の処理）の特定が必要だが
C++は演算子のオーバーロードとかインライン展開とかテンプレートがそれ以前の障害として立ちはだかる点がCより重症
パフォーマンスを上げるための手段を豊富に提供してプログラムを書く人の選択に委ねているみたいな？
つまりC++はソースコードのROM専はお断りな言語
>>295
ｽﾏﾝ言いたかったのはK&Rではなくてカーニハンとロブ・パイクやったorz
『プログラミング作法』の第7章「性能」のところにC++の特性について（CやJavaとの比較が）書かれていた希ガス、
（目次）ttps://tatsu-zine.com/books/practice-of-programming
ちな本は売ったから手元に無い
>>297
本来のK&Rがまさにそれなのでは…
Unixの移植目的で作られた言語なので、移植性と意図通りのアセンブリコードに落ちること
（ソースコードからアセンブリコードが透けて見えること）の両立が着手時点の第一優先だったはず
故に生ポインタが言語の前面に出てきてインクリメント/デクリメントがそれぞれ2種類あった >>298
いや、new もオーバーロードでしょ。 新しくメモリのようなものを持って来るってことでしょ。
言語上ではオペレーターじゃないの？ オペレータはオーバーロードするもんじゃね？
まぁいいか。 >>305
「本当は」って書いてるだろ
# 流れを読んでない近視眼的なアフォどもは無視 「本当は」とは？
C++の規格？
本来の英語の意味？ 突然「本当は」とか書いても、どういう意味でどういう意図で書いたかなんてわからんぞ >>304
ごちゃごちゃ書いてるけどどこから
> 老害じゃなければ一目で処理の重さがわかるんじゃね
が出てくるのかさっぱりわからん >>311
いや、グローバルのオペレーターに対して、型特化を新設するんだから、newも代入も、オーバーロードでいいんだよ。って話。
c++の実現方法（クラス内定義）でイメージしちゃうから、オーバーライドと思っちゃう気持ちはわかるけど。 ::operator newは新設か？
ユーザー定義するとビルトインを置き換えるだろ operatorをオーバーライドしてる人いるみたいだけど、operatorを仮想関数にするのってどういう時なの？ >>323
具体的には何のoperatorをオーバーライドしてるの？ operator==を仮想化したら、多態性が必要な状況であれこれはかどるだろう。
Numberクラスを基底として、RealクラスやらComplexクラスを作ったりしたら、同値確認にoperator==を使いたくなるだろう。 >>327
それってダブルディスパッチの問題起きないの？ よく分からん揉め方をしているが、
俺は>>298の表現は極めて的確で分かりやすいと思うぞ。
俺はあれで納得だ。サンクス。一応言っておく。 >>327
RealクラスとComplexクラスを比較した時の振る舞いが直感的じゃなくね？ はてoverloadとoverrideは排他的な存在だっただろうか
ちなみに規格で::newはreplace, displace
overrideとは言わない >>333
その場合はオーバーロードよりも強力なダブルディスパッチを使うのが妥当だった。すまね。 まだおまいらオーバーなんちゃらで言い争っているのかｗ >>332
operator newって仮想関数にできなくない？ なんでオーバーライドが的確なの？ >>336
言い争ってなんかいねえぜ
一部のアフォどもをこっちはスルーしてるんで争いになってない >>334
排他的くねなぜならシグネチャが変わらないオーバーロードは無いしシグネチャが変わるオーバーライドもこれまた無いからだ そうか？
https://ideone.com/VOwt42
これはオーバーロードかつオーバーライドだと思うが
オーバーロードは特定の関数について言及しているのではなく同一スコープに同一の名前が複数存在する状態を指すものだと思っとりました >>341
それは
上の方はオーバーライド
で
下の方はオーバーロード（を追加している）
でしょ
関数単位で見たら排他だと思う >>342
あー左様かvoid B::f(int)のオーバーライドとf()のオーバーロードが同時にありえるのか、
完全に排他的（背反）というわけでもないな
ただしそれぞれ独立な概念とは言える
なぜなら下記の4通り全ての組み合わせが有り得、互いの成立要件に他方の成立の真偽が関係しないだから、
1. オーバーライド∧オーバーロード
2. オーバーライド∧￢オーバーロード
3. ￢オーバーライド∧オーバーロード
4. ￢オーバーライド∧￢オーバーロード 訂正
△： ただしそれぞれ独立な概念とは言える
○： ただしそれならそれでそれぞれ独立な概念とは言える 同じ名前の関数で、引数が同じならオーバーライド、 引数が違えばオーバーロードだよ？
そんなに難しい話じゃないはずだった気がしたんだけどな。 >>345
usual な operator new は、いつも
void* operator new(std::size_t);
というシグネチャなのに、なぜオーバロードなのか
という話題だったのでは？ 「同じ名前の関数で、引数が同じならオーバーライド、 引数が違えばオーバーロードだよ？」
これまた珍説を >>347
＞引数が違えばオーバーロードだよ？
演算子のオーバーロード みんな人に説明できるだけのまともな言語能力を備えてから来てくれ
あとクソみたいな反論をするのもやめよう >>348
それは>>298と>>319を読んだ上で物申してるのかね constオブジェクトのデストラクタって
一般に中で非constメソッドを呼んでいるのに
なんで合法に呼び出されるの？
それとも合法に見えるのはVC++固有？
プロセスが死ぬまで破棄されないのが正しいロジックなんじゃないの const の考え方には logical const と bitwise const があって、
logical const を実現するために言語としては bitwise const を基本として要求してる感じ。
logical const ってのは論理的な const 性で、
bitwise const ってのはビットパターンとして不変ってことね。
mutable キーワードを付ければ const なメンバ関数からも操作できるデータメンバを
作れるけど、これは bitwise const でなくてもよくなるだけで
logical const であることは要求される。
(その性質を満たすようにプログラマが配慮しないといけない。
コンパイラは面倒みてくれない。
reinterpret_cast と同じくらいには危険で面倒くさいと思う)
寿命が尽きたオブジェクトにはアクセスは許されないから
もはや logical も bitwise も関係なく const 性は無意味になる。 >>354
>寿命が尽きたオブジェクトにはアクセスは許されないから
>もはや logical も bitwise も関係なく const 性は無意味になる。
これはだいたいﾜｶﾀ
前半はわからん
bitwise const でないオブジェクトがROMに割り付けられたり、とか、
bitwise const でないオブジェクトがmemcpy()的手段で同じビットパターンに繰り返し上書きされるみたいな
処理があったりするとbitwise constでないことは致命的だが
それ以外のケースではconstといいつつクラス内部ではmutableな扱いであっても全く実害無いんじゃ…
ていうかそもそもC++の非PODオブジェクトに対するconstはbitwise constなのかかなり疑問が、、 >>355
logical const であれば性質として充分だよ。
だけど、それをコンパイラがチェックすることは出来ないから、
原則としては bitwise const を要求して、
それがちゃんとできてなけりゃエラーも出す。
だけど、 bitwise でなくても logical に出来る場面では
プログラマの責任でやるよっていうのを mutable キーワードで表すってわけ。 おい、mutableなんてキーワード初めて知ったぞｗ
ググってみたらC++11から導入されてたんだな知らんかった、、、 >>359
ANSI で規格化された最初から有ったがな (´・ω・｀) 「C++の非PODオブジェクトに対するconstはbitwise constなのかかなり疑問が」
標準レイアウトではないconstexprなオブジェクトはビットレベルでconstなのだろうか
constexpr struct A { constexpr A()=default; int m=1; private: int n=2; } a;
確かに疑問だ どんどんキーワードが増えるのは思いつきで仕様を決めてるからだ。
無能SEの下のプロジェクトではよくあること。
50年は仕様を追加しないつもりで仕様を決めてほしい。 コンピュータを取り巻く事情は予想の斜め上をいく形でどんどん変わるのに言語だけのんびりしとれるかいな 永久に仕様が追加されない言語なんてたくさんあるから好きなのを使いなよ
機能が必要になった背景やそれを追加することが適当だという根拠まで知ってろとは言わないからさ 雑魚に上から言われる筋合いはない。そんな態度だから囲まれて職質されるんだよ。 つ、追加しなくても1.5年待てば倍速くなるもん…！
ていうかメモリバリア周りの扱いが未だに規格化されていないのは言語としてはお寒い状況だといわざるおえない
ゆくゆくはOpenMPIを正式に取り込んでキャッシュスヌープ無しのメニーコア環境でも
最高のパフォーマンスを発揮できるだけの選択肢をプログラマに提示し、
さらにはGPGPU対応もしてﾎｽｲ、 ｽﾏﾝOpenMPIはOpenMPのつもりで言った！ openmpみたいなマクロまみれよりtbbのほうが好き そんなに新機能を追加したいなら、新しく別言語を創れ。JavaやC#みたに成功して普及した事例はいくらでもある。
一度普及した言語に、碌に実務でコードも書いたことないような輩が後からやってきてデタラメな糞仕様を追加するんじゃない。 CとC++が同じ言語と思ってるとは、さすが見込みどおりの雑魚。 実務でコード書く人＝Windowフォームにボタンを乗せる仕事の人 ライブラリの蓄積もあるからさ。 負債の蓄積とのバランスだよねー。
ときどき Go とか Rust とかみたいなのが出てきて一新してくれりゃいいんだけど、
C++ はともかく C はいつまでも死なない気がする。 別に新機能のほしいものリストを無秩序に書き連ねたわけではないもん；；
C++はSimulaの代替品として登場した時点から実行時パフォーマンスの追求を意識していたし、
理解しやすさなら他の言語を選択すればよい昨今においては
特に実行時パフォーマンスの追求こそがC++の存在意義として強調されるべき
テンプレートによるメタプログラミングに最高の効率を阻害する穴があれば塞がれねばならないし、
最適化がほっといたら中途半端にとどまるケースには尻を叩くキーワードが追加されねばならないし、
そのときどきのアーキテクチャーの詳細に立ち入ってでもあらゆる実行時パフォーマンス追求手段が
プログラマに提示されねばならない
インテリセンスがまともに働かないとかテンプレートの分割コンパイルがもはや完成しないバベルの塔だとか
言語規格が変わり続けて解説書が分厚くなる一方だといった側面の不調法はそうであってこそ許容される、 機械の方が人間より賢くプログラムするようになってアセンブラが滅びたら
Cも滅びる気がする ウニファイドコールシンタックスを直ちに入れるのです。
コードサジェストが爆発してもいいじゃない。 >>377
機会が賢くなったら、あらゆる言語をCに一回トランスコ―ドするようになる気がする。
そこでパフォーマンスチューニングしてコンパイル。
人間だとコストかかってできない方法。 中間言語とか3番地コードと条件判断とgotoで必要にしてほぼ十分なのでは… >>380
あーそんなもんか。
それじゃ、アセンブリにした方が早いね。
もしくはあらゆる言語がLLVMを介してコンパイルされるとかね。
LLVMのストラクチャも自動生成とか。
あー怖い。 ちょっとしたコーディングミスで、以下の簡易コードように書いてしまって、ハマったのですが、コンパイルエラーにならなかった事に驚きました。
string a(何らかの文字列);
string s = s.replace(置換指示); //a.replace() と書こうとした。
コピーコンストラクトの右辺に、構築中（？）の自分自身を使ってしまったと言う事なのですが、これは規格上合法なのでしょうか？ x^=x でゼロになるんだっけ。
一応昔からある文法だけど。 >>384
それの使い道がよくわからん
コンパイラと環境によっては x=0 より速かったりとか？
即値は全て名前を付けなきゃいけないとかいう糞コーディングルールの回避とか？
volatileをつけて、
ダミーリードと0クリアを1文で書けるとか？
思い付くのはこのくらい コンストラクタが実行される前なのでオブジェクトの内容は不定だろうし
不定なオブジェクトにも適切にアクセスする場合なら合法かもしれない
ただ不定な変数を使って何かしようとすると途端に undefined behavior 地雷を
踏むことが多いのでそこで頑張っても実りがあるとも思えないけど >>385
アセンブラでよく使う xor eax,eax を逆コンパイルするとアレになる xor eax,eaxがゼロクリアで、
or eax,eaxが何もしない。 さすがにPC系コンパイラで
0クリアを最適化しないのは無いかと
xor eax, eax は0イディオムとか言って、
普通のxorとは微妙に扱いが異なる
昔は sub ax, axより xor ax, axの方が微妙に速かったりした
今はフラグ以外は同じ
>>390
何もしないわけじやない
ちゃんとフラグが変わる ttp://www.st.rim.or.jp/~nkomatsu/premicro/corezoom2.JPG
昔とはこういうスゴイ編み物の時代ですかね 編み物だって意味のあるつまらないことの積み重ねで実現されている。
プログラミングだって多分同じ。 コルモゴロフの最小プログラムに対しても同じ事が言える？ >>382
質問を変えると、
何でコンパイルエラーにしてくれないんだろう？
ってところが気になっています。 >>382
3.3.2/1には反しないが3.8/6的にはだめだろう(たぶん)
未定義動作なのでコンパイルエラーになることは要求されていない >>391
それは x86／インテル方言なだけでは？
普通のアーキテクチャならばロードだけでフラグが変わるもんですキッパリ inline void zero_clear(int& x) { x ^= x; } そう言えば64bitアセンブラ勉強してた時ウェブで64bitレジスタでxor rax raxってするより、64bitプログラムでもxor eax eaxってした方が機械語短いって書いてたな。
アセンブラ上は同じ長さだけど、機械語上は64bit命令の方が長い＆32bitレジスタへの操作は自動的に64bitレジスタの上位bitがゼロクリアされるから同じ動きになるとかなんとか。
キャッシュに入るコードが増えるから速くもなるらしい。 intel公式のドキュメントに書いてあるレベルだから
普通のコンパイラは当然そういうコードを吐くと思うよ OpenMPIを用いたプロセス並列コードのプロファイルを取りたいんですが、
gprofだとテンプレートがごちゃごちゃしててすごく見にくいです。
何か勧めなフリーのプロファイラはないでしょうか？ 座標を動的配列で格納していき、
(50,50),(100,100) //直線1の座標
(30,30),(70,70) //直線2の座標
↑こんな感じに直線の数だけ座標の組み合わせが増えます。
この上から2個の座標の組み合わせ、
つまり座標4点を使い交点を計算するプログラムを作ろうとしています。
計算式を作っていく際にfor文を使っているのですが
1つ目の座標の組み合わせと2つ目の座標の組み合わせを計算式内で使うので
二重ループがいいかと思い作ろうとしましたが動的配列での二重ループの作り方が分かりません。
助けて頂けないでしょうか…。
長々と申し訳ありません。 >>396
void* p = &p;
↑こういうのは受け入れないといけない一方で >382 を NG とするための境目を
ちゃんと定めてコンパイラ実装するのはめんどくさそうだなと思う。
頻繁に踏む問題でも無くてコンパイラ実装者がそこに注力する動機も薄そうだし。 >>397
む、なるほど…
確かに未定義であれば、コンパイルエラーにしなくとも文句は言えませんね。
>>408
!!!なるほど!!!
実用性はさておき、その例文で納得してしまった。 >>407
動的配列だと何が問題あるの？
何につまずいているのかよくわからんなあ
例えばキューで実装するとか
直線をひとつづつプッシュ、
描画タイミングで直線を必要数ポップし交点を描画 Iteratorで2重ループするやり方がわからな
いとか？ はい
iteratorでの二重ループが分かりません。
x1={1,2,3}
x2={4,5,6}
1*4 , 1*5 , 1*6
2*4 , 2*5 , 2*6
3*4 , 3*5 , 3*6
といったような計算が出来るプログラムを動的配列でつくりたいです。 >>412
まず通常のループは書けるの？
たとえばx2は4固定でいいのでループを記述してみたら？ >>415
通常のループも、二重ループもあらかじめ用意した配列でなら書けます
動的配列になるとiteratorの使い方が分からずプログラムが動かなくなってしまうのですが笑
>>416
ありがとうございます使ってみます！ >>419
つまり分からないのはイテレータのループそのもので、二重ループは関係ないということかな？ perlのfor my $elem (@array){をやるのに何年懸ったんだろうといつも思う >>420
そんなかんじですね
たとえば、x[i+1]をiteratorのループではどう表現するのかとかそういうのが分からないとかです イテレータは繰り返しを前提としているので基本的に進むと戻るの操作しか提供しない。ランダムアクセスっていうのもなくはないけどね。
it++で前進、it--で後退。操作して、Container.begin()と同じ値なら先頭を、Continer.end()と同じ値になったらそのコンテナの末端を指している。
基本的にはポインタを抽象化したものだからポインタの操作を思い出すと少しわかりが早い。 >>422
君には早いのでまずはポインタでぐぐってくれ
x[i + 1] == *(x + i + 1) ポインタではループ書けませんって
なんかつき合う気失せるぐらい初心者やね
いやアンタが悪い訳じゃないんやが >>419
それ、end()が何を返しているかとか、
連続領域でないのにポインタを返しているとか
そういう系の問題じゃね？
あと「イテレータのループ」というのが
range-based-forだったりすると
x[i+1]はそもそも無理だぞ みなさんありがとうございます！
もっと勉強して出直してきます Cとjavaの基礎やったから基本の文法とオブジェクト指向の触りみたいな部分だけわかるんだけどこの状態でテンプレートとかの勉強初めていいの？
あそこらへん急に難しくなるイメージあるけど他に先にやるべきこととかあります？
あとそういう人におぬぬめの本とかもしあったら教えてくだされ >>428
まずテンプレートライブラリの使用方法を重点的に
自分でテンプレートを書くのは後回しにしたほうがよい >x[i + 1] == *(x + i + 1)
はて、いったい何の言語の話だろうか >>424
ポインタを意識させないのがイテレターだろうに
>>430
左辺と右辺が同じだって事が言いたいんだろうけど...
上に書いた理由でトンチンカンと言わざるを得ない >>422
it_next = it;
it_next ++;
とか >>432
意味がわからない
もう少しわかりやすく頼む
出来ないならもう発言しなくて良いから なぜにイテレータでやろうとするのか
valarray使えばこんなの即効だろ あのー、このスレに限らずどこもなんだけどさ、
初心者をケナスくせは、やめた方が良いよ。
ちょっと知ってる者の傾向だね。
ちょっと自分が物事を知ってるから、
「自分らが、上だ。と、知らない者をけなす癖」が多大に有るよね。
本当に知ってる者は、初心者にもやさしく教えてあげるよ。 >>432
>左辺と右辺が同じ
少なくともここはC++のスレで、C++では同じでないのだが何を言ってるんだお前は 知らない者を貶す気はないけど知ったかの頓珍漢な指摘は全力でバカにする また規格に自信ある奴が日本語読めてないな
日本語の文脈を理解できるようになってから発言してくれ >>437
C++でいつでも同じかなんてことはどうでも良い
レス自体トンチンカンなんだから 全くその通りだよね
ポインタ滅ぶべしとか思ってるのかも知れないけど、初心者はまずイテレータを理解してその後
ポインタを学べば良いなんてプロセスは効果的とは限らないし、個人的には無理があると思う。 C++使ってて初心者は隠蔽された中身を理解しなくていいとか本気で思ってる奴いるのかよ
それにイテレータはポインタのような操作ができるインターフェイスなのでポインタを理解してることは前提となっている 逆だよ。初心者は隠蔽された中身を理解しなくていい範囲と使うべき。
初心者に教えるときも注意しなきゃいかん。 >>443
イテレターを使う上で、ポインタを知らないと何が問題？ 「あたかもポインタのように振る舞うオブジェクト」を使うにあたって
そもそもポインタを知らないことの何が問題か本気でわからないのか？ イテレーターのコンセプト、理解してる？
ポインタのように振る舞う、じゃないよ。 イテレーションすることを目的にしてるけど、
ポインタもイテレータの機能を持ってるからポインタを想像するとわかりやすいっていうのはある。 >>447
どっかから引用したわけじゃないんで
そういうフレーズにはなってないだろうなあ
ポインタの使い方に、イテレータの使い方を似せてあるのは
誰の目にも明らかなんだが、おまえだけ違うのか？
重箱の隅でない説明がもしできるなら拝聴したいぜ ポインタに似せるというコンセプトではないので、ポインタと同じ構文で操作できてもポインタとは何の関係もありませ〜んｗｗｗｗ
そんな話してねえだろコミュ障か？ イテレータの使い方がポインタの使い方に似せてある…？
もしかして、イテレータの意味わかってないんじゃないか？？ >>451
はいはい
イテレータはポインタの操作方法と互換性がある
ただし静的配列やvectorで使われているランダムアクセスイテレータはすべての操作をサポートしているが、それ以外ではサポートしていない操作もあるので注意
とまで補足を入れたらいいんだろ
配列の話をしていたはずなのにアスペはすぐ話の腰折るから困る むしろ初心者ほど中身を知りたがるもの。
イテレータなんて実装が隠蔽されてるわけじゃなし、知った上で抽象化したらこうなるってのが妥当な方向だ。
コンパイラがやる最適化等とは別の話だ。 だいたいポインタの理解なんて義務教育レベルだしな。 >>450
初心者に教える、つう前提を無視するなよ。アホか？
なんで初心者にイテレーター教えるのにポインタが必要なんだよ。説明してみろ。 さあねえ
俺はポインタを知らんやつにイテレータを教えたことがない
それを馬鹿にしたければするがいい
じゃあ、あんたはどうやって教えたのか、こっちが聞きたい >>456
その場でイテレータを使うだけなら必要ないが、それでは何故か動くおまじないになるだけ
マンツーマンじゃあるまいし基礎を理解していない者に教えるのは疲れるし両者にとって不毛だ
複雑な実装のイテレータを理解しろともコンピュータの仕組みを理解しろとも言ってないし
キーワードだけ見つけて何がなんだか分からない助けてくれと言う前に簡単な基礎からやれという指摘はおかしいか？ >>453
ちがうちがう
イテレータっていうのは繰り返しの抽象化だから、ランダムアクセスだのなんだのってのはおまけ
ポインタっていうのはアドレスに少し機能を付け加えたもの
リストのイテレータはリストのポインタと関係ないが、リストの特別版である配列のイテレータは配列のポインタと互換がある
だから、イテレータの操作とポインタの操作に互換があるというのは間違えてる
人に教える前にデータ構造について一から勉強しなおしたほうがいいのでは？ ポインタに限ったことではなく、イテレータでもハンドルでも
「何が」「どこにある」という情報を持つもの、という概念を説明するとき
ポインタが最も直接的な実装となっているので
具体的なアドレス値を図に書いて説明できるし
復習するにも実測値でその図を書いてみることができるし
デバッガでも関係性を追ってみることが出来る
++で何をどう増やしているのか、比較とはどういうことかも
実測値から直感しやすい
そして、それで憶えたことがvectorのイテレータでならとりあえず通用する
そこからlistだとかistream_iteratorだとかへと差分学習で進めば楽だし
algorithmもポインタさえ知ってればとりあえず使えて
そこからまた差分学習でイテレータで使う場合を憶えれば楽という経験則
何か間違っているかね？ 誰かさんみたいに、ちがうちがうと自分の繊細さに酔うやつが
学習者の思考を丹念に潰しやる気を削いでいく有害な騒音源となる
語学の先生にもいるだろ？ イテレータはポインタに似せたというよりは、部分的にポインタと共通のインターフェイスに抽象化されたものであって、
C にも有ったポインタという機能と新しい機能を無理なく (?) 統合するアイデアでしょ。
だから、どちらが先にありきと言えるものではないけども、
大抵の C++ 入門書だと時代的に早く出現したポインタを先に説明するのが一般的だと思うし、
初心者がその流れに沿わない学習をしているのだとしたら
体系的に学ぼうとせず場当たり的に調べてるんじゃないのと疑うって話じゃないかな。
前提がちゃんと出来上がってない人の質問にきちんと答えるのは無理だよ。
だからこれとこれを先にやった方がいいよっていうのは誠実な回答だよ。 >>459
マジでアスペか
実用上どのように使うかって話をしてるのに、聞いてもいないのに一人で勝手に賢いイテレータの定義の話をしている
お前は>>412と>>419と>>422を100回読んでから入門サイトでどんな説明をしてるか見てこい
俺はその上で質問者のやろうとしていることは、ポインタを操作することと同じなのでまずポインタを理解してくれと言っている >>462
は？ イテレータは少なくとも1993年以後にできたもので
ポインタはBにもあったもので、どちらが先にありきは明白だ
イテレータの設計にあたりポインタを意識しなかったなんて珍説を唱えるには膨大な説明がいると思うが
おまえやってみるか？ 33e4-p7enの主張が二転三転していて何が言いたいのかわからん std::optionalもアクセス構文が同じだから、使うにはポインタの知識が必要なのかな >>463
必要なのは配列とインデックスと有効範囲だけだろ。ポインタを説明する必要は無い。 >>467
使うために必要かどうかではない
ポインタはC++を使う上で知ってて当たり前
ID:95r+Hm0D0 みたいに添字しかわかんねえと言われたらお前はそれよりもポインタからだとなる もうやめてくんない？
誰もイテレータの成り立ちなんて興味ないのよ 初心者に配列管理を説明するのにわざわざポインタ持ち出すな、つうてんの。そういう事言ってるから老害なんだよ。
range-based forを説明した方がよっぽど有益だわ。 >>460
もちろんvectorを例にイテレータとポインタをまとめて教えるのは一つの手段として有りだと思うよ
ただ、何度も書いてる通りポインタとイテレータは独立した概念だから、その差分学習は論理必然じゃない
現に、俺は学部時代に授業でプログラム習ったときは、vectorのような連続領域じゃなくlistのような抽象リストで習ってるし
ポインタはCの授業で、アドレスの抽象として習ってるし、イテレータはデザパタの本で知ったからね
どの学び方がいいかは人それぞれなんだろうけど、独立した概念を一緒だよとか変な方便使うのは間違ってると思うよ >>471
この意見はさすがに論外だわ
ポインタは難しいものでもややこしいものでもないから、ちゃんとした読み物があれば問題なく理解できる
難しいなら後回しにしてもいいならわかるが、最初から教えないというのは学習の機会を奪っているとさえいえる >>443
はげどう
>>444
言語選ぼうよ；；
>>445
イテレータはポインタの概念を引きずってゐる
プログラムの動作を簡明に表すという意味では
配列の構文さえあれば十分なのに、
※ 個人の感想です 老害が多いな
ソフトをやるならアセンブラからとか言いそうな勢い 尤も、C++の配列とか要素型であるクラスの継承とか多態性を表現しきらん欠陥品ではあるのだが
（インターフェースの配列はポインタの配列としてやるしかない；；
それゆえにやっぱC++で入門するなら中身知っとけと、 >>475
あなたに教えを請う人がいれば、あなたが教えたいように教えたらいい >>478
STLはテンプレートライブラリだから、動的なポリモーフィズムにガッツリ対応してないのは当然だし、
そーいうのがほしけりゃ自分で書けばいいだけ >>480
左様動的なポリモーフィズムにガッツリ対応したコンテナクラスのテンプレートを
曲がりなりにもかけるようになってからがC++の入門編
抽象化された上位レイヤーの知識だけあれば詳細は知らなくて良い、というのは
漏れのない抽象化が達成された後のみ通用する話だが
ずんねんながらC++はそうではないし言語の性格上っ今後とも永遠にそうはならない >>471
その有益というrange-based forを説明してくれよ。 >>483
悪いが馬鹿老害は黙っててくれないか。
若い人がせっかく説明したほうが有益だと言ってくれてるのだから。他の人も賛同してくれてる。 >>464
いや、もちろん意識してるだろ。
そう書いたつもりだけど、どこをどう読んだんだ？ >>471
おまえさ、じゃあ配列の添字は何だと思っているわけ？
「どこにある」という情報をもつもの、という点で同じだぞ
だから for(i = first ; i != last; ++i) において first や last や i が
整数であろうがポインタであろうがイテレータであろうが
同じ論理が通用するんだろうがよ
ポインタで範囲外アクセスこくような大馬鹿者が
整数ならそんなことないとでもぬかすのか？ >>472
おまえC++やCよりも前に何かやってただろ
俺だってC++をCより先に憶えたクチで
そんな真似ができたのはアセンブラ使いだったからな
間接の概念をまっさらから憶えるのに
イテレータは無駄に難しいマゾプレーだつってんだ
ポインタわかっててもハンドルで悩むやついるくらいで
それに輪を掛けて++まであるのがイテレータであって >>471
まだ説明してないのか。説明頼むよ。キミが言い出したことなんだよ。 （void*以外の）ポインタ自体も生のアドレス概念からは抽象化されている。
指されるオブジェクトの型やサイズを持っているんだからね。
それをさらに（ある方向に）抽象化したものがイテレータなんであって、そのように段階を追って
抽象化されていくストーリーを語るのは初心者向けにも有意義だと考える。 イテレータに限らないけど抽象化されたものは抽象化されたままで扱わないと抽象化した意味がなくて、
(内部の実装を意識しなきゃならないのなら抽象化の甲斐が無い。)
一方では、その抽象化を作る側になることもあるので抽象化が出来上がるまでは抽象化の内側も知ってなきゃいけない。
つまり、層を積み重ねるたびに抽象化の壁を作っていくってのがプログラムを構成する基本的なやり方だろう。
だから、プリミティブな方から積み重ねながらその抽象化が意味するところを学ぶってのは普通の方法だと思う。
そういう意味で >>493 に賛成。
抽象化の内側を知ってしまった人が抽象化の壁の向こうを忘れて抽象化されたものとしてだけ
扱うってのはそれなりにセンスがいるんじゃないかとも思うんだけど、
C/C++ の背景にあるセマンティクスは良くも悪くも機械の理屈なんで、
どうあがいても高級アセンブラだと割り切って泥臭いポインタの側から学ぶのがいいと私は思うよ。
その泥臭いところを頑張って隠してるのが C++ ってもんなんで、
泥臭いところを知ったら C++ の色んな機能が「あー、こういうの欲しかったわー」ってなってありがたみを感じる。 ストラウストラップが言うにはC++は
低レイヤーにアクセスできる機能とオーバーヘッドが無く使いやすいように隠蔽できる機能を持っている言語というようなことを言っていて
低レイヤーの部分を知らなくていいとは言っていない アセンブラの代替言語なのだから当たり前だ。用途もOSやドライバ、マイコン向けばかりだ。
COBOL、FortranやPerl、C#やJavaの代わりに使う人などいない。
低層を隠蔽する機能などお呼びではない。 いやCOBOLの代わりには使うぞ
Fortranの代わりつーとCな客はいたねえ http://opencv.jp/cookbook/opencv_img.html#image-resize
ここのソースコードをコピペしてコンパイルしようとしたのですが
関数 `cv::Mat::release()' 内:
test.cpp:(.text._ZN2cv3Mat7releaseEv[_ZN2cv3Mat7releaseEv]+0x47): `cv::Mat::deallocate()' に対する定義されていない参照です
collect2: error: ld returned 1 exit status
このようなエラー文が出てしまいます
使っているOSはdebian stretchです
/usr/include/opencv2には必要なファイルはありました
どのようにコンパイルすればいいのでしょうか >>501
すみませんでした
こっちで質問してみます c++に限った話じゃないんだけど参考書
とかだとメソッドの後にフィールドが
書かれてる事が多いようだけど、それが
一般的なの？ ちがう
一般的にはフィールドたるメンバ変数の方が先に来る
学習の都合で、メンバ変数を先に説明した方が、どう考えてもラク
メンバ関数を先に説明すると、入門書を読むレベルの初心者は間違いなく混乱するので、そんな参考書はまず見かけない
そもそもメソッドの中で使う変数は始めに宣言しておかないと使えない
結論としてはあなたが用語の取り違えをしてる……としか レイアウト、というとデータの並び順の意味にとられかねず語弊がある public、protected、privateの順に書いていくと
自然と変数はpublic関数の次に来るわ 普通アクセス修飾子の順じゃなくてフィールド→メソッドの順じゃないの
カプセル化するから変数なんてほとんどprivateだろうし
変数は変数でまとめて書いてもらわないと混乱する ユーザーにとって重要な項目から順に書く
つまり、public→protected→privateで
ユーザーに見せる必要のないprivateは一番下で 変数の宣言と関数の宣言の順序がどうでも良いのは自明
メンバ関数の定義がメンバ関数内で使用するメンバ変数の宣言に先行する場合も実験する限り合法
（規格に具体的にどういう文言で規定してあるのかは知らん
まあ定義時点で不完全な型やら値やらはテンプレートの定義で頻出するから
あんま定義と宣言の順序にこだわらない処理系の作りなのだと納得しておく
しかしなぜかテンプレートの引数でない型の定義（または宣言）と使用には厳格な順序を求められる…
次のコードはビルドが通らない
class Baz {
// struct Bar; // 左のコメントアウトを外したら逝ける
void foo(Bar& b);
struct Bar { int x, y; }
};
多分Cとの互換性のために仕様がﾜｹﾜｶﾒになった例 ルールが存在してwell documentedで、ガバナンスがきいていることが重要
お前らのオレオレ哲学なんかどうでもいい ああそっか、プロトタイプ宣言しなきゃいけないんだっけC++は
C#の脳で考えてたわ >変数の宣言と関数の宣言の順序がどうでも良いのは自明
自明かねぇ
C++11は問題になる例が思いつかないがC++98,03,14はどうでも良くない コンストラクタ実行時のメンバ変数の初期化の実行順が、初期化子の記述順ではなくクラス定義での並び順に従うっていうのがあった気がするけど、新しい規格では変わったんだっけ？ >>516
うそーん、初期化子の記述順＞クラス定義の並び順だと思ってた。
てか、宣言の並び順は無関係？
そら、警察官も道行く江添さんに聞きたくもなるわｗ >>516
微妙な表現以外、特に変わったという話は聞いたことがない
C++03 12.6.2/5
Then, nonstatic data members shall be initialized in the order they were declared in the class definition (again regardless of the order of the mem-initializers).
C++20 draft 15.6.2/(13.3)
Then, non-static data members are initialized in the order they were declared in the class definition (again regardless of the order of the mem-initializers). >C++11は問題になる例が思いつかないがC++98,03,14はどうでも良くない
とか書いてるから何か制約が無くなるような変更があったのかと思って聞いたんでない？ ちな漏れがどうでもよい（どんな順序でも問題ない）と言ったのは
変数の宣言と関数の宣言の順序（どちらを先にするか）だからな
これ豆な C++11でもこれがあったか
struct A {
int m;
decltype(m) /*←mは先に宣言が必要*/ f() { return m; /*←mは後でもいい*/ }
};
C++11で緩和されたのは11章のどっか(忘れた) static メンバ関数と friend 関数の使い分けについて教えてください
どちらも似た機能だと思ってしまうのですが‥ あ～、そんなこと考えたことなかったけど、クラス (メンバ関数) 内部から見たら近いっちゃ近いのかも？
クラスを定義する側じゃなくてそのクラスを使う側の気持ちで考えて。 friend 関数は public で，static メンバ関数は private で，て感じでこの前は書きました
普通はどうするものかをお聞きしたいところです すまんけど自明すぎてどう使い分けるとか説明できない。
使い分け以前にそもそも理解できているか怪しいと思う。 何度も宣伝するようで気が引けますが，前に書いたのは >>158
演算子のオーバーロードに絡むものは基本 friend で，内輪で使うものは private の static メンバ関数で，
くらいの線引きをしています．
書いてみてわかったのは「自明」という感じはしないこと，かな，考えてみれば friend 関数って他の言語にはなさそうです 何で？ operatorはグローバルに出さなくても多重定義候補に挙がるぞ
俺は別の理由でoperatorをグローバルにする傾向があるが >>527
http://codepad.org/8Z3c2obA
ほー，これは不思議だなあ‥
friend をはずすとコンパイルできない
friend をつけてしまうと public に置こうが private に置こうが関係ない，という認識であっていますか？ 何が不思議？
friendを外すとメンバoperator+に過剰な仮引数となりエラー
friendは「メンバではない」のでアクセス指定は無関係
1点だけ気になるのが、friendは当該クラス自体と同じスコープに新しい識別子を導入しないはず・・・
識別子はoperator+で、これのみは某か標準のヘッダで既に宣言されているということか？ >>529
＞operator+に過剰な仮引数となりエラー
つまり operator+ の >>528 とは違うもう一つの呼び出し書式にしないといけないわけですね．
でもこの場合は private に置くとコンパイルできない
http://codepad.org/RLo9fKuI
friend はアクセス制御如何にかかわらず「強引にpublic にする」ように見えますね‥わからない‥ friendなら、その人のプライベートにアクセスできる。それだけの意味。 ある人のfriendなら、その人のプライベートにアクセスできる。 >>531
>>522 をどうかよろしくお願いいたします． >>530
強引にpublic・・・で憶えやすいならそれでいいんじゃね？
ちな俺の憶え方はメンバでないものをどうやってprivateにするんだ、だ あるクラスX内部のstaticでpublicな関数fは、Xのインスタンスの存在に関係なくX::fという名前でアクセスできる。
あるクラスX内部のfriendな関数gは、X内部のプライベートなメンバーm_aにアクセスできる。 >>534
確かに friend 関数は「メンバーじゃない」ですか‥main() と同じような普通の関数なわけですね‥ friendは他のクラスのメンバかも知れない
そういうときも俺の憶え方なら動揺せずに済む メンバ関数より、メンバでもfriendでもない関数を使おう
って誰かが言ってた 欲しい機能がメンバでない関数で使えないとなれば
それはクラスの設計ミスないしはダサい設計だかんな
クラックできちまうのと違う提供すべき機能の欠落 >>530
(1) friendが無い場合
「z = x + y;」に出くわしたコンパイラは
1. インスタンスxに対しするC::operator+(y)（1引数）の呼び出し
2. グローバルな関数C operator+(C const& a, C const& b)（およびその亜種）の呼び出し
のあてはめを順次試みるがどちらの関数も宣言が存在しないからあてはまるものが無くエラーになる
(2) friendがある場合
friendがつくことでoperator+()はCのメンバ関数ではなく、グローバルな関数として宣言されたことになる
このとき「z = x + y;」に出くわしたコンパイラは、上の1、2の順で当てはめを試み、
グローバルな関数C operator+(C const& a, C const& b)の呼び出しと解釈する。
本来この関数はクラスCのprivateメンバにアクセスできないが、friendの力でそれができ、めでたくビルドできて動く。
細かい話は規格の人がフォローして☆ﾎｽｲ >(2) friendがある場合
最も近い(内側の)名前空間の関数になる(11.3/6-7)
friend関数がメンバーではないことがC++14に明記されていなかったようで、C++17ドラフトに追記された模様(N4659 12.2/2)
＜おまけ＞
宣言の場所がクラス内という事情により、リンカーはともかくコンパイラーから存在が見えにくい関数となる
この関数を使うには
・名前空間スコープで明示的に宣言し直す
C operator+(C const& a, C const& b);
・ADL(argument dependent lookup)でクラススコープの検索を発動させる
>>541でoperator+が呼び出せているのはADLによる つまりクラスの外で定義された関数をイメージすればいい
struct A { friend void operator+(A,A) {/**/} };
↓
struct A { friend void operator+(A,A); };
void operator+(A,A) { /**/ } // ただしADLが無いと見えない ドット拡張とかすればいいのにね
int static_value.fanction() = 0; // function専用
vid functionx.function(char*p){} // function専用
ファイル内スコープなんて今時ほとんど使わないから無視するか識別子重なったら同一と見做すかして
ついでにドット型はファイル内の前方参照も無くし宣言を省けるようにするとかさ >>541
＞friendがつくことでoperator+()はCのメンバ関数ではなく、グローバルな関数として宣言された
なるほど，そんなところだろうと >>528 で考えておりました．
件のライブラリもどきでは，operatorX のみクラス外に公開できればいいので，friend 関数で公開しておりました
その他は(基本的に）（公開すらしたくなかったため）static メンバ関数でのprivate 宣言となりました．
そうしたいようにそう書けばいいのですが今一つ統一感を見えてなかったかもしれません．
>>540
すみません >>522
static関数とfriendは全然違うし似てるとこなんてない >>546
みなさんこれが典型的ななんの役にも立たない回答の好例です >>546
static 関数をpublic に置くか，friend 関数にするかの判断がよくわからないのです．
なにか指針があればうれしいのですが 呼ぶときにクラス名を書きたいか書きたくないかで判断
コンパイルした結果には大した差はない クラスの外の関数とオーバーロードさせたければfriend
https://ideone.com/Bfcfbq staticはメンバを触れない。friendは触れる。
それくらいしか違いないけどなぁ。
俺、フレンド関数はほとんど書いたことない。 違ったっけ。
staticってthisもってないんじゃなかった？ https://ideone.com/qDEfdG
勘違いやったわ。ごめんなさい。
一個勉強になった。 メンバ変数をprotectedにする人ってなんなの？露出狂なの？ そういう人が日本に一人二人いるかも知れないけど、気にするだけ損だよ 継承しても触れるようにするためだけど。継承自体がほとんどない。 クラス内に定義されたstatic関数は、そのクラスのオブジェクトが存在しなくても使える関数ってのが本来の意味。
動的なオブジェクト状態には依存せず、静的なクラス構造のみに依存するからstaticね。
対してfriendは、自分をさらけ出す人を指定するめのもの。
stream のから呼び出されるオペレーターを定義する時には、既に完成している stream （だけ）に対して自オペレーターをさらけ出してしまうのがいろいろな意味で最も効率的。
以上から、friend関数は、静的ポリモーフィズムを関数レベルでお手軽に実現したいときに使うと思っている。 表層的に言うと
staticはグローバル関数をクラススコープにして、かつアクセス制御も効くようにしたもの
friendは>>531の通り
ただそれだけのこと >>561
なんで素っ裸でコートきてんの？露出狂なの？って聞かれて
コート脱いだらちんこ見えるようにする為だよって答えてんのと同じだぞ
まったく…露出狂は社会に出ちゃいけない存在なんだから、もう二度とプログラミングするんじゃないぞ >>565
うまい事言うなあ
friendは「なんで俺にだけ素っ裸見せんの？露出狂なの？」と聞かれて
「だってお前友達じゃん。だからお前にだけ俺の裸見せてやんよ」と言ってるわけだしな」 あれだろ
日本語のガールフレンドと
英語のgirl friendじゃ意味が違うというアレ >>565
あんたに決められる筋合いはねー。災いあれ。 friendはクラスの役割を適当に分担しながら実装の隠蔽を図るのにはまあ妥当な仕組みだろうな 継承をほとんど使わないってどんな分野だろう
俺んとこではポートを叩くときのプロトコルが
似ているようで少しずつ違うなんての普通にあるし 複数のクラスのfriendが可能
staticは1個だけ >>567
親しき仲にも礼儀あり。
アクセサぐらい用意するよね。 >>565
＞もう二度とプログラミングするんじゃないぞ
わかりました，もう止めます‥ C++のfriendが現実世界の友達と違うのは、最初に決めたやつ以外にfriendを増やすことは全く好ましくない、
という点だろう >>569
publicにしてあるほうが、まだかわいげがあるよ
もう、これからはすべてpublicにしなさい friendじゃなくfamilyが良かった気がする >>578
#define family friend
で行ける？ printf("We are the World."); ←わかる
cout << "We are the World" <<endl; ←わからない
printfは「関数」だからわかります。
coutの<<はシフト？よくわからないです。
なぜC++はこんな文字の出力のさせ方にしたんでしょうか？関数じゃダメだったんですか？ >>583
<<は演算子オーバーロードだけどcoutなんて使う必要ないよprintfでOK >>583
それはまさにC++の作者（以下、禿）が
彼の著書でアピールしていたことだ
coutとは何か？ <<とは何か？
記号と意味はどこでどのように関連付いているのか
意味は関数で表記することにしよう
<<の意味を表記する関数の関数名をoperator<<としよう
プログラム言語の命令とデータは動詞と目的語だ
動詞は関数と1対1対応でよいが目的語の定義は動詞の蓄積だ
・・・てな具合 >>583
シフト演算子を全く別の意味に使う
ひどい設計だと思う cout.<<("We are the World"). <<(endl);
があれば少しはマシだったかね。 >>583
演算子のオーバーロードのよいお題ということで無理矢理ねじこんだんじゃないかな using namespace std;
double value = 1.23;
cout << "value = " << value << endl; >>587
お約束を破っているが流し込んでる感が出ているので芸術点高い +-*/と違って<< がシフト演算子なんて決まってないから「本来と違う」なんて意味なさない vectorオブジェクトが破棄されるとき、要素の解放順は要素順であることは保証されていますか？ >>593
いや決まってる
ライブラリを抜きにした純粋な言語ではシフトの意味しかない
元の言語のC言語も同じ
* の方がいろいろな意味で使われている >>596
べつにc/c++の話じゃなく、一般に<<をIOの意味で使ってもなんとも思わんでしょ
+-*/はさすがに刷り込まれている 数学の演算子とプログラム言語の演算子のことじゃないかな。
+ - は数学とプログラム言語で一致
* / は数学と違うけど文字セットに乗除の記号がないし妥当な代用
<< をシフトに使うのはC系プログラム言語の独特の使い方
だったら << が出力になってもええじゃないか、という話。 向きは違うけどbashみたいなイメージだと思ってた 数学では、比較してずっと小さい、ずっと大きいという意味で<<、>>を使うことがあるみたいだが。 >>595
ありがとうございます
保証するにはどうすればいいですか？
ググってstackoverflowとか見たんですが、できないという人もいたり
clear()を使えという人もいてよくわかりません 禿が言い出した<<と
おまいらが言い出す<<では
悪いが社会への影響度がまるで違う
大勢のPGが<<はI/Oだと素直に従うかどうかでだ
新しい言語に旧来の言語と似た記号が出てきたからって
同じ意味でなければならないという法はどこにもない ローテート命令が演算子化されてないのは何故なんだぜ？ 自己解決しました
>>604
必要な場面がありまして printfをモダンにアレンジして新規格作ればいいのに。 >>605
それな
俺も時々欲しくなるんだけど
キャリーを含む/含まないとかCHAR_BITの違いとかで
移植性が確保しにくそうだよな
記号を何にするかなんて後から決めりゃいいことだ >>605
ローテートなんて頻繁に使うものじゃないから
ビットが立ってる数を数えるとか、
ビットが立ってる位置を調べるとか、
バイト単位の並び替えとか、
小数から整数へ四捨五入とか、
他にいくらでも足したいものはある 誰がこんなクソ言語つくったんだよ
作者はたぶんバチが当たって禿げてるはず だいたい最初にアスタリスクを乗算演算子にした奴は誰だよ。 operator:=とかoperator!?とか定義できるようにしてくれたら
お前らが度肝を抜くような使い方して見せるのに、残念でならない。 operator?:ならマジで提案してみそ
あわよくば大手柄だぞ >>613
コンパイルエラーになろうが、ソース書くだけなら現状でもできるだろうから、度肝を抜いてくださいな。 >>618
BASICのように=の意味が文脈で変わるべきだと？ いやっすいやっす！代入に２タイプも使うのいやっす！ >>623
勝手に変えたらどう？
数学はコンパイル不要だから、最初に定義さえすればお前の使いたい記号を好きなだけ使えるよ 自民党の恐怖の言論弾圧が迫る！
売国安倍は憲法改正で国民主権と基本的人権
を奪うつもりだ。 ← 民主主義の崩壊
http://www.data-max.co.jp/280113_ymh_02/
↑ マスコミは 9条しか報道しないが 自民案
の真の恐さは21条など言論の自由を奪うこと
自民案が通ると 政府批判しただけで逮捕されるぞ！
https://www.youtube.com/watch?v=h9x2n5CKhn8
上のビデオで 自民党は 日本人に基本的人権
は必要ないと 異常なことを平気で言う。
http://xn--nyqy26a13k.jp/archives/31687
↑ 都民ファーストも安倍と同じく 憲法改正で 人権
無視の大日本帝国憲法に戻すつもりだから
絶対に投票してはだめだ。 民主主義が崩壊する
http://blog.goo.ne.jp/ngc2497/e/8899f65988fe0f35496934dc972e2489
↑ ネトウヨ= 安倍サポーター工作員はネットで国民を騙す。
https://dot.asahi.com/aera/2016071100108.html?page=3
http://blog.goo.ne.jp/kimito39/e/c0dd73d58121b6446cf4165c96ebb674
↑ 安倍自民を操るカルト右翼「日本会議」は国民主権否定。
国民投票や選挙では自民党、維新、小池新党に絶対に入れるな。 2003年8月の第1回から2007年3月の第6回までいずれも中国北京で計9次の会合が行なわれた
話し合いで解決しなかった
原爆、弾道ミサイルの開発にカネ、時間を与えてしまった
軍事力でつぶすしかないのに、まだこんなこといってる
,,-―--、
|:::::::::::::;;;ﾉ ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|::::::::::( 」 ＜ 対話で解決しよう
ﾉﾉﾉ ヽ_l ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
,,-┴―┴- 、 ∩_
／,|┌-[]─┐| ＼ ( ﾉ
/ ヽ| | バ | '、／＼ / /
/ `./| | カ | |＼ /
＼ ヽ| lゝ | | ＼__/
＼ | ￣￣￣ |
⊂|＿＿＿＿__|
|l＿l i l＿l |
| ┬ >>623
数学は、最初に定義さえすれば自由にしていいんだよ。 プログラミング勉強し始めた初心者ですが
手詰まりになったので質問させてください
ttp://judge.u-aizu.ac.jp/onlinejudge/description.jsp?id=ALDS1_3_C&lang=jp
この問題をやっていますが、以下のコードで「Time Limit Exceeded」となってしまいます
他の正解者のコード見てもやってることは同じな気がするのですが
なにがいけないのでしょうか？
C++14コード
ttp://codepad.org/2Yxb33Ab 追記です
Case#8までは「Accepted」でOKなんですが
Case#9が「Time Limit Exceeded」でした
Case#9は入力が2000000行もあるっぽいです
でも他の人とやってること自体は同じなんだから
このコードでできるはずと思い込んでしまって
何が悪いのかさっぱり検討つきません。。。 Listそのものがそんなに早くないとかかなぁ。
デリートはO(1)で終わるけど、ポインタの付け替えとかあるから、雑に遅いカモね。
最近のコンピュータだと配列の方が早かったりする。 もしかしたら、sstringしてるのが重いかもなぁ。
cinで取れるのに何でssteamしてるのかよくわからん。 >>630
>>632-639
ありがとうございます！
まさに>>635だったみたいです
1行ごとに入力を読み込みたいからsstream使ってたのですが
そのせいでwhileループで毎回sstreamとstringの変数を定義しているせいでした
cinとstringだけで入力を読み込むようにして
変数の定義をループの外にしたらようやく自分のコードで通りました
sstream使わなくてもstring変数の定義をループ内に書いたままにしてたら
ずっと通らなくてそれで何時間も四苦八苦してようやくすっきりしました
変数の定義って思いの外処理時間がかかるんだなあとしみじみ実感しました
わざわざコーディングまでしてくださってありがとうございました > 変数の定義って思いの外処理時間がかかるんだなあとしみじみ実感しました
ものによる
テキトーこくな >>642
> ものによる
string だろ
話の流れも読めないのか？
> テキトーこくな
実際にやってるだろうに何を言ってるんだよ
いちゃもんつけたいだけか？ 変数の定義って処理なのか？
stringが遅いのはどの言語でも同じ。ヒープに確保してるから。
Cの特権は固定長ならスタックに文字配列を確保できること。 >>644
COBOLとかFORTRANヒープの概念があるとは デフォルトだとcinがstdioと同期取ってやたら遅かったりもする罠 コンストラクタがやけに重いクラスとかあるんだよ、標準でも。 C++のstream関連は全て糞
operator<<()の多重定義で自作クラスのフォーマット文字列化（stringizing）ができる、というのがちょっと嬉しかったけど
しょせんコードの見かけだけの話やし、実行速度は速いし改造もしにくい、
（printf()ならvprintf()を使って関数1個書けば良いところをstd::streambufの派生クラスを作る羽目に、、
行単位の排他とかの作り方を比べたらﾜｶﾙ
だいたい一般に1つのクラスに対して一般に
(1) 人間が読むためのフォーマット文字列化
(2) ストレージか何かへのシリアライズ
(3) ストレージか何かからのデシリアライズ
の3つの要求が生じるのに対してoperator<<()とoperator>>()の多重定義の2個では数が足りない
だったら上記3メソッドのインターフェースを全部Cのstdioベースで実装して済ませるわ；
とにかくC++の中にあってstreamはパフォーマンスよりもコードの見かけに拘ってみました感が異端 >>644
> 変数の定義って処理なのか？
コンストラクタって知ってるか？
> stringが遅いのはどの言語でも同じ。ヒープに確保してるから。
そもそもstring型はすべての言語にないし文字列型と言う意味ならFORTRAN77のように固定領域にとる言語もある
>>645
モダンなバージョンなら普通にあるでしょ
Fortran ⇒ Allocate 文
Cobol もオブジェクト指向になってるぐらいだからあると思う 相談室ということで
C++でディープラーニングのライブラリといったらTensor Flowとtiny dnn以外にあります？ >>648
おちつけ。
> 実行速度は速いし改造もしにくい、
> だいたい一般に1つのクラスに対して一般に >>649
つまりインスタンス生成を「変数の定義」って言ってるのか。分りにくいな。 >>651
ありがとうございます
調べてまいります でけた！
ttp://judge.u-aizu.ac.jp/onlinejudge/review.jsp?rid=2524752#1
>>654
ｽﾏﾝorz >>648
モダンな言語の多くはprintfライクだし、javaも結局追加された。
printfライクのほうが効率的なことは経験的にわかってるのだからstreamにイマドキのformat関数を追加してくれればいいのに。 もっと50 msばかり速くすた、
ttp://judge.u-aizu.ac.jp/onlinejudge/review.jsp?rid=2526468#1 さらに1桁速くしたわふーん（0.65 sec → 0.06 sec）
ttp://judge.u-aizu.ac.jp/onlinejudge/review.jsp?rid=2526595#1
メモリ消費量も1/4未満になた、（34520 KB → 7432 KB） と思ったらイデオンGCCで動かねーでやんの。
https://ideone.com/oqpQ8i
VC2017では動く魔法のコード。 うほ。素晴らしい。
が、今度はVCで動かなくなった。
なんじゃそれ。 なんか、VCもGCCも半分くらいずつ間違えてる予感。
Setだけだとストレージがないからなんかバグの予感するし。
ストレージ持たせようとすると修飾が間違ってるって言われてる感じがする。
なんだこれ。 https://ideone.com/mqTzb8
これで手打ち。
よくわからん回り方されたなぁ。
とほほほ・・・。 VC++のバグ…ではなくいつもの標準非準拠の独自仕様の気はする
https://ideone.com/10vEzK >>673
およ、折衷案できそうか？
自分はVC動けばいいんだけど、
コード公開するときに動かないと間抜けっぽいから良対応しようと一応やってる。
visualデバッガが便利すぎてVCやめるの大変。 完全な解決策も規格の規定も知っているが、
再現する最小限のコードにしてから他人に見せる知能も持ち合わせていない者には時間の無駄 非修飾名の探索の問題だから発想を変えて明示的修飾で回避すればいいって話？
https://ideone.com/YTnOF2 templateの使い方を完全に勘違いしてやがる。 折衷案色々あるなぁ、感心する。
>>676
別に個人のコードでどこかに迷惑かけてるわけじゃないし、この程度のコードも読めない方が問題。
それに高慢なお方は最初から相手にしてない。マウントしてほしくてやってるんじゃないんだよ。 https://ideone.com/Ofcm9I
>>677を採用。これで解決しました。
明示の仕方がいまいちよくわかってなかった。
大変ありがとうございました。 auto で受けるとおかしげなことになるんちゃう？ 馬鹿に触らせるなテンプレートって昔から言うしな。
フレームワークのテンプレートライブラリ提供する側だけが使っていいんだよ。 テンプレートはSTLやboostのまねをしていれば下手なことにはならないはずだが 何故そういうコードになっているかを理解せずに猿真似して意味があるかどうかはわからんけど
autoで受けるとおかしなことになるのは、キャストや代入で望む結果を得る方法（expression templateなど）全部そう
暗黙のキャストでなく関数呼び出しを強制すればautoでも大丈夫だけど > 馬鹿に触らせるなテンプレートって昔から言うしな。
自分が触りたくないのはわかったから >>682
コピコン切ってあるから大丈夫だと思う。あとは推論性能。 >>688
あ、なるほど、状況を勘違いしてた。
C++17 からは RVO が使える場合は常に RVO で処理する (従来は「してもよい」というオプショナルな動作) ことと、
そのときはコピー (ムーブ) コンストラクタが無くても良いというルールが念頭にあったのだけれど、
この場合は RVO は関係なかった。 スマソ >C++17 からは RVO が使える場合は常に RVO で処理する
ほうほう、それは本当ですか "clacla.h"
class Clacla {
void func1();
void func2();
void func3();
};
"clacla.cpp" //実装部
クラスClacla くくり { <-ここ
void func1() { printf( "1" ); }
void func2() { printf( "2" ); }
void func3() { printf( "3" ); }
};
のように関数の実装時にClacla::を省略する方法ってあるでしょうか？ >>694
最適化が有効なら C++17 であろうがなかろうが clang なら RVO が効くはずだけど、 u.p の値は null になっちゃうな。
RVO がどうこうじゃなくて this の挙動に関するなんか変なルールが適用されてるとかかも？ >>696
クラス内部にインライン関数を埋め込む方法しかない。 >>697
いやだからISO/IEC DIS 14882:2017 15.2/p3の規定により常にRVOが働くわけではないのではないかと申しているのですよ
ついでにu.pがnullptrになることはない 右辺値参照の暗黙適用は例外の処理で不都合があるよね
元の値をTmpにコピっといて例外発生で書き戻すにしても
関数A処理内で呼び出した関数Bからの例外をAのユーザコードでは完スルーなのに
コンパイラコードではコッソリ捕まえて書き戻す必要が有る
そんときロックでも掛かってたらどーすんのよと
呼び出し繋がりを横断的に管理要するとんでもないコスト増なんじゃね？ Tmpのアドレスを関数B（およびその先の関数）が知る可能性がコンパイラから見て排除できない限り
関数Aから関数Bを呼び出す前にTmpは元の値の完コピーにならざるおえないのでは…
（そうでなければ副作用のある関数を安全にコンパイルできない＆安心して書けない
さらにロックに入るときと出るときは上と同じ理由で結果的に完コピーになる上に、
まともなOSならメモリバリアまで手当てしてくれるんじゃ… つまり右辺値参照の暗黙適用が効力を持つのはｽｹﾞｰ広範にインライン展開されるような場合
（当然いかなるOSのAPIやシステムコール類の呼び出しも含まない
「だけ」
であって、通常のプログラマーにはあんまありがたみがはっきりしない仕様
※ 個人の感想です コンパイラに頼らないで、素直にパラメーターの参照にしよう >>700
意図するところをあらためて説明すると、
最適化オプションを有効にする (RVO が効くはず) と実際に null になるんだから
clang があてにならないのじゃない？ という話。 いや noexcept 付きを呼ぶ場合も有難味あると思うよ
C++は const祭りに noexcept祭り追加でござる
特殊化も爆発 >>706
なるほど理解した
C++11の頃に輝いたclangはその後、規格的にはG++にも劣るゴミなのでそのへんは致し方ない tcp/ipの勉強のためにC＋＋で何か作れば勉強になるかな？って思ってるのだけど
こういうものを作れば勉強になるよってものある？？
パケットの動きだったり階層の考え方だったりを学びたい >>710
TCP/IPの勉強ならWireSharkの使い方覚えた方が早いかも
その上のプロトコルレベルなら勉強したいプロトコルの簡単なクライアントから始めればいいと思う
ちなみに俺はNetNewsに流れるむふふ画像を取り込みたかったのでnntpのクライアントをperlで組んで勉強した >>711
プロトコルレベルの勉強をしたい
そうなるとhttpサーバを立てることになるのかな？
そういう場合は簡単なhttpサーバとクライアントを作成すれば良いのかね？
それで通信しあってwiresharkで中身を見てtcpだったりhttpだったりを見るべき？ おれは一昔前、深夜ボリュームでかくする姉貴のPCが煩くてTCP通信でマスターボリューム弄るサーバー＆クライアント作ってコッソリ仕込んでコントロールしてたな。
まぁ、やってやるぞというモチベーションは大事だとおもうよ。
ガンバってね。 >>713
姉貴のパソコンにサーバプログラム常駐させる
そいつがポートXXXで待ち構える
同じ家なのでネットワーク帯は同じで
自分のpcからポートXXXにメッセージ送信する
姉貴のサーバプログラムが受け取ってボリューム下げる処理をする
こんなことしてたってことかね？ >>715
まぁ大体そんな感じなんだが、急に音量小さくすると即効でばれるので、まず、姉貴PCの音量を取得するのが第一だな。
そこからスライダーでボリューム下げていった値をサーバーに順次送信しサーバープログラムがその値に応じて音量を徐々にフェードコントロールするといった具合だな。 >>716が>>715の三人きょうだいの次女である可能性が否定できない >>716
いつも音量小さくなってたのはあんたのせいだったのね？？
ってことはそれって通信はhttp？ >>718 http関係ない
ボリュームと改行の平文を繰り返し送るだけの超簡易仕様
だれでも作れる >>719
相互にsend recvしてるだけってことかな >>712
サーバーよりクライアントの方が簡単だからサーバーは適当な奴持ってきて簡単なクライアントを作るところから始めればいいと思う >>721
IISサーバとかってことかな？
あの辺の使い方も基本は同じよね？
ポート指定して使うみたいな >>722
> IISサーバとかってことかな？
環境ならWindows IISが簡単だろうね
ネットでググれば情報たくさんあるし そもそも、TCP/IPの練習にC++は妥当なのか？ >>724
CとC++しか言語知らんのや...
IISサーバーと通信できない
これのポートとかどう設定するんや... >>725
以前ネットワークプログラム勉強するのにこのサイト利用させてもらった
わかりやすいと思う
http://x68000.q-e-d.net/~68user/net/ 初歩の初歩の初歩の質問なんだけど
あるPCにポートXXを口とするサーバソフトを同時に二つ立てることはできないよね？
1つめはXXを使うとしてその後にたてられた2つめはどうなる？
(スレチっぽくなってますがよろしくです...) 出来ます
サーバー側はリクエストに応じて複数のプロセスを起動し、
同じポート番号を使って複数のプロセスが受け答えします
各プロセスはそれぞれで生成したソケットを使ってクライアントとやり取りします >>730
それってプログラム内でforkして子プロセスを作る場合の話です？
サーバソフトAとサーバソフトBの両立ができたとすると
ポートXX使用します！ってのはどこでどちらを使うと判断するのでしょうか... 特定ポートでlistenするプロセスは一つだけです。
複数のプロセスで共用は出来ません。 >>729
LANポートが複数あればできるし、LANポートがひとつしかなくてもIPアドレスを複数割り当てられるなら可能 >>733
ああ言えばこういうの典型
どうでもいいけどC++と関係ないクソ話もうヤメロよカスども C++98ではできない
C++11以後できるようになった
だろ、通信は本質的にマルチタスクだ 規格外のライブラリならほぼ何でもありといえばありだけどさ。
ライブラリ自信はまだ策定中でしょ。 bind()する時のローカルのIPアドレスを別々にすれば同一ポートで別々のサーバプログラムって動かないの？ >>741
だから動くってば
ユニークである必要があるのはIPアドレス:ポート番号の組み合わせだから
>>730
＞各プロセスはそれぞれで生成したソケットを使って
まさかその生成されたソケットがサーバーと同じポート番号を持つとか思ってないよな？
いずれにせよこんなのはネットワーク初心者の話題であってC++とは何も関係ない >>737
それが間違ってるって話
>>741が言うようにローカルアドレスを指定すれば同じPCで同じポートを使用するサーバーを複数立てられる 自己訂正
＞まさかその生成されたソケットがサーバーと同じポート番号を持つとか思ってないよな？
あはは、これは俺の勘違いだったわ
acceptで返されるソケットはlistenポートと同じポート番号を持っている 質問です。
{ 10/*%*/ } = { a,b,c };
というのは、
a = 10%
b = 10%
c = 10%
なのでしょうか？それとも、
a+b+c = 10%
なのでしょうか？ C++を習得するのに莫大な時間を費やしました。
C++のプロフェッショナルなプログラマーになりたかった。
なのに、ハード系の知識が無いと言う理由で、もらう仕事はVB.NET、C#.NET系ばかりでした。 質問を書くのを忘れやんした。
C++の仕事ってハード系、通信系、制御系以外、通常業務のシステム開発はないんでしょうか？ ポート重複で同じアドレスでBananaサーバーみたいなラックマウントサーバーの仕組みってあれは一つのサーバーがlistenで待って接続してきたクライアントの処理を複数の子サーバーに割り振っているだけなのか？ struct unko { unko()=delete; };
int main() { unko u{}; }
何故コンパイルが通るのかを理解するのに半日かかった
やはりこの言語はクソ >>746
他人から降って湧いてくることしか期待してないからそうなる
自分がやりたいことは自分で始めろ >>747
C++はC#とかでできないことがあるときに仕方なく使うイメージがある >>749
あれ
何で動くんだ？
plain old dataあたりの話が噛んでる？ C#の方が楽なところが特に無いのでC#という選択肢が無い >>752
PODがかかわってる部分はあるけど基本として理解しておくべきことは
=default,=delete指定はコンストラクタの宣言でも定義でもない
ということ
つまり>>749の文脈では
struct unko { unko()=delete; };
int main() { unko u{}; }
は
struct unko {};
int main() { unko u{}; }
と等価でありuはaggregate初期化されコンストラクタは呼ばれないからエラーにならない
(unko();みたいにはっきりとデフォルトコンストラクタが呼ばれる状況ならエラーになる) >>752
規格によると unko u{}; は
8.5/p17『If the initializer is a (non-parenthesized) braced-init-list, the object or reference is list-initialized』によりリスト初期化される
リスト初期化は8.5.4/p3『If T is an aggregate, aggregate initialization is performed』
に該当するのでコンストラクターが呼ばれずにaggregate初期化される。
なおaggregateの定義は8.5.1/p1により『array or a class (Clause 9) with no user-provided constructors (12.1), no (略)』
ここで8.4.1/p1により「=delete」は関数本体だが、
8.4.2/p5によりuser providedではないと見なされている(たぶん) >>748
パケットレベルで振り分けたり、プロキシとして動作したり色々
ロードバランサ 仕組み
とかでググるがよろし
あとそこまで行くと完全にスレチなので
ネットワーク
http://mevius.2ch.net/hack/
とかに行っとくれ >>747
20年前は普通にあった、ていうかそれしか方法がなかったが
今はもっと楽な方法があるのでほぼ無くなった
僅かな例外はパフォーマンスを求めるようなプログラムを作る場合だが
それでもライブラリなどの表から見えない部分の作成に限られる 各添字が 1 から X まで動く多次元配列を一次元で
A[i + X*j + X*X*k]
のように表しているのですが、この多次元配列の各添字を入れ替える操作を頻繁に行うので、関数にしたいです。
どのようにするのが良いでしょうか。
たとえば
f(A, B, 2, 3, 1);
のように引数をとって B という配列に
B[j + X*k + X*X*i] = A[i + X*j + X*X*k]
と要素を入れたいです。
「2, 3, 1」を関数の中で解釈する方法も分からなくて困っています。 >>760
その例だと A[X][X][X] の３次元相当だけど３次元限定でいいの？ >>760
こういう解釈でいいかな？
template <typename T, std::size_t X>
void fillA2B(T (&A)[X*X*X], T (&B)[X*X*X], int ax1, int ax2, int ax3)
{
int i, j, k;
int& ii = (ax1==1)? i: ( (ax1==2)? j: k );
int& jj = (ax2==1)? i: ( (ax2==2)? j: k );
int& kk = (ax3==1)? i: ( (ax3==2)? j: k );
for ( i = 0 ; i < X ; ++i )
for ( j = 0 ; j < X ; ++j )
for ( k = 0 ; k < X ; ++k )
B[ii + X * jj + X * X * kk] = A[i + X * j + X * X * k];
}
int main()
{
const int N = 2;
int A[N*N*N], B[N*N*N];
int n{0};
for ( int a = 0 ; a < N*N*N; ++a )
A[a] = n++;
fillA2B<int, N>(A, B, 1, 2, 3);
fillA2B<int, N>(A, B, 2, 3, 1);
fillA2B<int, N>(A, B, 3, 1, 2);
return 0;
} 左辺が j, k ,i 右辺が i, j, k のようだが ……素直に3次元の配列にすりゃあいいんじゃねえのかなコレ
どーーーしても1次元にしなきゃいけない重大な理由が背後に控えてんのかな？ B[ii][jj][kk] = A[i][j][k];
でも通るな >>761
もちろん任意の次元を一度に扱えたら最高です。
ゆくゆくは各添字の次元を変えることも考えています。
>>762>>765
すみません。
全要素を並び替えたいです。
>>766
カラムメジャー、ロウメジャーを任意にしたいという背景があります。
また、各添字の次元が本当は任意であるということもあります。
>>763
ありがとうございます。
確かにこれで>>760はできそうです。
パーミュテーションの実装の仕方が分かりました。
原理的にはこれで任意の添字の数、次元に対応できる (それぞれ関数を作る必要はある) と思うのですが、もっとアカデミックな方法ともあるのでしょうか？ >>769
アカデミックは知らんが一般化するなら
B[ i*bi[0] + j*bi[1] + k*bi[2] + ... ]
と各次元ごとの係数を変数にして設定だな
>>760のたとえばでは bi[0] = X*X, bi[1] = 1, bi[2] = X
あとはインターフェイスにあわせてヘルパ処理を用意すればいい
f(... int x, int y, int z)
int bi[3];
bi[x - 1] = 1;
bi[y - 1] = X;
bi[z - 1] = X*X; >>770
ありがとうございます。
あとは任意個数の引数を取れるようにすれば添字がいくつあっても、各添字がどのように走っても一つの関数で対応できますね。
勉強になりました。 任意個数の引数って、まさか省略記号と可変個数実引数では・・・
と思ったらモロじゃねえか おいおい
このスレ的にはinitializer_listやtemplate parameter packだろ >>773
template parameter pack って variadic template と同じもの？
後者の呼び方には馴染んでるんだけど。 >>773
ほっといたっていずれ覚えるだろうに何故押し付けるのか >>776
より良い代替案があるんだったらそっちに誘導すべきだろう。
実際使うべきじゃないし。 >>776
このスレ的にはって書いてあるのが読めてないのか
自分が苦手なものに触れられたくないのか
どっちだ？ >>779
最近お前みたいなニワカが増えてうんざりするわ
というかCの可変長引数がどこに出てきた？ つかぬことを伺いますが、
あるクラス内で定義した構造体を同クラス内でstatic constメンバとして宣言し、
外部で定義しようとしたところ、「～との互換性がありません」と出て上手く行きません
どうすればよいのでしょうか
～ヘッダ内
class Hage{
public:
struct A{
int a;
int b;
};
static const struct A M;
}
～ソース内
#include "ヘッダ"
const struct A Hage::M; //不正 const struct Hage::A Hage::M; >>781
少なくとも Hoge::A としなけりゃダメなんじゃないか
>>771を読んでもCの可変長引数とは決めつけられなかった うわあ何でこんな初歩的なことに躓いていたんだアホらしい
>>783-784サンクス ###HUM###
000-K,AZ,0,1,
001-KI,L,I.T,DEF,11.2,TE,F,0.12235,
002-EM,OBLA,7##END >>780
うわーおまえ、それ人に聞かなきゃ判んねえの？
省略記号は右端という初歩の初歩でミスりながら
ドヤってる笑い地獄が２日前あったんだが
突っ込めなきゃせっかくボケた芸人も泣いてるだろうな >>773の「モロじゃねえか」がどっから出てきてるのか謎だ 多分Cの可変長引数なら右端以外にも書けると思ってんじゃないかな こんなイメージかな？
#define X (100)
#define f(a,b,c,d,e) ((b)[(c)+X*(d)+X*X*(e)] = (a)[(e)+X*(c)+X*X*(d)]) >const struct A Hage::M; //不正
初歩的でなく相当に高度な気がしてならない
規格の3.4.1/p7,p8,p14あたりを頭に入れていないといけない
「class NS::C;」のように何でも「::」を付ければ良いと言うわけでもないので だってグローバルスコープにも struct A; が存在したらどうなるか？
って考えればすぐわかりそうなモノじゃんね グローバルが優先される所と、グローバルよりクラスや名前空間が優先される所が入り乱れたこの言語で
どちらが優先なのかを正確に覚えてるのはかなりの変人である可能性が高い
https://ideone.com/RZTBk7 >>795
その例ではいったんA::の中に入っているから B はA::B になるけど
>>781 のはそうじゃないからな。 >>788
おーいバカ、省略記号の位置の件はわかったか？
まさか789なみの重度池沼じゃねえよな >>771は>>770を参考にして新たに考えようとしてるじゃないか。
それを>>770のやり方でまんま行こうとしている、と解釈するのは悪意があるぞ。 >>800
お前まだ分からんのか・・・
>>770のどこが大ボケなんだよ
添え字演算子の中で二項演算子の後に省略記号書いて再帰的に計算させたり
パラメータパック（またはそれを含む式）も無しに引数の左端にいきなり省略記号書いたり
なんてのはCでもC++でも出来ないの
お前みたいにCの可変長引数もvariadic templateも分かってるつもりなら
>>770を見た瞬間にこれは文面上の省略であって動くコードではないと一瞬でわかるはずなんだよ
質問でもないのにageまくるわ自分も初心者のくせして同じ初心者（あるいはそれ以上）を聞きかじりの知識でバカにしようとするわ
憂さ晴らしにしか利用しないのなら出ていけ 文面上の省略だっておｗ
大ボケに苦しい言い訳を上塗りして
アフォから超アフォに進化したなあ 驚いた、ム板にIP信者がいるとはね
嘆かわしい限りだ >>800
だったら>>771をターゲットにすればよかったんだよ
お前は>>770をも貶し続けていると見なされていたんだよ 大ボケ＋言い訳＋IP信者＋錯乱
この安定したアフォぶりは、どう見ても同一人物だなｗ %%%3%%%
000-DOK<NAZE-0.8112162>
001-3800%\73NMB/1,81,2,NB"IKKI"%
002-91.81%ML7"8.122231746668193,43@ML.4@"%^23.1444
003-1.33321444718%"YLD""SO"%{71.%{62.1339816{331.422231765%<<<NL6
004-LOOP%Go To"000"%
VCL javaやc#しかやったことないような人間がc++でもメモリ管理をきちんと身につけるには何から始めるのが手っ取り早いでしょう？ >>812
C++ ではなるべくスマートポインタを使って自動化すべきなんだけど、
その内側にあるメモリの気持ちを実感として持つには C の範囲で色々やってみるのもいいかな。 >>812-813
JavaやC#が選択肢になる状況でC++を選択する理由はない。
今C++を何に使うか決まってないのなら、JavaやC#を極める方向に努力した方がいい。 VisualStudioでMFCのSDIテンプレートを作ると、ドキュメントクラス、ビュークラス、アプリケーションクラス、メインフレームクラスができますが、
これらのポインタを初期化時にグローバル化しておいて、以後あらゆるクラスから気軽にアクセスできるようにしとくのは良くないんでしょうか？
グローバル変数はあまり使うべきではないという考えは置いておくとして、動作上問題は起こるのでしょうか？ 問題が起こらないように作れば起こらない
としか言えない MFCのtheAppには100万回ぶち切れてきたけど動作上は特に問題は無い あーこの人、こうやっちゃったんだ(ﾆﾔﾆﾔ
しながら使うもの
ARM C++ベースなんで同情するところもあるけどね グローバル変数だからといって頭ごなしにぶち切れるのもいかがなものか…
CPU視点でやるべきことに対して処理順序にあいまいさが生じないなら実行上問題無いし、
プログラマーの視点で管理できる個数なら実用上も問題無い
同一クラスの複数インスタンスが欲しければグローバルな配列にしたらやり過ごせる
ていうか仮にtheAppを根とする木構造で全てのデータを管理することを思い立ったとして、
その木の根付近をぶち切って得た2～3の大枝をグローバル変数を根とするそれぞれ別の木にする、ぐらいの
挿し木設計は設計上のショートカットとして許されるべきや
というのは、プログラムのあらゆる箇所で
theApp()->getMemberA()->getMemberAA()->getMemberAAA()->...->getMemberZZ()->getValue()
と書かねばならなかったものが、
g_dataAA->...->getMemberZZ()->getValue()
ぐらいで済む 平気でグローバル変数を使う奴はtheAppの混じったコードを使いまわし続けて大量にデータを持たせるようになる
そして結合しまくりのクラスを他のソフトにコピペしていつのまにか神theAppができある
マルチスレッドで読み書きしてるもんだから予想外のバグが起こる
上司はそれでそれが当たり前だと思ってるから同じようにしろと俺に命令する
俺切れる >マルチスレッドで読み書きしてるもんだから予想外のバグが起こる
これはグローバル変数でなくとも起きる設計なら起きるから別件
ていうか
>CPU視点でやるべきことに対して処理順序にあいまいさが生じ(>>822)
ているケースにあたる
非同期呼び出しの同期化は呼び出される側のクラスで解決すべき、というだけ
メソッド内で完結できれば最も安全
パホーマンスや処理の粒度の関係でそれが適さない場合は
トランザクション処理をちゃんと設計汁、 >>823
アプリケーションの中で寿命の長いデータはどこにどうやって置いてるの？ >>824
ちょっと足りなかったわ
マルチスレッドでかつ複数のクラスを跨って別々の場所で読み書きされているからいつどこで変更されるかわからないことが多々ある
そうなるとあちらを立てればこちらが立たずといった感じになり、きれいに書く気力が失われてさらに汚さが加速する
>>825
必要なデータだけを引数で与えるべき グローバル変数で同期とるんじゃないぞ。そんなもので同期なんて取れないからな。
ちゃんとOSが提供する同期オブジェクト使えよ。 どんな環境でもOSがあってしっかりした同期の仕組みが有るとか思ってるお花畑がいると聞いて いやはや無知で申し訳ない。
マルチスレッド機能があって同期の仕組みが提供されない処理系があるならばご教授して頂きたい。 文脈上Windowsでの話なのははっきりしてるのに「どんな環境でも」とか >>826
>必要なデータだけを引数で与えるべき
引数を渡す側がそのデータをどこにどうやって保持すればいいのか、という問題が残るだけでは？ >>831
> 引数を渡す側がそのデータをどこにどうやって保持すればいいのか、という問題が残るだけでは？
再帰的にたどって行けばいいだけかと
プログラムの寿命とほぼ同じ寿命が必要ならmain( )で定義することになるだろうし どうしてもグローバル的なものがほしいなら、グローバルにしてしまえよ。
アクセス用の関数だけしっかり同期処理書けばいい。 んまーマルチスレッド機能有りのOSであり
(1) OSがプリエンプトしてくるのを止めるAPIが無い
(2) ユーザープログラム独自に割り込み禁止命令を実行できない（特権命令違反でトラップされる
としたらユーザー側ではフラグのread modify writeのアトミック性を保証する術がまるきり無くなる いやすまん下記も追加
(3) interlock系の命令が使えない（特権命令違反か何かでトラップされる
(3)は使えるかな普通…
>>829のは杞憂かもしれんな… しかしまあ同期処理はOSが提供すべき（理念としてだけでなく、その方が効率よく実現できるから
というのは同意
マルチスレッド機能があるOSなら必ずプリエンプトされないコード範囲を持つので、そこでなら
interlock系の命令を持たないZ-80みたいなCPUでも何も問題なくアトミックなread-modify-writeができる、 >>834-835
Compare-And-Swapとかの命令が特権命令になってるプロセッサなんてあるんだっけ？ >>837
Interlock系命令の意味で言った
正しい言葉使いかは知らん…！ atomicなread及びwriteが使えるならmutexを構成できるし、それを利用すればread modify writeも可能だよ。 ミューテックスが何だって？
くだらねえ話しやがって・・ >>831
どんどん上にたどっていく
そのデータを管理しなければいけないクラスあるいはmain関数が保持すればいい
externした変数はそのクラスが所有権を持っていることと同等なので、パフォーマンス上の都合が無ければ極力共有は避けるべき
あとコードを使いまわすときにも障害になる
ファイルにまとめて他でincludeしてもそのまま使えない >>841
＞そのデータを管理しなければいけないクラスあるいはmain関数が保持すればいい
クラスが持つっていうのはそのクラスのスタティックメンバにしろという意味？
それでは結局グローバル変数とか無名namespace内変数とあまり変わらないような気がする。 >>842
言ってる意味がわからない
クラスA内クラスBとCを宣言して
B b;
C c;
c.set_data(b);
だとか
main関数内で
Dptr d_ptr = D::get_resource();
Eptr e_ptr = E::get_resource();
F f(d_ptr, e_ptr);
f.excute();
とかこんな風にする >>843
んー
＞そのデータを管理しなければいけないクラスあるいはmain関数が保持すればいい
「あるいは」ってどういう意味？
main関数内に持つ方はわかるんですよ。
そうでなく、「クラスが保持」の方の解説をお願いしたい。ずっと保持し続けるんだから
スタティックメンバなのかな？と思った。 >>820
では、例えば初期化時にtheApp内に、Doc、View、MainFrmクラスのポインタをメンバに持たせておいて、
以降、あらゆるクラスからtheAppを介してアクセスしてもよいということですね。
こういったやり方でふとよぎった不安なんですが、
長時間アプリを起動していたとき、とあるクラスの参照ポインタがいつのまにか変わっていて、
例えばビュークラスを取得しようと「theApp.GetView()」としたときにはすでにそこにViewクラスはいない。。。なんてことは起こりませんか？ >>844
普通なパブリックなメンバでいいと思うけど
その所有権をもったクラスの寿命が尽きたら同時に開放される
>>845
もちろん参照元からは参照先の実態があることが保障されないのでよくある
特定のメンバの参照数が数百箇所になってたときは手に負えなくなったのでさすがに作り直した >>848
推敲とかしてないのである程度読み替えて言いたいことを汲み取ってね
そのクラスの変数の寿命な うん、寿命の長いオブジェクトをどうやって保持し続けるかっていう話なのにね 悩む理由がよく分からないが。適当な管理クラス作ればいいだけでは。 >>849
寿命の長いオブジェクトをどうやって保持し続けるかがテーマなので、
「a というデータはクラスBのオブジェクトbに持たせればいい」では
じゃあそのbはどこにどうやって保持し続けるのかという無限後退に陥る。
普通のグローバル変数やシングルトン
theAppにぶら下げるの
mainの中に置く
一長一短あるのでそれ以外に何かないかなという話 別に永続化、シリアライズの話までしてないわけでしょ。
mainかグローバルの2択で推奨はmain、どのスコープからも見えてアクセスしたいならグローバルもありで終わりでしょ。 >>853
あなたの意見は>>833以降ずっと一貫しているからいいですよ。
>>823の意見がわかるようでわかりにくい >>846
>>もちろん参照元からは参照先の実態があることが保障されないのでよくある
ソースコードで意図的にdeleteとか、アドレス移動する命令をいれてなくても起こるんですか？
（ガベージコレクションみたいなことが） >>829
無知を謝る必要はない
マルチコアのDSPをOSレスで使うとか >>826
パラメータで渡すべき情報と
そうじゃない情報と
がある >>852
スタティックメモリ(グローバル変数など)
auto変数(スタックやレジスタなど)
OSやAPI側の保存領域(APIを用いた設定など)
ファイルなど > プログラムのあらゆる箇所で
> theApp()->getMemberA()->getMemberAA()->getMemberAAA()->...->getMemberZZ()->getValue()
> と書かねばならなかった
本当にあらゆる箇所に重複コードを書きまくっているとしたら相当なアフォだな
関数化かキャッシュするだろふつー 最近WindowsのほうでVSを入れまして、簡単なSTGを作って遊んでいるのですが、MacOSでもC++でSTGを作ることはできるのでしょうか？
Windowsでは、DxlibといったSTG制作に特化したライブラリがありますが、MacOSではどうなのでしょうか…？実際にMacでSTG制作の経験がある方、挫折した方の話をお聞かせください。よろしくお願いします。 >>864
何かおかしなことを言っていたらすみません。
STG制作入門のホームページでそのようなことが書かれていたので、そう認識していた次第です。 それはDirectXの薄いラッパなので何に特化しているとかはない
マルチプラットフォームで作りたいならOpenGLで作れ OpenGLか…
難しそうだしまだ取っ付くべきじゃないような気がするんだけどそんなことはない？ >>845
それぞれアクセス関数が用意されているので馬鹿なことはやめなさい >>862
黙れよｷﾁｶﾞｲ
theApp()はtheAppかthisの間違いだがそれは別にして
メソッドgetMenberA()を有するクラスから始まって、
メソッドgetValue()を有するクラスFooまでの全てのクラス
が完璧にカプセル化された設計の元で
theAppから配下のFooのメンバにアクセスするアクセッサは実質的に>>862な状況を呈する
これはもう完璧なカプセル化を諦めて途中までグローバル変数にする（挿し木設計）か
インライン展開による最適化を期待するぐらいしか手が無い まあ神の視座に立てば完璧な抽象化を徹底してそんな深いアクセッサをいらなくすれば良いのだが
そんなことが最初からできるなら苦労は無い、 > カプセル化を諦めて途中までグローバル変数
ヘボ野郎 二次元配列の中身を1命令で一気に出力する方法はないでしょうか
いちいち2重ループかくのめんどくさいです >>874
Cでの方法を教えていただけると嬉しいです すいませんIDかわりました
>>875は>>873です 俺も暇なヤツだなｗ
template <typename T> void print_dim(T&);
template <typename T, int RANK>
struct print_dim_t
{
void doit(T& x)
{
for(auto& y : x) print_dim(y);
}
};
template <typename T>
struct print_dim_t<T, 1>
{
void doit(T& x)
{
for(auto& y : x) std::cout << y << ',';
}
};
template <typename T>
void print_dim(T& x)
{
print_dim_t<T, std::rank_v<T>> obj;
obj.doit(x);
} #define print_dim(array, type) do_print_dim_##type((type *)&array, (type *)(&array + 1))
void do_print_dim_int(int *first, int *last)
{
for(int *p = first; p != last; p++) printf(" %d", *p);
} 暇じゃないので横着しました
int* it = (int*) mat;
for_each(it, it + ROW * COL, [](int i){cout << i << " ";}); linuxの質問です
・koファイルからコマンドライン実行で実行ファイルを実行したい
どうやって実現するか調べてもわからなくてやり方教えて欲しいです
A --B みたいな呼び出しかたをしたい
・複数スレッドを立てているBプロセスを
全スレッドsleepにすることできる？ >>880
親プロセスをスリープにできるだけでも問題ないです system, execl, execlp, execle, execv, execvp, execvpe, spawn, popen, fork >>880 上半分だけ
.ko ってデバイスドライバとかのローダブルモジュールじゃないかな。
動作中のカーネルにinsmodで組み込まなきゃ使えないと思うんだけど。 すまん、質問の意図を取り違えたかも。
カーネルモジュールの中から外部コマンドを呼びたいって話かな。
可能かも知れん、と言うかカーネルがコマンドを実行するのと同じ手順のはずだが、
具体的な方法はさっぱり分からん。役に立たなくて申し訳ない。 >>884
とても欲しいです...
>>886
カーネルオブジェクトから外部コマンド(実行ファイル)をコマンド形式で呼び出したいって意味ですね >>882に書かれている関数のそれぞれの機能を比較し、該当する関数のソース(in Linux kernel)を読んでみては？ >>889
今解説読んでいてsleep関連が終わったとこ
exec関連多すぎて大変 >>880
ちょいと検索したところ call_usermodehelper て関数があるみたい。 >>891
今調べたら出てきました！
自分が望んだことできそうですありがとうございます ("a,b,c")とは、a,b,cの合計を表すのでしょうか？
それとも、a,b,c各それぞれを表すのでしょうか？ ここの住人はソースコードをコメントで装飾するのに、どういう書き方をしていますか？
参考にさせて下さい 「ptr->member」は、「(*ptr).member」と同じ意味。 本を読んでも
structやunionが具体的に、どの様に動作してるのか分かりません。 基本の基本なので、
先ずは、小さなサンプル作って、実際に動かしてデバッガで追ってみる。
その上で、判らない事を質問すべき。 質問です
以下のコードがコンパイルに通りません
class Structure { public: std::string type; };
std::vector< std::unique_ptr<void> > data;
std::unique_ptr<void> structure(new Structure);
structure->type = "HogeHoge";
data.push_back(structure);
>g++ -Wall -std=c++11 -c hogehoge.cpp
>error: ‘std::unique_ptr<void>::pointer {aka void*}’ is not a pointer-to-object type
> structure->type = "HogeHoge";
> ^
std::unique_ptr<void>ではなくて、
std::unique<Structure>にするとコンパイル通りました
voidだとだめなんでしょうか エラーになる理由を教えて下さい >>900
こりゃ -> の誤植だな。
印刷屋さんがC知らなくて矢印記号と思ったんだな。
コード部分は執筆者が念を入れてチェックしなきゃね。 >>906
エラーメッセージに書いてあるだろ
structure->type = "HogeHoge"; の代入先がオブジェクトじゃねえぜと
おまえさんはvoid = char const*;をやろうとしたんだよ あ、すまんちょいミスった
指摘できるやついる？解説頼むわ >>906
unique_ptrあんまりしらんから想像で書くけど
そいつがデストラクタまで管理したいからvoidじゃなくてちゃんと型渡せってことじゃね >>906
> エラーになる理由を教えて下さい
void 型の変数なんてないから
そもそも何をしたいんだよ... unique_ptr<void>という型なので、
中にtypeというメンバーがあることがコンパイラからはわからない。
static_cast<Structure*>(structure.get())->type = "HogeHoge";
のように明示すればコンパイルだけは通るかと思ったんだが、
こっちだと>>911の問題に引っかかって、その前の行でエラーになる。 >>913の最後の行は勘違いだった。
こちらの環境だと、unique_ptr<void>の時点でエラーになる。 unique_ptr<void *> だとどうなる？ >>913
delete できないからね
voidを渡すんならカスタムデリータもセットにしなきゃならない。
template <typename T>
struct vp_deleter {
void operator ()(void *p)const
{
delete static_cast<T*>(p);
}
};
std::unique_ptr<void, vp_deleter<int>> a(new int(8));
なら通った。 void型なんて定義もなければサイズもないから
素で使うがそもそもNG >>907
anyは知りませんでした
stdじゃなくてboostにあるんですね つかってみます
>>909
つまり void*->type は void.type になるってことですね
voidポインタは使ったことなくて、あれから調べたのですが
アクセスする前にキャストが必要だと知りました・・
無知ゆえの初歩的なミスです 指摘ありがとうございます
>>911, >>913, >>916
スマートポインタなのでデストラクタを呼び出せるようにしないといけないんですね
カスタムデリータは知りませんでした コード参考になります
void型なのはStructureの他にもプリミティブ型とかも入れたかったからです
boost::any使うやり方とカスタムデリータ渡すやり方両方やってみます
皆さんレスありがとうございました ひとつのカスタムデリータでいろんな型をdeleteするってなら無理 いまだにforkとthreadの動作の違いがわからない ある配列がありそれを指定した順番で並び替えしたい
std::vector< any_struct_t > array; //これを並び替えたい
std::vector< unsigned int > index_list = { 3,8,6,0,2...}; //この順番にしたい
探しているんだけど適当なライブラリが見つからない
標準ライブラリに入ってたりする？
またはアルゴリズムが知りたい
出来ればswap回数が少ない方法が知りたい 配列もう一個用意してその添え字に移動するんじゃだめなん std::vector<any_struct_t> ret(index_list);
std::transform(index_list.cbegin(), index_list.cend(), ret.begin(), [&array](auto i){ return array[i]; }); >>924
それタイプミスあります？
でももう一つ配列を用意してコピーする点では
他の方と一緒ですね
別配列を用意せず全てswapで済ます方法も作ってみましたが
これにはindex_listが更に2本必要になり
効率は別配列と変わらないと予想される結果でした
参考になりました
ありがとうございました >>925
別領域を全く使わずin-placeでかつ汎用性のあるやり方ってすごく難しそう。
でも不可能性の証明も難しそうなんだよな。 index_list に含まれる値がそれぞれ重複なく1回だけ出現とか、
いかにも破られそうな条件を暗黙に期待するライブラリ、
てのも変な感じだしねぇ。 >>927
「別領域を全く使わず」を見落としてたすまぬ 「別領域を全く使わず」とはいっても、テンポラリの変数を１個とか２個の固定数だけ使うのは除く。 屁理屈を言うと、index_listを壊していいなら、
以下の手順で別領域を使わない置換は可能。遅いけど。
for( size_t i = 0; i < array.size() - 1; ++i )
{
std::swap( array[i], array[index_list[i]] );
std::swap( index_list[i], *std::find( index_list.begin()+i+1, index_list.end(), i ) );
} おっと、index_list.begin()+i+1の「+1」は消してくれ この話をきっかけに、std::next_permutation の仕様を見てみたが、どういう時に使うのかよくわからない。 お前ら、プログラム書くとき、普通にnoexceptを何回も書いてるの？ >>936
permutation を実装するときに決まってんだろ？ >>938
今までthrow()と書いてた場所には書いてるよ
むしろ、書いてないの？ >>918
any は C++17 で標準に入ったよ。 規格と規格じゃないものの区別も付かない低能はすっこんでて >>908
ありがとうございます。
いくら検索しても出て来ないので、困ってました。 >>934
別領域を使わない置換に再挑戦。今回はO(n)のはず。
for( size_t i = 0; i < array.size() - 1; ++i )
{
size_t j = i, k = index_list[i];
while( k != i )
{
std::swap( array[j], array[k] );
index_list[j] = j; j = k; k = index_list[k];
}
index_list[j] = j;
} 後出しのようで心苦しいけどindex_listを壊すのはダメだと思う。
const参照で渡すインタフェースにできないという意味で汎用性条件を満たしていない。 >>947
以下の2つの理由により、外側のループがn回まわる間に
内側のループの中身はたかだかn回しか実行されない。
1. 内側のループ内で処理済みのインデックスjに対し index_list[j]=j が実行される。
2. index_list[i]==i の条件が最初から満たされていた場合、内側のループは実行されない
要するに、内側のループを実行済みかのフラグとしてindex_listを使ってるだけ。
>>948
index_listを壊している時点で屁理屈なのは自覚しているんで、仕方ない。
一応、別配列にムーブする場合と比べると、
最初から正しい位置にある要素への処理が不要になるというメリットは有る。 >>928, >>948
ライブラリに対するオレオレ定義をいちいち開陳しなくていいよ、チラ裏にでも書いとけ 駄目な理由が引数を壊すってことだけなら、引数を値渡しにしてやれば、
呼び出し時に勝手にコピーされるので問題ないはず。
壊していい引数を渡す時はstd::move()すればいいし。 引数がconst参照＝引数の状態を変更しない(てか、できない)という意思表示
に対して
引数が右辺値参照＝引数の状態を変更する(しても文句言うな)という意思表示
というのはアリ？
右辺値参照に対する理解が曖昧なんで漠然とよく分からない(何が分かって
ないかも分からないｗ)んだが、もっと別な意思表示方法もある？ ほ～ん>>946の奴はちゃんと動いたわ；
ttps://ideone.com/6lwMOn >>946の奴は要素[i]が内側のwhile()ループからは1回以上アクセスされないから確かにO(N)な気配、 右辺値参照というのは、関数f()へのT型データの値渡し時に暗黙のうちに行われる（C++03までは無条件に行われていた）
(左辺値) = (右辺値)
という代入処理において、
当該代入処理後、右辺値が関数呼び出し元によって使われなくなることが明白なとき、
左辺値へのコピー後、右辺値をデストラクトする
という処理に暗黙のうちになっていたものを、
右辺値から左辺値への移動
と「も」書けるようにするためのしくみ
Tに効率の良いムーブコンストラクタ（か右辺値参照を引数とする代入演算子）を定義しないとメリットが生じない
ポインタに__restrictを付けるべきかどうか悩まねばならないレベルの人用
C++03でもコンストラ・デストラ呼び出し回数削減の最適化がかかって同じような効果になるケースが多々あるから
そういうのが信用できない神経質な人向け
※ 個人の感想です >>957
右辺値参照には一時オブジェクトしか代入できない縛りがあるから㍉
関数fooを
voiid foo(int&& x)
というバージョンしか定義していないとすると、
int g_x = 10;
foo(g_x);
がビルドが通らないのではないか；
一般的な使用を想定すれば、結局foo(const int& x)も定義必要
C++03までしか使ったこと無いから知らんけど；； >>958
その場合はfoo(int(g_x));が通るから、必須ではないよ
コピーを外側で明示的にやらせることで、こっちのほうが責任が明確になるので好きという人もいる オブジェクトのコピーとかムーブのためにここまで言語仕様を複雑にしないといけないのか。おれにはさっぱり理解不能だわ。 使わなくてもいいんじゃないか？
使ったことないから複雑に感じるだけで、そこまで複雑でもないよ >>961
GCをもたない言語の宿命だから嫌なら性能を犠牲にするかGCを持つ言語を使えばいい いやいやスマポがあるじゃない。
中級が多いプロジェクトならスマポ強制のほうが性能上がるんじゃないかと思う。 個人的にはC++の言語仕様の暗黒面はほとんど「参照」が絡んでいると思う。 ADLとか部分特殊化のマッチとかのほうが、はるかに複雑で暗黒だと思う >>964
理解してないのでなにを指摘してるかさっぱり分からないが、
つまり、気取ってC++でGCっぽいことしようとして破綻してるわけだな。 >>968
> 理解してないのでなにを指摘してるかさっぱり分からないが、
わからないなら絡んでくるなよ...
> つまり、気取ってC++でGCっぽいことしようとして破綻してるわけだな。
全然違うし >>967
そう思う。
そのへんは「ルール」でしかないけど、右辺値参照はそれ自体が左辺値参照とは違うひとつの概念だから理解可能 右辺値参照なんか、破壊不可オブジェクトをムーブするときくらいしか使わないような。うにーくぽいんたとか。
それ以外は参照でいいし。 右辺値参照の有用性を理解できない人間にとってはそもそもC++自体が無用だと思う
さっさと退散しなさい ところでなんでそんなに一時オブジエクトを参照しなきゃいけないコードを書くの？
参照元を管理するのが面倒だから？ そういう人は初めからGC言語使えばよくね？ ということですか？ なんでとか言われても。。。
壊してもいい一時オブジェクトの場合、特別に効率的な扱いをしたくなるケースなんて山ほどある
それが分からないならC++なんて触らずにGC言語専門でやってればいいと思うよ そのあたりはトレードオフなんだよ。
そりゃあ気にせずに済むなら気にしたくないが、気にしなきゃならないときに出来ることがないのはつらいって話で。 俺もわからん
左辺値参照ではなく右辺値参照を使った方が
良い状況ってどんなの？
あと唐突にガページコレクション出してるけど
何の関係があるの？ そりゃ右辺値を束縛したくてかつconst左辺値じゃダメな場合だろ んー？
結局無いんでしょ？
使うべきシチュが
そうならそう言えばいいのに 使うシチュエーションがない？
規格決める奴等が無駄にあーだこーだ言ってるだけとか思ってるなら病院に行った方がいいと思う 初期化はどう？って言われても・・
右辺値参照で初期化するのがベターな状況は
浮かびませんけど >>981
と言いつつも
思い浮かばないんでしょ？
じゃあ君もワイと一緒ですね んん？
右辺値を束縛したい（一時オブジェクトだから左辺値としての実体はない）
けどconst左辺値じゃダメ（中身を変更したいから）
↑
これのどこにわかりにくい点があるというのか？
「RVOが保証されるようになったらいらない」という意見なら理解できるが・・・ たとえば swap の実装なんか（素朴には）moveを３回繰り返すんだから
右辺値参照の有用性は明らかだろ >>973「なんでそんなに一時オブジエクトを参照しなきゃいけないコードを書くの？」
↓
>>984「右辺値を束縛したい（一時オブジェクトだから左辺値としての実体はない）けどconst左辺値じゃダメ」
「これのどこにわかりにくい点があるというのか？」
これがアスペというやつか >>985
これを右辺値参照Verに書き換えて
利点を示してもらえますか？
void swap(int& a,int& b)
{
int c = a;
a = b;
b = c;
}
void main()
{
int a = 1;
int b = 2;
swap(a,b);
} >>986
そっちこそ唐突に>>793と>>984を唐突に矢印で結び付けてるけど大丈夫か？
お前の脳内の連想なんて誰にもわからないぞ なら何なら利点があるの？
long long型ならあるの？
もう訳が分からないよ >>991
コピーコストの大きいコンテナだったら三回も代入したくないだろ？ >>982
もう使わないなら右辺値参照版のコンストラクタに渡したほうがいいじゃん
そしたら、コピーが起きなくて済むでしょ？ >>986
右辺値を束縛したい文脈ではかわりにconst左辺値で常におkなのでは…（ていうかconstはあってもなくても良い
>>985
T型データのswapは素朴にはT型データのコピー3回＋破棄2回ぐらいが生じる
のでわ… swapが頻繁に起こるような用途なら、なんではじめからポインタで管理しないんですか？ 一時オブジェクトもglvalueなんだから
T &に束縛できればよかった >>995
ヒープじゃなくてスタックで処理したいから 結局のところ
右辺値参照はコピーコストを削減出来るのが利点で
それぐらいしか使い道がないってことか
かつ、コピーコンストラクタよりムーブコンストラクタの方が
コストを軽く出来るクラスに限られると
struct a{ void* p; }; // これには効果が期待出来るが
struct b{ int p[65536]; }; // これには効果は期待出来ない
結論としては、やっぱいらねーやこんなのってことだな 後者も効果が期待できるよ
そして、コピーコストが削減できるだけってのは正しいが、いるかいらないかは人による >>998
> struct b{ int p[65536]; }; // これには効果は期待出来ない
それはあんたがそんな構造をよく使うんなら正しい
よかったじゃないか、結論が出てｗ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 72日 12時間 33分 11秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
