07/03/24 17:48:28
const PBYTEはBYTE* constになる。
const BYTE* aはaの指す先がconstという意味。
BYTE* const aはaそのものがconstという意味。
それぞれ別の型として扱われるので多重定義できる。
仮引数そのものがconstかどうかは多重定義の解決の際に考慮されないので、
実質的にはA(const BYTE* a)とA(BYTE* a)の中からどちらのAを呼ぶかということになる。
main関数の中のAの呼出では、それぞれaとbの型に引数が最も合うAが選ばれたということ。
755:デフォルトの名無しさん
07/03/24 17:54:04
constなポインタとconstなオブジェクトを指すポインタの違いはこんな感じ
int i;
const int c;
int *const pc;
const int* cp;
pc = &i; //エラー：pcはconstだから
cp = &c; //Ok
*pc = 0; //Ok
*cp = 0; //エラー：cpの指す先はconstだから
756:デフォルトの名無しさん
07/03/24 17:57:58
>>754-755
うぉぉ すごく良くわかりました
> const PBYTEはBYTE* constになる。
これに気づけなかった。感激です
あとﾄﾞﾙｼﾞっょぃ
757:デフォルトの名無しさん
07/03/24 18:15:44
ポインタが絡んだときに、constがどこにつくかってのは、定期的に出るね。
cont BYTE *
だから分かりにくいのであって
BYTE const * //上の型はこれ
BYTE * const
BYTE const * const
そもそもなんで、型の前にも後ろにも付けられるようにしたんだか。
後ろだけだったら、こんなに混乱しなかったはずなのに。
758:デフォルトの名無しさん
07/03/24 18:22:36
>>757
C++の言語仕様は何でもあり
これがすべての混乱の元と言われている
759:デフォルトの名無しさん
07/03/24 18:30:57
結局C/C++は女子供の使うものじゃなかったんだよ。
スキルのもった、何でも自分で出来る現場のおっさんが、好きなように出来るように作られたもの
それが出来ないなら、制限されたC♯で"安全な"プログラムを組めって事さ
760:デフォルトの名無しさん
07/03/24 18:35:28
>>757
URLﾘﾝｸ(www.research.att.com)
761:デフォルトの名無しさん
07/03/24 18:40:16
>>758
これはC++だけではなく、基のCからそうだった。
762:デフォルトの名無しさん
07/03/24 18:50:53
const BYTE *A だったら
(const BYTE)←Aって感じでポインタのAがconst BYTEを指してますよーっ
て感じで直感的かもしれない気がしただけでしたごめんなしあ
763:デフォルトの名無しさん
07/03/24 18:51:13
C++はオブジェクト指向が追加されて更に言語仕様が複雑になった
CはポインタとGOTOを制限すれば構造化プログラミングを
正常に行える。
オブジェクト指向言語でありながらポインタがある。この言語仕様で
自由にプログラマーがコーディングする他人が読めないコードに
なるのはむしろ必然
764:デフォルトの名無しさん
07/03/24 19:14:33
GOTOなんて気持ち悪すぎ
765:デフォルトの名無しさん
07/03/24 22:11:17
>>763
初心者丸出しの発言乙ｗ
766:デフォルトの名無しさん
07/03/24 22:23:51
玄人がするような発言をして下さい↓
767:デフォルトの名無しさん
07/03/24 22:25:49
gotoにも使いどころはあるよ
768:デフォルトの名無しさん
07/03/24 22:28:47
プログラミング規約を行わないでコーディングさせたら
プログラムを複雑にするのは事実
フレームワークを言語に取り入れるのは大規模開発では常識となっている。
世界で活躍するプログラマになると実行速度・コードサイズ・可読性に優れた
コーディングを行っている。
他人が読めないコードは最悪のコーディングスタイルだ
769:デフォルトの名無しさん
07/03/24 22:33:57
実行速度やコードサイズを犠牲にして可読性上げてるんじゃなかったっけ・・・
770:デフォルトの名無しさん
07/03/24 22:38:53
ｴｾ玄人がするような発言をして下さい↓
771:デフォルトの名無しさん
07/03/24 22:40:33
実行速度・コードサイズは最適なアルゴリズムを採用することにより実現
可読性はクラス設計を適切に行い、関数の粒度を均一にすることで実現
更に優秀なプログラマなら再利用可能なプログラム設計も行える。
772:デフォルトの名無しさん
07/03/24 23:05:56
ごめんなさい
どれも出来ません。
773:デフォルトの名無しさん
07/03/24 23:06:22
・最適な
・適切に
・関数の粒度を均一にすること
・優秀なプログラマ
774:デフォルトの名無しさん
07/03/24 23:09:56
goto 使わずにどうやって for の二重ループから脱出するの?
775:デフォルトの名無しさん
07/03/24 23:11:01
フラグ立てんじゃね？
まあ俺はgoto使っちまうがな
776:デフォルトの名無しさん
07/03/24 23:11:45
日本ブレイク工業社歌ばりにブレイクブレイク。
777:デフォルトの名無しさん
07/03/24 23:16:07
最初は素直な実装を心がけてればいいんじゃないかな
778:デフォルトの名無しさん
07/03/24 23:25:07
2重ループを関数に移してreturnするな俺は
779:デフォルトの名無しさん
07/03/24 23:38:25
で、goto 使うななんて発言はどこにも見当たらないんだが…
780:デフォルトの名無しさん
07/03/24 23:44:06
ばっかだなぁ throwがあるじゃないか
781:デフォルトの名無しさん
07/03/24 23:45:14
例外ってgotoよりタチが悪いだろ
782:デフォルトの名無しさん
07/03/25 00:58:07
gotoを全く使ってはいけないのではなく、多用すると可読性が悪くなるから制限が必要
多重ループからの離脱はgoto使うとむしろ可読性が良くなるから使うべきケース
783:デフォルトの名無しさん
07/03/25 01:23:56
try throw catchってやばいのん？
784:デフォルトの名無しさん
07/03/25 01:27:33
>>783
もちろん、ちょーやばい。宇宙並みにヤバイ。お前は絶対使うなよ！ やばいから！
・・・俺は使うけど。
785:デフォルトの名無しさん
07/03/25 02:04:48
例外は"見えないgoto"だとはよくいったものだ。
悪用すると、gotoよりも可読性が悪くなる。
使わなくて済むのなら避けるべき。
786:デフォルトの名無しさん
07/03/25 02:44:48
どの言語でも例外を非ローカル脱出に使うのは推奨されていないなあ…
787:デフォルトの名無しさん
07/03/25 10:25:08
例外って、使う使わないというものじゃなくて
「使わざるを得ない」ものではなかろうか
788:デフォルトの名無しさん
07/03/25 12:41:01
うるさいうるさいうるさい！
789:デフォルトの名無しさん
07/03/25 16:35:02
質問失礼します。
とある関数で、time(NULL)を種として乱数を発生させているのですが、
高速で繰り返し関数を呼び出しているため、同じ乱数が何度も発生してしまいます。
速度を落とさずこれを回避するには、どうすればよいでしょうか？
790:デフォルトの名無しさん
07/03/25 16:36:12
種を与えるのは一回だけでいい
791:デフォルトの名無しさん
07/03/25 18:43:58
循環参照とか循環インクルードとか、
このヘッダインクルードしたらこのヘッダもついてくるから
新しくヘッダつくるかそしたらこのヘッダインクルードしないといけないから
そしたらこのヘッダもついてくるからって
もう嫌になった
792:デフォルトの名無しさん
07/03/25 18:46:20
インクルードガードしろ
793:デフォルトの名無しさん
07/03/25 19:53:17
分割コンパイルするならｲﾝｸﾙｰﾄﾞｶﾞｰﾄﾞ必須だろ、常識的に考えて
794:デフォルトの名無しさん
07/03/25 20:00:55
インクルードガードは本当は良くないんじゃないんですかね。
それはただの対処法ってだけじゃないの？
795:デフォルトの名無しさん
07/03/25 20:04:53
やっぱ#pragma onceで重複処理するだけって駄目なのか・・・
796:デフォルトの名無しさん
07/03/25 20:09:15
>>794
ただの対処法がダメならどうしろとｗ
>>795
そいつぁコンパイラを選ぶんじゃなかったか
797:デフォルトの名無しさん
07/03/25 20:14:56
>>796
基本的に循環しないように分割の設計していかないと駄目だと思うのよね。
それが基本的に本当だと思うのよね。
ヘッダ1000個とかになって人間として難しいって時の対処法でインクルードガードがあるんだと思うんだよね。
798:デフォルトの名無しさん
07/03/25 20:32:57
それはつまり、NULLが定義されているのがstddef.hのみだった場合
stdio.hやstdlib.h内でstddef.hをincludeするのは禁止で、かつ
ユーザーはstdio.hとstdlib.hの両方を使用するコードを書くべきではない
ということですよね？
799:デフォルトの名無しさん
07/03/25 20:46:45
標準ライブラリは重複してもおｋなの？
800:デフォルトの名無しさん
07/03/25 20:48:24
何をもっておｋとしたいのか判らん
オブジェクトコードを1バイトでも軽くしたいとかコンパイルを1秒でも早く終わらせたいとか
そんな目標があるのか？
801:デフォルトの名無しさん
07/03/25 20:51:50
つまり発生する問題はその程度ということですか、ならおｋです
802:デフォルトの名無しさん
07/03/25 21:00:31
>>797
＞基本的に循環しないように分割の設計していかないと駄目だと思うのよね。
＞それが基本的に本当だと思うのよね。
んなこたねーよ馬鹿。循環していなくても
同じ宣言・定義を2回読む危険性はあるだろ。
>>799
標準ライブラリもインクルードガードされているから大丈夫。ソース見れ。
>>800
#include <stdio.h>と何回も書くと
その分だけオブジェクトコードが増えるとでも思ってるのか？
時間は数ミリくらいは遅くなるだろうが。
803:デフォルトの名無しさん
07/03/25 21:11:19
>>802
>>799は>>797理論について標準ライブラリも重複しないようにせにゃならんのかと言ってんじゃね？
804:デフォルトの名無しさん
07/03/25 23:18:38
>>798->>803
バカかお前ら。依存関係の事言ってんだよ
805:デフォルトの名無しさん
07/03/25 23:24:59
>>804 ごめん、よくわからん
806:デフォルトの名無しさん
07/03/25 23:25:03
結局これか
URLﾘﾝｸ(www.kouno.jp)
807:デフォルトの名無しさん
07/03/25 23:28:37
>>804
無能
808:デフォルトの名無しさん
07/03/25 23:34:21
>>806に関連して(このスレの流れには関係ないが)
borlandのコンパイラ及びmakeは、自動的に依存ファイルの更新をチェックする機能がある
(.objのコメントにincludeされたファイルと日付を含め、makeがそれをチェックする)
まあmakeにかかる時間が若干増えるが。
809:デフォルトの名無しさん
07/03/26 00:24:06
>>806
Indian Hill スタイルガイドを策定したヤツは馬鹿ですか？ 信じられん。
一度、#include を入れ子にしてないプログラムのメンテしたことあるけど地獄だったぞ。
810:デフォルトの名無しさん
07/03/26 02:43:27
例えばクラスAを保持しているクラスBとCがあって、それぞれが別々の
.cpp と .h のセットに記述されていた場合とか、
入れ子 #include が禁止だと非常に困る
811:デフォルトの名無しさん
07/03/26 05:27:27
>789
どういう状況かは知らないが、似たような経験がある。
とあるアプリのプラグインを開発していたんだけど、
アプリの仕様上、その機能が使われる度に毎回プラグインがロードされるので
static変数が使いにくいという状況だった。
そのときに色々と調べて見つかった方法が、
・シードをファイル等に書き込んでおく
・プラグインとは別にプロセスを立ち上げ、種を保持しておく
・ミリ秒ではなくマイクロ秒を種に与える
の3つだった。他にもあるかもしれない。
812:デフォルトの名無しさん
07/03/26 16:52:23
Win32APIフックについて教えてください。
ユニットテストでAPI呼出失敗を検証する為、
APIフックを行う必要があります。
いろいろ調べた結果、以下のHPにサンプルがありました。
URLﾘﾝｸ(ruffnex.oc.to)
URLﾘﾝｸ(ruffnex.oc.to)
動作検証した所、フックは成功しました。
しかし、フック状態から元の状態に戻す方法がわかりませんでした。
(プログラムを終了すれば元の状態にもどりますが、そうではなく、任意のタイミングで戻したい)
どのようなコードを書けばよいのか、識者の方ご教授いただけませんでしょうか。
813:デフォルトの名無しさん
07/03/26 16:57:48
そりゃ、自分のプロセスのテーブルを上書きして書き換えてるだけだから。
そこのページに置いてある API_Hook.zip をちゃんと読めば分かるよ。
814:デフォルトの名無しさん
07/03/26 17:03:34
ややすれ違い WindowsAPIべったりな話題だから
ｽﾚﾘﾝｸ(tech板)l50
さらにいうなら親切にBBS用意してるんだからそっちで聞くほうがいいとおもうけどな
さらにいうならもう一個下のサンプルにはちゃんと実装されてるんだから
それぐらい調べてからでも遅くないと思うんだけどな
でもってReplaceIATEntryInAllModsの引数逆転させてみな
815:812
07/03/26 17:40:00
>>813
>>814
レスありがとうございます。
ご指摘の通り、ソースを調べてから質問するべきでした。
また、スレ違いであることも、重ねてお詫びします。
申し訳ありませんでした。
816:デフォルトの名無しさん
07/03/26 18:34:00
Cの質問です。
unsigned int a = 1;
a -= 2;
このとき、aの値がUINT_MAXになることは保障されているのでしょうか？
817:デフォルトの名無しさん
07/03/26 18:42:17
UnsignedIntegerOutOfBoundExceptionがシグナれます
818:デフォルトの名無しさん
07/03/26 18:52:17
>>816
整数オーバーフローが発生した場合の動作は未定義
そもそもUINT_MAX==2^(sizeof unsigned)-1である保証もない
819:816
07/03/26 18:58:34
>>818
分かりました
別の方法を考えてみることにします・・・
レスありがとうございました！
820:デフォルトの名無しさん
07/03/26 19:31:05
>>818
あれ、そうだっけ。
intとかの負数を含む型は、
オーバーフローは未定義だったのは規格で書いてあった覚えあるけど。
unsignedも未定義って書いてたっけ？
確か2^Nで余剰を取った結果になるって書いてたと思うけど。
821:デフォルトの名無しさん
07/03/26 21:09:16
>>816
規格では、符号なし整数の演算結果が範囲外になったときは範囲内に収まるまで
(その型の最大値+1) を足したり引いたりした値になるとされている。 ISO C 6.3.1.3
これにより ((unsigned int)-1) は常に UINT_MAX に等しいと言える。
822:デフォルトの名無しさん
07/03/26 21:19:31
UINT_MAX は-1よりも~0の方が好きだな
単なる好みの問題だけど
823:デフォルトの名無しさん
07/03/26 21:21:05
オーバーフローはバグの原因になるから理解するのはいいけど、
実際にプログラムに組み込むなよｗ
824:デフォルトの名無しさん
07/03/26 21:44:31
>>822
それって保証されてるん？
825:デフォルトの名無しさん
07/03/26 22:00:58
C90/C99ともにただ 0 とだけ書いた場合は (int)0 と等価なので
それを全ビット反転するわけだから -1 になると思うが
826:デフォルトの名無しさん
07/03/26 22:01:46
書き漏らした
int範囲で -1 になると思う
827:デフォルトの名無しさん
07/03/26 22:02:27
負数の表現方法は C の規格外。
828:デフォルトの名無しさん
07/03/26 22:03:45
~0Uだな
829:デフォルトの名無しさん
07/03/26 22:12:28
つまり、-1 が 0x80000001 な環境でも
(unsigned)-1 は 0xFFFFFFFF （が UINT_MAX とする）になるということか。
830:デフォルトの名無しさん
07/03/26 22:15:01
まぁそういうことだよな？
ただの -1 なら 0x80000001 で解釈されるけど
(unsigned)キャスト時はコンパイルでUINT_MAXに置換されるってことなんだろうか
831:デフォルトの名無しさん
07/03/26 23:28:52
VC++ 2005を始めました。
Byte単位でのファイル入出力はできますか？
ビギナー本には書いてないし、ネットでも色々探したのですが…。
ｴﾛい人、方法を教えてくだされ。
832:デフォルトの名無しさん
07/03/26 23:34:42
fread() fwrite()
833:デフォルトの名無しさん
07/03/26 23:36:00
fstream