>>950 else ifを連続してかくとVBの昔のバージョンだときちんと判定されなかったから、
ある程度まではしょうがないんだけどね。
ただ、優良サンプルというほどのもんじゃない。
むしろそこまで行かないようにするテクニックを紹介すべきだと漏れは思う。
あるお客様より、客先製作プログラムの機能追加依頼が来る。
.BASファイル内に、数十個のDBアクセス関数があった。
DBアクセス関数の成功・失敗を示す戻り値が、見事なほどにばらばら…
Func1: 成功の場合 1、 失敗の場合 0
Func2: 成功の場合 0、 失敗の場合 -1
Func1: 成功の場合 0、 失敗の場合 1
Func1: 成功の場合 True、 失敗の場合 False
...
以前どっかのシステムのメンテしたとき、そんなのあったな。
>>953 しかしFunc2以降は・・・コピペ後の編集忘れだよな?
>>952 昔、っていつのバージョンよ。
V2とか言うなよ
>>948 switch 〜 case 文って、コンパイラでクセがあるよな。
組み込みって、命令フェッチが死ぬほど遅かったり。
ROM より早い RAM とか、メモリ上とか、
あるいは直接キャッシュ上とかに展開したり。
僅か数ステップの命令数の違いやらでも、時としては動かなかったり。
>957
case文が少ないと直接分岐命令に展開するけど、
case文の数が増えるとジャンプテーブルにになったりとか。
なんかいろいろあるらしい。
959 :
仕様書無しさん:02/05/16 06:57
>911
>
> char buff[10];
> ……
> strcpy(buff,&buff[2]);
>
> 久しぶりにこんなコーディングを見た。
> 書いたのは馬鹿っ高い金を取るので有名な会社のヤツ。
>
strcpy(buff,buff+2)
と同じで先頭の2文字を詰めてる、普通だと思うが。
>>959 いくらマ板だからって、そりゃないだろ…
オマエはそれを普通だと思うのか!
961 :
仕様書無しさん:02/05/16 07:15
>960
#include <stdio.h>
#include <string.h>
int
main()
{
char buff[10];
strcpy(buff,"XXYYhoge");
puts(buff);
strcpy(buff,&buff[2]);
puts(buff);
strcpy(buff,buff+2);
puts(buff);
}
動くよ。
>>959 そのCソースのアセンブル展開をみないと、動くかどうかわからんだろ
コピー元とコピー先が重なる場合の動作は保証されてるのかされてないのか。
俺はされてないに一票。
964 :
仕様書無しさん:02/05/16 08:29
memcpyとmemmoveがあるのは何故だろう。
以前、ある新人にmemcpyとmemmoveの2つの存在理由を考えてみ、と言ったら
「作った人が違うんじゃないんですか。」とのたまいやがった。
先輩組は笑う気にもなれなかった。(一部の新人組は爆笑してた)
966 :
仕様書無しさん:02/05/16 09:00
まぁ、大抵エイリアスだからどっちでも構わないんだけどね。
967 :
仕様書無しさん:02/05/16 09:32
>>959 って動くんじゃないの?
バカにもわかりやすくおせーてくださいおながいします!
結局は誰も俺なんかには教えてくれないわけか・・・・・
マ板は不親切じゃのう(´┏┓`#)
MSDN読めば?
>971
なぜMSDNなのか教えてください。
C言語の仕様ならC言語の本を読むべきだし、
CPU依存の話ならCPUの解説書を見るべきだとおもう。
コンパイラの動作の詳細ならMSDNに載っているとは思えない。いや、ひょっとしてそーゆー情報もMSDNにあるのかしら?
memcpy、memmoveは関数の仕様であって
CPU依存ではないだろ?
memcpyとmemmoveの動作が違うのがコンパイラのせい?
初耳だな
974 :
仕様書無しさん:02/05/16 12:47
>コピー元とコピー先の文字列が重なり合っているときの
>strcpy 関数の動作は未定義です。
MSDNのも書いておいてあげよう。
MSDNライブラリ Visual Studio 6.0から
解説
memmove 関数は src から dest に count バイト数をコピーします。コピー元とコピー先の領域が一部重なっている場合は、memmove は、重なっている部分の内容をコピーしてから、上書きします。
解説
memcpy 関数は src から dest に count バイト数をコピーします。コピー元とコピー先が重なり合っていると、この関数は、重なっているコピー元のバイトをコピーしてから、上書きするとは限りません。重なり合っている領域を扱うときは memmove 関数を使ってください。
関数の仕様って完全に決まってたのか?
知らん買った。
>>978 いやいや、うちの会社には絶対にきて欲しくないタイプの人だね
そういえば、こういう書き方するやつがいたな。
sprintf( a, "%s%s", a, b );
981 :
仕様書無しさん:02/05/16 18:43
こういうのあった。
char *buf;
char size[1024];
buf = malloc(sizeof(size));
この配列は sizeof でしか使われていない。
別の関数にも、size[] の中身の数字だけ違って同じのがいっぱいあった。
>>978 > 関数の仕様って完全に決まってたのか?
少なくともC言語の標準関数の仕様は決まっている。
君の作った関数の仕様は決まってないかも知れないが
983 :
仕様書無しさん:02/05/16 18:54
char buff[10];の時
strcpy(buff+2,buff);はまずいが
strcpy(buff,buff+2);はいいと思う。
今動くからって理由で本来未定義の動作をあてにすんなよ...
コンパイラ(付属の標準Cライブラリの実装)変わったら一発で意図通り動かなくなる可能性大。
>>983 strcpyが必ず1バイトずつ順番にコピーしてくれるとか決め付けてないか?
>>981 sizeofの使い方を小一時間教えてください。
>>983 後ろからコピーって可能性もあるし。
誰しもプログラムをはじめた頃は
strcpyとかには一度ははまった経験があると思うんだが・・・。
学習能力のないやつが多いのか?
C++とかならStringクラスでも使えばいいじゃん。
なぜそこまで低レベルの処理にこだわる?
990 :
仕様書無しさん:02/05/16 21:26
STRCPY(3) Linux Programmer's Manual STRCPY(3)
名前
strcpy, strncpy - 文字列をコピーする
書式
#include <string.h>
char *strcpy(char *dest, const char *src);
char *strncpy(char *dest, const char *src, size_t n);
説明
strcpy()関数は src(終端文字`\0'を含む)をポインタとする文
字列を destをポインタとする配列にコピーする。二つの文字 列
は重ならない。受け側の文字列であるdestはコピーを受け取るの
に十分な程度に大きくなければならない。
srcのnバイトを越えない数の文字がコピーされるこ と を 除 け
ば、strncpy()関 数も同様である。したがって、もし srcの最初
のnバイトの中にNUL文字が無ければ、コピーの結果としてできる
文字列はNUL終端していないものになる。
src の長さが n よりも少ない場合は、 dest の残りはNULLで埋
められる。
返り値
strcpy()関数とstrncpy()関数は受け側の文字列destへのポイ ン
タを返す。
バグ
strcpy()の受け側の文字列が十分に大きくない場合 (つまり、プ
ログラマが間抜けか不精で、コピーする前にサイズをチェックす
る ことを怠った場合)、何が起こるかわからない。固定長文字列
を溢れさせるのはクラッカーが好むテクニックである。
準拠
SVID 3, POSIX, BSD 4.3, ISO 9899
関連項目
bcopy(3), memccpy(3), memcpy(3), memmove(3)
GNU April 11, 1993 1
991 :
仕様書無しさん:02/05/16 21:27
なるほど、そうか、しかしだな、今まで書いた
コードを考えると、信じたくないぞ!
>>973 おえおえ、そのコンパイラがDMAとか使ってたらどうする?
めったにないとは思うがCPU依存じゃん・・。
>>989 その通りなんだけど、これくらいの事頭の隅に入れとけよ、と言いたい。
Z80でメモリ転送するときにハマった覚えがあるよ〜
次スレあるの?
996 :
仕様書無しさん:02/05/16 22:11
1000
い
while(1){
return 0;
}
1000!!!
1001 :
1001:
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。