cppunit-devel — CppUnit Developer Mailing List

[Cppunit-devel] CppUnit 1.7.0

[Baptiste L. <bl...@cl...>]

    Hi Steve,

    I noticed you updated the version 1.7.0, so If I understood well, we're
going to make the change for release 1.8.0 straight into the main trunc,
right ?

    Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

Re: [Cppunit-devel] Re: [ cppunit-Bugs-464844 ] Comp. warnings & errors - rel 1.6.0

[Stanley S. <su...@t-...>]

"Steve M. Robbins" wrote:

> Hi,
>
> On Sun, Sep 30, 2001 at 12:54:47PM -0500, Stanley Sutton wrote:
>
> > I'm having the same problem on Solaris 8, with the Forte 6 update 1 compiler.
>
> OK.  It seems likely that Baptiste's change will fix this particular
> problem.  If you have the chance, you could apply the diff below or
> grab the CVS sources now or release 1.6.1 tomorrow and test them.
> We'd really like to know whether the problem goes away.
>
> > One subtle difference in the Forte 6 update 1 and later compilers is
> > that they are ISO complient, rather than ANSI complient.  The
> > compiler/linker also has some mangling issues.  I've attached the
> > readme for the update 1 compiler.
>
> So, even with the fix, is there a problem linking with CppUnit?
>
> -S
>
> Index: include/cppunit/extensions/HelperMacros.h
> ===================================================================
> RCS file: /cvsroot/cppunit/cppunit/include/cppunit/extensions/HelperMacros.h,v
> retrieving revision 1.15
> retrieving revision 1.16
> diff -u -b -B -r1.15 -r1.16
> --- include/cppunit/extensions/HelperMacros.h   2001/09/23 06:09:15     1.15
> +++ include/cppunit/extensions/HelperMacros.h   2001/09/30 14:44:18     1.16
> @@ -101,6 +101,13 @@
>  #define CPPUNIT_TEST_SUITE( ATestCaseType )                               \
>    private:                                                                \
>      typedef ATestCaseType __ThisTestCaseType;                             \
> +    class ThisTestCaseFactory : public CppUnit::TestFactory               \
> +    {                                                                     \
> +      virtual CppUnit::Test *makeTest()                                   \
> +      {                                                                   \
> +        return new ATestCaseType();                                       \
> +      }                                                                   \
> +    };                                                                    \
>    public:                                                                 \
>      static void                                                           \
>      registerTests( CppUnit::TestSuite *suite,                             \
> @@ -174,15 +181,9 @@
>        ThisTestCaseFactory factory;                                      \
>        __ThisTestCaseType::registerTests( builder.suite(), &factory );   \
>        return builder.takeSuite();                                       \
> -    }                                                                   \
> -  private:                                                              \
> -    class ThisTestCaseFactory : public CppUnit::TestFactory             \
> -    {                                                                   \
> -      virtual CppUnit::Test *makeTest()                                 \
> -      {                                                                 \
> -        return new __ThisTestCaseType();                                \
>        }                                                                 \
> -    }
> +  private: /* dummy typedef so that the macro can still end with ';'*/  \
> +    typedef ThisTestCaseFactory __ThisTestCaseFactory
>
>  #define __CPPUNIT_CONCATENATE_DIRECT( s1, s2 ) s1##s2
>  #define __CPPUNIT_CONCATENATE( s1, s2 ) __CPPUNIT_CONCATENATE_DIRECT( s1, s2 )
>
> --
> by Rocket to the Moon,
> by Airplane to the Rocket,
> by Taxi to the Airport,
> by Frontdoor to the Taxi,
> by throwing back the blanket and laying down the legs ...
> - They Might Be Giants
>
> _______________________________________________
> kkkkkkkkkkkkkkkkkkkkkkkk/registerTests

jjjkkkkk

> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel

With that patch, it does compile and run correctly.  I appreciate the help.  Now I
just have to figure our how ot use it for generating unit tests for a B*-Tree
class.  :-)

--
Stanley M. Sutton   sms...@ie...           su...@t-...
TSurf Corporation - The gOcad Company -         http://www.t-surf.com
11011 Richmond Ave. Suite 350                   Houston TX 77042
Phone: (1) 713 787 0746 ext. 13                 Fax: (1) 713 787 0852
---------------------------------------------------------------------
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
                                      - Benjamin Franklin

Re: [Cppunit-devel] Re: [ cppunit-Bugs-464844 ] Comp. warnings & errors - rel 1.6.0

[Baptiste L. <bl...@cl...>]

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Sunday, September 30, 2001 7:57 PM
Subject: Re: [Cppunit-devel] Re: [ cppunit-Bugs-464844 ] Comp. warnings &
errors - rel 1.6.0


> Hi all,
>
> Does anyone find the doxygen-generated manpages to be useful, or do
> you use the HTML docs exclusively?  The issue is this: it is a bit
> of a nuisance to get the manpages installed correctly, so 1.6.1
> will not install them, though it does install the HTML.  I don't find
> the manpages useful, so I won't make the effort to install them unless
> other folks want it.  Let me know!

    HTML only for me ;-). It's hard to get away with C++ without looking at
the "neighbor" classes. The advanced linking facility of Doxygen really help
with that.

> On Sun, Sep 30, 2001 at 04:29:28PM +0200, Baptiste Lepilleur wrote:
>
> >   I don't remember the rules. I'm sure I read something about it
somewhere.
> > An alternative would be to move the nested class declaration to
> > CPPUNIT_TEST_SUITE where the type is explicit available as a macro
> > parameter. In fact I just did that (comitted).
>
> Brilliant.  I expect that will work.
>
> Thanks for the contrib/msvc files.  I modifed the makefile to put them
> into the distribution.  Once you've cvs-added and cvs-committed your
> FAQ file, I think we are ready to release 1.6.1.  Let me know if there
> is something you want to put in.

    Oops, forgot to add and commit. Should be done when you get the mail.

    Baptiste.

Re: [Cppunit-devel] Re: [ cppunit-Bugs-464844 ] Comp. warnings & errors - rel 1.6.0

[Steve M. R. <ste...@vi...>]

Hi,

On Sun, Sep 30, 2001 at 12:54:47PM -0500, Stanley Sutton wrote:

> I'm having the same problem on Solaris 8, with the Forte 6 update 1 compiler.

OK.  It seems likely that Baptiste's change will fix this particular
problem.  If you have the chance, you could apply the diff below or
grab the CVS sources now or release 1.6.1 tomorrow and test them.
We'd really like to know whether the problem goes away.


> One subtle difference in the Forte 6 update 1 and later compilers is
> that they are ISO complient, rather than ANSI complient.  The
> compiler/linker also has some mangling issues.  I've attached the
> readme for the update 1 compiler.  

So, even with the fix, is there a problem linking with CppUnit?

-S


Index: include/cppunit/extensions/HelperMacros.h
===================================================================
RCS file: /cvsroot/cppunit/cppunit/include/cppunit/extensions/HelperMacros.h,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -b -B -r1.15 -r1.16
--- include/cppunit/extensions/HelperMacros.h	2001/09/23 06:09:15	1.15
+++ include/cppunit/extensions/HelperMacros.h	2001/09/30 14:44:18	1.16
@@ -101,6 +101,13 @@
 #define CPPUNIT_TEST_SUITE( ATestCaseType )                               \
   private:                                                                \
     typedef ATestCaseType __ThisTestCaseType;                             \
+    class ThisTestCaseFactory : public CppUnit::TestFactory               \
+    {                                                                     \
+      virtual CppUnit::Test *makeTest()                                   \
+      {                                                                   \
+        return new ATestCaseType();                                       \
+      }                                                                   \
+    };                                                                    \
   public:                                                                 \
     static void                                                           \
     registerTests( CppUnit::TestSuite *suite,                             \
@@ -174,15 +181,9 @@
       ThisTestCaseFactory factory;                                      \
       __ThisTestCaseType::registerTests( builder.suite(), &factory );   \
       return builder.takeSuite();                                       \
-    }                                                                   \
-  private:                                                              \
-    class ThisTestCaseFactory : public CppUnit::TestFactory             \
-    {                                                                   \
-      virtual CppUnit::Test *makeTest()                                 \
-      {                                                                 \
-        return new __ThisTestCaseType();                                \
       }                                                                 \
-    }
+  private: /* dummy typedef so that the macro can still end with ';'*/  \
+    typedef ThisTestCaseFactory __ThisTestCaseFactory                   
 
 #define __CPPUNIT_CONCATENATE_DIRECT( s1, s2 ) s1##s2
 #define __CPPUNIT_CONCATENATE( s1, s2 ) __CPPUNIT_CONCATENATE_DIRECT( s1, s2 )




-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] Re: [ cppunit-Bugs-464844 ] Comp. warnings & errors - rel 1.6.0

[Stanley S. <su...@t-...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta http-equiv="Content-Type" content=
"text/html; charset=iso-8859-1">
<meta name="LAST-MODIFIED" content="00/08/28">
<meta name="DESCRIPTION" content="Sun WorkShop Component Readme">
<meta name="KEYWORDS" content=
"readme, documentation, publication,">
<meta name="GENERATOR" content=
"Mozilla/4.04 [en] (X11; I; SunOS 5.5.1 sun4u) [Netscape]">
<title>Sun WorkShop(TM) Compilers C++ 6 update 1 Readme</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" cellpadding="0" width="98%">
<tr>
<td align="right"><i><font size="-1">Updated 00/08/28</font></i></td>
</tr>
</table>

<table border="0" cellpadding="6" width="100%">
<tr>
<td bgcolor="#666699"><font face="Arial,Helvetica"><font color= 
"#FFFFFF"><font size="+4">Sun WorkShop(TM) Compilers C++ 6 update 1
Readme</font></font></font></td>
</tr>
</table>

&nbsp; 

<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td width="10%">&nbsp;</td>
<td>&nbsp; <font size="+2">Contents&nbsp;</font> 

<ol type="A">
<li><a href="#introduction">Introduction</a></li>

<li><a href="#about">About the Sun WorkShop 6 update 1 C++ Compiler
(5.2)</a></li>

<li><a href="#corrections">Software Corrections</a>&nbsp;</li>

<li><a href="#problems">Problems and Workarounds</a>&nbsp;</li>

<li><a href="#limitations">Limitations and
Incompatibilities</a>&nbsp;</li>

<li><a href="#documenation">Documentation Errata</a>&nbsp;</li>

<li><a href="#shippable">Shippable Libraries</a>&nbsp;</li>

<li><a href="#new">New Features</a>&nbsp;</li>

<li><a href="#standards">Standards Not Implemented</a></li>
</ol>

<p>&nbsp;</p>

<hr>
<p><a name="introduction"></a><font size="+2">A. Introduction</font></p> 

<p>This document contains last minute information about the Sun
WorkShop 6 update 1 C++ compiler. It describes the software
corrections addressed by this release and lists the known problems,
limitations, and incompatibilities.</p>

<p>To view the text version of this document, type the following at
a command prompt:</p>

<pre>
   example% CC -xhelp=readme
</pre>

<p> To access the HTML version of this document, point your
Netscape(TM) Communicator 4 or compatible Netscape version browser
to:</p>

<pre>
   <a href=
"../../index.html">file:/opt/SUNWspro/docs/index.html</a>
</pre>

<p><b>Note -</b>&nbsp;If your Sun WorkShop software is not installed
in the <tt>/opt</tt> directory, ask your system administrator for
the equivalent path on your system. 

<p>For more information about this product, see the following
sources. If your Sun WorkShop 6 update 1 software is not installed
in the <tt>/opt</tt> directory, ask your system administrator for
the equivalent path on your system.</p>

<ul>
<li><b>Man pages and readmes.</b> These describe the new features,
performance enhancements, problems and workarounds, and software
corrections in this Sun WorkShop 6 update 1 release. 

<p> You can access these documents in HTML on your local system or
network by pointing your browser to <a href="../../index.html"><tt>
file:/opt/SUNWspro/docs/index.html</tt></a>.</p>
</li>

<li><b>The Sun WorkShop and Sun WorkShop TeamWare online help.</b>
The online help has been updated for the new features in this Sun
WorkShop 6 update 1 release. 

<p>You can access the online help on your local system or network
by pointing your browser to <a href="../../index.html"><tt>
file:/opt/SUNWspro/docs/index.html</tt></a>. You can also access
the online help from the Help menus in the Sun WorkShop
products.</p>
</li>

<li><b><i>What's New in Sun WorkShop 6 update 1</i></b>. This
document describes the new features in this Sun WorkShop 6 update 1
release and in the Sun WorkShop 6 release. 

<p> You can access this manual on your local system or network by
pointing your browser to <a href="../../index.html"><tt>
file:/opt/SUNWspro/docs/index.html</tt></a>. You can also access it
by pointing your browser to <a href="http://docs.sun.com"><tt>
http://docs.sun.com</tt></a> and searching for the Forte(TM) Developer
6 update 1 collection.</p>
</li>

<li><b>Sun WorkShop 6 manuals.</b> These manuals were provided with
Sun WorkShop 6. Information in the man pages, readmes, and online
help for Sun&nbsp;WorkShop&nbsp;6&nbsp;update&nbsp;1 supersedes
information in the manuals. 

<p> You can access the manuals on your local system or network by
pointing your browser to <a href="../../index.html"><tt>
file:/opt/SUNWspro/docs/index.html</tt></a>. You can also access
them by pointing your browser to <a href="http://docs.sun.com"><tt>
http://docs.sun.com</tt></a> and searching for the Forte(TM) C, Forte(TM)
C++, Forte(TM) for High Performance Computing, and Forte(TM) TeamWare
products.</p>

<p>The following Sun WorkShop manuals are <i>not</i> available
through <tt>http://docs.sun.com</tt>. You can access them on your
local system or network by pointing your browser to <a href= 
"../../index.html"><tt>
file:/opt/SUNWspro/docs/index.html</tt></a>.</p>

<ul>
<li><i>Sun WorkShop Memory Monitor User's Manual</i></li>

<li><i>Standard C++ Class Library Reference</i></li>

<li><i>Standard C++ Library User's Guide</i></li>

<li><i>Tools.h++ Class Library Reference</i></li>

<li><i>Tools.h++ User's Guide</i></li>

<li><i>Sun Performance Library Reference</i></li>
</ul>
<p>
</li>

<li><b>Sun WorkShop 6 update 1 supplements.</b> The supplements
provide more detailed information on some of the major new features
in this Sun WorkShop 6 update 1 release. 

<p> You can access the supplements by pointing your browser to <a
href="http://docs.sun.com"><tt> http://docs.sun.com</tt></a> and
searching for the Forte Developer 6 update 1 collection. The
supplements are not available on your local system or network
because they are not on the Forte Developer 6 update 1 CD.</p>
</li>
<li><i><b>Sun WorkShop 6 update 1 Release Notes.</b></i> These notes
provide installation-related and late-breaking information about
this Sun&nbsp;WorkShop&nbsp;6&nbsp;update&nbsp;1 release. Information
in the release notes supersedes information in any of the other
documentation.

<p>The release notes are available as a text file on the Forte
Developer 6 update 1 CD at <tt>
/cdrom/devpro_v8n1_&lt;platform&gt;/release_notes.txt</tt> (where
<tt>&lt;platform&gt;</tt> is either <tt>sparc</tt> or <tt>intel</tt>).
The release notes are also
available in HTML on the <a href=
"http://www.sun.com/forte/developer/hotnews.html"> Forte Developer
Products Hot News</a> page at <tt>
http://www.sun.com/forte/developer/hotnews.html</tt>.</p>
</li>
</ul>

<p>&nbsp;</p>

<hr>
<a name="about"></a><font size="+2">B. About the Sun WorkShop 6
update 1 C++ Compiler (5.2)</font> 

<p>The Sun WorkShop 6 update 1 C++ compiler (5.2) runs on SPARC(TM)
processors running Solaris(TM) SPARC Platform Edition versions 2.6,
7, and 8, and Intel(R) processors running Solaris Intel Platform
Edition, versions 2.6, 7, and 8. Information unique to one or more
platforms is identified as "(SPARC)" or "(IA)."&nbsp;</p>

<p>This 5.2 version of the C++ compiler is upwardly
source-compatible and binary-compatible with C++ compiler versions
5.0 and 5.1. That is, you can compile source code written for
versions 5.0 and 5.1 of the C++ compiler using the 5.2 C++
compiler. In addition, you can link object code that was generated
by C++ compiler versions 5.0 and 5.1 with object code that was
generated by the 5.2 C++ compiler.</p>

<p>The 5.2 C++ compiler also offers the <tt>-compat</tt> option for
compiling source code that was written for the 4.2 C++ compiler.
The <tt>-compat</tt> option was introduced in version 5.0.</p>

<p>&nbsp;</p>

<hr>
<a name="corrections"></a> <font size="+2">C. Software
Corrections</font>
<p>
This section discusses the following software corrections.
</p>
<ol>
<li><a href="#aStatic">Support for
<tt>-instance=static</tt> and <tt>-instance=semiexplicit</tt> With
Static Variables Within Templates</a></li>
<li><a href="#aDifferent">Different Behavior for
Function-Local Static Variables for Extern Inline Functions</a></li>
<li><a href="#aTemplate">Template Syntax Error is No
Longer Ignored</a></li>
</ol>
<p>
<ol>

<li><a name="aStatic"><font size="+1">Support for
<tt>-instance=static</tt> and <tt>-instance=semiexplicit</tt> With
Static Variables Within Templates
</font></a>
<p>
With prior versions of the C++ compiler, use of the
static instances method and use of the semi-explicit instances
method were not supported with static variables within templates.
This restriction does not exist with the 5.2 version.</p>

<li><a name="aDifferent"><font size="+1">Different Behavior for
Function-Local Static Variables for Extern Inline Functions
</font></a>
<p>Under the ARM rules, function-local static variables
for extern inline functions are file static. Under the ISO
standard, function-local static variables for extern inline
functions are global variables that are shared
among compilation units.</p>
<p>
The 5.0 and 5.1 versions of the C++ compiler implemented the ARM
behavior for both compatibility mode (<tt>-compat</tt>) and
standard mode (the default mode). The 5.2 version of
the C++ compiler implements the ARM behavior for compatiblity mode
and the ISO behavior for standard mode. For example,
<pre>
one.cc

    inline int inner() { 
      static int variable = 0; return variable++; 
    }
    int outer() { return inner(); }

two.cc

    inline int inner() { 
      static int variable = 0; return variable++; 
    }
    int main() { return inner() + outer(); }
</pre>
<p>When compiled in compatibility mode (<tt>-compat</tt>), the two
variables are different and the result of main is <tt>0</tt> (zero).
<p>
When compiled in standard mode (the default mode), the two
variables are the same and the result of main is <tt>1</tt> (one).
To obtain the old behavior in standard mode, declare the 
inline function static.</p>
</li>

<li><a name="aTemplate"><font size="+1">Template Syntax Error is No
Longer Ignored</font></a>

<p>The following template syntax has never been valid, but Sun C++
4 and 5.0 did not report the error. The 5.1 and 5.2 versions of the
C++ compiler report this syntax error when you compile in standard
mode (the default mode).</p>

<pre>
  template&lt;class T&gt; class MyClass&lt;T&gt; { ... }; // definition error
  template&lt;class T&gt; class MyClass&lt;T&gt;;         // declaration error
</pre>

<p>In both cases, the "<tt>&lt;T&gt;</tt>" on
"<tt>MyClass&lt;T&gt;</tt>" is invalid, and must be removed, as
shown in the following example:</p>

<pre>
  template&lt;class T&gt; class MyClass { ... }; // definition
  template&lt;class T&gt; class MyClass;         // declaration
</pre>
</li>
</ol>
<p>&nbsp;</p>

<hr>
<a name="problems"></a><font size="+2">D. Problems and
Workarounds</font> 

<p>This section discusses the following software bugs that could
not be fixed in time for this release. For updates, check Forte
Developer Products Hot News at <a href=
""><tt>http://www.sun.com/forte/developer/hotnews.html</tt></a>.</p>

<ol>
<li><a href="#anEmpty">An Empty Virtual Base Class Can Cause a
Program to Core Dump</a></li>

<li><a href="#cNameMangling">Name Mangling Linking
Problems</a></li>

<li><a href="#cmake">Using <tt>make</tt> With Standard Library
Header Files on Versions 2.6 and 7 of the Solaris Operating
Environment</a></li>

<li><a href="#cIncorrect">Debugging Tools Erroneously Report Extra
Leading Parameter for Member Functions</a></li>

<li><a href="#cUndefined">Reference From Template to Non-Global
File-Scope Object is Not Supported</a></li>

<li><a href="#cHeaders">Standard Header Warning Messages</a></li>

<li><a href="#cpragma"><tt>#pragma</tt> <tt>align</tt> Inside
Namespace Requires Mangled Names</a></li>

<li><a href="#cctypend"><tt>__ctype</tt> Not Defined
Errors</a></li>
</ol>
<p>
<ol>
<li><a name="anEmpty"><font size="+1">An Empty Virtual Base Class
Can Cause a Program to Core Dump</font></a> 

<p>A program might core dump if it has a complex class hierarchy
that contains empty virtual base classes. To prevent the problem,
add a data member to the empty virtual base class. You do not need
to initialize the data member. When you copy or assign the virtual
base class, you do not need to copy or assign the data member. 
<!-- 4309374/4350308 --></p>
</li>

<li><a name="cNameMangling"><font size="+1">Name Mangling Linking
Problems</font></a> 

<p>The following conditions may cause linking problems:</p>

<ul>
<li>A function is declared in one place as having a const parameter
and in another place as having a non-const parameter. 

<p>Example:</p>

<pre>
  void foo1(const int);
  void foo1(int);
</pre>

<p>These declarations are equivalent, but the compiler mangles the
names differently. To prevent this problem, do not declare value
parameters as <tt>const</tt>. For example, use <tt>void
foo1(int);</tt> everywhere, including the body of the function
definition.
</p>
</li>

<li>A function has two parameters with the same composite type, and
just one of the parameters is declared using a typedef.

<p>Example:</p>

<pre>
  class T;
  typedef T x;
  // foo2 has composite (that is, pointer or array)
  // parameter types
  void foo2(T*, T*)
  void foo2(T*, x*);
  void foo2(x*, T*);
  void foo2(x*, x*);
</pre>

<p>All declarations of <tt>foo2</tt> are equivalent and should mangle
the same. However, the compiler will mangle some of them
differently. To prevent this problem, use typedefs consistently. 

<p>If you cannot use typedefs consistently, a workaround is to use
a weak symbol in the file that defines the function to equate a
declaration with its definition. For example:</p>

<p><font size=-1><tt>#pragma weak "__1_undefined_name" = "__1_defined_name"</tt></font></p>

<p><b>Note</b> -- Some mangled names are dependent on the target
architecture. (For example, <tt>size_t</tt> is <tt>unsigned</tt>
<tt>long</tt> for the SPARC V9 architecture, and <tt>unsigned</tt>
<tt>int</tt> otherwise.) In such a case, two versions of the
mangled name will be involved, one for each model. Two pragmas must
be provided, controlled by appropriate <tt>#if</tt> directives.</p>
</li>
</ul>

<p>For more information, see the <i>C++ Migration Guide</i>. To
access this guide in HTML, point your browser to <a href= 
"../../index.html"><tt>
file:/opt/SUNWspro/docs/index.html</tt></a>.</p>
</li>

<li><a name="cmake"></a><font size="+1">Using <tt>make</tt> With
Standard Library Header Files on Versions 2.6 and 7 of the Solaris
Operating Environment</font> 

<p>The standard library file names do not have "<tt>.h</tt>"
suffixes. Instead, they are named <tt>istream</tt>, <tt>
fstream</tt>, and so forth. In addition, the template source files
are named <tt>istream.cc</tt>, <tt>fstream.cc</tt>, and so
forth.</p>

<p>If, in the Solaris 2.6 or 7 operating environment, you include a
standard library header in your program, such as <tt>
&lt;istream&gt;</tt>, and your makefile has <tt>.KEEP_STATE</tt>,
you will encounter problems. For example, if you include <tt>
&lt;istream&gt;</tt>, <tt>make</tt> thinks that <tt>istream</tt> is
an executable and uses the default rules to build <tt>istream</tt>
from <tt>istream.cc</tt> resulting in very misleading error
messages. (Both <tt>istream</tt> and <tt>istream.cc</tt> are
installed under the C++ include files directory). Here are possible
workarounds:</p>

<ul>
<li>Use the <tt>-r</tt> option which disables the default <tt>
make</tt> rules. This solution may break the build process.</li>

<li>Use the <tt>dmake</tt> utility in serial mode instead of <tt>
make</tt>:<br>
<tt>dmake -m serial</tt></li>

<li>Avoid the use of <tt>.KEEP_STATE</tt>.</li>
</ul>
<p>
</li>

<li><a name="cIncorrect"></a><font size="+1">Debugging Tools
Erroneously Report Extra Leading Parameter for Member
Functions</font> 

<p>In compatability mode (<tt>-compat=4</tt>), the C++ compiler
incorrectly mangles the link names for pointers to member
functions. The consequence of this error is that the demangler, and
hence some debugging tools, like <tt>dbx</tt> and <tt>c++filt</tt>,
report the member functions as having an extra leading parameter
consisting of a reference to the class type of which the function
is a member. To correct this problem, add the flag <tt>-Qoption
ccfe -abiopt=pmfun1</tt>. Note, however, that sources compiled with
this flag may be binary incompatible with sources compiled without
the flag. In standard mode (the default mode), there is no problem
with mangled names.&nbsp;</p>
</li>

<li><a name="cUndefined"></a><font size="+1">Reference From
Template to Non-Global File-Scope Object is Not Supported</font> 
<!-- 4174997 --> 

<p> A program using templates and static objects causes link-time
errors of undefined symbols. The compiler currently does not
support reference to non-global file-scope objects from
templates</p>
</li>

<li><a name="cHeaders"></a><font size="+1">Standard Header Warning
Messages</font> 

<p>There are known problems with standard headers that cause lots
of warnings when <tt>+w</tt> is used.</p>
</li>

<li><a name="cpragma"><font size="+1"><tt>#pragma</tt> <tt>
align</tt> Inside Namespace Requires Mangled Names</font></a> 

<p>When you use <tt>#pragma align</tt> inside a namespace, you must
use mangled names. For example, in the following code, the <tt>
#pragma align</tt> statement has no effect. To correct the problem,
replace <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> in the <tt>#pragma
align</tt> statement with their mangled names.</p>

<pre>
  namespace foo {
    #pragma align 8 (a, b, c)
    static char a;
    static char b;
    static char c;
  }
</pre>
</li>

<li><a name="cctypend"><font size="+1"><tt>__ctype</tt> Not Defined
Errors</font></a> <!-- BG 4300780 --> 

<p>The Solaris 8 operating environment has a bug that can cause
"<tt>__ctype</tt> not defined" errors from the C++ compiler when
you use <tt>MB_CUR_MAX</tt> from <tt>&lt;stdlib.h&gt;</tt>.</p>

<p>The bug will be fixed in an update to the Solaris 8 operating
environment. The workaround is to include the standard header <tt>
&lt;ctype.h&gt;</tt> as well as the header <tt>
&lt;stdlib.h&gt;</tt>.</p>
</li>
</ol>

<p>&nbsp;</p>

<hr>
<a name="limitations"></a><font size="+2">E. Limitations and
Incompatibilities</font> 

<p><font size="+1">1. C++ Shared Library Patch</font></p>

<p>A SUNWlibC patch is provided for each version of the Solaris
Operating Environment supported by this Sun WorkShop 6 update 1
release on each of the supported platforms. Without these patches,
some programs will not link and some programs will terminate in
unusual ways due to runtime errors.</p>

<p>For information about required and optional patches for 
      this Sun WorkShop 6 update 1 release, 
      see the <i>Sun WorkShop 6 update 1 Release Notes</i>. 
      The release notes are available as a text file on the Forte
      Developer 6 update 1 CD at <tt>
      /cdrom/devpro_v8n1_&lt;platform&gt;/release_notes.txt</tt> (where
      <tt>&lt;platform&gt;</tt> is either <tt>sparc</tt> or <tt>intel</tt>).
      The release notes are also
      available in HTML on the <a href=
      "http://www.sun.com/forte/developer/hotnews.html"> Forte Developer
      Products Hot News</a> page at <tt>
      http://www.sun.com/forte/developer/hotnews.html</tt>.<p>
<p>&nbsp;</p>

<p><font size="+1">2. Compiler Version Incompatibilities</font></p>

<p>The remainder of this section discusses the incompatibilities
between Sun WorkShop C++ compiler versions 4.0, 4.1, 4.2, and the
following versions:</p>

<blockquote>
<ul>
<li>Sun WorkShop C++ compiler 5.0</li>

<li>Sun WorkShop 6 C++ compiler 5.1</li>

<li>Sun WorkShop 6 update 1 C++ compiler 5.2</li>
</ul>
</blockquote>

<ol type="a">
<li><a href="#cachedifferences">Cache Version Differences May Cause
Compilation Errors</a></li>

<li><a href="#interface">C++ Interface Incompatibilities</a></li>

<li><a href="#iostreams">Using Tools.h++ With <tt>
iostreams</tt></a></li>

<li><a href="#using">Using Multiple Template Repositories; <kbd>
-ptr</kbd> Option Ignored</a></li>

<li><a href="#incompatible">Linking With 4.0.1 Libraries Containing
Pointers to <kbd>const</kbd> Member Functions</a></li>

<li><a href="#unparsable">Linking With Libraries Compiled With
Earlier Compilers</a></li>

<li><a href="#compat">Mixing Object Code From Different
Versions</a></li>
</ol>

&nbsp;<br>
&nbsp; 

<ol type="a">
<li><a name="cachedifferences"></a><font size="+1">Cache Version
Differences May Cause Compilation Errors</font>
<p>When upgrading compilers, it is always good practice to run <tt>
CCadmin -clean</tt> on every directory that contains a <tt>
SunWS_cache</tt> subdirectory (alternately, you can use <tt>rm -rf
SunWS_cache</tt>). Failure to do so can result in compilation
errors such as the following:</p>

<font size=-1>

<ul>
<li><tt>SunWS_cache: Error: Database version mismatch<br>
&lt;path&gt;/SunWS_cache/CC_version.
</tt>
<p>
</li>

<li>
<tt>
"&lt;path&gt;/SunWS_cache/CC_state",<br>
line 3: Error: "" not allowed here.
** Assertion ** : 0 
</tt>
<p>
</li>
</ul>
</font>
<p>
</li>

<li><a name="interface"></a><font size="+1">C++ Interface
Incompatibilities</font> 

<p>The Sun WorkShop 6 C++ compiler (5.1) and the Sun WorkShop 6
update 1 C++ compiler (5.2) are not binary compatible with versions
4.0, 4.1, and 4.2 of the C++ compiler unless the <tt>-compat</tt>
option is used when compiling with the 5.1 or 5.2 compiler. The
incompatibility is due to the changes in the class layouts, the
calling sequences, and the way names are mangled to meet the
requirements defined in the ANSI/ISO C++ Standard.</p>

<p>The Sun WorkShop 6 update 1 C++ compiler (5.2), the Sun WorkShop
6 C++ compiler (5.1) and the Sun WorkShop C++ compiler 5.0 are
binary compatible.</p>

<p>See the <i>C++ Migration Guide</i> for more information. To
access this document in HTML, point your browser to <a href= 
"../../index.html"><tt>
file:/opt/SUNWspro/docs/index.html</tt></a>.</p>
</li>

<li><a name="iostreams"></a><font size="+1">Using Tools.h++ With
<tt>iostreams</tt></font> 

<p> The C++ compiler now uses standard iostreams as the default.
However, Tools.h++ version 7 is built with classic iostreams. If
you use Tools.h++ in standard mode, you must include <kbd>
libiostream</kbd> as shown in the following compiler option:</p>

<pre>
  -library=rwtools7,iostream
</pre>

<p>See the <i>C++ Migration Guide</i> for more information. To
access this guide in HTML, point your browser to <a href= 
"../../index.html"><tt>
file:/opt/SUNWspro/docs/index.html</tt></a>.</p>
</li>

<li><a name="using"></a><font size="+1">Using Multiple Template
Repositories; <tt>-ptr</tt> Option Ignored</font> 

<p>In compilers prior to C++ compiler 5.0, the <tt>-ptr</tt> flag
was used to designate repositories for template instantiations.
With the 5.0, 5.1, and 5.2 versions of the C++ compiler, the <tt>
-ptr</tt> flag is no longer required, as the compilation system
reads from the template repositories corresponding to the object
files that it reads, and writes template instances into the
repository contained in the directory of the output location
specified by the CC command.</p>

<p> In this release, the <tt>-ptr</tt> option is obsolete and is
ignored by the compiler. Even though the option is ignored, you
should remove <tt>-ptr</tt> from all compilation commands because,
in a later release, it may be reimplemented with a different
behavior.</p>

<p><b>Note --</b> Sharing a single template repository for more
than one application or library has not been and is currently not
supported. Attempting to do so can lead to compilation failure and
unpredictable results at runtime because of template
redefinitions.</p>
</li>

<li><a name="incompatible"></a><font size="+1">Linking With 4.0.1
Libraries Containing Pointers to <kbd>const</kbd> Member
Functions</font> 

<p>The C++ 4.0.1 compiler generated different mangled names for
pointers to <tt>const</tt> member functions than the C++ compiler
versions 4.1, 4.2, 5.0, 5.1, and 5.2 do. If you are using the Sun
WorkShop 6 C++ compiler and you are unable to link with a library
that was built with 4.0.1 and that contains such names, you should
either recompile the library, or compile the rest of the program
with the <tt>-compat -Qoption ccfe -abirel=4.0.1</tt> flags.</p>

<p><b>Note --</b> Future releases may not support the <tt>
-abirel=4.0.1</tt> flag.</p>
</li>

<li><a name="unparsable"></a><font size="+1">Linking With Libraries
Compiled With Earlier Compilers</font> 

<p>The C++ 4.0.1 and C++ 4.1 compilers generated a mangled name
that was unparsable for templates instantiated with an extern "C"
function. As a consequence, debugging tools behaved incorrectly. We
have corrected the problem, but some users may be unable to link
objects that are compiled using versions 5.0, 5.1, or 5.2 of the
C++ compiler with libraries compiled with earlier compilers. This
incompatibility should be extremely rare, but in the event that it
does happen, you can either</p>

<ul>
<li>Recompile the library with the Sun WorkShop 6 update 1 C++
compiler (5.2), or</li>

<li>Compile the new objects using the Sun WorkShop 6 update 1 C++
compiler (5.2) with the <tt>-compat=4</tt> and <tt>-Qoption ccfe
-abirel=4.1</tt> flags.</li>
</ul>

<p><b>Note --</b> Future releases may not support the <tt>
-abirel=4.1</tt> flag.</p>
</li>

<li><a name="compat"></a><font size="+1">Mixing Object Code From
Different Versions</font> 

<p>You can mix object code from different versions of the
SunWorkShop C++ compiler in the same program, as long as you don't
mix compatibility-mode and standard-mode code. However, you must
link the final program using a compiler at least as new as the
newest compiler version in the mix.</p>
</li>
</ol>

<p>&nbsp;</p>

<hr>
<a name="documenation"></a><font size="+2">F. Documentation
Errata&nbsp;</font> 

<ul>
<li><b><i>C++ Migration Guide</i>.</b> Section 1.3.2 "Mixing Old and
New Binaries" says that you can mix code if no exceptions cross the
boundary, but this is not true. If you mix <tt>compat=4</tt> with
<tt>compat=5</tt> code in the same program, you can use exceptions
in the <tt>compat=4</tt> code or in the <tt>compat=5</tt> code, but
not in both. If you have exceptions in the <tt>compat=4</tt> code,
link libC before linking libCrun. If you have exceptions in the
<tt>compat5</tt> code, link libCrun before linking libC. 
<p>
</li>

<li><b><i>C++ Migration Guide</i>.</b> Section 2.3.1 "Copy Constructor"
has an invalid code fragment. Replace it with:
<pre>
  class T {
    T(const T&amp;); // private
  public:
    T();
  };
  T    f1(T t) { return t; }  // Error, can't return a T
  void f2()    { f1( T() ); } // Error, can't pass a T
</pre>
</li>

<li><b><i>C++ Migration Guide</i>.</b> Section 3.3.1 "Resolving Type Names"
has  invalid code examples. Replace the first code example with:
<pre>
  typedef int S;
  template&lt; class T &gt; class B { typedef int U; };
  template&lt; class T &gt; class C : public B&lt;T&gt; {
       S s; // OK
       T t; // OK
       U x; // 1 No longer valid
       T::V z; // 2 No longer valid
  };
</pre>
<p>Replace the paragraph below the code example with:</p>
<blockquote>
<p>The new language rules state that no base class that is
dependent on a template parameter is searched
automatically
to resolve type names in a template, and that no name coming from a
base class or template parameter class is a type name unless it
is declared to be so with the keyword <tt>typename</tt>.
</blockquote>
<p>Replace the second code example with</p>
<pre>
  typedef int S;
  template&lt; class T &gt; class B { typedef int U; };
  template&lt; class T &gt; class C : public B&lt;T&gt; {
    S s; // OK
    T t; // OK
    typename B::U x; // OK
    typename T::V z; // OK
    };
</pre>
</li>
<li><b><i>C++ Migration Guide</i>.</b> Section 3.4 "Class Name Injection"
is missing a semi-colon (<tt>;</tt>) in CODE EXAMPLE 3-2.
Replace the second-to-last line in the code example with:
<pre>
  };
</pre>
</li>

<li><b><i>C++ Migration Guide</i>.</b> Section 3.7 "String Literals
and <tt>char*</tt>" has an invalid code example. Remove the
semi-colon (<tt>;</tt>) from the first line:
<pre>
  #define GREETING "Hello world"
</pre>
</li>

<li><b><i>C++ Programming Guide</i>.</b> Section 2.1.1 
"Language-Adaptable Header Files" shows spaces in some macro names.
Replace all occurrences of "<tt>_ _STDC_ _</tt>" with "<tt>__STDC__</tt>".
Replace all occurrences of "<tt>_ _cplusplus</tt>" with "<tt>__cplusplus</tt>".
<p></li>

<li><b><i>C++ Programming Guide</i>.</b> Section 4.3.3.4
"Explicit Instantiation of Template Class Static Data members"
as an invalid code fragment. Replace it with:
<pre>
  template int String<19>::overflows;
</pre>
</li>

<li><b><i>C++ Programming Guide</i>.</b> Section 4.7.2
"Local Types as Template Arguments" has errors in CODE EXAMPLE 4-1.
In <tt>file1.cc</tt> replace the last line with:
<pre>
  Array&lt;Foo&gt; File1Data(10);
</pre>
<p>In <tt>file2.cc</tt> replace the last line with:</p>
<pre>
  Array&lt;Foo&gt; File2Data(20);
</pre>
</li>
<li><b><i>C++ Programming Guide</i>.</b> Section 5.4.3
"Specifying Exceptions to Be Thrown" has an error in
the last code example. Remove the semi-colon (<tt>;</tt>)
from the second line:
<pre>
  void f(int) throw(x)
</pre>
</li>

<li><b><i>C++ Programming Guide</i>.</b> Section 7.5.3 
"Casting Down or Across the Hierarchy" has errors in both code examples.
<p>
Add the following to the beginning of the first code example:
<pre>
#include &lt;assert.h&gt;
#include &lt;stddef.h&gt; // for NULL
</pre>
<p>Replace the second code example with:
<pre>
#include &lt;assert.h&gt;
#include &lt;stddef.h&gt; // for NULL
#include &lt;typeinfo&gt;

class A { public: virtual void f() { } };
class B { public: virtual void g() { } };
class AB : public virtual A, private B { };

void attempted_casts( )
{
    AB ab;
    B* bp  = (B*)&ab;    // C-style cast needed to break protection
    A* ap  = dynamic_cast<A*>(bp); // fails, B is inaccessible
    assert(ap == NULL);
    try {
        AB& abr = dynamic_cast<AB&>(*bp); // fails, B is inaccessible
    }
    catch(const std::bad_cast&) {
        return; // failed reference cast caught here
    }
    assert(0); // should not get here
}
</pre>
</li>
<li><b><i>C++ Programming Guide</i>.</b> Section 9.3
has an error in
the last code example. Remove the semi-colon (<tt>;</tt>)
from the first line:
<pre>
   #include &lt;rw/stdmutex.h&gt;
</pre>
</li>


<li><b><i>C++ Library Reference</i></b>. Section 2.3
"Mathematical Functions" has an error in TABLE 2-1.
Replace <tt>double ang(const complex)</tt> with
<tt>double arg(const complex)</tt>.<p></li>

<li><b><i>C++ Library Reference</i></b>. Section 3.3.9
"Handling Input Errors" has an error in the code example.
Replace <tt>#include &lt;unistd.h&gt;</tt> with
<tt>#include &lt;stdlib.h&gt;</tt>.
<p></li>

<li><b><i>C++ Library Reference</i></b>. Section 3.4.1.5
"Repositioning within a File" has an error in the first code fragment.
Add a semi-colon (<tt>;</tt>) to the end of the line:

<pre>
  enum seek_dir { beg=0, cur=1, end=2 };
</pre>
</li>

<li><b><i>C++ Library Reference</i></b>. Section 4.8
"Object Destruction" has an error in the code example.
Replace the first line of the function definition with:

<pre>
  void multi_process(const char* filename, int numthreads)
</pre>
</li>


<li><b><i>C++ User's Guide</i></b>.
In the entries for 
<b><tt>-xtarget</tt></b>, <b><tt>-xarch</tt></b>, and <b><tt>
-xchip</tt></b>, add <b><tt>generic64</tt></b>
and <b><tt>native64</tt></b> to the lists of valid values.
See the <b><tt>CC</tt></b>(1) man page for details.<p></li>
</ul>

<hr>
<a name="shippable"></a><font size="+2">G. Shippable
Libraries</font> 

<p> If your executable uses a Sun dynamic library listed in the
file named below, your license includes the right to redistribute
the library to your customer.</p>

<pre>
    <a href=
"runtime.libraries.html">&lt;install-directory&gt;/SUNWspro/READMEs/runtime.libraries</a>

</pre>

(Replace <tt>&lt;install-directory&gt;</tt> with the path to your
Sun WorkShop installation directory. In a default installation,
<tt>&lt;install-directory&gt;</tt> is <tt>/opt</tt>.) 

<p> You may not redistribute or otherwise disclose the header
files, source code, object modules, or static libraries of object
modules in any form.</p>

<p> The License to Use appears in the End User Object Code License,
viewable from the back of the plastic case containing the
CDROM.</p>

<p>&nbsp;</p>

<hr>
<a name="new"></a><font size="+2">H. New Features</font> 

<p> For information about new features, see <i>What's New in Sun
WorkShop 6 update 1</i>. This document describes the new features
in this Sun WorkShop 6 update 1 release and in the Sun WorkShop 6
release.</p>

<p> You can access this manual on your local system or network by
pointing your browser to <a href="../../index.html"><tt>
file:/opt/SUNWspro/docs/index.html</tt></a>. You can also access it
by pointing your browser to <a href="http://docs.sun.com"><tt>
http://docs.sun.com</tt></a> and searching for the Forte Developer
6 update 1 collection.</p>

<p>&nbsp;</p>

<hr>
<a name="standards"></a> <font size="+2">I. Standards Not
Implemented</font> 

<p><!-- BG 4310670 --> The C++ compiler (CC) supports the ISO
standard for C++, ISO IS 14882:1998, Programming Language C++. The
following list describes requirements in the standard that are not
supported in this release:</p>

<ul>
<li>Expressions involving non-type template parameters in the
function parameter list for function templates, such as 

<p><tt>template&lt;int I&gt; void foo(mytype&lt;2*I&gt; ) { ...
}</tt></p>
</li>

<li>Template template parameters (templates as template
parameters).<p></li>

<li>Universal character names.<p></li>
</ul>

<p>The following functions, which appeared in the 1994 Addendum to
the 1990 C standard and are included by reference in the 1998 C++
standard, are supported on versions 7 and 8 of the Solaris
operating environment, but are not supported on version 2.6. With
version 2.6 of the Solaris operating environment, the declarations
do not appear in any headers, and the functions are not available
in the Solaris run-time libraries.</p>

<blockquote>
<pre>
btowc
fwide
fwprintf
fwscanf
mbrlen
mbrtowc
mbsinit
mbsrtowcs
swprintf
swscanf
vfwprintf
vswprintf
vwprintf
wcrtomb
wcsrtombs
wcsstr
wctob
wmemchr
wmemcmp
wmemcpy
wmemmove
wmemset
wprintf
wscanf
</pre>
</blockquote>

<p>&nbsp;</p>

<hr>
<p><a href="./copyright.html">Copyright</a> 2000 Sun Microsystems,
Inc., 901 San Antonio Road, Palo Alto, CA 94303, U.S.A. All rights
reserved.&nbsp;</p>

<p>Sun, Sun Microsystems, the Sun logo, docs.sun.com, and Solaris
are trademarks, registered trademarks, or service marks of Sun
Microsystems, Inc. in the U.S. and other countries.</p>
</td>
</tr>
</table>

&nbsp;
</body>
</html>

Re: [Cppunit-devel] Re: [ cppunit-Bugs-464844 ] Comp. warnings & errors - rel 1.6.0

[Steve M. R. <ste...@vi...>]

Hi all,

Does anyone find the doxygen-generated manpages to be useful, or do
you use the HTML docs exclusively?  The issue is this: it is a bit
of a nuisance to get the manpages installed correctly, so 1.6.1
will not install them, though it does install the HTML.  I don't find
the manpages useful, so I won't make the effort to install them unless
other folks want it.  Let me know!


On Sun, Sep 30, 2001 at 04:29:28PM +0200, Baptiste Lepilleur wrote:

>   I don't remember the rules. I'm sure I read something about it somewhere.
> An alternative would be to move the nested class declaration to
> CPPUNIT_TEST_SUITE where the type is explicit available as a macro
> parameter. In fact I just did that (comitted).

Brilliant.  I expect that will work.

Thanks for the contrib/msvc files.  I modifed the makefile to put them
into the distribution.  Once you've cvs-added and cvs-committed your
FAQ file, I think we are ready to release 1.6.1.  Let me know if there
is something you want to put in.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] 1.6.1 changes

[Baptiste L. <bl...@cl...>]

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "Cpp Unit Develpment Mailing List" <cpp...@li...>
Sent: Saturday, September 29, 2001 11:19 PM
Subject: Re: [Cppunit-devel] 1.6.1 changes


> On Sat, Sep 29, 2001 at 10:39:46PM +0200, Baptiste Lepilleur wrote:
> > ----- Original Message -----
> > From: "Steve M. Robbins" <ste...@vi...>
>
> > > Since Baptiste has already expressed interest in the FAQ, I'm
> > > happy to leave that to him should he wish it; otherwise I'll throw
> > > something together at the last minute.
> >
> >   Wouldn't mean to. Though how would you organize the FAQ ?
>
> I think your three categories (windows, unix, generic) are a good
> start.  Unfortunately, I can never predict acurately which categories
> will tend to be useful.  I tend to start with a single category,
> introducing a new category when a sufficient number of related
> questions appear.
>
> Oh, and generic questions should probably be first in the list.

  I moved the WIN32 question to doc/FAQ. It's in text format for now since I
don't know how to use Doxygen to generate stuffs like a TOC, but then, there
is only 4 questions... I added a generic question (to hint at the macros...)
:

1.1) Isn't there an easier way to write unit tests than using TestCaller ?

   Yes, there is. Macros have been created to take care of the repetitive
work. Look up include/extensions/HelperMacros.h in CppUnit documentation.
Most of CppUnit test suite is also written that way since they remain
compatible as CppUnit evolve. They also use RTTI if available.

    Feel free to reword.

    Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

Re: [Cppunit-devel] Re: [ cppunit-Bugs-464844 ] Comp. warnings & errors - rel 1.6.0

[Baptiste L. <bl...@cl...>]

[...]
> > "BaseTestCase.h", line 11: Error:
> >
> > BaseTestCase::__ThisTestCaseType is not accessible
> >
> > from BaseTestCase::ThisTestCaseFactory::makeTest().
> >
> > 1 Error(s) detected.
>
> __ThisTestCaseType is a typedef, defined using the macro
> CPPUNIT_TEST_SUITE.  It is private to class BaseTestCase.
>
> So what is the rule of access to private members for a nested class?
> All the compilers other than Forte seem to allow such access.
>
> Would adding
>
>     friend class ThisTestCaseFactory;
>
> to the end of the macro CPPUNIT_TEST_SUITE_END (in
> include/cppunit/extensions/HelperMacros.h) solve the problem?

  I don't remember the rules. I'm sure I read something about it somewhere.
An alternative would be to move the nested class declaration to
CPPUNIT_TEST_SUITE where the type is explicit available as a macro
parameter. In fact I just did that (comitted).

>
> -S
>
> --
> by Rocket to the Moon,
> by Airplane to the Rocket,
> by Taxi to the Airport,
> by Frontdoor to the Taxi,
> by throwing back the blanket and laying down the legs ...
> - They Might Be Giants
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

[Cppunit-devel] Re: [ cppunit-Bugs-464844 ] Comp. warnings & errors - rel 1.6.0

[Steve M. R. <ste...@vi...>]

On Fri, Sep 28, 2001 at 12:54:36AM -0700, no...@so... wrote:
> Bugs item #464844, was opened at 2001-09-25 08:25
> You can respond by visiting: 
> http://sourceforge.net/tracker/?func=detail&atid=111795&aid=464844&group_id=11795

> Initial Comment:
> I downloaded release 1.6.0 on a unix machine with 
> 
> SunOS 5.6 and played a little with it.
> 
> 
> 
> As long as I did not change the default compiler and 
> 
> flags, everything worked fine.
> 
> 
> 
> But then I switched to Forte' 6 Upd.1 compiler and I 
> 
> got some warnings for the generation of the cppunit 
> 
> shared lib and errors when compiling the unit tests.
> 
> 
> 
> Hereafter what I did and what I got:
> 
> 
> 
> ./configure CXX=CC CXXFLAGS=-g --enable-static=no
> 
> 
> 
> make
> 
> 
> 
> ...
> 
> CC -DHAVE_CONFIG_H -I. -I. -I../../config -
> 
> I../../include -I../../include -g -c 
> 
> RepeatedTest.cpp  -KPIC -DPIC -o .libs/RepeatedTest.o
> 
> "../../include/cppunit/extensions/RepeatedTest.h", 
> 
> line 33: Warning: 
> 
> CppUnit::RepeatedTest::countTestCases hides the 
> 
> virtual function CppUnit::TestDecorator::countTestCases
> 
> () const.
> 
> "../../include/cppunit/extensions/RepeatedTest.h", 
> 
> line 33: Warning: CppUnit::RepeatedTest::toString 
> 
> hides the virtual function 
> 
> CppUnit::TestDecorator::toString() const.
> 
> 2 Warning(s) detected.


Thanks.  I'll fix these for the next release.



> make check
> 
> 
> 
> ...
> 
> Making check in cppunittest
> 
> make  cppunittestmain
> 
> source='BaseTestCase.cpp' object='BaseTestCase.o' 
> 
> libtool=no \
> 
> depfile='.deps/BaseTestCase.Po' 
> 
> tmpdepfile='.deps/BaseTestCase.TPo' \
> 
> depmode=none /bin/sh ../../config/depcomp \
> 
> CC -DHAVE_CONFIG_H -I. -I. -I../../config -
> 
> I../../include -I../../include     -g -c -o 
> 
> BaseTestCase.o `test -f BaseTestCase.cpp || 
> 
> echo './'`BaseTestCase.cpp
> 
> "BaseTestCase.h", line 11: Error: 
> 
> BaseTestCase::__ThisTestCaseType is not accessible 
> 
> from BaseTestCase::ThisTestCaseFactory::makeTest().
> 
> 1 Error(s) detected.

__ThisTestCaseType is a typedef, defined using the macro
CPPUNIT_TEST_SUITE.  It is private to class BaseTestCase.

So what is the rule of access to private members for a nested class?
All the compilers other than Forte seem to allow such access.

Would adding

    friend class ThisTestCaseFactory;

to the end of the macro CPPUNIT_TEST_SUITE_END (in
include/cppunit/extensions/HelperMacros.h) solve the problem?

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] 1.6.1 changes

[Duane M. <dua...@ma...>]

--- At Sat, 29 Sep 2001 22:39:46 +0200, Baptiste Lepilleur wrote:

>For #3 to make it in, someone
>> (Duane?)  will have to supply the relevant preprocessor symbols to
>> use.

I checked with some others about telling the difference between OS X and
OS < X. I have not been able to locate any way of telling the compile
time environments apart.

I would recommend not adding this feature until I have more information
in support of OS X.

It may be useful to add the config-mac file to the project but not
integrate it into Portability.h. A note at the top of the file would be
useful.

Just some suggestions.

..Duane

Re: [Cppunit-devel] Not equals test

[Duane M. <dua...@ma...>]

--- At Sat, 29 Sep 2001 12:39:07 -0400, Steve M. Robbins wrote:

>On Fri, Sep 28, 2001 at 04:35:13PM -0700, Duane Murphy wrote:
>> I couldnt find an equivalent to CPPUNIT_ASSERT_NOT_EQUAL. That is
>> checking to make sure that some value was NOT some other value. I found
>> this useful in checking error conditions where you want to make sure that
>> the normal non-error condition is NOT returned. Pretty much any other
>> error is fine.
>> 
>> If there is a technique for doing this, please let me know.
>
>In my case, I just use
>
>	CPPUNIT_ASSERT( a != b );

That's of course true, but I like the additional output from
CPPUNIT_ASSERT_EQUAL. Its useful to know what was or was not equal.

..Duane

Re: [Cppunit-devel] 1.6.1 changes

[Steve M. R. <ste...@vi...>]

On Sat, Sep 29, 2001 at 10:39:46PM +0200, Baptiste Lepilleur wrote:
> ----- Original Message -----
> From: "Steve M. Robbins" <ste...@vi...>

> > Since Baptiste has already expressed interest in the FAQ, I'm
> > happy to leave that to him should he wish it; otherwise I'll throw
> > something together at the last minute.
> 
>   Wouldn't mean to. Though how would you organize the FAQ ?

I think your three categories (windows, unix, generic) are a good
start.  Unfortunately, I can never predict acurately which categories
will tend to be useful.  I tend to start with a single category,
introducing a new category when a sufficient number of related
questions appear.

Oh, and generic questions should probably be first in the list.


> > To aid the FAQ compiler, it would be helpful to send in candidate
> > questions and answers.  Perhaps those of you who just joined us
> > recall one or two large stumbling blocks?  Or those of you reading
> > the user- and help- forums see questions coming up over and over?
> >
> > Similarly, corrections and additions to other bits of docs would be
> > greatly appreciated!  In particular, the intro page (cppunit.sf.net)
> > cookbook need work.  Learning to use CppUnit was quite troublesome in
> > my experience, so this is one area that should get extra attention, I
> > feel.
>     I skimmed through the cookbook and I noticed that the macros are never
> evoked. I think that the macros are actually the fastest way to get started
> with CppUnit

I agree.  I was a little annoyed to learn about the macros *after*
having plowed through their cumbersome alternatives.


>     Oh, by the way, I have those nifty Workspace Whiz template that allow
> the owner of that add-ins to create a new test case class and had it to the
> project in a few mouse click. Where should I put it in the CppUnit dist ? I
> was thinking of contrib/msvc/.

That sounds fine.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] 1.6.1 changes

[Baptiste L. <bl...@cl...>]

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "Cpp Unit Develpment Mailing List" <cpp...@li...>
Sent: Saturday, September 29, 2001 8:28 PM
Subject: [Cppunit-devel] 1.6.1 changes


> On Thu, Sep 27, 2001 at 02:59:04PM +0200, Baptiste Lepilleur wrote:
> > Quoting "Steve M. Robbins" <ste...@vi...>:
>
> > > Well, so far, we aren't exactly inundated with bug reports.  So making
> > > the change at the end of next week is probably fine.
> > >
> > > At any rate, ONCE the branch is made, the idea is to merge 1.6.x
> > > bugfix changes to the main trunk (if applicable) as you do them.
> > > Any delay of the merge just makes it more complicated.
> >
> >   Well, I was thinking about a slighlty tighter time schedule :-)
> >   - have the branch made this week-end, and
> >   - release 1.8.0 by the end of next week-end...
>
> Ah, I had originally misunderstood your timetable.
>
> OK, I have time this weekend to do 1.6.1, and then I'll make the branch
> at that point.  Deal?
    Sound good to me.

> So the question becomes: what can we reasonably include in 1.6.1?
> The changes I'd like to make are the following
>
> 1. Fix the doc file to include cookbook.html.
> 2. Eliminate the repeated includes pointed out by Bob S.
> 3. Include the (non-OSX) mac config.
> 4. Include an FAQ available both in the sources and via the web.
> 5. Updated docs, especially the intro/cookbook.

  I also comitted a little while ago the TestCallerTest fix (nothing major).

> I can certainly do #1 and #2 myself.  For #3 to make it in, someone
> (Duane?)  will have to supply the relevant preprocessor symbols to
> use.  Since Baptiste has already expressed interest in the FAQ, I'm
> happy to leave that to him should he wish it; otherwise I'll throw
 > something together at the last minute.

  Wouldn't mean to. Though how would you organize the FAQ ?

    I can think of 3 sections should come out:
- Windows specifics
    Well, we already have 3 questions compiled from FAQ on the forum. More
are welcome.

- Unix specifics (would this includes Mac OS X?)
    I'm the dumb boy there here. How to I build the examples, where do I
found the executable of the build samples...

- Generic
    Where is the XML output ? ;-)

> To aid the FAQ compiler, it would be helpful to send in candidate
> questions and answers.  Perhaps those of you who just joined us
> recall one or two large stumbling blocks?  Or those of you reading
> the user- and help- forums see questions coming up over and over?
>
> Similarly, corrections and additions to other bits of docs would be
> greatly appreciated!  In particular, the intro page (cppunit.sf.net)
> cookbook need work.  Learning to use CppUnit was quite troublesome in
> my experience, so this is one area that should get extra attention, I
> feel.
    I skimmed through the cookbook and I noticed that the macros are never
evoked. I think that the macros are actually the fastest way to get started
with CppUnit (especially on VC++ where you can have VC++ macro or add-ins
generating most of the code for you).

    That's how I'm introducing CppUnit at work. I present a Fixture, and
show how to add tests and what are the macro available to write assertions.
How a suite is created for the fixture and where you can find it in the
TestRunner. That way you can start using the framework without having to
understand it. Face it, most of the guys don't really care how CppUnit
works. They just want it to make their life easier.

    They might want to start understanding the whole thing when they want to
write attipical test (functionnal test), or reach the limit of CppUnit and
want to enhance it...

    Of course, I don't think that "for tomorow TODO".

    Oh, by the way, I have those nifty Workspace Whiz template that allow
the owner of that add-ins to create a new test case class and had it to the
project in a few mouse click. Where should I put it in the CppUnit dist ? I
was thinking of contrib/msvc/.

> Are there other items to include in 1.6.1 that can be done today or
> tomorrow (especially on the non-unix side)?

    Well, I actually got a bug report (somewhat MFC don't open the right
dialog when browsing the unit test). I'll try to reproduce it before
attempting solving it. Since it's MFC black magic and I'm not really an
expert in that area, I don't expect a quick resolution. I'll have to
reproduce the bug first.

>
> -Steve
>
> P.S.  Don't worry about the short deadlines.  We can make 1.6.2 at any
> time.
>
>
> >   By the way, has xprogramming.org been contacted, the page haven't been
> > updated ?
>
> Not by me.  I'm only handling the SF release process (and I'm going to
> do the next Debian release, too).  Baastien said he did a freshmeat
> announcement.  I don't know of any other channels.  I'd suggest: if
> you know of a community of potential interest then make the
> announcement and let us on cppunit-devel know.

    Ok. I'll contact Ron...

    Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

[Cppunit-devel] 1.6.1 changes

[Steve M. R. <ste...@vi...>]

On Thu, Sep 27, 2001 at 02:59:04PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:

> > Well, so far, we aren't exactly inundated with bug reports.  So making
> > the change at the end of next week is probably fine.
> > 
> > At any rate, ONCE the branch is made, the idea is to merge 1.6.x
> > bugfix changes to the main trunk (if applicable) as you do them.
> > Any delay of the merge just makes it more complicated.
> 
>   Well, I was thinking about a slighlty tighter time schedule :-)
>   - have the branch made this week-end, and 
>   - release 1.8.0 by the end of next week-end...

Ah, I had originally misunderstood your timetable.

OK, I have time this weekend to do 1.6.1, and then I'll make the branch
at that point.  Deal?

So the question becomes: what can we reasonably include in 1.6.1?
The changes I'd like to make are the following

1. Fix the doc file to include cookbook.html.
2. Eliminate the repeated includes pointed out by Bob S.
3. Include the (non-OSX) mac config.
4. Include an FAQ available both in the sources and via the web.
5. Updated docs, especially the intro/cookbook.

I can certainly do #1 and #2 myself.  For #3 to make it in, someone
(Duane?)  will have to supply the relevant preprocessor symbols to
use.  Since Baptiste has already expressed interest in the FAQ, I'm
happy to leave that to him should he wish it; otherwise I'll throw
something together at the last minute.

To aid the FAQ compiler, it would be helpful to send in candidate
questions and answers.  Perhaps those of you who just joined us
recall one or two large stumbling blocks?  Or those of you reading
the user- and help- forums see questions coming up over and over?

Similarly, corrections and additions to other bits of docs would be
greatly appreciated!  In particular, the intro page (cppunit.sf.net)
cookbook need work.  Learning to use CppUnit was quite troublesome in
my experience, so this is one area that should get extra attention, I
feel.

Are there other items to include in 1.6.1 that can be done today or
tomorrow (especially on the non-unix side)?  

-Steve

P.S.  Don't worry about the short deadlines.  We can make 1.6.2 at any
time.


>   By the way, has xprogramming.org been contacted, the page haven't been 
> updated ?

Not by me.  I'm only handling the SF release process (and I'm going to
do the next Debian release, too).  Baastien said he did a freshmeat
announcement.  I don't know of any other channels.  I'd suggest: if
you know of a community of potential interest then make the
announcement and let us on cppunit-devel know.

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] TestRegistry?

[Baptiste L. <bl...@cl...>]

The TestRegistry component usage was not well defined. It also had some
portability problems (rely on order of static variable initialization in
different code units). It also only allowed to register instantiated Test,
which was not compatible with the MFC TestRunner which assumes ownership of
the test to run.

It has been replaced by TestFactoryRegistry which solved those previous
problem, and added some others features (a test can be registered in a
specific suite).

TestRegistry should have been removed since it has fallen into obsolescence.

Baptiste.


----- Original Message -----
From: "Duane Murphy" <du...@us...>
To: "CppUnit Developers" <cpp...@li...>
Sent: Friday, September 28, 2001 4:50 AM
Subject: Re: [Cppunit-devel] TestRegistry?


> --- At Thu, 27 Sep 2001 19:38:11 -0700, Duane Murphy wrote:
>
> >I have been looking through the sources of CppUnit learning my way around
> >the system.
> >
> >I found that TestRegistry seems pretty stand-alone. No one else seems to
> >reference it.
> >
> >What is the future and the direction of TestRegistry or did I miss
something?
>
> Well, I guess I can partially answer this question. TestRegistry looks to
> have been removed from TestSuite and TestCase (as per the ChangeLog).
>
> Being new to CppUnit, I am wondering why?
>
> ..Duane
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

Re: [Cppunit-devel] Not equals test

[Steve M. R. <ste...@vi...>]

On Fri, Sep 28, 2001 at 04:35:13PM -0700, Duane Murphy wrote:
> I couldnt find an equivalent to CPPUNIT_ASSERT_NOT_EQUAL. That is
> checking to make sure that some value was NOT some other value. I found
> this useful in checking error conditions where you want to make sure that
> the normal non-error condition is NOT returned. Pretty much any other
> error is fine.
> 
> If there is a technique for doing this, please let me know.

In my case, I just use

	CPPUNIT_ASSERT( a != b );

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

[Cppunit-devel] Not equals test

[Duane M. <du...@us...>]

I couldnt find an equivalent to CPPUNIT_ASSERT_NOT_EQUAL. That is
checking to make sure that some value was NOT some other value. I found
this useful in checking error conditions where you want to make sure that
the normal non-error condition is NOT returned. Pretty much any other
error is fine.

If there is a technique for doing this, please let me know.

In light of not finding something I added this macro which might be a
useful addition to CppUnit. (This should look very familiar. I think I
changed two characters :-):

namespace CppUnit
{
	namespace TestAssert
	{
	    template <class T>
	    void assertNotEqual( const T& expected,
	                       const T& actual,
	                       long lineNumber = Exception::UNKNOWNLINENUMBER,
	                       std::string fileName = Exception::UNKNOWNFILENAME )
	    {
	      if ( assertion_traits<T>::equal(expected,actual) ) // lazy
toString conversion...
	      {
	        assertNotEqualImplementation(
assertion_traits<T>::toString(expected),
	                                      assertion_traits<T>::toString(actual),
	                                      lineNumber, 
	                                      fileName );
	      }
	    }
	}
#define CPPUNIT_ASSERT_NOT_EQUAL(expected,actual)\
  (CppUnit::TestAssert::assertNotEqual ((expected),\
    (actual),__LINE__,__FILE__))
}

..Duane

RE: [Cppunit-devel] Re: [cppunit - Open Discussion] RE: Why Syste m Includes?

[Baptiste L. <gai...@fr...>]

Quoting "Summerwill, Bob" <BSu...@eu...>:

> >> I'd also like to tone this down a bit.  In fact, the difference
> >> between <header> and "header" is system-dependent
> >>   <http://www.eskimo.com/~scs/C-faq/q10.8.html>.  
> >> But it still seems to me that <cppunit/foo> is the correct choice
> in
> >> this case.  Other "3rd party" libs, like Qt and Gtk use <>-style
> includes.
> 
> Thanks for the reference.  I was about to ask if you could elaborate on
> the
> difference between the two types of #includes.  It had always been my
> understanding that <> tried the include paths, and that "" tried the
> same directory as the file doing the include, then did the standard
> search -
> but I (incorrectly) thought that this behaviour was guaranteed.
> 
> Out of interest, does anyone know which compilers don't implement this
> "normal" behaviour?  I know that GCC and MSVC++ are both "standard"
> in this respect.

  Actually the standard behavior ( quoted form search file in 'parent' file ) 
must be rather standard because RogueWave is using it in Thread++.

  That FAQ also omit another weird behavior of the quoted form (at least for 
VC++) that lead to no end of trouble when you are using "../". The quoted form 
search the parent file directory, but also the grand-parent file directory, ...

  For example:

  Content of file /1.cpp:
  #include "sub/2.h"

  Content of file /sub/2.h:
  #include "3.h"

  Content of file /3.h:
  <no more include>

  Compiling /1.cpp will succeed in spite of the fact that 3.h is not in the sub 
directory, because 3.h is in the directory of the grand-parent including file : 
1.cpp include sub/2.h which include 3.h (at least according to VC++ rules).

  This lead to the fact that the include might work in a given context and not 
in another one. That is why I said that "../" should not be used. You can 
easily forget one level of ".." and have it working because of the location of 
some including files.

  I think acceptable forms for CppUnit would be (I take 
cppunit/extensions/HelperMacros.h as an example again):

#include <cppunit/Portability.h>
#include <cppunit/extensions/AutoRegisterSuite.h>
#include <cppunit/extensions/TestSuiteBuilder.h>
#include <string>

-- or --  
#include <cppunit/Portability.h>
#include "AutoRegisterSuite.h"
#include "TestSuiteBuilder.h"
#include <string>

While the second form lead to file include filename resolution (the 
preprocessor look straight at the right place, that is the current directory), 
it is less safer than the first form (which is unambigous). The second form 
also implies that you have a stable include directory structure (it depends on 
the location of the current file), which is not our case.

So let's stick to what we are doing for now.

Baptiste.

---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French

RE: [Cppunit-devel] Re: [cppunit - Open Discussion] RE: Why Syste m Includes?

[Summerwill, B. <BSu...@eu...>]

>> I'd also like to tone this down a bit.  In fact, the difference
>> between <header> and "header" is system-dependent
>>   <http://www.eskimo.com/~scs/C-faq/q10.8.html>.  
>> But it still seems to me that <cppunit/foo> is the correct choice in
>> this case.  Other "3rd party" libs, like Qt and Gtk use <>-style
includes.

Thanks for the reference.  I was about to ask if you could elaborate on the
difference between the two types of #includes.  It had always been my
understanding that <> tried the include paths, and that "" tried the
same directory as the file doing the include, then did the standard search -
but I (incorrectly) thought that this behaviour was guaranteed.

Out of interest, does anyone know which compilers don't implement this
"normal" behaviour?  I know that GCC and MSVC++ are both "standard"
in this respect.


Cheers,
Bob

-----Original Message-----
From: Steve M. Robbins [mailto:ste...@vi...]
Sent: 28 September 2001 03:17
To: CppUnit Development
Subject: Re: [Cppunit-devel] Re: [cppunit - Open Discussion] RE: Why
System Includes?


On Thu, Sep 27, 2001 at 11:00:40AM -0400, Steve M. Robbins wrote:
> On Thu, Sep 27, 2001 at 07:43:57AM -0700, no...@so... wrote:

> > For the cpp file it is ok. #include <filename> states that include path
indicate
> > with /I option are search first, then those of the environment variable.
> 
> Careful -- you're getting into system-dependent behaviour here!
> I've never met a C compiler that used an environment variable to change
> the header include path!

I take this back.  GCC does pay attention to some environment variables.
On the other hand, I've never seen them in use.


> All the headers in include/cppunit *must* include the other headers
> using <cppunit/...> notation.

I'd also like to tone this down a bit.  In fact, the difference
between <header> and "header" is system-dependent
  <http://www.eskimo.com/~scs/C-faq/q10.8.html>.  
But it still seems to me that <cppunit/foo> is the correct choice in
this case.  Other "3rd party" libs, like Qt and Gtk use <>-style includes.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] config-mac

[Duane M. <du...@us...>]

--- At Thu, 27 Sep 2001 22:55:39 -0400, Steve M. Robbins wrote:

>On Thu, Sep 27, 2001 at 07:46:13PM -0700, Duane Murphy wrote:
>> I have started a port of CppUnit to the Macintosh. Actually the basic
>> stuff (no GUI) works just find. But it does need a config file (Mac's
>> dont have autoconfig :-).
>
>Which brand of Mac are we speaking of?  
>The Mac OSX *can* and *should* run the configure script.
>
>
>> I made the following change to Portablity.h as well"
>> 
>> /* include platform specific config */
>> #if defined(__BORLANDC__)
>> #    include <cppunit/config-bcb5.h>
>> #elif defined (_MSC_VER)
>> #    include <cppunit/config-msvc6.h>
>> #elif defined(macintosh)
>                ^^^^^^^^^
>Does a Mac OSX system define this?  If so, we need something more specific.

You are of course correct. This is for non-Mac/OS X. I'll have to dig
further to workout how to tell the difference.

..Duane

Re: [Cppunit-devel] config-mac

[Steve M. R. <ste...@vi...>]

On Thu, Sep 27, 2001 at 07:46:13PM -0700, Duane Murphy wrote:
> I have started a port of CppUnit to the Macintosh. Actually the basic
> stuff (no GUI) works just find. But it does need a config file (Mac's
> dont have autoconfig :-).

Which brand of Mac are we speaking of?  
The Mac OSX *can* and *should* run the configure script.


> I made the following change to Portablity.h as well"
> 
> /* include platform specific config */
> #if defined(__BORLANDC__)
> #    include <cppunit/config-bcb5.h>
> #elif defined (_MSC_VER)
> #    include <cppunit/config-msvc6.h>
> #elif defined(macintosh)
                ^^^^^^^^^
Does a Mac OSX system define this?  If so, we need something more specific.

> #	include <cppunit/config-mac.h>
> #else
> #    include <cppunit/config-auto.h>
> #endif

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] TestRegistry?

[Duane M. <du...@us...>]

--- At Thu, 27 Sep 2001 19:38:11 -0700, Duane Murphy wrote:

>I have been looking through the sources of CppUnit learning my way around
>the system.
>
>I found that TestRegistry seems pretty stand-alone. No one else seems to
>reference it. 
>
>What is the future and the direction of TestRegistry or did I miss something?

Well, I guess I can partially answer this question. TestRegistry looks to
have been removed from TestSuite and TestCase (as per the ChangeLog). 

Being new to CppUnit, I am wondering why?

..Duane

[Cppunit-devel] config-mac

[Duane M. <du...@us...>]

I have started a port of CppUnit to the Macintosh. Actually the basic
stuff (no GUI) works just find. But it does need a config file (Mac's
dont have autoconfig :-).

Here is the config-mac file I put together based on some of the other
config files.

I made the following change to Portablity.h as well"

/* include platform specific config */
#if defined(__BORLANDC__)
#    include <cppunit/config-bcb5.h>
#elif defined (_MSC_VER)
#    include <cppunit/config-msvc6.h>
#elif defined(macintosh)
#	include <cppunit/config-mac.h>
#else
#    include <cppunit/config-auto.h>
#endif

--- BEGIN config-mac.h ---

#ifndef _INCLUDE_CPPUNIT_CONFIG_MAC_H
#define _INCLUDE_CPPUNIT_CONFIG_MAC_H 1
 
/* define if library uses std::string::compare(string,pos,n) */
#ifdef CPPUNIT_FUNC_STRING_COMPARE_STRING_FIRST 
#undef CPPUNIT_FUNC_STRING_COMPARE_STRING_FIRST  1 
#endif

/* define if the library defines strstream */
#ifndef CPPUNIT_HAVE_CLASS_STRSTREAM 
#define CPPUNIT_HAVE_CLASS_STRSTREAM  1 
#endif

/* Define if you have the <cmath> header file. */
#ifdef CPPUNIT_HAVE_CMATH 
#undef CPPUNIT_HAVE_CMATH
#endif

/* Define if you have the <dlfcn.h> header file. */
#ifdef CPPUNIT_HAVE_DLFCN_H 
#undef CPPUNIT_HAVE_DLFCN_H
#endif

/* define to 1 if the compiler implements namespaces */
#ifndef CPPUNIT_HAVE_NAMESPACES 
#define CPPUNIT_HAVE_NAMESPACES  1 
#endif

/* define if the compiler supports Run-Time Type Identification */
#ifndef CPPUNIT_HAVE_RTTI 
#define CPPUNIT_HAVE_RTTI  1 
#endif

/* define if the compiler has stringstream */
#ifndef CPPUNIT_HAVE_SSTREAM 
#define CPPUNIT_HAVE_SSTREAM  1 
#endif

/* Define if you have the <strstream> header file. */
#ifndef CPPUNIT_HAVE_STRSTREAM 
#define CPPUNIT_HAVE_STRSTREAM  1 
#endif

/* Name of package */
#ifndef CPPUNIT_PACKAGE 
#define CPPUNIT_PACKAGE  "cppunit" 
#endif

/* Define to 1 to use type_info::name() for class names */
#ifndef CPPUNIT_USE_TYPEINFO_NAME 
#define CPPUNIT_USE_TYPEINFO_NAME  CPPUNIT_HAVE_RTTI 
#endif

/* Version number of package */
#ifndef CPPUNIT_VERSION 
#define CPPUNIT_VERSION  "1.5.6" 
#endif
 
/* _INCLUDE_CPPUNIT_CONFIG_MAC_H */
#endif

--- END config-mac.h ---

.Duane

[Cppunit-devel] TestRegistry?

[Duane M. <du...@us...>]

I have been looking through the sources of CppUnit learning my way around
the system.

I found that TestRegistry seems pretty stand-alone. No one else seems to
reference it. 

What is the future and the direction of TestRegistry or did I miss something?

Thanks,
..Duane Murphy

Re: [Cppunit-devel] Re: [cppunit - Open Discussion] RE: Why System Includes?

[Steve M. R. <ste...@vi...>]

On Thu, Sep 27, 2001 at 11:00:40AM -0400, Steve M. Robbins wrote:
> On Thu, Sep 27, 2001 at 07:43:57AM -0700, no...@so... wrote:

> > For the cpp file it is ok. #include <filename> states that include path indicate
> > with /I option are search first, then those of the environment variable.
> 
> Careful -- you're getting into system-dependent behaviour here!
> I've never met a C compiler that used an environment variable to change
> the header include path!

I take this back.  GCC does pay attention to some environment variables.
On the other hand, I've never seen them in use.


> All the headers in include/cppunit *must* include the other headers
> using <cppunit/...> notation.

I'd also like to tone this down a bit.  In fact, the difference
between <header> and "header" is system-dependent
  <http://www.eskimo.com/~scs/C-faq/q10.8.html>.  
But it still seems to me that <cppunit/foo> is the correct choice in
this case.  Other "3rd party" libs, like Qt and Gtk use <>-style includes.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants