bug-cgicc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: cgicc compile on HP-UX 11.11 using aCC


From: JACQUOT,BRYAN (HP-FtCollins,ex1)
Subject: RE: cgicc compile on HP-UX 11.11 using aCC
Date: Mon, 21 Jan 2002 10:42:40 -0500

Hello Stephen,

I assume you got the message from the hp aCC engineer about
this problem being a defect with the aCC compiler:

--------------------------------------------------------------------

>>I am attempting to compile cgicc
>>It has to do with namespaces and an overloaded operator.

>Right, it doesn't seem to happen without operator functions.
>Though there are other more complex cases where it fails without them.

>>but rather a friend of the class, that the operator is not in the cgicc
>>namespace (even though it is defined to be in the namespace)?

>It has nothing to do with friend.

>>Is that expected behavior?

>It looks like you found the same bug as CR  JAGad73036:
>Error 419 namespace scope not applied in namespace function def outside 

--------------------------------------------------------------------

I looked at the defect report and don't see an estimated fix date.
The workaround is to add the explicit namespace qualification as
you suggested.  So I guess the only thing left is for you to decide
whether you want to add the workaround in the next release.

Please let me know.  I'll be happy to test your configure script
when you get that ready.

Thanks,

Bryan Jacquot

> -----Original Message-----
> From: Stephen F. Booth [mailto:address@hidden
> Sent: Wednesday, January 16, 2002 9:15 AM
> To: 'JACQUOT,BRYAN (HP-FtCollins,ex1)'; address@hidden
> Subject: RE: cgicc compile on HP-UX 11.11 using aCC
> 
> 
> I must admit I'm a little confused, because in FormEntry.cpp the
> following code works:
> 
> CGICCNS FormEntry& 
> CGICCNS FormEntry::operator= (const FormEntry& entry)
> {}
> 
> The only difference I can see is that this operator= is a member
> function of a class in the namespace, while in MStreamable.cpp
> operator<< is just a function in the namespace.  But why is the code
> above so different than
> 
> STDNS ostream&
> CGICCNS operator<<(STDNS ostream& out,
>       const MStreamable& obj)
> {}
> 
> ??
> 
> Why would one have access to all the data structures of a namespace
> inside a member function of a class in that namespace, but 
> not inside a
> function in that namespace?  It just doesn't add up.  I guess 
> I need to
> read about namespaces a little more.  Do you have any 
> academic knowledge
> of how this is supposed to work?
> 
> -Stephen
> 
> > -----Original Message-----
> > From: address@hidden [mailto:address@hidden On
> Behalf
> > Of JACQUOT,BRYAN (HP-FtCollins,ex1)
> > Sent: Monday, January 14, 2002 11:36 AM
> > To: 'Stephen F. Booth'; 'address@hidden'
> > Subject: RE: cgicc compile on HP-UX 11.11 using aCC
> > 
> > > -----Original Message-----
> > > From: Stephen F. Booth [mailto:address@hidden
> > > Sent: Sunday, January 13, 2002 12:35 PM
> > >
> > >
> > > > > > 2)  The MStreamable.cpp file is missing the
> > > CGICC_BEGIN_NAMESPACE,
> > > > > >     and CGICC_END_NAMESPACE macros at the beginning and
> > > end of the
> > > > > >     file.  I'm not sure why it compiles correctly with gcc,
> but
> > > the
> > > > > >     HP aCC compiler gave compiler errors without 
> these macros.
> > > > > >
> > > > > >     Here's the (HP) diff -e output to fix the problem:
> > > > > >
> > > > > > BEGIN--------------------------------------------
> > > > > > 36a
> > > > > >
> > > > > > CGICC_END_NAMESPACE
> > > > > > .
> > > > > > 26a
> > > > > > CGICC_BEGIN_NAMESPACE
> > > > > >
> > > > > > .
> > > > > > END----------------------------------------------
> > > > >
> > > > > I'm not sure that MStreamable.cpp needs to have those macros-
> > > > > my general
> > > > > approach is that in longer cpp files I will use those
> > > macros, but in
> > > > > shorter files like MStreamable I use the CGICCNS macro
> > > which usually
> > > > > expands to 'cgicc::', which should take care of the scoping.
> I'm
> > > not
> > > > > sure why it didn't work.  If you look at the
> > > pre-processed output is
> > > > > there actually a namespace qualifier in front of the
> > > > > streaming operator?
> > > >
> > > > Yes, here's (some of) the output from the preprocessor:
> > > >
> > > > #line 30
> > > >  std:: ostream&
> > > >  cgicc:: operator<<( std:: ostream& out,
> > > >  const MStreamable& obj)
> > > > {
> > > >  obj.render(out);
> > > >  return out;
> > > > }
> > > >
> > > > Here are the compile errors I get when I don't include those
> macros:
> > > > (The compiler can't find the def'n for the MStreamable class.)
> > > > And adding those name space macros fixes the problem.
> > > > I am not able to explain why.
> > >
> > > I think I've made a mistake in the code-- shouldn't the
> implementation
> > > for operator<< look like
> > >
> > > STDNS ostream&
> > > CGICCNS operator<<( STDNS ostream& out,
> > >   const CGICCNS MStreamable& obj)
> > > { ... }
> > >
> > > ??
> > >
> > > It looks like I left out the CGICCNS scoping for the
> > > MStreamable object
> > > that is being written to the stream, which I guess is necessary.
> Does
> > > this check with your understanding of C++ namespaces?  Even though
> > > operator<< is a member of the cgicc namespace, it doesn't
> > > have access to
> > > all the members of that namespace until inside the function
> > > definition.
> > > But I'm confused as to why it would work with gcc and others...
> > >
> > > -Stephen
> > 
> > 
> > Ah ha, that make sense.  Because the CGICCNS scoping was omitted
> > for the MSTreabable parameter, the compiler was looking in the
> > global namespace.  Since the .h file declares MStreamable as part
> > of the CGICCNS, it appropriately couldn't find the object's
> > definition.  I don't know how gcc is finding the type of
> > MStreamable.
> > 
> > Bryan
> > 
> > _______________________________________________
> > bug-cgicc mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/bug-cgicc
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]