Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Compiling Code::Blocks with the MS compiler
Michael:
--- Quote from: 280Z28 on January 22, 2006, 08:20:43 am ---The compiler with VS 2005 is one of the most compliant compilers available.
--- End quote ---
VS 2005 is a relatively good ISO-C++ compliant compiler (for sure better than Visual Studio C++ 6), but may be you would like to give a look at here.
Michael
Michael:
--- Quote from: killerbot on January 22, 2006, 09:59:24 am ---[EDIT] It would indeeed by nice to have CB and plug-ins compilable with different compilers, but stick to the standards...
--- End quote ---
Yes, IMHO it would be really nice :D. Anyway, this will provide additional work, because all the C::B and plugins modifcations, updates and so on need to be checked with all the supported compilers.
Michael
280Z28:
I wanted to use Visual Studio to track down the code completion bug I was facing, and I'd just like to say that within 2 minutes of running CB within the VS debugger for the first time, I found the problem. :shock: :lol:
Rick, you aren't using a Pentium 4, are you? :o
Ceniza:
--- Quote from: 280Z28 ---Functions were deprecated primarily for two reasons:
1) Known insecurities. Obvious reason to deprecate. If you don't feel like changing these, define the following directive:
#define _CRT_SECURE_NO_DEPRECATE
--- End quote ---
Obvious reason to deprecate? Defining another macro to make this specific compiler behave and stop throwing things it'sn't supposed to?
The reason to deprecate something in a compiler is because the standard says so. C99 and C++98 haven't deprecated that, it's plain wrong for a compiler to start adding deprecations here and there because they want to.
If they just showed a warning suggesting the use of another STANDARD function or read why you should use those functions carefully, that'd be fine, but no, they don't. An example of this is using gets with gcc under Linux. gets hasn't been deprecated, but should be used with care or replaced with a call to fgets or anything else, but just because it's "insecure" doesn't give "obvious reasons" to the compiler to call it deprecated.
And then what? Will MS just remove those functions in the next release because were deprecated in the current version?
But anyway, if you can find something useful in the whole process of modifying the sources to make them compile with that compiler and not just having that compiler telling lies, that'd be good.
280Z28:
I disagree with you, but I guess that's ok because you'll never be using the VC compiler in the first place and I have a property sheet to add that to macro to projects I'm converting. ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version