diff options
Diffstat (limited to 'etc')
-rw-r--r-- | etc/ACE-guidelines.html | 697 | ||||
-rw-r--r-- | etc/ACE-porting.html | 184 | ||||
-rw-r--r-- | etc/ACE-subsets.html | 684 | ||||
-rw-r--r-- | etc/ACE-tutorials.html | 83 |
4 files changed, 0 insertions, 1648 deletions
diff --git a/etc/ACE-guidelines.html b/etc/ACE-guidelines.html deleted file mode 100644 index b3b3d13cc37..00000000000 --- a/etc/ACE-guidelines.html +++ /dev/null @@ -1,697 +0,0 @@ -<!-- $Id$ --> - -<html> - <head> - <title>ACE Software Development Guidelines</title> - <link rev=made href="mailto:levine@cs.wustl.edu"> - </head> - -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - -<hr> - <h3>ACE Software Development Guidelines</h3> - -<ul> - <li><strong>General</strong><p> - <ul> - <li>Every text file must end with a newline.<p> - - <li>Use spaces instead of tabs, except in Makefiles. Emacs users - can add this to their <strong>.emacs</strong>: - - <pre>(setq-default indent-tabs-mode nil)</pre></p> - - Microsoft Visual C++ users should do the following: - - <pre> - Choose: Tools -- Options -- Tabs - Then Set: "Tab size" to 8 and "Indent size" to 2, and - indent using spaces. - </pre><p> - - <li>Every program should have a ``usage'' message. It should be - printed out if erroneous command line arguments, or a - <strong><code>-?</code></strong> command line argument, are - provided to the program.<p> - - <li>The program <strong><code>main</code></strong> function should - always be declared with arguments, e.g., - <pre> - int - main (int argc, char *argv[]) - { - [...] - - return 0; - } - </pre><p> - - It should also return 0 on successful termination, and non-zero - otherwise.<p> - - <li>Avoid use of floating point types (float and double) and operations - unless absolutely necessary. Not all ACE platforms support them. - Therefore, wherever they are used, ACE_LACKS_FLOATING_POINT - conditional code must be also be used.<p> - </ul> - - <li><strong>Code Documentation</strong><p> - <ul> - <li>Use comments and whitespace (:-) liberally.<p> - - <li>Insert a CVS/RCS keyword string at the top of every source file, - Makefile, config file, <em>etc</em>. For C++ files, it is: - <pre> - // $<!-- -->Id$ - </pre> - It is not necessary to fill in the fields of the keyword string, - or modify them when you edit a file that already has one. CVS - does that automatically when you checkout or update the file.<p> - - To insert that string at the top of a file: - <pre> - perl -pi -e \ - 'if (! $o) {printf "// \$<!-- -->Id\$\n\n";}; $o = 1;' <em>file</em> - </pre><p> - - <li>Comments, especially in header files, must follow the - <a href=http://www.dscpl.com.au>OSE</a> Tools format requirements. - Please see the ``Classinfo Tools'' section of the - <a href=http://www.dscpl.com.au>OSE</a> ``Tools Manual'' - for these requirements.<p> - - </ul> - - <li><strong>Preprocessor</strong><p> - <ul> - <li>Never #include standard headers directly, except in a few - specific ACE files, <em>e.g.</em>, OS.h and stdcpp.h. Let - those files #include the correct headers. If you do not do - this, your code will not compile with the Standard C++ Library.<p> - - <li>Always follow a preprocessor <strong><code>#endif</code></strong> - with a <strong><code>/* */</code></strong> C-style comment. It - should correspond to the condition in the matching - <strong><code>#if</code></strong> directive. For example, - <pre> - #if defined (ACE_HAS_THREADS) - # if defined (ACE_HAS_STHREADS) - # include /**/ <synch.h> - # include /**/ <thread.h> - # define ACE_SCOPE_PROCESS P_PID - # define ACE_SCOPE_LWP P_LWPID - # define ACE_SCOPE_THREAD (ACE_SCOPE_LWP + 1) - # else - # define ACE_SCOPE_PROCESS 0 - # define ACE_SCOPE_LWP 1 - # define ACE_SCOPE_THREAD 2 - # endif /* ACE_HAS_STHREADS */ - #endif /* ACE_HAS_THREADS */ - </pre><p> - - <li>Always insert a <strong><code>/**/</code></strong> between an - <strong><code>#include</code></strong> and - <strong><code>filename</code></strong>, as shown in the above - example. This avoids dependency problems with Visual C++.<p> - - <li>Be very careful with names of macros and enum values. It's - always best to prefix them with something like <code>ACE_</code> - or <code>TAO_<code>. There are too many system headers out - there that #define <code>OK</code>, <code>SUCCESS</code>, - <code>ERROR</code>, and so on.<p> - </ul> - - <li><strong>C++ Syntax and Constructs</strong><p> - <ul> - <li><strong><code>for</code></strong> loops should look like: - <pre> - for (size_t i = 0; i < Options::instance ()->spawn_count (); ++i) - spawn (); - </pre> - (though I prefer to always wrap the body of the loop in braces, - to avoid surprises when other code or debugging statements are - added, and to maintain sanity when the body consists of a macro, - such as ACE_ASSERT:) - <pre> - for (size_t i = 0; i < Options::instance ()->spawn_count (); ++i) - { - ACE_ASSERT (spawn () == 0); - } - </pre><p> - - Similarly, <strong><code>if</code></strong> statements should have - a space after the ``<strong>if</strong>'', and no spaces just after - the opening parenthesis and just before the closing parenthesis.<p> - - <li>If a loop index is used after the body of the loop, it - <strong>must</strong> be declared before the loop. For example, - - <pre> - size_t i = 0; - for (size_t j = 0; file_name [j] != '\0'; ++i, ++j) - { - if (file_name [j] == '\\' && file_name [j + 1] == '\\') - ++j; - - file_name [i] = file_name [j]; - } - - // Terminate this string. - file_name [i] = '\0'; - </pre> - - <li>Avoid unnecessary parenthesis. We're not writing Lisp :-)<p> - - <li>Put inline member functions in a <strong><code>.i</code></strong> - file. That file is conditionally included by both the - <strong><code>.h</code></strong> file, for example:<p> - - <pre> - class ACE_Export ACE_High_Res_Timer - { - [...] - }; - - #if defined (__ACE_INLINE__) - #include "ace/High_Res_Timer.i" - #endif /* __ACE_INLINE__ */ - </pre><p> - - and <strong><code>.cpp</code></strong> file:<p> - - <pre> - #define ACE_BUILD_DLL - #include "ace/High_Res_Timer.h" - - #if !defined (__ACE_INLINE__) - #include "ace/High_Res_Timer.i" - #endif /* __ACE_INLINE__ */ - - ACE_ALLOC_HOOK_DEFINE(ACE_High_Res_Timer) - </pre><p> - - <strong>NOTE:</strong> It is very important to ensure than an - inline function will not be used before its definition is seen. - Therefore, the inline functions in the .i file should be arranged - properly. Some compilers, such as <code>g++</code> with the - <code>-Wall</code> option, will issue warnings for violations.<p> - - <li><code>ACE_Export</code> must be inserted between the - <code>class</code> keyword and class name for all classes that - are exported from libraries, as shown in the example above. - <strong>However</strong>, do <strong>not</strong> use - <code>ACE_Export</code> for template classes!<p> - - <li>Mutators and accessors should be of this form:<p> - - <pre> - void object_addr (const ACE_INET_Addr &); - // Sets <object_addr_> cache from <host> and <port>. - - ACE_INET_Addr &object_addr (void); - // Returns the <ACE_INET_Addr> for this profile. - </pre><p> - - instead of the ``set_'' and ``get_'' form.<p> - - <li>Never use <strong><code>delete</code></strong> to deallocate - memory that was allocated with <strong><code>malloc</code></strong>. - Similarly, never associate <strong><code>free</code></strong> with - <strong><code>new</code></strong>. - <strong><code>ACE_NEW</code></strong> or - <strong><code>ACE_NEW_RETURN</code></strong> should be used to - allocate memory, and <strong><code>delete</code></strong> should - be used to deallocate it. And be careful to use the correct form, - <strong><code>delete</code></strong> or - <strong><code>delete []</code></strong> to correspond to the - allocation.<p> - - <li>Don't check for a pointer being 0 before deleting it. It's - always safe to delete a 0 pointer. If the pointer is visible - outside the local scope, it's often a good idea to 0 it - _after_ deleting it. Note, the same argument applies to - free().<p> - - <li>Always use <strong><code>ACE_NEW</code></strong> or - <strong><code>ACE_NEW_RETURN</code></strong> to allocate memory, - because they check for successful allocation and set errno - appropriately if it fails.<p> - - <li>Never compare or assign a pointer value with <strong>NULL</strong>; - use <strong>0</strong> instead. The language allows any pointer to - be compared or assigned with <strong>0</strong>. The definition - of <strong>NULL</strong> is implementation dependent, so it is - difficult to use portably without casting.<p> - - <li>Never cast a pointer to or from an <strong><code>int</code></strong>. - On all currently supported ACE platforms, it is safe to cast - a pointer to or from a <strong><code>long</code></strong>.<p> - - <li>Be very careful when selecting an integer type that must be a - certain size, <em>e.g.</em>, 4 bytes. <strong>long</strong> is - not 4 bytes on all platforms; it is 8 bytes on many 64-bit - machines. ACE_UINT32 is always 4 bytes, and ACE_UINT64 is - always 8 bytes.<p> - - <li>If a class has any virtual functions, and its destructor is - declared explicitly in the class, then the destructor should - <strong>always</strong> be virtual as well. And to support - compiler activities such as generation of virtual tables and, - in some cases, template instantiation, the virtual destructor - should <strong>not be inline</strong>. (Actually, any non-pure - virtual function could be made non-inline for this purpose. But, - for convenience, if its performance is not critical, it is usually - easiest just to make the virtual destructor non-inline.)<p> - - <li>Constructor initializers must appear in the same order as - the data members are declared in the class header. This avoids - subtle errors, because initialization takes place in the order - of member declaration.<p> - - <li>Initialization is usually cleaner than assignment, especially - in a conditional. So, instead of writing code like this: - - <pre> - ssize_t n_bytes; - - // Send multicast of one byte, enough to wake up server. - if ((n_bytes = multicast.send ((char *) &reply_port, - sizeof reply_port)) == -1) - </pre> - - Write it like this: - - <pre> - ssize_t n_bytes = multicast.send ((char *) &reply_port, - sizeof reply_port) - - // Send multicast of one byte, enough to wake up server. - if (n_bytes == -1) - </pre><p> - - But, beware if the initialization is of a static variable. - A static variable is only initialized the first time its - declaration is seen. Of course, we should avoid using - static variables at all.<p> - - <li>It is usually clearer to write conditionals that have - both branches without a negated condition. For example,<p> - - <pre> - if (test) - { - // true branch - } - else - { - // false branch - } - </pre><p> - - is preferred over:<p> - - <pre> - if (! test) - { - // false test branch - } - else - { - // true test branch - } - </pre><p> - - <li>If a cast is necessary, avoid use of function-style casts, - <em>e.g.</em>, <code>int (foo)</code>. Instead, use - one of the ACE cast macros: - - <pre> - return ACE_static_cast(size_t, this->count_) > that->size_; - </pre><p> - - The general usage guidelines for the four styles of casts are:<p> - <ul> - <li><strong>ACE_const_cast</strong>: use to cast away - constness, or volatile-ness.<p> - <li><strong>ACE_static_cast</strong>: use to cast between - compatible types, such as downcasting a pointer or narrowing - an integer.<p> - <li><strong>ACE_reinterpret_cast</strong>: use only when - ACE_static_cast is not suitable.<p> - <li><strong>ACE_dynamic_cast</strong>: avoid, unless you really - want to type check at run-time.<p> - </ul> - - <li>In general, if instances of a class should not be copied, - then a private copy constructor and assignment operator should - be declared for the class, but not implemented. For example: - - <pre> - // Disallow copying by not implementing the following . . . - ACE_Object_Manager (const ACE_Object_Manager &); - ACE_Object_Manager &operator= (const ACE_Object_Manager &); - </pre><p> - - If the class is a template class, then the - <code>ACE_UNIMPLEMENTED_FUNC</code> macro should be used: - - <pre> - // = Disallow copying... - ACE_UNIMPLEMENTED_FUNC (ACE_TSS (const ACE_TSS<TYPE> &)) - ACE_UNIMPLEMENTED_FUNC (void operator= (const ACE_TSS<TYPE> &)) - </pre><p> - - <code>ACE_UNIMPLEMENTED_FUNC</code> can be used with non-template - classes as well. Though for consistency and maximum safety, it - should be avoided for non-template classes.<p> - </ul> - - <li><strong>I/O</strong><p> - <ul> - <li>Use <strong><code>ACE_DEBUG</code></strong> for printouts, - and <strong><code>ACE_OS::scanf/fprintf ()</code></strong> for - file I/O. Avoid using iostreams because of implementation - differences across platforms.<p> - <li>After attempting to open an existing file, always check for success. - Take appropriate action if the open failed.<p> - </ul> - - <li><strong>UNICODE conformity</strong><p> - - <ul> - <li>Define strings as <strong><code>ASYS_TCHAR</code></strong> if - they need to be passed into system API. It expands to - <code>wchar_t</code> only when - <code>ACE_HAS_MOSTLY_UNICODE_APIS</code> is defined.<p> - - <li>Use <strong><code>ASYS_TEXT</code></strong> and - <strong><code>ASYS_WIDE_STRING</code></strong> for format - strings and other string arguments passed to - <code>ACE_DEBUG</code> or <code>ACE_ERROR</code>. For - example,<p> - <pre> - void - ACE_FOO::ace_bar (int err, ASYS_TCHAR *astr) - { - ACE_TRACE ("ACE_FOO::ace_bar"); - - ACE_DEBUG ((LM_DEBUG, ASYS_TEXT ("From ACE_FOO::ace_bar"))); - - if (err) - ACE_ERROR ((LM_ERROR, - ASYS_TEXT ("(%P) Printing this string %s\n"), - astr)); - } - </pre> - <p> - This is because ACE also support platforms which use UNICODE - in most of their APIs. On these platforms, ACE also uses - UNICODE as its system string type.<p> - - <li><strong><code>ACE_TRACE</code></strong> handles conversion - between char strings and UNICODE strings automatically.<p> - - <li>Other helper macros include - <strong><code>ASYS_MULTIBYTE_STRING</code></strong> and - <strong><code>ASYS_ONLY_MULTIBYTE_STRING</code></strong>. See - the end of <a href="../ace/OS.h">OS.h</a> for more details.<p> - - </ul><p> - - <li><strong>Exceptions</strong><p> - - <ul> - <li>There are many ways of throwing and catching exceptions. The - code below gives several examples. Note that each method has - different semantics and costs. Whenever possible, use the - first approach.<p> - - <pre> - #include "iostream.h" - - class exe_foo - { - public: - exe_foo (int data) : data_ (data) - { cerr << "constructor of exception called" << endl; } - ~exe_foo () - { cerr << "destructor of exception called" << endl; } - exe_foo (const exe_foo& foo) : data_ (foo.data_) - { cerr << "copy constructor of exception called" << endl; } - int data_; - }; - - - void - good (int a) - { - throw exe_foo (a); - }; - - void - bad (int a) - { - exe_foo foo (a); - throw foo; - }; - - int main () - { - cout << endl << "First exception" << endl << endl; - try - { - good (0); - } - catch (exe_foo &foo) - { - cerr << "exception caught: " << foo.data_ << endl; - } - - cout << endl << "Second exception" << endl << endl; - try - { - good (0); - } - catch (exe_foo foo) - { - cerr << "exception caught: " << foo.data_ << endl; - } - - cout << endl << "Third exception" << endl << endl; - try - { - bad (1); - } - catch (exe_foo &foo) - { - cerr << "exception caught: " << foo.data_ << endl; - } - - cout << endl << "Fourth exception" << endl << endl; - try - { - bad (1); - } - catch (exe_foo foo) - { - cerr << "exception caught: " << foo.data_ << endl; - } - - return 0; - } - </pre> - - Output is: <p> - - <pre> - First exception - - constructor of exception called - exception caught: 0 - destructor of exception called - - Second exception - - constructor of exception called - copy constructor of exception called - exception caught: 0 - destructor of exception called - destructor of exception called - - Third exception - - constructor of exception called - copy constructor of exception called - destructor of exception called - exception caught: 1 - destructor of exception called - - Fourth exception - - constructor of exception called - copy constructor of exception called - destructor of exception called - copy constructor of exception called - exception caught: 1 - destructor of exception called - destructor of exception called - - </pre> - - </ul><p> - -</ul> - - -<hr> -<h3><a href="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">ACE</a> - Usage Guidelines</h3> -<ul> - <li>Always use <strong><code>ACE_OS</code></strong> (static) - member functions instead of bare OS system calls.<p> - - <li>Use the <strong><code>ACE_SYNCH_MUTEX</code></strong> macro, - instead of using one of the specific mutexes, such as - <strong><code>ACE_Thread_Mutex</code></strong>. This provides - portability between threaded and non-threaded platforms.<p> - - <li>Avoid creating a static instance of user-defined (class) type. - Instead, either create it as an - <strong><code>ACE_Singleton</code></strong>, - <strong><code>ACE_TSS_Singleton</code></strong>, or as an - <strong><code>ACE_Cleanup</code></strong> object. See the - <strong>ACE</strong> - <a href="../ace/Singleton.h"><code>Singleton.h</code></a>, - <a href="../ace/Object_Manager.h"><code>Object_Manager.h</code></a>, and - <a href="../ace/Managed_Object.h"><code>Managed_Object.h</code></a> - header files for more information.<p> - - Static instances of built-in types, such as - <strong><code>int</code></strong> or any pointer type, are fine.<p> - - Construction of static instance of a user-defined type should - <em>never</em> spawn threads. Because order of construction of - statics across files is not defined by the language, it is usually - assumed that only one thread exists during static construction. - This allows statics suchs as locks to be safely created. We do not - want to violate this assumption.<p> - - <li>Do not use run-time type identification (RTTI). Some platforms - do not support it.<p> - - <li>Do not use exception handling. Some platforms do not support it. - And, it imposes an execution speed penalty.<p> - - <li>Because ACE does not use exception handling, dealing with - failures requires a bit of care. This is especially true - in constructors. Consider the following approach: - - <pre> - ACE_NEW_RETURN (this->name_space_, LOCAL_NAME_SPACE, -1); - - if (ACE_LOG_MSG->op_status () != 0) - .... - </pre> - - This snip of code is from - <a href="../ace/Naming_Context.cpp"><code>ACE_Naming_Context</code></a>. - All failed constructors in ACE (should) call ACE_ERROR. This sets - the thread specific <strong>op_status</strong>, which can be checked - by the caller. This mechanism allows the caller to check for a failed - constructor without the requiring the constructor to throw - exceptions.<p> - - <li>Avoid using the C++ Standard Template Library (STL) in our - applications. Some platforms do not support it yet.<p> -</ul> - - -<hr> -<h3><a href="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">Other - ACE</a> and - <a href="http://www.cs.wustl.edu/~schmidt/TAO-overview.html">TAO</a> - Guidelines</h3> -<ul> - <li>Never add copyrighted, confidential, or otherwise restricted - code to the ACE or TAO distributions without written permission - from the owner.<p> -</ul> - - -<hr> -<h3><a href="http://www.cs.wustl.edu/~levine/CVS.html">CVS</a> - Usage Guidelines</h3> -<ul> - <li>Always make sure that a change builds and executes correctly - on at least one platform before checking it into the CVS repository.<p> -</ul> - - -<hr> -<h3>Script Guidelines</h3> -<ul> - <li>In general, it's best to write scripts in perl.<p> - - <li>Don't specify a hard-coded path to perl itself. Use - the following code at the top of the script to pick up - perl from the users <code>PATH</code>:<br> - <pre> - eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}' - & eval 'exec perl -S $0 $argv:q' - if 0; - </pre><p> - - <li>If your perl script relies on features only available - in never versions of perl, include the a statement similar - to the following:<br> - <pre> - require 5.003; - </pre> - - <li>Don't depend on <strong><code>.</code></strong> being - in the user's path. If the script spawns another executable - that is supposed to be in the current directory, be sure the - prefix its filename with <strong><code>.</code></strong>.<p> -</ul> - - -<hr> -<h3>Software Engineering Guidelines</h3> -<ul> - <li><strong>Advise</strong>: Keep other developers informed of problems - and progress.<p> - - <li><strong>Authorize</strong>: We have contractual obligations to not - unilaterally change interfaces. If you need to change or remove an - interface, get an OK.<p> - - <li><strong>Minimize</strong> risk: Test all changes. Solicit review of - changes.<p> - - <li><strong>Revise</strong> only when necessary: Every change has risk, - so avoid making any change unless there is a good reason for it.<p> - - <li><strong>Normalize</strong>: Factor out commonality. For example, - maintain a data value in only one place.<p> - - <li><strong>Synthesize</strong>: Build stubs and scaffolding early to - simulate the complete system. Maintain a checked-in version of the - system that cleanly builds and tests at all times.<p> -</ul> - - -<hr> -<h3><a href="http://www.cs.wustl.edu/~schmidt/rules.html">ACE - Design Rules</a></h3> - - -<hr> <P> - <font size=-1> - Last modified <!--#echo var="LAST_MODIFIED" -->.<p> - </font> - -</body> -</html> diff --git a/etc/ACE-porting.html b/etc/ACE-porting.html deleted file mode 100644 index 42b82c380ed..00000000000 --- a/etc/ACE-porting.html +++ /dev/null @@ -1,184 +0,0 @@ -<HTML> -<HEAD> - <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> - <META NAME="Generator" CONTENT="Microsoft Word 97"> - <META NAME="Template" CONTENT="C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\html -.dot"> - <META NAME="GENERATOR" CONTENT="Mozilla/4.05 [en] (Win95; I) [Netscape]"> - <TITLE>Porting ACE and TAO to a New OS Platform</TITLE> -</HEAD> -<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#FF0000"> - -<HR><P> -<H3>Porting ACE and TAO to a New OS Platform</H3><P> - -The <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A> -framework and the <A -HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</A> ORB have been -ported to <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE-versions-i.html">many OS -platforms</A>. Porting ACE and TAO to new platforms is fairly easy. -The following document describes the step-by-step process to use when -porting the various <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">components -and layers</A> in ACE to a new OS platform. Once ACE is ported, it is -straightforward to port TAO, as well.<P> - -<hr align=left width="50%"><P> -<H4>Create a <CODE>config.h</CODE> Header File for the Target OS Platform</H4> - -A <CODE>config-*.h</CODE> header file exists in <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/">$ACE_ROOT/ace</A> -for each platform to which ACE has been ported. This file contains -the portability macros for each particular configuration of ACE. A -complete description of the existent macros can be found in the <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/README">$ACE_ROOT/ace/README</A> -file. <P> - -Currently, you must edit this file by hand to port it to new OS -platforms. It's a good idea to use the <CODE>config-*.h</CODE> files -for platforms with similar characteristics as examples. Ultimately, -we plan to <A HREF="http://squall.tn.cornell.edu/aceconf">auto -configure</A> these files. <P> - -<hr align=left width="50%"><P> -<H4>Port the <CODE>ACE_OS</CODE> Class</H4> - -The <CODE>ACE_OS</CODE> class encapsulates most of variation between -the different OS implementations, <EM>e.g.</EM>, UNIX, Win32, and -various real-time operating systems. It is the core class of the ACE -OS abstraction layer. Most work required to port ACE to a new OS -platform resides in this class. There are <EM>many</EM> examples of -how ACE has been ported to other operating systems in the -<CODE>ACE_OS</CODE> class in the -<CODE>$ACE_ROOT/ace/OS.{h,i,cpp}</CODE> files. <P> - -Optional features in pthreads are covered by <CODE>ACE_HAS_*</CODE> -and/or <CODE>ACE_LACKS_*</CODE> macros, which are described in the <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/README">$ACE_ROOT/ace/README</A> -file. Particular platform features, such as DCE pthreads calls that -end in <CODE>_np</CODE>, should be bracketed by platform defines -rather than by inventing more <CODE>ACE_HAS_*</CODE> or -<CODE>ACE_LACKS_*</CODE> definitions. <P> - -An important part of porting ACE to a new platform is to map the -threading API correctly. Currently, ACE has support for the following -thread APIs: <P> - -<UL> -<LI> <B>UNIX International (UI) Threads</B> - (<CODE>ACE_HAS_STHREADS</CODE>) - Solaris 2, UnixWare. <P> - -<LI> <B>POSIX Pthreads</B> (<CODE>ACE_HAS_PTHREADS</CODE>) - drafts 4 - [DCE], 6 [FSU], 7 [AIX], as well as the final standard (also - called draft 10) [MIT, Linux, and Solaris]. <P> - -<LI> <B>Win32 Threads</B> (<CODE>ACE_HAS_WTHREADS</CODE>) - Windows - NT, Windows '95/98, and Windows CE <P> -<LI> <B>VxWorks Tasks</B> (<CODE>VXWORKS</CODE>) - VxWorks <P> -</UL> - -If your OS platform does not support any of these threading packages, -you must port the <CODE>ACE_OS::thr_*</CODE> functions. <P> - -<hr align=left width="50%"><P> -<H4>Port the C++ Wrapper Components</H4> - -After porting the <CODE>ACE_OS</CODE> class, the next step is to port -all of the ACE C++ wrapper components, such as sockets, threads, -synchronization mechanisms. A full list of the categories and classes -can be found in the <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ACE-categories">$ACE_ROOT/ACE-categories</a> -file. It is easiest to concentrate on porting one category at the -time. The ACE release contain a <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/tests/README">one-button -test suite</A> in the <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/tests/">$ACE_ROOT/tests/</A> -directory. These tests can be used to validate the correctness of the -various ACE C++ wrappers as they are ported. <P> - -<hr align=left width="50%"><P> -<H4>Port the Higher-level Framework Components of ACE</H4> - -Having ported (and tested) all the components of the ACE OS adaptation -layer and C++ wrappers, you can proceed to port the higher level -components of ACE, such as the Reactor, Service Configurator, -Connector, Acceptor, and Streams frameworks. At this point, it should -be relatively easy to port the rest of ACE because most of the -platform-dependent code is localized in the lower layers of ACE. <P> - -<hr align=left width="50%"><P> -<H4>Port TAO</H4> - -After porting and successfully testing all the ACE framework -components, it also should be relatively easy to port and <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/TAO-INSTALL.html">install</A> -TAO because all of its platform-dependent code is localized in ACE. -Typically, the only problems that arise when porting TAO is bugs with -C++ compilers. <P> - -<HR><P> -<H3>C++ Features Required to Port ACE and TAO</H3> - -ACE and TAO have been ported to most C++ compilers. The following is -a list of which C++ features a compiler must support in order to -compile ACE and TAO: - -<UL> -<LI> <B>Templates</B> -- The C++ compiler must support templates. - However, it need not support template member functions nor must it - support template traits. <P> - -<LI> <B>Multiple inheritance and dynamic binding</B> -- The C++ - compiler must support multiple inheritance and dynamic - binding. <P> -</UL> - -The following is a list of which C++ features that ACE and TAO can -take advantage of if a compiler supports them: - -<UL> -<LI> <B>Exceptions</B> -- The ACE library itself is ``exception - neutral,'' <EM>i.e.,</EM> it does not catch or throw C++ - exceptions. However, you can use exceptions in code - that uses ACE including throwing exceptions inside call back - methods, as long as you provide the code to handle it. - TAO can be configured to use C++ exceptions if ACE supports them, - <EM>i.e.</EM>, if <CODE>ACE_HAS_EXCEPTIONS</CODE> is defined. <P> - -<LI> <B>RTTI and ANSI casts</B> -- If the OS platform supports RTTI - and the new ANSI - C++ casts, <EM>i.e.</EM>, <CODE>ACE_HAS_ANSI_CASTS</CODE> is - enabled, then the various <CODE>ACE_*_cast</CODE> macros will - utilize these casts. Otherwise, the macros will default to - "C-style" casts. <P> - -<LI> <B>Namespaces</B> -- ACE does not utilize namespaces. However, - TAO will automatically take advantage of namespaces if the C++ - compiler supports them, <EM>i.e.</EM>, if - <CODE>ACE_HAS_BROKEN_NAMESPACES</CODE> is <EM>not</EM> enabled. <P> - -<LI> <B>STL</B> -- Unfortunately many of the platforms that ACE - supports don't have an STL library. Moreover, different versions - of STL behave differently. Therefore, ACE does not depends on - STL and does not use it internally. - If your target platform(s) support STL you should be able to - use it with ACE and TAO without problems, though your C++ - compiler may have problems with it (this is beyond the scope - of ACE, however). <P> - - If you are considering STL, you might consider - <A HREF="http://corp.metabyte.com/~fbp/stl/index.html">STLport</a>, - which is a port of the SGI STL to numerous platforms that ACE - and TAO also support. <P> -</UL> - -<P><HR><P> - -Back to the <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ACE-documentation.html">ACE -documentation</A> page. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</HTML> diff --git a/etc/ACE-subsets.html b/etc/ACE-subsets.html deleted file mode 100644 index a6bc60e8457..00000000000 --- a/etc/ACE-subsets.html +++ /dev/null @@ -1,684 +0,0 @@ -<HTML> - -<HEAD> -<TITLE>ACE Subsets</TITLE> - -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - -<HR> -<H3>Proposal for Splitting ACE into Multiple Libraries</H3> - -The following is a draft of our proposal for spliting ACE into -multiple libraries, each of which will contain a smaller subset of the -overall ACE functionality. The primary motivations for subsetting ACE -are: - -<UL> -<LI> <EM>Principle of parsimony</EM> -- <EM>i.e.</EM>, developers - should incur time/space overhead for components they use, rather - than for all the components in the ACE framework. <P> - -<LI> <EM>Simplify the learning curve</EM> -- <EM>i.e.</EM>, developers - only need to learn how to program components that they actually - use. <P> -</UL> - -The main design goals of this proposal are as follows: <P> - -<OL> -<LI> Support the original libACE as before. Thus, for users who -want to use the existing ACE library as is, there will be -no changes, i.e., just link with <CODE>libACE</CODE> as usual. <P> - -<LI> Allow ACE (and TAO) programmers to use smaller subsets of the -entire <CODE>libACE</CODE> library. These subsets will include the -following libraries: <P> - -<DL> - -<DT> <img alt="o" src="gifs/misc/redball.gif"> <CODE>libACE_OS</CODE> --- This library contains the OS adaptation layer and its supporting -classes. All other ACE libraries will depend on -<CODE>libACE_OS</CODE> and it will depend on <EM>no</EM> other ACE -libraries. <P> - -<DT> <img alt="o" src="gifs/misc/redball.gif"> -<CODE>libACE_Utils</CODE> -- This library contains the various ACE -container classes and other miscellaneous classes, such as Singleton, -auto_ptr, timers, etc. This library will depend only on -<CODE>libACE_OS</CODE>.<P> - -<DT> <img alt="o" src="gifs/misc/redball.gif"> -<CODE>libACE_Logging</CODE> -- This library contains the various ACE -logging and tracing classes. This library will depend only on -<CODE>libACE_OS</CODE>. <P> - -<DT> <img alt="o" src="gifs/misc/redball.gif"> -<CODE>libACE_Threads</CODE> -- This library contains the ACE -thread/process management and synchronization classes. This library -will depend only on <CODE>libACE_OS</CODE>. <P> - -<DT> <img alt="o" src="gifs/misc/redball.gif"> -<CODE>libACE_Demux</CODE> -- This library contains the ACE Reactor and -Proactor classes. This library will depend on <CODE>libACE_OS</CODE> -and <CODE>libACE_Thread</CODE>. <P> - -<DT> <img alt="o" src="gifs/misc/redball.gif"> -<CODE>libACE_Connection</CODE> -- This library contains the ACE -Connection components, i.e., Acceptor, Connector, and Svc_Handler. -This library will depend on <CODE>libACE_OS</CODE>, -<CODE>libACE_Thread</CODE>, and <CODE>libACE_Demux</CODE>. <P> - -<DT> <img alt="o" src="gifs/misc/redball.gif"> -<CODE>libACE_Sockets</CODE> -- This library contains the ACE C++ -wrappers for sockets. This library will depend on -<CODE>libACE_OS</CODE>. <P> - -<DT> <img alt="o" src="gifs/misc/redball.gif"> <CODE>libACE_IPC</CODE> --- This library contains all the ACE C++ wrappers for the other types -of IPC and FILE I/O other than sockets. This library will depend on -<CODE>libACE_OS</CODE> and <CODE>libACE_Sockets</CODE>. <P> - -<DT> <img alt="o" src="gifs/misc/redball.gif"> -<CODE>libACE_Svcconf</CODE> -- This library contains the ACE C++ -wrappers for the Service Configurator. This library will depend on -<CODE>libACE_OS</CODE>, <CODE>libACE_Demux</CODE>, -<CODE>libACE_Thread</CODE>, and <CODE>libACE_Sockets</CODE>. <P> - -<DT> <img alt="o" src="gifs/misc/redball.gif"> -<CODE>libACE_Streams</CODE> -- This library contains the ACE Streams -classes. This library will depend on <CODE>libACE_OS</CODE>, -<CODE>libACE_Demux</CODE>, and <CODE>libACE_Thread</CODE>. <P> - -<DT> <img alt="o" src="gifs/misc/redball.gif"> -<CODE>libACE_Memory</CODE> -- This library contains the ACE C++ -wrappers for shared memory and memory-mapped files. This library will -depend on <CODE>libACE_OS</CODE>.<P> - -</DL> -</OL> - -In addition, we will create <CODE>libACE_TAO</CODE>, which contains -just the core set of components in ACE that are required to support -TAO. This library is targeted at embedded systems developers who want -to minimize the footprint of ACE+TAO. <P> - -Note that the ACE library subsets described above are intended as a -guideline, <EM>not</EM> a complete specification. The actual -partitioning of files in the final ACE library subsets may differ -somewhat in order to improve footprint and simplify common -use-cases. <P> - -<HR><P> -<H3>Configuration Management</H3> - -Configuration management for the ACE library subsets described above -will be organized as follows: - -<OL> -<LI> A single source tree with a single "version" for the source - tree. <P> - -<LI> Releases of libACE and its "subsets" will be atomic, <EM>i.e.</EM>, - all or nothing. <P> -</OL> - -<HR><P> -<H3>Classes in Each ACE Library Subset</H3> - -Below, we describe the classes in each ACE library subset. - -<H4>libACE_OS</H4> - -This library contains the OS adaptation layer and its supporting -classes. The classes in this library should not depend on any other -ACE library subsets. All of the other libraries will depend on this -library. The following classes are included in this library. - -<PRE><CODE> -ACE.cpp -ACE.h -ACE.i -config.h -Basic_Types.cpp -Basic_Types.h -Basic_Types.i -OS.cpp -OS.h -OS.i -Version.h -</PRE></CODE> - -<H4>libACE_Utils</H4> - -This library contains the following ACE container classes and other -miscellaneous classes. - -<PRE><CODE> -ARGV.cpp -ARGV.h -ARGV.i -Array.cpp -Array.h -Array.i -Auto_Ptr.cpp -Auto_Ptr.h -Auto_Ptr.i -Containers.cpp -Containers.i -Containers.h -Date_Time.cpp -Date_Time.h -Date_Time.i -Dynamic.cpp -Dynamic.h -Dynamic.i -Filecache.cpp -Filecache.h -Free_List.cpp -Free_List.i -Free_List.h -Get_Opt.cpp -Get_Opt.h -Get_Opt.i -Hash_Map_Manager.cpp -Hash_Map_Manager.h -High_Res_Timer.cpp -High_Res_Timer.h -High_Res_Timer.i -Managed_Object.cpp -Managed_Object.h -Managed_Object.i -Map_Manager.cpp -Map_Manager.h -Map_Manager.i -Object_Manager.cpp -Object_Manager.i -Object_Manager.h -Profile_Timer.cpp -Profile_Timer.h -Profile_Timer.i -Registry.cpp -Registry.h -Singleton.cpp -Singleton.h -Singleton.i -SString.cpp -SString.h -SString.i -System_Time.cpp -System_Time.h -Time_Request_Reply.cpp -Time_Request_Reply.h -Time_Value.cpp -Time_Value.h -Time_Value.i -Timer_Hash.cpp -Timer_Hash.h -Timer_Hash_T.cpp -Timer_Hash_T.h -Timer_Heap.cpp -Timer_Heap.h -Timer_Heap.i -Timer_Heap_T.cpp -Timer_Heap_T.h -Timer_Heap_T.i -Timer_List.cpp -Timer_List.h -Timer_List.i -Timer_List_T.cpp -Timer_List_T.h -Timer_List_T.i -Timer_Queue.cpp -Timer_Queue.h -Timer_Queue.i -Timer_Queue_Adapters.cpp -Timer_Queue_Adapters.h -Timer_Queue_Adapters.i -Timer_Queue_T.cpp -Timer_Queue_T.h -Timer_Queue_T.i -Timer_Wheel.cpp -Timer_Wheel.h -Timer_Wheel.i -Timer_Wheel_T.cpp -Timer_Wheel_T.h -Timer_Wheel_T.i -</PRE></CODE> - -<H4>libACE_Logging</H4> - -This library contains the various ACE logging and tracing classes. - -<PRE><CODE> -Dump.cpp -Dump.h -Dump_T.cpp -Dump_T.h -Log_Msg.cpp -Log_Msg.h -Log_Msg.i -Log_Priority.h -Log_Record.cpp -Log_Record.h -Log_Record.i -Trace.cpp -Trace.h -Trace.i -</PRE></CODE> - -<H4>libACE_Threads</H4> - -This library contains the ACE thread/process management and -synchronization classes. - -<PRE><CODE> -Activation_Queue.h -Activation_Queue.cpp -Atomic_Op.i -Future.h -Future.cpp -Method_Object.h -Method_Object.cpp -Process.cpp -Process.h -Process.i -Process_Manager.cpp -Process_Manager.h -Process_Manager.i -Sched_Params.cpp -Sched_Params.h -Sched_Params.i -Synch.cpp -Synch.h -Synch.i -Synch_Options.cpp -Synch_Options.h -Synch_Options.i -Synch_T.cpp -Synch_T.h -Synch_T.i -Thread.cpp -Thread.h -Thread.i -Thread_Manager.cpp -Thread_Manager.h -Thread_Manager.i -Token.cpp -Token.h -Token.i -</PRE></CODE> - -<H4>libACE_Demux</H4> - -This library contains the ACE Reactor and its associated classes, -including the ACE Connection components. - -<PRE><CODE> -Event_Handler.cpp -Event_Handler.h -Event_Handler.i -Event_Handler_T.cpp -Event_Handler_T.h -Event_Handler_T.i -Handle_Set.cpp -Handle_Set.h -Handle_Set.i -Priority_Reactor.cpp -Priority_Reactor.i -Priority_Reactor.h -Proactor.h -Proactor.i -Proactor.cpp -Reactor.cpp -Reactor.h -Reactor.i -Reactor_Impl.h -Select_Reactor.cpp -Select_Reactor.h -Select_Reactor.i -WFMO_Reactor.cpp -WFMO_Reactor.h -WFMO_Reactor.i -XtReactor.cpp -XtReactor.h -</PRE></CODE> - -<H4>libACE_Connection</H4> - -This library contains the ACE Connection components, i.e., Acceptor, -Connector, and Svc_Handler. - -<PRE><CODE> -Acceptor.cpp -Acceptor.h -Acceptor.i -Asynch_Acceptor.cpp -Asynch_Acceptor.h -Asynch_Acceptor.i -Asynch_IO.cpp -Asynch_IO.h -Asynch_IO.i -Connector.cpp -Connector.h -Connector.i -Dynamic_Service.cpp -Dynamic_Service.h -Dynamic_Service.i -Strategies.cpp -Strategies.h -Strategies.i -Strategies_T.cpp -Strategies_T.h -Strategies_T.i -Svc_Handler.cpp -Svc_Handler.h -Svc_Handler.i -</PRE></CODE> - -<H4>libACE_Sockets</H4> - -This library contains the ACE C++ wrappers for sockets. - -<PRE><CODE> -IPC_SAP.cpp -IPC_SAP.h -IPC_SAP.i -LOCK_SOCK_Acceptor.cpp -LOCK_SOCK_Acceptor.h -LSOCK.cpp -LSOCK.h -LSOCK.i -LSOCK_Acceptor.cpp -LSOCK_Acceptor.h -LSOCK_Acceptor.i -LSOCK_CODgram.cpp -LSOCK_CODgram.h -LSOCK_CODgram.i -LSOCK_Connector.cpp -LSOCK_Connector.h -LSOCK_Connector.i -LSOCK_Dgram.cpp -LSOCK_Dgram.h -LSOCK_Dgram.i -LSOCK_Stream.cpp -LSOCK_Stream.h -LSOCK_Stream.i -SOCK.cpp -SOCK.h -SOCK.i -SOCK_Acceptor.cpp -SOCK_Acceptor.h -SOCK_Acceptor.i -SOCK_CODgram.cpp -SOCK_CODgram.h -SOCK_CODgram.i -SOCK_Connector.cpp -SOCK_Connector.h -SOCK_Connector.i -SOCK_Dgram.cpp -SOCK_Dgram.h -SOCK_Dgram.i -SOCK_Dgram_Bcast.cpp -SOCK_Dgram_Bcast.h -SOCK_Dgram_Bcast.i -SOCK_Dgram_Mcast.cpp -SOCK_Dgram_Mcast.h -SOCK_Dgram_Mcast.i -SOCK_IO.cpp -SOCK_IO.h -SOCK_IO.i -SOCK_Stream.cpp -SOCK_Stream.h -SOCK_Stream.i - -</PRE></CODE> - -<H4>libACE_IPC</H4> - -This library contains all the ACE C++ wrappers for the other types of -IPC and FILE I/O other than sockets. This library will depend on the -<CODE>libACE_Socket</CODE> library. - -<PRE><CODE> - -Addr.cpp -Addr.h -Addr.i -DEV.cpp -DEV.h -DEV.i -DEV_Addr.cpp -DEV_Addr.h -DEV_Addr.i -DEV_Connector.cpp -DEV_Connector.h -DEV_Connector.i -DEV_IO.cpp -DEV_IO.h -DEV_IO.i -FIFO.cpp -FIFO.h -FIFO.i -FIFO_Recv.cpp -FIFO_Recv.h -FIFO_Recv.i -FIFO_Recv_Msg.cpp -FIFO_Recv_Msg.h -FIFO_Recv_Msg.i -FIFO_Send.cpp -FIFO_Send.h -FIFO_Send.i -FIFO_Send_Msg.cpp -FIFO_Send_Msg.h -FIFO_Send_Msg.i -FILE_Addr.cpp -FILE_Addr.h -FILE_Addr.i -FILE.cpp -FILE.h -FILE.i -FILE_Connector.cpp -FILE_Connector.h -FILE_Connector.i -FILE_IO.cpp -FILE_IO.h -FILE_IO.i -INET_Addr.cpp -INET_Addr.h -INET_Addr.i -IO_SAP.cpp -IO_SAP.h -IO_SAP.i -IOStream.cpp -IOStream.h -IOStream_T.cpp -IOStream_T.h -IOStream_T.i -Pipe.cpp -Pipe.h -Pipe.i -Signal.cpp -Signal.h -Signal.i - -SPIPE_Addr.cpp -SPIPE_Addr.h -SPIPE_Addr.i -SPIPE.cpp -SPIPE.h -SPIPE.i -SPIPE_Acceptor.cpp -SPIPE_Acceptor.h -SPIPE_Acceptor.i -SPIPE_Connector.cpp -SPIPE_Connector.h -SPIPE_Connector.i -SPIPE_Stream.cpp -SPIPE_Stream.h -SPIPE_Stream.i -SV_Message.cpp -SV_Message.h -SV_Message.i -SV_Message_Queue.cpp -SV_Message_Queue.h -SV_Message_Queue.i -SV_Semaphore_Complex.cpp -SV_Semaphore_Complex.h -SV_Semaphore_Complex.i -SV_Semaphore_Simple.cpp -SV_Semaphore_Simple.h -SV_Semaphore_Simple.i -SV_Shared_Memory.cpp -SV_Shared_Memory.h -SV_Shared_Memory.i -TLI.cpp -TLI.h -TLI.i -TLI_Acceptor.cpp -TLI_Acceptor.h -TLI_Acceptor.i -TLI_Connector.cpp -TLI_Connector.h -TLI_Connector.i -TLI_Stream.cpp -TLI_Stream.h -TLI_Stream.i -TTY_IO.cpp -TTY_IO.h -Typed_SV_Message.cpp -Typed_SV_Message.h -Typed_SV_Message.i -Typed_SV_Message_Queue.cpp -Typed_SV_Message_Queue.h -Typed_SV_Message_Queue.i -UNIX_Addr.cpp -UNIX_Addr.h -UNIX_Addr.i -UPIPE_Addr.h -UPIPE_Acceptor.cpp -UPIPE_Acceptor.h -UPIPE_Acceptor.i -UPIPE_Connector.cpp -UPIPE_Connector.h -UPIPE_Connector.i -UPIPE_Stream.cpp -UPIPE_Stream.h -UPIPE_Stream.i -</PRE></CODE> - -<H4>libACE_Svcconf</H4> - -This library contains the ACE C++ wrappers for the Service -Configurator component. - -<PRE><CODE> -Parse_Node.cpp -Parse_Node.h -Parse_Node.i -Service_Config.cpp -Service_Config.h -Service_Config.i -Service_Main.cpp -Service_Manager.cpp -Service_Manager.h -Service_Manager.i -Service_Object.cpp -Service_Object.h -Service_Object.i -Service_Record.cpp -Service_Record.h -Service_Record.i -Service_Repository.cpp -Service_Repository.h -Service_Repository.i -Service_Types.cpp -Service_Types.i -Service_Types.h -Shared_Object.cpp -Shared_Object.h -Shared_Object.i -Svc_Conf.h -Svc_Conf_l.cpp -Svc_Conf_y.cpp -Svc_Conf_Tokens.h -</PRE></CODE> - -<H4>libACE_Streams</H4> - -This library contains the ACE Streams classes. - -<PRE><CODE> -IO_Cntl_Msg.cpp -IO_Cntl_Msg.h -IO_Cntl_Msg.i -Message_Block.cpp -Message_Block.h -Message_Block.i -Message_Queue.cpp -Message_Queue.h -Message_Queue.i -Message_Queue_T.cpp -Message_Queue_T.h -Message_Queue_T.i -Module.cpp -Module.h -Module.i -Multiplexor.cpp -Multiplexor.h -Multiplexor.i -Stream.cpp -Stream.h -Stream.i -Stream_Modules.cpp -Stream_Modules.h -Stream_Modules.i -Task.cpp -Task.h -Task.i -Task_T.cpp -Task_T.h -Task_T.i -</PRE></CODE> - -<H4>libACE_Memory</H4> - -This library contains the ACE C++ wrappers for shared memory and -memory-mapped files. - -<PRE><CODE> -Malloc.cpp -Malloc.h -Malloc.i -Malloc_T.cpp -Malloc_T.h -Malloc_T.i -Mem_Map.cpp -Mem_Map.h -Mem_Map.i -Memory_Pool.cpp -Memory_Pool.h -Memory_Pool.i -Obstack.cpp -Obstack.h -Read_Buffer.cpp -Read_Buffer.h -Read_Buffer.i -Shared_Memory.h -Shared_Memory_MM.cpp -Shared_Memory_MM.h -Shared_Memory_MM.i -Shared_Memory_SV.cpp -Shared_Memory_SV.h -Shared_Memory_SV.i -</PRE></CODE> - -<HR><P> -Back to the <A HREF="ACE.html">ACE</A> home page. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</HTML> diff --git a/etc/ACE-tutorials.html b/etc/ACE-tutorials.html deleted file mode 100644 index 63df8e7df59..00000000000 --- a/etc/ACE-tutorials.html +++ /dev/null @@ -1,83 +0,0 @@ -<TITLE>ACE Beginners' Guide</TITLE> -<BODY text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff"> - -<HR><P> -<H3>The Beginners' Guide to ACE</H3> - -The <A HREF="http://www.cs.wustl.edu/~schmidt/ACE-members.html">ACE -development team</A> is creating a set of tutorials to help ACE -newcomers learn how to use the framework effectively. <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/etc/tutorials/index.html">Follow -this link to the tutorials.</A> <P> - -<HR> -<H3>Developing New Tutorials</H3> - -Here are some general guidelines for creating tutorials: <P> - -<UL> -<LI> Choose a topic that you know very well or are just learning. -<P> - This isn't really a conflict... -<P> - If you know a topic very well, you're likely to know what is most - important to the novice and what can be left until later. If you're - just learning a topic, then you know what questions you have that - must be answered before you can continue. -<P> -<LI> Keep it simple. -<P> - Don't try to use a lot of really cool ACE features along the way. Stick - to the basic stuff and show that. Try to use a minimum of ACE objects - that are not the direct target of the tutorial. -<P> - (For instance, don't get all caught up in ACE_Singleton<> if you're - trying to show how to use an ACE_Reactor.) -<P> - If you want to show something really cool that happens to depend on - another ACE feature, do a tutorial on that other feature first! I've - found that folks will tend to get stuck on *anything* they don't - understand even if it isn't directly relevant to what you're trying - to teach. -<P> -<LI> Document the heck out of it! -<P> - There's no such thing as too much documentation. Don't worry about - repeating yourself along the way. Assume that the reader knows nothing - at all about the topic at hand and explain even the parts that you feel - are painfully obvious. -<P> - If you feel that sticking a bunch of comments in the code makes it harder - to read then stick in a label and document at the end of the file or - something. Alternately, create both a well-documented version and a - sparsely-documented version. Then folks can choose between 'em. -<P> -<LI> Over-teach it. -<P> - If there's a tutorial created for a topic that you feel strong in, - create another one anyway. Everybody tends to code a little differently. - Perhaps your tutorial style will "feel" better to some newcomers - than an existing tutorial. You won't hurt anybody's feelings if - you present the same material in a different way. -<P> -<LI> Steal existing code. -<P> - The ultimate form of code reuse :-) Seriously... grab one or more - of the existing ACE tests or examples. Then strip it down to the - bare bones & add heaps of comments. I don't think the software-police - will be coming after anyone for that! -</UL> -<P> -If this thing takes off, I'll start to organize the tutorials into -groups. For now, lets concentrate on quantity & quality. Organization -can come later... -<P> - -<HR><P> -Back to the <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE-documentation.html">ACE -documentation</A> page. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</HTML> |