Hi JS, On Thu, Feb 5, 2009 at 7:38 PM, Jean-Sébastien Guay <jean-sebastien.g...@cm-labs.com> wrote: > Oh come on. Aren't you pushing this a bit too far? We're not playing > anyone's game, just using a tool that allows us to compile code on a given > platform. This platform choice (which is only one option, we support Linux > too, but cannot go away from Windows completely) is dictated by our clients > and past history. That's what's locking us into using that tool, not the > tool itself.
I'm not suggesting dropping windows support, I'm just saying that you keep all the platform specific hacks as far away from general code as possible. You keep is as localised as possible, this is the key to cross platform development - it's why the OSG is so portable. Adding obscure platform specific hacks to all header files is totally wrong for this project, and make it less maintainable. It would be a backwards step that I won't merge. > Even if I were working on personal projects only, I would still advocate for > OSG to support VS in the best way possible. It's too big a market and a user > base to push to the wayside and have half-baked support for. Not supporting the MS pet way of doing things isn't providing poor windows support. The OSG supports VS just fine. Using CMake you can disable the Export pragma's, you have complete control. If you want to then isolate the warnings from OSG headers yourself then again you have complete control to do so. Rather than stuff macro's or extra includes why not in your own application just have your own macro such as: #define INCLUDE(header) / #pragma (warning(push)) / #pragma (warning(disable : a b c d)) / #include<header> / #pragma (warning(pop)) Then in your own code you just have: INCLUDE(osg/Node) Like the ScopedLock trick we use for Mutex management - it's an design pattern that ensures robust resource management and far more maintainable than need to enclose everything carefully with lines that are only relevant to a single platform. > But then even OSG's headers will generate warnings. A library should not > generate warnings, but should not obscure the warnings in your own code. > Period. Do you at least agree with that? I really stove for the ideal of the OSG header not generating any warnings so not requiring the pragma's, I wrote just this as my goal, but we've falling short, and through lack of effort. The reality is that modern compilers at high warning levels produce lots of false positives on perfectly correct code. > As Matthew said, this could be replaced by macros in a single header, or > something else. As I said, I was trying to suggest something, anything, in > the hope we could go forward in some way. Just arguing back and forth > doesn't help anything, so I think I'll stop replying about this subject if > we don't go forward at least a bit. Mathew's suggest is marginally better, but still a horrible hack. > What happens if I forget to add #endif to the end of a header to close the > include guards? That's not standard C++ either, just common practice, and no > one really fights that. The #ifdef #endif around headers is a back that we all have to employ across all platforms. If someone missing it out we have a good chance of catching it on the any platform. It's a pain but it is at least maintainable without too much effort or likely-hood of introducing mistakes. Contracts this we push/pop macro/include errors - the code would still compile even under VisualStudio, no one would know about a problem until someone starting looking for errors that were being accidentally suppressed. If you code typically doesn't generate warnings, and continues not to generate warnings you'll happily assume everything is dandy... but it's not, it's broken, but... where.... ooooo lots of headers to go through. > Well, since you don't even see the VS warnings, and don't see errors related > to OSG_EXPORT, and don't see... I don't understand how that's worse. Someone > (probably me, lucky as I am) will compile on Windows, see the error, track > it to the missing end marker (whatever that may be) and submit the fix, the > same as a missing OSG_EXPORT. For the number of times a new header is added > to OSG, I think it's really minor. The OSG_EXPORT issues is a pain, but at least if they are missing someone eventually picks up the error and the error report you get pinpoints the problem precisely. The push/pop is a very different beast - its an untraceable and largely un-noticable error. The OSG_EXPORT also provides a function to the binaries, doesn't add any extra lines of code to the headers and is well understood by most developers. So it's more functional, and less intrusive and more maintainable than the proposed push/pop macro/headers. >> This certainly won't make help code portability and maintainability. > > Let's just suppress all warnings in osg/Export then, and see if users like > that. (I'm only partly joking) > > Anyways, the basic premise I'm maintaining is that > > a) a library should not cause any warnings when including its headers in > user code > b) a library should not suppress warnings caused by user code > > If you don't agree with that, then I'll let go, because suppressing *some* > warnings in osg/Export is probably the best middle ground I'm likely to get. Sigh. I have worked my bollocks off trying to reduce the number of suppressed warnings in include/osg/Export. We have got as far as we are going to get without holding back the release for many more weeks, and without modifying many hundreds of files, needless changes too, then won't actually fix any bugs, it just compilers over zealous warnings we are suppressing via code changes to code that is typically perfectly correct in the first place. What is far far more important is testing and fixing real bugs. Fixing real bugs benefits everybody. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
