This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: is it a bug or do i miss something?(about conflicts between template parameter and data member)


Hi,

> if i made some stupid mistakes, please tell me ,3x

This is a mistake:
#include <stdio.h>

For C++ it should be:
#include <cstdio>

But the primary issue you are concerned about is this:

template <int type>
Derived<type>::Derived()
    :
    Base(type) // <-- type here refers to Base::type member variable, which has not been initialized yet and has a garbage value.
{
}

I'm not sure the syntax to make the type in the Base(type) initialization list refer to the template parameter type instead of the base class Base::type member variable.  (Other than changing the name of the template parameter from "type" to something that doesn't collide.  But that's not in the spirit of the challenge!)

I've never run into this situation before, as a side effect due to the naming conventions I use moreso than by intentional diligence.

My naming conventions look something like this (a "scoping based Hungarian notation" variant):

static int sFoo; // static variables 's' prefix
int const kFoo = 7; // constants and enums 'k' prefix
int mFoo; // struct & class member variables 'm' prefix
template <int Type_t> // Declared typedefs and template typename '_t' suffix
void Blah(int inValue); // input parameters to functions 'in' prefix
void Blah(int& outValue); // output parameters to functions 'out' prefix
void Blah(int& ioValue); // in/out parameters to functions 'io' prefix
void Blah(std::ostream& useStream); // usage parameter has 'use' prefix
#define $FOO 7 // macro constants use '$' prefix
#define FOO$($1, $2) printf($1, $2) // macro function use '$' suffix

The distinction between 'io' and 'use' is a semantic subtly.

The use of '$' character in preprocessor directives is non-standard -- although supported by every preprocessor I have ever used, and I've used many of them.  It is a way to avoid identifier collisions between the preprocessor defines and the C++ code.

The above naming convention is primarily intended to aid in code legibility and help code maintenance.  It just by happenstance avoids the situation you ran into.

There are a few other conventions that go beyond the "scoping Hungarian", such as interface classes having 'I' prefix, simple concept interface classes having 'Can' prefix, and a private 'Do' method, ala:

class CanRead
{
public:
    virtual ~CanRead() { }
    void Read(std::ostream&);
private:
    virtual void DoRead(std::ostream&) const = 0;
};

HTH,
--Eljay


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]