0からの、超初心者C++相談室

**デフォルトの名無しさん** · 2018/11/12(月) 14:55:13.35

何にも知らない0からの出発、超初心者のためのC++相談室

**デフォルトの名無しさん** · 2018/11/12(月) 15:33:07.21

まずC#を覚えます

**デフォルトの名無しさん** · 2018/11/12(月) 15:41:29.72

>>1
乙

**デフォルトの名無しさん** · 2018/11/12(月) 16:05:28.85

C99に準拠したCプログラムってC++コンパイラで完全にビルドできますか？

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/12(月) 16:09:07.07

>>4
型キャストが必要な場合と、C++キーワードに引っかかるケースがあるから、コンパイルできるとは限らない。

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/12(月) 16:21:58.14

例えば、classという名前の変数がある場合は、C++ではコンパイルできない。
void *型の変数にint *の値をキャストなしに代入しようとすると、C++ではコンパイルエラー。

**デフォルトの名無しさん** · 2018/11/12(月) 16:35:33.39

>>4
C99モードにすればおk
$ gcc -Wall -std=c99 -lm round.c

**デフォルトの名無しさん** · 2018/11/13(火) 08:18:22.77

>>5-6
ありがとうございます。
C99では未定義だがC++で定義・予約されている言葉なんかが引っ掛かってしまうんですね。

**デフォルトの名無しさん** · 2018/11/13(火) 18:41:26.33

extern "C" {}って書いてる？

**デフォルトの名無しさん** · 2018/11/13(火) 21:54:10.86

まずCから
Cも分かってないのにC++とかﾑﾘ

**デフォルトの名無しさん** · 2018/11/13(火) 22:08:24.41

C99頃から互換性も無いし、別言語だからそうでも無いけど、どっちかと言うとCのprintfに影響受けてる言語の方が多いね。
どっち先に覚えても良いけど、Cのprintfは押さえておいた方がいい。
(ただ、経験的にC++のオブジェクト指向を覚えるにはJavaかC#から入った方がいいので、挫折したらそっちを一旦勉強する事を勧める)

**デフォルトの名無しさん** · 2018/11/13(火) 22:32:00.82

今の最新の規格ならだいぶ使いやすくなってるはず
とりあえず変数にはconstを付けれ

**デフォルトの名無しさん** · 2018/11/13(火) 23:50:04.90

C++とJavaのオブジェクト指向って、なにが違うのでしょうか？

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/13(火) 23:59:43.80

>>13
C++は、new を付けたらポインタ型になるが、Javaはnewを付けたら参照型になる。

**デフォルトの名無しさん** · 2018/11/14(水) 00:06:33.69

>>14
JavaよりC++のほうが難しいといわれるのは、ポインタがあるからっていう意味合いが大きいんでしょうか？

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/14(水) 00:19:07.08

>>15
C++のポインタは癌だ。どこにでもアクセスできてしまうし、メモリーリークが起きる恐れがある。安全ではない。
チェック付きの配列とスマートポインタを使えば、少しは安全になるが、完璧ではない。

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/14(水) 00:36:22.61

まず、ポインタ変数の宣言が初心者殺し。
int* a, b;の場合、bはポインタではない。

関数ポインタはさらに文法が複雑すぎる。
関数ポインタ型の複雑さから逃れるには、typedefを使うとよい。

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/14(水) 01:24:53.28

ポインタ型をtypedefしまくった環境がWindowsのWin32 APIだ。
intを大文字でINTと書く。intのポインタをLPINTと書く。unsigned intをUINTと書き、そのポインタをLPUINTと書く。
基本的な関数型は全てtypedefで定義済み。

これなら、ややこしいアスタリスク記号(*)に戸惑う必要はない。

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/14(水) 01:35:38.43

型を大文字で書くと分かりやすいという意味で、Win32ではよく使うポインタ型を全て大文字で定義している。
char *にはLPSTRを、const char *にはLPCSTRを用意している。

**デフォルトの名無しさん** · 2018/11/14(水) 03:03:41.18

なんてことを昔の人は考えたが、当然スマートポインタのほうがより安全である

**デフォルトの名無しさん** · 2018/11/14(水) 07:23:04.49

>>15
>>14じゃ無いけど、個人的にはfriendクラスとかJavaには無いクラス同士の関係があったりするが最初はそれがどう言う関係か理解出来なかった。
Javaでオブジェクト指向に慣れた後理解出来た。
C++はそう言う独特のオブジェクト指向があるので、まずそこまで複雑じゃ無いオブジェクト指向言語で慣れる方がC++独特のオブジェクト指向の理解に繋がる。

**デフォルトの名無しさん** · 2018/11/14(水) 11:35:25.78

>>18
無駄に覚えることを増やす馬鹿言語

wsとかswとか_sとかいっぱいつけやがってシッチャカメッチャカ

**デフォルトの名無しさん** · 2018/11/14(水) 11:36:41.07

あとtypedefしてる型を型チェックのときに同一とみなすのが意味ない
せっかく型を別けてるのに

**デフォルトの名無しさん** · 2018/11/14(水) 12:34:52.66

整数を定義するときって以下の３つだとどれがメモリ消費量とか実行速度の面で一番効率いいですか？

#define XXX (1234)
enum{ XXX = 1234};
constexpr int XXX = 1234;

**デフォルトの名無しさん** · 2018/11/15(木) 08:07:09.42

効率は実測が基本

**デフォルトの名無しさん** · 2018/11/15(木) 12:16:37.45

>>24
今時のコンパイラならどれも同じになるだろうけど、#defineはただの置き換えだから、実質直接数字に置き換える。
お馬鹿なコンパイラなら、これが一番速い。
(メモリ上のXXXに格納された1234をレジスタに読むのじゃ無く、レジスタに直で1234と書き込むので、メモリアクセス分は速い)

**デフォルトの名無しさん** · 2018/11/15(木) 17:16:40.52

constexprが候補に上がる時点で最新のコンパイラだと思われる

**デフォルトの名無しさん** · 2018/11/15(木) 22:39:39.09

AIの力でコンパイラの性能を上げるって可能ですか？

**デフォルトの名無しさん** · 2018/11/16(金) 09:32:03.61

a = xxx;
a = yyy;

これは、二重定義になりますか？

29 · 2018/11/16(金) 09:41:00.05

解決方法として

a = ("xxx" && "yyy");

を考えているのですが、これで良いでしょうか？

**デフォルトの名無しさん** · 2018/11/16(金) 11:34:07.59

a[] = {xxx, yyy};

29 · 2018/11/16(金) 11:52:01.81

>>31様
ありがとうございます！

**デフォルトの名無しさん** · 2018/11/20(火) 23:59:39.03

**デフォルトの名無しさん** · 2018/11/21(水) 04:04:25.43

整数型とbool型を比較したり代入しようとしたときに警告かエラーを出す方法はありますか？
int i=5;
bool b=true;
i=b;
if(i==b)
if(i)
↑3行すべてでエラーなり警告なりを出してほしい
b=i;とif(b==i)は警告が出ます
環境はvs2017です

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/22(木) 03:29:53.66

C/C++ではありえません。不可能です。

**デフォルトの名無しさん** · 2018/11/22(木) 06:04:18.72

>>34
C++のboolのサイズはcharと同じだから
b=i: で警告になるのは整数型と論理型の変換というより単にサイズの小さい方に
代入しようとしたから警告になるてことだろうね

boolを使わずに Booleanクラスとかを自分で作れば型変換の許可/不許可も自在だけど
ま、やらんわな。そんな非効率なことは

**デフォルトの名無しさん** · 2018/11/24(土) 11:20:27.36

34です
遅くなりましたがありがとうございます
自作クラスを作ってまでエラー出したいものでもないので気にしないことにします

**デフォルトの名無しさん** · 2018/12/02(日) 21:29:56.53

MSがC++をCより勧める利点ってなんでしょう。
.NET関連で商売する為にC#などの利用を推奨するのは理解できるのですが
C++に拘りC99にすら対応しないのは何かよっぽどの理由があるのかなと思ってしまいます。

**デフォルトの名無しさん** · 2018/12/03(月) 21:46:10.27

.net以前はMFCで商売してたからね。
その遺産を保守するのにC++が必要。

今でもそう言う会社相手に商売してる。
今はまだマシだけど、開発環境独占だと標準規格無視してた。
対応しなくても売れるのに、対応する必要は無いわな。

**デフォルトの名無しさん** · 2018/12/03(月) 21:49:11.54

御開帳です

http://connect.uh-oh.jp/

**デフォルトの名無しさん** · 2018/12/05(水) 04:20:50.45

enum EN { yama,kawa}
をアクセスする規則がわかりません。　EN.yama の時もあれば　単にyamaの
時もあります。規則はどうなってるんでしょうか？

**デフォルトの名無しさん** · 2018/12/05(水) 14:48:45.83

namespace

**デフォルトの名無しさん** · 2018/12/05(水) 23:17:47.17

C++ならEN.yamaはあり得ないだろう

**デフォルトの名無しさん** · 2019/01/09(水) 10:11:37.02

新年記念up

**デフォルトの名無しさん** · 2019/01/11(金) 18:31:10.60

win16からwin32への移行では役に立ったのかもしれない。

**デフォルトの名無しさん** · 2019/01/22(火) 13:59:06.16

ゼロが流行っているのか？

**デフォルトの名無しさん** · 2019/08/28(水) 20:07:30.06

Cは習わないとダメですか？

**デフォルトの名無しさん** · 2019/08/29(木) 10:03:19.38

c++相談室だぞ
習わなくていいなんて答えるヤツはいないぞ

**デフォルトの名無しさん** · 2019/08/30(金) 20:54:35.96

いやCの勉強なんてしなくていいよ
最初からC++の勉強をすればいい

**デフォルトの名無しさん** · 2019/08/31(土) 00:49:34.53

C++は糞
Cだけやっとけば充分

**デフォルトの名無しさん** · 2019/08/31(土) 21:44:16.76

C++って便利になってもゴチャゴチャしてて汚い言語だとどっかで聞きました

**デフォルトの名無しさん** · 2019/09/01(日) 01:17:32.77

ゴチャゴチャだと？
無理して拡張された機能を使わなければいいだけの話じゃないか
C言語でオブジェクト指向プログラミングをしようとするとどれだけ危険で汚くなるか分かってるんだろ？
C++は表面的にだけどそれをきれいにまとめた点だけでも評価されていいんじゃないか？

**デフォルトの名無しさん** · 2019/09/01(日) 01:34:32.37

つまりテンプレートを使うなということですね判ります

**デフォルトの名無しさん** · 2019/09/21(土) 17:36:37.24

c++は元はクラス形オブジェクトシステムを高速に動作させる為に始めたけど
今は単に高速にする事を目的に作っている様に見える
その為に一度に出来る様な記述を追加していってて有る意味便利なんだけど
機能が増えすぎて正確に把握するのが大変
その影響で何処か間違うとその間違った部分とは違う部分が違ってて
それを理解するのが大変
あちこちが絡みすぎてて言語自体がスパゲッティになってる印象
大量の事項を正確に覚えてそれられを正しく組み合わせないといけないから大変
超初心者にはかなりきつい
プログラミング初心者がやる様な物ではない
ある程度他のプログラミング言語をやって出来るようになってからの方が多分良い

**デフォルトの名無しさん** · 2019/09/21(土) 17:40:00.07

>その影響で何処か間違うとその間違った部分とは違う部分が違ってて
>それを理解するのが大変

「何処か間違うとその間違った部分とは違う部分が違っててそれを理解するのが大変」
はその通りだが

「その影響で」
は関係無い
大変なのは今に始まったことじゃない
高機能ωになる前からずっとそう

**デフォルトの名無しさん** · 2019/09/22(日) 09:05:21.83

この板にはC++委員会で多くの人が使いにくいと思っている仕様を提案してしまった
人が来ているので、最新のC++がダメになった、などと言うのは禁句。

**デフォルトの名無しさん** · 2019/09/22(日) 18:46:16.43

>>52
STLに関しては、コンテナ以外の部分を使わなければ、かなりスパゲッティー感が
なくなる。C++98以降、STLの実装にしか使わないような template の機能強化
に邁進してしまったようだ。しかし、C++ reference などで STL がふんだんに
使って説明されてしまってるので若い人の間で STL が C++ の標準だと
思われてしまい、そこが難しいので C++ が嫌われる結果となっている。
本来はライブラリはプログラミングが簡単になることを目的にしているはずなのに、
STLはその逆を言ってしまっている。
問題なのは、STLを使いまくったC++コードがネット上に増えてしまっていること。

**デフォルトの名無しさん** · 2019/09/22(日) 19:24:43.32

奥が深いからね
ｼｮｳｶﾞﾅｲね

**デフォルトの名無しさん** · 2019/09/22(日) 19:40:18.23

STLのコンテナ以外の部分とか自作template使わないとプロ感出ないからね
仕方ないね

**デフォルトの名無しさん** · 2019/09/23(月) 09:41:06.71

言語仕様を一通り学んだ後でライブラリの詳細な使い方を覚えていけるのが理想。
ところが、cppreference では、言語仕様を本文だけでは説明し切れておらず、
サンプルコードを見てやっと理解できるようになっているが、そこで
非常に難解なSTLの使い方をしてしまっている。それでは
STLの非常に詳細な仕様を知らないとSTLの基礎となっている言語仕様すら
理解できないことになり、ある種の「トートロジー」のような現象が起きてしまう。
前段階の理解を元に三段論法的に論理や理解を進めていくという説明の仕方になっていないのだ。
そのやり方が C++ が難解であるというイメージを植えつけてしまっている。
cppreference の執筆者やC++委員会の上の方の人の中に、STLをC++の言語
それ自体だと思っている人がいるように思えてならない。
確かにPythonやRubyでは、似たような機能を持つものが、言語そのものの一部
である位置づけになっている。しかし、その理解はとても容易である。
だから、言語仕様を説明するサンプルコードがその理解を前提にしていたとしても、
理解の妨げにはならない。ところが、C++ではその事情は一変するのだ。

**デフォルトの名無しさん** · 2019/09/23(月) 11:55:25.99

codecvtですね判ります

**デフォルトの名無しさん** · 2019/09/23(月) 12:36:29.52

>>60
正確には、トートロジーというより、循環論法に近い。

**デフォルトの名無しさん** · 2019/09/23(月) 13:25:24.38

>>60
たとえば cppreference のどの記事のことを言ってるんですか？
１つか２つでもいいんで、具体例がほしいです。

**デフォルトの名無しさん** · 2019/09/23(月) 14:28:50.02

>>63
もしかしたら >>60 の説明は「ずれて」いたかもしれないけど、例えば、言語仕様の
サンプルコードに高頻度に vector が出てくるので、それ自体がどうやって実装されているかを
調べることも重要になってくる。すると、initailizer-list なるものが重要であることがわかり、
vector の実装でそれがどう関係しているかも知りたくなる。それを知る前にまずは、vector template
の細かい仕様を調べたくなり、以下を見るとする：
https://en.cppreference.com/w/cpp/container/vector

↑は冒頭部分からしてこうなってる：
template<
　class T,
　class Allocator = std::allocator<T>
> class vector;
(1)
namespace pmr {
　template <class T>
　using vector = std::vector<T, std::pmr::polymorphic_allocator<T>>;
}
(2) (since C++17)
1) std::vector is a sequence container that encapsulates dynamic size arrays.
2) std::pmr::vector is an alias template that uses a polymorphic allocator

これは、初心者には難しすぎるし、実装を調べたいような上級者には情報が不足しており、
「帯に短し襷に長し」状態である（ちゃんとした説明になっていないのだ）。
上の部分を見た場合、最初に、allocator とはなんなのか、ということが疑問になる。
そして、allocator を調べなくてはならなくなる・・・・。

まず、vector とは何なのかが大まかに知りたかった人にすら、これでは難しい。
例えば、Ruby なら、[a,b,c] は、リストといって、集合です、と説明して
わずかなサンプルでもその全体像が分かった気がしてくる。
それとは全然違うことになってしまっている。

**デフォルトの名無しさん** · 2019/09/23(月) 14:39:03.51

>>64
誤：initailizer-list
正：initializer-list

vector の仕様を調べようとすると、(1),(2)の2つの定義が出ており、(2)では
なぜか、namespace pmr が出てきて、さらに、using vector = ・・・、で
vector という名前が alias で定義されているらしい。基礎の基礎を知りたくて
vectorを調べたのに、namespace と using alias が出てくる。そして、pmr
という namespace がいったい何なのかということを知る必要が出てくる。

まず説明に言葉が足りてない気がする。英語は曖昧さを含み易い言語らしく、
英語に強い人に聞いても「文脈でどっちとも取れるので正確な意味は分からない」
と言われる。日本語に比して言葉の意味が薄くて、サンプルコードが重要となる。
IntelのCPU命令のマニュアルだと、擬似コードで説明されている事があり、
その場合にはほぼ正確に言っていることが分かるが。cppreferenceはそれもない。
ほぼ、サンプルコードだけが頼りになっているが、そのサンプルも分かりにくい。
サンプルに対する英語の説明が少なすぎるから。

**デフォルトの名無しさん** · 2019/09/23(月) 15:02:06.71

>>64
時々、「コードこそがドキュメント」などという人がいて、それに従って
cppreferenceが書かれてしまっている可能性がある。しかし、vectorの
「仕様」とは、vectorが如何に実装されているかではなく、如何に使うか
の説明から入るべきなのに、>>64は、実装をモロに見せてしまってるから
難しくなっている。(1)のtemplate文だけでは、templateの仕様がまだ理解できてない
段階では、vectorの仕様を知ることが出来ないことになる。そう書くよりも、
いきなり、

std::vector<int> v = {7, 5, 16, 8};　　// (100)

で、4つの整数型の要素を持つ配列を確保します。
メモリ上で要素は、隣り合わせに並びます。
配列の長さは動的に変更することが出来ます。

と書いたほうが良いし、完全な referece を書きたい場合でも、>>64 の(1)のように
書くべきではなくて、例えば、(100)を一般化して

[vector 型オブジェクトの作成方法]
std::vector<int> オブジェクト名 = 初期化子;　　// (101)
　初期化子 := {初期値リスト}

などと書かないいけない。

>>64 の (1)は、vector自体の「実装方法」を書いているだけで
vectorの「仕様書」にはなっていない。