Re: Using C++ in GCC is OK

[Michael Veksler <mveksler at tx dot technion dot ac dot il>]

There are several C++ features which not all compilers support well,
these features should be avoided if possible.

For example VC++ 2008 treats
    struct foo{     static const int bar=1;   };

As if the coder has also written (at the same spot)
    const int foo::bar;

The consequence is multiple definitions of foo::bar which make the linker
emits an. You can force the linker to accept such duplicate symbols,
but from what I read,  not verified,  using this flag is a bad idea.

Another case:    class foo {     class bar {     }; };

Some compilers still disagree whether class bar is an implicit friend of
class foo or not.

And don't get me started on template related incompatibility of compilers.
Even passing std::set<int> to gcc GCC-4.3 may trigger seemingly unrelated
warnings, depending on code near std::set (I have commented an existing PR
showing this case).

Maybe there should be a special flag in GCC to make it more strict, such 
that
these cases will be warned about.

Michael


On 05/31/10 03:26, Mark Mitchell wrote:
> I am pleased to report that the GCC Steering Committee and the FSF have
> approved the use of C++ in GCC itself.  Of course, there's no reason for
> us to use C++ features just because we can.  The goal is a better
> compiler for users, not a C++ code base for its own sake.
>
> Before we start to actually use C++, we need to determine a set of
> coding standards that will apply to use of C++ within GCC.  At first, I
> believe that we should keep the set of C++ features permitted small, in
> part so that GCC developers not familiar with C++ are not rapidly
> overwhelmed by a major change in the implementation language for the
> compiler itself.  We can always use more of C++ later if it seems
> appropriate to do so, then.
>
> For example, I think it goes without question that at this point we are
> limiting ourselves to C++98 (plus "long long" so that we have a 64-bit
> integer type); C++0x features should not be used.  Using multiple
> inheritance, templates (other than when using the C++ standard library,
> e.g. std::list<X>), or exceptions also seems overly aggressive to me.
> We should use features that are relatively easy for C programmers to
> understand and relatively hard for new C++ programmers to misuse.  (For
> example, I think constructors and destructors are pretty easy and hard
> to misuse.)
>
> Because C++ is a big language, I think we should try to enumerate what
> is OK, rather than what is not OK.  But, at the same time, I don't think
> we should try to get overly legalistic about exactly what is in and what
> is out.  We need information guidelines, not an ISO standard.
>
> Is there anyone who would like to volunteer to develop the C++ coding
> standards?  I think that this could be done as a Wiki page.  (If nobody
> volunteers, I will volunteer myself.)  Whoever ends up doing this, I
> would urge the rest of us not to spend too much time in the C++
> coding-standards bikeshed; we're not going to win or lose too much
> because we do or do not permit default parameters.
>
>