C++ 二次元配列の動的生成について
掲題の件、以下のステートメントが紹介されているサイトをよく見かける。
--------------------------------------------------------------------
// 動的生成(smax * slen)
char **s = new char*[smax]
for(int i = 0;i < smax;i++) s[i] = new char[slen];
// 上記ステートメントで動的に生成したメモリ領域の開放
for(int i = 0;i < smax;i++) delete s[i];
delete s;
--------------------------------------------------------------------
しかし、上記ステートメントだと、配列sは厳密には「2次元配列」((smax * slen)個分)としてではなく、
「ポインタの配列」((1次元配列(slen個分)の先頭要素のポインタ)の配列)として作成される。
【根拠】
以下のソースでコンパイル時にエラー「no matching function for call to 【関数名】」となる。
--------------------------------------------------------------------
const int smax = 3;
const int slen = 7;
void print(char x[slen], int n)
{
cout << x[n] << endl;
}
void strcopy(char dst[slen], char src[slen], int i)
{
/* srcの文字列をdstにコピーする */
]
int main()
{
char p[slen] = { ‘First’,’Second’,’Third’ };
// 配列を動的生成
char **s = new char*[smax]
for(int i = 0;i < smax;i++) s[i] = new char[slen];
// 配列に値をコピーする
for(i = 0;i < max;i++) strcopy(s, p, i)
// 配列の中身を画面表示
for(i = 0;i < smax; i++) print(s, i);
// 動的に生成したメモリ領域の開放
for(int i = 0;i < smax;i++) delete s[i];
delete s;
return 0;
}
--------------------------------------------------------------------
2次元配列を仮引数としている関数strcopy()に、動的に生成した配列sが受け渡しが行えないというエラー。
※ 尚、同じ2次元配列pについては、コンパイルでエラーとなっていない。
配列sは2次元配列として作成したつもりだったのだが、
「2次元配列として受け渡しが行えない。」となると、
論理上、配列sは「2次元配列として作成されていない」ように思う。
以下のように動的生成すればOK。
--------------------------------------------------------------------
// 要素がslen個分ある配列を、smax個分動的生成。(smax * slen)
char (*s)[slen]= new char[smax][slen]
// メモリの開放
delete s;
--------------------------------------------------------------------
以下のソースでコンパイルしたところ、正常終了した。
--------------------------------------------------------------------
const int smax = 3;
const int slen = 7;
void print(char x[slen], int n)
{
cout << x[n] << endl;
}
void strcopy(char dst[slen], char src[slen], int i)
{
// srcの文字列をdstにコピーする
]
int main()
{
char p[slen] = { ‘First’,’Second’,’Third’ };
// 配列を動的生成
char (*s)[slen]= new char[smax][slen];
// 配列に値をコピーする
for(i = 0;i < smax; i++) strcopy(s, p, i);
// 配列の中身を画面表示
for(i = 0;i < smax; i++) print(s, i);
// 動的に生成したメモリ領域の開放
delete s;
return 0;
}
--------------------------------------------------------------------
<動作環境>
以上。
walkman
出先等で音楽聞くのにiPod(第四世代)使っていたのだが、
10年以上も使っており、電池切れが早まってきており、パフォーマンスに物足りなさを感じていた。
また、iTunesに保管している音楽データが結構増えてきており、今現在、全ての音楽データをiPodに転送出来なくなった。
そろそろ、新しいポータブル音楽プレーヤーが欲しいと思っていた今日この頃。
Macユーザということで、買い替えるのならiPod Touchとなるのだが、
既にiPhoneを持っており、iPod Touchって「iPhoneの廉価版」というくらいに機能スゲーカブっているのよね。
同じもの2つ持つの嫌だ。
また、既に使っているiPhoneに音楽データ入れて使うのも、、
もし音楽プレーヤーは電源が切れていたも、「あっ、電源切れた。」と思うだけなんだけど、
iPhoneは会社や現場との業務連絡手段で使っているため、電源が切れているのは痛くて、そのへんがすこし違う。
iPhoneに音楽プレーヤーのややがさつな取り扱いを持ち込みたくないため、音楽プレーヤーは別に所持したい。
あれこれ考えましたが、SONYのwalkman(NW-A30)を選びました。
ただ、幾つか気につく点が…
まず、iTunes内の操作でのwalkmanへの音楽データ転送ができないのね。
※ iTunesがwalkmanバイアスが識別出来ないようである。
WindowsだとiTunesの替わりにMedia Goという専用ソフトがあり、
それで音楽データをライブラリに管理したり、walkmanに自動転送する機能が具備されているのだが、
※ まぁ、対応してたとしても、Macユーザなら、音楽データの管理はiTunes使いたい。
じゃどう音楽データを転送するのかというと、
データを転送する機能だけ具備したContent Transferというツールがあって
ただただ、ドラックドロップで手動で転送してくれっていう…。
原始的ですね。(嫌いではないのだがね。)
一応Content Transferにも自動転送機能はあり、「おっ」と思ったのだが、
音楽データを外部HDに保管しており、そのフォルダを指定して転送しようとすると以下のメッセージ。
外部HDを認識してくれないみたい。冷たいねぇ。
結局、手動で音楽データを転送しました。(3253曲 約20GB)
2、3時間かかったよ。
Macをメインで使っているのであれば、iPodシリーズをチョイスするのが無難だったかもしれない。
結構お金払ったし、痛いが、少し教訓にはなったか。
追伸 : 今年もよろしく…
校正と校閲
ある日、とあるジャズバーでマスターや常連客とたわいのない話をしていた中で、「校閲」についての話になった。
※ そういや、今、テレビで校閲をテーマにしたドラマやっているらしいが…。
さてその「校閲」についてだが、それとは別に「校正」というのもあって、「校正」と「校閲」とでは意味が違うとのこと。
・校正
出版物の誤植や体裁上の不備を正す。
出来上がった原稿の1字1句を確認。誤字や脱字、表記のブレ等文字の誤りを修正。
・校閲
原稿に記載されている内容が、事実に則ってるいるものかをを確認、訂正する。
原稿に記載しているメッセージに対し、文献等を元に信頼できる情報を探し、徹底的に事実確認を検証するらしい。
この「校正と校閲」の作業。聞いた分には地味にキツそうだ。(キーキー言いそう。)
この大変さは広く一般になかなか認知されていないが、この「校正と校閲」を行うことで、出来上がりの出版物の品質が格段に違うとのこと。
俺、てっきり「校正と校閲」って同じこと言ってんのかと思っていたよ。アハハ。
いい話聞けたな。
ところで、このような「地味にキツイ」作業。程度の違いこそあれ、どの現場にもあるとは思う。
俺の配属先の現場にも幾つか思い当たるものがあるが、言いたいことがある。
それは、「この「地味にキツイ」作業の存在に向き合わない奴があまりに多すぎる。」ということ。
特に一部の勘違いリーダ各位については、この手の作業をアサインする人間を恣意的に選んで、頭ごなしに丸投げするしな。
以上。
追伸：
このあとそのジャズバーにライブ観にいってきまぁす。
その人来てるといいなぁ。
直電
配属先プロジェクトでは、客先からの問い合わせは等については、
契約上の都合および、作業の管理上の都合により、プロジェクトを統括している会社側で対応する取り決めとしており、
担当レベルとの直接のやりとりはなるべくは避ける取り決めとしている。
しかし、現実には、その統括している会社側で対応しきれなかったりすることもあり、
担当レベルでも客先からの電話での問い合わせ(以下「直電」という。)を受け、対応するケースも多々発生している。
このことについて、個人的には問題ないものと認識している。
ただ、その直電の回数が頻繁で、やりとりに時間がかかったり、また、新たな作業を依頼されることもある。
それが、客先からの依頼ということもあり、本来プロジェクトに必要なものかに関わらず、必然的に優先度が高いのものとなる。
また、客先側の都合で発生するため、作業タスクとしてピックアップおよびマネジメントがとてもしにくい。
すなわち、プロジェクトを進めるにあたって、事前にプランニングされていない作業が最優先で次々割り込まれる格好となる。
そうなるとその客先からの各種対応を優先的に作業することを強いられてしまい、本来の担当作業に対する稼働捻出が難しくなる。
このように「客先からの直電」については、プロジェクト進捗の妨げとなる要因に大化けする可能性を秘めている。(少しオーバーかもしれんけど、こんくらい言っておこう。)
そのようなこともあり、担当レベルは客先からの直電には、なるべく避ける取り決めとしている。
ある日、客先からの電話問い合わせが無条件でこちらに転送されることが少々多く感じたので、
上司にお話ししたら、こんな回答。
「一度電話受けているのであれば、直電ではないんしゃないの?」
はぁ?。バカにしてんのか?。
電話とってそのままこっちにパスすんのって、実質、直電と同意義だろうがよ。
その上司は、所属グループのマネジメントを行っているが、
客先からの直電が、上司が懸念している稼働超過の原因の1つになっているのに、それを問題視していないようだ。
すなわち、その上司の業務(マネジメント)はポーズだけということ。
以前からそのきらいはあったが、少し失望している。
以上。
「あそぶ! ゲーム展」行ってきました。
「あそぶ! ゲーム展」行ってきました。
http://www.skipcity.jp/vm/game/
ゲームセンターCXでも特集やってて、気になっていた。
中に入ると、各種デジタルゲームが展示されており、
オシロスコープをモニタにしてプレイする「テニス・フォー・ツー」や、
デジタルゲーム元祖といわれている「コンピュータースペース」から、
「平安京エイリアン」、「ドンキーコング」等、バラエティに富んている。
ゲームもプレイ可能で、無料で何回でもプレイできる。
※ ただし、マナー上、ゲームのプレイを占有するのはご法度。
ゲームオーバーになったら、他の人に人にゆずってください。
スペースインベーダのブース。テーブル筐体のやつ懐かしい。
昔、上級生がやってんのを見てて、すごく羨ましかった記憶がある。
で、スペースインベーダー久々にプレイしてたけど、感覚鈍ってんのね。すぐにゲームオーバ。
名古屋撃ち披露できず…。
子供よりウキウキしちゃってたよ。間違いなく。
もちろん、ゲーム機が展示されているだけではなく、
デジタルゲームの歴史についてや、技術的にどのような進化を遂げているのかもきちんと解説している。
この展覧会。シリーズで3回行われるとのことで、今回は初回のステージ1。
次のステージに何が展示されるのかとても楽しみだ。
追伸 : 今年もよろしく。
メッセージサービスの矛盾
相手に意図を伝える際、同じ思いを言葉として伝えるにしても、
「話す」のと「書く」のでは、その成り立ち方は異なる。
その証拠に、友人との会話をテープレコーダに録音しておいて、その内容をそのまま文章に起こしてみるとよくわかる。
ほぼ間違いなく支離滅裂な文章が完成する。
「話す」について、「書く」に比べ意図を早めに伝えることが可能で、また、無意識にその即効性を求められる。
その特性上、使われる言葉のついてはその正確性よりも、それを発信するタイミング、スピードが重要だったりする。
また、「話す」において、実際のところ、言葉だけで意図のやり取りをしておらず、
会話する際の身振り手振りや当事者間で置かれている状況等の外的要因が、無意識に有効活用されている。
そのため、言葉が細かいところで意味が誤っていたとしても、
当事者間の頭の中でうまいこと訂正され、適切に意思の通達が行える仕組みとなっている。
よく言われる「話し言葉」とは、あまり時間をかけられずに瞬発性を求められる
「話す」行為において、適した言葉なのだと思う。
それに対し「書く」については、「話す」に比べ、言葉の正確性が求められる。
それは、「書く」手段での当事者間の意思疎通する場合、共有している状況に相違が発生する可能性が高く、
そのことにより「話す」際に無意識に利用していた外的要因を有効活用しにくいためである。
その分、チョイスする言葉に高い精度が求められる。
ただし、「書く」については「話す」に比べ、あまり意思の通達に即効性は求められない。
急いで相手に思いを伝える際、瞬間的に精度の高い文書を記載できるに越したことはないのだが、
その場合はむしろ、無意識に相手に伝える手段を「書く」から「話す」に切り替えているはずだ。
LINE等のメッセージサービスで友達とやりとりしていて、使っていて何か漠然とした違和感を感じることがあった。
それは、メッセージサービスでの相手とのやり取りに、会話するのと同等の瞬発力を求めているのに、
メッセージサービスが許している行為が、それに適した「話す」ではなく、「書く」のみという、
「特性と矛盾したインタフェース」であるということ。
今まで感じていた漠然な思いを、自分なりに結論に導くことができ、なんか、少しスッキリした。
