インスタンス生成方法の呼び方について

Question

インスタンス生成方法の呼び方について

解決済

回答 4

投稿 2015/11/15 22:18 ・編集 2015/11/15 22:30

評価
クリップ 0
VIEW 2,833

Chironian

C++総合1位

インスタンスを生成する方法を２つに分けることができます。newやmalloc()等を用いて生成する方法(A)と、それ以外の方法(B)です。

方法(A)はnewやmalloc()等で明示的に獲得したものであり、deleteやfree()等で明示的に解放する必要がある方法です。
方法(B)とは、明示的な解放処理が不要なもので
  ①グローバル変数
  ②ローカル変数
  ③クラス内の静的変数
  ④クラス内のメンバ変数
等です。
この方法(A)と方法(B)について、適切な用語がないでしょうか？

一度簡単に説明すれば、その意味を想起しやすい用語が欲しいのです。
専門用語はないでしょうか？もしくは、分かりやすい用語を思いついた方がいらっしゃいましたら、是非教えて下さい。

(A)は「動的領域」のような用語で良いと思うのですが、(B)は良い言葉を思いつきません。④を含めたいのでなかなか良い用語がないのです。
④については、このクラスがnewで獲得されていた場合でも、このメンバ変数については明示的に解放する必要はありません。なので、明示的な解放が不要と言う意味で方法(B)に含めたいのです。
でも、「明示的解放不要領域」では長いし、生成方法の説明ではないので違和感が強いのです。

気になる質問をクリップする

クリップした質問は、後からいつでもマイページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

クリップを取り消します
良い質問の評価を上げる

以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します

評価を下げられる数の上限に達しました

評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる

teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します

この機能は開放されていません

評価を下げる条件を満たしてません

評価を下げる理由を選択してください
プログラミングに関係のない質問やってほしいことだけを記載した丸投げの質問問題・課題が含まれていない質問意図的に内容が抹消された質問広告と受け取られるような投稿
詳細な説明はこちら

上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。
質問の評価を下げる機能の利用条件

この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
- メールアドレスの認証
  メールアドレスの認証
- 質問評価に関するヘルプページの閲覧
  質問評価に関するヘルプページの閲覧

回答 4 件

評価が高い順
新着順
古い順

+1

すでにベストアンサーがついていますが気になったので
投稿します。

方法(B)とは、明示的な解放処理が不要なもので
  ①グローバル変数
  ②ローカル変数
  ③クラス内の静的変数
  ④クラス内のメンバ変数
  等です。

この分類は、どうもうまくいかない様に思います。

ローカル変数としてポインタを定義した場合、
ポインタの中身はmallocすることもできると思いますが、
その場合、明示的な解放処理が必要で、
Chironianさんの分類ではどちらともいえない気がします。

データの保持先がスタック領域か、ヒープ領域か、静的領域か、
という分け方ならわかります。

投稿 2015/11/16 00:40

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

2015/11/16 01:16

ポインタ自体はあくまでもアドレスを記録した領域です。この領域自体については明示的な解放はしません。
そして、ポインタの指す先の領域が動的生成領域であり、こちらは明示的に解放が必要になります。

ポインタ自体はあくまでもアドレスを記録した領域です。この領域自体については明示的な解放はしません。そして、ポインタの指す先の領域が動的生成領域であり、こちらは明示的に解放が必要になります。

キャンセル
2015/11/16 01:24

それは分かりますが、ポインタの指す領域はヒープ領域とは違うのですか？

それは分かりますが、ポインタの指す領域はヒープ領域とは違うのですか？

キャンセル
2015/11/16 01:43 編集

ポインタの指す先はnewやmalloc()で獲得した場合はヒープ領域ですよ。
ところで、静的定義領域を指すこともあります。
#include <iostream>
class Foo {};
Foo GlobalFoo;
struct Bar
{
　　static Foo StaticFoo;
　　Foo MemberFoo;
};
Foo Bar::StaticFoo=Foo();
int main()
{
　　Foo LocalFoo;
　　Bar* p=new Bar;

　　Foo* q1=&GlobalFoo;
　　Foo* q2=&LocalFoo;
　　Foo* q3=&(Bar::StaticFoo);
　　Foo* q4=&(p->MemberFoo);

　　return 0;
}
この q1, q2, q3, q4のケースをうまいこと一言で表現したかったのですよ。
pは解放しないといけないのですが、q1～q4は解放してはいけないのです。

【追記】
上記のp, q1～q4自身(アドレスが記録されたポインタ)は全て方法(B)の領域です。
そして、pの指す先が方法(A)の領域です。
ついでに、q1～q4の指す先が方法(B)の領域です。

ポインタの指す先はnewやmalloc()で獲得した場合はヒープ領域ですよ。ところで、静的定義領域を指すこともあります。 #include <iostream> class Foo {}; Foo GlobalFoo; struct Bar { 　　static Foo StaticFoo; 　　Foo MemberFoo; }; Foo Bar::StaticFoo=Foo(); int main() { 　　Foo LocalFoo; 　　Bar* p=new Bar; 　　Foo* q1=&GlobalFoo; 　　Foo* q2=&LocalFoo; 　　Foo* q3=&(Bar::StaticFoo); 　　Foo* q4=&(p->MemberFoo); 　　return 0; } この q1, q2, q3, q4のケースをうまいこと一言で表現したかったのですよ。 pは解放しないといけないのですが、q1～q4は解放してはいけないのです。【追記】上記のp, q1～q4自身(アドレスが記録されたポインタ)は全て方法(B)の領域です。そして、pの指す先が方法(A)の領域です。ついでに、q1～q4の指す先が方法(B)の領域です。

キャンセル
2015/11/16 01:57

言葉足らずですみません。
その二つのケースがあることは理解しているつもりです。
「ポインタの中身はmallocすることもできますが」と書いた後のコメントだったので、
「(mallocで確保した)ポインタの指す領域は」と略して書いてしまいました。

でも、それならば新しい用語を作るより、
非ヒープ領域とでもした方が良いのでは無いでしょうか？
静的定義領域だと、一般的な用語でないので、
用語の説明がないと何のことかわからない人が多い気がします。

言葉足らずですみません。その二つのケースがあることは理解しているつもりです。「ポインタの中身はmallocすることもできますが」と書いた後のコメントだったので、「(mallocで確保した)ポインタの指す領域は」と略して書いてしまいました。でも、それならば新しい用語を作るより、非ヒープ領域とでもした方が良いのでは無いでしょうか？静的定義領域だと、一般的な用語でないので、用語の説明がないと何のことかわからない人が多い気がします。

キャンセル
2015/11/16 02:00

ヒープ領域以外に、解放が必要な領域ってあるんでしょうか？

ヒープ領域以外に、解放が必要な領域ってあるんでしょうか？

キャンセル
2015/11/16 02:01 編集

Barはヒープに確保されてます。
q4はそのヒープ領域に確保した領域(MemberFoo)を指しているのですが、方法(B)に属するのです。なので、非ヒープ領域と表現できないのですよ。
実は、方法(B)を非ヒープ領域って呼び方を検討したのですが、上記理由で断念しました。

【追記】
> ヒープ領域以外に、解放が必要な領域ってあるんでしょうか？
ないわけではないですが、現在の議論では考えなくてよいと思います。

Barはヒープに確保されてます。 q4はそのヒープ領域に確保した領域(MemberFoo)を指しているのですが、方法(B)に属するのです。なので、非ヒープ領域と表現できないのですよ。実は、方法(B)を非ヒープ領域って呼び方を検討したのですが、上記理由で断念しました。【追記】 > ヒープ領域以外に、解放が必要な領域ってあるんでしょうか？ないわけではないですが、現在の議論では考えなくてよいと思います。

キャンセル
2015/11/16 02:22

あ、その通りですね。
具体的に説明していただいて、ありがとうございます。

それを踏まえて今考えたのですが、
struct BarにFoo *pMemberFooというメンバがあって、
コンストラクタでnewしてデストラクタでdeleteする場合、
それは「静的定義」とは呼びにくい様に思いますが、
どうでしょうか？

細かくてすみせん。

あ、その通りですね。具体的に説明していただいて、ありがとうございます。それを踏まえて今考えたのですが、 struct BarにFoo *pMemberFooというメンバがあって、コンストラクタでnewしてデストラクタでdeleteする場合、それは「静的定義」とは呼びにくい様に思いますが、どうでしょうか？細かくてすみせん。

キャンセル
2015/11/16 02:40

pMemberFooと言う「Fooのインスタンスのアドレスを記録しているポインタ」自体は明示的な解放は不要なので「静的定義領域」になります。
newで獲得された*pMemberFooと言うFooのインスタンスは「動的生成領域」となります。
この２つは混同し易いのですが、それぞれ別のメモリが割り当てられており、異なる領域なのですよ。

遅くまでお付き合い下さり、ありがとうございました！！
それでは、お休みなさい。

pMemberFooと言う「Fooのインスタンスのアドレスを記録しているポインタ」自体は明示的な解放は不要なので「静的定義領域」になります。 newで獲得された*pMemberFooと言うFooのインスタンスは「動的生成領域」となります。この２つは混同し易いのですが、それぞれ別のメモリが割り当てられており、異なる領域なのですよ。遅くまでお付き合い下さり、ありがとうございました！！それでは、お休みなさい。

キャンセル
2015/11/16 09:25

また言葉が足りなかったようです。
その二つが違うことは分かりますが、、
Foo* q5=p->pMemberFoo;
としたら、p->pMemberFooは動的生成領域を指すポインタなので、
同じ領域を指すq5は動的生成領域を指すポインタですよね？

でも、q5は解放してはまずいので(B)のケースに
当てはまるように思うのですが、どうでしょうか？
ということを言いたかったのです。

また言葉が足りなかったようです。その二つが違うことは分かりますが、、 Foo* q5=p->pMemberFoo; としたら、p->pMemberFooは動的生成領域を指すポインタなので、同じ領域を指すq5は動的生成領域を指すポインタですよね？でも、q5は解放してはまずいので(B)のケースに当てはまるように思うのですが、どうでしょうか？ということを言いたかったのです。

キャンセル
2015/11/16 12:37

> でも、q5は解放してはまずいので(B)のケースに当てはまるように思う

q5自体ではなく、q5の指す先の領域について、その特性に応じた用語を定義したいのです。

q5の指す先は、この場合はnewで獲得されてますので「動的生成領域」です。
q5の指す先は、Barが責任を持って獲得／解放した場合でも、明示的に解放する必要があると言う事実は変わりません。

> でも、q5は解放してはまずいので(B)のケースに当てはまるように思う q5自体ではなく、q5の指す先の領域について、その特性に応じた用語を定義したいのです。 q5の指す先は、この場合はnewで獲得されてますので「動的生成領域」です。 q5の指す先は、Barが責任を持って獲得／解放した場合でも、明示的に解放する必要があると言う事実は変わりません。

キャンセル
2015/11/16 14:10

> q5自体ではなく、q5の指す先の領域について、その特性に応じた用語を定義したいのです。

そうだったのですね。
それが理解出来ていませんでした。
丁寧に教えていただいて、ありがとうございました。

> q5自体ではなく、q5の指す先の領域について、その特性に応じた用語を定義したいのです。そうだったのですね。それが理解出来ていませんでした。丁寧に教えていただいて、ありがとうございました。

キャンセル

0

「ローカル変数」とおっしゃられている変数（関数のスコープの中で（スタック領域内に）メモリ確保され、スコープを抜けるとfreeやdeleteなど書かずとも自動で解放される）は、「自動変数」と呼ばれていますね。
ほかは「外部変数」「静的変数」の、合計3種類の「記憶クラス」があります。

次ページの「記憶クラス」の記述がご参考になるかと思います。
http://www9.plala.or.jp/sgwr-t/c/sec12.html

クラスのメンバー変数は、クラスのインスタンス自体の記憶クラスにゆだねられるわけで（グローバル変数としてインスタンスを作成されるか、自動変数として作成されるか、別のインスタンスの中に作成されるか...）、まさしくクラスインスタンスの「メンバー（変数）」なのでしょう。

ちなみに、mallocのような処理を自動変数として行いたい場合は _allocaという関数があります。こちらは必要量のメモリを（スタック領域から）確保しつつも、freeを書かずともスコープを抜けた時点でメモリを開放してくれます。

呼び名としては、new や malloc は「動的割り当て（変数）」、グローバル変数などではじめから確保しておき、プロセスの消滅で消えるものは「静的割り当て（変数）」、スコープを抜けると自動で消える局所変数は「自動変数」で、いかがでしょうかね...
http://www.geocities.co.jp/SiliconValley-Bay/7437/c/malloc.html

投稿 2015/11/15 23:50

編集 2015/11/16 00:00

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

2015/11/16 00:11

ご回答ありがとうございます。
「静的割り当て」、「自動変数」のどちらとも、④のメンバ変数に対してイマイチしっくり来ません。
catsforepawさんのご提案で気がついたのですが、「生成」と考えるからよろしくなかったようです。「割り当て」も「生成」と似た概念なのでしっくり来ないようです。

ご回答ありがとうございます。「静的割り当て」、「自動変数」のどちらとも、④のメンバ変数に対してイマイチしっくり来ません。 catsforepawさんのご提案で気がついたのですが、「生成」と考えるからよろしくなかったようです。「割り当て」も「生成」と似た概念なのでしっくり来ないようです。

キャンセル

0

性質の異なる物を一緒にしての呼び名なので、グルーピングの理由である「明示的解放不要領域」と呼ぶほか無いと思いますよ。他の名前にすると、「なぜこれとこれが同じグルーピングなのか」とかが分からなくなってしまう。

ちょっと気になる表現があるのですが、

一度簡単に説明すれば、その意味を想起しやすい用語が欲しいのです。

もしかして、教育目的に使うのですか？それはやめた方が良いと思います。それぞれ個別にきっちり説明しないと。

投稿 2015/11/16 00:38

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

2015/11/16 01:18

あ、使い方はちょっと上でも触れましたが、開発中のライブラリ内の変数名やコメントに使います。コメントはまだしも変数名は頭が痛いのです。長々と書きたくないし、こんな普通にお目にかからない概念に略号をあまり使いたくないし。

あ、使い方はちょっと上でも触れましたが、開発中のライブラリ内の変数名やコメントに使います。コメントはまだしも変数名は頭が痛いのです。長々と書きたくないし、こんな普通にお目にかからない概念に略号をあまり使いたくないし。

キャンセル

同じタグがついた質問を見る

score 1 · Accepted Answer · 2015-11-15T23:38

ベストアンサー

0

「コード定義領域」というのはどうでしょうか。インスタンスが配置される領域がコードに書かれた時点で確定しているという意味で思いついたのですが。これだとメンバ変数でも当てはまりそうな気がします。

投稿 2015/11/15 23:38

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

2015/11/16 00:00 編集

なるほど！！　コードで定義されている領域ですね。定義って表現がしっくりきました。
ならば、動的生成領域に対する概念なので、静的定義領域とするとなんかよさげに感じます。どう思われます？
てか、使ってみました。私の中では「静的定義領域」で決定しました。
ありがとうございました。

なるほど！！　コードで定義されている領域ですね。定義って表現がしっくりきました。ならば、動的生成領域に対する概念なので、静的定義領域とするとなんかよさげに感じます。どう思われます？てか、使ってみました。私の中では「静的定義領域」で決定しました。ありがとうございました。

キャンセル
2015/11/16 00:11

おお、決定したのですね。
ただ、「静的」が付くとstaticと混同してしまって自動変数やメンバ変数がしっくりこない感じになってしまいますが……。私も一瞬「動的」に対して「静的」が浮かんだのですが、前述の理由で「コード」にしてみたのですが。

おお、決定したのですね。ただ、「静的」が付くとstaticと混同してしまって自動変数やメンバ変数がしっくりこない感じになってしまいますが……。私も一瞬「動的」に対して「静的」が浮かんだのですが、前述の理由で「コード」にしてみたのですが。

キャンセル
2015/11/16 01:11

やはり、そうでしたか。

テンプレートやconstexprはコンバイル時に処理してしまうから、「静的」と表現されることが多いです。これに対して、実行時の処理は「動的」ですね。
そのような文脈に近いので、私の中では「静的」で安定しました。
今開発中のライブラリは、テンプレート・メタ・プログラミングとかも使っているので、この中で使うのなら、たぶんあまり違和感を感じないと思うのです。

マジで「定義」を思いつかなかったので助かりました。変数名やコメントに苦しんでいたのですよ。ありがとうございます。

やはり、そうでしたか。テンプレートやconstexprはコンバイル時に処理してしまうから、「静的」と表現されることが多いです。これに対して、実行時の処理は「動的」ですね。そのような文脈に近いので、私の中では「静的」で安定しました。今開発中のライブラリは、テンプレート・メタ・プログラミングとかも使っているので、この中で使うのなら、たぶんあまり違和感を感じないと思うのです。マジで「定義」を思いつかなかったので助かりました。変数名やコメントに苦しんでいたのですよ。ありがとうございます。

キャンセル

質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう！

インスタンス生成方法の呼び方について

関連した質問

同じタグがついた質問を見る

質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう！

インスタンス生成方法の呼び方について

15分調べてもわからないことは、teratailで質問しよう！

関連した質問

同じタグがついた質問を見る

SNSアカウントでログイン

teratailアカウントでログイン