はきだめC/C++下級者の質問箱

// >>950
#include <iostream>
#include <string>
int main()
{
std::string foo = "bar";
std::cout << foo;
return 0;
}

>>950
ポインタ取っ払って直接インスタンス持つ様にできる状況を考えてみれ。
new してるってことは動的にメモリを確保してるってことで、それに用が無いなら、new も delete も必要ない。

class A {
int dummyMember;
public:
A():
dummyMember(0)
{}
~A(){}
};

class B {
A a0;
A a1;
A array[10];
public:
B(){}
~B(){}
}

int main(int argc, char* argv) {
A instanceA;
B instanceB;
return 0;
}

上のコードでは、instanceAもinstanceBもスタック上に作られてるからnewはいらない。
クラスBの中身の a0, a1, array[] は、Bの中に含まれている。個別にnewする必要はない。
instanceAもinstanceBもreturnで抜ける際に勝手にそれぞれのデストラクタが呼び出される。
当然deleteもいらない。

>>953
スタック上につくられてるからnewはいらないというのは、おかしな説明だな。

まあ…そうだね。

ていうかまあ、>>949でFAなんだよな。
すまんかった。

いろんなソースコードを読んで勉強したいんですが、
C/C++版のcpanみたいなサイトご存じないでしょうか。

sourceforge
google code

>>957
ありがとー。
さっそく見てみます。

構造体のワードアライメントって未だに考慮しないとならないんだな。
ちょっといじってサイズが4分の1になってびっくりした。
そろそろ自動で解決してくれよと思う。

>>959
「ちょっといじって」が何のことかわからんが、大抵の場合は
規格に従う限り無理だろう。

BYTE、DWORD、char、LONG、BYTE･･･みたいな感じに並んでた
BYTE、char、boolなどを全部前方にまとめてみただけだけ。
詳しい規格は知らないけど単に２パスしてくれれば
いいような気もするが難しいのかな？

構造体は「集合」じゃないんですが。

構造体の順番勝手に変えられたらまずいだろ。

packしろ

>>961
既にメンバの並び順に依存した規定が標準として定められてしまっている。
互換性を考えると無理。

昔は並び替えちまうコンパイラもあったような…
まあ、今は昔の話だ罠

コンパイラ依存で #pragma 使ってサポートできなくはないだろうね。

windowsで、ファイルのコピーするときですが、
コピーしている途中のデータにアクセスして、
リアルタイムでその容量を知ることってできますか？

その容量がわかると、
・現在何M中何Mです。
とか、速度を計算して
・後何秒で終わります
とかできそうなんですが。

よろしくお願いします。

>>968
エクスプローラを見ていれば判ることですが、殆ど意味がありません。
そもそも、「書き込み中のファイル」は検出できるかもしれませんが
「読み込み中のファイル」を検出できないので無理です。

>>968 CopyFileEx

>>969
恥ずかしすぎる

>>969
>>970
ありがとうございます。
ネットの環境がなかったのでお礼遅れました。

CopyFileExで検索したら、msdnのページの
詳しい解説が出てきました。

質問ばかりで申し訳なんですが、疑問が出てきました。
自前でこういう関数は作れるんでしょうか？
「コピー中のファイルを検出して1秒ごとに表示」
というサンプル作ってみたんですが、
コピー中のファイル検出できましたが、
容量は毎回同じ"全部の容量"しか表示されませんでした。

たとえば、ファイル形式の変更（gif->jpgなど）、圧縮
符号化などのソフトをみると、作成中のファイルの容量を調べて
処理過程を表示させているような気がしてます。
よろしくお願いします。

気がするだけ

たぶん、自前で作れると思うけど、君には無理なんじゃないかな？

俺も興味ある。
符号化先のリアルタイムの容量って
知ることできないの？

コピーしてる途中のファイルをdirコマンドで
見たら全部の容量が表示されたんだが。

処理系経過って普通のアプリについてるもんだから
スキルいらんと思うだが。
そういう俺はスキルないけどな！

他のアプリがコピー中のファイルの、処理済み容量を知ることはできないと思うが。
OSによっては、ディスクに書き出した時点でファイルサイズが決まるから経過は見えるけどバッファサイズ単位でしか増えないし。

for (i = 0; i < 100; i++) {
fread(buf, filesize / 100);
fwrite(buf)
printf("%d %%\n", i + 1);
}

>>977
ありがとうございます。
freadってこういう風につかえるんですね。
調べて書いてみます。

↓「>977のソースがコンパイルできません」かな?w

>>978
実際に作るなら、100分割とかにはしないで、最小コピーサイズで分割しろ。
1MBごととか、4MBごととかな。512bytesの倍数にしろよ。

>>980
なんで?
バッファリングされているから何の意味もないと思うのだけど。

>>981
何によってバッファリングされ、そしてそのサイズはいくつ？

>>981
あれ？俺何に突っ込まれてる？
512の倍数にしろってとこかな？

>>983
言ってること全体だと思われ。
そんなんに気を回さなきゃならんくらいなら、ファイルストリームの意味無いじゃんよう。

>>984
そうかなー？CopyFileに肉薄するためには、何かを考えないといけないと思うんだけど。
小さく分けても、HDDの読み書き速度が20〜60MB/sだから意味ないし、
大きくしすぎても、メモリを圧迫する可能性があるし。
どこかに妥当な「最小コピーサイズ」があるとは思わない？

そりゃチューンの話で、もっと言えば実装依存の話じゃないか。
妥当な最小コピーサイズは確かにあるだろうし、
具体的な数字の目処もある程度予想は着けられるかもしれないが、
アプローチの方向は根本的に間違ってるかと思われ。

それ以前の問題で>>977のfilesize/100は高確率で100バイトずれるバグをはらんでるはずだから
そのままじゃ受け入れられないけどさ…。

>>986
そう？FFCのアプローチはそうだよ？

FFCでググったらフットサルチームしか引っかかってきませんでした。
俺の負けでいいです。

Fire File Copy

…根本的に齟齬があることがわかりました。
ちゃんとチューンするなら、そりゃマストのアプローチです。
でもそれならfreadとかfwriteとか使わない。
俺はそう申し上げたかった。

バッファのサイズを考えることは、単にチューン目的だけじゃなくて、
アーキテクチャの面もあると思うんだけど、話したくなさそうなのでもういい。

何でそこにアーキテクチャが顔を出すのかは正直理解が及ばないけど、とりあえずお疲れ様でした。

>>992
OSのファイルキャッシュを汚染する/しないとか、HDDのシークを減らすとか、
ヒープを取り過ぎないようにするとか。
これらってアーキテクチャだと思うんですが、どうでもいいです。

>>993
どうでもいいならレスすんな、馬鹿

>>993
それは全然アーキテクチャじゃないと思われ…
アーキ語るなら、せめて内側のことと外側のことは分けて考えようぜ
な？

なぜかここでFCB

>>995
アーキテクチャでしょ

次スレ：はきだめC/C++下級者の質問箱 2
http://pc8.2ch.net/test/read.cgi/tech/1156206091/

それがはきだめクオリティ

踏み台

@

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。