m*****n
发帖数: 3575 | 1 能否用CMake替代Visual Studio的劳什子？
学生给我交付的是Visual Studio的一大摊子，里面还加载着用CMake辅助编译的开源库
既然底层都是make
能否用CMake把调用库都分析出来，最后直接用CMakeLIsts.txt完事？
Visual Studio实在是配置过于复杂，而且错误无法排查。 |
p**z
发帖数: 65 | 2 先说明，C++ 不是我日常用语言。
但是应该是可以的，用命令行或者 CMake 简单的 GUI build 的话免费的 toolchain
应该就可以。
https://cmake.org/runningcmake/
如果喜欢 IDE，Jetbrain 的 CLion 似乎是基于 CMake 的 workflow。缺点是试用期过
后不免费，但是老师和学生可以要免费的 license：
https://www.jetbrains.com/clion/ |
h*i
发帖数: 3446 | 3 我最近刚把我的数据库系统datalevin搞得可以在Windows下用。据我有限的知识，
Visual Studio在Windows下应该是不可替代的。除非你完全用gcc那一套，比如mingw来
编译。但这两者是不能混用的，要么用VC编译，要么用mingw编译。
cmake不过是调用VC的东西而已，底层并不是make。所以用cmake你还是得用VC，当然了
，一个CMakeLists.txt应该就够了。
【在 m*****n 的大作中提到】
: 能否用CMake替代Visual Studio的劳什子？
: 学生给我交付的是Visual Studio的一大摊子，里面还加载着用CMake辅助编译的开源库
: 既然底层都是make
: 能否用CMake把调用库都分析出来，最后直接用CMakeLIsts.txt完事？
: Visual Studio实在是配置过于复杂，而且错误无法排查。
|
q***i
发帖数: 627 | 4 应当有完全替代IDE的命令，CMake+命令
不过我已经不记得乐
【在 h*i 的大作中提到】
: 我最近刚把我的数据库系统datalevin搞得可以在Windows下用。据我有限的知识，
: Visual Studio在Windows下应该是不可替代的。除非你完全用gcc那一套，比如mingw来
: 编译。但这两者是不能混用的，要么用VC编译，要么用mingw编译。
: cmake不过是调用VC的东西而已，底层并不是make。所以用cmake你还是得用VC，当然了
: ，一个CMakeLists.txt应该就够了。
|
d****y
发帖数: 312 | 5 用msbuild直接命令行编译solution file不就行了 |
r*****n
发帖数: 1285 | 6 Cmake也得有compiler才能行。
【在 m*****n 的大作中提到】
: 能否用CMake替代Visual Studio的劳什子？
: 学生给我交付的是Visual Studio的一大摊子，里面还加载着用CMake辅助编译的开源库
: 既然底层都是make
: 能否用CMake把调用库都分析出来，最后直接用CMakeLIsts.txt完事？
: Visual Studio实在是配置过于复杂，而且错误无法排查。
|
w***g
发帖数: 5958 | 7 以前有windows sdk, 可以配合cmake直接用，绕过vs.
VS也可以配合cmake用。 |
c*******v
发帖数: 2599 | 8 People are still using the bcc32.exe (Borland compiler).
Official Document:
https://edn.embarcadero.com/article/20997
User example:
https://gitlab.odin.cse.buffalo.edu/bglavic/MayBMS_Mirror/blob/
ff5d7728e633c7416562a871805c4c000f294fd8/postgresql-8.3.3/src/bcc32.mak
【在 w***g 的大作中提到】
: 以前有windows sdk, 可以配合cmake直接用，绕过vs.
: VS也可以配合cmake用。
|
d*******r
发帖数: 3299 | 9 所以写C++确实费神, build就搞死一堆人... |
m*****n
发帖数: 3575 | 10 是这么回事，底层差异的确有
现在开源又多了套CygWin
CMake只是个壳子，生成GCC的Makefile的
然后用GCC的make去编译。
而make就像你说的，要么用mingw要么用cygwin
【在 h*i 的大作中提到】
: 我最近刚把我的数据库系统datalevin搞得可以在Windows下用。据我有限的知识，
: Visual Studio在Windows下应该是不可替代的。除非你完全用gcc那一套，比如mingw来
: 编译。但这两者是不能混用的，要么用VC编译，要么用mingw编译。
: cmake不过是调用VC的东西而已，底层并不是make。所以用cmake你还是得用VC，当然了
: ，一个CMakeLists.txt应该就够了。
|
|
|
m*****n
发帖数: 3575 | 11 你说的solution file是sln吗？
那不本质上和VS还是一回事？
【在 d****y 的大作中提到】
: 用msbuild直接命令行编译solution file不就行了
|
m*****n
发帖数: 3575 | 12 谢谢，我看它好像也调用了sdk
【在 w***g 的大作中提到】
: 以前有windows sdk, 可以配合cmake直接用，绕过vs.
: VS也可以配合cmake用。
|
g****t
发帖数: 31659 | 13 Windows生产用最好的办法可能还是就老老实实visual studio。不然夜长梦多。
未来维护也麻烦。任何work around都可能下一秒被一个msft patch弄坏。
: 所以写C 确实费神, build就搞死一堆人...
【在 d*******r 的大作中提到】
: 所以写C++确实费神, build就搞死一堆人...
|
m*****n
发帖数: 3575 | 14 我去试试，谢谢。
【在 c*******v 的大作中提到】
: People are still using the bcc32.exe (Borland compiler).
: Official Document:
: https://edn.embarcadero.com/article/20997
: User example:
: https://gitlab.odin.cse.buffalo.edu/bglavic/MayBMS_Mirror/blob/
: ff5d7728e633c7416562a871805c4c000f294fd8/postgresql-8.3.3/src/bcc32.mak
|
g****t
发帖数: 31659 | 15 社区太小了。不适合生产。老老实实vs studio算了。
自己用另外一回事。
: 我去试试，谢谢。
【在 m*****n 的大作中提到】
: 我去试试，谢谢。
|
m*****n
发帖数: 3575 | 16 我用的就是老版的VS
学生告诉我必须用老版，新的就不兼容。
感觉一旦微软停止支持老版VS
这个环节就要崩
【在 g****t 的大作中提到】
: Windows生产用最好的办法可能还是就老老实实visual studio。不然夜长梦多。
: 未来维护也麻烦。任何work around都可能下一秒被一个msft patch弄坏。
:
:
: 所以写C 确实费神, build就搞死一堆人...
:
|
i********s
发帖数: 6 | 17 当然可以，一般我是用CMake + Ninja + MS SDK + VisualStudio Communicty Version
，因为这几个都是免费使用的。如果你已经安装了VS专业版或者企业版，就当然更好。
使用CMake需要注意版本兼容的问题，因为很多开源软件使用了比较旧版的CMake，如果
你比较熟悉CMake的policy，很容易修改然后调用开源库的CMake脚本。
【在 m*****n 的大作中提到】
: 能否用CMake替代Visual Studio的劳什子？
: 学生给我交付的是Visual Studio的一大摊子，里面还加载着用CMake辅助编译的开源库
: 既然底层都是make
: 能否用CMake把调用库都分析出来，最后直接用CMakeLIsts.txt完事？
: Visual Studio实在是配置过于复杂，而且错误无法排查。
|
a**a
发帖数: 161 | 18 装个wsl2，windows就全兼容linux了，鱼和熊掌通吃
【在 m*****n 的大作中提到】
: 能否用CMake替代Visual Studio的劳什子？
: 学生给我交付的是Visual Studio的一大摊子，里面还加载着用CMake辅助编译的开源库
: 既然底层都是make
: 能否用CMake把调用库都分析出来，最后直接用CMakeLIsts.txt完事？
: Visual Studio实在是配置过于复杂，而且错误无法排查。
|
m*****n
发帖数: 3575 | 19 有没有这方面的教程，或者博客？
Version
【在 i********s 的大作中提到】
: 当然可以，一般我是用CMake + Ninja + MS SDK + VisualStudio Communicty Version
: ，因为这几个都是免费使用的。如果你已经安装了VS专业版或者企业版，就当然更好。
: 使用CMake需要注意版本兼容的问题，因为很多开源软件使用了比较旧版的CMake，如果
: 你比较熟悉CMake的policy，很容易修改然后调用开源库的CMake脚本。
|
g****t
发帖数: 31659 | 20 除了vs studio一切workaround都可能要付出代价的。
windows cpp不用vs studio，到时候你发现程序因为什么鸟毛windows注册表设置，
或者没有跟从windows特殊写法,程序极慢怎么办？一点点hack各种东西是很痛苦的。而且
deploy也麻烦。windows自己也有版本问题。
此类问题网上很多。远不是profile就能解决干净的。
https://stackoverflow.com/questions/33255393/why-is-this-c-program-slower-on
-windows-than-linux
如果考虑性能和IO，cpp本质上在linux和windows其实不是跨平台可用的。
据我个人经验，golang，java好的多。
【在 m*****n 的大作中提到】
: 有没有这方面的教程，或者博客？
:
: Version
|
|
|
m*****n
发帖数: 3575 | 21 关键是底层的金融模块，人家提供的就是C++的
所以已经尽量简化了，把需要和底层通讯的模块单做一个命令行程序
就这也绕不开Visual C++ 和VS吗？
而且
on
【在 g****t 的大作中提到】
: 除了vs studio一切workaround都可能要付出代价的。
: windows cpp不用vs studio，到时候你发现程序因为什么鸟毛windows注册表设置，
: 或者没有跟从windows特殊写法,程序极慢怎么办？一点点hack各种东西是很痛苦的。而且
: deploy也麻烦。windows自己也有版本问题。
: 此类问题网上很多。远不是profile就能解决干净的。
: https://stackoverflow.com/questions/33255393/why-is-this-c-program-slower-on
: -windows-than-linux
: 如果考虑性能和IO，cpp本质上在linux和windows其实不是跨平台可用的。
: 据我个人经验，golang，java好的多。
|
g****t
发帖数: 31659 | 22 这看你是什么通信了。要我我就用vs studio。
Windows tcp ip 一堆参数都跟Linux不一样。
: 关键是底层的金融模块，人家提供的就是C 的
: 所以已经尽量简化了，把需要和底层通讯的模块单做一个命令行程序
: 就这也绕不开Visual C 和VS吗？
: 而且
: on
【在 m*****n 的大作中提到】
: 关键是底层的金融模块，人家提供的就是C++的
: 所以已经尽量简化了，把需要和底层通讯的模块单做一个命令行程序
: 就这也绕不开Visual C++ 和VS吗？
:
: 而且
: on
|
n******t
发帖数: 4406 | 23 golang和java也是個平臺之間加一層shim，golang的write到了不通的平臺上也就是簡
單轉一下而已。這事情上沒有silver bullet。你要真性能和io你仍然需要分開搞。
windoww下面用mingw性能上沒有問題。VS的優勢主要是要聯機幫助，和開發C#。
而且
on
【在 g****t 的大作中提到】
: 除了vs studio一切workaround都可能要付出代价的。
: windows cpp不用vs studio，到时候你发现程序因为什么鸟毛windows注册表设置，
: 或者没有跟从windows特殊写法,程序极慢怎么办？一点点hack各种东西是很痛苦的。而且
: deploy也麻烦。windows自己也有版本问题。
: 此类问题网上很多。远不是profile就能解决干净的。
: https://stackoverflow.com/questions/33255393/why-is-this-c-program-slower-on
: -windows-than-linux
: 如果考虑性能和IO，cpp本质上在linux和windows其实不是跨平台可用的。
: 据我个人经验，golang，java好的多。
|
c*******v
发帖数: 2599 | 24 mingw也好，其他的办法也好。都可能有性能问题。见我前面列的一个讨论。
此类讨论连续多年都有。之前我也碰到过。只用c89也会碰到且能在windows 10测试出
来。同样的c89程序，mingw可能比linux上慢很多。
总体而言，除非要往windows market卖。严重不推荐在windows用gcc，clang。
MSFT不愧是黑店。
【在 n******t 的大作中提到】
: golang和java也是個平臺之間加一層shim，golang的write到了不通的平臺上也就是簡
: 單轉一下而已。這事情上沒有silver bullet。你要真性能和io你仍然需要分開搞。
: windoww下面用mingw性能上沒有問題。VS的優勢主要是要聯機幫助，和開發C#。
:
: 而且
: on
|
l*********s
发帖数: 5409 | 25 msvc优化更好
【在 n******t 的大作中提到】
: golang和java也是個平臺之間加一層shim，golang的write到了不通的平臺上也就是簡
: 單轉一下而已。這事情上沒有silver bullet。你要真性能和io你仍然需要分開搞。
: windoww下面用mingw性能上沒有問題。VS的優勢主要是要聯機幫助，和開發C#。
:
: 而且
: on
|
n******t
发帖数: 4406 | 26 你爲什麼會覺得同樣一段代碼在OS 1下面用編譯器X比在OS 2下面用編譯器X出來的程序
慢很多，是因爲OS A下你沒有用編譯器Y的？
而且更讓我驚奇的是，你爲啥覺得windows下面程序用那個編譯器的主要因素是性能？
【在 c*******v 的大作中提到】
: mingw也好，其他的办法也好。都可能有性能问题。见我前面列的一个讨论。
: 此类讨论连续多年都有。之前我也碰到过。只用c89也会碰到且能在windows 10测试出
: 来。同样的c89程序，mingw可能比linux上慢很多。
: 总体而言，除非要往windows market卖。严重不推荐在windows用gcc，clang。
: MSFT不愧是黑店。
|
n******t
发帖数: 4406 | 27 問題是windows下面crt的性能根本就不重要啊，最care性能的都直接調win32 api。
不過這都不是最重要的，windows下面的基本上是desktop，很少有壓榨性能的需求。當
然做遊戲另當別論，但是那種一般都會自己有gui的toolkit。
【在 l*********s 的大作中提到】
: msvc优化更好
|
c*******v
发帖数: 2599 | 28 my two cents:
这不是我觉得的。是实际测试出来的。前面不是贴了stackoverflow的讨论么。类似的
讨论有很多。
理论上c89也是windows之编程接口。然而实际问题碰上了很难debug。
最后的办法就是用vs studio，按msft给的提示一点点修。换言之，得重写成mscpp那个
全套的东西。
问题不仅仅在编译器。在于windows对c89标准库的支持有很多问题。总归要用windows
api，sdk，
etc。
换言之，c89的程序在linux系各种版本上都没什么问题。undefined behavior多数都是
约定俗成
，保守点写就可以。windows我是怕了。
在windows下，语法上可以用c89。但是性能出问题很难修。还不如一开始就用ms cpp。
例如redis到今天还没有offical windows版本。目测这件事不容易。
再比如我之前有个处理声音的c程序。放那一直没修好。除非很懂windows的。不然目测
修好则
需要至少3天。我现在还放着没管。
【在 n******t 的大作中提到】
: 你爲什麼會覺得同樣一段代碼在OS 1下面用編譯器X比在OS 2下面用編譯器X出來的程序
: 慢很多，是因爲OS A下你沒有用編譯器Y的？
: 而且更讓我驚奇的是，你爲啥覺得windows下面程序用那個編譯器的主要因素是性能？
|
n******t
发帖数: 4406 | 29 你說這個鏈接和用不用mingw的關係我沒看出來：
https://stackoverflow.com/questions/33255393/why-is-this-c-program-slower-on
-windows-than-linux
這明顯是windows和linux的文件系統性能的差別。
"The code is compiled under GCC for Linux, and Visual Studio for Windows,
but I cannot imagine a universe in which the compiler used should make any
measurable difference to a pure I/O benchmark. The filesystem used in all
cases is NTFS."
他居然認爲這件事是一個pure I/O benchmark，這才是最絕望的地方。
windows
【在 c*******v 的大作中提到】
: my two cents:
: 这不是我觉得的。是实际测试出来的。前面不是贴了stackoverflow的讨论么。类似的
: 讨论有很多。
: 理论上c89也是windows之编程接口。然而实际问题碰上了很难debug。
: 最后的办法就是用vs studio，按msft给的提示一点点修。换言之，得重写成mscpp那个
: 全套的东西。
: 问题不仅仅在编译器。在于windows对c89标准库的支持有很多问题。总归要用windows
: api，sdk，
: etc。
: 换言之，c89的程序在linux系各种版本上都没什么问题。undefined behavior多数都是
|
c*******v
发帖数: 2599 | 30 不一定是文件系统。也可能是windows cache，heap size什么设置什么的问题。
这些我认为msft自己的工具链都处理好了。或者会给提示。但是gcc mingw不包括这些
部分。
windows专家可能能写好gcc mingw。我没这个水平。只能不选这条路了。
on
【在 n******t 的大作中提到】
: 你說這個鏈接和用不用mingw的關係我沒看出來：
: https://stackoverflow.com/questions/33255393/why-is-this-c-program-slower-on
: -windows-than-linux
: 這明顯是windows和linux的文件系統性能的差別。
: "The code is compiled under GCC for Linux, and Visual Studio for Windows,
: but I cannot imagine a universe in which the compiler used should make any
: measurable difference to a pure I/O benchmark. The filesystem used in all
: cases is NTFS."
: 他居然認爲這件事是一個pure I/O benchmark，這才是最絕望的地方。
:
|
|
|
n******t
发帖数: 4406 | 31 如果你在寫一個服務器端的程序，選windows除了你的客戶就是用windows的，沒有任何
意義。Windows不是一個設計成跑服務器的平臺。但是如果你的客戶明確要windows，你
當然應該用原生環境開發，用什麼go和java都是給自己找事。
windows下面從來就沒有真正支持過iso C，但是不重要，在Unix下面只用iso C，這年
頭也已經不行了，你至少得用posix的東西，如果是Linux，你most likely還會用glibc
的東西，這種東西在windows下面就是win32 api.
但是在C這個level上面，mingw+win32api是沒有什麼性能問題的(也沒法有性能問題，
因爲不管你用啥最後都變成了win32api call），而且這個也是gcc在windows下面開發
推薦的做法。注意這個approach是native的，不是可移植的，which我前面說了，總結
成兩點：
1. windows下面開發，如果你是純粹的desktop，性能不重要。這個時候你主要需要考
慮開發速度，界面，兼容，這個時候最好是用C#+VSstudio，不追求用戶體驗可以用qt
，gtk，go這種跨平臺的。
2. 要care性能的，你應該用native的開發環境，如果你有錢有時間上VS，沒錢而且不
想折騰windows開發工具，用mingw+win32api（再強調一次，這個不是portable的
solution，是native solution，窮人的native solution也是native solution)。
windows
【在 c*******v 的大作中提到】
: my two cents:
: 这不是我觉得的。是实际测试出来的。前面不是贴了stackoverflow的讨论么。类似的
: 讨论有很多。
: 理论上c89也是windows之编程接口。然而实际问题碰上了很难debug。
: 最后的办法就是用vs studio，按msft给的提示一点点修。换言之，得重写成mscpp那个
: 全套的东西。
: 问题不仅仅在编译器。在于windows对c89标准库的支持有很多问题。总归要用windows
: api，sdk，
: etc。
: 换言之，c89的程序在linux系各种版本上都没什么问题。undefined behavior多数都是
|
n******t
发帖数: 4406 | 32 windows的文件系統吞吐和linux比就是垃圾。這個從90年代末就是這樣，怎麼調都沒用。
不過這不是重點，重點在於爲什麼他會認爲在一個mount的文件系統上面call libc的
fwrite，測得是pure I/O？考慮到這個人顯然是當前IT從業人員的高級水平，整個行業
的狀況就非常讓人擔憂了。
【在 c*******v 的大作中提到】
: 不一定是文件系统。也可能是windows cache，heap size什么设置什么的问题。
: 这些我认为msft自己的工具链都处理好了。或者会给提示。但是gcc mingw不包括这些
: 部分。
: windows专家可能能写好gcc mingw。我没这个水平。只能不选这条路了。
:
: on
|
r*g
发帖数: 3159 | 33 C++的也分是什么版本的。我用过国内交易所的Api.那是MSC++编译的。示例文档，技术
交流群全是windows based。看你目标要是把程序跑起来干活，还是自己hack做实验,否
则还是不要乱搞了。
【在 m*****n 的大作中提到】
: 关键是底层的金融模块，人家提供的就是C++的
: 所以已经尽量简化了，把需要和底层通讯的模块单做一个命令行程序
: 就这也绕不开Visual C++ 和VS吗？
:
: 而且
: on
|
c*******v
发帖数: 2599 | 34 mingw除了自己的几个东西，用的就是system32目录里面那几个过去vc6/vb6用的c run
time等等一些dll。
所以mingw build出来的exe，在windows 10出问题不奇怪。
因为windows 10更新的时候是不会去照顾过去的dll的。
我的理解：mingw的项目的risk，与vc6/vb6写的程序在windows 10跑相当。
不出问题也就算了，出问题之后肯定要windows专家才能解决。
所以很难认为用mingw,不用msft新的toolchain是划算的。
glibc
【在 n******t 的大作中提到】
: 如果你在寫一個服務器端的程序，選windows除了你的客戶就是用windows的，沒有任何
: 意義。Windows不是一個設計成跑服務器的平臺。但是如果你的客戶明確要windows，你
: 當然應該用原生環境開發，用什麼go和java都是給自己找事。
: windows下面從來就沒有真正支持過iso C，但是不重要，在Unix下面只用iso C，這年
: 頭也已經不行了，你至少得用posix的東西，如果是Linux，你most likely還會用glibc
: 的東西，這種東西在windows下面就是win32 api.
: 但是在C這個level上面，mingw+win32api是沒有什麼性能問題的(也沒法有性能問題，
: 因爲不管你用啥最後都變成了win32api call），而且這個也是gcc在windows下面開發
: 推薦的做法。注意這個approach是native的，不是可移植的，which我前面說了，總結
: 成兩點：
|
n******t
发帖数: 4406 | 35 mingw的runtime也是更新的，不是你說的copy dll。此外，VS一樣要更新crt。
很多open source的windows版本都是用mingw編譯的，並沒有你說的毛病。
至於划算不換算，就是見仁見智了。有人覺得200塊也挺多的，但是沒有200塊的人並不
是不能寫出好程序的。
run
【在 c*******v 的大作中提到】
: mingw除了自己的几个东西，用的就是system32目录里面那几个过去vc6/vb6用的c run
: time等等一些dll。
: 所以mingw build出来的exe，在windows 10出问题不奇怪。
: 因为windows 10更新的时候是不会去照顾过去的dll的。
: 我的理解：mingw的项目的risk，与vc6/vb6写的程序在windows 10跑相当。
: 不出问题也就算了，出问题之后肯定要windows专家才能解决。
: 所以很难认为用mingw,不用msft新的toolchain是划算的。
:
: glibc
|
g****t
发帖数: 31659 | 36 Mingw调用的那些dl, 不能Copy进自己的软件里。微软有限制。但这个同样的代码可能
会比Linux慢很多的问题，我之前查过绵延多年。stackoverflow， quora一开始就有不
少条。非常多样。所以我认为risk是很高的。
: mingw的runtime也是更新的，不是你說的copy dll。此外，VS一樣要更新crt。
: 很多open source的windows版本都是用mingw編譯的，並沒有你說的毛病。
: 至於划算不換算，就是見仁見智了。有人覺得200塊也挺多的，但是沒有200塊的
人並不
: 是不能寫出好程序的。
: run
【在 n******t 的大作中提到】
: mingw的runtime也是更新的，不是你說的copy dll。此外，VS一樣要更新crt。
: 很多open source的windows版本都是用mingw編譯的，並沒有你說的毛病。
: 至於划算不換算，就是見仁見智了。有人覺得200塊也挺多的，但是沒有200塊的人並不
: 是不能寫出好程序的。
:
: run
|
n******t
发帖数: 4406 | 37 都不能copy進自己的軟件里。。微軟下面是沒有真正的靜態鏈接的說法的。
而且我實在是不懂你爲啥覺得兩個不同的操作系統，在同一個硬件上面performance應
該一樣。你真當寫OS的人大街上隨便找麼？
【在 g****t 的大作中提到】
: Mingw调用的那些dl, 不能Copy进自己的软件里。微软有限制。但这个同样的代码可能
: 会比Linux慢很多的问题，我之前查过绵延多年。stackoverflow， quora一开始就有不
: 少条。非常多样。所以我认为risk是很高的。
:
:
: mingw的runtime也是更新的，不是你說的copy dll。此外，VS一樣要更新crt。
:
: 很多open source的windows版本都是用mingw編譯的，並沒有你說的毛病。
:
: 至於划算不換算，就是見仁見智了。有人覺得200塊也挺多的，但是沒有200塊的
: 人並不
:
: 是不能寫出好程序的。
:
: run
|
b***i
发帖数: 3043 | 38 我以前做个那个面试项目就是要求项目用CMakeList，这样既可以在VS里面使用，可以
在Linux下编译。我就两个都试验了一下，确实好用。你可以要求你的学生交付这样的
CMakeList的项目。你在Linux下编译如何？
【在 m*****n 的大作中提到】
: 能否用CMake替代Visual Studio的劳什子？
: 学生给我交付的是Visual Studio的一大摊子，里面还加载着用CMake辅助编译的开源库
: 既然底层都是make
: 能否用CMake把调用库都分析出来，最后直接用CMakeLIsts.txt完事？
: Visual Studio实在是配置过于复杂，而且错误无法排查。
|
m*****n
发帖数: 3575 | 39 丫在VS现有条件下能编译过就不错了。还要啥自行车啊！
高校出来卖劳力的都是老油条
【在 b***i 的大作中提到】
: 我以前做个那个面试项目就是要求项目用CMakeList，这样既可以在VS里面使用，可以
: 在Linux下编译。我就两个都试验了一下，确实好用。你可以要求你的学生交付这样的
: CMakeList的项目。你在Linux下编译如何？
|
b***i
发帖数: 3043 | 40 可以绕开啊，比如过时的C++ Builder 10,就不是VS，也可以用啊。但是，你学生提交
的是老板的VS,谁帮你把sln改成在那个编译器下能够编译呢？
【在 m*****n 的大作中提到】
: 关键是底层的金融模块，人家提供的就是C++的
: 所以已经尽量简化了，把需要和底层通讯的模块单做一个命令行程序
: 就这也绕不开Visual C++ 和VS吗？
:
: 而且
: on
|
|
|
m*****n
发帖数: 3575 | 41 他得改过来。他改不过来我不付尾款。
【在 b***i 的大作中提到】
: 可以绕开啊，比如过时的C++ Builder 10,就不是VS，也可以用啊。但是，你学生提交
: 的是老板的VS,谁帮你把sln改成在那个编译器下能够编译呢？
|
b***i
发帖数: 3043 | 42 到底项目多大？如果只是一个文件，还好办，命令行可以做到。
VS
c:hello>cl /EHsc hello.cpp
C++ builder
bcc32 filename.cpp
【在 m*****n 的大作中提到】
: 他得改过来。他改不过来我不付尾款。
|
c*******v
发帖数: 2599 | 43 一定范围内的程序，在不同OS表现可以相同啊。这是个连续的spectrum，不是非黑即白
的。
弄清楚这个区域，那我就可能分出来这一块。写一个单独的c89或者别的c标准的库。
各种设备上这个部分就可以重用。
最简单的，例如不牵涉IO的math，问题都不大（加几个宏处理整数长度什么的）。
file IO比较麻烦，但也可以分类。等等。能往外走的越多，越省工时。
【在 n******t 的大作中提到】
: 都不能copy進自己的軟件里。。微軟下面是沒有真正的靜態鏈接的說法的。
: 而且我實在是不懂你爲啥覺得兩個不同的操作系統，在同一個硬件上面performance應
: 該一樣。你真當寫OS的人大街上隨便找麼？
|
m*****n
发帖数: 3575 | 44 用了两个API和一个libevent
外加监听本地端口，分析json和cp936转码（可能没有）
【在 b***i 的大作中提到】
: 到底项目多大？如果只是一个文件，还好办，命令行可以做到。
: VS
: c:hello>cl /EHsc hello.cpp
: C++ builder
: bcc32 filename.cpp
|
