opencxx-users

[Opencxx-users] Problem compiling OpenC++ on Cygwin.

[Peter C. C. <pc...@so...>]

Hello!

I'm attempting to compile OpenC++ under Cygwin on my Windows XP machine. 
The compile is failing during the processing of driver.cc with the 
following message:

/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_algobase.h: In 
function `void std::swap(_Tp&, _Tp&) [with _Tp = 
std::auto_ptr<Opencxx::MetacompilerConfiguration::IteratorIface>]': 
../opencxx/MetacompilerConfiguration.h:50:   instantiated from here
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_algobase.h:132: 
error: passing `const 
std::auto_ptr<Opencxx::MetacompilerConfiguration::IteratorIface>' as 
`this' argument of `std::auto_ptr<_Tp>::operator 
std::auto_ptr_ref<_Tp1>() [with _Tp1 = 
Opencxx::MetacompilerConfiguration::IteratorIface, _Tp = Opencxx::Meta 
compilerConfiguration::IteratorIface]' discards qualifiers

It looks like I'm trying to convert a const auto_ptr to an auto_ptr_ref 
and gcc isn't going for it. I'm using v3.4.4 and I'm wondering if 
perhaps the code was originally written for an older version of the 
compiler. Would I be better advised to use the CVS version over the 
current official version? The message above came during an attempt to 
compile v2.8.

Thanks!

Peter

Re: [Opencxx-users] Problem compiling OpenC++ on Cygwin.

[Jonathan G. <gt...@ma...>]

Peter C. Chapin wrote:

> Hello!
>
> I'm attempting to compile OpenC++ under Cygwin on my Windows XP
> machine. The compile is failing during the processing of driver.cc
> with the following message:
>
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_algobase.h: In
> function `void std::swap(_Tp&, _Tp&) [with _Tp =
> std::auto_ptr<Opencxx::MetacompilerConfiguration::IteratorIface>]':
> ../opencxx/MetacompilerConfiguration.h:50:   instantiated from here
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_algobase.h:132:
> error: passing `const
> std::auto_ptr<Opencxx::MetacompilerConfiguration::IteratorIface>' as
> `this' argument of `std::auto_ptr<_Tp>::operator
> std::auto_ptr_ref<_Tp1>() [with _Tp1 =
> Opencxx::MetacompilerConfiguration::IteratorIface, _Tp = Opencxx::Meta
> compilerConfiguration::IteratorIface]' discards qualifiers
>
> It looks like I'm trying to convert a const auto_ptr to an
> auto_ptr_ref and gcc isn't going for it. I'm using v3.4.4 and I'm
> wondering if perhaps the code was originally written for an older
> version of the compiler. Would I be better advised to use the CVS
> version over the current official version? The message above came
> during an attempt to compile v2.8.
>
> Thanks!
>
> Peter
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
Hi,

I had a similar problem when I first started using it.  Scott D. Fleming
gave me the following advice:

The problem is that in gcc 3.4.x std::auto_ptrs can't be swapped with
std::swap. I assume this is a bug in the STL, and not a feature. The
reason for the problem is that std::swap has a const tmp variable; i.e.
(from bits/stl_algobase.h):

  template<typename _Tp>
    inline void
    swap(_Tp& __a, _Tp& __b)
    {
      // concept requirements
      __glibcxx_function_requires(_SGIAssignableConcept<_Tp>)

      const _Tp __tmp = __a; // <---THIS CAUSES std::auto_ptr PROBLEMS
      __a = __b;
      __b = __tmp;
    }

And std::auto_ptr's auto_ptr_ref operator, which is called in the const
line above, is a non-const method; i.e. (from memory.h):

  template<typename _Tp>
    class auto_ptr
    {
      ...
      template<typename _Tp1>
        operator auto_ptr_ref<_Tp1>() throw()
        { return auto_ptr_ref<_Tp1>(this->release()); }
      ...

My solution to the problem was add my own swap function to the OpenC++
code, and  use it to swap std::auto_ptrs. To accomplish this, I edited
the MetacompilerConfiguration.h file in the OpenC++ source. I added this
function definition near the top of the file just under "class ErrorLog":

  template<class T>
  inline void
  MYswap(std::auto_ptr<T>& a, std::auto_ptr<T>& b)
  {
    std::auto_ptr<T> c = a;
    a = b;
    b = c;
  }

Next (in the same file), I changed class
MetacompilerConfiguration::Iterator (found in the public section of
class MetacompilerConfiguration), so that its operator= went from:

        Iterator& operator=(Iterator iter)
        {
            std::swap(impl_, iter.impl_);
            return *this;
        }

To:

        Iterator& operator=(Iterator iter)
        {
            MYswap(impl_, iter.impl_);
            return *this;
        }

And this solved the problem for me, and I expect it will for you as well.

Now, I must warn you that there is another problem you will encounter
with OpenC++ once you have built it. There is a mistake in the grammar
that OpenC++'s parser expects. Prior to GCC 3.4, this was never a
problem, but since GCC 3.4, the STL library uses the syntax that the
broken grammar doesn't accept. In particular OpenC++ expects template
declarations to look like this:

  template<typename T>...

With an identifier like "T" following typename, but in fact the
following is legal C++:

  template<typename>...

This causes occ to issue errors whenever it parses the GCC library files
that include the latter syntax (e.g., bits/cpp_type_traits.h). I fixed
the problem by changing the Parser::rTempArgDeclaration member function
definition in parser/Parser.cc. I changed this line (roughly the third
line in the function):

    if(t0 == CLASS && lex->LookAhead(1) == Identifier){

To this:

    if(t0 == CLASS && !(lex->LookAhead(1) == Identifier)){
        lex->GetToken(tk1);
        decl = PtreeUtil::List(new Leaf(tk1));
    }
    else if(t0 == CLASS && lex->LookAhead(1) == Identifier){

I am not positive that my Ptree representation for the template argument
declaration (temp.arg.declaration) is exactly what the OpenC++
maintainers would want, but it seemed to make sense to me.

Anyway, I hope these fixes help you get OpenC++ running. I've been using
it for a couple of years, and it's really a lovely tool.
Cheers, Scott

PS: There is one other fix that you will probably want to apply, found in:

    http://sourceforge.net/mailarchive/message.php?msg_id=9785370


Afterwards, it solved the compile problem but still did not work.  I had
to get his version on OpenC++ before it started working. 

Good Luck,

-- 
Jonathan Gdalevich
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: gt...@pr...

Re: [Opencxx-users] Problem compiling OpenC++ on Cygwin.

[Stefan S. <se...@sy...>]

Jonathan Gdalevich wrote:

> The problem is that in gcc 3.4.x std::auto_ptrs can't be swapped with
> std::swap. I assume this is a bug in the STL, and not a feature. The

Apparently not:

http://gcc.gnu.org/ml/libstdc++/2004-11/msg00086.html

Regards,
		Stefan

Re: [Opencxx-users] Problem compiling OpenC++ on Cygwin.

[Peter C. C. <pc...@so...>]

Jonathan Gdalevich wrote:

>I had a similar problem when I first started using it.  Scott D. Fleming
>gave me the following advice...
>  
>
Thanks for your note. The changes you made fixed the compilation issue. 
During 'make check' I get failures during the 'compilation-via-plug-in' 
tests that seem to be Cygwin related. The log file shows libtool 
complaining about undefined references in a shared library and 
explicitly says that they are not allowed under Cygwin. I imagine these 
errors are to be expected.

I'm not sure if trying to swap auto_ptrs at all is a good idea. I know 
they have strange semantics. However, I don't know all the issues. In 
any case, I'm looking forward to playing around with this system. I have 
used the Ada community's ASIS some. ASIS is a standard library that 
makes it easy for me to write analysis programs that tap into the Ada 
compiler's parse tree and symbol table information. I thought that it 
would be nice to have something like that for C++ and it seems like 
OpenC++ might be just that thing. Now if only I can find the time to play...

Peter

Re: [Opencxx-users] Problem compiling OpenC++ on Cygwin.

[Stefan S. <se...@sy...>]

Peter C. Chapin wrote:

> I'm not sure if trying to swap auto_ptrs at all is a good idea. I know 
> they have strange semantics. However, I don't know all the issues. In 
> any case, I'm looking forward to playing around with this system. I have 
> used the Ada community's ASIS some. ASIS is a standard library that 
> makes it easy for me to write analysis programs that tap into the Ada 
> compiler's parse tree and symbol table information. I thought that it 
> would be nice to have something like that for C++ and it seems like 
> OpenC++ might be just that thing. Now if only I can find the time to 
> play...

Hi Peter,

I'v been playing with the OpenC++ code for a couple of years, until
I realized that to be really useful it required a number of serious
improvements that couldn't be made incrementally.

I'm now working on synopsis (http://synopsis.fresco.org), which aims at
exactly what you are looking for: a set of APIs to introspect various
representations of the source code such as parse tree, symbol table,
or (abstract) syntax tree.
The code is based on OpenC++ (from which it forked about six years ago),
but is evolving quickly. It provides C++ and python bindings for its APIs.
Right now I'm working on a complete parser rewrite, which works similar
to the g++ parser, i.e. instead of postponing symbol table creation to
a second phase, it builds and uses the symbol table during the first
phase, to disambiguate the syntax.

The generated parse tree is similar but not identical to the one generated
by OpenC++. It aims at full ISO C++ conformance.

Just a FYI...

Regards,
		Stefan

Re: [Opencxx-users] Problem compiling OpenC++ on Cygwin.

[<se...@in...>]

On Sat, 2005-12-10 at 22:57 -0500, Stefan Seefeld wrote:

[...]

> 
> Hi Peter,
> 
> I'v been playing with the OpenC++ code for a couple of years, until
> I realized that to be really useful it required a number of serious
> improvements that couldn't be made incrementally.

Yup, that is
Opencxx must modify the used grammar to conform to the one in the
annexe of ISO standard.
- peoples are used to it
- will cure the problem with the stdc++ headers for gcc 3.4

With gcc version 4.x the problem is deeper, we require semantic
analysis. Or you must make some minor customs change to the gcc stdc++
headers.

Which are the show stopper for version 1.9

> The generated parse tree is similar but not identical to the one generated
> by OpenC++. It aims at full ISO C++ conformance.
> 
> Just a FYI...
> 
> Regards,
> 		Stefan