diff options
Diffstat (limited to 'ACE/docs')
26 files changed, 7167 insertions, 0 deletions
diff --git a/ACE/docs/ACE-FMM.html b/ACE/docs/ACE-FMM.html new file mode 100644 index 00000000000..0430b7b9a7d --- /dev/null +++ b/ACE/docs/ACE-FMM.html @@ -0,0 +1,283 @@ +<!-- $Id$ --> + +<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> +<html> + <head> + <title>ACE FMM</title> + </head> + + <body bgcolor=#ffffff> +<center> +<font face=helvetica size=5>ACE Frequently Made Mistakes</font> + +<br> +<br> +<table border=0 cellpadding=3 cellspacing=1 width=550> + +<tr> +<td align=right valign=top> + <b>symptom</b> +</td> +<td align=left valign=top> + ACE_Task::getq() returns the error + <b>resource temporarily unavailable</b> +</td> +</tr> +<tr> +<td align=right valign=top> + <b>probable cause</b> +</td> +<td align=left valign=top> + Your Task is a subclass of ACE_Task<ACE_NULL_SYNCH> and + you are using it in a multithreaded program. +</td> +</tr> +<tr> +<td align=right valign=top> + <b>solution</b> +</td> +<td align=left valign=top> + Try using ACE_Task<ACE_MT_SYNCH> + instead so that the associated Message_Queue + is configured for access by multiple threads. +</td> +<tr><td colspan=2><hr noshade></td></tr> + +<tr> +<td align=right valign=top> + <b>symptom</b> +</td> +<td align=left valign=top> + ACE_Task::wait() throws an assert violation +</td> +</tr> +<tr> +<td align=right valign=top> + <b>probable cause</b> +</td> +<td align=left valign=top> + When you activate()d your Task, you specified + THR_DETACHED, which causes wait() to be unable to perform what you + want it to. +</td> +</tr> +<tr> +<td align=right valign=top> + <b>solution</b> +</td> +<td align=left valign=top> + Make sure you specify the flag THR_JOINABLE when activating + your ACE_Task object. +</td> +<tr><td colspan=2><hr noshade></td></tr> + + + +<tr> +<td align=right valign=top> + <b>symptom</b> +</td> +<td align=left valign=top> + Apparent race conditions when spawning threads (or activating Tasks) + from within a constructor. +</td> +</tr> +<tr> +<td align=right valign=top> + <b>probable cause</b> +</td> +<td align=left valign=top> + You are not guaranteed to have a valid <b>this</b> pointer + until the constructor has exited. Threads spawned from + a constructor are free to run + immediately, and may attempt to use an invalid <b>this</b> pointer. + +</td> +</tr> +<tr> +<td align=right valign=top> + <b>solution</b> +</td> +<td align=left valign=top> + Move your Task activations and other thread-spawning activites + <b>out</b> of the constructor. +</td> +<tr><td colspan=2><hr noshade></td></tr> + + + +<tr> +<td align=right valign=top> + <b>symptom</b> +</td> +<td align=left valign=top> + Compiler issues warnings/erros regarding using too few template + arguments, such as "'ACE_Svc_Handler' : too few template arguments". +</td> +</tr> +<tr> +<td align=right valign=top> + <b>probable cause</b> +</td> +<td align=left valign=top> + Instead of using the appropriate macro, you supplied an actual class + name as a parameter. This will fail depending upon platform and compiler, + due to the way templates are handled. +</td> +</tr> +<tr> +<td align=right valign=top> + <b>solution</b> +</td> +<td align=left valign=top> + Instead of instantiating a template class like <b>ACE_Svc_Handler<<u>ACE_SOCK_Stream</u>, ACE_NULL_SYNCH></b>, use the form of <b>ACE_Svc_Handler<<u>ACE_SOCK_STREAM</u>, ACE_NULL_SYNCH></b> which circumvents the platform peculiarities by using the macro. This also applies to some other template classes. +</td> +<tr><td colspan=2><hr noshade></td></tr> + + + +<tr> +<td align=right valign=top> + <b>symptom</b> +</td> +<td align=left valign=top> + Unable to compare ACE_thread_t variables (such as ACE_Thread::self()) + using operator== (). +</td> +</tr> +<tr> +<td align=right valign=top> + <b>probable cause</b> +</td> +<td align=left valign=top> + On some platforms, thread ids are numeric, and on some, they aren't. On some + implementations, simple a == b comparisons + are legal and sane. Some are not. + +</td> +</tr> +<tr> +<td align=right valign=top> + <b>solution</b> +</td> +<td align=left valign=top> + Use the <b>ACE_OS::thr_equal()</b> function to reliably compare thread + ids, regardless of platform. +</td> +<tr><td colspan=2><hr noshade></td></tr> + +<tr> +<td align=right valign=top> + <b>symptom</b> +</td> +<td align=left valign=top> + ACE_Reactor::run_event_loop() does not seem to function correctly + for a Reactor created in your application. +</td> +</tr> +<tr> +<td align=right valign=top> + <b>probable cause</b> +</td> +<td align=left valign=top> + You have not set the ACE_Reactor::instance() to refer to your new reactor. + run_event_loop only functions on the reactor currently installed as the + global Singleton. +</td> +</tr> +<tr> +<td align=right valign=top> + <b>solution</b> +</td> +<td align=left valign=top> + Use the <b>ACE_Reactor::instance(ACE_Reactor *, + int delete_reactor = 0)</b> static method to install your reactor as the global + Singleton before calling run_event_loop(). +</td> +<tr><td colspan=2><hr noshade></td></tr> + + + + + +<tr> +<td align=right valign=top> + <b>symptom</b> +</td> +<td align=left valign=top> +Infinite recursion when you invoke ACE_Reactor::remove_handler() +</td> +</tr> +<tr> +<td align=right valign=top> + <b>probable cause</b> +</td> +<td align=left valign=top> +You are invoking remove_handler() from within handle_close() (or a +method invoked by handle_close()) but you have not specified the +DONT_CALL flag. +</td> +</tr> +<tr> +<td align=right valign=top> + <b>solution</b> +</td> +<td align=left valign=top> +Be sure to <b>OR</b> in the DONT_CALL flag in this situation.<br> +e.g. --<br> +<ul><pre> +int MyHandler::handle_close (ACE_HANDLE handle, + ACE_Reactor_Mask close_mask) +{ + ... + my_reactor_->remove_handler( this, + ACE_Event_Handler::READ_MASK | + ACE_Event_Handler::DONT_CALL ); + ... + return 0; +} +</pre></ul> + +</td> +<tr><td colspan=2><hr noshade></td></tr> + +<!-- + +<tr> +<td align=right valign=top> + <b>symptom</b> +</td> +<td align=left valign=top> + +</td> +</tr> +<tr> +<td align=right valign=top> + <b>probable cause</b> +</td> +<td align=left valign=top> + +</td> +</tr> +<tr> +<td align=right valign=top> + <b>solution</b> +</td> +<td align=left valign=top> + +</td> +<tr><td colspan=2><hr noshade></td></tr> + +--> +<tr> +<td align=center colspan=2> +<font size=2>maintained by <a href="mailto:bob@werken.com">bob@werken.com</a></font> +</td> +</tr> + +</table> +</center> +Back to <A HREF="index.html">ACE Documentation Home</A>. +</body> +</html> + diff --git a/ACE/docs/ACE-SSL.html b/ACE/docs/ACE-SSL.html new file mode 100644 index 00000000000..b3ba856bbc5 --- /dev/null +++ b/ACE/docs/ACE-SSL.html @@ -0,0 +1,45 @@ +<HTML> +<!-- $Id$ --> +<Title>ACE+SSL</TITLE> + + <BODY text = "#000000" + link="#000fff" + vlink="#ff0f0f" + bgcolor="#ffffff"> + + <HR><P> + <H3>What is ACE+SSL?</H3> + <p>ACE plus SSL is an addition to the core classes which allow the use + of the Secure Socket Layer with the ACE framework. The following + are the core classes conditionally compiled in when you run + <code>make ssl=1</code>:</p> + <ul> + <li>ACE_SSL contains the interface to the ssl library OpenSSL. + <li><code>ACE_SSL_SOCK_Stream</code> uses an interface and + behavior nearly identical to <code>ACE_SOCK_Stream</code>, + only with the additional ssl layer functionality. + <li><code>ACE_SSL_SOCK_Acceptor</code>/<code>Connector</code> + are again similar to their <code>ACE_SOCK</code> counterparts. + </ul> + + <p>The SSL/TLS library we use is OpenSSL which is available at + <A HREF="http://www.openssl.org/">http://www.openssl.org/</A>. + This library must be installed in order to use ACE+SSL. We + cannot answer all of the questions you may have about OpenSSL, + but hopefully through using the ACE+SSL interface your questions + will be reduced.</p> + + <H3>How do I get ACE+SSL?</H3> + <p>Due to the relaxation of export restrictions we have gained + permission to distribute ACE+SSL along with the normal ACE + distribution. It can be found in $ACE_ROOT/ace/SSL. An SSL + pluggable transport for can be found in + $ACE_ROOT/TAO/orbsvcs/orbsvcs/SSLIOP. + + + <HR><P> + Back to <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html"> + ACE</A> home page. <P> + <!--#include virtual="/~schmidt/cgi-sig.html" --> + </BODY> +</HTML> diff --git a/ACE/docs/ACE-bug-process.html b/ACE/docs/ACE-bug-process.html new file mode 100644 index 00000000000..1494c0e97da --- /dev/null +++ b/ACE/docs/ACE-bug-process.html @@ -0,0 +1,182 @@ +<!-- $Id$ --> + +<HTML> + <TITLE>ACE, TAO, and CIAO Bug Fixing Policies</TITLE> + <BODY text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff"> + +<HR> +<H3>ACE, TAO, and CIAO Bug Fixing Policies</H3> + +As <A HREF="http://www.dre.vanderbilt.edu/ACE/">ACE</A>, <A +HREF="http://www.dre.vanderbilt.edu/TAO/">TAO</A>, and <A +HREF="http://www.dre.vanderbilt.edu/CIAO/">CIAO</A> have grown in +popularity the volume of mail on the <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">mailing +lists</A> and USENET newsgroup <A +HREF="news:comp.soft-sys.ace">comp.soft-sys.ace</A> has grown +considerably. While this increase is healthy, and a natural +consequence of the larger number of ACE, TAO, and CIAO users, it is +straining the resources of the researchers in the <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE-members-i.html">DOC +group</A> at <A +HREF="http://www.cs.wustl.edu/~schmidt/doc-center.html">Washington +University</A>, <A HREF="http://zen.uci.edu">UC Irvine</A> and <A +HREF="http://www.dre.vanderbilt.edu">ISIS</A> to respond to all the +traffic immediately. Prompt bug fixes from the DOC group also +discourage the creation of a larger community of <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE-members.html">users</A> and +<A +HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.htlm">commercial +support companies</A> who have deep knowledge of how ACE, TAO, and +CIAO work and can help provide bug fixes and new features. <P> + +To ensure the continued growth and maturation of ACE, TAO, and CIAO, +and to allow the user and vendor communities to evolve, please make it +a point to abide by the following policies: + +<UL> + +<LI> All bug reports to the <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">mailing +lists</A> should be submitted using the appropriate bug report form in +<A HREF="../PROBLEM-REPORT-FORM">$ACE_ROOT/PROBLEM-REPORT-FORM</A> +(for ACE), <A +HREF="../TAO/PROBLEM-REPORT-FORM">$TAO_ROOT/PROBLEM-REPORT-FORM</A> +(for TAO), <A +HREF="../TAO/CIAO/PROBLEM-REPORT-FORM">$CIAO_ROOT/PROBLEM-REPORT-FORM</A> +(for CIAO). Please use these forms since bug reports that are not +submitted in this form are likely to fall through the cracks. Here is +our policy for addressing these bug reports: <P> + +<OL> + +<LI> If a report is from someone <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE-sponsors.html">sponsoring</A> +our work we will respond to it in a very timely manner. Please +contact <A HREF="mailto:schmidt@cs.wustl.edu">me</A> if you'd like to +become a sponsor. <P> + +<LI> If it's a bug report that pertains to the latest official and/or +beta release and it also contains a fix we will try to apply this in a +timely manner. In general, people who submit good bug reports with +fixes tend to get much better help from the core DOC group team, +irrespective of whether they are sponsors or not since they are +helping our overall effort move ahead. <P> + +<LI> If it's a bug report for the latest official and/or beta release +that prevents ACE, TAO, or CIAO from working on a major platform used +by ourselves or our sponsors we'll try to fix it as time permits. <P> + +</OL> + +<LI> You should also consider entering your bug report into our <A +HREF="http://deuce.doc.wustl.edu/bugzilla/index.cgi">bug tracking +database</A> so that it's archived for future processing. As usual, +we try to address these bugs as time permits, but may not get to them +for a while unless it affects our work or the work of our +sponsors. <P> + +We encourage bug reports for those without support to be posted +initially to the <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">ACE users</A> +(<A HREF="mailto:ace-users@cs.wustl.edu">ace-users@cs.wustl.edu</A>), +<A HREF="http://www.cs.wustl.edu/~schmidt/TAO-mail.html">TAO users</A> +(<A HREF="mailto:tao-users@cs.wustl.edu">tao-users@cs.wustl.edu</A>), +and <A HREF="http://www.cs.wustl.edu/~schmidt/CIAO-mail.html">CIAO +users</A> (<A +HREF="mailto:ciao-users@cs.wustl.edu">ciao-users@cs.wustl.edu</A>) +mailing lists, where the open-source user community may already have +developed, or have an interest in developing, a solution. <P> + +<LI> While the core DOC group development team participates in this +mailing list, we cannot response to all postings. Therefore, if you +post something and don't get a reply, please do the following:<P> + +<UL> +<LI> + Check to see whether your posting made it to the list, which you + can see by checking out the <A + HREF="http://groups.google.com/groups?q=comp.soft-sys.ace&ie=UTF-8&oe=UTF-8&hl=en">comp.soft-sys.ace</A> newsgroup to see if your posting is visible. <P> + +<LI> If it's not visible, please make sure you're + <A HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">subscribed +to the mailing + list(s)</A> you sent the report to since we have a "members only" posting + requirement to minimize spam. <P> + +<LI> If it is visible and you haven't received a reply this probably means + that either no one knows the answer or no one has time to answer it. + As always, if you need more predictable help please contact one of + <A +HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.html">commercial +support</a> companies for ACE+TAO.<P> + +</UL> + +<LI> If you find a problem with a version of TAO that was released by + <A HREF="http://www.theaceorb.com/">OCI</A> then please report it + to <A + HREF="mailto:taosupport@ociweb.com">taosupport@ociweb.com</A>. + Likewise, if you find a problem with a version of TAO that was released by + <A HREF="http://www.prismtech.com">PrismTech</A> then please + report it to <A + HREF="mailto:technical-support@prismtech.com">technical-support@prismtech.com</A>. + Their versions of TAO are different from the DOC group's + version of TAO and thus they provide their own support. <P> + +<LI> If it's a general question about how to use ACE, TAO, or CIAO +feature we'll try to respond as time permits, though we will also rely +on the experience of the open-source user community to field these +types of questions, as well. You should first check out the <A +HREf="http://www.theaceorb.com/faq/">online FAQ</A> to see if your +question has already been answered. If you require consulting support +for ACE, TAO, or CIAO, please contact one of the companies that +provides <A +HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.html">commercial +support</A>.<P> + +</UL> + +Naturally, we encourage other ACE, TAO, and CIAO users to continue to +help provide fixes and advice in response to postings on the mailing +lists and newsgroup. If you have a patch that fixes a problem you've +found with our software here's the process for submitting it: + +<OL> +<LI> Use the latest contents of subversion CVS repository, i.e., + what's available from <P> + + <A HREF="https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/">https://svn.dre.vanderbilt.edu/</A> <P> + +<LI> Create a ``unified diff'' and put this into Bugzilla at <P> + + <A HREF="http://deuce.doc.wustl.edu/bugzilla/index.cgi">http://deuce.doc.wustl.edu/bugzilla/index.cgi</A> <P> + + and send an email to the appropriate <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">mailing +list(s)</A> and/or <A HREF="news:comp.soft-sys.ace">newsgroup</A> +newsgroup summarizing what the problem was and you've done to fix the +problem, i.e., use the <A HREF="../ChangeLog"</A>ChangeLog</A> +format. <P> + +<LI> Ideally, you could also create (or augment) a test program that + validates your patch and integrate it into the <A +HREF="../tests">ACE_ROOT/tests</A> directory. <P> </OL> + +Please be sensitive to the fact that the core <A +HREF="http://www.dre.vanderbilt.edu/">DOC group</A> team is +<EM>very</EM> busy, so we often don't have time to address problems +reported by non-sponsors. If you'd like an immediate response, please +contact <A HREF="mailto:schmidt@cs.wustl.edu">me</A> about becoming a +sponsor or contact one of the companies that provides <A +HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.html"> +commercial support</A> for ACE, TAO, and CIAO. <P> + +<HR><P> +Back to the <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A> page.<BR> +Back to <A HREF="index.html">ACE Documentation Home</A>. + +<!--#include virtual="/~schmidt/cgi-sig.html" --> +</BODY> +</HTML> diff --git a/ACE/docs/ACE-categories.html b/ACE/docs/ACE-categories.html new file mode 100644 index 00000000000..2d6e46223a8 --- /dev/null +++ b/ACE/docs/ACE-categories.html @@ -0,0 +1,753 @@ +<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> +<html> +<!-- $Id$ --> +<head> +<title>ACE Class Categories</title> +</head> +<body> + +<BODY text = "#000000" +link="#000fff" +vlink="#ff0f0f" +bgcolor="#ffffff"> + +<HR><P> +<h3><a href = "http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</a> Class Categories</h3> + +This document groups each file in <A +HREF="../ace">$ACE_ROOT/ace</A> +into its appropriate class category and provides a link to the C++ +source code and <A +HREF="http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/">HTML +versions</A> of the relevant manual pages</A>. <P> + +<b>[ACE]</b> +<ul> +<b>[Containers]</b> +<ul> +<li><a href = "../ace/Array.cpp">Array.cpp</a></li> +<li><a href = "../ace/Array.h">Array.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Array.html">[doxygen]</a></b> +<li><a href = "../ace/Array.inl">Array.inl</a></li> +<li><a href = "../ace/Containers.cpp">Containers.cpp</a></li> +<li><a href = "../ace/Containers.inl">Containers.inl</a></li> +<li><a href = "../ace/Containers.h">Containers.h</a></li> +<li><a href = "../ace/Hash_Map_Manager.cpp">Hash_Map_Manager.cpp</a></li> +<li><a href = "../ace/Hash_Map_Manager.h">Hash_Map_Manager.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Hash__Map__Manager.html">[doxygen]</a></b> +<li><a href = "../ace/Filecache.cpp">Filecache.cpp</a></li> +<li><a href = "../ace/Filecache.h">Filecache.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Filecache.html">[doxygen]</a></b> +<li><a href = "../ace/Free_List.cpp">Free_List.cpp</a></li> +<li><a href = "../ace/Free_List.inl">Free_List.inl</a></li> +<li><a href = "../ace/Free_List.h">Free_List.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Free__List.html">[doxygen]</a></b> +<li><a href = "../ace/Managed_Object.cpp">Managed_Object.cpp</a></li> +<li><a href = "../ace/Managed_Object.h">Managed_Object.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Managed__Object.html">[doxygen]</a></b> +<li><a href = "../ace/Managed_Object.inl">Managed_Object.inl</a></li> +<li><a href = "../ace/Map_Manager.cpp">Map_Manager.cpp</a></li> +<li><a href = "../ace/Map_Manager.h">Map_Manager.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Map__Manager.html">[doxygen]</a></b> +<li><a href = "../ace/Map_Manager.inl">Map_Manager.inl</a></li> +<li><a href = "../ace/Object_Manager.cpp">Object_Manager.cpp</a></li> +<li><a href = "../ace/Object_Manager.inl">Object_Manager.inl</a></li> +<li><a href = "../ace/Object_Manager.h">Object_Manager.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Object__Manager.html">[doxygen]</a></b> +<li><a href = "../ace/SString.cpp">SString.cpp</a></li> +<li><a href = "../ace/SString.h">SString.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SString.html">[doxygen]</a></b> +<li><a href = "../ace/SString.inl">SString.inl</a></li> +</ul> +<b>[Concurrency]</b> +<ul> +<li><a href = "../ace/Activation_Queue.h">Activation_Queue.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Activation__Queue.html">[doxygen]</a></b> +<li><a href = "../ace/Activation_Queue.cpp">Activation_Queue.cpp</a></li> +<li><a href = "../ace/Atomic_Op.inl">Atomic_Op.inl</a></li> +<li><a href = "../ace/Future.h">Future.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Future.html">[doxygen]</a></b> +<li><a href = "../ace/Future.cpp">Future.cpp</a></li> +<li><a href = "../ace/Method_Request.h">Method_Request.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Method__Request.html">[doxygen]</a></b> +<li><a href = "../ace/Method_Request.cpp">Method_Request.cpp</a></li> +<li><a href = "../ace/Process.cpp">Process.cpp</a></li> +<li><a href = "../ace/Process.h">Process.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Process.html">[doxygen]</a></b> +<li><a href = "../ace/Process.inl">Process.inl</a></li> +<li><a href = "../ace/Process_Manager.cpp">Process_Manager.cpp</a></li> +<li><a href = "../ace/Process_Manager.h">Process_Manager.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Process__Manager.html">[doxygen]</a></b> +<li><a href = "../ace/Process_Manager.inl">Process_Manager.inl</a></li> +<li><a href = "../ace/Sched_Params.cpp">Sched_Params.cpp</a></li> +<li><a href = "../ace/Sched_Params.h">Sched_Params.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Sched__Params.html">[doxygen]</a></b> +<li><a href = "../ace/Sched_Params.inl">Sched_Params.inl</a></li> +<li><a href = "../ace/Synch.cpp">Synch.cpp</a></li> +<li><a href = "../ace/Synch.h">Synch.h</a></li> +<li><a href = "../ace/Synch.inl">Synch.inl</a></li> +<li><a href = "../ace/Synch_Options.cpp">Synch_Options.cpp</a></li> +<li><a href = "../ace/Synch_Options.h">Synch_Options.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Synch__Options.html">[doxygen]</a></b> +<li><a href = "../ace/Synch_Options.inl">Synch_Options.inl</a></li> +<li><a href = "../ace/Synch_T.cpp">Synch_T.cpp</a></li> +<li><a href = "../ace/Synch_T.h">Synch_T.h</a></li> +<li><a href = "../ace/Synch_T.inl">Synch_T.inl</a></li> +<li><a href = "../ace/Thread.cpp">Thread.cpp</a></li> +<li><a href = "../ace/Thread.h">Thread.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Thread.html">[doxygen]</a></b> +<li><a href = "../ace/Thread.inl">Thread.inl</a></li> +<li><a href = "../ace/Thread_Manager.cpp">Thread_Manager.cpp</a></li> +<li><a href = "../ace/Thread_Manager.h">Thread_Manager.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Thread__Manager.html">[doxygen]</a></b> +<li><a href = "../ace/Thread_Manager.inl">Thread_Manager.inl</a></li> +<li><a href = "../ace/Token.cpp">Token.cpp</a></li> +<li><a href = "../ace/Token.h">Token.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Token.html">[doxygen]</a></b> +<li><a href = "../ace/Token.inl">Token.inl</a></li> +</ul> +<b>[Config]</b> +<ul> +<li><a href = "../ace/config.h">config.h</a></li> +<li><a href = "../ace/Basic_Types.cpp">Basic_Types.cpp</a></li> +<li><a href = "../ace/Basic_Types.h">Basic_Types.h</a></li> +<li><a href = "../ace/Basic_Types.inl">Basic_Types.inl</a></li> +<li><a href = "../ace/Version.h">Version.h</a></li> +</ul> +<b>[Connection]</b> +<ul> +<li><a href = "../ace/Acceptor.cpp">Acceptor.cpp</a></li> +<li><a href = "../ace/Acceptor.h">Acceptor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Acceptor.html">[doxygen]</a></b> +<li><a href = "../ace/Acceptor.inl">Acceptor.inl</a></li> +<li><a href = "../ace/Asynch_Acceptor.cpp">Asynch_Acceptor.cpp</a></li> +<li><a href = "../ace/Asynch_Acceptor.h">Asynch_Acceptor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Asynch__Acceptor.html">[doxygen]</a></b> +<li><a href = "../ace/Asynch_Acceptor.inl">Asynch_Acceptor.inl</a></li> +<li><a href = "../ace/Asynch_IO.cpp">Asynch_IO.cpp</a></li> +<li><a href = "../ace/Asynch_IO.h">Asynch_IO.h</a></li> +<li><a href = "../ace/Asynch_IO.inl">Asynch_IO.inl</a></li> +<li><a href = "../ace/Connector.cpp">Connector.cpp</a></li> +<li><a href = "../ace/Connector.h">Connector.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Connector.html">[doxygen]</a></b> +<li><a href = "../ace/Connector.inl">Connector.inl</a></li> +<li><a href = "../ace/Dynamic_Service.cpp">Dynamic_Service.cpp</a></li> +<li><a href = "../ace/Dynamic_Service.h">Dynamic_Service.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Dynamic__Service.html">[doxygen]</a></b> +<li><a href = "../ace/Dynamic_Service.inl">Dynamic_Service.inl</a></li> +<li><a href = "../ace/Strategies.cpp">Strategies.cpp</a></li> +<li><a href = "../ace/Strategies.h">Strategies.h</a></li> +<li><a href = "../ace/Strategies.inl">Strategies.inl</a></li> +<li><a href = "../ace/Strategies_T.cpp">Strategies_T.cpp</a></li> +<li><a href = "../ace/Strategies_T.h">Strategies_T.h</a></li> +<li><a href = "../ace/Strategies_T.inl">Strategies_T.inl</a></li> +<li><a href = "../ace/Svc_Handler.cpp">Svc_Handler.cpp</a></li> +<li><a href = "../ace/Svc_Handler.h">Svc_Handler.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Svc__Handler.html">[doxygen]</a></b> +<li><a href = "../ace/Svc_Handler.inl">Svc_Handler.inl</a></li> +</ul> +<b>[IPC]</b> +<ul> +<b>[IO_SAP]</b> +<ul> +<li><a href = "../ace/IO_SAP.cpp">IO_SAP.cpp</a></li> +<li><a href = "../ace/IO_SAP.h">IO_SAP.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__IO__SAP.html">[doxygen]</a></b> +<li><a href = "../ace/IO_SAP.inl">IO_SAP.inl</a></li> +<br> +<b>[DEV_SAP]</b> +<ul> +<li><a href = "../ace/DEV.cpp">DEV.cpp</a></li> +<li><a href = "../ace/DEV.h">DEV.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__DEV.html">[doxygen]</a></b> +<li><a href = "../ace/DEV.inl">DEV.inl</a></li> +<li><a href = "../ace/DEV_Connector.cpp">DEV_Connector.cpp</a></li> +<li><a href = "../ace/DEV_Connector.h">DEV_Connector.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__DEV__Connector.html">[doxygen]</a></b> +<li><a href = "../ace/DEV_Connector.inl">DEV_Connector.inl</a></li> +<li><a href = "../ace/DEV_IO.cpp">DEV_IO.cpp</a></li> +<li><a href = "../ace/DEV_IO.h">DEV_IO.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__DEV__IO.html">[doxygen]</a></b> +<li><a href = "../ace/DEV_IO.inl">DEV_IO.inl</a></li> +<li><a href = "../ace/TTY_IO.cpp">TTY_IO.cpp</a></li> +<li><a href = "../ace/TTY_IO.h">TTY_IO.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__TTY__IO.html">[doxygen]</a></b> +</ul> +<b>[FILE_SAP]</b> +<ul> +<li><a href = "../ace/FILE.cpp">FILE.cpp</a></li> +<li><a href = "../ace/FILE.h">FILE.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FILE.html">[doxygen]</a></b> +<li><a href = "../ace/FILE.inl">FILE.inl</a></li> +<li><a href = "../ace/FILE_Connector.cpp">FILE_Connector.cpp</a></li> +<li><a href = "../ace/FILE_Connector.h">FILE_Connector.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FILE__Connector.html">[doxygen]</a></b> +<li><a href = "../ace/FILE_Connector.inl">FILE_Connector.inl</a></li> +<li><a href = "../ace/FILE_IO.cpp">FILE_IO.cpp</a></li> +<li><a href = "../ace/FILE_IO.h">FILE_IO.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FILE__IO.html">[doxygen]</a></b> +<li><a href = "../ace/FILE_IO.inl">FILE_IO.inl</a></li> +</ul> +</ul> +<b>[IPC_SAP]</b> +<ul> +<li><a href = "../ace/IPC_SAP.cpp">IPC_SAP.cpp</a></li> +<li><a href = "../ace/IPC_SAP.h">IPC_SAP.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__IPC__SAP.html">[doxygen]</a></b> +<li><a href = "../ace/IPC_SAP.inl">IPC_SAP.inl</a></li> +<br> +<b>[Addr]</b> +<ul> +<li><a href = "../ace/Addr.cpp">Addr.cpp</a></li> +<li><a href = "../ace/Addr.h">Addr.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Addr.html">[doxygen]</a></b> +<li><a href = "../ace/Addr.inl">Addr.inl</a></li> +<li><a href = "../ace/DEV_Addr.cpp">DEV_Addr.cpp</a></li> +<li><a href = "../ace/DEV_Addr.h">DEV_Addr.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__DEV__Addr.html">[doxygen]</a></b> +<li><a href = "../ace/DEV_Addr.inl">DEV_Addr.inl</a></li> +<li><a href = "../ace/FILE_Addr.cpp">FILE_Addr.cpp</a></li> +<li><a href = "../ace/FILE_Addr.h">FILE_Addr.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FILE__Addr.html">[doxygen]</a></b> +<li><a href = "../ace/FILE_Addr.inl">FILE_Addr.inl</a></li> +<li><a href = "../ace/INET_Addr.cpp">INET_Addr.cpp</a></li> +<li><a href = "../ace/INET_Addr.h">INET_Addr.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__INET__Addr.html">[doxygen]</a></b> +<li><a href = "../ace/INET_Addr.inl">INET_Addr.inl</a></li> +<li><a href = "../ace/SPIPE_Addr.cpp">SPIPE_Addr.cpp</a></li> +<li><a href = "../ace/SPIPE_Addr.h">SPIPE_Addr.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SPIPE__Addr.html">[doxygen]</a></b> +<li><a href = "../ace/SPIPE_Addr.inl">SPIPE_Addr.inl</a></li> +<li><a href = "../ace/UNIX_Addr.cpp">UNIX_Addr.cpp</a></li> +<li><a href = "../ace/UNIX_Addr.h">UNIX_Addr.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__UNIX__Addr.html">[doxygen]</a></b> +<li><a href = "../ace/UNIX_Addr.inl">UNIX_Addr.inl</a></li> +<li><a href = "../ace/UPIPE_Addr.h">UPIPE_Addr.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__UPIPE__Addr.html">[doxygen]</a></b> +</ul> +<b>[FIFO_SAP]</b> +<ul> +<li><a href = "../ace/FIFO.cpp">FIFO.cpp</a></li> +<li><a href = "../ace/FIFO.h">FIFO.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FIFO.html">[doxygen]</a></b> +<li><a href = "../ace/FIFO.inl">FIFO.inl</a></li> +<li><a href = "../ace/FIFO_Recv.cpp">FIFO_Recv.cpp</a></li> +<li><a href = "../ace/FIFO_Recv.h">FIFO_Recv.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FIFO__Recv.html">[doxygen]</a></b> +<li><a href = "../ace/FIFO_Recv.inl">FIFO_Recv.inl</a></li> +<li><a href = "../ace/FIFO_Recv_Msg.cpp">FIFO_Recv_Msg.cpp</a></li> +<li><a href = "../ace/FIFO_Recv_Msg.h">FIFO_Recv_Msg.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FIFO__Recv__Msg.html">[doxygen]</a></b> +<li><a href = "../ace/FIFO_Recv_Msg.inl">FIFO_Recv_Msg.inl</a></li> +<li><a href = "../ace/FIFO_Send.cpp">FIFO_Send.cpp</a></li> +<li><a href = "../ace/FIFO_Send.h">FIFO_Send.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FIFO__Send.html">[doxygen]</a></b> +<li><a href = "../ace/FIFO_Send.inl">FIFO_Send.inl</a></li> +<li><a href = "../ace/FIFO_Send_Msg.cpp">FIFO_Send_Msg.cpp</a></li> +<li><a href = "../ace/FIFO_Send_Msg.h">FIFO_Send_Msg.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FIFO__Send__Msg.html">[doxygen]</a></b> +<li><a href = "../ace/FIFO_Send_Msg.inl">FIFO_Send_Msg.inl</a></li> +</ul> +<b>[SOCK_SAP]</b> +<ul> +<li><a href = "../ace/LOCK_SOCK_Acceptor.cpp">LOCK_SOCK_Acceptor.cpp</a></li> +<li><a href = "../ace/LOCK_SOCK_Acceptor.h">LOCK_SOCK_Acceptor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LOCK__SOCK__Acceptor.html">[doxygen]</a></b> +<li><a href = "../ace/LSOCK.cpp">LSOCK.cpp</a></li> +<li><a href = "../ace/LSOCK.h">LSOCK.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK.html">[doxygen]</a></b> +<li><a href = "../ace/LSOCK.inl">LSOCK.inl</a></li> +<li><a href = "../ace/LSOCK_Acceptor.cpp">LSOCK_Acceptor.cpp</a></li> +<li><a href = "../ace/LSOCK_Acceptor.h">LSOCK_Acceptor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK__Acceptor.html">[doxygen]</a></b> +<li><a href = "../ace/LSOCK_Acceptor.inl">LSOCK_Acceptor.inl</a></li> +<li><a href = "../ace/LSOCK_CODgram.cpp">LSOCK_CODgram.cpp</a></li> +<li><a href = "../ace/LSOCK_CODgram.h">LSOCK_CODgram.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK__CODgram.html">[doxygen]</a></b> +<li><a href = "../ace/LSOCK_CODgram.inl">LSOCK_CODgram.inl</a></li> +<li><a href = "../ace/LSOCK_Connector.cpp">LSOCK_Connector.cpp</a></li> +<li><a href = "../ace/LSOCK_Connector.h">LSOCK_Connector.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK__Connector.html">[doxygen]</a></b> +<li><a href = "../ace/LSOCK_Connector.inl">LSOCK_Connector.inl</a></li> +<li><a href = "../ace/LSOCK_Dgram.cpp">LSOCK_Dgram.cpp</a></li> +<li><a href = "../ace/LSOCK_Dgram.h">LSOCK_Dgram.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK__Dgram.html">[doxygen]</a></b> +<li><a href = "../ace/LSOCK_Dgram.inl">LSOCK_Dgram.inl</a></li> +<li><a href = "../ace/LSOCK_Stream.cpp">LSOCK_Stream.cpp</a></li> +<li><a href = "../ace/LSOCK_Stream.h">LSOCK_Stream.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK__Stream.html">[doxygen]</a></b> +<li><a href = "../ace/LSOCK_Stream.inl">LSOCK_Stream.inl</a></li> +<li><a href = "../ace/SOCK.cpp">SOCK.cpp</a></li> +<li><a href = "../ace/SOCK.h">SOCK.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK.html">[doxygen]</a></b> +<li><a href = "../ace/SOCK.inl">SOCK.inl</a></li> +<li><a href = "../ace/SOCK_Acceptor.cpp">SOCK_Acceptor.cpp</a></li> +<li><a href = "../ace/SOCK_Acceptor.h">SOCK_Acceptor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Acceptor.html">[doxygen]</a></b> +<li><a href = "../ace/SOCK_Acceptor.inl">SOCK_Acceptor.inl</a></li> +<li><a href = "../ace/SOCK_CODgram.cpp">SOCK_CODgram.cpp</a></li> +<li><a href = "../ace/SOCK_CODgram.h">SOCK_CODgram.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__CODgram.html">[doxygen]</a></b> +<li><a href = "../ace/SOCK_CODgram.inl">SOCK_CODgram.inl</a></li> +<li><a href = "../ace/SOCK_Connector.cpp">SOCK_Connector.cpp</a></li> +<li><a href = "../ace/SOCK_Connector.h">SOCK_Connector.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Connector.html">[doxygen]</a></b> +<li><a href = "../ace/SOCK_Connector.inl">SOCK_Connector.inl</a></li> +<li><a href = "../ace/SOCK_Dgram.cpp">SOCK_Dgram.cpp</a></li> +<li><a href = "../ace/SOCK_Dgram.h">SOCK_Dgram.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Dgram.html">[doxygen]</a></b> +<li><a href = "../ace/SOCK_Dgram.inl">SOCK_Dgram.inl</a></li> +<li><a href = "../ace/SOCK_Dgram_Bcast.cpp">SOCK_Dgram_Bcast.cpp</a></li> +<li><a href = "../ace/SOCK_Dgram_Bcast.h">SOCK_Dgram_Bcast.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Dgram_Bcast.html">[doxygen]</a></b> +<li><a href = "../ace/SOCK_Dgram_Bcast.inl">SOCK_Dgram_Bcast.inl</a></li> +<li><a href = "../ace/SOCK_Dgram_Mcast.cpp">SOCK_Dgram_Mcast.cpp</a></li> +<li><a href = "../ace/SOCK_Dgram_Mcast.h">SOCK_Dgram_Mcast.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Dgram__Mcast.html">[doxygen]</a></b> +<li><a href = "../ace/SOCK_Dgram_Mcast.inl">SOCK_Dgram_Mcast.inl</a></li> +<li><a href = "../ace/SOCK_IO.cpp">SOCK_IO.cpp</a></li> +<li><a href = "../ace/SOCK_IO.h">SOCK_IO.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__IO.html">[doxygen]</a></b> +<li><a href = "../ace/SOCK_IO.inl">SOCK_IO.inl</a></li> +<li><a href = "../ace/SOCK_Stream.cpp">SOCK_Stream.cpp</a></li> +<li><a href = "../ace/SOCK_Stream.h">SOCK_Stream.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Stream.html">[doxygen]</a></b> +<li><a href = "../ace/SOCK_Stream.inl">SOCK_Stream.inl</a></li> +</ul> +<b>[SPIPE_SAP]</b> +<ul> +<li><a href = "../ace/SPIPE.cpp">SPIPE.cpp</a></li> +<li><a href = "../ace/SPIPE.h">SPIPE.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SPIPE.html">[doxygen]</a></b> +<li><a href = "../ace/SPIPE.inl">SPIPE.inl</a></li> +<li><a href = "../ace/SPIPE_Acceptor.cpp">SPIPE_Acceptor.cpp</a></li> +<li><a href = "../ace/SPIPE_Acceptor.h">SPIPE_Acceptor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SPIPE__Acceptor.html">[doxygen]</a></b> +<li><a href = "../ace/SPIPE_Acceptor.inl">SPIPE_Acceptor.inl</a></li> +<li><a href = "../ace/SPIPE_Connector.cpp">SPIPE_Connector.cpp</a></li> +<li><a href = "../ace/SPIPE_Connector.h">SPIPE_Connector.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SPIPE__Connector.html">[doxygen]</a></b> +<li><a href = "../ace/SPIPE_Connector.inl">SPIPE_Connector.inl</a></li> +<li><a href = "../ace/SPIPE_Stream.cpp">SPIPE_Stream.cpp</a></li> +<li><a href = "../ace/SPIPE_Stream.h">SPIPE_Stream.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SPIPE__Stream.html">[doxygen]</a></b> +<li><a href = "../ace/SPIPE_Stream.inl">SPIPE_Stream.inl</a></li> +</ul> +<b>[TLI_SAP]</b> +<ul> +<li><a href = "../ace/TLI.cpp">TLI.cpp</a></li> +<li><a href = "../ace/TLI.h">TLI.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__TLI.html">[doxygen]</a></b> +<li><a href = "../ace/TLI.inl">TLI.inl</a></li> +<li><a href = "../ace/TLI_Acceptor.cpp">TLI_Acceptor.cpp</a></li> +<li><a href = "../ace/TLI_Acceptor.h">TLI_Acceptor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__TLI__Acceptor.html">[doxygen]</a></b> +<li><a href = "../ace/TLI_Acceptor.inl">TLI_Acceptor.inl</a></li> +<li><a href = "../ace/TLI_Connector.cpp">TLI_Connector.cpp</a></li> +<li><a href = "../ace/TLI_Connector.h">TLI_Connector.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__TLI__Connector.html">[doxygen]</a></b> +<li><a href = "../ace/TLI_Connector.inl">TLI_Connector.inl</a></li> +<li><a href = "../ace/TLI_Stream.cpp">TLI_Stream.cpp</a></li> +<li><a href = "../ace/TLI_Stream.h">TLI_Stream.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__TLI__Stream.html">[doxygen]</a></b> +<li><a href = "../ace/TLI_Stream.inl">TLI_Stream.inl</a></li> +</ul> +</ul> +<b>[UPIPE_SAP]</b> +<ul> +<li><a href = "../ace/UPIPE_Acceptor.cpp">UPIPE_Acceptor.cpp</a></li> +<li><a href = "../ace/UPIPE_Acceptor.h">UPIPE_Acceptor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__UPIPE__Acceptor.html">[doxygen]</a></b> +<li><a href = "../ace/UPIPE_Acceptor.inl">UPIPE_Acceptor.inl</a></li> +<li><a href = "../ace/UPIPE_Connector.cpp">UPIPE_Connector.cpp</a></li> +<li><a href = "../ace/UPIPE_Connector.h">UPIPE_Connector.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__UPIPE__Connector.html">[doxygen]</a></b> +<li><a href = "../ace/UPIPE_Connector.inl">UPIPE_Connector.inl</a></li> +<li><a href = "../ace/UPIPE_Stream.cpp">UPIPE_Stream.cpp</a></li> +<li><a href = "../ace/UPIPE_Stream.h">UPIPE_Stream.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__UPIPE__Stream.html">[doxygen]</a></b> +<li><a href = "../ace/UPIPE_Stream.inl">UPIPE_Stream.inl</a></li> +</ul> +<b>[Misc]</b> +<ul> +<li><a href = "../ace/IOStream.cpp">IOStream.cpp</a></li> +<li><a href = "../ace/IOStream.h">IOStream.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__IOStream.html">[doxygen]</a></b> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__IOStream_T.html">[doxygen]</a></b> +<li><a href = "../ace/IOStream_T.inl">IOStream_T.inl</a></li> +<li><a href = "../ace/Pipe.cpp">Pipe.cpp</a></li> +<li><a href = "../ace/Pipe.h">Pipe.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Pipe.html">[doxygen]</a></b> +<li><a href = "../ace/Pipe.inl">Pipe.inl</a></li> +<li><a href = "../ace/Signal.cpp">Signal.cpp</a></li> +<li><a href = "../ace/Signal.h">Signal.h</a></li> +<li><a href = "../ace/Signal.inl">Signal.inl</a></li> +</ul> +</ul> +<b>[Logging and Tracing]</b> +<ul> +<li><a href = "../ace/Dump.cpp">Dump.cpp</a></li> +<li><a href = "../ace/Dump.h">Dump.h</a></li> +<li><a href = "../ace/Dump_T.cpp">Dump_T.cpp</a></li> +<li><a href = "../ace/Dump_T.h">Dump_T.h</a></li> +<li><a href = "../ace/Log_Msg.cpp">Log_Msg.cpp</a></li> +<li><a href = "../ace/Log_Msg.h">Log_Msg.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Log__Msg.html">[doxygen]</a></b> +<li><a href = "../ace/Log_Msg.inl">Log_Msg.inl</a></li> +<li><a href = "../ace/Log_Priority.h">Log_Priority.h</a></li> +<li><a href = "../ace/Log_Record.cpp">Log_Record.cpp</a></li> +<li><a href = "../ace/Log_Record.h">Log_Record.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Log__Record.html">[doxygen]</a></b> +<li><a href = "../ace/Log_Record.inl">Log_Record.inl</a></li> +<li><a href = "../ace/Trace.cpp">Trace.cpp</a></li> +<li><a href = "../ace/Trace.h">Trace.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Trace.html">[doxygen]</a></b> +<li><a href = "../ace/Trace.inl">Trace.inl</a></li> +</ul> +<b>[Memory]</b> +<ul> +<b>[Mem_Map]</b> +<ul> +<li><a href = "../ace/Mem_Map.cpp">Mem_Map.cpp</a></li> +<li><a href = "../ace/Mem_Map.h">Mem_Map.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Mem__Map.html">[doxygen]</a></b> +<li><a href = "../ace/Mem_Map.inl">Mem_Map.inl</a></li> +</ul> +<b>[Shared_Malloc]</b> +<ul> +<li><a href = "../ace/Malloc.cpp">Malloc.cpp</a></li> +<li><a href = "../ace/Malloc.h">Malloc.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Malloc.html">[doxygen]</a></b> +<li><a href = "../ace/Malloc.inl">Malloc.inl</a></li> +<li><a href = "../ace/Malloc_T.cpp">Malloc_T.cpp</a></li> +<li><a href = "../ace/Malloc_T.h">Malloc_T.h</a></li> +<li><a href = "../ace/Malloc_T.inl">Malloc_T.inl</a></li> +<li><a href = "../ace/Memory_Pool.cpp">Memory_Pool.cpp</a></li> +<li><a href = "../ace/Memory_Pool.h">Memory_Pool.h</a></li> +<li><a href = "../ace/Memory_Pool.inl">Memory_Pool.inl</a></li> +</ul> +<b>[Shared_Memory]</b> +<ul> +<li><a href = "../ace/Shared_Memory.h">Shared_Memory.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Shared__Memory.html">[doxygen]</a></b> +<li><a href = "../ace/Shared_Memory_MM.cpp">Shared_Memory_MM.cpp</a></li> +<li><a href = "../ace/Shared_Memory_MM.h">Shared_Memory_MM.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Shared__Memory__MM.html">[doxygen]</a></b> +<li><a href = "../ace/Shared_Memory_MM.inl">Shared_Memory_MM.inl</a></li> +<li><a href = "../ace/Shared_Memory_SV.cpp">Shared_Memory_SV.cpp</a></li> +<li><a href = "../ace/Shared_Memory_SV.h">Shared_Memory_SV.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Shared__Memory__SV.html">[doxygen]</a></b> +<li><a href = "../ace/Shared_Memory_SV.inl">Shared_Memory_SV.inl</a></li> +</ul> +<b>[Utils]</b> +<ul> +<li><a href = "../ace/Obstack.cpp">Obstack.cpp</a></li> +<li><a href = "../ace/Obstack.h">Obstack.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Obstack.html">[doxygen]</a></b> +<li><a href = "../ace/Read_Buffer.cpp">Read_Buffer.cpp</a></li> +<li><a href = "../ace/Read_Buffer.h">Read_Buffer.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Read__Buffer.html">[doxygen]</a></b> +<li><a href = "../ace/Read_Buffer.inl">Read_Buffer.inl</a></li> +</ul> +</ul> +<b>[Misc]</b> +<ul> +<li><a href = "../ace/ARGV.cpp">ARGV.cpp</a></li> +<li><a href = "../ace/ARGV.h">ARGV.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__ARGV.html">[doxygen]</a></b> +<li><a href = "../ace/ARGV.inl">ARGV.inl</a></li> +<li><a href = "../ace/Auto_Ptr.cpp">Auto_Ptr.cpp</a></li> +<li><a href = "../ace/Auto_Ptr.h">Auto_Ptr.h</a></li> +<li><a href = "../ace/Auto_Ptr.inl">Auto_Ptr.inl</a></li> +<li><a href = "../ace/Date_Time.cpp">Date_Time.cpp</a></li> +<li><a href = "../ace/Date_Time.h">Date_Time.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Date__Time.html">[doxygen]</a></b> +<li><a href = "../ace/Date_Time.inl">Date_Time.inl</a></li> +<li><a href = "../ace/Dynamic.cpp">Dynamic.cpp</a></li> +<li><a href = "../ace/Dynamic.h">Dynamic.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Dynamic.html">[doxygen]</a></b> +<li><a href = "../ace/Dynamic.inl">Dynamic.inl</a></li> +<li><a href = "../ace/Get_Opt.cpp">Get_Opt.cpp</a></li> +<li><a href = "../ace/Get_Opt.h">Get_Opt.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Get__Opt.html">[doxygen]</a></b> +<li><a href = "../ace/Get_Opt.inl">Get_Opt.inl</a></li> +<li><a href = "../ace/Registry.cpp">Registry.cpp</a></li> +<li><a href = "../ace/Registry.h">Registry.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Registry.html">[doxygen]</a></b> +<li><a href = "../ace/Singleton.cpp">Singleton.cpp</a></li> +<li><a href = "../ace/Singleton.h">Singleton.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Singleton.html">[doxygen]</a></b> +<li><a href = "../ace/Singleton.inl">Singleton.inl</a></li> +<li><a href = "../ace/System_Time.cpp">System_Time.cpp</a></li> +<li><a href = "../ace/System_Time.h">System_Time.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__System__Time.html">[doxygen]</a></b> +</ul> +<b>[Name_Service]</b> +<ul> +<li><a href = "../ace/Local_Name_Space.cpp">Local_Name_Space.cpp</a></li> +<li><a href = "../ace/Local_Name_Space.h">Local_Name_Space.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Local__Name__Space.html">[doxygen]</a></b> +<li><a href = "../ace/Local_Name_Space_T.cpp">Local_Name_Space_T.cpp</a></li> +<li><a href = "../ace/Local_Name_Space_T.h">Local_Name_Space_T.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Name__Options.html">[doxygen]</a></b> +<li><a href = "../ace/Name_Proxy.cpp">Name_Proxy.cpp</a></li> +<li><a href = "../ace/Name_Proxy.h">Name_Proxy.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Name__Proxy.html">[doxygen]</a></b> +<li><a href = "../ace/Name_Request_Reply.cpp">Name_Request_Reply.cpp</a></li> +<li><a href = "../ace/Name_Request_Reply.h">Name_Request_Reply.h</a></li> +<li><a href = "../ace/Name_Space.cpp">Name_Space.cpp</a></li> +<li><a href = "../ace/Name_Space.h">Name_Space.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Name__Space.html">[doxygen]</a></b> +<li><a href = "../ace/Naming_Context.cpp">Naming_Context.cpp</a></li> +<li><a href = "../ace/Naming_Context.h">Naming_Context.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Naming__Context.html">[doxygen]</a></b> +<li><a href = "../ace/Registry_Name_Space.cpp">Registry_Name_Space.cpp</a></li> +<li><a href = "../ace/Registry_Name_Space.h">Registry_Name_Space.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Registry__Name__Space.html">[doxygen]</a></b> +<li><a href = "../ace/Remote_Name_Space.cpp">Remote_Name_Space.cpp</a></li> +<li><a href = "../ace/Remote_Name_Space.h">Remote_Name_Space.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Remote__Name__Space.html">[doxygen]</a></b> +</ul> +<b>[OS Adapters]</b> +<ul> +<li><a href = "../ace/ACE.cpp">ACE.cpp</a></li> +<li><a href = "../ace/ACE.h">ACE.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/namespaceACE.html">[doxygen]</a></b> +<li><a href = "../ace/ACE.inl">ACE.inl</a></li> +<li><a href = "../ace/OS.cpp">OS.cpp</a></li> +<li><a href = "../ace/OS.h">OS.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/namespaceACE__OS.html">[doxygen]</a></b> +<li><a href = "../ace/OS.inl">OS.inl</a></li> +</ul> +<b>[Reactor]</b> +<ul> +<li><a href = "../ace/Event_Handler.cpp">Event_Handler.cpp</a></li> +<li><a href = "../ace/Event_Handler.h">Event_Handler.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Event__Handler.html">[doxygen]</a></b> +<li><a href = "../ace/Event_Handler.inl">Event_Handler.inl</a></li> +<li><a href = "../ace/Event_Handler_T.cpp">Event_Handler_T.cpp</a></li> +<li><a href = "../ace/Event_Handler_T.h">Event_Handler_T.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Event__Handler__T.html">[doxygen]</a></b> +<li><a href = "../ace/Event_Handler_T.inl">Event_Handler_T.inl</a></li> +<li><a href = "../ace/Handle_Set.cpp">Handle_Set.cpp</a></li> +<li><a href = "../ace/Handle_Set.h">Handle_Set.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Handle__Set.html">[doxygen]</a></b> +<li><a href = "../ace/Handle_Set.inl">Handle_Set.inl</a></li> +<li><a href = "../ace/Priority_Reactor.cpp">Priority_Reactor.cpp</a></li> +<li><a href = "../ace/Priority_Reactor.inl">Priority_Reactor.inl</a></li> +<li><a href = "../ace/Priority_Reactor.h">Priority_Reactor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Priority__Reactor.html">[doxygen]</a></b> +<li><a href = "../ace/Proactor.h">Proactor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Proactor.html">[doxygen]</a></b> +<li><a href = "../ace/Proactor.inl">Proactor.inl</a></li> +<li><a href = "../ace/Proactor.cpp">Proactor.cpp</a></li> +<li><a href = "../ace/Reactor.cpp">Reactor.cpp</a></li> +<li><a href = "../ace/Reactor.h">Reactor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Reactor.html">[doxygen]</a></b> +<li><a href = "../ace/Reactor.inl">Reactor.inl</a></li> +<li><a href = "../ace/Reactor_Impl.h">Reactor_Impl.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Reactor__Impl.html">[doxygen]</a></b> +<li><a href = "../ace/Select_Reactor.cpp">Select_Reactor.cpp</a></li> +<li><a href = "../ace/Select_Reactor.h">Select_Reactor.h</a></li> +<li><a href = "../ace/Select_Reactor.inl">Select_Reactor.inl</a></li> +<li><a href = "../ace/WFMO_Reactor.cpp">WFMO_Reactor.cpp</a></li> +<li><a href = "../ace/WFMO_Reactor.h">WFMO_Reactor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__WFMO__Reactor.html">[doxygen]</a></b> +<li><a href = "../ace/WFMO_Reactor.inl">WFMO_Reactor.inl</a></li> +<li><a href = "../ace/XtReactor.cpp">XtReactor.cpp</a></li> +<li><a href = "../ace/XtReactor.h">XtReactor.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__XtReactor.html">[doxygen]</a></b> +</ul> +<b>[Service_Configurator]</b> +<ul> +<li><a href = "../ace/DLL.cpp">DLL.cpp</a></li> +<li><a href = "../ace/DLL.h">DLL.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__DLL.html">[doxygen]</a></b> +<li><a href = "../ace/Parse_Node.cpp">Parse_Node.cpp</a></li> +<li><a href = "../ace/Parse_Node.h">Parse_Node.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Parse__Node.html">[doxygen]</a></b> +<li><a href = "../ace/Parse_Node.inl">Parse_Node.inl</a></li> +<li><a href = "../ace/Service_Config.cpp">Service_Config.cpp</a></li> +<li><a href = "../ace/Service_Config.h">Service_Config.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Service__Config.html">[doxygen]</a></b> +<li><a href = "../ace/Service_Config.inl">Service_Config.inl</a></li> +<li><a href = "../ace/Service_Manager.cpp">Service_Manager.cpp</a></li> +<li><a href = "../ace/Service_Manager.h">Service_Manager.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Service__Manager.html">[doxygen]</a></b> +<li><a href = "../ace/Service_Manager.inl">Service_Manager.inl</a></li> +<li><a href = "../ace/Service_Object.cpp">Service_Object.cpp</a></li> +<li><a href = "../ace/Service_Object.h">Service_Object.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Service__Object.html">[doxygen]</a></b> +<li><a href = "../ace/Service_Object.inl">Service_Object.inl</a></li> +<li><a href = "../ace/Service_Repository.cpp">Service_Repository.cpp</a></li> +<li><a href = "../ace/Service_Repository.h">Service_Repository.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Service__Repository.html">[doxygen]</a></b> +<li><a href = "../ace/Service_Repository.inl">Service_Repository.inl</a></li> +<li><a href = "../ace/Service_Types.cpp">Service_Types.cpp</a></li> +<li><a href = "../ace/Service_Types.inl">Service_Types.inl</a></li> +<li><a href = "../ace/Service_Types.h">Service_Types.h</a></li> +<li><a href = "../ace/Shared_Object.cpp">Shared_Object.cpp</a></li> +<li><a href = "../ace/Shared_Object.h">Shared_Object.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Shared__Object.html">[doxygen]</a></b> +<li><a href = "../ace/Shared_Object.inl">Shared_Object.inl</a></li> +<li><a href = "../ace/Svc_Conf.h">Svc_Conf.h</a></li> +<li><a href = "../ace/Svc_Conf_l.cpp">Svc_Conf_l.cpp</a></li> +<li><a href = "../ace/Svc_Conf_y.cpp">Svc_Conf_y.cpp</a></li> +<li><a href = "../ace/Svc_Conf_Tokens.h">Svc_Conf_Tokens.h</a></li> +</ul> +<b>[Streams]</b> +<ul> +<li><a href = "../ace/IO_Cntl_Msg.cpp">IO_Cntl_Msg.cpp</a></li> +<li><a href = "../ace/IO_Cntl_Msg.h">IO_Cntl_Msg.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__IO__Cntl__Msg.html">[doxygen]</a></b> +<li><a href = "../ace/IO_Cntl_Msg.inl">IO_Cntl_Msg.inl</a></li> +<li><a href = "../ace/Message_Block.cpp">Message_Block.cpp</a></li> +<li><a href = "../ace/Message_Block.h">Message_Block.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Message__Block.html">[doxygen]</a></b> +<li><a href = "../ace/Message_Block.inl">Message_Block.inl</a></li> +<li><a href = "../ace/Message_Queue.cpp">Message_Queue.cpp</a></li> +<li><a href = "../ace/Message_Queue.h">Message_Queue.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Message__Queue.html">[doxygen]</a></b> +<li><a href = "../ace/Message_Queue.inl">Message_Queue.inl</a></li> +<li><a href = "../ace/Message_Queue_T.cpp">Message_Queue_T.cpp</a></li> +<li><a href = "../ace/Message_Queue_T.h">Message_Queue_T.h</a></li> +<li><a href = "../ace/Message_Queue_T.inl">Message_Queue_T.inl</a></li> +<li><a href = "../ace/Module.cpp">Module.cpp</a></li> +<li><a href = "../ace/Module.h">Module.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Module.html">[doxygen]</a></b> +<li><a href = "../ace/Module.inl">Module.inl</a></li> +<li><a href = "../ace/Stream.cpp">Stream.cpp</a></li> +<li><a href = "../ace/Stream.h">Stream.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Stream.html">[doxygen]</a></b> +<li><a href = "../ace/Stream.inl">Stream.inl</a></li> +<li><a href = "../ace/Stream_Modules.cpp">Stream_Modules.cpp</a></li> +<li><a href = "../ace/Stream_Modules.h">Stream_Modules.h</a></li> +<li><a href = "../ace/Stream_Modules.inl">Stream_Modules.inl</a></li> +<li><a href = "../ace/Task.cpp">Task.cpp</a></li> +<li><a href = "../ace/Task.h">Task.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Task.html">[doxygen]</a></b> +<li><a href = "../ace/Task.inl">Task.inl</a></li> +<li><a href = "../ace/Task_T.cpp">Task_T.cpp</a></li> +<li><a href = "../ace/Task_T.h">Task_T.h</a></li> +<li><a href = "../ace/Task_T.inl">Task_T.inl</a></li> +</ul> +<b>[System_V_IPC]</b> +<ul> +<b>[System_V_Message_Queues]</b> +<ul> +<li><a href = "../ace/SV_Message.cpp">SV_Message.cpp</a></li> +<li><a href = "../ace/SV_Message.h">SV_Message.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SV__Message.html">[doxygen]</a></b> +<li><a href = "../ace/SV_Message.inl">SV_Message.inl</a></li> +<li><a href = "../ace/SV_Message_Queue.cpp">SV_Message_Queue.cpp</a></li> +<li><a href = "../ace/SV_Message_Queue.h">SV_Message_Queue.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SV__Message__Queue.html">[doxygen]</a></b> +<li><a href = "../ace/SV_Message_Queue.inl">SV_Message_Queue.inl</a></li> +<li><a href = "../ace/Typed_SV_Message.cpp">Typed_SV_Message.cpp</a></li> +<li><a href = "../ace/Typed_SV_Message.h">Typed_SV_Message.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Typed__SV__Message.html">[doxygen]</a></b> +<li><a href = "../ace/Typed_SV_Message.inl">Typed_SV_Message.inl</a></li> +<li><a href = "../ace/Typed_SV_Message_Queue.cpp">Typed_SV_Message_Queue.cpp</a></ +li> +<li><a href = "../ace/Typed_SV_Message_Queue.h">Typed_SV_Message_Queue.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Typed__SV__Message__Queue.html">[doxygen]</a></b> +<li><a href = "../ace/Typed_SV_Message_Queue.inl">Typed_SV_Message_Queue.inl</a></li> +</ul> +<b>[System_V_Semaphores]</b> +<ul> +<li><a href = "../ace/SV_Semaphore_Complex.cpp">SV_Semaphore_Complex.cpp</a></li> +<li><a href = "../ace/SV_Semaphore_Complex.h">SV_Semaphore_Complex.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SV__Semaphore__Complex.html">[doxygen]</a></b> +<li><a href = "../ace/SV_Semaphore_Complex.inl">SV_Semaphore_Complex.inl</a></li> +<li><a href = "../ace/SV_Semaphore_Simple.cpp">SV_Semaphore_Simple.cpp</a></li> +<li><a href = "../ace/SV_Semaphore_Simple.h">SV_Semaphore_Simple.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SV__Semaphore__Simple.html">[doxygen]</a></b> +<li><a href = "../ace/SV_Semaphore_Simple.inl">SV_Semaphore_Simple.inl</a></li> +</ul> +<b>[System_V_Shared_Memory]</b> +<ul> +<li><a href = "../ace/SV_Shared_Memory.cpp">SV_Shared_Memory.cpp</a></li> +<li><a href = "../ace/SV_Shared_Memory.h">SV_Shared_Memory.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SV__Shared__Memory.html">[doxygen]</a></b> +<li><a href = "../ace/SV_Shared_Memory.inl">SV_Shared_Memory.inl</a></li> +</ul> +</ul> +<b>[Timers]</b> +<ul> +<li><a href = "../ace/High_Res_Timer.cpp">High_Res_Timer.cpp</a></li> +<li><a href = "../ace/High_Res_Timer.h">High_Res_Timer.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__High__Res__Timer.html">[doxygen]</a></b> +<li><a href = "../ace/High_Res_Timer.inl">High_Res_Timer.inl</a></li> +<li><a href = "../ace/Profile_Timer.cpp">Profile_Timer.cpp</a></li> +<li><a href = "../ace/Profile_Timer.h">Profile_Timer.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Profile__Timer.html">[doxygen]</a></b> +<li><a href = "../ace/Profile_Timer.inl">Profile_Timer.inl</a></li> +<li><a href = "../ace/Time_Request_Reply.cpp">Time_Request_Reply.cpp</a></li> +<li><a href = "../ace/Time_Request_Reply.h">Time_Request_Reply.h</a></li> +<li><a href = "../ace/Time_Value.h">Time_Value.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Time__Value.html">[doxygen]</a></b> +<li><a href = "../ace/Timer_Hash.cpp">Timer_Hash.cpp</a></li> +<li><a href = "../ace/Timer_Hash.h">Timer_Hash.h</a></li> +<li><a href = "../ace/Timer_Hash_T.cpp">Timer_Hash_T.cpp</a></li> +<li><a href = "../ace/Timer_Hash_T.h">Timer_Hash_T.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Timer__Hash__T.html">[doxygen]</a></b> +<li><a href = "../ace/Timer_Heap.cpp">Timer_Heap.cpp</a></li> +<li><a href = "../ace/Timer_Heap.h">Timer_Heap.h</a></li> +<li><a href = "../ace/Timer_Heap_T.cpp">Timer_Heap_T.cpp</a></li> +<li><a href = "../ace/Timer_Heap_T.h">Timer_Heap_T.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Timer__Heap__T.html">[doxygen]</a></b> +<li><a href = "../ace/Timer_List.cpp">Timer_List.cpp</a></li> +<li><a href = "../ace/Timer_List.h">Timer_List.h</a></li> +<li><a href = "../ace/Timer_List_T.cpp">Timer_List_T.cpp</a></li> +<li><a href = "../ace/Timer_List_T.h">Timer_List_T.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Timer__List__T.html">[doxygen]</a></b> +<li><a href = "../ace/Timer_Queue.cpp">Timer_Queue.cpp</a></li> +<li><a href = "../ace/Timer_Queue.h">Timer_Queue.h</a></li> +<li><a href = "../ace/Timer_Queue.inl">Timer_Queue.inl</a></li> +<li><a href = "../ace/Timer_Queue_Adapters.cpp">Timer_Queue_Adapters.cpp</a></li> +<li><a href = "../ace/Timer_Queue_Adapters.h">Timer_Queue_Adapters.h</a></li> +<li><a href = "../ace/Timer_Queue_Adapters.inl">Timer_Queue_Adapters.inl</a></li> +<li><a href = "../ace/Timer_Queue_T.cpp">Timer_Queue_T.cpp</a></li> +<li><a href = "../ace/Timer_Queue_T.h">Timer_Queue_T.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Timer__Queue__T.html">[doxygen]</a></b> +<li><a href = "../ace/Timer_Queue_T.inl">Timer_Queue_T.inl</a></li> +<li><a href = "../ace/Timer_Wheel.cpp">Timer_Wheel.cpp</a></li> +<li><a href = "../ace/Timer_Wheel.h">Timer_Wheel.h</a></li> +<li><a href = "../ace/Timer_Wheel_T.cpp">Timer_Wheel_T.cpp</a></li> +<li><a href = "../ace/Timer_Wheel_T.h">Timer_Wheel_T.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Timer__Wheel__T.html">[doxygen]</a></b> +</ul> +<b>[Token_Service]</b> +<ul> +<li><a href = "../ace/Local_Tokens.cpp">Local_Tokens.cpp</a></li> +<li><a href = "../ace/Local_Tokens.h">Local_Tokens.h</a></li> +<li><a href = "../ace/Local_Tokens.inl">Local_Tokens.inl</a></li> +<li><a href = "../ace/Remote_Tokens.cpp">Remote_Tokens.cpp</a></li> +<li><a href = "../ace/Remote_Tokens.h">Remote_Tokens.h</a></li> +<li><a href = "../ace/Remote_Tokens.inl">Remote_Tokens.inl</a></li> +<li><a href = "../ace/Token_Collection.cpp">Token_Collection.cpp</a></li> +<li><a href = "../ace/Token_Collection.h">Token_Collection.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Token__Collection.html">[doxygen]</a></b> +<li><a href = "../ace/Token_Collection.inl">Token_Collection.inl</a></li> +<li><a href = "../ace/Token_Manager.cpp">Token_Manager.cpp</a></li> +<li><a href = "../ace/Token_Manager.h">Token_Manager.h</a></li> +<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Token__Manager.html">[doxygen]</a></b> +<li><a href = "../ace/Token_Manager.inl">Token_Manager.inl</a></li> +<li><a href = "../ace/Token_Request_Reply.cpp">Token_Request_Reply.cpp</a></li> +<li><a href = "../ace/Token_Request_Reply.h">Token_Request_Reply.h</a></li> +<li><a href = "../ace/Token_Request_Reply.inl">Token_Request_Reply.inl</a></li> +<li><a href = "../ace/Token_Invariants.h">Token_Invariants.h</a></li> +<li><a href = "../ace/Token_Invariants.inl">Token_Invariants.inl</a></li> +<li><a href = "../ace/Token_Invariants.cpp">Token_Invariants.cpp</a></li> +</ul> +</ul> + +<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> diff --git a/ACE/docs/ACE-configuration.txt b/ACE/docs/ACE-configuration.txt new file mode 100644 index 00000000000..50738880854 --- /dev/null +++ b/ACE/docs/ACE-configuration.txt @@ -0,0 +1,180 @@ +* $Id$ * + +================================================================ +Configuring ACE Using the `configure' Script +================================================================ + +QuickStart +---------- +GNU Autoconf support in ACE is still under development. However it is +a small subset of Autoconf support in ACE has been made available for +testing and feedback purposes. To use Autoconf support in ACE, do +something like the following: + + cd ACE_wrappers + mkdir objdir + cd objdir + +Then: + Bourne Shell: CXX=c++ ../configure + C Shell: env CXX=c++ ../configure +make + +Description +----------- +To help speed development, the work being done by the ACE +Configuration Project is being slowly introduced into the official ACE +distribution. Some of the functionality in the work created by the +ACE Configuration Project has been removed so that ACE may be built in +the usual fashion. Once the ACE Configuration Project work stabilizes +on more platforms that removed functionality may be added to ACE. + +Currently the configure script contains most of the tests that are +necessary to properly configure ACE on most platforms. However, there +are still some autoconf tests that are missing. As such, you may +encounter and most likely will have compilation problems. Please +report any problems to the contacts listed at the end of this +document. + +The `configure' script that is currently being used has been modified +from the ACE Configuration Project's `configure' script to prevent +makefiles from being automatically generated since there are still +some issues that must be addressed before automatically generated +makefiles are incorporated into the official ACE distribution. + +A listing of available configure script options can be shown by +entering: + + ./configure --help + +at the command line. The output should look something like the +following: + + +Usage: configure [options] [host] +Options: [defaults in brackets after descriptions] +Configuration: + --cache-file=FILE cache test results in FILE + --help print this message + --no-create do not create output files + --quiet, --silent do not print `checking...' messages + --version print the version of autoconf that created configure +Directory and file names: + --prefix=PREFIX install architecture-independent files in PREFIX + [/usr/local] + --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX + [same as prefix] + --bindir=DIR user executables in DIR [EPREFIX/bin] + --sbindir=DIR system admin executables in DIR [EPREFIX/sbin] + --libexecdir=DIR program executables in DIR [EPREFIX/libexec] + --datadir=DIR read-only architecture-independent data in DIR + [PREFIX/share] + --sysconfdir=DIR read-only single-machine data in DIR [PREFIX/etc] + --sharedstatedir=DIR modifiable architecture-independent data in DIR + [PREFIX/com] + --localstatedir=DIR modifiable single-machine data in DIR [PREFIX/var] + --libdir=DIR object code libraries in DIR [EPREFIX/lib] + --includedir=DIR C header files in DIR [PREFIX/include] + --oldincludedir=DIR C header files for non-gcc in DIR [/usr/include] + --infodir=DIR info documentation in DIR [PREFIX/info] + --mandir=DIR man documentation in DIR [PREFIX/man] + --srcdir=DIR find the sources in DIR [configure dir or ..] + --program-prefix=PREFIX prepend PREFIX to installed program names + --program-suffix=SUFFIX append SUFFIX to installed program names + --program-transform-name=PROGRAM + run sed PROGRAM on installed program names +Host type: + --build=BUILD configure for building on BUILD [BUILD=HOST] + --host=HOST configure for HOST [guessed] + --target=TARGET configure for TARGET [TARGET=HOST] +Features and packages: + --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) + --enable-FEATURE[=ARG] include FEATURE [ARG=yes] + --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] + --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) + --x-includes=DIR X include files are in DIR + --x-libraries=DIR X library files are in DIR +--enable and --with options recognized: + --enable-static[=PKGS] build static libraries [default=no] + --enable-shared[=PKGS] build shared libraries [default=yes] + --with-gnu-ld assume the C compiler uses GNU ld [default=no] + --disable-libtool-lock force libtool not to do file locking + --enable-debug enable debugging [default=yes] + --enable-exceptions enable C++ exception handling [default=yes] + --enable-fast enable -fast flag, e.g. Sun C++ [default=no] + --enable-inline enable code inlining [default=yes] + --enable-log-msg-prop enable threads inheriting + ACE_Log_Msg properties from parent + thread [default=yes] + --enable-logging enable ACE logging macros [default=yes] + --enable-malloc-stats enable malloc statistics + collection [default=no] + --enable-optimize enable additional optimizations [default=yes] + --enable-probe enable ACE_Timeprobes [default=no] + --enable-profile enable profiling [default=no] + --enable-purify Purify all executables [default=no] + --enable-quantify Quantify all executables [default=no] + --enable-reentrant enable reentrant functions [default=yes] + --enable-repo use GNU template repository + GNU C++ with repo patches and + EGCS only [default=no] + --enable-rtti enable run-time type + identification + *Currently only for Sun C++ [default=no] + --enable-static-obj-mgr enable static Object_Manager [default=yes] + --enable-threads enable thread support [default=yes] + --enable-verb-not-sup enable verbose ENOTSUP reports [default=no] + --enable-trace enable ACE tracing [default=no] + --enable-xt-reactor build support for the XtReactor [default=no] + --with-x use the X Window System + --with-gperf compile the gperf program [default=yes] + --with-tli-device[=DEV] device for TCP on TLI [default=/dev/tcp] + +To enable debugging and disable code inlining, for example, just enter +the following on the command line: + + ./configure --enable-debug --disable-inline + +This will generate a configuration header file `ace/config.h' to be +used when compiling ACE that will enable ACE debugging macros and +disable code inlining during compilation of ACE. + +Once the `ace/config.h' header has been created you will have to +select a platform macros file. Please read the ACE installation +documents for more information about this. + +---------------------------------------------------------------- +Caveats +---------------------------------------------------------------- +The `configure' script will check for libraries that contain certain +functions. If it finds a library that isn't listed in your +platform_macros.GNU file you will have to add that library to the list +of libraries to link against. + +Shared library generation when using ACE Autoconf support is different +from the stock ACE shared library generation mechanism. The Autoconf +supported shared library mechanism does not yet fully support all of +the platforms ACE's stock shared library mechanism supports. As such, +you may encounter problems if an attempt is made to build a shared +library when using ACE's autoconf support. + +Remember that the stock ACE build procedure is always available. If +your attempts to use ACE's Autoconf support are unsuccessful then +contact the parties listed below, and use ACE stock build procedure as +described in ACE-INSTALL.html. + +---------------------------------------------------------------- +Contacts +---------------------------------------------------------------- +If you do have problems please e-mail the ACE Configuration Project +maintainer at: + + Ossama Othman <ossama@uci.edu> + +or send mail to the ACE mailing list. + +For more information take at a look at the ACE Configuration Project +web page at: + + http://www.cs.wustl.edu/~othman/aceconf + diff --git a/ACE/docs/ACE-development-process.html b/ACE/docs/ACE-development-process.html new file mode 100644 index 00000000000..ecae894332e --- /dev/null +++ b/ACE/docs/ACE-development-process.html @@ -0,0 +1,185 @@ +<!-- $Id$ --> + +<html> + <head> + <title>ACE+TAO Development and Release Process</title> + <link rev=made href="mailto:levine@cs.wustl.edu"> + </head> + +<body text = "#000000" +link="#000fff" +vlink="#ff0f0f" +bgcolor="#ffffff"> + +<hr> +<h3>The ACE+TAO Development and Release Process</h3> + +To improve the quality of our software and minimize development +effort, we try to follow the structured development and release +process described below.<p> + +An important concept to keep in mind is <em>risk</em>. Before you +commit <em>any</em> change to ACE+TAO, please consider the effects +that it will have. Could it possibly cause a build failure, on any +platform? Could it possibly cause different run-time behavior? And +so on. If so, it is your responsibility to adequately build and test +with the change, in order to verify that it has no unintended +effects.<p> + +Please keep in mind the cost of committing a mistake. It may take you +only a few seconds to fix, but its cost to the group may be much +larger. With our large group, workspace updates and builds are likely +to happen at any time. If one break, it can take hours to rebuild it. +And each developer that was waiting for a successful build would be +blocked for the duration of the broken build, the fix, and the +rebuild.<p> + +<hr> +<h3>The ACE+TAO+CIAO Development Process</h3> + +The ACE+TAO+CIAO development process looks like:<p> +<ol> + <li>Every change to ACE+TAO must have a bug report. <em>Change</em> + includes fixes, enhancements, updates, and so on. + <li><a href="http://deuce.doc.wustl.edu/bugzilla/index.cgi">Create a +bug report</a>. + <li>Accept the bug report if you are going to implement the change. + <li>Implement the change in your workspace(s). + <li>Test the change sufficiently to demonstrate that it both does + what is intended, and doesn't break anything. The test may be + as simple as building and running the ACE+TAO tests on at least two + platforms. + Or as complicated as rebuilding and test all of ACE+TAO on + all platforms that we have. + <li>Create an appropriate ChangeLog entry. + <li>Commit the change using a ChangeLogTag commit message only when + you are available the next 3 days to resolve any issues. + If you aren't available, hold your commit until you are available + <li>Respond to the requester of the change, if any. Please do this + <em>after</em> committing your change. + <li>Make sure that the requester is listed in the THANKS file. + <li>Update the bug report to indicate resolution. + <li>Monitor the next round of build/tests for problems with your change. + Because there are slow systems it can take up to 4 days to get all builds done. + <li>Respond immediately to reports of problems with your changes. +</ol> + +<p><hr> +<H3>Bug Lifecycles</H3> +<P> + +A bug should typically follow this life cycle:<p> +<center><table cellpadding=5 border=0> +<tr> + <td>Submitter:</td> + <td>Enters problem</td> +<tr> + <td>Bugmaster:</td> + <td>Assigns</td> +<tr> + <td>Owner:</td> + <td>Accepts</td> +<tr> + <td>Owner:</td> + <td>Reproduces problem - if it needs a new test, write it and + put it in the regression tests. + If it can't be reproduced, set to Resolved/CANT_FIND.<br> + If it's a duplicate, set it to Resolved/DUPLICATE. + Fix code, commit changes, set to Resolved.</td> +<tr> + <td>Submitter:</td> + <td>Tests it again; set to Verified (pass) or Reopened (fail)</td> +<tr> + <td>Owner:</td> + <td>After next release is done, re-test; sets to Closed or Reopened.</td> +</table></center> + +<p><hr> +<H3>The Role of the Build Czar</H3> +<P> + +At all times, we'll have a build czar. The role may be shared by +multiple people. The build czar is responsible for ensuring that the +next kits are clean, <em>i.e.</em>, it builds and runs cleanly on all +platforms. The status of all ACE+TAO builds is tracked automatically +<A HREF="http://tao.doc.wustl.edu/scoreboard/"</A>online</A>.<p> + +A comprehensive summary of the build czar's role is available <A HREF="bczar/bczar.html">here</A>. +This role is briefly summarized below:<p> +<ul> + <li>Remind people to check build logs. Developers are still + responsible for verifying that their changes are clean. + <li>Fix minor problems caused by compilation errors. More complex + problems should be fixed by the developers who caused them. The + build czar should help track down the guilty parties. + <li>Freeze the CVS repository when it's decided to no more + non-critical changes will be accepted for the next kits. + The build czar has the final say over when the freeze is + implemented. The tendency to implement a freeze sooner than + later is intentional, desirable, beneficial, and the "Right Thing"[TM] + to do. + <li>Verifies that the final round of builds/tests are clean. + <li>Creates the kits. + <li>Unfreezes the CVS repository. + <li>Sends email to appropriate news groups announcing the new kits. + <li>Passes the mantle on to the next build czar.<p> +</ul> + +If another developer interferes with the build czar's duties, the +build czar has the unilateral authority to pass the mantle to the +violator. This is also intentional, desirable, beneficial, and the +Right Thing[TM] to do.<p> + +<p><hr> +<H3>The ACE+TAO+CIAO Release Process</H3> +<P> + +Minor releases of ACE+TAO+CIAO occur periodically, typically twice a +year. Minor releases have two-digit numbers, <EM>e.g.,</EM> 5.3. +Major releases are released infrequently, typically once a year. +Major releases are 1-digit numbers, <EM>e.g.,</EM>5, that include +substantially new functionality. Both major and minor releases are +carefully tested on all platforms the ACE+TAO run on. In particular, +we do not put out major or minor releases of ACE+TAO+CIAO until all the +compilations and regression tests work successful on all the platform +we support. <P> + +Between major/minor releases, we release betas periodically, +<EM>e.g.,</EM> once a month, so that ACE+TAO+CIAO users can download +and test our latest work in progress. ACE+TAO+CIAO beta kits have +three-digit numbers, <EM>e.g.,</EM> 5.3.1. Betas are often not as +stable as the major or minor releases, but they often contain +important fixes that aren't in the official releases. Although we try +to ensure the quality of betas, they may not compile cleanly on all +platforms, nor will they necessarily pass all of the tests on all +platforms. They will, however, compile cleanly and pass most tests on +most platforms. As usual, we endeavor to fix any problems that arise +as quickly as possible. Naturally, if you require 100% predictable +stability and support, please contact one of the companies that +provides <A +HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.html"> +commercial support</A> for ACE+TAO.<P> + +The first beta following a major/minor release is called a +<EM>bug-fix-only</EM> (BFO) beta. As the name implies this beta will +have only fixes for the major or minor releases just made. Types of +fixes and checkins that are allowed to go in for the BFO include, bug +fixes in the implementation, fixes to the build systems like +Makefiles, project files, and MPC files, adding new tests and +examples, fixes to the documentation etc. Fixes that are definitely +not allowed include, changes to the public interface, refactoring +implementations, removing files from the repository, adding new files +into the repository etc. The idea is to allow commercial support +vendors to stabilize the major or minor release for their product +offerings. <p> + +<hr><p> + <font size=-1> + Last modified +<!--#echo var="LAST_MODIFIED" -->.<p> + </font><hr> + +Back to <A HREF="index.html">ACE Documentation Home</A>. + +</body> +</html> diff --git a/ACE/docs/ACE-guidelines.html b/ACE/docs/ACE-guidelines.html new file mode 100644 index 00000000000..f54c5f76707 --- /dev/null +++ b/ACE/docs/ACE-guidelines.html @@ -0,0 +1,1340 @@ +<!-- $Id$ --> + +<html> + <head> + <title>ACE Software Development Guidelines</title> + <link rev=made href="mailto:ace-users@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>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> + + <li>Try to limit the length of source code lines to less than 80 + characters. Users with 14 inch monitors appreciate it when + reading code. And, it avoids mangling problems with email + and net news.<p> + + <li>Try to avoid creating files with excessively long names (45 characters). + Moreover, ensure that the names of generated files e.g. <code>MakeProjectCreator</code>, + <code>tao_idl</code> do not also go beyond that limit. Some operating + systems cannot handle very long file names correctly.<p> + + <li>If you add a comment to code that is directed to, or + requires the attention of, a particular individual: + <strong>SEND EMAIL TO THAT INDIVIDUAL!</strong>.<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>An ACE-using program's entry point should use the portable form: + <pre> + int ACE_TMAIN (int argc, ACE_TCHAR *argv[]) + </pre> + This form is portable to all ACE platforms whether using narrow + or wide characters. The other two common forms: + <pre> + int main (int argc, char *argv[]) + int wmain (int argc, wchar_t *argv[]) + </pre> + as well as any other main entrypoint form should only be used + when there is some overarching reason to not use the portable form. + One example would be a Windows GUI program that requires WinMain. + <p>See <a href="wchar.txt"><code>$ACE_ROOT/docs/wchar.txt</code></a> + for more information on ACE support on <code>wchar</code>.<p> + + <li>The program entry point function, in any form mentioned above, must + always be declared with arguments, <em>e.g.</em>, + <pre> + int + ACE_TMAIN (int argc, ACE_TCHAR *argv[]) + { + [...] + + return 0; + } + </pre><p> + + If you don't use the <code>argc</code> and/or <code>argv</code> + arguments, don't declare them, <em>e.g.</em>, + <pre> + int + ACE_TMAIN (int, ACE_TCHAR *[]) + { + [...] + + return 0; + } + </pre><p> + + Please declare the second argument as <code>ACE_TCHAR *[]</code> + instead of <code>ACE_TCHAR **</code> or <code>char *[]</CODE>. + Ancient versions of MSC++ + complained about <code>ACE_TCHAR **</code> and <code>char + *[]</CODE> is not Unicode-compliant.<p> + + <code>main</code> must also return 0 on successful + termination, and non-zero otherwise.<p> + + <li>Avoid use of floating point types (<code>float</code> and + <code>double</code>) and operations + unless absolutely necessary. Not all ACE platforms support them. + Therefore, wherever they are used, <code>ACE_LACKS_FLOATING_POINT</code> + conditional code must be also be used.<p> + + <li>Avoid including the string "<code>Error</code>" in a source + code filename. GNU Make's error messages start with + "<code>Error</code>". So, it's much easier to search for + errors if filenames don't contain "<code>Error</code>".<p> + + + <li>Narrow interfaces are better than wide interfaces. If there + isn't a need for an interface, leave it out. This eases maintenance, + minimizes footprint, and reduces the likelihood of interference + when other interfaces need to be added later. (See the + <a href="#ACE_Time_Value example">ACE_Time_Value</a> example + .<p> + + <li> Never use <CODE>assert()</CODE> macros or related constructs + (such as abort()) calls in core ACE, TAO, and CIAO + library/framework code. These macros are a major problem for + production software that uses this code since the + error-handling strategy (i.e., abort the process) is + excessive. Instead, extract out the expressions from + assert() macros and use them as + precondition/postconditions/invariants in the + software and return any violations of these + conditions/invariants via exceptions or error return values. + It's fine to use <CODE>assert()</CODE> macros et al. in test + programs, but make sure these tests never find their way into + the core ACE, TAO, and CIAO library/framework code base. <P> + + </ul> + + <li><strong>Code Documentation</strong><p> + <ul> + <li>Use comments and whitespace (:-) liberally. Comments + should consist of complete sentences, <em>i.e.</em>, start + with a capital letter and end with a period.<p> + + <li>Insert a svn 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. SVN + 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>Be sure to follow the guidelines and restrictions for use of the + documentation tools for ACE + header files, which must follow the + <a href="http://www.doxygen.org/">Doxygen</a> + format requirements. + The complete documentation for Doxygen is available in the + <a href="http://www.stack.nl/~dimitri/doxygen/download.html#latestman"> + Doxygen 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> + <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 use <strong><code>#if defined (MACRONAME)</code></strong> + to test if a macro is defined, rather than the simpler + <strong><code>#if MACRONAME</code></strong>. Doxygen requires this. + The one exception to this the macros used to prevent multiple + inclusion of header files, as shown below. + + <li>Always follow a preprocessor <strong><code>#endif</code></strong> + with a <strong><code>/* */</code></strong> C-style comment. Using + C-style comments with preprocessor code is required for some old + compilers. 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>Be sure to put spaces around comment delimiters, e.g., + <strong><code>char * /* foo */</code></strong> instead of + <strong><code>char */*foo*/</code></strong>. MS VC++ + complains otherwise.<p> + + <li>Always insert a <strong><code>/**/</code></strong> between an + <strong><code>#include</code></strong> and + <strong><code>filename</code></strong>, for system headers and + <strong><code>ace/pre.h</code></strong> and + <strong><code>ace/post.h</code></strong> as + shown in the above example. This avoids dependency problems + with Visual C++ and prevents Doxygen from including the + headers in the file reference trees. <p> + + <li>Be very careful with names of macros, <code>enum</code> values, and variables + 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 <code>#define</code> <code>OK</code>, <code>SUCCESS</code>, + <code>ERROR</code>, <code>index</code>, <code>s_type</code>, + and so on.<p> + + <li>When using macros in an arithmetic expression, be sure to test + that the macro is defined, using <code>defined(<em>macro</em>)</code> before specifying + the expression. For example: +<pre> +#if __FreeBSD__ < 3 +</pre> + +will evaluate true on any platform where <code>__FreeBSD__</code> is +not defined. The correct way to write that guard is: +<pre> +#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> + #if defined(ACE_PSOS) + typedef long ACE_NETIF_TYPE; + # define ACE_DEFAULT_NETIF 0 + #else /* ! ACE_PSOS */ + typedef const TCHAR* ACE_NETIF_TYPE; + # define ACE_DEFAULT_NETIF ASYS_TEXT("le0") + #endif /* ! ACE_PSOS */ + </pre><p> + + instead of: + + <pre><p> + #if defined (ACE_PSOS) + // pSOS supports numbers, not names for network interfaces + long net_if, + #else /* ! ACE_PSOS */ + const TCHAR *net_if, + #endif /* ! ACE_PSOS */ + </pre><p> + + <li>Protect header files against multiple inclusion with this + construct: + <pre> + #ifndef FOO_H + #define FOO_H + + [contents of header file] + + #endif /* FOO_H */ + </pre><p> + + This exact construct (note the <code>#ifndef</code>) + is optimized by many compilers such they only open the + file once per compilation unit. Thanks to Eric C. Newton + <ecn@smart.net> for pointing that out.<p> + + If the header <code>#include</code>s an ACE library header, + then it's a good idea to include the <code>#pragma once</code> + directive: + <pre> + #ifndef FOO_H + #define FOO_H + + #include "ace/ACE.h" + #if !defined (ACE_LACKS_PRAGMA_ONCE) + # pragma once + #endif /* ACE_LACKS_PRAGMA_ONCE */ + + [contents of header file] + + #endif /* FOO_H */ + </pre><p> + + <code>#pragma once</code> must be protected, because some + compilers complain about it. The protection depends on + <code>ACE_LACKS_PRAGMA_ONCE</code>, which is defined in + some ACE config headers. Therefore, the protected + <code>#pragma once</code> construct should only be used after + an <code>#include</code> of an ACE library header. Note that + many compilers enable the optimization if the <code>#ifndef</code> + protection construct is used, so for them, <code>#pragma once</code> + is superfluous.<p> + + <strong>No</strong> code can appear after the final + <code>#endif</code> for the optimization to be effective and + correct.<p> + + <li><p>Files that contain parametric classes should follow this style: + <pre> + #ifndef FOO_T_H + #define FOO_T_H + + #include "ace/ACE.h" + #if !defined (ACE_LACKS_PRAGMA_ONCE) + # pragma once + #endif /* ACE_LACKS_PRAGMA_ONCE */ + + // Put your template declarations here... + + #if defined (__ACE_INLINE__) + #include "Foo_T.inl" + #endif /* __ACE_INLINE__ */ + + #if defined (ACE_TEMPLATES_REQUIRE_SOURCE) + #include "Foo_T.cpp" + #endif /* ACE_TEMPLATES_REQUIRE_SOURCE */ + + #if defined (ACE_TEMPLATES_REQUIRE_PRAGMA) + #pragma implementation "Foo_T.cpp" + #endif /* ACE_TEMPLATES_REQUIRE_PRAGMA */ + + #endif /* FOO_T_H */ +</pre></p> + <p> + Notice that some compilers need to see the code of the template, + hence the <code>.cpp</code> file must be included from the + header file. + </p> + <p> + To avoid multiple inclusions of the <code>.cpp</code> file it + should also be protected as in: + <pre> + #ifndef FOO_T_CPP + #define FOO_T_CPP + + #include "Foo_T.h" + #if !defined (ACE_LACKS_PRAGMA_ONCE) + # pragma once + #endif /* ACE_LACKS_PRAGMA_ONCE */ + + #if !defined (__ACE_INLINE__) + #include "ace/Foo_T.inl" + #endif /* __ACE_INLINE__ */ + + // put your template code here + + #endif /* FOO_T_H */ +</pre></p> + <p>Finally, you may want to include the template header file from a + non-template header file (check + <code>$ACE_ROOT/ace/Synch.h</code>); in such a case the template + header should be included <strong>after</strong> the inline + function definitions, as in:</p> + <p><pre> + #ifndef FOO_H + #define FOO_H + + #include "ace/ACE.h" + #if !defined (ACE_LACKS_PRAGMA_ONCE) + # pragma once + #endif /* ACE_LACKS_PRAGMA_ONCE */ + + // Put your non-template declarations here... + + #if defined (__ACE_INLINE__) + #include "Foo.inl" + #endif /* __ACE_INLINE__ */ + + #include "Foo_T.h" + + #endif /* FOO_H */ +</pre></p></li> + + <li>Avoid <code>#include <math.h></code> if at all possible. + The <code>/usr/include/math.h</code> on SunOS 5.5.1 through 5.7 + defines a struct name <strong>exception</strong>, which complicates + use of exceptions.<p> + + <li>On a <code>.cpp</code> file always include the corresponding + header file <em>first</em>, like this:<p> +<pre> + // This is Foo.cpp + + #include "Foo.h" + #include "tao/Bar.h" + #include "ace/Baz.h" + + // Here comes the Foo.cpp code.... +</pre><p> + + In this way we are sure that the header file is self-contained + and can be safely included from some place else. + + <li>In the TAO library <strong>never</strong> include + <code><corba.h></code>, this file should only be included + by the user and introduces cyclic dependencies in the library + that we must avoid.<p> + + <li>Never include a header file when a forward reference will do, + remember that templates can be forward referenced too. + Consult your favorite C++ book to find out when you must include + the full class definition.<p> + </ul> + + <li><strong>C++ Syntax and Constructs</strong><p> + <ul> + <li><strong><code>for</code></strong> loops should look like: + <pre> + for (unsigned int i = 0; i < count; ++i) + ++total; + </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 an <code>ACE_ASSERT</code> without a trailing semicolon: + <pre> + for (unsigned int i = 0; i < count; ++i) + { + ACE_ASSERT (++total < UINT_MAX;) + } + </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><p> + + <li>Prefix operators are generally more efficient than postfix + operators. Therefore, they are preferred over their postfix + counterparts where the expression value is not used.<p> + + Therefore, use this idiom for iterators, with prefix operator + on the loop index: + <pre> + ACE_Ordered_MultiSet<int> set; + ACE_Ordered_MultiSet_Iterator<int> iter(set); + + for (i = -10; i < 10; ++i) + set.insert (2 * i + 1); + + </pre> + rather than the postfix operator: + <pre> + for (i = -10; i < 10; i++) + set.insert (2 * i + 1); + </pre><p> + + <li>Prefer using <strong> <code> if (...) else .... </code> </strong> + instead of <strong> <code> ?: </code> </strong> operator. It is a lot + less error prone, and will help you avoid bugs caused due to the + precedence of <strong> <code> ?: </code> </strong>, compared with other + operators in an expression. + + <li>When a class provides <code>operator==</code>, it must also provide + <code>operator!=</code>. Also, both these operators must be + <code>const</code> and return <code>bool</code>. + + <li>Avoid unnecessary parenthesis. We're not writing Lisp :-)<p> + + <li>Put inline member functions in a <strong><code>.inl</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.inl" + #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.inl" + #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 .inl 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>Some inlining heuristics:<p> + <ul> + <li>One liners should almost always be inline, as in: +<pre> +ACE_INLINE +Foo::bar () +{ + this->baz (); +} +</pre><p> + + <li>The notable exception is virtual functions, which should + generally not be inlined.<p> + + <li>Big (more than 10 lines) and complex function (more than one if () + statement, or a switch, or a loop) should not be inlined.<p> + + <li>Medium sized stuff depends on how performance critical it is. + If you know that it's in the critical path, then make it + inline. When in doubt, profile the code.<p> + </ul> + + <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 or classes that + are not used out of the ACE library, for example.!<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>. + + const ACE_INET_Addr &object_addr const (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><a name="ACE_Time_Value example">Avoid default arguments</a> + unless there's a good reason. For an example of how they got + us into a jam is: + <pre> + ACE_Time_Value (long sec, long usec = 0); + </pre> + + So, <code>ACE_Time_Value (2.5)</code> has the unfortunate + effect of coercing the 2.5 to a long with value 2. That's + probably not what the programmer intended, and many compilers + don't warn about it.<p> + + A nice fix would be to add an <code>ACE_Time_Value (double)</code> + constructor. But, that would cause ambiguous overloading + due to the default value for the second argument of + <code>ACE_Time_Value (long sec, long usec = 0)</code>. + We're stuck with <code>ACE_Time_Value</code>, but now we + know that it's easy to avoid.<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 (and non-constant) 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 C-style "sledgehammer" + casts. Use standard C++ casts + (e.g. <code>static_cast<int> (foo)</code>) instead.<p> + + <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> + + <li>Never use <code>BOOL</code>, or similar types. + (<code>ACE_CDR::Boolean</code> and + <code>CORBA::Boolean</code> are acceptable). Use the + standard C++ <code>bool</code> for boolean variables, instead.<p> + + <li>Functions should always return -1 to indicate failure, and + 0 or greater to indicate success.<p> + + <li>Separate the code of your templates from the code for + non-parametric classes: some compilers get confused when + template and non-template code is mixed in the same file.<p> + + <li>It's a good idea to specify the include path (with <code>-I</code>) + to include any directory which contains files with template + definitions. The Compaq Tru64 cxx <code>-ptv</code> compiler option + may help diagnose missing template instantiation problems.<p> + + <li>When referring to member variables and functions, use + <code>this-></code><em>member</em>. This makes it clear to the + reader that a class member is being used. It also makes it crystal + clear to the compiler which variable/function you mean in cases + where it might make a difference. <p> + + <li>Don't use template template arguments, this C++ construct is not + supported by the HP aCC 3.70 compiler at this moment. For example the + following template decleration is one that just doesn't work. + <pre> + template<typename S_var, size_t BOUND, template <typename> class Insert_Policy> class A {}; + </pre> + </ul> + <li><strong>I/O</strong><p> + <ul> + <li>Use <strong><code>ACE_DEBUG</code></strong> for printouts, + and <strong><code>ACE_OS::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> + <li>Notice that <strong><code>ACE_DEBUG</code></strong> and + <strong><code>ACE_ERROR</code></strong> don't support + <code>%ld</code> of any other multicharacter format.<p> + </ul> + + <li><strong>WCHAR conformity</strong><p> + + <ul> + <li>For ACE, use <code>ACE_TCHAR</code> instead of char for strings and <code>ACE_TEXT()</code> + around string literals. Exceptions are <code>char</code> + arrays used for data and strings that need to remain as 1 + byte characters. + + <li>If you have a char string that needs to be converted to <code>ACE_TCHAR</code>, + use the <code>ACE_TEXT_CHAR_TO_TCHAR()</code> macro. If you have a <code>ACE_TCHAR</code> + string that needs to be converted to a <code>char</code> string, use the + <code>ACE_TEXT_ALWAYS_CHAR()</code> macro + + <li>Do not use the Win32 <code>TCHAR</code> macros. The wide character-ness of ACE + is separate from UNICODE and _UNICODE. + + <li>For TAO, don't use <code>ACE_TCHAR</code> or <code>ACE_TEXT</code>. The CORBA specification + defines APIs as using char. So most of the time there is no need + to use wide characters. + </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> + + <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> + </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> + Usage Guidelines</h3> +<ul> + <li>Always use the <strong><code>ACE_OS</code></strong> + namespace functions instead of bare OS system calls.<p> + + <li>As a general rule, the only functions that should go into the + <strong><code>ACE_OS</code></strong> namespace are ones that + have direct equivalents on some OS platform. Functions that + are extensions should go in the + <strong><code>ACE</code></strong> namespace.<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 C++ exception handling directly. Some platforms do + not support it. And, it can impose an execution speed penalty. + Instead use the TAO/ACE try/catch macros.<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>Another consequence of ACE's avoidance of exception handling is + that you should use <CODE>open()</CODE> methods on classes that + perform initializations that can fail. This is because <CODE>open()</CODE> + returns an error code that's easily checked by the caller, + rather than relying on constructor and thread-specific status + values. <P> + + <li>Avoid using the C++ Standard Template Library (STL) in our + applications. Some platforms do not support it yet. It is + safe to use the STL generic algoritms. The following have been + used already and don't seem to cause any portability issues: + <pre> + std::swap + std::for_each + std::fill + std::generate + std::transform + std::copy + </pre><p> + + <li>Be <em>very</em> careful with <code>ACE_ASSERT</code>. It + must only be used to check values; it may never be used to + wrap a function call, or contain any other side effect. That's + because the statement will disappear when ACE_NDEBUG is enabled. + For example, this code is BAD: + <pre> + ACE_ASSERT (this->next (retv) != 0); // BAD CODE! + </pre> + + Instead, the above should be coded this way: + + <pre> + int const result = this->next (retv); + ACE_ASSERT (result != 0); + ACE_UNUSED_ARG (result); + </pre><p> + + <li>Never put side effects in <code>ACE_DEBUG</code> code: + <pre> + ACE_DEBUG ((LM_DEBUG, + "handling signal: %d iterations left\n", + --this->iterations_)); // BAD CODE! + </pre> + + Note that this won't work correctly if <code>ACE_NDEBUG</code> is + defined, for the same reason that having side-effects in + <code>ACE_ASSERT</code>s won't work either, <em>i.e.</em>, because + the code is removed.<p> + + <li>Be <strong>very</strong> careful with the code that you put + in a signal handler. On Solaris, the man pages document systems + calls as being Async-Signal-Safe if they can be called from signal + handlers. In general, it's best to just set a flag in a signal + handler and take appropriate action elsewhere. It's also best + to avoid using signals, especially asynchronous signals.<p> + + <li>Immediately after opening a temporary file, unlink it. For + example: + <pre><code> + ACE_HANDLE h = open the file (filename); + + ACE_OS::unlink (filename); + </code></pre><p> + + This avoids leaving the temporary file even if the program crashes.<p> + + <li>Be sure to specify the <code>THR_BOUND</code> thread creation + flag for time-critical threads. This ensures that the thread competes + for resources globally on Solaris. It is harmless on other platforms.<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>When enhancing, updating, or fixing ACE or TAO, always: + <ol> + <li>Test your change on at least Windows and Linux before commiting. + After commiting watch the scoreboard to catch errors your change + may be related to on other platforms. + <li>An an entry to the appropriate ChangeLog. TAO and some + ACE subdirectories, such as <a href="../ASNMP">ASNMP</a>, + <a href="../apps/JAWS">JAWS</a>, and + <a href="../apps/gperf">gperf,</a> have their + own ChangeLogs. If you don't use one of those, use the + <a href="../ChangeLog">ChangeLog</a> in the top-level + <a href="..">ACE_wrappers</a> directory. A ChangeLog entry should + have the form: + <pre><tab> * dir/file.ext [(methods)]: description...</pre> + If you have a number of files, the names should be on separate lines. + In this case, it's also ok to start the description on a new line + indented to "dir." + <li>Commit your change using a message of this form:<p> +<code> +ChangeLogTag: Thu Jul 22 09:55:10 UTC 1999 David L. Levine + <levine@cs.wustl.edu> +</code> + <li>If the change is in response to a request by someone else: + <ol> + <li>Make sure that person is acknowledged in + <a href="../THANKS">ACE_wrappers/THANKS</a>, and<p> + <li>Respond to that person.<p> + </ol> + </ol> + + <li><strong>Never</strong> add copyrighted, confidential, or otherwise + restricted code to the ACE or TAO distributions without reviewing + the situation with DOC management (i.e. Doug Schmidt). You will also + most likely need to get written permission from the owner. The + particular language and form needed will be relayed to you after + discussing it with DOC management.<p> +</ul> + + +<hr> +<h3>SVN 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 SVN repository. + All changes <strong>must</strong> be tested with g++ before commiting. + That means you may need to test on at least two platforms.<p> +</ul> + + +<hr> +<h3>Script Guidelines</h3> +<ul> + <li>In general, it's best to write scripts in Perl. It's + OK to use Bourne shell. Never, never, never use csh, ksh, + bash, or any other kind of shell.<p> + + <li>Follow the Perl style guide guide as closely as + possible. <code>man perlstyle</code> to view it. + + <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>Never, never, never start the first line of a script + with "<code>#</code>", unless the first line is "<code>#! /bin/sh</code>". + With just "<code>#</code>", t/csh users will spawn a new shell. + That will cause their <code>.[t]cshrc</code> to be + processed, possibly clobbering a necessary part of + their environment.<p> + + <li>If your Perl script relies on features only available + in newer 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> + + <li><strong>Be available</strong>: Breaking compilation in one + platform or another should be avoided (see above), + but it is bound to happen when so many platforms are in use. + Be available after making a change, + if you won't be available for at least 48 hours after the change + is made then don't make it!<p> +</ul> + + + +<hr> +<h3><a href="http://www.cs.wustl.edu/~schmidt/rules.html">ACE + Design Rules</a></h3> + + +<hr><p> + <font size=-1> +<!-- hhmts start --> +Last modified: Wed Nov 23 11:00:44 CST 2005 +<!-- hhmts end --> + </font><p> + + + +Back to <A HREF="index.html">ACE Documentation Home</A>. + +</body> +</html> diff --git a/ACE/docs/ACE-lessons.html b/ACE/docs/ACE-lessons.html new file mode 100644 index 00000000000..4448644ae68 --- /dev/null +++ b/ACE/docs/ACE-lessons.html @@ -0,0 +1,270 @@ +<HTML> + +<!-- $Id$ --> +<HEAD> +<TITLE>Lessons Learned Building Reusable OO Telecommunication Software</TITLE> +</HEAD> + +<BODY text = "#000000" +link="#000fff" +vlink="#ff0f0f" +bgcolor="#ffffff"> + +<HR> +<H3>Lessons Learned Building Reusable OO Telecommunication Software Frameworks</H3> + +<DT>Douglas C. Schmidt +<DT>Department of Computer Science +<DT>Washington University, St. Louis +<DT><A HREF="http://www.cs.wustl.edu/~schmidt/">http://www.cs.wustl.edu/~schmidt/</A> +<DT><A HREF="mailto:schmidt@cs.wustl.edu">schmidt@cs.wustl.edu</A> + +<P>The following article appeared in the Lucent Bell Labs ``Multiuse +Express'' magazine, Vol. 4, No. 6, December, 1996. <P> + +<P><HR><P> + +<H3>The Distributed Software Crisis</H3> + +Developing complex software systems is expensive and error-prone. +Object-oriented (OO) programming languages [Stroustrup:91,Gosling:96], +components [Box:97], and frameworks [Lewis:95] are heavily touted +technologies for reducing software cost and improving software +quality. When stripped of their hype, the primary benefits of OO stem +from the emphasis on <EM>modularity</EM> and <EM>extensibility</EM>, +which encapsulate volatile implementation details behind stable +interfaces and enhance software reuse. <P> + +Developers in certain well-traveled domains have successfully applied +OO techniques and tools for years. For instance, the Microsoft MFC +GUI framework and OCX components are <EM>de facto</EM> industry +standards for creating graphical business applications on PC +platforms. Although these tools have their limitations, they +demonstrate the productivity benefits of reusing common frameworks and +components.<P> + +Software developers in more complex domains like telecom have +traditionally lacked standard off-the-shelf middleware components. As +a result, telecom developers largely build, validate, and maintain +software systems from scratch. In an era of deregulation and stiff +global competition, this in-house development process is becoming +prohibitively costly and time consuming. Across the industry, this +situation has produced a ``distributed software crisis,'' where +computing hardware and networks get smaller, faster, and cheaper; yet +telecom software gets larger, slower, and more expensive to develop +and maintain. <P> + +The challenges of building distributed software stem from +<EM>inherent</EM> and <EM>accidental</EM> complexities [Brooks:87] +associated with telecom systems: <P> + +<UL> +<LI> Inherent complexity stems from the fundamental challenges of + developing telecom software. Chief among these is detecting and + recovering from network and host failures, minimizing the impact of + communication latency, and determining an optimal partitioning of + service components and workload onto processing elements throughout + a network. <P> + +<LI> Accidental complexity stems from limitations with tools and + techniques used to develop telecom software. A common source of + accidental complexity is the widespread use of algorithmic + decomposition, which results in non-extensible and non-reusable + software designs and implementations. <P> +</UL> + +The lack of extensibility and reuse in-the-large is particularly +problematic for complex distributed telecom software. Extensibility +is essential to ensure timely modification and enhancement of services +and features. Reuse is essential to leverage the domain knowledge of +expert developers to avoid re-developing and re-validating common +solutions to recurring requirements and software challenges. <P> + +While developing high quality reusable software is hard enough, +developing high quality extensible and reusable telecom software is +even harder. Not surprisingly, many companies attempting to build +reusable middleware fail -- often with enormous loss of money, time, +and marketshare. Those companies that do succeed, however, reap the +benefits resulting from their ability to develop and deploy complex +applications rapidly, rather than wrestling endlessly with +infrastructure problems. Unfortunately, the skills required to +successfully produce telecom middleware remain something of a "black +art," often locked in the heads of expert developers. <P> + +<P><HR><P> + +<H3>Lessons Learned Building Reusable OO Communication Software Frameworks</H3> + +Over the past decade, I've worked with many companies (including +Motorola Iridium, Ericsson, Siemens, Bellcore, Kodak, and McDonnell +Douglas) building reusable OO communication software [Schmidt:96]. In +these projects, we've applied a range of OO middleware tools including +OMG <A HREF="http://www.cs.wustl.edu/~schmidt/corba.html">CORBA</A> +(an emerging industry standard for distributed object computing) and +the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A> +framework (a widely used C++ framework that implements many strategic +and tactical design patterns for concurrent communication software). +The following are lessons learned from developing and deploying +reusable OO communication software components and frameworks in +practice: <P> + +<UL> +<LI> <B><EM> Successful reuse-in-the-large requires non-technical +prerequisites -- </EM></B><P> + + Many political, economical, organizational, and psychological + factors can impede successful reuse in telecom companies. I've + found that reuse-in-the-large works best when (1) the marketplace is + competitive (i.e., time-to-market is crucial, so leveraging existing + software substantially reduces development effort), (2) the + application domain is non-trivial (i.e., repeatedly developing + complete solutions from scratch is too costly), and (3) the + corporate culture is supportive of an effective reuse process (e.g., + developers are rewarded for taking the time to build robust reusable + components). When these prerequisites <EM>don't</EM> apply, I've + found that developers often fall victim to the "not-invented-here" + syndrome and rebuild everything from scratch. <P> + +<LI> <B><EM> Iteration and incremental growth is essential </EM></B> -- <P> + + Expanding on the corporate culture theme, I've observed that it's + crucial for software managers to openly support the fact that good + components, frameworks, and software architectures take time to + craft and hone. For reuse to succeed in-the-large, management must + have the vision and resolve to support the incremental evolution of + reusable software. In general, an 80% solution that can be evolved + is often preferable to trying to achieve a 100% solution that never + ships. Fred Brook's observation that ``Plan to throw the first one + away, you will anyway'' [Brooks:75] applies as much today as it did + 20 years ago. <P> + +<LI> <B><EM> Integrate infrastructure developers with application developers +</EM></B> -- <P> + + Truly useful components and frameworks are derived from solving real + problems, e.g., telecommunications, medical imaging, avionics, OLTP, + etc. Therefore, a time honored way of producing reusable components + is to generalize from working systems and applications. In + particular, resist the temptation to create ``component teams'' that + build reusable frameworks in isolation from application teams. I've + learned the hard way that without intimate feedback from application + developers, the software artifacts produced by a component team + won't solve real problems and will not be reused. <P> + +<LI> <B><EM> Industry ``standards'' are not panaceas -- </EM></B> <P> + + Expecting emerging industry standards (like CORBA or TINA) to + eliminate telecom software complexity today is very risky. For + instance, although some CORBA ORB implementations are suited for + certain telecom tasks (such as managing network elements), the + semantics of higher level OMG services (such as the Common Object + Services) are still too vague, under-specified, and non</EM></B> + -interoperable. Although CORBA isn't yet suited to address certain + demanding real-time performance and reliability requirements in the + telecom domain, over the next 2 years we'll see CORBA-based products + emerge that support such features [Schmidt:96].<P> + +<LI> <B><EM> Beware of simple(-minded) solutions to complex software problems +-- </EM></B> <P> + + Apply simple solutions to complex problems that sound too good to be + true typically are... For example, translating code entirely from + high-level specifications or using trendy OO design methodologies + and programming languages is no guarantee of success. In my + experience, there's simply no substitute for skilled software + developers, which leads to the following final ``lesson learned.'' +<P> + +<LI> <B><EM> Respect and reward quality developers </EM></B> -- <P> + + Ultimately, reusable components are only as good as the people who + build and use them. Developing robust, efficient, and reusable + telecom middleware requires teams with a wide range of skills. We + need expert analysts and designers who have mastered design + patterns, software architectures, and communication protocols to + alleviate the inherent and accidental complexities of telecom + software. Moreover, we need expert programmers who can implement + these patterns, architectures, and protocols in reusable frameworks + and components. In my experience, it is exceptionally hard to find + high quality software developers. Ironically, many telecom + companies treat their developers as interchangeable, "unskilled + labor" who can be replaced easily. I suspect that over time, + companies who respect and reward their high quality software + developers will increasingly outperform those who don't. <P> +</UL> + +<P><HR><P> +<H3>Concluding Remarks</H3> + +Developing reusable OO middleware components and frameworks is not a +silver bullet. Software is inherently abstract, which makes it hard +to engineer its quality and to manage its production. The good news, +however, is that OO component and framework technologies are becoming +mainstream. Developers and users are increasingly adopting and +succeeding with object-oriented design and programming.<P> + +On the other hand, the bad news is that (1) existing OO components and +frameworks are largely focused on only a few areas (e.g., GUIs) and +(2) existing industry standards still lack the semantics, features, +and interoperability to be truly effective throughout the telecom +software domain. Too often, vendors use industry standards to sell +proprietary software under the guise of open systems. Therefore, it's +essential for telecom companies to work with standards organizations +and middleware vendors to ensure the emerging specifications support +true interoperability and define features that meet telecom software +needs.<P> + +Finally, to support the standardization effort, it's crucial for us to +capture and document the patterns that underlie the successful telecom +software components and frameworks that do exist. Likewise, we need +to reify these patterns to guide the creation of standard frameworks +and components for the telecom domain. I'm optimistic that the next +generation of OO frameworks and components will be a substantial +improvement over those we've worked with in the past.<P> + +For more information on building reusable OO communication software +frameworks with CORBA and ACE, see the following WWW URLs:<P> + +<A HREF="http://www.cs.wustl.edu/~schmidt/corba.html">http://www.cs.wustl.edu/~schmidt/corba.html</A><p> +<A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">http://www.cs.wustl.edu/~schmidt/ACE.html.</A> + +<P><HR><P> +<H3>References</H3> + +[Box:97] Don Box, "Understanding COM," Addison-Wesley, + Reading, MA, 1997.<P> + +[Brooks:75] Frederick P. Brooks, "The Mythical Man-Month," + Addison-Wesley, Reading, MA, 1975.<P> + +[Brooks:87] Frederick P. Brooks, "No Silver Bullet: Essence and + Accidents of Software Engineering," IEEE Computer, Volume + 20, Number 4, April 1987, 10-19.<P> + +[Gosling:96] The Java Programming Language, Addison-Wesley, + Reading, MA, 1996.<P> + +[Lewis:95], Ted Lewis et al., "Object Oriented Application + Frameworks," IEEE Computer Society Press, 1995.<P> + +[OMG:95] Object Management Group, The Common Object Request Broker: + Architecture and Specification 2.0, July, 1995.<P> + +[Schmidt:96] Douglas C. Schmidt, "A Family of Design Patterns for + Application-Level Gateways," Theory and Practice of Object + Systems, Wiley and Sons, 1996.<P> + +[Schmidt:97] Aniruddha Gokhale, Douglas C. Schmidt, Tim Harrison, and + Guru Parulkar, "Towards Real-time CORBA," IEEE Communications + Magazine, Volume 14, Number 2, February 1997.<P> + +[Stroustrup:91] Bjarne Stroustrup, The C++ Programming Language, 2nd + Edition, Addison-Wesley, Reading, MA, 1991.<P> + +<P><HR><P> +Back to <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html"> +ACE</A> home page.<BR> +Back to <A HREF="index.html">ACE Documentation Home</A>. +<!--#include virtual="/~schmidt/cgi-sig.html" --> +</BODY> +</HTML> diff --git a/ACE/docs/ACE-porting.html b/ACE/docs/ACE-porting.html new file mode 100644 index 00000000000..79f773f4a2c --- /dev/null +++ b/ACE/docs/ACE-porting.html @@ -0,0 +1,198 @@ +<!-- $Id$ --> + +<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, TAO, and CIAO to a New OS Platform</H3><P> + +<A HREF="http://www.dre.vanderbilt.edu/ACE">ACE</A>, <A +HREF="http://www.dre.vanderbilt.edu/TAO">TAO</A>, and <A +HREF="http://www.dre.vanderbilt.edu/CIAO">CIAO</A> have been +ported to <A HREF="http://www.dre.vanderbilt.edu/versions.html">many +OS platforms</A>. Porting ACE, TAO, and CIAO 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 and CIAO, as well.<P> + +Before starting a port that you plan to contribute back to the +ACE+TAO+CIAO open-source community, we recommend that you do the +following: + +<UL> +<LI> Read and follow the <A HREF="ACE-guidelines.html">programming style + guidelines</A> we use when writing ACE, TAO, and CIAO code, + which will make it much easier to integrate and maintain your port + in the source tree. <P> + +<LI> Contact <A HREF="mailto:d.schmidt@vanderbilt.edu">Douglas + C. Schmidt</A> and let him know that you're planning to contribute + a port, which will make it make easier to work out the logistics + of when/how the port will be integrated. <P> +</UL> + +<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="../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="../ace/README">$ACE_ROOT/ace/README</A> file. <P> + +Currently, you must edit this file by hand to port it to new OS +platforms, though on some platforms it's possible to use the ACE <A +HREF="../configure.ac">autoconf script</A>. It's a good idea to use +the <CODE>config-*.h</CODE> files for platforms with similar +characteristics as examples. + +<hr align=left width="50%"><P> +<H4>Port the <CODE>ACE_OS</CODE> Namespace</H4> + +The <CODE>ACE_OS</CODE> namespace 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 of the ACE OS +abstraction layer. Most work required to port ACE to a new OS +platform resides in this namespace. 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_NS_*.{h,inl,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="../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>ACE_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 Facade Components</H4> + +After porting the <CODE>ACE_OS</CODE> namespace, the next step is to +port all of the ACE C++ wrapper facade components, such as sockets, +threads, synchronization mechanisms. A full list of the categories +and classes can be found in the <A +HREF="ACE-categories.html">$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="../tests/README">regression test suite</A> +in the <A HREF="../tests/">$ACE_ROOT/tests/</A> directory. These +tests can be used to validate the correctness of the various ACE C++ +wrapper facades 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++ wrapper facades, 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 and CIAO</H4> + +After porting and successfully testing all the ACE framework +components, it should be straightforward to port and <A +HREF="../TAO/TAO-INSTALL.html">install</A> TAO and <A +HREF="../TAO/CIAO/CIAO-INSTALL.html">install</A> CIAO because the bulk +of their platform-dependent code is localized in ACE. Typically, the +only problems that arise when porting TAO and CIAO is bugs and +limitations with C++ compilers. <P> + +<HR><P> +<H3>C++ Features Required to Port ACE, TAO, and CIAO</H3> + +ACE, TAO, and CIAO 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 and of + the advanced concepts outlined in <A + HREF="http://www.moderncppdesign.com/"> Modern C++ Design</A>. <P> + +<LI> <B>Multiple inheritance and dynamic binding</B> -- The C++ + compiler must support multiple inheritance and dynamic + binding. <P> + +<LI> <B>Namespaces</B> -- ACE+TAO+CIAO utilizes C++ namespaces, so the + C++ compiler must support them.<P> + +<LI> <B>ANSI casts and RTTI</B> -- ACE+TAO+CIAO uses the ANSI C++ + casts, so the C++ compiler must support them, which implies + support for RTTI.<P> + +</UL> + +The following is a list of which C++ features that ACE, TAO, CIAO 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 requires the use of C++ exceptions, + <CODE>ACE_HAS_EXCEPTIONS</CODE> must be defined. <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. ACE therefore 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, TAO, and CIAO 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://www.stlport.org/">STLport</a>, + which is a port of the SGI STL to numerous platforms that ACE, + TAO, and CIAO also support. <P> + +</UL> + +<P><HR><P> + +Back to the <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE-documentation.html">ACE +documentation</A> page.<BR> +Back to <A HREF="index.html">ACE Documentation Home</A>. + +<!--#include virtual="/~schmidt/cgi-sig.html" --> +</BODY> +</HTML> diff --git a/ACE/docs/ACE-subsets.html b/ACE/docs/ACE-subsets.html new file mode 100644 index 00000000000..ef2a1e0dcd1 --- /dev/null +++ b/ACE/docs/ACE-subsets.html @@ -0,0 +1,196 @@ +<!-- $Id$ --> + +<html> + <head> + <title>ACE+TAO Subsetting</title> + <link rev=made href="mailto:ace-users@cs.wustl.edu"> + </head> + +<body text = "#000000" + link="#000fff" + vlink="#ff0f0f" + bgcolor="#ffffff"> + +<hr><p> +<H2>ACE+TAO Subsetting</H2> + +<p> +We are involved in ongoing activities to subset ACE+TAO to make them +more flexible and to reduce their memory footprint for embedded +systems. This document describes what we've done thus far, what we're +planning to do next, and how to leverage our efforts to minimize the +size of your ACE+TAO applications. </P> + +<hr> +<h3>Contents</h3> +<ul> + <li><a href="#pastwork">Past Work</a> + <li><a href="#futurework">Future Work</a> +</ul> + +<hr> +<h3><a name="pastwork">Past Work</a></h3> +<p> + +Previous ACE+TAO subsetting efforts were mainly concerned with +breaking up ACE into multiple libraries. Although this was a worthy +goal, the existing component definitions in <a +href="../ace/ace.mpc">ace.mpc</a> are too tightly coupled. Even if +ACE was compiled into multiple libraries, therefore, applications +would still have to link almost every one of them.</p> + +<p> +Potentially more satisfying results can be obtained through the use of +namespaces, e.g., ACE_OS, and/or breaking up large cpp's into smaller +ones to decrease the size of object files, and statically linking them +into the application.</p> + +<p> +In fact, this technique was applied systematically to ACE_OS in 2003, +and resulted in a <a +href="http://www.dre.vanderbilt.edu/Stats/footprint.shtml">10-15% +decrease in overall footprint</a> for statically linked applications. +Interestingly, these techniques also helped reduce <a +href="http://www.dre.vanderbilt.edu/~isisbuilds/auto_compile_logs/CP_Metrics/metrics/">compilation +times by ~50%</a>.</p> + +<p> +Another very powerful technique for reducing the size of shared +libries is <a href="../apps/soreduce/README">The Shared Library +Reduction (<CODE>soreduce</CODE>) tool</a>. <code>soreduce</code> +also benifits from the techniques listed above and should give +results comparable to static linking. In fact, when deploying multiple +applications, use of shared libraries with <code>soreduce</code> will +result in smaller overall footprint than static linking.</p> + +<hr> +<h3><a name="futurework">Future Work</a></h3> +<p> + +Depending on funding and contributions from the ACE community, future +work on subsetting in ACE can be divided into two thrusts: <P> + +<UL> + +<LI> <B>Code refactoring</B>, which helps to reduce the coupling +between applications and ACE C++ wrappers and frameworks. The amount +of coupling that's in ACE currently yields larger compiled size for +executable applications, increased link times, and indirect dependency +on a large amounts of code that may not be needed for many embedded +applications. <P> + +<LI> <B>Functionality Refactoring</B>, which enables application +developers to choose lightweight reusable classes and frameworks, +rather than monolithic and heavyweight implementations, to decrease +compilation times, link times, and compiled memory footprint of +embedded applications. <P> + +</UL> + +Our ideas for performing each of these thrusts is described in detail +below. + +<h4>ACE Code Refactoring</H4> + +ACE is currently designed in such a way that application developers +must link many classes and methods of ACE with their application, even +if they use a small number of classes and functions in their +application. As a result, static memory resource utilization is +unnecessarily high for common use cases. This section describes +techniques to address the existing code structuring complexities in +ACE, which were originally driven by the poor quality of C++ tools +that were available in the 1990's. For example, early C++ compilers +in the embedded domain lacked support for namespaces, which forced +developers to write classes that had a number of utility functions +useful for network programming. Now that modern C++ compilers have +better support for standard C++, we propose the following +optimizations to ACE: <P> + +<UL> + +<LI> We will identify ACE classes and utility functions that serve a + common goal, and move them into a namespace of their own. Since C++ + allows a single namespace to be reopened in multiple translation + units, we plan to split the operations into multiple C++ source + files, giving the linker a chance to choose a smaller sized object + files while creating an executable. <P> + +<LI> Currently, ACE inlines many of its methods, which tradesoff run-time + performance for larger footprint. We propose to examine the contents + of inlined files in ACE, and evaluate whether inlining is required in + every instance. ACE aggressively inlined functions to get better + performance from the tool chains, but this has lead to increased code + coupling within ACE, as well as increased coupling between + applications that use ACE. We will evaluate the tradeoffs associated + with inlining and performance of certain functions and selectively + inline those methods. These optimizations are described further in + <A +HREF="http://www.amazon.com/exec/obidos/tg/detail/-/0201379503/104-7731669-1857527?v=glance">Efficient +C++: Performance Programming Techniques</A> by Dov Bulka and + David Mayhew. +</UL> + +We expect that we will be able to reduce footprint by ~25-30% for ACE +applications, and a ~15-20% reduction in compile and link time of +applications. <P> + +<H4>Functionality Refactoring</H4> + + This section proposes to address additional compile-time and memory +footprint problems that can be solved by functionality refactoring. +During the past decade, ACE has been designed and built based on many +unique requirements from users around the globe. Though this input +enhanced the flexibility of ACE and increased the visibility of ACE, +it also led to functionality "clumping," i.e., many classes in ACE +have functionality associated with them that are not required for many +applications. For example, the ACE_Svc_Handler serves as an event +handler for the ACE Reactor framework, serves as a handler to +implement the thread-per-connection strategies, and can be dynamically +loaded from shared libraries using the ACE Service Configurator +framework, which in turn depends on the ACE Reactor framework. Though +all these dependencies and functionalities are required for some +applications, they yield excessive coupling and overhead for +applications (such as clients) that only want to use the ACE +Acceptor/Connector framework to connect and send messages to remote +servers. <P> + + To address the issues of tight-coupling outlined above, we propose +to refactor the code and functionality of the existing ACE frameworks +and wrapper classes to offer finer-grained components that can be +selectively included by embedded applications. Our initial efforts +would focus on the following key ACE frameworks: +<UL> +<LI> Logging +<LI> Service Configurator +<LI> Object Manager +<LI> Reactor +<LI> Framework Component +<LI> Thread Manager +<LI> Proactor +</UL> + +We propose to apply the techniques we have mentioned above. As a +result, we expect that we will be able to reduce footprint by another +~20-25% for certain classes of ACE applications, and a ~15-20% +reduction in compile- and link-time of applications. <P> + + Collectively, the optimizations we propose above will greatly +reduce the memory footprint and speedup the compilation and link time +for ACE-based applications. <P> + +<p> Anyone interested in contributing time or funding to these efforts +should please contact <a +href="mailto:d.schmidt@vanderbilt.edu">d.schmidt@vanderbilt.edu</a>. +If you have questions about ACE and/or ACE subsetting and footprint +reduction please post these questions to the <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">ACE mailing +list</A>.</p> + +<P><HR><P> +Back to the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A> +home page.<BR> +Back to <A HREF="index.html">ACE Documentation Home</A>. + +<!--#include virtual="/~schmidt/cgi-sig.html" --> +</BODY> +</HTML> diff --git a/ACE/docs/CE-status.txt b/ACE/docs/CE-status.txt new file mode 100644 index 00000000000..3b618df0980 --- /dev/null +++ b/ACE/docs/CE-status.txt @@ -0,0 +1,51 @@ +/** +@page wince ACE on Windows CE status + +Last updated Tuesday 15-November-2005 by Steve Huston <shuston@riverace.com> + +@subsection ce_status Status + +As of ACE 5.5, Riverace supports ACE on Windows CE building with Microsoft +Visual Studio 2005 and targeting the Pocket PC 2003 SDK and Windows Mobile 5. +OCI supports TAO 1.3 on at least Windows CE 3 with the PocketPC 2002 SDK. +Contact the individual support provider for complete information regarding +these platforms as well as the supported hardware targets. + +@subsection ce_evc eMbedded Visual C++ Projects + +Whereas previous ACE versions had separate ACE and ACE_OS eMbedded Visual C++ +project files, the project and workspace arrangement is now the same as +for other Windows versions. The project and workspace files themselves are +generated using the MakeProjectCreator tool when the ACE kit is prepared. +Both EVC3 and EVC4 use the same project and workspace files. + +Developers working with sources checked out from CVS must generate the +project and workspace files locally using MPC. The autobuild system's +generate_makefile and generate_workspace commands can be used for this. + +@subsection ce_vc8 Visual Studio 2005 Projects + +The ACE release process generates the needed Visual Studio 2005 solution and +project files with "_WinCE" appended to the name (e.g. ACE_WinCE.vcproj) to +distinguish them from both Win32-targeted VC8 projects (ACE_vc8.vcproj) and +Visual Studio 2003 projects (ACE.vcproj). The files are generated with +the "Pocket PC 2003 SDK (ARMV4)" and "Windows Mobile 5.0 Pocket PC SDK +(ARMV4I)" platforms defined. To add additional platforms, the files must be +regenerated using MPC. + +@subsection ce_wchar Unicode/WChar + +ACE on WindowsCE automatically has ACE_HAS_WCHAR and ACE_USES_WCHAR turned +on. Thus ACE_TCHAR and ACE_TEXT() are the wide char versions. + +@subsection ce_tests Running the Test Suite on Windows CE + +The ACE test suite in ACE_wrappers/tests is used on Windows CE as well as +on dekstop Windows. The test suite tools are being extended to use a +product called Pocket Controller, Enterprise edition from Soft Object +Technologies, Inc. (www.soti.net) that can script the actions needed to +copy the test files to a PocketPC device, run the test, and copy the log +files back to the build machine for analysis and reporting to the +scoreboard. + +*/ diff --git a/ACE/docs/CVS.html b/ACE/docs/CVS.html new file mode 100644 index 00000000000..b986f9dec0a --- /dev/null +++ b/ACE/docs/CVS.html @@ -0,0 +1,889 @@ +<!-- $Id$ --> + +<html> +<head> + <title>CVS Minimal Help</title> + <link rev=made href="mailto:levine@cs.wustl.edu"> +<!-- Changed by: David Levine, 26-Mar-1997 --> +</head> + +<body text = "#000000" + link = "#000fff" + vlink = "#ff0f0f" + bgcolor = "#ffffff"> +<hr><p> +<center> + <h1>CVS Minimal Help</h1> + <h2><a href="mailto:levine@cs.wustl.edu">David L. Levine</a></h2> + <font size=-1> + Last modified Monday, 30-Sep-2002 11:15:16 CDT. + </font> +</center> +<h2> </h2> + +This page contains the minimum (and then some) commands necessary to +access and update <a href="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</a> +through <a href="file:/project/doc/pkg/cvs/cvs-1.10/doc/cvs.ps">CVS</a> +version control. The intended audience is local ACE developers, so +it's not by any means a general introduction to CVS. And some HTML +links and other references are local only.<p> + +The information here is based on CVS versions 1.9 and 1.10.5 and later.<p> + +Notes to emacs users: the emacs Tools/Version Control (or vc) pulldown +has CVS commands: it's well worth checking out. And, see the +<a href="#Preliminaries">Preliminaries</a> section for a handy +addition to your .emacs file.<p> + +If you'd like to update your CVS workspace remotely, see +<a href="http://www.cs.wustl.edu/~nanbor/">Nanbor Wang</a>'s   +<a href="http://www.cs.wustl.edu/~nanbor/CVSUP/">CVSup</a>  page.<p> + +Please <a href="mailto:levine@cs.wustl.edu">email me</a> any corrections or +suggestions!<p> + + +<font size="+2"><strong>Contents:</strong></font> +<ol> + <li><a href="#The Model">The Model</a> + <li><a href="#Preliminaries">Preliminaries</a> + <li><a href="#Getting started with ACE on CVS">Getting + started with ACE on CVS</a> + <li><a href="#Windows NT setup">Windows NT setup</a> + <li><a href="#Checking in changes">Checking in changes</a> + <li><a href="#Workspace update">Workspace update</a> + <li><a href="#Adding/removing files/directories">Adding/removing + files/directories</a> + <li><a href="#Modules">Modules</a> + <li><a href="#ChangeLog updates">ChangeLog updates</a> + <li><a href="#File revisions">File revisions</a> + <li><a href="#File reversion">File reversion</a> + <li><a href="#Renaming a file">Renaming a file</a> + <li><a href="#Local version control">Local version control</a> + <li><a href="#Branches">Branches</a> + <li><a href="#Remote repositories">Remote repositories</a> + <li><a href="#Exporting from CVS">Exporting from CVS</a> + <li><a href="#ACE_wrappers-frozen workspace">ACE_wrappers-frozen + workspace</a> + <li><a href="#ACE release bug-fix branch">ACE release bug-fix branch</a> + <li><a href="#Warning messages/problems">Warning messages/problems</a> + <li><a href="#For more info on CVS">For more info on CVS</a> +</ol> + + +<hr><p> +<h3>1. <a name="The Model">The Model</a></h3> +The following terms are used in the discussion in this web page:<br> +<ul> + <li><em>Repository</em>: The master store of all versions of all + controlled files.<p> + <li><em>Workspace</em>: A user's collection of controlled files. + The user may modify these files at will.<p> + <li><em>Check out</em>: Retrieve one or more files from the + repository, and place them in a workspace. Any version of any + file may be retrieved; typically, that will be the latest version.<p> + <li><em>Check in, or commit</em>: Update the latest version of + one or more files in the repository. This is done from a workspace.<p> + <li><em>Module</em>: Directory. +</ul> + +Our use of CVS fits into the +<a href="http://www.cs.wustl.edu/~levine/ACE_wrappers/docs/ACE-development-process.html">ACE development process</a>.<p> + + +<hr><p> +<h3>2. <a name="Preliminaries">Preliminaries</a></h3> +<p>The <code>CVSROOT</code> environment variable listed below is <font +color=red> <strong><blink>required</blink></strong></font>. If you +want to use CVS from within emacs, you'll have to restart it from a +shell that has <code>CVSROOT</code> defined.<p> + +Emacs users might want to add <var>(setq vc-follow-symlinks t)</var> +to your .emacs file to instruct emacs to follow symlinks to +version-controlled plain files.<p> + +For lack of a better place to put the following, I'll put it here. +It's a good idea to insert a CVS/RCS keyword string at the top of +every file that you place under CVS control. This includes source +files, Makefiles, config files, <em>etc</em>. It will embed in the +file a concise record of the filename, last update time, revision +number, and last user who updated it. For C++ files, the keyword +string is: + <pre> + // $<!-- -->Id$ + </pre> +It's 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> + +On Unix systems, you might want to create a file called <code>.cvsrc</code> +in your home directory with the following contents: +<pre><code> +co -P +update -P +</code></pre> +That will cause CVS to prune empty directories on checkout or update. +<p> + + +<hr><p> +<h3>3. <a name="Getting started with ACE on CVS">Getting started with ACE on CVS</a></h3> +Note: the first three steps are for UNIX platforms. See the +<a href="#Windows NT setup">Windows NT setup</a> section for +setup information for Windows NT. +<ol> + <li>% <code>setenv CVSROOT /project/cvs-repository </code> #### + site-specific location<p> + <li>cd to the directory that you want your ACE_wrappers workspace + to be under.<p> + <li>% <code>setenv ACE_ROOT `pwd` </code> #### to set the ACE_ROOT + environment<p> + <li>Change your umask to something like 022 <strong>if</strong> you want + others to be able to view your workspace.<p> + <li>% <code>cvs checkout ACE_wrappers</code><p> + <li>Add the ace/config.h and include/makeinclude/platform_macros.GNU + symlinks. For example, for Sun C++ on SunOS 5.5: + <pre><code> + % ln -s config-sunos5.5.h ace/config.h + % ln -s platform_sunos5_sunc++.GNU include/makeinclude/platform_macros.GNU + </code></pre><p> + <li>Hack away in your own workspace. All files have user write + permission. +</ol><p> + + +<hr><p> +<h3>4. <a name="Windows NT setup">Windows NT setup</a></h3> +Thanks to <a href="http://www.cs.wustl.edu/~brunsch/">Darrell Brunsch</a> +and <a href="http://www.cs.wustl.edu/~irfan/">Irfan Pyarali</a> for +providing this NT setup information. (It contains a site-specific +<code>CVSROOT</code>.)<p> + +You can use the CVS client under Windows NT to keep a local repository +of ACE. To set it up, follow these steps:<P> +<ol> + <li>Find or create a directory in your path (I just created a utils + directory and added it to my path).<p> + <li>Download the files cvs.exe, patch.exe, and win32gnu.dll. They're + in a zip file on + <a href="http://download.cyclic.com/pub/cvs-1.10.5/windows/">Cyclic + Software's download site.</a> (Cyclic Software hsa been acquired + by SourceGear Corporation.)<p> + + Alternatively, <a href="http://www.wincvs.org">WinCVS</a> provides + a graphical front-end on Windows. <strong>NOTE: </strong>if + you use WinCVS, beware that it enables read-only checkout by + default. So be sure not to check out that way if you want to + edit files.<p> + + Thanks to <a href="http://www.riverace.com">Steve Huston</a> for that + note.<p> + <li>Be sure that the <a href="http://www.sourcegear.com/CVS">SourceGear</a> + cvs utilities precede any + <a href="http://www.cygnus.com/misc/gnu-win32/">Cygnus + GNU-Win32 utilities</a> in your path, something like this:<p> + + <pre> + d:\utilities\cvs;D:\utilities\gnuwin32\b18\H-i386-cygwin32\bin + </pre> + <li>Add to your environment: <BR> + <code>LOGNAME = </code><em>username</em><br> + <code>CVSROOT = ace.cs.wustl.edu:/project/cvs-repository</code><br> +</ol> +Please note that this approach uses a remote shell. So, your +account must be able to rsh to the server machine.<p> + +For an alternative approach that uses CVS pserver instead of rsh, +please see Darrell's <a +href="http://tao.cs.wustl.edu/howto/use_win32_pserver.html">CVS +pserver page for Win32</a>.<p> + + +<hr><p> +<h3>5. <a name="Checking in changes">Checking in changes</a></h3> +By convention, any repository change should be documented in +an appropriate ChangeLog. The ChangeLog entry should start with +a line of this form: +<pre> + ChangeLogTag: <em>date</em> <em>name</em> <<em>email address</em>> +</pre><p> + +In all examples below, <code>ChangeLog</code> refers to appropriate +ChangeLog.<p> + +<h4>5.1. Command line</h4> + To enter your workspace changes into the master repository from + the command line::<p> +<pre> + % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>file(s)/directori(es)</em> ChangeLog +</pre><p> + +<h4>5.2. From emacs</h4> + To checkin one file or directory to the repository:<p> +<ol> + <li><code>C-x v v </code>(vc-next-action) to check the file or directory + in<p> + <li>Insert the ChangeLogTag, using the first line of your ChangeLog entry<p> + <li><code>C-c C-c </code> to finish checkin +</ol><p> + + +<hr><p> +<h3>6. <a name="Workspace update">Workspace update</a></h3> +To update your workspace from the master repository, to pick up changes +by others:<p> + <blockquote>% <code>cvs update ACE_wrappers</code></blockquote><p> + +cvs will print out a line for each directory that it enters +(by default, it will recurse through the directory tree; to +disable this and only update one directory, add <code>-l</code> +after <code>update</code>).<p> + +cvs will print out a line for each file that differs from what is +in the repository. This first character indicates the file status: +<ul> + <li><code>U</code> the file was brought <strong>up-to-date</strong>, so + now it agrees with what is in the repository + <li><code>P</code> same as <code>U</code>, except used by CVS server + when it sends a patch instead of the entire file + <li><code>M</code> the file is <strong>modified</strong> in your + workspace with respect to the repository; without any + other message, it means that the file was not modified + by this update operation. If changes were + successfully merged (without conflict), then cvs will + note on the previous lines. + <li><code>C</code> the file needs to be updated, but a + <strong>conflict</strong> was detected. The file now + contains the differences, demarcated with + <code><<<<<<<</code> and + <code>>>>>>>></code>. The + unmodified file was moved to <em>.#file.revision</em>. + You'll need to edit the file to resolve the + differences. I get a lot of false positives on files + that I know I didn't modify locally: for those cases, + I just remove the file and rerun update. + <li><code>A</code> or <code>R</code> The file has been + <strong>added</strong> or <strong>removed</strong> + to/from your workspace, but the add or + remove has not yet been committed. + <li><code>?</code> the file is <strong>private</strong> to your + workspace: it does not exist in the repository +</ul> + +To show what update would do to the currently directory (recursively), +without actually doing it: +<blockquote>% <code>cvs -n update <strong>.</strong></code></blockquote> +<blockquote> + The -q option to update suppresses the ``Updating'' message for each + directory: + <blockquote>% + <code>cvs -nq update <strong>.</strong></code></blockquote> +</blockquote> + +To get the status of the current directory (recursively) with respect to +the repository: +<blockquote>% <code>cvs status <strong>.</strong></code></blockquote> + +To get the status of a single file with respect to the repository, +with symbolic tags displayed: +<blockquote>% <code>cvs status -v <em>file</em></code></blockquote> + +To show local (in current workspace) changes to one or more files, +relative to the versions that they were checked out from: +<blockquote>% <code>cvs diff <em>file(s)/directori(es)</em></code> +</blockquote> + +To show local (in current workspace) changes to one or more files, +relative to the latest versions in the repository: +<blockquote>% <code>cvs diff -rHEAD <em>file(s)/directori(es)</em></code> +</blockquote><p> + + +<hr><p> +<h3>7. <a name="Adding/removing files/directories">Adding/removing files/directories</a></h3> +Adding one or more text files requires two steps: +<pre> + % cvs add <em>file . . .</em> + % cvs commit <em>file . . .</em> +</pre><br> +The commit may be done later, on the entire directory, etc. +Note that cvs <strong>add</strong> is not recursive, so +that the files in each directory of a hierarchy must be +added in separate commands. Also, only files in the current +directory can be added.<p> + +Binary files require the <code>-kb</code> option to <code>cvs add</code>: +<pre> + % cvs add -kb <em>file . . .</em> + % cvs commit <em>file . . .</em> +</pre><br> +If not applied during the <code>add</code> operation, <code>-kb</code> +can be applied using <code>cvs admin -kb</code>.<p> + +Removing files is similar, except the cvs <strong>remove</strong> +command is used instead of the <strong>add</strong> command: +<pre> + % cvs remove <em>file . . .</em> + % cvs commit <em>file . . .</em> +</pre><p> + +An add of an empty directory doesn't require a commit.<p> + +Removing a directory is more problematic. There is no CVS command to +remove (or rename) a directory: it has to be done behind CVS' back, +directly in the repository. This is by design; a CVS command can't be +used to irrevocably destroy information. Therefore, never remove a +directory. You can safely remove all of the files in it, using the +above steps. + +To just remove a directory from a workspace (without removing it from +the repository): first, remove the directory and all of its files +using usual OS commands. Second, run +<pre> + % cvs update -P <em>directory-path </em> +</pre><br> +to prune the directory from the workspace.<p> + + +<hr><p> +<h3>8. <a name="Modules">Modules</a></h3> +Instead of referring to ``ACE_wrappers'' above, you can refer +to a module, such as ace, tests, performance-tests, and so on. +To get a list of known modules, use the -c option to checkout: +<blockquote>% <code>cvs checkout -c</code></blockquote><p> + +<strong>IMPORTANT</strong>: if a subdirectory is added to ACE, it +<strong>must</strong> be added to the list of known modules in +<code>$CVSROOT/CVSROOT/modules</code>! If you don't want to edit that +file, please tell <a href="mailto:levine@cs.wustl.edu">David</a>. The +<code>CVSROOT</code> files are under RCS control. emacs' VC tools +handle them the same way that they handle CVS-controlled files. So, +you can check them out and back in with <code>C-x v v</code>.<p> + +To add an entirely new module: +<ol> + <li>Create the directories/files.<p> + <li>Add the module to <code>$CVSROOT/CVSROOT/modules</code>, as + mentioned above.<p> + <li>Create a new directory in <code>$CVSROOT</code>, owned by the appropriate + group and with sufficient (probably group write+setuid) permissions.<p> + <li>Change to the directory just above the top-level directory for + the module in your workspace.<p> + <li><code>cvs checkout <em>new module name</em></code><p> + <li>Add all of the new directories/files in the module, as described + <a href="#Adding/removing files/directories">above</a>, then commit. +</ol> + + +<hr><p> +<h3>9. <a name="ChangeLog updates">ChangeLog updates</a></h3> +To automatically update the ChangeLog, use the emacs command: +<pre> + C-u C-x v a +</pre> +Thanks to James Hu <jxh@cs.wustl.edu> for this useful tidbit.<p> + +To set a specific host address in your ChangeLog entries, add a line +like this to your <code>~/.emacs</code>: +<pre> + (setq mail-host-address "cs.wustl.edu") +</pre><p> + +To set a specific name in your ChangeLog entries, add a line like +this to your <code>~/.emacs</code>: +<pre> + (setq user-full-name "my full name") +</pre> +Otherwise, CVS uses the name (GECOS field) from your passwd entry.<p> + + +<hr><p> +<h3>10. <a name="File revisions">File revisions</a></h3> +File revisions in and below the current directory may be tagged with: +<pre> + % cvs tag <em>tag</em> <strong>.</strong> +</pre><p> + +To retrieve an old revision of a file, use the -r option to cvs +<strong>update</strong>: +<pre> + % cvs update -r<em>tag file</em> +</pre> +The revision tags of a file can be viewed +with the cvs <strong>log</strong> command.<p> + +Or, to retrieve the file and/or directory versions as of a +certain date and time, use the -D option to cvs <strong>update</strong>, +for example: +<pre> + % cvs update -D "last Saturday" OS.{h,i,cpp} +</pre> + +<strong>NOTE: </strong>The -r and -D options are ``sticky''; they will +apply to the file(s)/directories until overwritten with another revision +tag or date, or until disabled. +They are disabled by using the update -A option, which also checks out +the latest revision: +<pre> + % cvs update -A <em>file</em> +</pre><p> + +To change the log message for a particular revision of a file:<p> +<pre> + % cvs admin -m<em>revision</em>:"<em>new message</em>" <em>file</em> +</pre><p> + + +<hr><p> +<h3>11. <a name="File reversion">File reversion</a></h3> +There are a few ways to revert a file to the last revision that is in +the repository, if you want to abandon your changes to it: + +<ul> + <li>The easiest way to abandon your changes <strong>in your + workspace</strong> is to use the emacs command <code>C-x v u </code> + (vc-revert-buffer). Or from the shell, you could remove the + file and update it with <code>cvs update <em>file</em></code>.<p> + + <li><strong>Do not remove a revision from the cvs repository + directly.</strong> To revert a revision that you made, use the + following command to revert the change in your workspace and + check in the reverted version: +<pre> + % cvs update -j<em>after_change</em> -j<em>before_change</em> <em>file</em> +</pre> + For example, if the version containing the version you want to + revert is 4.10, then, <em>after_change</em> should be + <code>4.10</code> and <em>before_change</em> should be + <code>4.9</code>.<p> + + <strong>NOTE:</strong> this doesn't seem to work with CVS version 1.10.<p> + + Make sure the patch succeeded (if you are not reverting a change + you made long time ago, most likely it will succeed) before + checking in the reverted version.<p> + + Also make sure the you add a ChangeLog entry explaining why + you reverted the change. +</ul> + +<hr><p> +<h3>12. <a name="Renaming a file">Renaming a file</a></h3> +There are three ways to rename a CVS-controlled file. The first +preserves the revision log, but it must be accessed by either the +original or new name, depending on what you want to see. And +revision numbers will start over at 1.0 unless set with the +<code>-r</code> option. It's all done in the user's workspace: +<pre> + Add ChangeLog entry containing: + Renamed <em>OLD</em> to <em>NEW</em> + % mv <em>OLD</em> <em>NEW</em> + % cvs remove <em>OLD</em> + % cvs add <em>NEW</em> + % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>OLD</em> <em>NEW</em> ChangeLog +</pre><br> + +The second method maintains the revision log in one place and the +revision number sequence. It makes fetching old releases of the +module more difficult, which may be an advantage or disadvantage +depending on local circumstances. It is more dangerous because the +repository is modified directly; see the warning in the cvs info page +about other users accessing the history file while it is being moved: +<pre> + % cd $CVSROOT/<em>MODULE</em> + % mv <em>OLD</em>,v <em>NEW</em>,v +</pre><br> + +The third method is to copy the history file in the repository. +Instead of moving the history file, as in the second method above, +copy it. It's not necessary to prevent others from accessing the +file. The cvs info pages show other steps, to remove the old tags +from the new history file. While technically correct, I don't think +that's necessary for our purposes.<p> + +While the first method is the safest, it has the distinct disadvantage +of hindering access of old versions. If that's not a problem for a +particular file, then it is the preferred approach. As Carlos would +probably say if you asked him, ``it's the right thing to do.''<p> + +If easy access to old versions is desired, I would use the third +approach: copy the history file in the repository.<p> + + +<hr><p> +<h3>13. <a name="Local version control">Local version control</a></h3> +All version control with CVS is done through the master repository. +CVS doesn't provide any facility for local checkpoints. If you want +local version control in your workspace, there's nothing to stop you +from using RCS or SCCS locally (but it might confuse emacs' version +control). The preferred approach is to create a branch, and +checkpoint as much as you want on that branch. When the time comes to +make the changes public, just merge the branch. See the <a +href="#Branches">Branches</a> section of this page, and the cvs man +page, for instructions on creating and using a branch.<p> + + +<hr><p> +<h3>14. <a name="Branches">Branches</a></h3> +To create a branch, you must first create a tag to identify the +branch. Then, you can checkout on that branch. There are various +ways to go about doing this, but these steps show how when starting +from scratch: + +<pre> + % cvs rtag -b <em>branch_tag</em> <em>module(s)</em> + % cvs checkout -r <em>branch_tag</em> <em>module(s)</em> +</pre> + +It's not necessary to checkout all the files in a directory or module +on the branch, but it's probably the easiest and least confusing +approach in the long run. <strong>Note</strong> that it's usually +tricky to tag individual files on a branch because CVS won't +be able to identify which module they're in. By way of example, +to checkout just <code>ace/OS.h</code> on a branch, you'd have to do +this, assuming that you're already in the <code>ace</code> directory: +<pre> + % cd .. + % cvs rtag -b <em>branch_tag</em> ace/OS.h + % cvs checkout -r <em>branch_tag</em> ace/OS.h + % cd ace +</pre> +This can be done after modifying files, and CVS will retain your +modifications. However, if you don't trust CVS, it's best to backup +your files first.<p> + +Checkouts on a branch are sticky, and will apply until the head +version of the file(s) have been checked out with the <code>-A</code> +option to <code>cvs update</code>. Presumably, this will be done +after merging the branch to the main trunk. See the +<a href="#Old file revisions">Old file revisions</a> section of this +page for similar discussion of sticky tags.<p> + +To merge an entire branch to the main trunk, use the <code>-j</code> +(for <em>join</em>) option to <code>cvs checkout</code>. That just +merges in your workspace; the repository can then be updated from the +workspace using <code>commit</code> as usual: +<pre> + Add ChangeLog entry containing: + merged <em>branch_tag</em> + % cvs checkout -P -Aj <em>branch_tag</em> <em>file(s)/directori(es)</em> + % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>file(s)/directori(es)</em> ChangeLog +</pre> +(The <code>-A</code> is needed if you are in the workspace that has +the checkouts on the branch. It updates the workspace to the latest +versions on the main trunk. So, <strong>don't</strong> use it if +you want to keep working on the branch.)<p> + +To merge any changes on the main trunk to a branch, the first time: +<pre> + Add ChangeLog entry containing: + merged main trunk changes + % cvs update -jHEAD <em>file(s)/directori(es)</em> + % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>file(s)/directori(es)</em> ChangeLog + % cvs tag <em>merged_foo_branch</em> <em>file(s)/directori(es)</em> +</pre> + +<strong>AFTER MERGING, APPLY A LABEL TO THE SOURCE BRANCH, +as shown above.</strong> +For example, if you merged from the main trunk to a branch, +apply a new label to the main trunk. You can use that label +later to merge any subsequent changes on the main trunk. The +<code>cvs</code> info pages have a good example of this. +Briefly: + +<pre> + Add ChangeLog entry containing: + merged main trunk changes + % cvs update -j<em>merged_foo_branch</em> -jHEAD <em>file(s)/directori(es)</em> + % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>file(s)/directori(es)</em> ChangeLog + % cvs tag <em>merged_foo_branch_again</em> <em>file(s)/directori(es)</em> +</pre> + + +Note that any files created on the branch won't be visible on +the main trunk, even after the merge. I'm not sure of right +way to take care of this, but I follow these steps for each +file created on the branch:<p> +<ol> + <li>In the repository, move the RCS file from the <var>Attic</var> + directory up to its parent directory. + <li>Edit the RCS file, replacing the "dead" state with "Exp". + <li>Merge from the branch to the main trunk: + <pre> + Add ChangeLog entry containing: + merged <em>branch_tag</em> + % cvs update -Aj <em>branch_tag</em> <em>file</em> + % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>file</em> ChangeLog + </pre> +</ol> + +To create a file on a branch, in a directory that has not been +checked out on the branch: +<ol> + <li>Add the file and commit it to the main branch + <li>Create the branch tag on the file, and check the file out + on the branch. + <li>Remove the file, cvs remove the file, and commit the removal. + <li>Check the file out on the branch. +</ol> +Alternatively, the recommended procedure is to simply check the +entire directory out on the branch, then create the file.<p> + +In general, deleting branch tags is not recommended. But it's often +necessary, especially when getting started with branches. The +<code>-d</code> option to <code>cvs rtag</code> can be used to delete +a branch tag.<p> + +The use of a branch for maintaining a release is illustrated +in the section on the <a href="#ACE release bug-fix branch">ACE +release bug-fix branch</a>.<p> + + +<hr><p> +<h3>15. <a name="Remote repositories">Remote repositories</a></h3> +Before setting up a repository for remote access, be sure to see +the <a href="file:/project/doc/pkg/cvs/cvs-1.10/doc/cvs.ps">CVS +documentation</a>. There are important security considerations.<p> + +An easy way to access a remote repository is via rsh. These steps +ought to get you going: +<ol> + <li>Install cvs on the local system, if it doesn't already have it.<p> + <li>Add yourself to an <code>.rhosts</code> file on the remote machine + of a user that can access the repository.<p> + <li>Set your <code>CVSROOT</code> environment variable to:<br> + <pre> + <em>remote user</em>@<em>remote host</em>:<em>remote repository</em> + </pre> +</ol> +Then, you can issue cvs commands just as you would on the remote machine.<p> + +If you have ssh on your client machine, you can use ssh instead of +rsh. Just set your <code>CVS_RSH</code> environment variable to +<code>ssh</code>. You don't need to add an <code>.rhosts</code> +entry with ssh, so it's the best alternative for remote repository +access.<p> + +Another way to access to remote cvs repository is to run cvs in +client-server mode. To use this feature, first check if you have your +<code>HOME</code> environment variable set properly. Then, set your +<code>CVSROOT</code> to:<p> +<pre> + :pserver:your_user_id@ace.cs.wustl.edu:/project/cvs-repository +</pre><p> +Then, do a cvs login as +<pre> + % cvs login +</pre><p> +Type in your password when CVS prompts you to enter your password. +This will create a file call "<code>.cvspass</code>" in your home +directory (as defined by <code>$HOME</code>) that contains the +encripted password for the server. You can now perform regular CVS +operation directly.<p> + +<strong>Notice:</strong> It's not difficult to decode the passwords in +<code>.cvspass</code> file. Therefore, never use cvs in client-server +mode in a unsafe environment. (Where others can read your .cvspass +file.)<p> + +To speed up client-server mode operations, it might help to use +the <code>cvs</code> <code>-z</code> option. It requires that +<code>gzip</code> be on your search path on both the client and +server. An example use is:<p> +<pre> + % cvs -z 1 update +</pre><p> + +Thanks to <a href="http://www.cs.wustl.edu/~nanbor/">Nanbor Wang</a> +and <a href="http://www.cs.wustl.edu/~brunsch/">Darrell Brunsch</a> +for figuring out and providing this documentation for cvs +client-server mode.<p> + + +<hr><p> +<h3>16. <a name="Exporting from CVS">Exporting from CVS</a></h3> +There are two different strategies for exporting CVS-controlled files, +such as for code releases. The first, preferred approach is to use +the cvs <strong>export</strong> command to stage a version of the +controlled files to a non-controlled directory. This version will +not have any of the CVS files in it. THe second approach is to +create a release from a user's CVS-controlled workspace.<p> + +To use cvs <strong>export</strong>, either a date or revision +tag must be specified. It's usually a good idea to tag the sources +with a revision tag and use that. So, the steps would be:<br> +<pre> + % cd <em>root of directory tree</em> + % cvs tag <em>tag</em> <strong>.</strong> + % cd <em>staging directory</em> + % cvs export -r <em>tag</em> + % find . -print | cpio -o -H tar | gzip -9 > <em>tar filename</em> +</pre> + +To tag and create a release in the form of a gzip'ped tar file +from a user's workspace: +<pre> + % cd <em>root of directory tree</em> + % cvs tag <em>tag</em> <strong>.</strong> + % find . -name CVS -prune -o -print | cpio -o -H tar | gzip -9 > <em>tar filename</em> +</pre> + +The relative advantage of the first, export approach is that you will +be sure that only CVS-controlled files will be released. However, it +requires the extra step and creation of the staging area.<p> + +This extra step is one reason why we don't currently stage releases of +ACE. Instead, they are built from Doug's personal workspace. That +workspace is visible on the web, so that ACE users can track the very +latest changes without any explicit action by Doug. If we were to +stage it, to make any change visible would require an explicit move to +the staging area.<p> + + +<hr><p> +<h3>17. <a name="ACE_wrappers-frozen workspace">ACE_wrappers-frozen workspace</a></h3> + +This section applies to the DOC group at Wash. U. only:<p> + +There's now a ``frozen'' ACE in +<strong>/project/cvs-repository/ACE_wrappers-frozen/</strong>. +It contains the latest official release of ACE.<p> + +There are complete g++ 2.7.2.1 and Sun C++ 4.2 builds in the +<strong>build</strong> directory below the directory noted above. +To use one of these builds, set or prepend to these environment variables:<p> +<table border> +<tr> +<th>Compiler</th> +<th>set <strong>WRAPPER_ROOT</strong> to:</th> +<th>prepend to <strong>LD_LIBRARY_PATH</strong>:</th> +<tr> +<td>g++</td> +<td>/project/cvs-repository/ACE_wrappers-frozen/build/SunOS5_g++</td> +<td>/project/cvs-repository/ACE_wrappers-frozen/build/SunOS5_g++/ace</td> +<tr> +<td>Sun C++</td> +<td>/project/cvs-repository/ACE_wrappers-frozen/build/SunOS5_sunc++-4.2</td> +<td>/project/cvs-repository/ACE_wrappers-frozen/build/SunOS5_sunc++-4.2/ace</td> +</table><p> + + +<hr><p> +<h3>18. <a name="ACE release bug-fix branch">ACE release bug-fix branch</a></h3> + +This section applies to the DOC group at Wash. U. only:<p> + +The ``main line'' CVS branch will (continue to) be the ``new features'' +branch. If you want the very latest and greatest ACE at all times, no +changes to the use of your workspace are required. Just +<code>cvs update</code> it as usual.<p> + +Bug fixes to the official release will go on a branch. For the ACE +4.2 release, for example, this branch is name +<strong>ACE-4_2</strong>. (CVS does not allow periods in branch names +or any other tags.) To use it, do this in your workspace: +<pre> + % cd .. + % cvs checkout -r ACE-4_2 ACE_wrappers +</pre> + +From that point on, all updates and commits in that workspace +will be from/to the <strong>ACE-4_2</strong> branch.<p> + + +<hr><p> +<h3>19. <a name="Warning messages/problems">Warning messages/problems</a></h3> +<dl> +<blockquote> + + <dt><pre>cvs update: conflict: <em>foo </em>is modified but no longer in the repository<br> +U <em>bar</em></pre> + <dd>That might indicate that file <em>foo</em> was renamed to <em>bar</em>. + If so, <em>foo</em> should be removed from the current workspace. (And + that warning will not reoccur for the workspace, because its CVS will + have removed <em>foo</em> from the workspace entries and checked out + <em>bar</em>.)<p> + + <dt><pre>cvs update: [<em>time</em>] waiting for <em>user</em>'s lock in <em>repository</em></pre> + <dd>Check for lock files and directories in the <code>$CVSROOT/CVSROOT</code> + and lock files anywhere in the <code>$CVSROOT</code> hierarchy. Remove + ones that no longer appear to be in use and retry. Lock files and + directories have names starting with ``.#'', I think.<p> + + <dt>Why does a file in the repository not have group and/or other read + permission?<p> + <dd>Because it didn't have those permissions when it was added to the + repository. To fix it, those permissions can be added to the ,v file in + the repository. To avoid it, those permissions should be added to the + file before it is created/committed the first time.<p> + + <dt>Why does CVS keep removing group/and or other read permission from a + file in my workspace?<p> + <dd>Because your umask is something like 7 or 77. Change it to something + like 22. If you don't want to change it for everything, then alias cvs; + in t/csh:<br> + <blockquote>% <code>alias cvs '(umask 22; \cvs \!*)'</code></blockquote> + <p> + Also, the file will have to have mode 644 before you commit it. So if + your editor removes group/other read permission, you'll have to ``fix'' + that as well.<p> + + <dt>I modified Makefile in my workspace so I don't build static or shared + ACE libraries. But, I forgot about it and commited the modified + Makefile to the repository. Help?<p> + <dd>You'll have to correct the Makefile and commit your corrections.<p> + + Instead of modifying your makefile, try these commands to build the + ACE static and shared libraries, respectively: + <blockquote>% make <code>static_libs_only=1</code></blockquote> + + <blockquote>% make <code>shared_libs_only=1</code></blockquote> + +</blockquote> +</dl><p> + + +<hr><p> +<h3>20. <a name="For more info on CVS">For more info on CVS</a></h3> +Please see these sources for more information on CVS: +<ul> + <li>David Discher's <a href="http://dpd.dpdtech.com/cvs/">Quick N + Dirty CVS HOW-TO</a> is really helpful.<p> + + <li>Please check out David G. Grubbs' great, comprehensive <a + href="http://cellworks.washington.edu/pub/docs/cvs/cvs-FAQ/cvsfaq0.html">"The + CVS FAQ"</a>.<p> + + <li><a href="http://www.loria.fr/~molli/cvs-index.html">CVS Bubbles</a> + is a collection of useful CVS information and links.<p> + + <li>Commercial support for CVS is available from <a + href="http://www.sourcegear.com/CVS">SourceGear Corporation</a>. + Their web pages are very helpful.<p> + + <li>Terris Linenbach has an interesting, brief discussion of + source code management on-line at <a + href="http://devguy.com/fp/ProgrammersCanvas">Programmers' + Canvas</a>. Programmers' Canvas is a pattern language, + also quite interesting. +</ul> + +<p><hr> +<p>Back to +<a href="http://www.cs.wustl.edu/~levine">David L. Levine's home page</a>. +<p> + + + +<font size=-1> +Last modified 11:15:16 CDT 30 September 2002. +<br> +[an error occurred while processing this directive] +[an error occurred while processing this directive] +<p> +</font> + + + +</body> +</html> diff --git a/ACE/docs/Download.html b/ACE/docs/Download.html new file mode 100644 index 00000000000..b2f5f49cfc1 --- /dev/null +++ b/ACE/docs/Download.html @@ -0,0 +1,367 @@ +<!-- $Id$ --> + +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> +<HTML> +<HEAD> + <TITLE>Obtaining ACE, TAO and CIAO</TITLE> +</HEAD> + +<BODY + text="#000000" + bgColor="#ffffff"> + +<HR> + <H3>Obtaining ACE, TAO, and CIAO</H3> + +Welcome to the download page for ACE, TAO, and CIAO, which are +open-source middleware developed by the <A +HREF="http://www.dre.vanderbilt.edu/">DOC group</a> that provide that +following capabilities: + +<P> + +<LI> <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A> is an +open-source framework that provides many components and <A +HREF="http://www.cs.wustl.edu/~schmidt/POSA">patterns</A> for +developing high-performance, distributed real-time and embedded +systems. ACE provides powerful, yet efficient abstractions for +sockets, demultiplexing loops, threads, synchronization primitives. +</P> + +<P> + +<LI> <A HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</A> (The ACE +ORB) is an open-source implementation of a <A +href="http://www.cs.wustl.edu/~schmidt/corba.html">CORBA</A> Object +Request Broker (ORB) built using components and patterns in the ACE +framework. + +</P> + +<P> + +<LI> <A HREF="http://www.cs.wustl.edu/~schmidt/CIAO.html">CIAO</a> +(Component Integrated ACE ORB) is an open-source implementation of the +CORBA Component Model (CCM) built on top of TAO. </P> +</LI> + +<A +HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.html">Commercial +support and pre-built versions</A> of ACE, TAO, and CIAO are available +from a number of companies. <P> + +<HR> + + <H3>Downloading Freely Available Versions of ACE, TAO, and CIAO</H3> + +<P> + +Our process for developing and releasing ACE, TAO, and CIAO, as well +as the role of stable releases vs. beta kits is described in detail in +the DOC group's <A +HREF="https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/ACE/docs/ACE-development-process.html?revision=HEAD"> +development and release process</A> document. Please check that +document to decide which version below is more appropriate for your +case. You may want to understand the DOC group's <A +HREF="https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/ACE/docs/ACE-bug-process.html?revision=HEAD"> +bug fixing policies</A> when you make this decision. +</P>The full packages to contain all sources with pre generated makefiles for GNU make, Visual C++ 7.1/8.0, Borland +C++ make. The sources only packes just contain the sources, you have to generate your own makefiles with MPC. +</P> + +<UL> +<LI> <B>Latest Beta Kit.</B> The latest <A + HREF="https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/ACE/VERSION?revision=HEAD">version</a> +of the ACE, TAO, and CIAO beta kit is available for + download below. <P> + +<TABLE BORDER="4"> + <TR><TH>Filename</TH><TH>Description</TH><TH>Full</TH><TH>Sources only</TH></TR> + <TR><TD>ACE+TAO+CIAO.tar.gz</TD> + <TD>ACE+TAO+CIAO (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO.tar.gz">FTP</A>] + </TD> +<!-- + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO-src.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO-src.tar.gz">FTP</A>] + </TD> +--> + </TR> + <TR><TD>ACE+TAO+CIAO.tar.bz2</TD> + <TD>ACE+TAO+CIAO (tar+bzip2 format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO.tar.bz2">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO.tar.bz2">FTP</A>] + </TD> +<!-- + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO-src.tar.bz2">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO-src.tar.bz2">FTP</A>] + </TD> +--> + </TR> + <TR><TD>ACE+TAO+CIAO.zip</TD> + <TD>ACE+TAO+CIAO (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO.zip">FTP</A>] + </TD> +<!-- + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO-src.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO+CIAO-src.zip">FTP</A>] + </TD> +--> + </TR> + <TR><TD>ACE+TAO.tar.gz</TD> + <TD>ACE+TAO (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO.tar.gz">FTP</A>] + </TD> +<!-- + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO-src.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO-src.tar.gz">FTP</A>] + </TD> +--> + </TR> + <TR><TD>ACE+TAO.tar.bz2</TD> + <TD>ACE+TAO (tar+bzip2 format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO.tar.bz2">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO.tar.bz2">FTP</A>] + </TD> +<!-- + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO-src.tar.bz2">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO-src.tar.bz2">FTP</A>] + </TD> +--> + </TR> + <TR><TD>ACE+TAO.zip</TD> + <TD>ACE+TAO (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO.zip">FTP</A>] + </TD> +<!-- + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO-src.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE+TAO-src.zip">FTP</A>] + </TD> +--> + </TR> + <TR><TD>ACE-html.tar.gz</TD> + <TD>Doxygen documentation for ACE+TAO+CIAO (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-html.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-html.tar.gz">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-html.tar.bz2</TD> + <TD>Doxygen documentation for ACE+TAO+CIAO (tar+bzip2 format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-html.tar.bz2">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-html.tar.bz2">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-html.zip</TD> + <TD>Doxygen documentation for ACE+TAO+CIAO (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-html.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-html.zip">FTP</A>] + </TD> + </TR> + <TR><TD>ACE.tar.gz</TD> + <TD>ACE only (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE.tar.gz">FTP</A>] + </TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-src.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-src.tar.gz">FTP</A>] + </TD> + </TR> + <TR><TD>ACE.tar.bz2</TD> + <TD>ACE only (tar+bzip2 format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE.tar.bz2">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE.tar.bz2">FTP</A>] + </TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-src.tar.bz2">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-src.tar.bz2">FTP</A>] + </TD> + </TR> + <TR><TD>ACE.zip</TD> + <TD>ACE only (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE.zip">FTP</A>] + </TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-src.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/ACE+TAO-distribution/ACE-src.zip">FTP</A>] + </TD> + </TR> +</TABLE> + +<P> + Patches between older beta kit versions are available via FTP at + <A HREF="ftp://download.dre.vanderbilt.edu/diffs">this location</A>. +</P> + +<LI> <B>Latest Release.</B> The latest release is ACE 5.5, TAO 1.5, and CIAO 0.5 +(ACE+TAO+CIAO x.5), please use the links below to download it.<P> + +<TABLE BORDER="4"> + <TR><TH>Filename</TH><TH>Description</TH><TH>Download</TH></TR> + <TR><TD>ACE-5.5+TAO-1.5+CIAO-0.5.tar.gz</TD> + <TD>ACE+TAO+CIAO (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5+TAO-1.5+CIAO-0.5.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5+TAO-1.5+CIAO-0.5.tar.gz">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5+TAO-1.5+CIAO-0.5.zip</TD> + <TD>ACE+TAO (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5+TAO-1.5+CIAO-0.5.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5+TAO-1.5+CIAO-0.5.zip">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5+TAO-1.5.tar.gz</TD> + <TD>ACE+TAO (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5+TAO-1.5.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5+TAO-1.5.tar.gz">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5+TAO-1.5.zip</TD> + <TD>ACE+TAO (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5+TAO-1.5.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5+TAO-1.5.zip">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5-html.tar.gz</TD> + <TD>Doxygen documentation for ACE+TAO (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5-html.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5-html.tar.gz">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5-html.zip</TD> + <TD>Doxygen documentation for ACE+TAO (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5-html.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5-html.zip">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5.tar.gz</TD> + <TD>ACE only (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.tar.gz">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5.zip</TD> + <TD>ACE only (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.zip">FTP</A>] + </TD> + </TR> +</TABLE> +<P> + + +<LI> <A NAME="stable-beta"></A><B>Latest BFO Beta.</B> The BFO beta +for the latest release of ACE 5.5 and TAO 1.5 is, ACE 5.5.1 and TAO +1.5.1 (ACE+TAO x.5.1). + +please use the links below to download it. +<TABLE BORDER="4"> + <TR><TH>Filename</TH><TH>Description</TH><TH>Download</TH></TR> + <TR><TD>ACE-5.5.1+TAO-1.5.1+CIAO-0.5.1.tar.gz</TD> + <TD>ACE+TAO+CIAO (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1+TAO-1.5.1+CIAO-0.5.1.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1+TAO-1.5.1+CIAO-0.5.1.tar.gz">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5.1+TAO-1.5.1+CIAO-0.5.1.zip</TD> + <TD>ACE+TAO (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1+TAO-1.5.1+CIAO-0.5.1.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1+TAO-1.5.1+CIAO-0.5.1.zip">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5.1+TAO-1.5.1.tar.gz</TD> + <TD>ACE+TAO (tar+gzip format)</TD> + <TR><TD>ACE-5.5.1+TAO-1.5.1.tar.gz</TD> + <TD>ACE+TAO (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1+TAO-1.5.1.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1+TAO-1.5.1.tar.gz">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5.1+TAO-1.5.1.zip</TD> + <TD>ACE+TAO (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1+TAO-1.5.1.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1+TAO-1.5.1.zip">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5.1-html.tar.gz</TD> + <TD>Doxygen documentation for ACE+TAO (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1-html.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1-html.tar.gz">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5.1-html.zip</TD> + <TD>Doxygen documentation for ACE+TAO (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1-html.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1-html.zip">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5.1.tar.gz</TD> + <TD>ACE only (tar+gzip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1.tar.gz">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1.tar.gz">FTP</A>] + </TD> + </TR> + <TR><TD>ACE-5.5.1.zip</TD> + <TD>ACE only (zip format)</TD> + <TD>[<A HREF="http://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1.zip">HTTP</A>] + [<A HREF="ftp://download.dre.vanderbilt.edu/previous_versions/ACE-5.5.1.zip">FTP</A>] + </TD> + </TR> +</TABLE> +<P> +</UL> +<P> + Older versions of ACE+TAO are also available via HTTP at <A + HREF="http://download.dre.vanderbilt.edu/previous_versions">this location</A> + . This location has a few of the previous major and minor + releases. This location will house all of the releases and betas + released after ACE+TAO-5.2+1.2. +</P> + + <H3>Other Sources for ACE+TAO+CIAO</H3> + +<UL> + <LI>The ACE+TAO Subversion repository can be browsed + <A HREF="https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/"> + via the web</A>. + </LI> + <li>ACE+TAO+CIAO source code may be obtained from the + <a href="https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/ACE/ACE-INSTALL.html?revision=HEAD#power">Subversion repository</a>.</li> + <LI>Stable commercially supported versions of ACE are available from + the Riverace + <A HREF="http://www.riverace.com/"> + web site</A>. + </LI> + <LI>Stable commercially supported versions of TAO are available from + the OCI + <A HREF="http://www.theaceorb.com/"> + web site</A>. + </LI> + <LI> Ken Sedgwick's <A HREF="http://dist.bonsai.com/ken/ace_tao_rpm/">Fedora + RPMs</A> for ACE and TAO. + + <LI>Users have contributed tools to automatically download, + configure and even compile ACE or TAO: + <UL> + <LI><A HREF="mailto:asagar@spdmail.spd.dsccc.com"> + Ajit Sagar</A> has written a + <A HREF="https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/ACE/ACE-install.sh?revision=HEAD"> + Bourne shell script</A> + to automatically download and install ACE on Unix machines. + </LI> + </UL> + </LI> +</UL><P> + +The DOC group is interested in getting help to finish the ACE +Configuration Project, which will fully integrate autoconf, automake +and libtool into the ACE+TAO+CIAO build process. This is work in +progress and works well for ACE and TAO. It is not recommended for +regular installations or builds for CIAO yet, but if you want to help +us improve autoconf support please contact <A +HREF="mailto:d.schmidt@vanderbilt.edu">d.schmidt@vanderbilt.edu</A>. + +</BODY> +</HTML> diff --git a/ACE/docs/README.tutorials b/ACE/docs/README.tutorials new file mode 100644 index 00000000000..8c84c98b1b5 --- /dev/null +++ b/ACE/docs/README.tutorials @@ -0,0 +1,7 @@ +# $Id$ + +ACE tutorials can be found in the following directories: + +. examples/C++NPv1 - C++ Network Programming Volume 1 examples. +. examples/C++NPv2 - C++ Network Programming Volume 2 examples. +. examples/APG - ACE Programmer's Guide examples diff --git a/ACE/docs/Symbol_Versioning.html b/ACE/docs/Symbol_Versioning.html new file mode 100644 index 00000000000..d0d50bca914 --- /dev/null +++ b/ACE/docs/Symbol_Versioning.html @@ -0,0 +1,233 @@ +<!-- $Id$ --> + +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<html> + <head> + <title>Symbol Versioning in ACE</title> + </head> + + <body> + <h3>Symbol Versioning in ACE</h3> + + <p> + To provide a means for ACE-based application developers to avoid + symbol conflicts when multiple versions of ACE are linked to an + application ACE supports <em>versioned namespaces</em>. When + enabled (disabled by default), ACE's versioned namespace support + causes all ACE symbols (classes, free functions, etc) to be + placed within a C++ namespace of the form "<code>namespace + ACE_5_5_1</code>". For example, the <code>ACE_Reactor</code> + would end up being placed in the versioned namespace like so: + </p> + + <blockquote> + <code> +<pre> + namespace ACE_5_5_1 + { + class ACE_Reactor + { + ... + }; + } + using namespace ACE_5_5_1; +</pre> + </code> + </blockquote> + + <p> + Notice that a <code>using</code> clause exposes the ACE types + embedded in the versioned namespace back to the global + namespace. This maximizes source code compatibility. ACE + itself does this through the use of two macros: + </p> + <ul> + <li> + <code>ACE_BEGIN_VERSIONED_NAMESPACE_DECL</code><br> + <ul> + <li> + Expands to "<code>namespace ACE_VERSIONED_NAMESPACE NAME + {</code>", where + <code>ACE_VERSIONED_NAMESPACE_NAME</code> by defaults to + namespace name of the form + <code>ACE_<em>major</em>_<em>minor</em>_<em>beta</em></code>. + Users may override the default by defining the + <code>ACE_VERSIONED_NAMESPACE_NAME</code> preprocessor + symbol in their <code><strong>ace/config.h</strong></code> + header file. + </li> + </ul> + </li> + <li> + <code>ACE_END_VERSIONED_NAMESPACE_DECL</code> + <ul> + <li> + Expands to "<code>} using namespace + ACE_VERSIONED_NAMESPACE_NAME;</code>", where + <code>ACE_VERSIONED_NAMESPACE_NAME</code> is described + above. + </li> + </ul> + </li> + </ul> + <h2>Things ACE-based Application Developers Should Know</h2> + <p> + Every effort has been made to make the versioned namespace + support in ACE as transparent as possible, including transparent + versioned symbol support in the ACE_Service_Configurator when + the ACE_Service_Configurator macros, such as <em>e.g.</em>, + <code>ACE_FACTORY_DECLARE</code>, are used appropriately. No + changes to service configurator directives are necessary. For + example, the <code>ACE_Service_Configurator</code> will + transparently mangle the factory function name in a service + configurator directive on-the-fly, meaning it will only load a + "versioned" factory function name. This allows multiple service + object factory functions, for example, to coexist in the same + process space. + </p> + <p> + There is, however, at least one caveat with respect to source + code compatibility: any forward declarations of ACE symbols must + also be placed within the versioned namespace. For example, if + you have a forward declaration for <code>ACE_Reactor</code> in + your application code, you will need to place it within the + configured ACE versioned namespace as follows: + </p> + <blockquote> + <code> +<pre> + ACE_BEGIN_VERSIONED_NAMESPACE_DECL + class ACE_Reactor; + ACE_END_VERSIONED_NAMESPACE_DECL +</pre> + </code> + </blockquote> + <p> + This must only be done once, as these macros hide the versioned + namespace name details from the application. Alternatively, you + could place the forward declaration in a namespace that is an + alias of the ACE versioned namespace, <em>e.g.</em>: + </p> + <blockquote> + <code> +<pre> + namespace Foo = ACE_VERSIONED_NAMESPACE_NAME;</code> + namespace Foo { + class ACE_Reactor; + } + using namespace Foo; +</pre> + </code> + </blockquote> + <p> + Versioned namespace support in ACE may be enabled by adding + <code>versioned_namespace=1</code> to your MPC + <code><strong>default.features</strong></code> file. + </p> + + <h2>Things ACE Developers Should Know</h2> + <p> + ACE developers should place all ACE symbols that are potentially + exposed to the user, including forward declarations in a + versioned namespace using the + <code>ACE_BEGIN_VERSIONED_NAMESSPACE_DECL</code> and + <code>ACE_END_VERSIONED_NAMESPACE_DECL</code> macros. Free + functions that are declared to have a C calling convention + (<em>i.e.</em>, <code>extern "C"</code>) should have their names + mangled using the <code>ACE_PREPROC_CONCATENATE</code> + preprocessor. For example: + </p> + <blockquote> + <code> +<pre> + void ACE_func (void) { ... } + ... + ACE_func(); // Call ACE_func() +</pre> + </code> + </blockquote> + <p> + becomes: + </p> + <blockquote> + <code> +<pre> + #if (defined (ACE_HAS_VERSIONED_NAMESPACE) \ + && ACE_HAS_VERSIONED_NAMESPACE == 1) \ + && !(defined (_MSC_VER) && _MSC_VER <= 1200) + // MSVC++ 6's preprocessor can't handle macro expansions + // required by the versioned namespace support. *sigh* + + # define ACE_FOO_FUNC_NAME ACE_PREPROC_CONCATENATE(ACE_VERSIONED_NAMESPACE_NAME, _ACE_foo_func) + + #else + + # define ACE_FOO_FUNC_NAME ACE_foo_func + + #endif /* ACE_HAS_VERSIONED_NAMESPACE == 1 */ + + ... + void ACE_FOO_FUNC_NAME (void) { ... } + + ACE_FOO_FUNC_NAME(); // Call mangled ACE_foo_func(). +</pre> + </code> + </blockquote> + <p> + The <code>ACE_PREPROC_CONCATENATE</code> is used rather than a + straight <code>##</code> preprocessor concatenation since in the + latter case preprocessor symbols like + <code>ACE_VERSIONED_NAMESPACE_NAME</code> will not be expanded + if they are concatenated. <code>ACE_PREPROCE_CONCATENATE</code> + forces the preprocessor to expand them during the argument + prescan by calling a macro that itself calls another that + performs the actual concatenation. + </p> + <h3>General Guidelines</h3> + <ul> + <li> + Versioned namespace macro/support must be added to all new files + added to ACE. + </li> + <li> + Do not place include directives between + <code>ACE_BEGIN_VERSIONED_NAMESPACE_DECL</code> and + <code>ACE_END_VERSIONED_NAMESPACE_DECL</code> macros. Doing + so will cause nested namespace to be created, which is not + the desired affect. + </li> + <li>Be aware of preprocessor conditional blocks when placing the + versioned namespace macros. For example, if you open + versioned namespace within a given preprocessor condition + block, you'll most likely want to close it in the same + block. + </li> + <li> + If necessary, reopen and close the versioned namespace + multiple times in the same file by using the macros multiple + times to address the concerns described in the above two + items. + </li> + <li> + The <code>$ACE_ROOT/bin/fuzz.pl</code> script has a sanity + checking test for versioned namespaces that may be of use when + debugging nested namespace issues, and for detecting + <code>BEGIN</code>/<code>END</code> mismatches. + </li> + </ul> + <p> + Versioned namespace support in ACE may be enabled by adding + <code>versioned_namespace=1</code> to your MPC + <code><strong>default.features</strong></code> file. Additional +information about versioned namespaces is available from the <A +HREF="http://www.riverace.com/newsletters/March2006.htm">Riverace +website</A>. + </p> + <hr> + <address><a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a></address> +<!-- Created: Fri Mar 17 08:35:50 PST 2006 --> +<!-- hhmts start --> +Last modified: Fri Mar 17 20:47:41 PST 2006 +<!-- hhmts end --> + </body> +</html> diff --git a/ACE/docs/ace_guidelines.vsmacros b/ACE/docs/ace_guidelines.vsmacros Binary files differnew file mode 100644 index 00000000000..4609babc863 --- /dev/null +++ b/ACE/docs/ace_guidelines.vsmacros diff --git a/ACE/docs/bczar/bczar.html b/ACE/docs/bczar/bczar.html new file mode 100644 index 00000000000..d7f652acfa9 --- /dev/null +++ b/ACE/docs/bczar/bczar.html @@ -0,0 +1,354 @@ +<!-- $Id$ --> + +<html> +<head> +<title>The realm of the build czar</title> +</head> + +<h2>Build Czar Duties</h2> +<p> + + Th main duties of the Build Czar are summarized as follows + + <li> Monitor the builds using the <a + href="http://www.dre.vanderbilt.edu/scoreboard"> Scoreboard </a> as + one of the primary source of information. + + <li> Notify developers who broke compilation to fix the errors as + soon as possible. A red color in the "Compile" column is not at all + acceptable. Build Czar should ensure that. If possible, let the + developer know what the source of problem could be. It is quite + possible that the developer who checked in the code or the user who + provided the patch may not have resources to investigate the + issues. Builds Czar's help is an absolute necessity then. + + <li> Keep an eye on the tests that are run in every build. Anything + abnormal needs to be notified to the right developer. The Build Czar + should try helping the developer by providing stack traces (in case + of crashes) or other details like printouts with debugging level + turned on. + + <li> Some tests fail in the daily builds for many reasons like known + bugs, transient timeouts etc. Make sure that no new test failures + show up. This <a href="mailto:jwillemsen@remedy.nl"> guy </a> knows + most of the information. Ask him to help you out with known + problems. + + <li> Keep an eye on the <a href="http://www.dre.vanderbilt.edu/Stats"> + footprint and performance </a> stats. Any obnormal changes needs to + be brought to the attention of the developer resposible for it + or to the <a href="mailto:devo-group@list.isis.vanderbilt.edu"> DEVO group </a>. + + <li> Keep the builds ticking. Any red on the "Last Finished" column + in the Scoreboard needs to be attended to. The link to the "Build + Name" would indicate the machine where the build is being run. + + <li> The builds don't cover all the possible configurations. If you + get a bug report about a compile error in a particular + configuration, try setting up a build to make sure that it doesnt + show up again if it has been fixed. + + <li> Keep an eye on the <a + href="http://deuce.doc.wustl.edu/bugzilla/index.cgi">bugzilla + </a> entries that are registered by users and developers. Decide on + the bugs that need to be fixed for the beta and pain developers for + an ETA. + +</p> + +<P> The document <a href="./privileges.html"> here </a> talks about +the powers of a build Czar. </P> + +<P> The Build Czar has the power to set up more builds on his own for +his convinience. This +<a href="https://svn.dre.vanderbilt.edu/viewvc/ACE_autobuild/trunk/README?revision=HEAD"> +page </a> has a +step by step instructions on how to do that. </P> + +<P> The build czar can get the build configuration by looking at the +config portion of the scoreboard </P> + +<p>Any pro-active involvement by the build czar is welcomed. Being +a pro-active build czar will mean that you watch the subversion archive +carefully and respond quickly to suspected changes. At the end it will +safe time because the repo stays stable.</p> + +<hr> +<h2>Recipe for Cutting a Beta/Minor Kit</h2> + +<P> The build czar is also incharge for the release of the +beta. Cutting a beta is as simple as cutting butter if things go +well. Here is the procedure followed while cutting a beta: + +<ol> +<li>The whole process takes somewhere between 8-9 hours, about 2 hours +for making the release itself and the remaining time for generating +the doxygen documentation.</li> +<li>I suggest you take advantage of GNU Screen so that even if your SSH session +is interrupted, the cutting process can continue. +<ul> +<li> type <code>screen</code> to start screen.</li> +<li> execute commands as normal. Note that Ctrl-A is special in screen, so you +need to type Ctrl-A-A to send a Ctrl-A to the shell</li> +<li> should your sesssion be interrupted, reconnect and type <code>screen -x</code></li> +<li> when finished, just type exit twice</li> +</ul> +<li>Prior to starting this, gather aggregate release notes from all +developers. This is usually in the form of an email plea asking for +a writeup of significant changes since the last beta. Add these notes +to the NEWS files before cutting the release so that all notes are +part of the release.</li> +<li>Checkout a new workspace on <tt>anduril.dre.vanderbilt.edu</tt></li> +<ul> +<li> +The best place to create the workspace is under /export/anduriltmp/bczar. Don't use +the home directory itself, it is an NFS share and not really fast. +</li> +<li>Checkout like this: +<ul><li>svn co https://svn.dre.vanderbilt.edu/DOC/Middleware/trunk DOC_ROOT</li> + <li>svn co https://svn.dre.vanderbilt.edu/DOC/MPC/trunk DOC_ROOT/ACE/MPC</li> +</ul> +</ul> +<li> Set $DOC_ROOT to point to the new +workspace you checked out.</li> +<li> Set an environment variable SIGNATURE indicating your full +name. This is used to fill the ChangeLog entry.</li> +<ul><li>For example,<tt>export SIGNATURE="Chris Cleeland"</tt></li></ul> +<li> Set an environment variable MAILID indicating your mail id. This +is used to fill the mail id portion of the ChangeLog entry.</li> +<ul><li>For example,<tt>export MAILID="cleeland@ociweb.com"</tt></li></ul> +<li> Change directories to to <tt>$DOC_ROOT</tt> </li> +<li> Tag the release by executing <code>ACE/bin/make_release -v beta -u</code> This will only +take a couple minutes to complete.</li> +<li> Create the kits by executing <code>ACE/bin/make_release -k ace+tao+ciao </code> + +<ul><li>These commands only tags and creates the kits for the + software itself, not documentation. </li> +<li>The kits end up in <tt>/export/anduriltmp/bczar/packages</tt></li> +</ul> +<p> +To summarise, the following is a transcript of the steps up to this point executing +successfully (assumes /project/acetmp/sm exists and is empty): <p> +<code> +sm@beatrice ~<br> +$ ssh bczar@anduril.dre.vanderbilt.edu<br> +No default printer<br> +-bash-3.00$ cd /export/anduriltmp/bczar<br> +-bash-3.00$ export DOC_ROOT=$PWD/DOC_ROOT<br> +-bash-3.00$ export SIGNATURE "Simon McQueen"<br> +-bash-3.00$ export MAILID sm@prismtech.com<br> +-bash-3.00$ svn co https://svn.dre.vanderbilt.edu/DOC/Middleware/trunk DOC_ROOT<br> +-bash-3.00$ svn co https://svn.dre.vanderbilt.edu/DOC/MPC/trunk DOC_ROOT/ACE/MPC<br> +-bash-3.00$ cd DOC_ROOT/<br> +-bash-3.00$ ACE/bin/make_release -v beta -u<br> +-bash-3.00$ ACE/bin/make_release -i -k ace+tao+ciao<br> +</code> +<p> +Feel free to cut and paste with suitable edits. +<li>In the <em>EXTREMELY</em> unlikely event that something goes wrong during the +<em>tagging</em> of the repo (ie, make_release -v beta -u), +the following files must be returned to the state they were in before the release +process started and then checked back into SVN:<br><code> +ACE/ChangeLog<br> +ACE/PROBLEM-REPORT-FORM<br> +ACE/VERSION<br> +ACE/TAO/ChangeLog<br> +ACE/TAO/PROBLEM-REPORT-FORM<br> +TAO/VERSION<br> +CIAO/ChangeLog<br> +CIAO/PROBLEM-REPORT-FORM<br> +CIAO/VERSION<br> +CIAO/ciao/Version.h<br> +TAO/tao/Version.h<br> +ace/Version.h<br></code><p> +The tag will also need to be removed: ACE+TAO+CIAO-X_Y_Z +(wher X and Y are the minor and beta release numbers of the release that is to be restarted).<p> +E.g.:<br> +<code> +svn rm https://svn.dre.vanderbilt.edu/DOC/Middleware/tags/ACE+TAO+CIAO-X_Y_Z<br /> +</code> + +Note that this <em>only</em> needs to be done if the <em>tagging</em> fails. If kit creation +fails, simply restart that process. +<li>The packages and up by default under /export/doc/latest, you can copy them to the webserver using the following commands. At the moment +you execute these commands all users can download these packages.</li> +<code> +cp /export/doc/latest/ACE* /export/www/download.dre/ACE+TAO-distribution<br> +cp /export/doc/previous-versions/ACE* /export/www/download.dre/previous_versions<br> +</code> +<li>Once the distribution is ready, get ready for creating doxygen +documentation. This is slightly complicated than it requires. We will +address the complexity soon.</li> +<li>Login to naboo.dre.vanderbilt.edu as bczar</li> +<ul><li>After login, ssh to bczar@download.dre.vanderbilt.edu as bczar and check whether ssh succeeds. If not fix the problem. The make script tries to copy the tar.gz files to the website using ssh.</li></ul> +<li> go to /web/users/isisbuilds/tmp/ACE_wrappers and remove the contents of this directory</li> +<li> Update the workspace with the right version tag </li> +<code> +svn co svn://svn.dre.vanderbilt.edu/DOC/Middleware/tags/ACE+TAO+CIAO-X_Y_Z/ACE ACE_wrappers<br> +svn co svn://svn.dre.vanderbilt.edu/DOC/Middleware/tags/ACE+TAO+CIAO-X_Y_Z/TAO ACE_wrappers/TAO<br> +svn co svn://svn.dre.vanderbilt.edu/DOC/Middleware/tags/ACE+TAO+CIAO-X_Y_Z/CIAO ACE_wrappers/TAO/CIAO<br> +</code> +<li> Set the needed environment variables using</li> +<code> +export ACE_ROOT=/web/users/isisbuilds/tmp/ACE_wrappers/ACE_wrappers +</code> +<li> Run doxygen --version within the shell. </li> +<li> Open up $ACE_ROOT/bin/generate_rel_manpages in your favorite editor.</li> +<li> Search for the string 'doxy_version'. </li> +<li> Check the version specified here. If it is the same as the one +you got using doxygen --version then you don't have to worry. </li> +<li> If it is different change the value of the doxy_version to the one installed on naboo.dre.vanderbilt.edu.</li> +<li> Now you are ready to create documentation </li> +<li> Do a <code>cd $ACE_ROOT</code> and then run <tt>make -f Release manpages</tt> to create the doxygen +documentation.</li> +<ul><li><b>If you can't leave the terminal window active for 6-9 hours, + consider prefixing this command with <tt>nohup</tt></b></li></ul> +<li>While doxygen churns, format a release announcement, including the +release notes gathered from developers. <a href="sample_relnotes.txt"> +You can use these as an example.</a> +<ul><li>Let <a href="mailto:schmidt@cs.wustl.edu">Doug Schmidt</a> review +these before you do anything with them.</li></ul> +<li>Check the file, generate_rel_manpages into the repository if you have made some changes to it.</li> +<li>Make sure the new version is available in Bugzilla.</li> +<ul> +<li>now we have a bczar Bugzilla user with full privileges. This bczar Bugzilla account would point to bczar user at ISIS. For example, as a new build czar, you could update the .forward file on one of the ISIS hosts, say, naboo.dre.vanderbilt.edu with your build czar email.</li> +<li>you should be able to send request through the bugzilla system to email you the password at any time to bczar@dre.vanderbilt.edu</li> +<li>here is the description of how to add a new version through Bugzilla.</li> +<li>go to any Bugzilla "Query" page, you should see a yellow box at the bottom. click "Log in" link to log in as bzar@dre.vanderbilt.edu.</li> +<li>look at the yellow box at bottom again. You will see several links following "Edit". Click on the "components" link.</li> +<li>you are then at "Select product" page. You should see a list components, i.e., ACE CIAO TAO. Click on the product you want to edit.</li> +<li>you are then at "Edit product" page. Scroll down a bit, you should see a list of all versions coming with this product. At the very beginning of the list, you should see "Edit versions" link. Click this link.</li> +<li>you should see a "Add a new version" text box and a "Add" link just above the yellow box at the bottom. Click on this link</li> +<li>you are then at "Add version of [Name of the product]" page.</li> +<li>you are able to add the new verion now.</li> +</ul> +<li>Now update the documentation at + www.dre.vanderbilt.edu/Doxygen.</li> +<ul> +<li>Login to naboo.dre.vanderbilt.edu</li> +<li>su to bczar user</li> +<li>cd to directory /web/www/Doxygen</li> +<li>Create a temporary directory. eg. tmp</li> +<li>Change Directory to tmp</li> +<li>scp file from the download server - + scp bczar@download.dre.vanderbilt.edu:/export/www/download.dre/ACE+TAO-distribution/ACE-html.tar.bz2 .</li> +<li>Unzip and untar the files - bunzip2 <filename>;tar -xvf + <filename></li> +<li>Do cd ..</li> +<li>Create directory 'Current Version No'</li> +<li>Change directory to 'Current Version No'</li> +<li>Move contents of tmp/html to this directory - mv ../tmp/html</li> +<li>Now Change Directory - cd ..</li> +<li>Remove the already existing soflink to the "Beta" with rm Beta</li> +<li>Create softlink "Beta" linking it to new Documentation using: ln X.Y.Z/html Beta --symbolic</li> +</ul> +<li>Mail the approved release announcement out to, at minimum the following: +<tt>ciao-users@cs.wustl.edu</tt>, +<tt>tao-users@cs.wustl.edu</tt>, +<tt>tao-announce@cs.wustl.edu</tt>, +<tt>ace-users@cs.wustl.edu</tt>, +<tt>ace-announce@cs.wustl.edu</tt>. Do this as yourself (not as bugzilla). +<b>N.B.</b> You will not be able to post to the users' lists unless you are +subscribed to them. Odds are you will not be able to post to the announce lists +at all. Ask someone else (like Doug) to do this step. +</ol> +</p> + + +<hr> + +<h2> Tips to being a Build Czar</h2> +<p> +1. Trust no one.<br> +2. Be careful with <a href=http://www.cs.wustl.edu/~schmidt>this +guy</a>, he is notorious in breaking builds (and fixing them as +well...Rumour has it that it's actually a super-scalar, +super-pipelined processor capable of out-of-order execution, in human +incarnation).<br> +3. Don't forgive people who break ACE :-)<br> +4. If a build hasn't run in a long time (symptoms are a "red" in the +Last Run column of the build scoreboard), delete the .disable file in +/path/to/build/directory/BUILD_NAME/ by hand.<br> +5. Think of the group who wrote the scoreboard update script, everytime +you catch an otherwise not so obvious error with the help of the +scoreboard. Tell <a href="mailto:devo-group@list.isis.vanderbilt.edu"> DEVO group +</a> about it.<br> +6. Add $CVSROOT/CVSROOT/etc/FROZEN to freeze the repo <br> +7. Add names of people who need to be given permission and make sure +that you add your name so that you can see what is being checked in. <br> +8. Leave a line at the end of the FROZEN file <br> +9. Compile once on Win32, Linux and Solaris before cutting a beta.<br> +10. Trust the release script when making a release. Don't make tar +balls by hand. Make sure that the public ftp directories +(/project/beguine/ftp/pub/ACE+TAO-distribution and +/project/beguine/ftp/pub/ACE+TAO-distribution/diffs) have the right +permissions, so that the release script can copy the tar balls.<br> +11. When making a release, make sure that all the auto_compiles on +that machine (deuce.doc.wustl.edu) are stopped. Also make sure that +there is enough space in /tmp on that machine.<br> +12. When all hell breaks loose, don't wait for the nightly builds to +monitor improvement. Instead manually start the builds.<br> +13. Maintain private up-to-date workspaces for problem platforms (read +as Solaris).<br> +14. Don't hesitate to ask for help.<br> +15. When you get an account to acess the cvs repo, make sure you are added to the correct groups, for example, gid=100(users),5000(doc),5002(acetaodev),5003(cvs). Otherwise you will have problem to checkout various modules.<br> +16. Install your public key to the different machines you have frequent access to avoid typing password.<br> +17. Update this page if you have any more tips for future build czars :-). This +page is <code>bugzilla@deuce.doc.wustl.edu:~/.www-docs/index.html</code><br> +</p> +</body> + +<body> +<Center> <h1>The Realm of the Build Czar</h1></center> +<hr> +<h2>Build Czar Arthur</h2> +<p>Many years have passes since the days of the legendary Build Czar +Arthur. His duties were given to him by the mystical Lady of the Lake, +who outlined the first responsibilities of the Build Czar.</p> +<tt> +<br> +Then bespake the Lady of the Lake,<br> +And these were the words said shee:<br> +"I knoweth of thy deeds, thou noble Arthur,<br> +but thy task hath not finished for thee"<br> +<br> +"Thou shalt feitch thy trusty steed,<br> +And cleanse thy builds againe;<br> +Then shallt thy ryde hath finnished,<br> +When new kits released thee cann."<br> +<br> +Then bespake him noble Arthur<br> +And these were the words said he:<br> +"With what weapons shallt I use,<br> +To asure these from the devil free?"<br> +<br> +Then appeered before noble Arthur,<br> +Uppon the ground a sacred scroll<br> +Conjurred by the Lady of the Lake<br> +Borne of the earth in a roll.<br> +<br> +She saies, "Clasp this to thine selfe<br> +For thee shallt find need for it.<br> +It shall keep others in the cold,<br> +Only to be ressurected when thee sees fit."<br> +<br> +"Others shall join thy person,<br> +To ryde with thee in thy quest;<br> +Thee shallt be thankful of theire help,<br> +And to alsoe hold them steadfast."<br> +<br> +"But if theire talke too lodly rise,<br> +And causeth much damage to thine cuntry,<br> +He must come forth, and make proclamation,<br> +For the next one he shall be."<br> +<br> +So hath Arthur to the Lady spoke:<br> +"For I sweare, and save my othe,<br> +While enimes and evils I seeke,<br> +I shall fight against them bothe.<br> +<br></tt> +<hr> + + +</html> + diff --git a/ACE/docs/bczar/privileges.html b/ACE/docs/bczar/privileges.html new file mode 100644 index 00000000000..299b88c299f --- /dev/null +++ b/ACE/docs/bczar/privileges.html @@ -0,0 +1,63 @@ +<!-- $Id$ --> + +<html> +<head> +<title> Build Czar powers </title> +</head> +<center><h1>Powers with the Build Czar</h1></center> + <P> + This document grants extensive privileges and powers to the Czar, + but those privileges impose several responsabilities that must be fulfilled, + failure to do so may result in some form of revolution + (picture a firing squad). + </P> + + <P> + Previous generations of the honorable royal family have automated + the build process as much as possible, but all machines require attention: + the build Czar must keep a constant vigil, lest some runaway process + stops working and a critical bug scapes into the wild. + </P> + + <P>Typically a runaway build is detected because on its next + execution an email indicating that the build is + <CODE>DISABLED</CODE> + is received. + The same email is also sent when a build is abruptly terminated (for + example because the machine running the build crashed). + Most of the time, + a test is not making progress and must be terminated, + the build then runs to completion. + If the machine crashed then it is necessary to go into the build + directory and remove the + <CODE>auto_compile/.disable</CODE> + file, so the next execution can complete successfully. + Occasionally the build fails because there is a CVS conflict, + there is not enough disk space or some similar problem, + in these cases the build Czar is encouraged to request adviced + from previous generations in the royal family they will + be happy to come back from retirement to provide advice and help + if needed. + </P> + <P>The build Czar should also investigate the errors and warnings + reported by a build, + contact the person or persons responsible for the failed build and + prompt them to fix the situation. If that process above fails the + build Czar should request help from a volunteer or proceed to fix + the problem himself/herself. If there is no available + backup/volunteer and the build Czar is busy, he/she will be + forced to excomunicate the original developer and report him or + her to the highest court of the land for whatever punishment is + deemed appropriate (lashing or bone breaking where not prohibited + by law). + </P> + <P>It is extremely important to fix broken builds within the day, + otherwise the errors tend to accumulate and once the process + breaks down it is extremely hard to recover, + in other words, + the term as a build Czar can extend beyond your expectations if + the builds are not clean again. + </P> +<hr> +</html> + diff --git a/ACE/docs/exceptions.html b/ACE/docs/exceptions.html new file mode 100644 index 00000000000..e014a807601 --- /dev/null +++ b/ACE/docs/exceptions.html @@ -0,0 +1,655 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<!-- $Id$ --> +<html> <head> +<title>Using ACE Exception Handling Macros to Enhance CORBA Portability</title> +</head> + +<body text="#000000" link="#0000ff" vlink="#cc0000" bgcolor="#ffffff"> +<Hr><P> +<h3>Using ACE Exception Handling Macros to Enhance CORBA Portability</h3> + +<P>CORBA <CODE>Environment</CODE> arguments provide a way to handle +exceptions when native c++ exception handling is unavailable or +undesirable. However, writing portable code using both native C++ +exception handling and <CODE>CORBA::Environment</CODE> objects is very +hard. If you plan to write portable code that must run on platforms +that do not have native C++ exceptions, therefore, we recommend you +use the ACE exception macros. This document explains how these macros +can help alleviate much of the accidental complexity. However, keep +in mind macros cannot solve all problems perfectly. </P> + +<P>Before reading the rest of this document, we recommend you check +out pages 307 through to 322 in the book, <A +HREF="http://cseng.aw.com/bookdetail.qry?ISBN=0-201-37927-9&ptype=0">Advanced +Corba Programming with C++</A> by <A +HREF="http://www.triodia.com/staff/michi-henning.html">Michi +Henning</A> & <A HREF="http://www.iona.com/hyplan/vinoski/">Steve +Vinoski</A>. Likewise, we recommend that you read the Error Handling chapter from the +<A HREF="http://www.theaceorb.com/product/">TAO Developer's Guide</A>. + +<P><HR><P> +<h3>Table of Contents</h3> +<ul> + <li><a href="#nutshell">ACE Try Macros in a Nutshell</a> + <li><a href="#examples">Examples</a> + <li><a href="#general">General Guidelines for Exception Handling</a> + <li><a href="#transition">Transition from ACE_TRY_ENV usage to the + ACE_ENV_ARG macros</a> + <li><a href="#caveats">Some Caveats</a> +</ul> + +<HR><P> +<h3><a name="nutshell">ACE Exception Macros in a Nutshell</h3> + +<P>This section explains some simple rules of writing programs for +platforms with and without native exception support using ACE's +exception macros. +</P> +<P>ACE exception macros are modelled like C++ language exceptions and +can be used like them, but with a small difference. These macros +rely on the CORBA::Environment variable to handle exceptions +on platforms that do not support exception +handling. (Please note that native exceptions can be turned on +or off at COMPILE time as an option to your make) +The exception macros have been modelled with some extra rules to +ensure this works even on +platforms without native exception support. See some <a +href="#examples">quick examples</a> on how to use ACE exception +macros. +</P> +<ol> + <li><P><em>Declaration of CORBA::Environment Parameter at Methods</em><br> + On platforms lacking native exceptions, all CORBA methods take an + extra parameter added at the end of their argument list. This + last parameter holds the CORBA::Environment variable. + However, on systems with native exceptions, no such extra method + parameter is added.<br> + In order for both configurations to work with the same source code, + following macros are defined. In native exception configurations, + they all resolve to <em>empty</em>.</p> + <ul> + <li><p><em>ACE_ENV_ARG_DECL</em></p> + in the pseudo exception configuration resolves to + <pre> + , CORBA::Environment ACE_TRY_ENV + </pre> + It is used for declaring the extra Environment parameter + at CORBA methods that take one or more regular parameters. + The fact that the comma is part of the macro substitution + caters for the hiding of this added argument when native + exceptions are used. However, by the same virtue its + usage is a bit peculiar -<br> + Example: a CORBA IDL defined method + <pre> + void mymethod (in boolean b); + </pre> + may be declared as follows in C++: + <pre> + void mymethod (CORBA::Boolean b ACE_ENV_ARG_DECL); + </pre> + Notice the missing comma before the ACE_ENV_ARG_DECL. + This notation is necessary because when using native exceptions, + also the presence of the comma before the (non-existent) + CORBA::Environment parameter must be hidden.</p> + </li> + <li><p><em>ACE_ENV_SINGLE_ARG_DECL</em></p> + is similar to <code>ACE_ENV_ARG_DECL</code>, but is used when + the method takes no other parameters. It is necessary as a + separate macro because it does not contain the leading comma + that <code>ACE_ENV_ARG_DECL</code> does. + Example: a CORBA IDL defined method + <pre> + void mymethod (); + </pre> + may look like this in C++: + <pre> + void mymethod (ACE_ENV_SINGLE_ARG_DECL); + </pre> + <li><p><em>ACE_ENV_ARG_DECL_WITH_DEFAULTS</em>, + <li><em>ACE_ENV_SINGLE_ARG_DECL_WITH_DEFAULTS</em></p> + are similar to the above two macros but add a default value + to the parameter declaration. In case of TAO, the default value + is <code>TAO_default_environment()</code>.<p> + Notice that these macros are only used at the declaration + of methods (usually in header files), not at their definition + (usually in implementation files.) At the definition, + instead use the corresponding macro without "_WITH_DEFAULTS". + Example: the CORBA IDL defined method + <pre> + void mymethod (); + </pre> + in the C++ header file looks like this: + <pre> + void mymethod (ACE_ENV_SINGLE_ARG_DECL_WITH_DEFAULTS); + </pre> + and in the C++ implementation file may look something like: + <pre> + void mymethod (ACE_ENV_SINGLE_ARG_DECL) + { + // ... + } + </pre> + </ul> + + <br> + </li> + + <li><P><em>Passing the CORBA::Environment Parameter into Method Calls</em><br> + Now that we've seen how to declare methods with Environment + parameters, let's see how to invoke such methods.</p> + <ul> + <li><p><em>ACE_ENV_ARG_PARAMETER</em></p> + in the pseudo exception configuration resolves to + <pre> + , ACE_TRY_ENV + </pre> + and is written as the last parameter of a method call that takes + one or more regular parameters. Again we need to omit the + comma that would normally precede this last parameter, as the + comma is already part of the macro definition. For example, + the CORBA IDL method + <pre> + void mymethod (in boolean b); + </pre> + would be invoked as follows: + <pre> + some_var.mymethod (bparam ACE_ENV_ARG_PARAMETER); + </pre> + </ul> + + <ul> + <li><p><em>ACE_ENV_SINGLE_ARG_PARAMETER</em></p> + is similar to <code>ACE_ENV_ARG_PARAMETER</code> but is used + for calling methods that don't take any regular parameters. + Our example of a CORBA IDL method + <pre> + void mymethod (); + </pre> + we would invoke as follows: + <pre> + some_var.mymethod (ACE_ENV_SINGLE_ARG_PARAMETER); + </pre> + </ul> + <br> + </li> + + <li><P><em>Definition of the CORBA::Environment variable </em><br> + We have seen how to declare methods with the CORBA::Environment + parameter, and how to invoke such methods. However, where does + the variable to pass into methods as the CORBA::Environment + parameter come from in the first place?</p> + <P>An environment variable can be defined in the needed scope + (for example, in the main program, or in a more local scope) + by the statement</p> + <pre> + ACE_DECLARE_NEW_CORBA_ENV; + </pre> + <P>You can then invoke the methods on the servant from the client + side as + <pre> + object_reference->func_name (x, y ACE_ENV_ARG_PARAMETER); + </pre> + + Even if you are interested in making calls within the client + side, you can define your method like this + <pre> + int AN_OBJ::foobar (int a, int b ACE_ENV_ARG_DECL); + </pre> + + <li><P><em>Throwing exceptions:</em><br> + Use <code>ACE_THROW</code> and <code>ACE_THROW_RETURN</code> to + throw exceptions. They should never be used within a try + block; please use <code>ACE_TRY_THROW</code> instead. + </P> + </LI> + + <li><P><em>Propagating exceptions:</em><br> + To simulate native exceptions on platforms without native + exception handling, <em>every</em> function call that may + throw exceptions must be followed by <code>ACE_CHECK</code> or + <code>ACE_CHECK_RETURN</code>.</p> + + <p><a name="exc-func">Exception-throwing functions include the + following categories:</p> + + <ol> + <li><p>Any function that takes a + <code>CORBA_Environment</code> argument.</p> + </li> + + <li><p><code>ACE_NEW_THROW_EX</code>. Notice that you + <em>should not</em> use <code>ACE_NEW_THROW</code>, + <code>ACE_NEW_THROW_RETURN</code>, + <code>ACE_NEW_TRY_THROW</code> anymore because they don't + work right with ACE try macros. Instead, use + <code>ACE_NEW_THROW</code> with appropriate ACE_CHECK* + macros.</p> + </li> + + <li><P><code>ACE_GUARD_THROW_EX</code>, + <code>ACE_READ_GURAD_THROW_EX</code>, and + <code>ACE_WRITE_THROW_EX</code>. + + <li><p><code>ACE_TRY</code> blocks. Follow every + <code>ACE_ENDTRY</code> with appropriate ACE_CHECK* + macros.</p> + <li> + </ol> + + <P>You should pass <code>ACE_TRY_ENV</code> to these + functions. + </p> + + <P>Be very careful not to combine exception throwing functions + in one statement like this: + </P> + <pre> + x = obj1->callme (ACE_ENV_SINGLE_ARG_PARAMETER) + + obj2->dare_me (ACE_ENV_SINGLE_ARG_PARAMETER); + ACE_CHECK; + </pre> + <P>This example may work differently when native exception + handling is enabled/disabled. + </p> + </LI> + + <li><P><em>Catching exceptions:</em><br> + Use <code>ACE_TRY</code> to catch exceptions if there's an + <code>ACE_TRY_ENV</code> available. Otherwise, you should use + <code>ACE_DECLARE_NEW_CORBA_ENV</code> to create one at + <em>proper</em> scope. The use of + <code>ACE_TRY_NEW_ENV</code> is considered depricated because it + can't deal with the case when you have multiple <code>TRY</code> + blocks in the scope of <code>ACE_TRY_NEW_ENV</code>. If there are + more than one try blocks in a function, use <code>ACE_TRY_EX</code> + for all subsequence try blocks to avoid name clashing of labels. + </p> + <ul> + <li><P>Within a <code>ACE_TRY</code> block, use the variable + <code>ACE_TRY_ENV</code> to pass down the + <code>CORBA_Environment</code> (see <a + href="#try_env">this</a> example.) + </p> + </LI> + + <li><P>Follow <em>every</em> exception throwing function with + <code>ACE_TRY_CHECK</code>. If you are using a TRY block + within another try block add a <code>ACE_TRY_CHECK</code> + at the end of this TRY block ie. after + <code>ACE_ENDTRY</code>. + </p> + </LI> + + <li><P>Use <code>ACE_CATCH</code> to catch exceptions of certain + type. + </p> + </LI> + + <li><P><code>ACE_CATCHANY</code> catches <em>any</em> exceptions + of type <code>CORBA_Exception</code>. The caught + exception is stored in a variable call + <code>ACE_ANY_EXCEPTION</code>. + </p> + </LI> + + <li><p><code>ACE_CATCHALL</code> emulate the <code>catch + (...)</code> c++ statement. It is identical to + <code>ACE_CATCHANY</code> on platforms without native + exception support. You can not access the caught + exception within the <code>ACE_CATCHALL</code> block.</p> + + <li><P>Use <code>ACE_RE_THROW</code> to rethrow the same exception + within a <code>ACE_CATCH</code> or + <code>ACE_CATCHANY</code> block. + </p> + </LI> + + <li><P>A <code>ACE_TRY</code> block must be terminated with + a <code>ACE_ENDTRY</code> statement. + </p> + </LI> + + <li><P>Throw an exception within a <code>ACE_TRY</code> + block or <code>ACE_CATCH</code> block using + <a href="#ace_try"><code>ACE_TRY_THROW</code></a>. + </p> + </LI> + </ul> + </li> + + <li><p><em>Printing out exceptions.</em> Use <code>ACE_PRINT_EXCEPTION + (EX,INFO)</code> to print out an exception. The macro takes two + arguments, a reference to an exception (EX) and a <code>char + *</code> string (INFO) which provides more information on the + exception. Since there's no portable way to print out + exceptions, you can redefine ACE_PRINT_EXCEPTION to fit your + need (or define it to null.) <em>You should always print out + the exception itself, not the CORBA_Environment that carries the + exception.</em></p> + </li> + + <li><P><em>Name of CORBA::Environment variable</em><br> + A function that may throw a CORBA::Exception needs a + CORBA::Environment variable to pass up exceptions (to throw in + the C++ sense) and to gather (catch () in the C++ sense) + exceptions from functions it called. By default, ACE exception + macros assume that the variable is named <code>ACE_TRY_ENV</code>. + <code>ACE_TRY_ENV</code> itself is also a macro which can be + redefined. + </pre> + + <P> + You can redefine the name of the variable to + something else to avoid name clashing. Alternatively, there's + another macro (<code>ACE_ADOPT_CORBA_ENV</code>) that allow you + to use another variable name as the default CORBA::Environment + <em>within</em> a function. + </P> + </LI> + +</ol> + +<HR><P> +<h3>Examples</h3><a name="examples"> + +Refer to <a href="../ace/CORBA_macros.h"><code> +$ACE_ROOT/ace/CORBA_macros.h</code></a> for complete definitions of +macros discussed here. + +<ul>Examples on using ACE try macros: + <li><p> + <pre> + <a name="try_env"> + ACE_TRY // Use ACE_DECLARE_NEW_CORBA_ENV to create ACE_TRY_ENV + // if you got undefined symbol warning here. + { + some_operation (arg1, arg2 ACE_ENV_ARG_PARAMETER); + ACE_TRY_CHECK; + + . + . + if (whatever) + ACE_TRY_THROW (CORBA::BAD_PARAM ()); + + some_other_operation (arg1, arg2, arg3 ACE_ENV_ARG_PARAMETER); + ACE_TRY_CHECK; + } + <a name="ace_try"> + ACE_CATCH (CORBA_some_exception, ex) + { + // error handling. + if (still_has_error) + ACE_TRY_THROW (CORBA::NOWAY ()); + } + ACE_CATCHANY + { + // error handling. + // then rethow the exception. + ACE_RE_THROW; + } + ACE_ENDTRY; + ACE_CHECK; + </pre> + </p> + </li> + + <li><p><code>ACE_TRY</code> and also declares a label for internal + use. To avoid defining the same label multiple times within a + function, use <code>ACE_TRY_EX</code> with different labels for + different try blocks instead. For example,<br> + + <pre> + ACE_TRY_EX (block_1) + { + some_operation (arg1, arg2 ACE_ENV_ARG_PARAMETER); + ACE_TRY_CHECK_EX (block_1); + + some_other_operation (arg1, arg2, arg3 ACE_ENV_ARG_PARAMETER); + ACE_TRY_CHECK_EX (block_1); + } + ACE_CATCH (CORBA_some_exception, ex) + { + // error handling. + } + ACE_CATCHANY + { + // error handling. + } + ACE_ENDTRY; + ACE_CHECK_RETURN (-1); + + // Some other operation here + // . + // . + // . + // . + + ACE_TRY_EX (block_2) + { + foo (arg ACE_ENV_ARG_PARAMETER); + ACE_TRY_CHECK_EX (block_2); + + bar (arg1, arg2 ACE_ENV_ARG_PARAMETER); + ACE_TRY_CHECK_EX (block_2); + } + ACE_CATCH (CORBA_some_exception, ex) + { + // error handling. + } + ACE_CATCHANY + { + // error handling. + } + ACE_ENDTRY; + ACE_CHECK_RETURN (-1); + </pre> + </p> + + <li><p>You may want to make a different series of calls after you + encounter/catch an exception. Here is what we recommend. + + <pre> + ACE_TRY + { + // Calls that can raise an exception + some_call1 (arg1, arg2 ACE_ENV_ARG_PARAMETER); + ACE_TRY_CHECK; + . + . + . + ACE_TRY_CHECK; + } + ACE_CATCH (CORBA_some_exception, ex) + { + // Caught an exception, so we need to make some other calls + // to continue.. + + ACE_TRY_EX (block1) // basically a label + { + some_other_call1 (arg1,.. ACE_ENV_ARG_PARAMETER); + ACE_TRY_CHECK_EX (block1); + } + ACE_CATCH (CORBA_some_other_exception, ex1) + { + // Handle the exception here.. + } + ACE_ENDTRY; + ACE_CHECK_RETURN (-1); // Needed to catch uncaught exceptions + } + ACE_ENDTRY; + ACE_CHECK_RETURN (-1); + </pre> + </p> + + <li><p>Be <em>VERY</em> wary of <code>ACE_CATCHALL</code>. It catches + exceptions of any type. If your program depends on it, then, + more often than not, there're something wrong with it. + </P> + </li> + + <li><p>Instead of depending on <code>ACE_CATCHALL</code>, use + <code>auto_ptr</code> style mechanism to prevent memory leaks + from exceptions. + </p> + </li> +</ul> + +<HR><P> +<h3><a name="general">General Guidelines for Exception Handling</h3> +<ul> + <li><p>Don't catch an exception just to rethrow it. Exceptions cost + you performance. + </p> + </li> + + <li><p>When exceptions occur, make sure an object's is still in + a valid state or change to a state that can be safely + destructed. + </p> + </li> + + <li><p>Watch out for side effect in the expression which may cause + exceptions. In the following example, what should + <code>i</code> be if an exception does occur?<br> +<pre> + ACE_TRY + { + obj[i++] = foo_bar_method (a, b ACE_ENV_ARG_PARAMETER); + } +</pre></p> + </li> + + <li><p>Make sure an exception doesn't cause resource leak (memory, + socket, ...) (hint: Use auto_ptr to avoid memory leak, + and ACE_Guard for locks.) + </p> + </li> + + <li><p>Don't catch any exception that you don't know how to handle.</p> + </li> + + <li><p>Never throw an exception from destructor (unless you know what + it implies.)</p> + </li> + + <li><p>Use exceptions to provide more information about the error.</p> + </li> + + <li><p>Rethrow a different exception only to provide <em>more</em> + information. Do not catch an exception just to rethrow, say, + <code>unknow_exception</code>.</p> + </li> +</ul> + +<HR><P> +<H3><a name="transition">Transition from ACE_TRY_ENV usage + to the ACE_ENV_ARG macros</h3> + +<P>Before TAO version 1.2.2, IDL defined methods were declared using +direct mentions of <code>CORBA::Environment ACE_TRY_ENV</code>. +The problem with this approach was that the ACE_TRY_ENV had +to be passed into ORB core method calls even when native exceptions +are supported. The TAO internal usage of the ACE_ENV_ARG family of +macros fixes this.</p> + +<p>For people who want to continue to use their old code that uses the +old <code>ACE_TRY_ENV</code> macros, they can define +<CODE>ACE_ENV_BKWD_COMPAT</CODE> in their <code>config.h</code> file. + +<P>CORBA applications that do not need support for emulated exceptions +can use direct C++ exception handling and omit the CORBA::Environment +parameter entirely.<BR> +On the other hand, applications that shall support environments without +C++ exceptions (such as all applications that are part of to TAO itself) +should use the ACE_ENV_ARG macros.<BR> +The script <code>$ACE_ROOT/bin/subst_env.pl</code> can assist in the +conversion from the direct ACE_TRY_ENV usage to the ACE_ENV_ARG macros. +Here is a list of the substitutions that the script does. For context, +two sample IDL methods are used: +<PRE> + void noargs (); + void withargs (in boolean b); +</pre> +At each example, first the <em>old usage</em> is given, then its +<code>subsitution</code>. +</p> + +<H4>Method declaration</h4> + +<UL> + <li><P><em>void noargs (CORBA::Environment &);</em></P> + <P><code>void noargs (ACE_ENV_SINGLE_ARG_DECL_NOT_USED);</code></P> + </li> + <li><P><em>void noargs (CORBA::Environment &ACE_TRY_ENV);</em></P> + <P><code>void noargs (ACE_ENV_SINGLE_ARG_DECL);</code></P> + </li> + <li><P><em>void noargs (CORBA::Environment &ACE_TRY_ENV = TAO_default_environment ());</em></P> + <P><code>void noargs (ACE_ENV_SINGLE_ARG_DECL_WITH_DEFAULTS);</code></P> + </li> + <li><P><em>void withargs (CORBA::Boolean b, CORBA::Environment &);</em></P> + <P><code>void withargs (CORBA::Boolean b ACE_ENV_ARG_DECL_NOT_USED);</code></P> + </li> + <li><P><em>void withargs (CORBA::Boolean b, CORBA::Environment &ACE_TRY_ENV);</em></P> + <P><code>void withargs (CORBA::Boolean b ACE_ENV_ARG_DECL);</code></P> + </li> + <li><P><em>void withargs (CORBA::Boolean b, CORBA::Environment & + ACE_TRY_ENV = TAO_default_environment ());</em></P> + <P><code>void withargs (CORBA::Boolean b ACE_ENV_ARG_DECL_WITH_DEFAULTS);</code></P> + </li> +</ul> + +<H4>Method invocation</h4> + +<UL> + <li><P><em>noargs (ACE_TRY_ENV);</em></P> + <P><code>noargs (ACE_ENV_SINGLE_ARG_PARAMETER);</code></P> + </li> + <li><P><em>withargs (bparam, ACE_TRY_ENV);</em></P> + <P><code>withargs (bparam ACE_ENV_ARG_PARAMETER);</code></P> + </li> +</ul> + +<HR><P> +<H3><a name="caveats">Caveats</H3> + +<P>As we already mentioned no set of macros can cover all cases +and preserve the semantics between native C++ exceptions and the +<CODE>CORBA::Environment</CODE> based mapping. +Some of the problems that our macros are described below: +<P> + +<UL> + <LI><P>Using the macros in loops can produce problems with + <CODE>break</CODE> and <CODE>continue</CODE> statements, for + example: + </P> + <PRE> + for (int i = 0; i < 10; ++i) + { + ACE_TRY + { + if (x[i] == 0) + continue; // will *not* work + if (x[i] == -1) + break; // will *not* work either + } + ACE_CATCH (CORBA::Exception, ex) + { + } + ACE_ENDTRY; + ACE_CHECK; + } + </PRE> + </LI> +</UL> + +<P><HR><P> + +Back to the <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE-documentation.html">ACE +documentation</A> page.<BR> +Back to <A HREF="index.html">ACE Documentation Home</A>. + + +<!--#include virtual="/~schmidt/cgi-sig.html" --> +</body></HTML> diff --git a/ACE/docs/index.html b/ACE/docs/index.html new file mode 100644 index 00000000000..4f14542cc80 --- /dev/null +++ b/ACE/docs/index.html @@ -0,0 +1,101 @@ +<html> + +<!-- $Id$ --> +<head> +<title>ACE Documentation Home</title> +</head> + +<body text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff"> + +<hr> + +<h1>ACE Documentation Home</h1> + +Everything you've always wanted to know about ACE, but were afraid to +ask. <P> + +<hr> + +<h3>ACE Documentation</h3> + +<ul> + <li><a href="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">Overview of ACE</a> - + a high-level view. + <li><A + HREF="http://www.cs.wustl.edu/~schmidt/ACE-documentation.html">ACE online documentation</a>. + <li><A + HREF="http://www.flyingdonkey.com/ace/">Translations for much of the ACE documentation</a>. + <LI><A HREF="http://www.cs.wustl.edu/~schmidt/ACE/">Books on ACE</A>. +</ul> + +<hr> + +<h3>ACE Structure</h3> + +<ul> + <li><a href="ACE-categories.html">Class Categories</a> - Listing of some of the classes + in ACE. + <li>ACE Inheritance Tree <a href="ACE-inheritance.pdf">[pdf]</a> <a href= + "ACE-inheritance.ps.gz">[ps.gz]</a> + <li><a href="ACE-subsets.html">ACE Subsets</a> - Outline of some of our ideas + for subsetting the ACE library. +</ul> + +<hr> + +<h3>Technical Papers and Tutorials</h3> + +<ul> + <li><a href="http://www.cs.wustl.edu/~schmidt/ACE-papers.html">Technical Papers</a> - + Postscript versions of many ACE papers. + <li>Tutorial on C++ Network Programming with Patterns, Frameworks, and ACE<a href="http://www.cs.wustl.edu/~schmidt/PDF/ACE-tutorial.pdf">[pdf]</a> + <a href="http://www.cs.wustl.edu/~schmidt/ACE-tutorial.ps.gz">[ps.gz]</a> + <!-- Bob's original can always be found at: http://dox.netwrench.com/acedox/fmm/ --> + <li><a href="ACE-FMM.html">ACE FMM</a> - ACE "Frequently Made Mistakes" +</ul> + +<hr> + +<h3>Bug Reports</h3> + +<ul> + <li><a href="ACE-bug-process.html">Bug Fixing Policies</a> - Our policies for + handling bug reports about ACE, TAO, and CIAO. + <li><a href="usage-bugzilla.html">Bug Tracking System</a> - Short description of our + Bugzilla bug tracking system. +</ul> + + +<hr> + +<h3>ACE Development</h3> + +<ul> + <li><a href="ACE-development-process.html">Development and Release Process</a> - The process we use + to develop and release the ACE, TAO, and CIAO software. + <li><a href="CVS.html">Overview of CVS</a> - How to use the source + control system we use for ACE, TAO, CIAO, etc. + <li><a href="ACE-guidelines.html">Style Guide</a> - How to write + compliant ACE, TOA, and CIAO code. + <li><a href="ACE-porting.html">Porting</a> - What to do to port to a new platform. + <li><a href="exceptions.html">Exception Macros</a> - How to use the ACE TRY + macros properly (note that these macros are now deprecated). + <LI><a href="http://www.acejoy.com">ACE developers forum in China</A>. +</ul> + +<hr> + +<h3>Other Stuff</h3> + +<ul> + <li><a href="ACE-lessons.html">Lessons</a> - Lessons we have learned while + building ACE. + <li><a href="ACE-SSL.html">ACE+SSL</a> - What is ACE+SSL and how to get it. + <li><a href="Symbol_Versioning.html">Symbol versioning</a> - How to do symbol versioning + with ACE+TAO. + <li><a href="CE-status.txt">CE-status.txt</a> - The status of ACE on Windows CE. + <li><a href="../ACEXML/docs/readme.txt">ACEXML</a> - A SAX2-based XML parser ACE uses and provides. +</ul> + +</body> +</html> diff --git a/ACE/docs/msvc_notes.txt b/ACE/docs/msvc_notes.txt new file mode 100644 index 00000000000..a0965a3e8bc --- /dev/null +++ b/ACE/docs/msvc_notes.txt @@ -0,0 +1,132 @@ +/** +@page msvc Miscellaneous Notes for ACE/TAO and Microsoft Visual C++ + +Here are just some random information about ACE/TAO with Microsoft Visual +C++. This is more a collection of ideas right now, so it may not be as +polished as other ACE documentation. + +@subsection msvc_configurations Configurations + +MSVC workspace and solution files come with several configurations. The +main two are Debug and Release. Debug produces libraries and +executables with debugging symbols and doesn't enable inlining. The +Release configuration enables optimizations and leaves out debugging +symbols. All projects contain both configurations. If you want to +build static or mfc versions of th elibrary you need to use different +project and solution files. Project files with _Static extension +denote workspaces for building static libraries. + +Different configurations produce different libraries and executables. For +example, Debug versions of dynamic libraries are always named *d.dll (like +aced.dll) and the executables are placed in the current directory. Release +versions of dynamic libraries are named *.dll (such as ace.dll) and their +executables are usually placed in the Release subdirectory. Other common +suffixes include *sd.lib for Static Debug and *s.lib for Static Release. + +Projects only use the same configuration versions of the libraries. The Debug +version of an ACE example only uses debug version of ACE library. + +@subsection msvc_otheroptions How to Set Other Options + +Other compile time options are set or unset via the config.h file. For +example, to turn on a compile time definition, #define it at the beginning of +config.h. Unsetting a definition just requires #define ACE_FOO 0 or a #undef +at the end of the file (after including config-win32.h). Different macros +require different techniques. + +@subsection msvc_libraries ACE/TAO Libraries + +I don't think we have any documents really giving any info on what libraries +are produced by the MSVC project files. + +So unlike the Unix platforms, Win32 libraries do not have a prefix of "lib", +instead it is used as an extension. For example, the debug version of the +dynamic ace library is aced.lib (which is a stub for aced.dll). The three +ACE libraries are: + +- ace +- ACE_RMCast +- ACE_SSL +- ACE_TMCast + +And for TAO we have the main TAO library and several sub libraries which +contain extra features of TAO that aren't always needed (such as the POA +in TAO_PortableServer). + +And finally we have the orbsvcs libraries. Each ORB service is contained +in its own library. More libraries may be needed to be linked in, since +some services require the use of others (such as TAO_AV requiring +TAO_CosTrading and TAO_CosProperty). + +The *.lib and *.dll files are located in ACE_wrappers/lib. You need +to point your PATH to $ACE_ROOT/lib for running the applications. + +I hesitate to put down explicit instructions on what libraries need to be +linked in, considering that the libraries are being split apart more and more +for footprint purposes. For most ACE stuff, you will only need to link in +ace.lib. For plain TAO clients TAO.lib is enough. TAO servers also require +TAO_PortableServer.lib for the POA. If the TAO application uses Dynamic Anys, +TAO_DynamicAny.lib is also needed. Then if any of the ORB Services are used, +more libraries are needed. For example, a client that uses the Name Service +would need to link TAO_CosNaming.lib. + +And note that the release versions of the libraries are listed above. For +debug configurations the libraries would be aced.lib, TAOd.lib, etc. + +@subsection msvc_external_projects External ACE/TAO Projects + +It is a little difficult for us to list how exactly one should create +projects that use ACE/TAO but are external to the ACE_wrappers tree. Since +most projects we create are in that tree, we can make assumptions about +directory structure that doesn't always apply for external projects. In +other words, we have ideas how they should work, but they usually remain +a bit, um, untested. :-) + +There are three main dependencies a project would have on ACE/TAO. + +- Include paths: Since all the headers use a subdirectory way of referring + to include files (such as "ace/OS.h" instead of just "OS.h"). In order + to make this work either the path to ACE_wrappers (and ACE_wrappers\TAO and + ACE_wrappers\TAO\orbsvcs, etc.) to the additional include paths of the + project or in MSVC. I believe it is a better idea to add them to the global + MSVC directories. That way the path to ACE on a machine doesn't get hard + coded into the project itself (this should make it easier to move the + project between machines where ACE is installed in different places). + +- Libraries and library paths: Depending on what features are needed, + different libraries are needed to be linked in. (This is covered more in + an above section). These libraries are specified in the project, but can + be specified in different ways. The first is the hard coded way (a full + path, such as "C:\ACE_wrappers\ace\aced.lib"). The second is listing only + the library (such as "aced.lib") and then specify the path either in the + project or via MSVC global settings. Just like for the include paths, MSVC + global settings is probably the more robust way of specifying this. + +- TAO_IDL: TAO's IDL compiler resides in ACE_wrappers\bin. If the external + project contains IDL files, then a custom build configuration can be used + to automatically call TAO_IDL. Note that the location of the release + version of the compiler is in ACE_wrappers\bin\Release (although it doesn't + matter which version you use, they both produce the same output). If + ACE_wrappers\bin is included in the path, then the build command can just + refer to tao_idl and it can be found via the path. The other options are + to refer to tao_idl via an absolute hard coded path or to add + ACE_wrappers\bin to the MSVC's global executable path settings. Either + way the bin directory must be in the path or in the global settings so + tao_idl can find aced.dll. + +So I guess in summary we would recommend adding most of the settings to Visual +C++'s global settings (include paths, library paths, and executable paths) +and just refer to the libraries without any paths. + +@subsection msvc_aceroot ACE_ROOT + +ACE_ROOT is an interesting environment variable. Even though it is heavily +used on Unix (in fact, ACE/TAO will not compile without it) it really isn't +needed for MSVC. The reason for this is that we were interested in making +configuration and setup really easy for Visual C++ on Windows. In retrospect +it might have made quite a few things easier to specify if ACE_ROOT was +required. One thing you might notice is that TAO_IDL will display a message +if ACE_ROOT isn't set, but it is only a problem if the IDL file includes +<orb.idl> and you don't use -I to specify where orb.idl is. + +*/
\ No newline at end of file diff --git a/ACE/docs/run_test.txt b/ACE/docs/run_test.txt new file mode 100644 index 00000000000..e236bcaa4cb --- /dev/null +++ b/ACE/docs/run_test.txt @@ -0,0 +1,232 @@ +/** +@page run_test_howto How to write a run_test.pl + +ACE/TAO's auto_builds expect run_test.pl's to follow some guidelines +that are needed to keep the auto_builds from hanging and to make +sure the run_test.pl works on all platforms + +- The run_test must not hang or block. +- The run_test must clean up any temporary files when it is done. +- The run_test must not require any user input +- The run_test should return a non-zero value if the test failed +- When an executable can't be spawned the test should directly exit and + not wait for a fail to be created by that executable + +Following is an example + +@subsection example Example + +@verbatim +eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}' + & eval 'exec perl -S $0 $argv:q' + if 0; + +# $Id$ +# -*- perl -*- + +use lib "$ENV{ACE_ROOT}/bin"; +use PerlACE::Run_Test; + +$status = 0; + +$plain_server_ior = "server.ior"; +$server_ior = PerlACE::LocalFile ("$plain_server_ior"); +unlink $server_ior; + +if (PerlACE::is_vxworks_test()) { + $SV = new PerlACE::ProcessVX ("server", "-o $plain_server_ior"); +} +else { + $SV = new PerlACE::Process ("server", "-o $server_ior_file"); +} + +$CL = new PerlACE::Process ("client", "-k file://$server_ior"); + +$server = $SV->Spawn (); + +if ($server != 0) { + print STDERR "ERROR: server returned $server\n"; + $status = 1; +} + +if (PerlACE::waitforfile_timed ($server_ior, $PerlACE::wait_interval_for_process_creation) == -1) { + print STDERR "ERROR: cannot find file <$server_ior>\n"; + $SV->Kill (); + exit 1; +} + +$client = $CL->SpawnWaitKill (60); + +if ($client != 0) { + print STDERR "ERROR: client returned $client\n"; + $status = 1; +} + +$server = $SV->TerminateWaitKill (5); + +if ($server != 0) { + print STDERR "ERROR: server returned $server\n"; + $status = 1; +} + +unlink $server_ior; + +exit $status; +@endverbatim + +@subsection details Example Details + +@verbatim +eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}' + & eval 'exec perl -S $0 $argv:q' + if 0; + +# $Id$ +@endverbatim + +This is the standard header stuff. The eval is a trick used +to get the perl script to run if it a unix shell treats it as +a shell script. + +The SVN ID string is the usual one we put in. + +@verbatim +use lib "$ENV{ACE_ROOT}/bin"; +use PerlACE::Run_Test; +@endverbatim + +The use lib line is used to tell Perl where the PerlACE modules are. +It should NOT be a relative path to the bin directory. This is how +it used to be done, but doing so would be incompatible with the "flat" +directory layout of ACE+TAO. The correct way is demonstrated above. +After the "use lib" line, always use $PerlACE::TAO_ROOT to reference +the location of TAO. Use either $ENV{ACE_ROOT} or $PerlACE::ACE_ROOT +to reference the location of ACE. + +And PerlACE::Run_Test is a module to be used by all run_test.pl's. +It does a couple of things, including parsing some common command +line arguments (like -Config and -ExeSubDir) and also brings in +the PerlACE::Process module. + +@verbatim +$status = 0; + +$server_ior = PerlACE::LocalFile ("server.ior"); + +unlink $server_ior; +@endverbatim + +Because of the way tests work on chorus, we need to have a fully +qualified path to all *.ior and *.conf files. We unlink the file +immediately because we use PerlACE::waitforfile_timed later. + +@verbatim +if (PerlACE::is_vxworks_test()) { + $SV = new PerlACE::ProcessVX ("server", "-o $plain_server_ior"); +} +else { + $SV = new PerlACE::Process ("server", "-o $server_ior_file"); +} +@endverbatim + +We check using PerlACE::is_vxworks_test() if we are testing for VxWorks. At +that moment we have to run on part of the test on the target, the other +part on the host system. The part that has to run on the target has to +be created as PerlACE::ProcessVX. When using VxWorks the files shouldn't +be passed in created by PerlACE::LocalFile because that refers to the +ior file on the host system, that is not reachable for the target, so +the plain text filename should be passed. + +@verbatim +$CL = new PerlACE::Process ("client", " -k file://$server_ior "); + +$server = $SV->Spawn (); + +if ($server != 0) { + print STDERR "ERROR: server returned $server\n"; + $status = 1; +} +@endverbatim + +The PerlACE::Process is constructed with an executable and +arguments. @note Unlike the old Process module, the process +isn't started until one of the Spawn methods is used. We check +the result of the spawn, if we couldn't spawn the process +we directly exit the script. + +@verbatim +if (PerlACE::waitforfile_timed ($server_ior, $PerlACE::wait_interval_for_process_creation) == -1) { + print STDERR "ERROR: cannot find file <$server_ior>\n"; + $SV->Kill (); + exit 1; +} +@endverbatim + +The PerlACE::waitforfile_timed method waits until the file is +created. In this way, we know when to start the client. If +no IOR file is used, then you'd need to use Perl's sleep +method. + +@verbatim +$client = $CL->SpawnWaitKill (60); + +if ($client != 0) { + print STDERR "ERROR: client returned $client\n"; + $status = 1; +} +@endverbatim + +Here is an example of starting the client. SpawnWaitKill will start +the process and wait for the specified number of seconds for the +process to end. If the time limit is reached, it will kill the +process and return -1. + +The return value of SpawnWaitKill is the return value of the +process, unless it timed out. You don't need to check for the +timeout, since SpawnWaitKill will print out a timeout error. +Instead, just check for != 0. + +@verbatim +$server = $SV->TerminateWaitKill (5); + +if ($server != 0) { + print STDERR "ERROR: server returned $server\n"; + $status = 1; +} +@endverbatim + +Here is the termination of the server. Servers are usually terminated +either by TerminateWaitKill or just WaitKill. TerminateWaitKill is +used when the server doesn't shut down itself. WaitKill is used when +it does (such as when the client calls a shutdown method). Once +again, we check the return status. + +@verbatim +unlink $server_ior; + +exit $status; +@endverbatim + +When you need the hostname the test is running on be aware of the +fact that with VxWorks we do cross host testing, part of the test +runs on the target, the other part on the host system. In your test +program add functionality to handle a commandline argument to pass +in the hostname of the target. In the run_test.pl script you can +then use the following code as example. + +@verbatim +$TARGETHOSTNAME = "localhost"; +if (PerlACE::is_vxworks_test()) { + $TARGETHOSTNAME = $ENV{'ACE_RUN_VX_TGT_HOST'}; + $SV = new PerlACE::ProcessVX ("server", "-ORBEndpoint iiop://$TARGETHOSTNAME:43210"); + } + else { + $SV = new PerlACE::Process ("server", "-ORBEndpoint iiop://$TARGETHOSTNAME:43210"); + } +$CL = new PerlACE::Process ("client", " -p 43210 -h $TARGETHOSTNAME"); +@endverbatim + +And finally, we unlink any files that were created and then just +exit with $status. + +*/ diff --git a/ACE/docs/svn/config b/ACE/docs/svn/config new file mode 100644 index 00000000000..f05b318d6ed --- /dev/null +++ b/ACE/docs/svn/config @@ -0,0 +1,133 @@ +### This file configures various client-side behaviors. +### +### The commented-out examples below are intended to demonstrate +### how to use this file. + +### Section for authentication and authorization customizations. +### Set store-auth-creds to no to avoid storing your subversion +### credentials in the auth/ area of your config directory. +### It defaults to yes. Note that this option only prevents +### saving of *new* credentials; it doesnt invalidate existing +### caches. (To do that, remove the cache files by hand.) +# [auth] +# store-auth-creds = no + +### Section for configuring external helper applications. +### Set editor to the command used to invoke your text editor. +### This will override the environment variables that Subversion +### examines by default to find this information ($EDITOR, +### et al). +### Set diff-cmd to the absolute path of your diff program. +### This will override the compile-time default, which is to use +### Subversions internal diff implementation. +### Set diff3-cmd to the absolute path of your diff3 program. +### This will override the compile-time default, which is to use +### Subversions internal diff3 implementation. +### Set diff3-has-program-arg to true or yes if your diff3 +### program accepts the --diff-program option. +# [helpers] +# editor-cmd = editor (vi, emacs, notepad, etc.) +# diff-cmd = diff_program (diff, gdiff, etc.) +# diff3-cmd = diff3_program (diff3, gdiff3, etc.) +# diff3-has-program-arg = [true | false] + +### Section for configuring tunnel agents. +# [tunnels] +### Configure svn protocol tunnel schemes here. By default, only +### the ssh scheme is defined. You can define other schemes to +### be used with svn+scheme://hostname/path URLs. A scheme +### definition is simply a command, optionally prefixed by an +### environment variable name which can override the command if it +### is defined. The command (or environment variable) may contain +### arguments, using standard shell quoting for arguments with +### spaces. The command will be invoked as: +### <command> <hostname> svnserve -t +### (If the URL includes a username, then the hostname will be +### passed to the tunnel agent as <user>@<hostname>.) If the +### built-in ssh scheme were not predefined, it could be defined +### as: +# ssh = $SVN_SSH ssh +### If you wanted to define a new rsh scheme, to be used with +### svn+rsh: URLs, you could do so as follows: +# rsh = rsh +### Or, if you wanted to specify a full path and arguments: +# rsh = /path/to/rsh -l myusername +### On Windows, if you are specifying a full path to a command, +### use a forward slash (/) or a paired backslash (\\) as the +### path separator. A single backslash will be treated as an +### escape for the following character. + +### Section for configuring miscelleneous Subversion options. +[miscellany] +### Set global-ignores to a set of whitespace-delimited globs +### which Subversion will ignore in its status output. +global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store *.class *C.i *C.inl *S.i *S.inl *C.h *S.h *C.cpp *S.cpp *C.hh *S.hh *S_T.i *S_T.inl *S_T.h *S_T.cpp .obj .pure .shobj config.h Templates.DB Thumbs.db ir.out *.aux *.lof *.lot *.log *.dvi *.blg *.bbl *.ior *Cli.* *Ser.* *Ser_T.* *.vcl *.vcb *.vcl *.vco *.SUP .depend.* GNUmake* [Mm]akefile *.mak *.a *.so* *.idb *.obj *.exe *_svnt.* *.user *.vcproj *.dsw *.dsp *.sln *.suo *.dep *.tlb *.pch *.ocx *.dll *.exp *.ilk *.lib *.ncb *.opt *.pdb *.plg *.bsc *.res LIB DLL Debug Release Static_Debug Static_Release *.bak *.trg *.mga *.mta ComponentLib.h *_[ip].c dlldata.c *.tds *.vxe +### Set log-encoding to the default encoding for log messages +# log-encoding = latin1 +### Set use-commit-times to make checkout/update/switch/revert +### put last-committed timestamps on every file touched. +use-commit-times = yes +### Set enable-auto-props to yes to enable automatic properties +### for svn add and svn import, it defaults to no. +### Automatic properties are defined in the section auto-props. +enable-auto-props = yes + +### Section for configuring automatic properties. +### The format of the entries is: +### file-name-pattern = propname[=value][;propname[=value]...] +### The file-name-pattern can contain wildcards (such as * and +### ?). All entries which match will be applied to the file. +### Note that auto-props functionality must be enabled, which +### is typically done by setting the enable-auto-props option. +[auto-props] +*.cpp=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.cxx=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.cc=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.C=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.c=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.l=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.y=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.h=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.hpp=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.inl=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.i=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.cs=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.java=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.idl=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.pidl=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.cidl=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.html=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.sh=svn:eol-style=native;svn:keywords=Author Date Id Revision;svn:executable +*.py=svn:eol-style=native;svn:keywords=Author Date Id Revision;svn:executable +*.pl=svn:eol-style=native;svn:keywords=Author Date Id Revision;svn:executable +*.mpc=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.mwc=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.mpb=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.mpt=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.cdp=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.pcd=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.cdd=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.cid=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.cpd=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.ccd=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.iad=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.xsd=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.xml=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.txt=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.am=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.ac=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.lst=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.pm=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.sty=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.cls=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.clo=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.tex=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.bib=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.bst=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.eps=svn:mime-type=application/postscript +*.ps=svn:mime-type=application/postscript +*.pdf=svn:mime-type=application/pdf +*.tab=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.doxygen=svn:eol-style=native;svn:keywords=Author Date Id Revision +*.rc=svn:eol-style=native;svn:keywords=Author Date Id Revision +Change?og*=svn:eol-style=native;svn:keywords=Author Date Id Revision diff --git a/ACE/docs/svn/svn-prefs.reg b/ACE/docs/svn/svn-prefs.reg new file mode 100644 index 00000000000..d1720218b74 --- /dev/null +++ b/ACE/docs/svn/svn-prefs.reg @@ -0,0 +1,88 @@ +REGEDIT4 + +[HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Servers\groups] + +[HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Servers\global] +"#http-proxy-host"="" +"#http-proxy-port"="" +"#http-proxy-username"="" +"#http-proxy-password"="" +"#http-proxy-exceptions"="" +"#http-timeout"="0" +"#http-compression"="yes" +"#neon-debug-mask"="" +"#ssl-authority-files"="" +"#ssl-trust-default-ca"="" +"#ssl-client-cert-file"="" +"#ssl-client-cert-password"="" + +[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auth] +"#store-auth-creds"="no" + +[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\helpers] +"#editor-cmd"="notepad" +"#diff-cmd"="" +"#diff3-cmd"="" +"#diff3-has-program-arg"="" + +[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\miscellany] +"global-ignores"="*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store *.class *C.i *C.inl *S.i *S.inl *C.h *S.h *C.cpp *S.cpp *C.hh *S.hh *S_T.i *S_T.inl *S_T.h *S_T.cpp .obj .pure .shobj config.h Templates.DB Thumbs.db ir.out *.aux *.lof *.lot *.log *.dvi *.blg *.bbl *.ior *Cli.* *Ser.* *Ser_T.* *.vcl *.vcb *.vcl *.vco *.SUP .depend.* GNUmake* [Mm]akefile *.mak *.a *.so* *.idb *.obj *.exe *_svnt.* *.user *.vcproj *.dsw *.dsp *.sln *.suo *.dep *.tlb *.pch *.ocx *.dll *.exp *.ilk *.lib *.ncb *.opt *.pdb *.plg *.bsc *.res LIB DLL Debug Release Static_Debug Static_Release *.bak *.trg *.mga *.mta ComponentLib.h *_[ip].c dlldata.c *.tds *.vxe" +"#log-encoding"="" +"use-commit-times"="yes" +"#template-root"="" +"enable-auto-props"="yes" +[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\tunnels] + +[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auto-props] +"*.cpp"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.cxx"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.cc"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.C"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.c"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.l"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.y"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.h"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.hpp"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.inl"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.i"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.cs"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.java"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.idl"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.pidl"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.cidl"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.html"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.sh"="svn:eol-style=native;svn:keywords=Author Date Id Revision;svn:executable" +"*.py"="svn:eol-style=native;svn:keywords=Author Date Id Revision;svn:executable" +"*.pl"="svn:eol-style=native;svn:keywords=Author Date Id Revision;svn:executable" +"*.mpc"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.mwc"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.mpb"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.mpt"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.cdp"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.pcd"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.cdd"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.cid"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.cpd"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.ccd"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.cid"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.xsd"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.xml"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.txt"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.am"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.ac"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.lst"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.pm"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.sty"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.cls"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.clo"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.tex"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.bib"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.bst"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.eps"="svn:mime-type=application/postscript" +"*.ps"="svn:mime-type=application/postscript" +"*.pdf"="svn:mime-type=application/pdf" +"*.ps"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.tab"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.doxygen"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"*.rc"="svn:eol-style=native;svn:keywords=Author Date Id Revision" +"Change?og*"="svn:eol-style=native;svn:keywords=Author Date Id Revision" diff --git a/ACE/docs/usage-bugzilla.html b/ACE/docs/usage-bugzilla.html new file mode 100644 index 00000000000..8d0e1a0d342 --- /dev/null +++ b/ACE/docs/usage-bugzilla.html @@ -0,0 +1,102 @@ +<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> +<html> + <!-- $Id$ --> + <head> + <title>DOC Center Bug Tracking System Usage</title> + </head> + + <body text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff"> + <h1>DOC Center Bug Tracking System Usage</h1> + + <p> + The + <a href="http://www.dre.vanderbilt.edu"> + Center for Distributed Object Computing</a> uses the + <a href="http://www.mozilla.org/projects/bugzilla/">Bugzilla</a> + bug tracking system to keep track of existing problems and + enhancement requests. + + <p> + To streamline our development process, you can now use it to + enter problem reports or make a request for a particular feature + that you'd like to see integrated into + <a href="http://www.dre.vanderbilt.edu/ACE">ACE</a>, + <a href="http://www.dre.vanderbilt.edu/TAO">TAO</a> or <a + href="http://www.dre.vanderbilt.edu/CIAO">CIAO</a>. + + <p> + You can also use it to track the status of a particular bug or + enhancement. In addition, the bug tracking system can be used + to add comments and attachments that contain solutions or simple + test cases. + + <p> + The bug tracking system is located at the following web site: + <samp> + <a href="http://deuce.doc.wustl.edu/bugzilla/index.cgi"> + http://deuce.doc.wustl.edu/bugzilla/index.cgi + </a> + </samp> + + <p> + If all you want to do is browse through the bugs in our bug + tracking system or view bug summary reports, then you can use + the bug tracking system right away. However, if you want to be + able to submit bug reports then you will have to create a bug + tracking system account. + + <p> + Upon entering a bug or enhancement request for the first time, + you will be asked to enter an e-mail address. Once you've done + that, you will be mailed a password that you can use to log on + to the bug tracking system. You will only be asked to do this + once. Any changes to bug reports you submit will be mailed to + the e-mail address you provide. + + <p> + Once you've logged on, you will have the ability to enter bug + reports and modify existing ones. Other than adding comments, + fixes and attachments, please do not modify bug reports you + haven't submitted. + + <p> + The bug tracking system is fairly straightforward to use. When + entering bug reports or enhancement requests, enter as much + information as possible. Most of the bug form fields provide + help if you are unsure what a particular field is used for. + + <p> + For more information about using Bugzilla, and about bug + reporting in general, please see the following web sites: + + <p> + <blockquote> + <samp> + <a href="http://www.mozilla.org/bugs"> + http://www.mozilla.org/bugs/ + </a><br> + <a href="http://www.mozilla.org/quality/bug-writing-guidelines.html"> + http://www.mozilla.org/quality/bug-writing-guidelines.html + </a> + </samp> + </blockquote> + + <p> + Keep in mind that the Bugzilla installation at the above web + site is <em>not</em> the same Bugzilla installation at the + Center for Distributed Object Computing. All bug reports and + enhancement requests for ACE and TAO should be done at the + Center for Distributed Object Computing's Bugzilla web site. + + + + <hr> + <address><a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a></address> +<!-- Created: Wed Aug 18 14:45:31 EDT 1999 --> +<!-- hhmts start --> +Last modified: Wed Nov 14 21:36:32 Pacific Standard Time 2001 +<!-- hhmts end --> + <br> + Back to <a href="index.html">ACE Documentation Home</a>. + </body> +</html> diff --git a/ACE/docs/wchar.txt b/ACE/docs/wchar.txt new file mode 100644 index 00000000000..14c0d9e5ce0 --- /dev/null +++ b/ACE/docs/wchar.txt @@ -0,0 +1,128 @@ +/** +@page wchar Wide Character/Unicode support in ACE + +Here's a first stab at some sort of documentation for the magic +wide-character (wchar) stuff in ACE. It should be possible to compile +ACE with wchar support on most platforms that ACE runs on. In some +cases, we don't enable wchar support by default since it increases the +footprint a bit. If you run into any problems, please use the +$ACE_ROOT/PROBLEM-REPORT-FORM to let us know. + +@subsection wchar_overview Overview + +There are three different wchar configurations that ACE can use. These are +no support mode, regular support mode, and full support mode (well, those are +the best names I can come up with for now). + +@subsection wchar_nosupport No Support + +By default, ACE will not use wchar_t at all. This is for platforms where +wchar_t does not exist or support for it is pretty flakey. + +@subsection wchar_regular Regular Support + +If ACE_HAS_WCHAR is defined, then ACE classes will be expanded to have extra +methods which take in wchar_t strings. Note that all the methods available +with No Support are also available here. This is the default in Windows +right now, and has been tested to work on Linux and VxWorks (well, only been +tested to compile/link of VxWorks). + +@subsection wchar_full Full Support + +Full support is turned on if ACE_HAS_WCHAR and ACE_USES_WCHAR are defined. +Like Regular Support, both char and wchar_t versions of some methods are +available, but unlike Regular Support, other methods that have char arguments +or return values may have wchar_t arguments or return values. + +This has only been tested in Windows, and is the default for Windows CE. + +@subsection wchar_othermacros Other Important Macros + +In addition to the ACE_HAS_WCHAR and ACE_USES_WCHAR mentioned above, there +are several other macros that are important when using wide character support +in ACE. + +These other macros are used in code to conditionally switch between char and +wchar_t. ACE_TCHAR is a char normally and wchar_t when ACE_USES_WCHAR is +defined. ACE_TEXT ("foo") expands to "foo" normally and L"foo" when +ACE_USES_WCHAR is defined. + +ACE_TEXT_CHAR_TO_TCHAR and ACE_TEXT_WCHAR_TO_TCHAR are used when a string +that is always a char or wchar_t string needs to be converted to a ACE_TCHAR +string. On the same note, ACE_TEXT_ALWAYS_CHAR is used when a string is +ACE_TCHAR * and needs to be a char * string. + +ACE_TEXT_WIDE ("foo") is unique in that it always maps to L"foo". It is not +a conditional macro. + +For string constants in code, ACE_TEXT and ACE_LIB_TEXT are used to put the +Unicode prefix (Usually 'L') before the string when needed. By default both +are controlled by ACE_USES_WCHAR. + +All ACE code except for the ACE library should use ACE_TEXT. ACE_LIB_TEXT +was introduced as a short-term fix for backwards compatibility purposes. +This allows ACE_TEXT to be overriden to act just like TEXT in Microsoft +Windows while not affecting ACE's interface. In the future ACE_LIB_TEXT and +this backwards compatibility will be deprecated and removed. + +Finally, on Windows there are a bunch of ACE_TEXT_Apicall type macros which +are used to choose the correct version of a Win32 API function depending on +ACE_USES_WCHAR. I'm hoping to remove these by adding a new ACE_OS_Win32 +class to perform the same task, but until then these ugly macros get the job +done. + +@subsection wchar_logmsg ACE_Log_Msg support + +One of the more troublesome aspect of supporting wide and Ansi strings is +the fact that the format strings for ACE_DEBUG and family always had to have +ACE_TEXT (or ACE_LIB_TEXT) around them. + +Now this should not be the case, since ACE_Log_Msg was extended to support +both types of format strings concurrently. This is okay, but when strings +are printed out via the format_string, care has to be taken. + +It is interesting how Unix and Windows treats the format specifiers +differently, based on their history. Win32 uses %s, %c, %S and %C, whereas +Linux seems to use %s, %c, %ls, and %lc. And they even treat %s and %c +differently. The route ACE takes is a bit of a mixture of both: + +- %c: prints out an Ansi character +- %C: prints out an Ansi string +- %s: prints out an ACE_TCHAR string +- %w: prints out a Wide character +- %W: prints out a Wide string + +An example, which will also function correctly even when ACE_USES_WCHAR is +defined: + +@verbatim +void print (char *a_str, wchar_t *w_str, ACE_TCHAR *t_str) +{ + ACE_DEBUG ((LM_DEBUG, + "%C %s %W\n", + a_str, + t_str, + w_str)); +} +@endverbatim + +@subsection wchar_win32macros Relation to Win32's UNICODE and _UNICODE macros + +It used to be that in previous versions of ACE that the Win32 macros affected +ACE in some way. This has been all removed in favor of the ACE_USES_WCHAR +and ACE_HAS_WCHAR macros. Along with this, the definition of some of the +Win32 string types (LPTSTR, LPCSTR, etc.) have been also removed. Since this +isn't a direct concern of ACE, they will have to be defined separately if +they are needed on non-Win32 platforms. + +The way I'd recommend doing this is to add the typdefs to config.h. + +@subsection wchar_legacy Legacy Support + +Most of the old macros (ACE_HAS_UNICODE, ACE_HAS_MOSTLY_UNICODE_APIS) are +ignored by default by ACE, since the new macros replaced them. If +ACE_LEGACY_MODE is defined, there is an attempt to map them to the new scheme +by just ACE_HAS_UNICODE == ACE_HAS_WCHAR and ACE_HAS_MOSTLY_UNICODE_APIS == +ACE_USES_WCHAR. + +*/ |