C++相談室 part132

2017/10/10(火) 00:11:34.01

次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512

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

前スレ
C++相談室 part131
http://mevius.2ch.net/test/read.cgi/tech/1501295308/

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

■長いソースを貼るときはここへ。■
　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

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd33-+nyC) · 2017/10/29(日) 08:19:49.13

>>274
256KBの間違いだろ？
まずは、メソッド、デストラクタ、std::stringの３つを学習してみな。便利だとわかるから。

2017/10/29(日) 08:25:23.25

>>274
ROMは256Kの誤記だとして
RAM8Kはきついな

マイコン向けの開発環境も無償版や評価版なんてのがあるから一回試した方がいいと思う

コンパイラのオプションで例外と実行時型情報はOFFにするのを忘れずに
C++のコンテナクラス(std::vectorやstd::string)はメモリ不足で使えなさそうだな

2017/10/29(日) 08:51:05.52

ROMは２５６ｋの間違い。外部RAMは２５６ｋｂある。（ただしSPIでアクセスするので遅い）
だから８ｋは純粋にワークとして使える。
８ｋのRAMがきついと思うのは何故？
C++もワークはスタックを使うと思うけど、プログラムの実行エリアとして例えばクラスインスタンスを
作るのにRAMを消費することになるんだろうか？　動的にインスタンスを作成するとそのクラスが大きいと
RAMエリア（mallocで確保してロードしたら、解放するまではRAMエリアを使う）を圧迫することになる。
ということはRAMをあまり消費しない手法ってあるんだろうか？

2017/10/29(日) 09:18:10.76

普通は処理系が要求するコード、CONSTデータ、、スタック、初期値付きデータ、BSSの各セクションを
プログラマーが明示的にリンカに指示して割り当てさせるんじゃね；；
これはCもC++も同じなのでCでのやり方を理解しているなんならC++でも同じようにやれば良い
（グローバルなオブジェクトの構築と破棄の手当てが追加になるだけぐらいしか違いが無い

2017/10/29(日) 09:30:39.20

>>282
最適化切って動作確認したり、デバッグ用のコードを仕込んだりしてると8Kは意外とすぐに使いきれてしまう
当然プログラムの規模や書き方によるところだから必ず足りないわけではないけど

C++だから足りないというわけではない
元のプログラムがCで書かれてて8Kで動いてたならまぁ大丈夫か

2017/10/29(日) 09:31:08.74

>>282
>８ｋのRAMがきついと思うのは何故？
全てはID:5nFESEae0が上記各セクションをROMやRAMにどのように割り付けようとしているのかにかかってゐるのだが、

仮にスタックと初期値つきデータとBSSを全部8 KBのRAMに割り付けた場合、
コード以外の全て（malloc()含む）のメモリ消費がトータルで8 KBに収まらねばならず、
メモリ不足のせいでやれることは相当にきびしくなるとおもー

2017/10/29(日) 09:38:54.44

ID:XRmGRjwZ0

> RAM8Kはきついな
> コンパイラのオプションで例外と実行時型情報はOFFにするのを忘れずに
> C++のコンテナクラス(std::vectorやstd::string)はメモリ不足で使えなさそうだな

こいつレベル低すぎだろ。ド素人にもほどがある。
完全に組み込み経験なしじゃねーか。学生じゃねーのか。

2017/10/29(日) 09:49:26.98

コンテナクラスの消費バイトは12バイト。だっけ？

2017/10/29(日) 09:56:55.29

sizeof(コンテナクラス)すればﾜｶﾙ、
ただしコンテナに要素の追加でmalloc()される分は別枠

**デフォルトの名無しさん** (JP 0Hc5-xXVv) · 2017/10/29(日) 10:05:31.40

>>274
論外　勉強目的だろ
自称プロでも 8kB なんて環境で組んだことのある人間なんて少数
普通はデフォルトのスタックサイズやvtableの存在すら知らん
考え直せ

2017/10/29(日) 10:24:19.89

Microchip マイコン PIC24FJ128GA006-I/PT 16ビット RISC PIC24FJ,
32MHz, 128 kB フラッシュ, 8 kB RAM, 64-Pin
http://jp.rs-online.com/web/p/microcontrollers/6230897/

8KB RAM は、400円のPIC マイコンとかだろ

そもそも、C++ のコンパイラが無い

2017/10/29(日) 10:29:34.45

コンパイラはありますよ。C/C++とうたってるので恐らくC++もできると思うが、、、
TIとかHewとか他にもKeilとか

2017/10/29(日) 10:41:22.70

＞グローバルなオブジェクトの構築と破棄の手当てが追加になるだけぐらいしか違いが無い

おお、心強いお言葉。
例えば

class MyClass
{
int buf[1000];
int no = 0;
void inputdisp(int aa){
sprintf(buf," aa=%d",aa);
}
};
int sub1()
{
MyClass aaa;
aaa.disp(333);
return 0;
}

こういう場合はaaaはbufは2000バイトのRAMを使うけれども、stackに確保するんだろうか？
aaa自体はrom上にできると考えていい？
それなら、ｃと混在で徐々にC++に変えていく程度でも問題ないのかなとは思っている。

2017/10/29(日) 10:52:19.32

>>292
>aaa自体はrom上にできると考えていい？
質問の意味不明　再入力せよ

2017/10/29(日) 11:05:38.47

動的にNewを使ってインスタンスを生成した場合には、コードは必然的にRam上に置かれる。しかしスタティックに
生成した場合は、Code部分は原理的にはRom上にも置くことができる。そういう機能があるかどうか？って質問。

2017/10/29(日) 11:08:14.46

>>294
>動的にNewを使ってインスタンスを生成した場合には、コードは必然的にRam上に置かれる。
断じて否
こういう手合いに騙されてはいけない

2017/10/29(日) 11:14:29.67

>>292
aaaもbufも同じ場所。大抵のコンパイラでは同じアドレスを指す。C解るならclassをstructに置き換えて考えたらいい。それと一緒。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd33-+nyC) · 2017/10/29(日) 11:15:45.86

operator newの再定義ね。

2017/10/29(日) 11:29:26.33

ていうか>>294ハ質問者本人かしつれいorz

>>292のMyClass::inputdisp(int aa)のコードは、名前が適当にマングルされて(*1)
　void hoge(MyClass* this, int aa) // (1)
という2引数の関数としてコードセクションにコードが格納される、というのが真実(*2)(*3)
オブジェクトaaaを動的にNewを使ってインスタンスを生成しようがスタティックに生成しようが、
そんなこととは無関係に、aaa.inputdisp((int型データ))というメソッドの呼び出しは(1)の関数呼び出しにコンパイルされる

*1: ここでは簡単のため’hoge’という名前にマングルされたとしている。本当は引数の型や戻り値も情報として含む名前になるが省略
*2: C++の言語規格でそうせよ決まっているかどうかは知らないが、そう処理する処理系しか無いと思う
*3: コードセクションがROM上なのかRAM上なのかはプログラマーがコードセクションをどう割り付けたかによる

2017/10/29(日) 12:14:39.69

>296
うろ覚えで使ってるが、
Section Type of Memory Section Type of Memory
　.bss RAM
　.stack RAM
　.data RAM
　.sysmem RAM
　.text　　ROM　　　これがコード部分
　.その他　ROM
こういうのがある。

Hewの場合#pragumaでセクションを生成できたとおもうが、一般的に＃pragma とかで割り当てできるんだろうか？
今回はTiのコンパイラを使う予定なので初めての試み。
多分　
static Myclass aaa;
みたいにスタティックかなにかを冠して宣言すれば.textにコードは配置されると思うが、どうなんだろう。
スタティックなんだから原理的には配置はどうにでもなる筈。

2017/10/29(日) 12:18:36.34

問題はスタティックにした場合,　コードは.textに配置されるとしてもdataが.dataに配置されると非常にまずい。
スタックでやってもらえないと困る。

2017/10/29(日) 12:34:41.62

>>300
関数が再入されることを考えたら普通にスタックに配置されると思うよ。
むしろstaticにしたらスタックには配置されない。
ここまでインスタンスの話。
コードはいずれにしても.textに配置されると思うよ。特に指定がない限り。でもそれは>>300にとっても問題にならないかと。

2017/10/29(日) 12:40:57.57

>>289
30年ぐらい前に ROM2KB, RAM2KB の Z80 ボード用プログラムをC言語で作ったことあるよ。

2017/10/29(日) 12:43:00.92

例えば、パネル表示をまとめたクラスのような場合にはクラスのメソッド部分が非常に大きくなる。しかもライブラリ
的に使うわけだから、階層のわりと下で使うことになる。3階層あって、2階層目くらいから同時にいくつかが
生成されてしまう可能性も高い。するとRAMエリアが直ぐにパンクする。なのでメソッドを大量に含んだライブラリ的な
働きをするクラスに関しては、.textにあってほしい。それは可能だと思うがじゃあそのクラス内でつかうバッファなどの
変数なんかが問題になる。これは動的に生成しないとクラスの使い道が非常に限られてくる。第一suba（）で使っていて
subb()で使うとバッファエリアが壊れてしまう。
１．bufを持てないクラスなんて殆ど意味がない。
２．bufをスタティックにしか配置できないクラスなんて使い道がない。
３．小規模マイコンでメソッドをramに確保するなんて馬鹿げている。
これは明らかだよね。
　つまりMyclassのbuf[1000]、メソード関数（）（例えば50個）をスタックと.textにそれぞれ上手く配置する工夫が
絶対に必要ってことだね。

2017/10/29(日) 12:45:06.72

＞コードはいずれにしても.textに配置されると思うよ。特に指定がない限り。でもそれは>>300にとっても問題にならないかと。

であれば何も問題ないですね。

**sage** (ﾜｯﾁｮｲ ebe8-KIob) · 2017/10/29(日) 12:54:06.20

組み込みはPCで動くの違って配置も考えないといけないから大変だな

マイコンでの配置に関してはここより組み込みが普通の電電板のマイコンスレでの方が良いような気がするが。

2017/10/29(日) 16:49:46.36

>>274
純粋にC言語の書き方するだけならコンパイラの能力次第だと思う

2017/10/29(日) 18:26:51.08

ヘッダファイルに型定義して、実装をCPPに書くのってどうかなーと思う。特に組み込み
だとファイルを分ける意味がわからない。分けるとクラスのイメージが掴みにくい気がする。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd33-+nyC) · 2017/10/29(日) 18:28:45.31

>>307
コンパイル時間短縮とか中身の隠蔽とかしたいなら、ソースとヘッダーを分けてもいいんじゃね？

2017/10/29(日) 18:58:48.05

>>307
その定義した型を他のファイルから使う時はどうするのさ？
単一のファイルしか使ってないなら分ける必要はないけど

2017/10/29(日) 19:08:11.02

クラスってのは型の定義なんだから、使う時は全部インクルードではだめなの？
例えば
clsAAA.h
clsBBB.h
...
clsXXX.h

main.cpp
の中で
include "cls\clsAAA.h"
include "cls\clsBBB.h"
....
include "cls\clsXXX.h"

2017/10/29(日) 19:13:52.28

>コンパイル時間短縮とか中身の隠蔽とかしたいなら、ソースとヘッダーを分けてもいいんじゃね？
100個くらいクラスがあってもどってことないと思うが、、、ロード時間が問題になるんだったら
clsディレクトリにクラスファイルを入れて
prtディレクトリにメソッドを実装しない型だけ抜き出したのを入れといて、xxx.prtをインクルードする
方がいいと思う。

2017/10/29(日) 19:15:39.48

prtは自動生成できるって前提だｙ。

2017/10/29(日) 19:18:10.19

やっぱりメッソドがデータなんかと分離するのはわかり難い。他のオブジェクト指向のコンパイラでもそんなことはしないしね。

2017/10/29(日) 19:21:46.87

ヘッダだけだと循環参照起きるし、循環参照起きるところだけcppってのも気持ち悪い

2017/10/29(日) 19:34:33.73

>>313
分けなきゃいけないことはない
分けた方が効率が良い（場合が多い）というだけだから
理解した上で敢えて分けないならそれはそれで好きにすれば良い

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd33-+nyC) · 2017/10/29(日) 19:36:43.09

>>314
inlineキーワード使って定義もヘッダーに書いちゃえば？

2017/10/29(日) 20:07:38.66

>>307
> ヘッダファイルに型定義して、実装をCPPに書くのってどうかなーと思う。

>>310
> クラスってのは型の定義なんだから、使う時は全部インクルードではだめなの？

いったい何をどうしたいのかさっぱりわからん

2017/10/29(日) 20:13:48.53

>314
前方宣言でいいのでは？
そういうのは特殊な場合だけだから

2017/10/29(日) 22:07:47.02

>>318
class Aからclass Bのメソッドを呼んで
class Bからclass Aのメソッドを呼ぶ場合前方宣言だけでは無理なはず

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd33-+nyC) · 2017/10/29(日) 22:10:20.28

>>319
宣言を両方最初に書いておき、定義を後に書く。

2017/10/29(日) 22:21:25.90

>>320
class Aとclass Bが同じファイルで定義されてるならいいかもしれないけど、そうじゃない場合のほうが多いでしょ

2017/10/29(日) 22:40:54.16

いづれにしてもメソッドをばらして別ファイルに書くほうが良いという根拠にはならんだろ。

2017/10/29(日) 22:52:18.92

一部分けなきゃできないところがあるから全部分けるだけで、できるならc#とかみたいに全部一つのファイルに書きたい

2017/10/29(日) 23:53:27.12

それだとクラスが縦に長くなって範囲がぱっと見わからなる
１クラス１ファイルの場合はいいけどさ

2017/10/30(月) 01:18:16.05

てかコードの利用者はヘッダしか見ねーんだから普通に分けとけよ

2017/10/30(月) 03:59:29.97

>323
できないところってどんなところ？　C#にできてC++にできないなんてどういうことか意味わからん。
ｃｌｓ：：とか邪魔くさい。悪しき慣習だろ。あまりにばかげてるからC#では止めにしただけでしょ。

2017/10/30(月) 05:31:15.27

>>323
一部だけ分けりゃいいじゃん
それとシングルソースにしちまうと分担がしにくいだろ

2017/10/30(月) 09:03:26.26

>>327
ヘッダとソースを分けないでって意味でシングルソースってことではないと思うぞ

2017/10/30(月) 10:19:54.36

モジュールについては検討中みたいだからそのうち仕様に入るんじゃね？
コンセプト並みのビッグトピックだからどんどん後ろ倒しされそうな気もするけど。

2017/10/30(月) 22:49:10.56

vector<shared_ptr<T>>を使う場合、
shared_ptrから自分自身のvector上のindexを取得するにはvector要素を1つずつ走査していくしかないんかね？

vector[0]のアドレスをうまく引き算すればうまくいくかと思いきや、
shared_ptr自体は同じアドレスを持つインスタンスがvectorに格納されているわけでないのでうまく行かんのです

2017/10/30(月) 23:15:50.92

>>330
基本的には無理。

何らかの基準でソート状態を保たせていれば、バイナリサーチ系の処理（lower_boundとか）が使えるので、必ずしも一個づつチェックする必要は無い。

2017/10/31(火) 01:31:02.70

もしindexが変わらんのであれば別にmap<shared_ptr<T>, int>持つとか
Tにindex持たせるとか

2017/10/31(火) 06:49:36.25

cppで作ったライブラリ(.a)をcに取り込むときって何か注意いる？

cppには公開apiを１つ用意して、そのなかでクラスを作って計算させようとしてる

2017/10/31(火) 08:34:02.64

>>333
その公開apiをextern "C"するのを忘れない事。

2017/10/31(火) 09:33:49.44

extern "C" しとかないと大抵はリンクの段階で失敗してくれるから、そんなにおかしなことにもならないだろうけどね。
あとは C++ 側で作ったライブラリから例外が送出されると C 側を通過できなくてクラッシュする環境がある。

2017/10/31(火) 11:08:02.92

>>300
やり方しだいジャネーノ？C++推奨しないが、スタックが～ ramが～っていうなら自分で管理するか、newに任せるにして実験すればいいんじゃね？
#include <stdio.h>
#include <string.h>
char buf_hige[1000];
class Hoge {
private: char *m_pBuf; int m_size, m_IsNew;
public:
Hoge(char *p, int s) { m_size = s; m_pBuf = p; m_IsNew = 0; }
Hoge() : m_size(100) { m_pBuf = new char[m_size]; m_IsNew = 1; }
~Hoge() { if (m_IsNew) { delete[]m_pBuf; printf("~Hoge()自動削除\n"); } else printf("~Hoge()\n"); }
void zero() { memset(m_pBuf, 0, m_size); }
void show() { printf("アドレス %p size %d\n", m_pBuf, m_size); }
};
void main() {
char buf_hoge[200];
Hoge a(buf_hige, sizeof(buf_hige));// 自分でメモリー割り当ててクラスを使う普通は ram.. #pragmaとかで移動できる？
Hoge b(buf_hoge, sizeof(buf_hoge));// 自分でメモリー割り当ててクラスを使う mainのstack
Hoge c;// 内部でnew/deleteして動的に使う ram
a.zero(); b.zero(); c.zero(); a.show(); b.show(); c.show();
}

2017/10/31(火) 14:04:56.90

普通の opereter new 定義するだけじゃ駄目なの？

2017/10/31(火) 15:27:26.38

その例なら m_pBuf とか m_size とか m_isNew がどこに置かれるかって話してるんだよ

2017/10/31(火) 15:50:52.40

>>300
リンカスクリプトで定義できるんじゃねーの

2017/10/31(火) 20:31:59.83

>>331
>>332
返信thx
やっぱむりかー。index持たせる方向で検討します

2017/11/01(水) 09:45:22.08

>>338
リンカーでMAP指定して確認したらいいんじゃねーの？アドレスわかるだろ？

2017/11/01(水) 23:49:32.94

共用体って使い道あるの？
素人目からしたら役に立つようには到底思えない

2017/11/02(木) 00:33:40.96

使わずに済むならそれにこしたことはないだろうけど、
部分的に動的型みたいにしたいときは有るよ。
yacc が生成するコードに出てきたりする。

2017/11/02(木) 01:14:44.84

>>342
例えば通信パケットとかで必ず固定長だけど、複数の箇所のコマンドとか意味とかのコードで
内容がコロコロ変わる様な時は便利かも知れない？
それぞれの構造体にキャストしろよって言いたくもなるけど、
複数の人で開発してると通信パケットの内容とかで下らない不具合出したくないから
１つのヘッダで全部規定したりって事はあったな

2017/11/02(木) 01:35:58.84

あ、後H8開発してた時とか、メモリマップドIOとかがモードでコロコロ意味変わる時、
１バイトのデータになったりビットフィールドになったりなとことかがunionになってた

2017/11/02(木) 04:56:03.82

union RGBA{
struct {R:5,G:5,B:5,A:1};
std::uint16_t Colors;
};
こんな感じのことするけど。たまに。

2017/11/02(木) 04:57:25.31

あ、片宣言抜けてた。
たまにしか使わないからなぁ。
struct {std::uint16_t R:5,G:5,B:5,A:1};

2017/11/02(木) 09:40:30.47

union { double d; int i; char c;} u;
は1番大きな要素、この場合は double d のサイズと
メモリアライメントを持つというのが union の重要な機能
これのおかげで非ワード境界からワードを読もうとするようなコードを避けられる

2017/11/02(木) 21:55:55.26

#pragma data_seg
でdllの共有領域を作ってるんですけど

ここにクラスのインスタンスを置いておくことはできますか？

2017/11/02(木) 22:11:01.00

コンストラクタのない、構造体にメンバ関数付いただけのクラスのインスタンスなら大丈夫じゃないかな。
動的にメモリをアロケーションするクラスではアロケーションしたメモリは共有されないので注意。

2017/11/02(木) 22:11:46.90

↑
共有されないってのは「プロセス間で」ということね

2017/11/02(木) 23:18:08.17

>>348
『プログラミング言語C』のmalloc()の実装例のやつで見た

2017/11/03(金) 00:39:07.86

共用体は、パリティチェックで使う

あるサイズの内容を、ある方法で計算して、データが破壊・改変されていないか。
通信データが正しいかどうか

2017/11/03(金) 01:31:20.38

>>349
確保済みのメモリブロックに対してのobject new 演算子ってのが
あるはず

2017/11/03(金) 07:14:49.06

境界調整はalignasでできるようになった

2017/11/03(金) 18:27:07.09

string::format()マダァー？
<<は失敗だったって早く認めようぜ

2017/11/03(金) 21:32:49.68

printf()系関数とstring::c_str()（ていうかbasic_string<T>::c_str()）があるから無問題

2017/11/03(金) 21:34:26.06

入力はscanf()系とか使うとCの経験が長いプログラマーには軽蔑の眼差しで見られるが
cinとかより速くて使い勝手も良いのだから仕方が無い

2017/11/03(金) 21:46:14.60

boost::format よく使ってる

2017/11/03(金) 23:08:11.68

可変テンプレート使えるんならprintfにクラス喰わせたりすることぐらいできるだろ

2017/11/04(土) 00:02:18.18

snprintfじゃstringstreamの代わりとしては役者不足だろ

2017/11/04(土) 07:27:21.97

「役者不足」は造語なんで使わないほうが無難

2017/11/04(土) 09:25:02.17

>>362
しかも「役不足」じゃあ、「役より実力が遥かに高い」の意味だしね。

2017/11/04(土) 12:54:53.20

「力不足」な

2017/11/04(土) 14:09:16.93

>>361
全然ｗｗｗｗｗｗｗｗｗｗｗ
自作クラスのシリアライズ/デシリアライズの下請け関数として使う分には
機能上全く困らない上に速いのだから

で、シリアライズ/デシリアライズおあ
void ISeriarizable::seriarize(FILE* fp)とvoid ISeriarizable::deseriarize(FILE* fp)
にして「<<」や「>>」のオーバーロードみたいな変態じみたことはせずに同等の柔軟性を確保できる
　　

2017/11/04(土) 14:29:00.75

設計が古いな。

2017/11/04(土) 15:30:32.32

cin,cout って組み込みで使えるんかい？
何処をどう書き換えるとそうなるん？

2017/11/04(土) 15:34:07.08

string s1("foo");
const char *p = NULL;
p = s1.c_str();
cout << p << endl;
return 0;
？？？？
cout << s1<<endl; じゃダメなん？

2017/11/04(土) 22:22:05.63

Coutを実験してみたがコードがバカでかくなるので駄目だな。組み込みでは使えない。

2017/11/04(土) 22:34:50.04

>>369
組み込みで何をやりたいのか知らんけど普通coutを書き換えるだろ

2017/11/04(土) 22:37:40.26

組み込みに使うなら実験とかじゃなくちゃんとどんなコードか把握しろよw怖いわ

2017/11/04(土) 22:57:54.30

そもそも組み込みの標準入出力がどんなもんなのかすら想像できないｗ

2017/11/04(土) 23:37:09.27

組み込みでは使えないなんていう次元ならそもそも標準ライブラリ使わないだろ

2017/11/05(日) 00:56:53.05

デバッグ担当「なぁ？なんかログにアホとかハゲとかあるんだけどナニコレ？オレの事おちょくってんじゃねーだろうなぁ？！あ！！！！」

2017/11/05(日) 05:24:49.90

streamの変更ムズいんだけど。
入力だとstreambufのunderflow実装すると思うけど、エラー発生したときどうやってistreamに通知すんの？

2017/11/05(日) 06:18:13.15

struct　lock＿interrupt　｛
　lock＿interrupt（）　：　masked（get＿imask＿ccr（））　｛　
set＿imask＿ccr（1）；　
　｝
　～lock＿interrupt（）　｛　
set＿imask＿ccr（masked）；　
　｝
　bool　masked；
｝；

　／／　in　some　function．．．　
　lock＿interrupt　lk；　
　／／　do　critical　action，　lets　forget　unmask　interrupt　flag！
｝　

このコード　lock＿interrupt（）　：　masked（get＿imask＿ccr（））　｛　
ここの部分の”：”ってどういう意味なの？
何となくコンストラクタとディストラクタがせっとになってるだろうなー
だから”｝”に出会うと自動的にディストラクトされるコードだろうか？
ってくらいしかわからないレベルだから、、、、是非ともこのコードを
使い倒してみたい。

2017/11/05(日) 06:23:01.44

メンバイニシャライザでググれ
てか初等文法くらい勉強しろよ

2017/11/05(日) 06:27:09.42

＞組み込みで何をやりたいのか知らんけど普通coutを書き換えるだろ

ん？
普通はcoutを使わないという意味だろうか？　それなら同意する。
#include <iostream>
を追加しただけで256kbyteを超えてしまう。これではマイコンじゃ使えないな。
もちろんcoutが使えないって意味だよ。使えないなら書き換える？　まあそれは
むりだな。なぜなら書き換える場合でもiostramをインクルードするひつようがあるからね。

つまり書き換えなんてできない。つまり使えないし使わない。すなわち結論としては
Cのsprintfを使うってのが順当かと思う。

2017/11/05(日) 06:30:56.15

>>376
あとついでにクラス全体を説明すると、コンストラクタで割り込みをマスクして
デストラクタで元に戻している。
こんな感じで使う

void foo () {
lock_intterupt lock; // 以下割り込み禁止
if (...) {
....
return;
}
.....
return;
}
割り込み禁止を解除するコードを書き忘れたり複数書いたりせずに済む。

2017/11/05(日) 06:35:39.18

＞メンバイニシャライザでググれ
キーワードありがとう。
ググってみた。メンバーイニシャライザってことはわかったんだがなんか特殊だな
masked = get_imask_ccr();
こういうことか？　なるほど。