Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
C::B with DM or vc++?
takeshimiya:
--- Quote from: mandrav on February 23, 2006, 06:54:58 pm ---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.
--- End quote ---
Good to hear :D, because other projects deletes them permanently and without further notice.
Michael:
--- Quote from: sethjackson on February 23, 2006, 05:39:05 pm ---
--- Quote from: Trikko on February 23, 2006, 05:17:19 pm ---
--- Quote from: Michael on February 23, 2006, 05:05:57 pm ---
Anyway, have a look at here.
--- End quote ---
DM passes 100% of dr. dobbs tests :D
http://www.digitalmars.com/changelog.html#new845
ehehhehe :)
--- End quote ---
Umm DM isn't on the list (show me where I can't find it)
--- End quote ---
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:
--- Quote from: mandrav on February 22, 2006, 02:04:41 pm ---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).
[/list]
--- End quote ---
This is understood. I'd like to add some other points though:
- Most compiling problems under VC are related to the mentioned
--- Code: ---_("some text"
"some more text")
--- End code ---
which needs to become
--- Code: ---_("some text")
_("some more text")
--- End code ---
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:
--- Quote from: ikolev on March 12, 2006, 03:06:06 pm ---Most compiling problems under VC are related to the mentioned
--- Code: ---_("some text"
"some more text")
--- End code ---
which needs to become
--- Code: ---_("some text")
_("some more text")
--- End code ---
--- End quote ---
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.
--- Quote ---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
--- End quote ---
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.
--- Quote ---VC 2005 for example has an option for "C++ analysis", which issues a lot of additional warnings for possible problems [...]
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version