Author Topic: Compiling Code::Blocks with the MS compiler  (Read 19472 times)

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Compiling Code::Blocks with the MS compiler
« Reply #15 on: January 22, 2006, 03:29:51 pm »
The compiler with VS 2005 is one of the most compliant compilers available.

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

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Compiling Code::Blocks with the MS compiler
« Reply #16 on: January 22, 2006, 03:38:44 pm »
[EDIT] It would indeeed by nice to have CB and plug-ins compilable with different compilers, but stick to the standards...

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

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Compiling Code::Blocks with the MS compiler
« Reply #17 on: January 22, 2006, 04:29:37 pm »
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
« Last Edit: January 22, 2006, 04:36:40 pm by 280Z28 »
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Compiling Code::Blocks with the MS compiler
« Reply #18 on: January 22, 2006, 04:38:25 pm »
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

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.

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Compiling Code::Blocks with the MS compiler
« Reply #19 on: January 22, 2006, 04:45:17 pm »
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. ;)
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Compiling Code::Blocks with the MS compiler
« Reply #20 on: January 22, 2006, 04:50:52 pm »
I'd like to just check in the fix rather than going through all I did to fix it. Is that possible?
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Compiling Code::Blocks with the MS compiler
« Reply #21 on: January 22, 2006, 04:51:37 pm »
Rick hasn't a P4, but you'ren't saying what problem you found.

Would you mind to explain how P4 and CodeCompletion relate there? :)