Cygwin + MinGW + GCC 相談室 Part 8

**デフォルトの名無しさん** · 2025/07/15(火) 23:36:59.18

ここの回答者クズばっかだな
そら初心者こないわ

**デフォルトの名無しさん** · 2025/07/15(火) 23:48:52.15

スレタイの初心者とは言え内容的にはプログラミング熟達者の方が多いから自力解決する事が多いのでは

**デフォルトの名無しさん** · 2025/07/15(火) 23:55:01.09

煽りとかそういうのでなく、純粋に意見として
今は初心者レベルの人はAIに聞いたほうがはるかに有用な答が得られる

**デフォルトの名無しさん** · 2025/07/16(水) 00:05:19.73

次スレ立てるときにはcygwinは控えめで

MSYS2ルート(mingw64-gcc/clang/bash/各種ライブラリ等windowsネイティブポート)
VSCodeルート(msys2導入せずmingw64コンパイラだけ導入)
WSL2ルート
のそれぞれで誰か説明したらwindowsプログラミング初心者(VSは使いたくない人)の助けになるかも

>>975
AIでまとめて貰っても良いかも

**デフォルトの名無しさん** · 2025/07/16(水) 03:12:54.62

TDM-GCC64ってなんなん

**デフォルトの名無しさん** · 2025/07/16(水) 16:55:53.12

>>976
gccの話なら開発環境は全部Linuxで済ませてWindowsはあくまでターゲットのひとつに留めといたほうが簡単で楽なんだけどね
まあこのスレはcygwin/mingwのスレだからそれはスレチか

**デフォルトの名無しさん** · 2025/07/16(水) 18:56:50.02

>>973
Visual Studioが至れり尽くせりなんだけど、それだけだとロックインするからスレタイの環境に興味がある人がいると思う
ただしこのスレではMSYS2以外で導入していろんな墓穴を掘っている傾向がある
とりあえずMSYS2導入(とその後のメンテ)をQiita/Zennで調べたら、初PCゲットしたてのスマホキッズでも躓く事は少ないのでは

マルチプラットフォームアプリ開発等の必要性が出てきたらWSLにすれば良いかと

**デフォルトの名無しさん** · 2025/07/16(水) 19:02:18.06

>>977
それは更新されてないから無視して良いかと

>>979にちょと書いたけど、初期導入以外にも本家gccへの追従更新やサードライブラリ追加導入の事も大切
そこがMSYS2が手頃なので

**デフォルトの名無しさん** · 2025/07/16(水) 19:04:00.62

もちろん「プログラミング熟達者」は好きにしたら良いと思う

**デフォルトの名無しさん** · 2025/08/22(金) 17:08:27.47

Windows用Gitに、msys2由来のコマンド類が結構入ってるけど、
こっちはどれくらい使えるものなのだろう

コンパイラは無い、というのはいいとして、
grep、sed、awkとから辺は入っているから
とりあえずシェルスクリプトでちょっと何かをしたい、と
思った時とかは、Gitについてるコマンド類でも充分なのかな

正直、Windows用GitとCygwin+MinGWを導入していると、
gnu-utilsあたりのコマンドが両方入っているような感じで、
どっちかもう消したいんよね

gitはWindows用Gitの方が都合がよいのでこちらを残すかと
思ってるのだが、なー

**デフォルトの名無しさん** · 2025/08/23(土) 21:23:36.16

>>982
Git for Winのmingw環境は、あくまでもgitのためのものだからな

bash、grepはじめ、UNIX的コマンドをより完全に使いたいのなら、
やはりCwgwin+MinGW+GCCかなと

ただ、Gitをメインに据えたいというのなら、
逆にGitのMinGWにgccとかを入れていくのがよいかなと
コマンドが足りなければその時にまた追加していく、で
それでgit環境がおかしくなったら、涙を拭いて頑張る、になるが

**デフォルトの名無しさん** · 2025/08/24(日) 10:11:40.65

全部入りがいいならMSYS2でいい

**デフォルトの名無しさん** · 2025/08/24(日) 21:06:59.10

msys2で全部入り(随時追加)が良いよ
各ランタイムの開発環境(ucrt64,mingw64,clang64)の合計なんて30GBにも満たない
昨今の(mono)プロジェクト単位の依存関係インストールに比べたら軽いものでは

**デフォルトの名無しさん** · 2025/08/27(水) 03:14:16.66

windowsのパス環境変数取り合いになるからなあ
こういうの
統合してほしい

**デフォルトの名無しさん** · 2025/08/27(水) 05:44:42.72

そう言う疑問はmsys2インストールして環境別のショートカットを見たら直ぐに分かる

**デフォルトの名無しさん** · 2025/10/12(日) 05:50:47.01

>>985
でけーよ…

**デフォルトの名無しさん** · 2025/12/03(水) 11:41:04.56

inline関数を使うときに
VCだと
inline int hoge(int fuga){ 中身 }
で使えるのに
mingw/gccとかだと
static inline int hoge(int fuga){ 中身 }
って描かないと使えない
なんで？
(.cに描くとか.hに描くとかそういうの無関係な話で)

**デフォルトの名無しさん** · 2025/12/03(水) 12:52:21.06

使えるよ
リンカーエラーでも出てる?

**デフォルトの名無しさん** · 2025/12/03(水) 12:55:52.88

あーわかった
>>989 cではなくてc++でコンパイルしな?

**はちみつ餃子** ◆8X2XSCHEME · 2025/12/03(水) 14:09:55.16

>>989
C ではインライン定義は外部定義 (external definition; 要するに普通の実体ある関数) の代替を与えるというルールで、インライン定義自体は外部定義を与えない (作らない)。

呼び出しのほうは実体のある外部定義を呼び出すか代用品であるインライン定義を使うかは未規定。
インライン化用の代用品を使うかもしれないし、実体のある関数を呼び出すかもしれない。
実体のある関数を使う選択をしたときに >>989 の状況では実体のある関数は作られていないから存在しないというリンカエラーになる。
GCC でも最適化オプションを付けてインライン化されてしまったときは (インライン化されたら関数をリンクする必要がないので) エラーにならずにリンクが完了することもある。

以下のように extern 付きの宣言を付けるとインライン関数定義から外部定義の生成を強制できるのでこれで対処することも出来る。

inline void foo(void) {}
extern void foo(void);

int main(void) {
foo();
}

C++ だとインライン関数がもう少し普通の関数と扱いが平等に近づいているので分かり易いんだが……

**デフォルトの名無しさん** · 2025/12/03(水) 22:07:45.02

らしいがこの人も勘違いしてそう
https://zenn.dev/mod_poppo/articles/c-inline-function
https://wocota.hatenadiary.org/entry/20090219/1235058524

**デフォルトの名無しさん** · 2025/12/04(木) 05:43:42.35

.hの方にinlineで
.cの方にexternってことか
気持ち悪いけど納得