C::B with DM or vc++?

[takeshimiya]

The fact that we may reject the patch, does not mean that it is deleted from the patch tracker. The patch will always be there for anyone to try and apply, if he/she needs to.

Good to hear , because other projects deletes them permanently and without further notice.

[Michael]

Anyway, have a look at here.

DM passes 100% of dr. dobbs tests

http://www.digitalmars.com/changelog.html#new845

ehehhehe

Umm DM isn't on the list (show me where I can't find it)

Yes, true . I cannot see DM on the list. Where is it?

Best wishes,
Michael

[severach]

Update the Windows SDK at http://cmeerw.org/prog/dm/ms_sdk.html and you'll find that DMC does not compile substantially faster than the others.

[ikolev]

But even if it could succesfully build in other compilers, we 'd still use GCC. This will never change, no matter what.
Here are the reasons:

• C::B is cross-platform and the only reliable cross-platform compiler available is GCC.
  
• I don't have MSVS nor have I ever used/seen it. I don't plan to change this now.
  
• The above point makes clear that even if someone contributed a patch for other compilers to build C::B, it wouldn't be accepted because we couldn't maintain it (been there, done that).
  

This is understood. I'd like to add some other points though:

- Most compiling problems under VC are related to the mentioned

Code Select Expand

_("some text"
"some more text")

which needs to become

Code Select Expand

_("some text")
_("some more text")

These could be easily fixed in the SVN trunk and avoided in the future, without any need for maintenance. While it won't solve VC-compatibility completely, it would reduce the size of a possible external patch.

- Having additional compiler support in external patches instead of the main codebase is a good idea, but AFAIK such patches are made against a specific SVN revision, so the maintainers of such patches would need to release a new patch for each new revision, or at least for the major ones (I'm not sure about this, I might be wrong).

- Maintaining additional compilers would surely take precious time of the CB team, so it's out of the question. But you might want to check out the Express version of Visual Studio 2005 which IIRC is free. I think the CB team could only benefit from knowing better the major C++ IDE on the market, at least for the fact that many future users of C::B with VS experience will often ask questions like "why doesn't C::B have this feature which VS has...".

- As killerbot mentioned, building with different compilers usually helps find problems and improves code quality. VC 2005 for example has an option for "C++ analysis", which issues a lot of additional warnings for possible problems (e.g. using pointers without checking if they are 0). But I'm not sure if this option is available in VS Express.

[thomas]

Most compiling problems under VC are related to the mentioned

Code Select Expand

_("some text"
"some more text")

which needs to become

Code Select Expand

_("some text")
_("some more text")

Why do these need to be changed? It is perfectly correct to continue a character constant in the next line, be it in a macro argument or not. The code is absolutely valid, it is the MS compiler which does not work properly.

Having additional compiler support in external patches instead of the main codebase is a good idea, but AFAIK such patches are made against [...] would need to release a new patch for each new revision

That is partially true at the present time, only very radical SDK changes will require that.
It is however one reason why I keep telling people "don't do this and don't do that right now", because this will change radically in the near future.

VC 2005 for example has an option for "C++ analysis", which issues a lot of additional warnings for possible problems [...]

To be honest, gcc is already quite pedantic if you turn on all warnings. Personally, I don't think that there are many MS products which are really apt to improve code. DM or Comeau may of course be an entirely different story, but the additional workload would be quite substantial.

[ikolev]

Why do these need to be changed? It is perfectly correct to continue a character constant in the next line, be it in a macro argument or not. The code is absolutely valid, it is the MS compiler which does not work properly.

Indeed. Besides, I suggested the wrong change. To make the example work in VC, it has to be

Code Select Expand


_("some text\
some more text")