opencxx-users

Re: [Opencxx-users] Fwd: Compile error?

[Scott D. F. <sd...@cs...>]

Hi Jason,
It looks like OpenC++ doesn't recognize the "explicit" keyword. In
parser/Lex.cc, there are lines like:

Lex.cc:853:    { "inline",              token(INLINE) },
Lex.cc:887:    { "volatile",            token(VOLATILE) },

But there is nothing equivalent for "explicit".

I think I can suggest a quick/dirty fix. The "explicit" specifier is
only used with constructors to prevent implicit type conversions. I
may be wrong, but I would expect that the specifier could just be
ignored as long as the client programmer is careful not to use
implicit conversions. I'm pretty sure this could be accomplished by
adding a line as follows to the table[] definition in parser/Lex.cc
(found around line 810).

    { "explicit", token(Ignore) },

Hope this helps.
Scott


On 3/17/06, Jason Kraus <zb...@gm...> wrote:
> Seems i sent too much, lets try this again.
>
> ---------- Forwarded message ----------
> From: Jason Kraus <zb...@gm... >
> Date: Mar 17, 2006 5:15 AM
> Subject: Compile error?
> To: ope...@li...
>
> So went to compile a file like so:
>
> zbyte64 OpenMetaBase # occ2 -c
> '/root/Desktop/OpenMetaBase/MetaBaseClass.mc' --verbose
> -I/usr/include/libxml++-2.6 -I/usr/include/glibmm-2.4
> -I/usr/include/glib-2.0 -I/usr/lib/glib- 2.0/include
> -I/usr/lib/glibmm-2.4/include -o metafoo.mo
> occ2: preproc1: g++ -E -x c++ -D__opencxx -I/usr/local/include
> -I/usr/include/libxml++-2.6 -I/usr/include/glibmm-2.4
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/glibmm-
> 2.4/include /root/Desktop/OpenMetaBase/MetaBaseClass.mc -o
> MetaBaseClass.ii
> occ2: parse-and-translate: /usr/local/bin/occ --private--external-driver =
-E
> <MetaBaseClass.ii --private--output MetaBaseClass.occ.tmp 2>
> MetaBaseClass.feedback
> occ2: command failed: /usr/local/bin/occ --private--external-driver -E
> <MetaBaseClass.ii --private--output MetaBaseClass.occ.tmp
> 2>MetaBaseClass.feedback
>
> I'll attatch the files...
>
> if you look in the feedback file you get to see the following:
>  /usr/include/glibmm-2.4/glibmm/ustring.h:119: parse error before `('
> In reality its glibmm-2.8.1, and the code it is complaining about is as
> follows:
>
>  template <class T>
> class ustring_Iterator
> {
> public:
>  typedef std::bidirectional_iterator_tag iterator_category;
>  typedef gunichar value_type;
>
>  typedef std::string::difference_type difference_type;
>  typedef value_type reference;
>  typedef void pointer;
>
>
>  inline ustring_Iterator();
>  inline ustring_Iterator(const
> ustring_Iterator<std::string::iterator>& other);
>
>  inline value_type
> operator*() const;
>
>  inline ustring_Iterator<T> & operator++();
>  inline const ustring_Iterator<T>
> operator++(int);
>  inline ustring_Iterator<T> & operator--();
>  inline const ustring_Iterator<T>
> operator--(int);
>
>  explicit inline ustring_Iterator(T pos); // this is line 119
>  inline T base() const
> ;
>
> private:
>  T pos_;
> };
> Any ideas? Thx in advanced.
>
>
>

Re: [Opencxx-users] Fwd: Compile error?

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

Scott D. Fleming wrote:
> Hi Jason,
> It looks like OpenC++ doesn't recognize the "explicit" keyword. In
> parser/Lex.cc, there are lines like:
> 
> Lex.cc:853:    { "inline",              token(INLINE) },
> Lex.cc:887:    { "volatile",            token(VOLATILE) },
> 
> But there is nothing equivalent for "explicit".
> 
> I think I can suggest a quick/dirty fix. The "explicit" specifier is
> only used with constructors to prevent implicit type conversions. I

Correct.

> may be wrong, but I would expect that the specifier could just be
> ignored as long as the client programmer is careful not to use
> implicit conversions.

As far as OpenC++ is concerned it simply means that occ would accept
some code that is not valid. But since OpenC++ doesn't do any of the
related analysis anyways, this is fine.

> I'm pretty sure this could be accomplished by
> adding a line as follows to the table[] definition in parser/Lex.cc
> (found around line 810).
> 
>     { "explicit", token(Ignore) },

Right. The slightly more involved fix would be to provide a new token,
and then teach the parser how to deal with it. At first it could
ignore it, but eventually it could integrate it into the generated
parse tree. That's what I did in the synopsis parser (http://synopsis.fresco.org/),
i.e. I expect it as a regular 'function-specifier', as mandated by
the C++ specification (ISO 14882).

Regards,
		Stefan