Re: [pooma-dev] Compilation problem with gcc-3.0

[Mark Zander]

Dave,

unwrap takes an AnyType and attempts to turn it into a specific type. At 
the time I wanted to write it as a function:

        T* t = unwrap<T*>(any);

Unfortunately, that syntax wasn't available to me in the compilers we were 
using. Is that explicit function specification? Not having that available I 
templated a whole class, and with a dummy constructor could end up with 
(almost) the same syntax:

        T* t = unwrap<T*>()(any);

Later, after the code was well in place, I realized that a static member 
function would be more efficient and wouldn't rely on an optimizing 
compiler to delete the code of a dummy constructor:

        T* t = unwrap<T*>::do_it(any);

Can we just rewrite unwrap as a function and get rid of all of those dummy 
constructors as shown in the first example above?

By the way your example for unwrap is wrong, it should be:

template<class T>
struct unwrap
{
    T* operator()( Ptr<AnyType>) {}
};

But maybe we could rewrite it as:

template<class T>
T* unwrap(Ptr<AnyType>) {}

Please stop by my office some time so we can finish hashing this out. Even 
though an improved compiler will compile this awkward construct, the 
compiler features are available such that we can eliminate the awkward 
construct altogether.

Mark


At 01:55 PM 6/27/2001 -0600, Dave Nystrom wrote:
> Hi Mark,
>
> John and I have been doing a little work to try and compile our stuff with
> gcc-3.0 which just came out.  We have been able to compile Pooma 2
> successfully with gcc-3.0 and several people on the Pooma 2 support contract
> are using it - so, we are optimistic about our chances.  Last night we ran
> into a problem in TecFramework for which John was able to contrive a
> workaround.  The message below which I am bouncing to you I sent to Mark
> Mitchell and the pooma-dev mailing list.  Also, below, I have included Mark
> Mitchell's response in which he offers another workaround.  So, there are two
> workarounds to this ubiquitous construct that TecFramework uses.  We don't
> really understand Mark's workaround but it is a one liner versus our two
> liner.  Assuming it really works, John says that it would be easier to go
> back and change the one liner than the two liner when gcc-3.1 is released.
> Anyway, what do you and Sid think is the best way to resolve this problem.
> We are very interested in being able to build and run with gcc if possible.
>
> Dave Nystrom                    email: address@hidden
> LANL X-3                        phone: 505-667-7913     fax: 505-665-3046
>
> --------------------------original-message-to-mark-mitchell-------------------------------
> Below is a small test case that includes two functions, find1 and find2.
> When I try to compile this with the g++ from gcc-3.0, I get the following
> error:
>
> saltydog % make
> g++ -c -o tUnwrapKernel.o tUnwrapKernel.cc
> tUnwrapKernel.cc: In member function `void X<C>::find2(Ptr<AnyType>)':
> tUnwrapKernel.cc:33: parse error before `;' token
> make: *** [tUnwrapKernel.o] Error 1
>
> The construct in the find2 function, i.e.
> "C* pClass( unwrap<C*>()(*object) );" is ubiquitous in our TecFramework
> library package.  John Hall and I experimented last night with various
> attempts to eliminate the error by using typename, etc.  The only solution we
> found was to replace this construct with the two line construct that is in
> the find1 function.  The original construct compiles just fine with KCC-4.0
> using --strict.  Is the failure to compile a problem with gcc-3.0 or is KCC
> taking liberties that it should not.  If there is a problem with gcc, would
> it be possible to get a fix anytime soon.  We would like to get our code up
> and running with gcc but making this change in so many places in our source
> code base would be tedious and undesirable if there is really a problem with
> gcc.  Also, we do not really own TecFramework and making these changes would
> require negotiation with other people - this is not really that big of a deal
> but we would just as soon avoid it if possible.
>
> Thanks,
>
> Dave Nystrom                    email: address@hidden
> LANL X-3                        phone: 505-667-7913     fax: 505-665-3046
>
> --------------------------------test.cc---------------------------------------
> class AnyType
> {};
>
> template<class T>
> class Ptr
> {
>   public:
>     Ptr( T* inT ) : t(inT) {}
>     T* operator*() { return t; }
>
>   private:
>     T* t;
> };
>
> template<class T>
> struct unwrap
> {
>     Ptr<AnyType> operator()( T& ) {}
> };
>
> template<class C>
> class X
> {
>   public:
>     void find1( Ptr<AnyType> object )
>     {
>         unwrap<C*> myUnwrap;
>         C* pClass( myUnwrap(*object));
>     }
>
>     void find2( Ptr<AnyType> object )
>     {
>         C* pClass( unwrap<C*>()(*object));
>     }
> };
>
> ---------------------------------------mark-mitchell's-response---------------------------------------
> --On Wednesday, June 27, 2001 01:55:14 PM -0600 Dave Nystrom <address@hidden>
> wrote:
>
> > Below is a small test case that includes two functions, find1 and find2.
> > When I try to compile this with the g++ from gcc-3.0, I get the following
> > error:
>
> Yes, this is a famous problem in GCC -- it uses a YACC parser that
> doesn't have enough look-ahead to see whether or not that construct
> is a function-declaration or an expression.  We need a new parser.
>
> I've begged LANL to let me do that for years -- and they agreed!  In
> fact, what I'm working on right now, is writing a nice bright shiny new
> C++ parser -- and it aready gets this example correct.  So, I'd expect
> this to be fixed in G++ 3.1, probably ready in about 6 months.  And,
> in development snaphots before that.
>
> Besides the workaround you found, another one that usually works is:
>
>   C* pclass ((0, unwrap<C*>()(*object)));
>
> The `0' can't appear in a parameter-declaration, so g++ knows pclass
> is a variable, and not a function.