Re: cvs commit: xml-axis/c/src/engine SharedObject.h SharedObject.cpp SessionScopeHandlerPool.h SessionScopeHandlerPool.cpp SerializerPool.h SerializerPool.cpp RequestScopeHandlerPool.h RequestScopeHandlerPool.cpp DeserializerPool.h DeserializerPool.cpp AppScopeHandlerPool.h AppScopeHandlerPool.cpp Main.c HandlerPool.h HandlerPool.cpp HandlerLoader.h HandlerLoader.cpp HandlerChain.h HandlerChain.cpp AxisEngine.h AxisEngine.cpp Axis.cpp

[Steve Loughran <st...@iseran.com>]

Sam Lang wrote:
> During the compile process for AxisC++, I'm getting a bunch of warnings
> from the headers:
> 
> warning: no newline at end of file
> 
> g++ gives this warning, but VC++ doesn't.  Because C++ compilers can
> differ dramatically across platforms, it might be worthwhile to have a
> set of C++ coding guidelines, to ensure this kind of problem doesn't
> happen.  The mozilla project has a set of guidelines for this purpose:
> 
> http://www.mozilla.org/hacking/portable-cpp.html
> 
> which addresses the above problem:
> 
> --snip--
> 10. Put a new line at end-of-file
> 
> Not having a new-line char at the end of file breaks .h files with the
> Sun WorkShop compiler and it breaks .cpp files on HP.
> --snip--
> 
> I would recommend adopting their guidelines, or coming up with your own.


I am +1 for x-platform code standards, but IMO the Mozilla ones are 
outdated or driven by support for obscure platforms & C++ compilers. 
Things have improved, not least because gcc is the defacto standard for 
everything but Windows.

My windows-linux-macosX code works with
-modern ISO C++: wchar_t is a type, for(int i=0) {} scopes I to the 
forloop, etc.
-unicode everywhere
-namespaces
-no C style casts. dynamic_cast, reinterpret_cast, const_cast, etc.
-STL datastructures. The VS.net 2003 is still buggy here *of course*
-all exceptions derive from std::exception

I'd drop 1,3,4,5,19 from the list, retain the rest, even #2, which is 
not as critical as it used to be, but still good practice -as you cannot 
predict the order things get constructed.

http://www.iseran.com/Win32/Articles/walkthrough.html

c++ portability (was: Re: cvs commit: xml-axis/c/src/engine SharedObject.h ...)

[Sanjiva Weerawarana <sa...@watson.ibm.com>]

"Steve Loughran" <st...@iseran.com> writes:
> 
> I am +1 for x-platform code standards, but IMO the Mozilla ones are 
> outdated or driven by support for obscure platforms & C++ compilers. 
> Things have improved, not least because gcc is the defacto standard for 
> everything but Windows.
> 
> My windows-linux-macosX code works with
> -modern ISO C++: wchar_t is a type, for(int i=0) {} scopes I to the 
> forloop, etc.
> -unicode everywhere
> -namespaces
> -no C style casts. dynamic_cast, reinterpret_cast, const_cast, etc.
> -STL datastructures. The VS.net 2003 is still buggy here *of course*
> -all exceptions derive from std::exception
> 
> I'd drop 1,3,4,5,19 from the list, retain the rest, even #2, which is 
> not as critical as it used to be, but still good practice -as you cannot 
> predict the order things get constructed.
> 
> http://www.iseran.com/Win32/Articles/walkthrough.html

While you're right that portability has indeed improved with latest 
versions of operating systems, many people who are C++ types end up
having to run code that requires quite a bit of legacy. As a result,
they don't have the freedom to update operating systems and compilers
as often as they may like to. This is especially true in workhorse
scientific computing systems - once things work well and highly 
efficiently, there is little reason to "upgrade" the underlying 
platform.

So, I'm +1 to following a rigourous set of rules for portability. 
Usually it means that you may have to do a bit more work (as some
cool new features would have to be avoided) but its worth the cost
if one of the desires is to support legacy integration, especially
in cross-language environments.

Sanjiva.