"static" constructor parameter confused with object name?

Discussion in 'C++' started by Joseph Turian, Sep 20, 2006.

  1. Consider this code snippet which doesn't compile:

    struct DebugOptions {
    };

    class Debug {
    public:
    Debug(const DebugOptions options) { _options = options; }

    private:
    static DebugOptions _options;
    };

    DebugOptions Debug::_options;

    main() {
    DebugOptions d;
    Debug::Debug(d);
    }

    jturian@bellini:/tmp 1$ gcc -o d d.cc
    d.cc: In function 'int main()':
    d.cc:16: error: conflicting declaration 'Debug d'
    d.cc:15: error: 'd' has a previous declaration as 'DebugOptions d'

    How can I call Debug::Debug using d as a parameter?

    Thanks,

    Joseph
    Joseph Turian, Sep 20, 2006
    #1
    1. Advertising

  2. Joseph Turian wrote:

    > Consider this code snippet which doesn't compile:
    >
    > struct DebugOptions {
    > };
    >
    > class Debug {
    > public:
    > Debug(const DebugOptions options) { _options = options; }
    >
    > private:
    > static DebugOptions _options;
    > };
    >
    > DebugOptions Debug::_options;
    >
    > main() {


    main returns int. _Always_

    > DebugOptions d;
    > Debug::Debug(d);


    You can't call a constructor directly. You can make this compile by
    changing the above line to:

    Debug temp(d);

    But this is a strange way of doing this - why are you using a
    constructor to set a static member variable anyway? Why not just use a
    static function, or better yet, just use a namespace and get rid of the
    class entirely. Are you a java programmer?

    Best regards,

    Tom
    Thomas Tutone, Sep 20, 2006
    #2
    1. Advertising

  3. Joseph Turian

    F.J.K. Guest

    Thomas Tutone wrote:
    > Joseph Turian wrote:
    >
    > > Consider this code snippet which doesn't compile:
    > >
    > > struct DebugOptions {
    > > };
    > >
    > > class Debug {
    > > public:
    > > Debug(const DebugOptions options) { _options = options; }
    > >
    > > private:
    > > static DebugOptions _options;
    > > };
    > >
    > > DebugOptions Debug::_options;
    > >
    > > main() {

    >
    > main returns int. _Always_
    >
    > > DebugOptions d;
    > > Debug::Debug(d);

    >
    > You can't call a constructor directly. You can make this compile by
    > changing the above line to:
    >
    > Debug temp(d);
    >
    > But this is a strange way of doing this - why are you using a
    > constructor to set a static member variable anyway? Why not just use a
    > static function, or better yet, just use a namespace and get rid of the
    > class entirely. Are you a java programmer?
    >
    > Best regards,
    >
    > Tom


    Hi Joseph,

    Tom already pointed out most of what is wrong. No offense meant, but
    your code looks horrible, clumsy, inexperienced, hence the Java
    question ;-) (most Java programmers tend to be conditioned into writing
    code in a somewhat object-fuscated style) Apart from that: don't use
    _options. Qualifiers with leading _ are reserved for the compiler +
    implementation.

    A quick implementation in the C++ way to do things would rather look
    like this (You don't really need the struct, but it can bew helpful if
    you want to organize different classes of debug options.):

    --- file debug.h
    namespace debug {
    struct Options {
    int a;
    };
    extern Options options;
    }

    --- file debug.cpp
    #include "debug.h"
    namespace debug {
    Options options;
    }

    --- file main.cpp
    #include "debug.h"
    int main () {
    debug::eek:ptions.a = 42;
    // Do something
    }
    F.J.K., Sep 20, 2006
    #3
  4. Joseph Turian posted:

    > Consider this code snippet which doesn't compile:
    >
    > struct DebugOptions {
    > };
    >
    > class Debug {
    > public:
    > Debug(const DebugOptions options) { _options = options; }
    >
    > private:
    > static DebugOptions _options;
    > };
    >
    > DebugOptions Debug::_options;
    >
    > main() {



    Implicit int was a feature of C89. It disappeared with C99 and also with
    C++.


    > DebugOptions d;
    > Debug::Debug(d);



    I don't know where you're getting that from -- why haven't you written the
    following:

    Debug object_name(d);

    , or if your intent was to create a nameless object:

    Debug(d);

    --

    Frederick Gotham
    Frederick Gotham, Sep 20, 2006
    #4
  5. Frederick Gotham wrote:

    > Joseph Turian posted:


    > > struct DebugOptions {
    > > };
    > >
    > > class Debug {
    > > public:
    > > Debug(const DebugOptions options) { _options = options; }
    > >
    > > private:
    > > static DebugOptions _options;
    > > };
    > >
    > > DebugOptions Debug::_options;
    > >
    > > main() {


    [snip]

    > > DebugOptions d;
    > > Debug::Debug(d);

    >
    >
    > I don't know where you're getting that from -- why haven't you written the
    > following:


    [snip]

    > , or if your intent was to create a nameless object:
    >
    > Debug(d);


    Fred, did you try compiling that? I think you mean:

    Debug(DebugOptions());

    Best regards,

    Tom
    Thomas Tutone, Sep 20, 2006
    #5
  6. Thomas Tutone posted:

    >> , or if your intent was to create a nameless object:
    >>
    >> Debug(d);

    >
    > Fred, did you try compiling that? I think you mean:
    >
    > Debug(DebugOptions());



    I should have written:

    (Debug)d;

    , as the intent is to create a nameless temporary and pass "d" as the
    argument to its constructor.

    Yet another bastard inconsistency between C and C++, all steming from "If it
    looks like a declaration, it's a declaration".

    --

    Frederick Gotham
    Frederick Gotham, Sep 20, 2006
    #6
  7. Qualifiers with leading _ [was Re: "static" constructor parameter confused with object name?]

    F.J.K. wrote:

    > Apart from that: don't use
    > _options. Qualifiers with leading _ are reserved for the compiler +
    > implementation.


    Could you please explain?
    What do you mean by qualifier, precisely?
    Using underscore anywhere, even member variables, is deprecated?

    Thanks,

    Joseph
    Joseph Turian, Sep 21, 2006
    #7
  8. F.J.K. wrote:
    > Tom already pointed out most of what is wrong. No offense meant, but
    > your code looks horrible, clumsy, inexperienced, hence the Java
    > question ;-) (most Java programmers tend to be conditioned into writing
    > code in a somewhat object-fuscated style)


    Please suggest a redesign.

    I currently have a class Debug. It is used globally to handle Debug
    output (output it to a tee'd stream), and its behavior is controlled by
    DebugOptions, which are passed in the constructor. So, it is typical to
    use Debug static methods:
    class Debug {
    static ostream& log(unsigned debuglevel);
    ...
    };
    Debug::log(3) << "Now I'm logging at to the debug log at debug level
    3.\n";

    I don't know if namespaces will work. The reason I'm using an object is
    because I want certain things output when the program terminates, and I
    do this by defining a destructor for Debug.

    Any suggestions about a less horrible, clumsy, and/or inexperienced
    approach are welcome.

    Thanks,

    Joseph
    Joseph Turian, Sep 21, 2006
    #8
  9. Joseph Turian

    Gavin Deane Guest

    Re: Qualifiers with leading _ [was Re: "static" constructor parameter confused with object name?]

    Joseph Turian wrote:
    > F.J.K. wrote:
    >
    > > Apart from that: don't use
    > > _options. Qualifiers with leading _ are reserved for the compiler +
    > > implementation.

    >
    > Could you please explain?
    > What do you mean by qualifier, precisely?
    > Using underscore anywhere, even member variables, is deprecated?


    17.4.3.1/3
    If the program declares or defines a name in a context where it is
    reserved, other than as explicitly allowed by this clause, the behavior
    is undefined.

    17.4.3.1.2/1
    Certain sets of names and function signatures are always reserved to
    the implementation:
    Each name that contains a double underscore (_ _) or begins with an
    underscore followed by an uppercase letter is reserved to the
    implementation for any use.
    Each name that begins with an underscore is reserved to the
    implementation for use as a name in the global namespace.

    So using a name (whether it be the name of a variable, function, type,
    namespace or anything else) yields undefined behaviour, which is a
    completely different concept to being deprecated.

    In your code you had a member variable called _options. As a member
    variable, it is not in the global namespace. The name exists only
    within the scope of the class. So the second part of 17.4.3.1.2/1 does
    not apply. And nothing about the first part of 17.4.3.1.2/1 applies
    either. So in this case F.J.K. was wrong and your code is fine.
    However, rather than having to remember exactly which rules apply where
    (I had to look it up again to check before I worte this post) many
    people, myself included, prefer simply to avoid leading underscores
    altogether. Note that, for example, if your member variable had been
    called _Options, the first part of 17.4.3.1.2/1 would apply and you
    would not be allowed to use that name.

    Gavin Deane
    Gavin Deane, Sep 21, 2006
    #9
  10. Joseph Turian

    Bo Persson Guest

    Re: Qualifiers with leading _ [was Re: "static" constructor parameter confused with object name?]

    Gavin Deane wrote:
    > Joseph Turian wrote:
    >> F.J.K. wrote:
    >>
    >>> Apart from that: don't use
    >>> _options. Qualifiers with leading _ are reserved for the compiler
    >>> +
    >>> implementation.

    >>
    >> Could you please explain?
    >> What do you mean by qualifier, precisely?
    >> Using underscore anywhere, even member variables, is deprecated?

    >
    > 17.4.3.1/3
    > If the program declares or defines a name in a context where it is
    > reserved, other than as explicitly allowed by this clause, the
    > behavior is undefined.
    >
    > 17.4.3.1.2/1
    > Certain sets of names and function signatures are always reserved to
    > the implementation:
    > Each name that contains a double underscore (_ _) or begins with an
    > underscore followed by an uppercase letter is reserved to the
    > implementation for any use.
    > Each name that begins with an underscore is reserved to the
    > implementation for use as a name in the global namespace.
    >
    > So using a name (whether it be the name of a variable, function,
    > type,
    > namespace or anything else) yields undefined behaviour, which is a
    > completely different concept to being deprecated.
    >
    > In your code you had a member variable called _options. As a member
    > variable, it is not in the global namespace. The name exists only
    > within the scope of the class. So the second part of 17.4.3.1.2/1
    > does
    > not apply. And nothing about the first part of 17.4.3.1.2/1 applies
    > either. So in this case F.J.K. was wrong and your code is fine.
    > However, rather than having to remember exactly which rules apply
    > where (I had to look it up again to check before I worte this post)
    > many people, myself included, prefer simply to avoid leading
    > underscores altogether. Note that, for example, if your member
    > variable had been called _Options, the first part of 17.4.3.1.2/1
    > would apply and you would not be allowed to use that name.
    >
    > Gavin Deane


    Also, using _option as the name for a member variable is not very
    useful, as we will then know that it is *either* a local variable, or
    a global implementation specific name. That makes it a pretty useless
    convention, even though it is legal.


    Bo Persson
    Bo Persson, Sep 21, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ding feng
    Replies:
    2
    Views:
    2,786
    ding feng
    Jun 25, 2003
  2. Xiangliang Meng
    Replies:
    9
    Views:
    424
    Chris Theis
    Jun 25, 2004
  3. tropos
    Replies:
    3
    Views:
    448
  4. Replies:
    4
    Views:
    4,109
    Alf P. Steinbach
    Mar 3, 2006
  5. Generic Usenet Account
    Replies:
    10
    Views:
    2,197
Loading...

Share This Page