diff options
Diffstat (limited to 'docs/ACE-guidelines.html')
-rw-r--r-- | docs/ACE-guidelines.html | 148 |
1 files changed, 7 insertions, 141 deletions
diff --git a/docs/ACE-guidelines.html b/docs/ACE-guidelines.html index 4dcb5145dc9..ec975667c53 100644 --- a/docs/ACE-guidelines.html +++ b/docs/ACE-guidelines.html @@ -3,7 +3,7 @@ <html> <head> <title>ACE Software Development Guidelines</title> - <link rev=made href="mailto:ace-users@cs.wustl.edu"> + <link rev=made href="mailto:levine@cs.wustl.edu"> </head> <body text = "#000000" @@ -35,12 +35,7 @@ bgcolor="#ffffff"> <li>Do not end text lines with spaces. Emacs users can add this to their <strong>.emacs</strong>: - <pre>(setq-default nuke-trailing-whitespace-p t)</pre> - - <strong>Note for Microsoft Visual Studio .NET Users:</strong> - <p>There is a macro project <code>(ace_guidelines.vsmacros)</code> - located in <code>$ACE_ROOT/docs</code> that replaces tabs with spaces - and removes trailing spaces each time you save a file.</p> + <pre>(setq-default nuke-trailing-whitespace-p t)</pre><p> <li>Try to limit the length of source code lines to less than 80 characters. Users with 14 inch monitors appreciate it when @@ -178,13 +173,6 @@ bgcolor="#ffffff"> manual</a>. For an example header file using Doxygen-style comments, please refer to <a href="../ace/ACE.h">ACE.h</a>.<p> - - <LI>All binary options for ACE and TAO should be specified in - terms of the integral values 0 and 1, rather than "true" and - "false" or "yes" and "no". All TAO options should be - documented in the <A HREF="../TAO/docs/Options.html">online - TAO options document</A>. <P>. - </ul> <li><strong>Preprocessor</strong><p> @@ -248,8 +236,6 @@ not defined. The correct way to write that guard is: #if defined (__FreeBSD__) && __FreeBSD__ < 3 </pre> -If using g++, problems like this can be flagged as a warning by using the "<code>-Wundef</code>" command line option. - <li>Try to centralize <code>#ifdef</code>s with <code>typedef</code>s and <code>#define</code>s. For example, use this: <pre> @@ -919,133 +905,13 @@ Foo::bar () <li><strong>Compilation</strong><p> <ul> <li>Whenever you add a new test or example to ACE or TAO, make - sure that you modify the MPC file in the parent directory. - This will make sure that your code gets compiled on a - regular basis.<p> + sure that you modify the Makefile or project file in the + parent directory. This will make sure that your code gets + compiled on a regular basis. In some cases, this also applies + to MSVC project files.<p> </ul><p> </ul> -<hr> -<h3><a href="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">ACE</a> - Shared Libary Guidelines</h3> - <ul> - <li> - <p> - Create a separate export macro for each dynamic library. A - header file containing the export macro and additional - support macros should be generated by using the <a - href="../bin/generate_export_file.pl">ACE_wrappers/bin/generate_export_file.pl</a> Perl script. - </p> - </li> - <li> - <p> - Make sure that your classes, structures and free functions - are annotated with this export macro. The only exceptions - are pure template classes, structures and free functions. - </p> - <p> - Only classes (and structures, free functions, etc) that are - part of the library public interface must be exported - (e.g. declared with an export macro). Those that are only - meant to be used internally need not be exported, - particularly for g++ <code>>=</code>4.0 since doing so - defeats some neat optimizations. Here's a common case in - where an export macro is generally used unnecessarily: - </p> - <blockquote> - <pre> -class FooExport Foo -{ -public: - virtual void kung_fu () = 0; -}; - -class FooExport Bar : public Foo -{ -public: - virtual void kung_fu () { ... } -}; - -class FooExport FooFactory -{ -public: - Foo * make_foo () - { - // Assume that this implementation is hidden from - // the application and is consequently out of line. - return new Bar(); - } -}; - </pre> - </blockquote> - <p> - Here the application is only meant to invoke operations - through a pointer or reference to the abstract base class - "<code>Foo</code>" created by the "<code>FooFactory</code>", - not the "<code>Bar</code>" subclass. In this case, - exporting "<code>Bar</code>" is unnecessary. If your - concrete class is meant to be used outside of the shared - library (e.g. as a template parameter, within a - <code>dynamic_cast<></code>, etc) you must then export - it. Otherwise, avoid doing so if you can. - </p> - </li> - <li> - <p> - Make sure that you specify that you are creating a dynamic - library in your <a href="../MPC/README">MPC</a> file by adding - a <code>sharedname</code> tag. - </p> - </li> - <li> - <p> - Make sure that you add the <code>FOO_BUILD_DLL</code> - preprocessor symbol to the <code>dynamicflags</code> of the - MPC project that is used to build a library. Note that the - export files are setup such that when this macro is defined, - the symbols are exported, otherwise they are imported. The - default behaviour is to set up for import so that clients of - your library don't need to worry about arcane build flags - like <code>FOO_BUILD_DLL</code> in their build setup. This - ties back to the first item. - </p> - </li> - <li> - <p> - When you specify the order of libraries to link to, make - sure that the dependent libraries come after the libraries - which depend on them, i.e., your link line should always - contain <code>-lDependsOnFoo -lFoo</code>. Note that this - is not a requirement on GNU/Linux but linkers on other - platforms are not as forgiving. - </p> - </li> - <li> - <p> - Use the <code>ACE_SINGLETON_DECLARE</code> macro to declare - a class as a singleton. Declare exported (i.e. default - visibility) singleton templates prior to typedefs that - reference them. This prevents g++ 4.0 from silently making - their visibility hidden (see <a - href="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=2260">Bug 2260</a> for details). - </p> - </li> - <li> - <p> - Avoid inlining virtual functions in classes that must be - exported since doing so can cause RTTI related problems - (e.g. <code>dynamic_cast<> failures</code>) when using - g++ >= 4.0 due to our use of that compiler's "visibility - attribute" support that is tied in to the export macros. - This includes virtual destructors automatically created by - the compiler when you don't declare one. Make sure you - define a no-op out-of-line virtual destructor if your base - class has a virtual destructor since you may otherwise run - into the mentioned RTTI problems. - </p> - </li> - </ul> - <hr> <h3><a href="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">ACE</a> @@ -1303,7 +1169,7 @@ eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}' <hr><p> <font size=-1> <!-- hhmts start --> -Last modified: Wed Nov 23 11:00:44 CST 2005 +Last modified: Tue Sep 20 14:06:27 CDT 2005 <!-- hhmts end --> </font><p> |