C++はRustと比較されて安全性に劣るとレッテルを貼られて、どうしたもんか考えあぐねてるところだろうw
言語の拡張に対して完全に方向転換を強いられてるのは間違いない
それはCも一緒だな
パフォーマンスを損なわずにRustと同等の安全性を追加するか、もうこのままそっとしておくかw、の2択だろう
>>674
もはやbetter Cでも何でもないのに、このスレでも繰り返しc++の話題出す奴居るし、やっぱユーザーも被ってるんだろな
まあCの設計の良否を他言語よりは比較的小さな差異から論じるのに有用だとは思う
おれみたいにC++は書かずともcpprefとか読んで式や文、宣言など局所的な構文知識だけちょっとある人は多かろう(ClassとかCに無い概念は読み飛ばしてて無知)
生まれた順序が逆だけど、FortranがC++とすればF言語/JuliaがCだね
大体サブセット+独自進化、標準化コミュニティ丸被り 0679デフォルトの名無しさん (ｽｯｯﾌﾟ Sd02-3rFQ)2024/04/12(金) 16:33:17.52ID:OadUyd3Md
C++は好きじゃないからC言語はもっと改善していって欲しい。
nullptr型とか入るの遅すぎじゃね？
C++はCの機能を保ったまま、ありとあらゆるプログラミングパラダイムを突っ込んだもの
それがベターかどうかは人によるな
ただ、Cと互換性を保ったままそこまで進化したのは奇跡に近い
でも、Rustが安全性と性能は両立出来ることを証明してしまってから、一気に旗色が悪くなったw
今まで性能を免罪符にして、多少(かなり？)の安全性を犠牲にしてきたけど、もはや通用しない時代になった
今後どう進化するか見物だな
Cだって対岸の火事ではない
ちなみに、Rustは安全な代わりに書きたいコードを書けるとは思わない方がいいw
これは書いてみないと分からん感覚だ
書きやすくて安全な言語は存在しないことも証明されたw
0684デフォルトの名無しさん (ﾜｯﾁｮｲ e2ad-ZiZa)2024/04/13(土) 07:18:38.29ID:SxW/5mRR0
慣れの問題では？
必ず遠回りをさせられる感覚は非常にムズムズするよな
あれならgccでstack-protectorとかsanitizeとかガン盛りした方が
気分良く高効率に書けると思った
今日から戯れに数十年前のx86なGUIのソースをx64に移植し始めたんだが
とりあえずエラーになるGetWindowsLongだかをx64用に書き換えていったらそこそこ動いてしまって、後は文字列が関係する処理だけだ
俺が書いた過去のコードがよっぽど優秀だったようだ
やはり若い頃にソースを沢山書いといてよかった
x64化でちょっとsize_tの扱いで躓いたので書いておこう
ポインタが64bitだから、その差を取る場合もあるsize_tも64bitなのは理屈では理解できるんだが
明らかに64bit幅が不要な箇所でsize_tに出くわすとおいおいと思ってしまう
これはbit数を明示した型を別に定義した方がよさそうだ
ああまいったまいった
>>686
Windows1.0のexeもWindows10(32bit版)でも動くからな
64bit版は16bitコードの実行が廃止されたから無理
APIの方は割と変わってるけど、それでもちょっと直せばビルドできる
優秀なのはMicrosoftの方だなw Windows11は最初から32bit版が無いんだよな…
ポインターに64bitも必要ない
36bit(64GB)有れば十分
farとnearポインター復活しても良いよw
win10使ってるけどOffice 97をバイナリコピーして使ってるぞ、とうとう11では動かんのか…？
主にExcel使うが関数の数は劣ってもヘルプは古い方がよく出来てて一般ユーザとしては好み、一々ブラウザ起動されてたらい回しは嫌だ
Office97は32bitだから動くでしょ
駄目なのはWindows3.1までの16bitアプリ
じぶんもフリーソフトをいくつか64bit化したけどほとんど修正してない
早めにUnicodeにしてたおかげもあるかな
あえて使う人もあんまりいないだろうけど、メンテナンスが止まってる(32bit 化、64bit 化されない)ようなソフトを使いたいってことはそれなりにあることじゃないの。
メーカーがつぶれて消えたりするのもよくあることだしな。
0696名無し兎と鰻の大乱闘 (ﾜｯﾁｮｲ dffd-02Vv)2024/04/29(月) 19:42:16.62ID:Yc7GJpMD0
そもそもしーげんごってなに？
アプリは32bitだがインストーラが16bitなのが結構あるらしい
もしもそんなのがあったら、メチャクチャ話題になってると思うよ
0699デフォルトの名無しさん (ﾜｯﾁｮｲ dfad-b946)2024/04/29(月) 22:45:20.14ID:c1TFMEcy0
知り合いにエミュレータ入れたりして凄く苦労してロータス123を動かして業務で使っている人が居る。
使うのに手間はあるとはいえエミュレータが成熟してしまったので
かなり古いソフトウェアを動かしたいならそっちでやれと言えてしまうようになったとも言える。
Windows の互換性維持システムも結局はエミュレータをサブシステムとして
組み込んでるようなもんだしな。
>>697
ファーレントゥーガとかそのパターンだね 0702デフォルトの名無しさん (ﾜｯﾁｮｲ df79-V7Lt)2024/04/30(火) 19:37:21.97ID:6siWZQQV0
なんで16bitの話になったのか理解不能
0703デフォルトの名無しさん (ﾜｯﾁｮｲ dfad-b946)2024/05/01(水) 16:53:57.29ID:udfiR5VM0
プリプロセッサでモジュール作れるようになるとC++使わなくてもCで十分だな
もっと早めにマスターするべきだった
0705デフォルトの名無しさん (ﾜｯﾁｮｲ df79-V7Lt)2024/05/02(木) 23:28:34.67ID:gN+cVuNV0
CでCOMやれって言われても困るし
逆にC++のがマシってのはその程度か
cでもできるってのと、c++使ったほうが楽ってのでは全然意味違う
チームで混乱を招くという理由以外でのc++ディスりは、大抵理解不足によるアレルギーから来るヒスのことが多い
まあ、そういうヒス起こす人が多いからチームでは使用禁止とかになっちゃうわけだから、り繋がってはいるんだけど
>>708
なわけ無いだろ
我慢ができないのはただのガキだぞ >>711
そうやって我慢できずに突っかかってきてるのもどうかと思うけどな… linuxカーネル縛りと趣味以外でc言語使うってどういうプロジェクト？
実際仕事でそういう人いる？
組み込みでも今時c++使えるだろ
0715デフォルトの名無しさん (ﾜｯﾁｮｲ dfac-R43V)2024/05/04(土) 01:40:48.74ID:nSEmjq+y0
メモリ構成が非常に小さいシステムの場合Cじゃない？
8bitのPICとか
こういうの考えたんだけどどうだろう？
実用性無いだろうか
#include <stdio.h>
typedef void (*exception_handler)(void);
void register_exception_handler(exception_handler handler)
{
handler();
}
void exception_occurred()
{
printf("例外が発生しました。\n");
}
void may_throw_exception(int condition)
{
if (condition) {
register_exception_handler(exception_occurred);
}
}
int main()
{
may_throw_exception(1);
return 0;
}
>>716
例外でもなくでもなくて草
Cで例外起こしたいならsetjmp/longjmpでやると決まってる >>716
「こういうの」とは何であるか説明が必要。
提示されたコードは関数 exception_occurred の呼び出しを回りくどくやっているだけで、
途中のメカニズムに意味がない。
(このコードでの使い方の範囲では。)
言葉で説明しづらいならこれが有用になるような使い方の例を示して欲しい。 >>722
C の言語仕様の範囲内でやる方法は setjmp/longjmp のみ。
setjmp/longjmp を自分で書きたいってことなら
アセンブラ (またはインラインアセンブラや intrinsic 関数) を使って
スタックポインタ操作したりレジスタの待避・復旧などをやる必要があるが……。
モダンな処理系だと最適化だのなんだのの都合でスタックフレームを省略したりだとかもあるので
それらと協調しないとまともに動作しない。
たとえば gcc だと setjmp/longjmp の実体は
組み込み関数の __builtin_setjmp/__builtin_longjmp として提供されてる。
処理系自体の機能として持たないとちゃんと動作させられんのだ……。 >>713
九州大学の人工衛星・イザナミ/イザナギは、mruby だから、C 言語
ベンチャーで上場したらしい Windows処理系の場合SEHがあるからsetjmp/longjmpをわざわざ使う事ないよ
というか外部ライブラリ等から例外を受ける場合SEH必須だよ