C言語なら俺に聞け 146
■ このスレッドは過去ログ倉庫に格納されています
>>176
> Java11
なんだそりゃ？と思って調べてみたら、なるほど酷いことになっている。
171,173は技術面での話で、政治的にはかなり深刻だなこれは。 言うほどひどい変更か？
RHEEとCentOSと同じだろ >>178
Windowsの場合はこことか読めばわかるんじゃないかな。
http://blog.fieldnotes.jp/entry/install-openjdk-on-windows
https://qiita.com/ykubota/items/582caa8621a5fc86d0a1
Linux の場合は何も考えなくても最初から入ってるディストリビューション結構あるのではないか?
少なくとも RHEL, CentOS, Ubuntu のような主要なディストリビューションにはある。
なくても yum や apt で追加可能。 しかし Windows のコマンドプロンプトから curl や tar が使えるようになっていたのは知らなかった。
これは良いな。一々余計なアーカイブソフトを後から入れなくても済む。 > 「上質なコードが相当量有る」ことが重要
フォートラン圧勝 printfでなにか文字表示させた場合と何もしない場合で結果が変わることってありますか？ とりあえず、値を取得する系の関数では副作用を起こすような記述はやめような
例えばグローバル変数をいじるとかポインタをいじるとか標準入力・標準出力・ファイル操作するとかはやめろよな
int getValue(int x, int y) {
…
return ○○;
}
こういう関数で printf とかするのは論外
あっ、ちなみに setter でも値の設定だけを行い、標準入力・標準出力・ファイル操作などはするなよ
void setValue(struct MyClass *obj, int x, int y) {
obj->r = x * x + y * y;
obj->theta = atan2(y, x);
}
みたいな感じで とりあえずsetter/getterはクソだな
オブジェクト界最大の汚点だ プログラム言語がサポートしていればそれ程酷いことにはならない
https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%83%91%E3%83%86%E3%82%A3_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0) バッチなのですがスペースの問題にぶち当たってます
素敵仕様って言うんですかね？
フルパスから拡張子を抜いたファイル名を取得したいんですが
%^n1でファイル名を取得しているんですが
ファイル名に全角スペースが入っているため完全なファイル名が取得できなく困っています
""で囲っても取得できないです 全角スペースと半角スペースが混ざっていると取得できるのですがなにかいい方法ありますか？
"D&Dで渡したファイルのパスが欲しい"に拘らなければ、テキストファイルにパスリストを書いて読み込むみたいな外部ファイルを使う方法にするとか
Powershellみたいに.Net Framwork呼ぶとか
もしくはファイル名取得用のコンパイルファイルをかますとか
Google先生以上の回答は出ないでしょうか？ void func(char *const restrict ary)
{
printf("%s\n",ary);
*(ary + 1) = '\0';
printf("%s\n",ary);
}
int main( int argc, char *argv[] )
{
char ary[] = "hoge";
func(ary);
return 0;
} このコードで配列の中身が書き換えられてしまうんですけどなぜですか？
constとrestrictの関係性がいまいちよくわかってないです・・・ スマホでポチポチ入力してたら既に書かれてるけど
>>198-199
とりあえずrestrictは無視するとして
>char *const ary
aryが定数。ary=0はコンパイルエラー。*ary=0はOK
>const char* aryまたは char const* ary
aryの参照先が定数。ary=0はOK、*ary=0はエラー >>198>>199
func() の中の *(any + 1) = '\0' がコンパイルエラーにならない理由は const が any に対するものであって
*any に対するものではないから。そのプログラムの場合 any そのものを変化させる any = NULL や any++
みたいな記述があるとエラーになる。
restrict はコンパイラの最適化に対するヒントで、そのポインタが別のポインタによって指されていないことを
前提とした最適化をして良いことをコンパイラに伝えるためのものだ。伝えられた側のコンパイラはそのような
最適化をやってもいいしやらなくても良い。 >>201
＞スマホでポチポチ入力してたら既に書かれてるけど
どうして、書いている時点でそれがわかるのですか？高性能な専用ブラウザなんでしょうか >>198-199
俺C言語詳しくない素人だけど、
ポインタに const 修飾子をつけるとき、
修飾子の位置によって定数化されるのが「ポインタ」か「ポインタの指す値」かが異なる。
char *const ary の場合はポインタ（アドレス）を書き換え不可。
++ary; は不可
*ary = 'A'; はOK
const char *ary の場合は値（文字列）を書き換え不可。
++ary; はOK
*ary = 'A'; は不可
restrict 修飾子は初めて見たけど、ググった限りは最適化に使うもので、
プログラムの意味は変わらないので無視してよかろう。 >>204
俺なんかゆっくり書いてる間に回答が3つも… ポインタも値もどっちも書き換え不可にするには
const 型* const 変数名;
としないといけなそうだな。 型 const * const 変数名; でも良い。 *const 変数名
って書くより
変数名[ ]
って書く方が好き モノクロA4レーザープリンタが、値段も含めていい感じになっていますね… >>205
>>206
でも一番わかりやすい！
まぁ、よく見る
const char **
の大半は意図した通りに機能してないよな
誰も中み書き換えないから表面化しないけど。。。 >>213
const 修飾子を型指定より前にもってくる書き方は正直いってなじめないですよね 関係ないけれども、今日から「民法」を勉強しはじめました、民法20条まで進みました
こういうのも新鮮でおもしろいなあ、と思いました 民法総則からキチンと基本原理を体型立ててやらないと理解できんぞ >>215
民法94条に到達して手が止まりました
これは難しい…条文は簡潔ですが判例が複雑怪奇でパターン抽出できないでいます
>>216
直に法文文面や判例にアタックしていますが弾き返されていますね…特に判例は裁判官の個性が見える気がします、当初考えていたほど「画一的」ではなかったのです >>219
さあ、適切なスレに移動してそこで10年くらい引きこもっていようか。 配列の中身を一つずつ見て0じゃなかったら0にするみたいなプログラムがあります。
中身を見て代入するか分岐するのと、
投機的に0を代入する方法のどちらが速いのでしょうか >>221
もちろん見ないほうが早い。
memsetで一気に0にするのが最速。
気になるなら測定しましょう。測定しない効率化なんてありえないよ。
それと、こいつを壁に飾っとくべし。
「プログラム最適化の第一法則：最適化するな」 最適化されたらどう書いても memset 使ったのと同じになるかも知れないけどな なんで開発要件も聞かないうちから見ないほうが速いに決まってるって言いきれるの？
0以外が入ってる可能性が低くて、書くより読むのが圧倒的に速いハードだったら責任取れんのかよ！ そんな特殊な環境なら最初からそう書いてくれない限りまともな回答はなくて当然 DRAMは読み書き同じ速度だけど
MRAMとかは書くのが遅いんで
チェックして書くのを最低限にするのが常識になる時代が来るかも >>227
>>224
> 気になるなら測定しましょう。測定しない効率化なんてありえないよ。
> それと、こいつを壁に飾っとくべし。
> 「プログラム最適化の第一法則：最適化するな」 >>227
これおれも思った
圧倒的じゃなくても0率がたかくて書くのが遅ければそう
組み込みならメモリマップでメモリ以外のデバイスがつながってるかも知れないし
あとはコードがそうなってる可能性としては
0じゃない個数を数えるコードを入れやすいようにとか
SFRで書く命令が決まってるとか
キャッシュの関係でなるべく書きたくないとか
C言語スレだからな
組み込みの可能性も当然考えなければ
あと、
条件が整えばmemcpyより速いコードは作れる
アラインメントが事前にわかってるとか
SIMD命令が使える事がわかっているとか
DMAが有効とか 経験の無さ自慢？
特殊なコードに対して特殊な状況を考えられないアホ自慢？ 自分は特殊な状況を考えられる特別な人と思いたいんですね。わかります。 なんとしてでも自分以外をアホということにしておきたい。わかります。 特殊な環境でしか生きられないなら、そこから出てくるなよ 実測が基本で、実測が出来ないなら
一般的な環境を想定してシンプルに記述するのが基本じゃないの Q.ｘｘとｘｘどっちの書き方が速いですか？
A.環境依存 まあ明らかな場合もあるけどね
特定の環境用コードなら実測が基本
でも仕事だと全てのパターンを実測してる暇は無い
そこでプロの勘を使う 大多数に当てはまるならそれでいい派 VS 1例でも当てはまらないならダメ派 今回だけじゃないだろ。
「ｘｘｘでどうなんですか？」
「（基本的な環境では）ｘｘｘだよ」
「いや、xxxxという稀な環境だと当てはまらないからそれは間違いだ！！」
しょっちゅう見かけるわ。 「極稀に当てはまらない場合がある」
↓
「だから気を付けよう」→穏便に話が終わる
「そんなことも知らない（思いつかない）のか！！」→荒れる 極稀な事を思いつく自分は頭が良くて偉いと言いたいのでしょう。仕方のない事です。
彼はこれまでずっと馬鹿にされ蔑まされてきたのですから。このような機会がなければ
うっぷんを晴らすことができません。もしここで人を罵倒する事が出来なければ彼は
益々ストレスを溜め鉈を持って新幹線に乗ってしまうかも知れません。もはや誰でも
良いのです。掲示板でこの程度のやり取りで大事件が防げるのならば安いものです。 「hogeとfugaのどちらが速いのでしょうか？」
「推測するな、計測せよ」
「極稀に当てはまらない場合がある」
「えっ？？？」 まあ>>227の指摘はアリだと思うし>>232辺りまでの対応はまあ普通
要するに>>233が無駄に荒らしてるだけ >>227も、指摘の内容はいいんだけど、責任とれるのかよなんて攻撃的な言い方するのは余計なんだよね。 普通は>>222と>>224で終わりだと思うわ
その先は蛇足 >>221が速さしか考えてないってのがそもそも素人 >>254
そこら辺は各人の取り方だけど無条件に代入が速いとか言ってる>>223-224が部下だったら俺も同じように言うと思う 素人素人と連呼してるやつ
自分が言われて傷ついているんだなｗ
memsetは速いぜ？
逆汗までしなくとも
ベンチマークくらいしてみたか ライブラリや開発環境
使える命令やハード
コア数、キャッシュサイズ、アーキテクチャ
クリアするサイズ
アラインメント
クリアするデバイス
データの出現率
こんなことで最速は変わる
memsetが1バイトずつちまちま代入するようなライブラリも世の中にはたくさんある
小規模組み込みの環境では大抵そう この頃のCPUだと特定の領域を0にする命令自体が最初からあったりしないのかね？ありそうな感じするんだけど。で、最適化されるとmemsetがその命令一つに置き換わって終わり。 >>262
memcpy って言ってるのは一人だけだしあまり賢くないみたいだから無視していいかと 遅くていいならREP STOSD命令
CPUを使わない方法もいくつか
DMAを使ったり
SRAMの場合デバイスリセットで0クリアされたり
FLASHだとイレースコマンドとか
PCでDMAを使う簡単な方法は
GPUのメモリをゼロクリアしておいて転送する >>262
あ、ごめんコピーじゃなくてクリアの間違い >>267
普通は無いだろ
REP STOSDだって単なるループ レジスタからメモリにコピーすると考えれば
コピーでも間違いではないけど >>271
妄想で生きてる奴には何言っても無駄だよ >>221の回答なら
「環境依存、実測しないとわからない」
で終わり というか、高速化しなきゃなやばいかなー と思ったのなら
void SAKUJO(dst,size){ memset(dst,0,size); }
くらいクソ適当に書いておいて、「あとで」 ごちゃごちゃいじればよろしい
それか、>>274のように 事前に済ませておく かだな ま、しかし、よくよく考えてみれば全てを同じ値で埋めておかねばならない状況はあまりないのではないか？
面倒だから一気に全て0にしておいて後から必要な所を埋めるなんてのはよくあるかも知れないが。
そういうのでも calloc() でメモリ確保するなら考える必要ないよな。 誰がどんな意図で書いたかわからないもの
わざわざ変えなくていいよ
問題があるとわかった時点で考えればいい ■ このスレッドは過去ログ倉庫に格納されています
