C++にこんな機能があったらいいのに…と思ったことはありませんか？
私はあります。

○ローカル関数
どうして定義できないのでしょうね。あったら何かと便利なんですけどね。私はこれを使いたい時、構造体と　operator()　を利用して擬似ローカル関数を作ってそれを使っています。

○後置参照
後置参照と言うのかどうかわかりませんが、多くの言語の場合、どんな順番で定義を書いても大丈夫ですよね。C++では常に順番に気を付けないといけないので、面倒でしかたがありません。これができればインクルード関係もすっきりすると思うんですよ。

○↓これが可能 無性にこの機能がほしい時があります。ありませんか？ありますよね？ですよね？（←w
他の書き方をすれば同じ結果を得ることはできますが、すっきりしないんですよ。見た目が。
こんなことでいちいち関数化するなんて耐えられませんし。
現在は下のように書く事で擬似的に実現させています。
int damy = 0;
switch(damy){
case 0:
　　　if(～) break;
}

○ポインタ、参照、コネクション？
ポインタと参照を融合させたものとして、「コネクション」というものを考えました。とは言っても、Javaで言うところの普通の参照です＾＾；
コネクションを宣言する際は、型名の後に　$　をつけます。($にした理由は特にありません。適当です)
ポインタの場合は　*　を、参照の場合は　&　を型名の後につけますよね。あれと同じです。
初期化の際に型が同じ変数を指定すると、それがコネクト先として設定されます。
あとは、普通の変数のように使用するだけです。
コネクションへの変更はコネクト先に反映されます。
つまり、コネクションを、コネクト先の変数そのものとして考えることができます。
ここまではC++で言うところの普通の参照と同じですね。
コネクションの特性は、途中でコネクト先をかえることができるところにあります。
コネクト先を変えたい場合は　$=　演算子を使用します。
以下サンプルコードです。
まあ、「参照先を途中で変えられる参照」と考えればわかりやすいでしょう。
ポインタを使うといちいち　*変数名　と書かないといけないので面倒なんですよ。

○関数の戻り値操作
関数を作るとき、「値を返すと膨大なコピーが発生するから、参照引数で受け取ってそれを直接操作するようにしよう。あ～でも結果を返すっていうイメージを壊したくないんだよな～」って思ったことはありませんか？
私はあります。しょっちゅうあります。
そこで考えました。 ｜戻値型｜　｜戻値受取変数名｜　｜関数名｜（｜引数｜）｛｜関数定義｜｝
という構文です。
特にこの機能を使う必要がない場合は戻値受取変数名を省略できます。
関数の中で戻値を操作できる所がポイントです。
ついでに戻値を書くのを省略できても便利だなと思いました。
なお戻値が初期化されていなかった場合は先にデフォルトコンストラクタで初期化します。
const int satou = Function();
//satouが初期化されてから関数が実行される。constがついていたら一時的にconstが外される


以上です。
ここまで読んでくださってありがとうございました。

MoNoQLoREATOR さんが書きました:○ポインタ、参照、コネクション？
(略)
まあ、「参照先を途中で変えられる参照」と考えればわかりやすいでしょう。
ポインタを使うといちいち　*変数名　と書かないといけないので面倒なんですよ。

参照先を途中で変える関数というのは参照先の選択部分にバグがあったとき発見しにくくなります。
後半に参照先に対して処理するメイン部分があるとそちらに意識が傾いて、想定外には変わってないはずという思い込みが起きるからです。
ポインタ演算子が付いていてもしばしば起きることなのでポインタ演算子が付いてなかったらますます変化する可能性に気付きにくくなります。

書くべきではないコードを書けないようになっているという点で他の言語より優れているのではないでしょうかね。

設計に根本的な問題があるので、できるからやっていいものでないですけどね。

沢山の返信ありがとうございます。
多種多様な意見が本当にありがたいです。

h2so5 さんが書きました:

MoNoQLoREATOR さんが書きました:>>naohiro19さん
返信ありがとうございます。
しかし、ラムダ関数では無名関数を定義することしかできないのではありませんか？
私が定義したいのはローカル関数です。
宣言したスコープ内でのみ有効な関数が欲しいのです。

名前を付けることもできますよ。

ISLe さんが書きました:

MoNoQLoREATOR さんが書きました:>>naohiro19さん
返信ありがとうございます。
しかし、ラムダ関数では無名関数を定義することしかできないのではありませんか？
私が定義したいのはローカル関数です。
宣言したスコープ内でのみ有効な関数が欲しいのです。

naohiro19さんの書かれたラムダ式は、宣言したスコープ内でのみ有効なAdd関数として使えます。

すみません。よく見ていませんでした。
どういった構文なのかを読み取ることができなかったので、検索して引っかかったこのサイトを参考にして、てっきり名前をつけることはできないのかと思ってしまいました。


>>獅子さん
長文の返信ありがとうございます。
私の考えには真っ向から反対のようですね。ひしひしと伝わってきました。
おそらく今まで相当な苦労をして来られたからこそなのだろうと察します。
その気持ちは良くわかります。
怠けて楽しかしていないのに不満を言う人を見ると、腹が立ちますよね。
私の日記のせいで不愉快な思いをすることになってしまったのならば申し訳ございません。
でも、人間やっぱり愚痴を言いたくなるときだってあるんですよ。
私は とんだ消しゴム人間ですが、どうか愚痴を言うだけくらいは許してください。

・・・というわけで愚痴を言わせてください。
まず、 これができないと、例えば次のような場面で不便です。 このように書いた場合でも、頻雑なことには変わりがないと思います。
特に、条件の数値や>GRAMさん
返信ありがとうございます。
欲望がにじみでてますねw
C#プロパティー　ですか。
調べてみました。
正直な感想を書きます。
「もう素直にpublicにしちゃえよ」
まあ、外からの変更は代入しか受け付けない(ですよね？)という仕樣にしたいというのであれば便利なのでしょうが、そんな場面は少ないんじゃないですかね？
あ、でもこれはsetに限ったことですね。
大半の人はgetがお目当てなのかな？
そうですね。それなら多いに賛成できます。
ちなみに、この解説ページでは「クラス外部から見るとメンバー変数のように振る舞い、 クラス内部から見るとメソッドのように振舞うもの」と説明していますが、私は常日頃からそれと似たようなものが欲しいと考えていたことを思い出しました。
「クラス外部から見るとconstメンバー変数として振る舞い、 クラス内部から見るとconst無しとして振舞うメンバー変数」
つまり、外からは変更できないけど中からは変更できるメンバー変数が欲しいのです。
変数名と関数名を同じ名前にはできないから、いつも煩わしく思っています。
よし、これをアクセス指定子で指定できるようにして、　publist　としましょう。(public+const) こんなふうに書けたらすばらしいと思いませんか！？
そんなわけでこれについてもご意見お待ちしております。


>>ISLeさん

ISLe さんが書きました:コメント含めて挙がっている要望は他の言語ではとっくに実現されていることばかりですね。

優れたプログラマは楽をするための苦労を厭わないわけですが、それは、自分が苦労して、自分以外も楽ができる、という図式です。
対して非難される「楽をしたい」は、自分ひとりの望みを叶えるために他人が苦労してくれるのを期待してただ待っている、という図式です。

一行目について。
これは、前回と同じく嫌なら他の言語に引っ越せばいいという意味で解釈させていただきます。
ISLeさんの文章からは、排他的なものを感じます。
これは最後の

ISLe さんが書きました:クリエィティブなことがしたいなら自らプログラムを書くことはやめるべきです。

という文章からも感じられるものです。
気に入らないなら自分が気にいるようなものを探せばいい。無ければ作ればいい。
これには大いに賛成です。
しかし、それは最終手段です。
まずは土台のあるものを少しずつ変えていくところから始める方が効率的です。
それでは不可能だとわかってから、捨てればいいのです。
私は、C++に未来を見出すことができなくなったら躊躇なく捨てる覚悟ができています。
もしかすると近い未来ではjavaの専属になっているかもしれません。
しかし、できることならば、長年慣れ親しんできた(とは言っても5年程ですが)言語とは別れたくないというのが心情です。
今のところC++よりも得意な言語が無いからという理由もあります。
だから、できるかぎりC++に期待したいんです。
ギリギリまで粘りたいんです。
実現されるかもしれないというわずかな期待にかけてこの日記を書いてるんです。
たとえ実現できなくても、それに代わる書き方が見つかる可能性だってあります。
実際にさっきあったわけですし。
だめなら私がそれを実装したコンパイラをつくろうとさえ考えています。
おそらく20年はかかるのでそれまでは他の言語に頼らざるを得なくなるでしょうけれど。
それでも、それでもだめだった場合、すなわちコンパイラ作りに挫折したとき、私はC++を信じることをやめます。
少なくとも私は、「ただ待っている」だけのつもりは決してありません。




みなさんと議論ができてとてもうれしい限りです。
やはり私は議論大好き人間でした。
あ、いや、これで議論終わりっていうわけじゃないですよ？
意見があったらどんどん返信してください。
もっともっとお話がしたいです。
もっともっと沢山の人の考えを聞いてみたいです。
議論をすると、自分が何倍何十倍にも成長したように感じられるんです。
以上です。
長い長いなが～～～～～～～～～～い文章を最後まで読んでいただきありがとうございました。

わたしならこうしますけどね。
breakを使うと後から見たとき分かりにくい気がします。
嫌なら引っ越せとは言ってないです。
プログラム言語は嫌でも使わざるを得ないものでしょう。

ただ「(非難される意味での)楽したい」だけならいくらでも選択肢は用意されているということです。

MoNoQLoREATOR さんが書きました:気に入らないなら自分が気にいるようなものを探せばいい。無ければ作ればいい。
これには大いに賛成です。
しかし、それは最終手段です。

このあたりは認識が違いますね。
わたしは「楽したい」と思った時点で行動に移します。
後回しにできるのならそれは大したことではないわけですから。

「楽したい」欲求がクリエイティブの原動力だとしても、それ自体がクリエイティブだとするのは詭弁です。
ただの容器にガソリンを注いだって何も起きないですよ。

MoNoQLoREATOR さんが書きました:だめなら私がそれを実装したコンパイラをつくろうとさえ考えています。
おそらく20年はかかるのでそれまでは他の言語に頼らざるを得なくなるでしょうけれど。
それでも、それでもだめだった場合、すなわちコンパイラ作りに挫折したとき、私はC++を信じることをやめます。
少なくとも私は、「ただ待っている」だけのつもりは決してありません。

C++を変えてしまうのなら良く似た言語に乗り換えるのと何が違うのですか？

「おそらく20年」ということは既に取り掛かっておられるのですよね？
何もしてないのに「ただ待っているだけのつもりはない」とおっしゃっても説得力皆無ですよ。
『つもり』という単語が含まれている時点で何もしていないと明言しているようなものですが。

コンパイラをまるまる作らなくても、新しい構文を解析して既存のC++コンパイラでコンパイルできるコードに変換するツールを作るという楽な方法もありますよ。
Cのコードに変換するツールとCコンパイラの組み合わせだったC++コンパイラもあったのですからね。

どうして20年を縮めるために楽できる方法を探したり試行錯誤しないのですか？
20年なんて適当な数字でハードルを上げて自分には無理だと思い込もうとしてますよね。
そこに「楽したい」の意味の違いがあるのですよ。

(追記)
誤解していただきたくないのですが、わたしは「こうだったら楽なのになあ」と妄想することを否定しているわけではありませんよ。

　おっと、プロパティについて誤解があるようですね。プロパティにするのと、「内部からはRW、外部からはRO」にするのとでは、全然違います。
プロパティは外見上はフィールド（メンバ変数）へのアクセスのようなものですけど、実質はメソッド呼び出しなので、クラス側が柔軟にコントロールすることが出来ます。この柔軟性は、メンバ変数への直接アクセスでは得られないものです。
これも、C++なら、ゲッターとセッターで十分といえば十分ですけれども、記法の簡略化及び生産性向上への貢献という意味では、十分に便利な言語機能になりうると思いますね。

ｱｯｰ、と、まず最初に弁明(?)すると、全然不愉快になってないのでお気になさらないでください＼(^q^)／すみません
むしろ私も嬉しい限りですよ。議論好きですし。
たしかに私は意見が全く違うようですが、だからといって私の意見が全人類に通ずる意見だとは全く思ってないです。
（むしろ普段から私の考え方はズレてるらしい(^p^)）

でもだからこそ他の人の意見はとても聞いていて面白くて、
自分の間違いに気付いたり、逆に相手が共感してくれたり、
結果がどちらも納得しなくても議論は有意義に感じます。

それにむしろ私の意見をぶっちゃけてるのは普段から良くしてくれているﾛﾘさんだからこそです、
ほんとうにいつもありがとうございますm(_ _)m

むしろ私の捨て身攻撃が不愉快でしたらすみません＼(^o^)／


で、ご返信についてですが

MoNoQLoREATOR さんが書きました:

CODE:

{
　　　if() break;
}

これができないと、例えば次のような場面で不便です。

CODE:

{
	if(a = 20 && a = 30 && a = 50){
		other();
	}
}

このように書いた場合でも、頻雑なことには変わりがないと思います。
特に、条件の数値や<,<=が変わった暁には発狂するでしょう。
そういった理由から、breakが使えれば便利だと言えると思います。
また、ソースコードをより簡潔に書くことができます。
breakを使ったコードは最も簡潔で、美しいとさえ思えます。
「あれを利用すればできるじゃないか」というのではなく、もっと簡潔な、いえ、最上級に簡潔で美しいコードを求めるべきだと思います。
少なくとも、それを求める行為は自然なことだと思います。
また、「今の機能でできないか」という思考は放棄していません。
switch-case文で代用していたじゃないですか。
もっとも、「現在の文法のみで可能な方法」の中で最も簡潔で美しい方法ではありませんでしたが。
私も、「今の機能でできないか」ということを一番に考えていますよ。

そうですかね。私もコード書くとしたらISLeさんと同じか似たようなものかくと思いますけど。
それに上の場合breakが「ブロックをひとつ抜ける」ではなく「ifとかのブロックは無視してすっ飛ばす」ってことですか？
もはや複雑化してきたらbreakがどこに飛ぶかわからなくなるとしか思えません。gotoのほうがまだマシです。

この件にかかわらず、すでに同じことが出来るのに新しい構文を追加するのは宜しくないと思います。
それ自体C++の複雑な構文が増えるわけですし、当然デメリットだって間違い無く出るはずですよね。
メリットばかりを見ているというか、デメリットを意識して吟味することが足りないと思います。

もっとも、「現在の文法のみで可能な方法」の中で最も簡潔で美しい方法ではありませんでしたが。
私も、「今の機能でできないか」ということを一番に考えていますよ。

今の機能で出来るんですよね。でも最も簡潔で美しい方法を考察する時間が足りないのではないですか？

しかし、それは悪い感情ではないと思います。

「楽したい」を甘い感情と言っては居ますがけして悪い感情と言っていません。甘いと言っているんです。
確かに「楽したい」が直接的に甘いというわけではないかも・・・しかし楽したいという感情は間違いなく怠惰を生んでいます。
現にアナタは今できることでいかに簡潔で美しく出来ないかを吟味する時間を怠ったと思います。

私だって確かに楽したいと思うことは多々あります。
でもそこで考えるのは、今あるものでどう乗り越えるかです。
ココを怠るべきではないと思うんです。
ココをじっくり考えて、悩んで、試して、今回のロリさんのように他の人の意見をもっと聞いた上で
それでもいまの機能で出来ないとわかったものこそ新しい手段を創るべきものであると思うんです。

そういうものこそ人が共感して楽するものになると思います。
確かに人によってはこの工程を楽したいで乗り越えるかもしれないです。
でもその人は同時に間違いなく楽した先にあるものを欲する気持ちがあるはずです。

それは欲求という感情です。
この感情には勝てないというのが動物なのです。
動物は、もちろん人間も含めて、この欲求を満たすためにどんな努力も惜しまないでしょう。

これには同意ですよ。

新しいものを創るときに
「楽したい」というか「楽するため」なんていう発想は甘いと思います。
もっと大きな先のために過程を楽にしたいのなら、理解できます。

ISLe さんが書きました:

MoNoQLoREATOR さんが書きました:だめなら私がそれを実装したコンパイラをつくろうとさえ考えています。
おそらく20年はかかるのでそれまでは他の言語に頼らざるを得なくなるでしょうけれど。
それでも、それでもだめだった場合、すなわちコンパイラ作りに挫折したとき、私はC++を信じることをやめます。
少なくとも私は、「ただ待っている」だけのつもりは決してありません。

C++を変えてしまうのなら良く似た言語に乗り換えるのと何が違うのですか？

「おそらく20年」ということは既に取り掛かっておられるのですよね？
何もしてないのに「ただ待っているだけのつもりはない」とおっしゃっても説得力皆無ですよ。
『つもり』という単語が含まれている時点で何もしていないと明言しているようなものですが。

コンパイラをまるまる作らなくても、新しい構文を解析して既存のC++コンパイラでコンパイルできるコードに変換するツールを作るという楽な方法もありますよ。
Cのコードに変換するツールとCコンパイラの組み合わせだったC++コンパイラもあったのですからね。

どうして20年を縮めるために楽できる方法を探したり試行錯誤しないのですか？
20年なんて適当な数字でハードルを上げて自分には無理だと思い込もうとしてますよね。
そこに「楽したい」の意味の違いがあるのですよ。

>>C++を変えてしまうのなら良く似た言語に乗り換えるのと何が違うのですか？
現在私が知っている言語の中でC++よりも自分好みの言語が無いから、ではその最も理想に近い言語を少し変える方法が最も簡単な実現方法だと考えているだけです。
C++よりも自分好みの言語があるのならばよろこんで乗り換えます。

>>(前略)『つもり』という単語が含まれている時点で何もしていないと明言しているようなものですが。
こう言ってはなんですが、「ただ待っているだけのつもりはない」という文章を正しく理解してください。
もちろん解釈の仕方は人それぞれだとは思いますが、「つもりである」ということを否定していると解釈するのが自然でしょう。
「～しないつもりだ」と言ったらその人は『つもり』という曖昧さがあると明言しているわけですが、
「～するつもりはない」と言ったらその人は『つもり』という曖昧な意志ではないと明言しているわけです。
また、既に申し上げている通り、それは最終手段です。
それ以外の方法で実現できる見込みがないとわかったとき、初めてそれを開始します。
ですから、おっしゃった通り、その作業にはまだ1ミリたりとも取り掛かっていません。

>>コンパイラをまるまる作らなくても、(後略)
はい。それは一番に考えました。
しかし、それでは最速の実行ファイルを作ることができないのではないかと感じたのです。
新しい機能や文法を追加したら、やはりそれ専用のアルゴリズムを用いた方が最も高速の実行ファイルができあがるのではないかと考えているわけです。

[anchor=a1 goto=a2]ｱﾝｶｰ[/anchor]
>>どうして20年を縮めるために楽できる方法を探したり試行錯誤しないのですか？(後略)
どうしてそのような解釈になったのか私には理解できません。
むしろ、「20年で作ることができる」という自信の表れだと解釈すべきですし、実際そうです。
私は諦める気など毛頭ありません。
そして、「20年を縮めるため」ではありませんが、「そもそも自分でコンパイラを作る必要を無くすため」に楽できる方法は探したり試行錯誤していますよ。
例えばbreakの件です。
switch-case文で代用するだけではあきたらず、広く情報をあつめるためにこうして日記を投稿しているではありませんか。
もっとも、本当により良い方法が見つかるとは期待していませんでしたが。
試行錯誤は言うまでも無いでしょう。
説得力は無いかもしれませんが、あれが私のその時点での最大の発想だったのですよ。
いくら試行錯誤して考えても思いつかないことだってあるんです。



>>獅子さん
だーかーらー！！！
ロリじゃないって何度言ったらわかるんだよそもそも私は男ですよもし私が仮にロリと呼ばれるような年齢だったとしてもそれはショタと言うんじゃないんですかてかそんなことどうでもいいんですよあと2年で飲酒が解禁されるようないい年したキモオタがロリやショタなわけがないでしょういったいあなたはなにを言って・・・もう、ロリでいいです。

こほん。
まあ、なにはともあれ、不愉快でないならよかったよかった。
獅子さんも議論好きの人なんですね。

ではさっそく。

>>それに上の場合breakが「ブロックをひとつ抜ける」ではなく「ifとかのブロックは無視してすっ飛ばす」ってことですか？
違います。
本家C++のbreak文の意味を獅子さんはおそらく理解されていないのではないかと思います。
forループ・whileループの{ }の中でbreakを書くと、そのループから脱出します。
switch-case文の{ }の中でbreakを書くと、そのswitch-case文から脱出します。
今回の場合、　{　}　を無属性ブレースと呼ぶことにしましょう。
無属性ブレースは　if(){}　や　関数や配列変数の初期化の際に用いるブレース以外のブレース――すなわちスコープを表すだけのブレース――を指すことにします。
無属性ブレースの中でbreakを書くと、その無属性ブレースから脱出します。
つまり、 などと書いた場合と同じ挙動です。
上記の例の　do　と　while(0);　を省略したものだと思っても問題ありません。

新月獅子 さんが書きました:この件にかかわらず、すでに同じことが出来るのに新しい構文を追加するのは宜しくないと思います。
それ自体C++の複雑な構文が増えるわけですし、当然デメリットだって間違い無く出るはずですよね。
メリットばかりを見ているというか、デメリットを意識して吟味することが足りないと思います。

「C++の構文が複雑だから、少しでも複雑でない構文を考えましたがどうですか」という提案をしているわけですよ私は。
構文に限ったことではありません。
例えば後置参照が可能なら(現在よりは)複雑でなくなると自信をもって言えます。
また、構文を変えることは問題だと思いますが、構文を追加することは何も悪くありません。(既にある構文の邪魔にならなければの話)
なぜなら、利用者はどちらを（あるいはどれを）使うか自由に選択することができるからです。
自分にとって最も都合の良い構文で記述すれば何の問題もありません。
選択肢が沢山あるほど自分好みの構文が存在する可能性が高くなるわけですから、追加するだけならば悪くはないと私は思います。
また、たとえ同じことが出来たとしても、見た目の簡潔さと美しさを追求することは重要だと思います。

考察する時間に関してはISLeさんへの返信で述べていますので、恐れ入りますが[anchor=a2 goto=a1]そちら[/anchor]をご参照ください。

また、獅子さんは「できること」を最も重要視されていらっしゃるようですが、私が最も重要視しているのは「見た目」です。
見た目を気にしないのであれば無属性ブレースなんて必要ありません。
では何故こんなにも自分が考えたものを渇望しているのか。
それは見た目の美しさや簡潔さを追求しているからに他なりません。

そして、獅子さんは現存するものに固執しすぎておられるように感じられます。
おそらく努力を最高の美徳だと考えていらっしゃるのでしょう。
たしかに努力が必要な場面で懸命に努力をする姿はなによりも美しいと思いますが、努力が必要でない場面あるいは努力しても目的を達成できない場面――今回では「自分が納得できるレベルまで、見た目を美しく簡潔にする」という目的を達成できない場面――においては他の方法をとった方が賢明であり、優雅です。
新しい手段を創って”楽をする”ことができるのならば、積極的にそちらを選択するべきだと私は思います。
楽をすることができる場面なのにそれをしないのは非効率的で美しくないと思うのです。

なぜか[anchor=a1 goto=a2]アンカー[/anchor]が使えません。
新しく返信するときは[anchor=a2 goto=a1]こんな風に[/anchor]ちゃんと使えるのですが。

すみません。期待し過ぎました。

それは何に対してですか？