"static" constructor parameter confused with object name?

[Joseph Turian]

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:ebug(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:ebug using d as a parameter?

Thanks,

Joseph

 

[Thomas Tutone]

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:ebug(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

 

[F.J.K.]

main returns int. _Always_


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:ptions.a = 42;
// Do something
}

 

[Frederick Gotham]

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:ebug(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);

 

[Thomas Tutone]

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:ebug(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

 

[Frederick Gotham]

Thomas Tutone posted:

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".

 

[Joseph Turian]

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]

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

 

[Gavin Deane]

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

 

[Bo Persson]

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