C言語なら俺に聞け 145
■ このスレッドは過去ログ倉庫に格納されています
Cライクな言語なら何でもこいだわ
（知らないのは新たに勉強せざるを得ないが）
1人で書くのは大抵C++ C++17かなり良くなってきたね
C++98での苦行が嘘のよう オールアセンブラで組んでた人が楽になるための言語。 STLを初めて見た頃は違和感ありありだったけど
それはテンプレートを使うからでも、見た目が悪いからでもなく、中途半端だったから
C++11から以後、そのへんの補完工事が始まったのがありがたい 結局テンプレートって、型をオブジェクト型に統一してしまえばいいだけで、あんまり意味無いよな。 Smalltalk風の継承モデルねえ
正直、俺も昔は盲信したことがあって今は恥じている
テンプレートならコンパイラがやってくれることを
自前でdynamic_castなんかやだよ
nested_exceptionとかは仕方ないけどね >>761
Javaなんかは内部でそうやって実現してるな。 printfの出力をマルチスレッドで行うことはできないのでしょうか
素人的には
スレッド1 printf("abcde");
スレッド2 printf("12345");
↓
出力 a1b23c4de5
となることを考えたのですが、WinAPIのCreateThreadやC++のThreadでも、CPU使用率はシングルスレッドのときと変わらず、出力もこのようにはなりませんでした
Windows VS2017 >>766
排他制御されていないCRTを探す方が難しい。 はじめまして。
大学でプログラミング関係の授業を受けるのですが、それの復習、応用などをrpgツクールmvですることは可能でしょうか？
ちょこっと調べた感じプログラミング要素もあるらしいのですが、c言語はあんまり使わないとかなんとかという記事も見られました。
どうせなら楽しく勉強したいので、ゲームを作りながら学習できないもんですかね...。 >>768
プログラミングを授業で受けるなら、ゲーム制作はツクールMVよりUnityのがいいと思うけど授業内容は進むに連れてむしろツクールMVやUnityのようなのの中身についてになるから復習がてらにはしにくい
モチベ維持にはとても良いと思います バリアント型は何ビットなん？って話になるのがC++。 >>766
目的はどっち？？
文字単位で混ぜたい？
高速化したい？ 同期ってのは、処理が終わるまで帰って来ないって話だ。
下手すっと何秒も帰って来ないから、そこら中が固まる。 数値計算手法の一つである陰解法って陽解法とどう違うんだろう？まったく理解が進まん
陰解法での次ステップの状態を計算するには陽解法と違って次ステップでの値が含まれてる関係で行列の方程式？を解かなければならないらしいけど、その方程式で導く値がどう答えに結びついていくのかがわからない
(最終的にはC言語のプログラムに落とし込みたい。陽解法のプログラムはもう作ってあるんで多少なりとも流用できると楽なんだけどそう簡単にはいかんよね？) 平たく言うと
100秒後の状態を得るのに途中の一つずつを100個全部求めなきゃいけないのが陽解法
10秒ごとの計算を10回、でいいのが陰解法
陰解法はかんたんに未来を得られる分、行列計算が面倒になる これなんですけど、printfのとこの"%2c"で、
" %2c"
" %2c "
など空白を入れることで配列が変わってくるのですが、前に空白と後ろに空白のときの規則性がわかりません。教えて欲しいです。
https://i.imgur.com/QI86not.jpg >>787
質問にある“配列”てのは、画面に出力される結果のことかな?
表示される文字やその順番は同じだけど、文字の間の空白の数が違う、と。
プログラミング界隈では“配列”って言葉は特定の意味を持った専門用語だし、
問題のプログラムはその意味での配列を使ってないから軽く混乱を招くかと。 >>787
%2c の部分は右詰めで幅2文字の指定になるが c なので常に1文字の指定になり
引数の int 型数値は unsigned char に変換されて出力される。つまり %2c の部分
だけでスペース1文字と引数で与えた1文字が出力される。(もちろん端末によっては
引数の値によって1文字の扱いにならないかも知れないが、その辺は説明が長く
なるので省略)。
後はその前後にスペースを付け加えて出すかだけの問題。そのプログラムには
改行がないので全て繋がって出力される。(1回も改行を出力しないままプログラムが
終わるので実行環境によっては出力の後に続けてシェルのプロンプトが出るかも
知れない)。 判りにくい日本語だな
判るものもかえって判らなくなるくらいひどい まず、%2cは必ず「ブランク*」(*は任意の1文字)になる。
その上で整形用のブランクはprintfを分けて、
ブランク以外の文字とかで試してみろ。 Visual BasicとかPerlとかから入った自分としては、
Cのほうが簡単に書ける場面もあれば
VBSやVBAがいい場面もあればPerlがいい場面もあって
要はどの言語でも楽しく書ければそれでええやん >>787
こんなの試してみたら分かったりしない？(\nは改行)
printf("%c\n",'a');
printf("%1c\n",'a');
printf("%2c\n",'a');
printf("%3c\n",'a');
printf("%4c\n",'a');
printf("%5c\n",'a'); 上の写真を見る限りjが増えたタイミングでprintfで改行コード入れてるっぽいけどそれならiのforが終わったタイミングで改行コード入れれば動くんじゃないですか？
なぜiが8までしか回さないのかわからないですが… しょーもない質問ですいません
vs2017で勉強してるど素人なんですが
コードをミスして修正しようとすると文字が上書きされて
文字を挿入できないん時があるんですが、
なぜでしょうか？ >>801
すまんが、どこに改行コードがあるのか、iが8までとは何の事か、
俺にはさっぱり読み取れねぇ
お前とは見えてる世界が違うようだ >>806
この程度読み取れないようじゃエスパーに向いてないよ
> どこに改行コードがあるのか
予想回答「int c=‘ ‘;」って改行コードですよね？
iが増えるたびに改行コードをprintしたいんですよね？
> iが8までとは何の事か
予想回答：すみません、jの間違いです！ C言語でのステートマシンの設計や、上手なコーディングについて
体系的に学べるお勧めの書籍やサイト教えて下さい。 連投で申し訳ないけど
この辺の技術ってC++勉強した方が身に付くのかな？ Cはライブラリが貧弱でほとんど自作しないといけない。
C++はその辺多少マシ。Boostとかあるし。 至極の名言教えてやるぜ。受け売りだけどな。
コードを効率的にしたり、最強の最適化だったりするそれが一番効くのは書かないことだ。
書くと何らかの負荷になる、コードもグチャグチャになる。
必要なことだけ書いて後は流れに任せるのが上達の道。 うーん・・・人によって考え方が違うから正解なんてないし
2chのこのレスだけでは具体的な提示とか難しいよね
本当に必要な処理だけ書いてたら関数長くなって
見通し悪くなったりメンテし辛くなったりしない？ >>810
ない。
>>811
関係ない。
君は本質的な「プログラミングの腕前」を上達させる為に、体系的に学べる物を探しているんだろ？
ならそれは言語には全く関係ないことは分かるだろ。
そして、そんな物は今はない。なぜならプログラミングは今もまだ発展途上だから。
そもそも歴史が浅い。プログラミングには100年ほどの歴史しかないし、
プログラミング作法が学問として成立してからは50年ほどしか経ってない。
だから現在でも試行錯誤中なんだよ。
それは今更C#/C++/Javaがラムダを採用したことからも分かるだろ。
ラムダ自体はLispの昔からあった。
そしてこれらの言語はそれを知っていて不採用としたわけだが、
今更の方向転換＝間違いを認めた、ということなんだよ。
まだそれくらいあやふやなものだって事。
勿論各自が「オレオレ流スーパーハッカー道」を上梓することは出来るのだけど、
実際そういう奴はいないようだ。
とはいえ、結果的に全ての言語が似たり寄ったりになってきているから、
これは成熟してきていることを意味する。
となると、今後は体系化されていくだろうし、そういうサイトや本が現れてきてもおかしくない。
今は>>813みたいな、一言集みたいなのしかないね。
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/ >>816
C++/C#/Java のラムダ式ってラムダ式じゃないと表現できない「何か」を表現する、というよりは、シンタックスシュガーとしてのラムダ式であることが不満です >>818
> ラムダ式じゃないと表現できない「何か」
とは何？
俺の理解では、これは存在しない。ラムダ無しでもチューリング完全だったろ。 >>818
ラムダ式じゃないと表現できない何かって何さ
定義した所の環境を使った第一級オブジェクトなプロシージャではだめなのか？ >>820
すまんが俺はLisp使いではないから、それについては知らない。
ただ、それが本当に役に立つものなら、C++は数年後に採用するだろうね。 >>815
一応言っておくと関数分割も必要なら必要なこととして処理されるべき。
ちなみに関数分割したほうが限度はあるけどキャッシュに乗って早くなる。 この板でチューリング完全て言葉をみるとは思わなかった だいたい、どう抽象化するのがええのかって話でチューリング完全は関係ないからねえ。
前提としてはそうでないとあかんかも知れんけど。 抽象化については「オブジェクト指向」で今のところ決着してるだろ。
これを否定する見解や言語は無いと思うが。 >>820
>>827
お前ら知ってるのならそのメリットを（出来れば具体的に）書いてみてくれないか？
一応Wiki読んだが、
> 明示的に再帰を書かずに再帰を実現する為に用いる事ができる。
> なお、一般にそういった言語では普通に再帰が使えるので、
> プログラミングにおいてはパズル的なテクニック以上の意味は無い。
> https://ja.wikipedia.org/wiki/%E4%B8%8D%E5%8B%95%E7%82%B9%E3%82%B3%E3%83%B3%E3%83%93%E3%83%8D%E3%83%BC%E3%82%BF
なら、いらねえし、採用されることはないと思うが。 >>828
その wikipedia の解説はちょっと本質からはずれている気がする
「明示的な識別子を含まないで再帰関数が記述できる」くらいか
ラムダ表現を採用している、というのなら不動点コンビネータくらいは記述できないといけないのではないか？
いいかえれば不動点コンビネータを表現できないラムダ表現は「何か大事な部分が欠けている」
ラムダ表現は理論的なモデル（計算可能性を論じるなど）として考案されたもので、実用とか効率とかからは遠く離れている
ラムダ表現を売りにする言語（lisp とか)ならともかく、C#/C++/Java のような実用・効率を求める言語で単に「ラムダ表現ができる」「簡潔だ」くらいの理由で採用されるのは、無目的に言語仕様を拡張しているという理由で個人的には不満
さらにはラムダ表現を老害フィルタがわりに使う者もいたりするが、そういうのには賛同しがたい javascriptだとアリって気がするよな。
なぜかは知らんが。まあlisp感あるからか。 javascriptにはなぜかオブジェクト指向が無いからな
コンビネータはC++には早晩実装されそうな気がする C++やJavaはクラスベースのオブジェクト指向言語
JavaScriptはプロトタイプベースのオブジェクト指向言語 >>829
今の仕様で不動点コンビネータが記述できるのかどうかは俺には分からないが、
焦点はその先で、「記述できたら何がうれしいのだ？」なのだと思うよ。
実用言語で重視されるのは当然「実用性」であって、「学術性」ではない。
逆に、実用性皆無なら、当該部分が削除された状態で採用されるべきだ。
例えばC#は意図的にインラインアセンブラを禁止している。
ヘルスバーグのインタビューがググッても出てこないのだが、心は、
「C#のコードならメンテできます」の為の必要知識量を抑えること、だった。
これは長期的に要員確保の難易度を下げ、結果的にメンテ性を上げる。
これも実用言語では重要だよ。
アメリカでPythonを使うのも、Python自体が良い言語だと思っている奴は皆無で、
「Pythonならみんな読めるし書けるから」だからね。
そのコードが10年以上使われることが分かっているのなら、
10年後に要員確保できない可能性がある言語を選択するのは間違いだし。
Cは、（時代的に無理ではあったが）何でもありの状態で、
文法は極めて簡単だが問題は中で何をやっているかで、読んでみなければ分からない。
「Cのコードならメンテできます」とか、簡単に言うのは無理だろ。
C#はイミフなコード構成（大体はCでも警告が出るもの）も禁止されており、
一応、エンジニアが「C#ならメンテできます」と言えることを目指している。
（上手く行っているとは言い難い部分もあるが）
酷い話だが、Javaは10年間全く進歩しないことによってこれを達成してしまっているし。
だから、話を戻すと、
実用言語においては実用性のある機能は取り入れるべきだが、
実用性がない機能は捨てられるべきなんだよ。
(大は小を兼ねる、多めに採用しとけ、ではない。同様に無駄に構文糖が多いのも問題）
今回ラムダが矮小化されて取り込まれているということなら、
取り込まれた部分は必要だと、切り捨てられた部分は不要だと判断されただけ。
勿論今後覆る可能性もあるけどね。 >>833
＞取り込まれた部分は必要だと、切り捨てられた部分は不要だと判断されただけ。
受動的な態度であればそうなるが、あえて私の感覚を述べるとすれば、
ラムダ式を C++/C#/Java（特にC++)に取り込む価値があったのか？
という点、C++ のラムダ式は operator()() で実現できるし、operator()() のシンタックスシュガーと考えてよい
シンタックスシュガーを全否定するわけではない
「ラムダ式」という偉大な名前に反して、実際にできることは一般的な「ラムダ式」のカバーする領域よりも狭くなっているのを「不満」と感じているだけなのかもしれない >>835
> C++ のラムダ式は operator()() で実現できるし、operator()() のシンタックスシュガーと考えてよい
一応それが禿がラムダをC++に採用するのに反対している理由だったと聞いたが、
結果的には折れたんだろ。
昨今は「出来ること」よりも「ソースコードの見やすさ」が重視されているし、妥当だと思うが。
比較すると、
1. そもそも operator()()（ファンクタ）では関数に見えない。これが最大のガン。
2. C/C++は階層記述能力が無く、関数内関数が出来ない。このため、
局所的に関数ポインタを使いたいだけの場合でも上位階層に関数を記述するしかなく、
結果的にその関数は他からも見える（使える）状態になってしまう。
匿名関数であれば、そこでしか使っていない事を文法的に保証できる。
3. ファンクタだとインスタンス変数は必ずコピーすることになる。
ラムダだとおそらく直接掴める場合もあり、この場合はケチれる。
（ただしこれは実装による）
だから関数内関数(クロージャ付き、最低限その階層の変数は見えるもの＝GCC拡張の仕様でいい）があれば、
1,2,3とも達成できるし、要らなかったかな、とも思う。
というか、C/C++とも、関数内関数（階層)は無しで押し切るつもりかよー、とは思う。
ラムダよりこっちの方が必要な気がするのだが。 Cとシェルスクリプトだけで生きていきたいんですが食べていけますか？
またそういった分野らOSSコミッター以外でありますでしょうか？ あるとするなら組込系かな
回路図とアセンブラは出来るの？ 今どき組み込み系もPythonできなきゃやっていけない時代よ >>841
ツール類は一昔前ならPerl/Ruby/TTL(TeraTerm)/VBA、今はPythonが必須だよ ツール類ってなんだよ
組み込みの話をしてるの
機器内部のファームウェア >>843
組み込み系開発者がCソースだけいじってればいいと思ってんのか >>837
そういうことはプログラム板ではなくプログラマ板で聞いてこい 最悪、シーケンサ（PC）でラダー図とアセンブラ触ってりゃ
行けるでしょ。
MELSEC-iQ-RとかはC言語で書く（OSはVxWorks）
ま所詮は他人の人生である Cでさえオーバースペックでアセンブラという場合まである ■ このスレッドは過去ログ倉庫に格納されています
