Defining constants in classes

[Joe]

This is a very basic question, but why can't I do the following ?

class schedule {

private:
static const string mScheduleFile = "schedule.t xt";
....
}
I hope it is clear what I am trying to do. In the member functions, I then
want to "fout.open(mSch eduleFile)".
Is there way of doing this that actually works?

TIA,
Joe.

[Jonathan Turkanis]

"Joe" <an**@anon.co m> wrote in message
news:9Y******** ********@newsfe 1-gui.server.ntli .net...

This is a very basic question, but why can't I do the following ?

class schedule {

private:
static const string mScheduleFile = "schedule.t xt";
...
}

The language rules only permit in-class initialization of static const
members of integral type.

You can get the effect you're after with a static member function
returning a string or string literal, like so:

const std::string& schedule_file()
{
static const std::string file("schedule. txt");
return file;
}

or

const char* schedule_file()
{
static const char* file = "schedule.t xt";
return file;
}
Jonathan

[Alf P. Steinbach]

* "Jonathan Turkanis" <te******@kanga roologic.com> schriebt:

"Joe" <an**@anon.co m> wrote in message
news:9Y******** ********@newsfe 1-gui.server.ntli .net...

This is a very basic question, but why can't I do the following ?

class schedule {

private:
static const string mScheduleFile = "schedule.t xt";
...
}

The language rules only permit in-class initialization of static const
members of integral type.

Yes, but the OP asked why.

The answer to that seems to be "nobody knows why".

The language just turned out that way through historic accidents etc.

You can get the effect you're after with a static member function
returning a string or string literal, like so:

const std::string& schedule_file()
{
static const std::string file("schedule. txt");
return file;
}

or

const char* schedule_file()
{
static const char* file = "schedule.t xt";
return file;
}

Or the constant can be defined in the class implementation file:
============ Schedule.hpp =============

#ifndef SCHEDULE_H
#include <string>

class Schedule
{
private:
static std::string const mScheduleFile;
};
#endif
============ Schedule.cpp =============

#include <Schedule.hpp >

std::string const Schedule::mSche duleFile = "schedule.t xt";

[Joe]

Thanks for the quick reply. That works fine, but I can't help feeling it
makes things a a little "untidy".

Is that a standard solution to a standard problem?
Or am I going about the whole problem in an unusual/bad way?

Joe.
"Jonathan Turkanis" <te******@kanga roologic.com> wrote in message
news:c2******** *****@ID-216073.news.uni-berlin.de...

"Joe" <an**@anon.co m> wrote in message
news:9Y******** ********@newsfe 1-gui.server.ntli .net...

This is a very basic question, but why can't I do the following ?

class schedule {

private:
static const string mScheduleFile = "schedule.t xt";
...
}

The language rules only permit in-class initialization of static const
members of integral type.

You can get the effect you're after with a static member function
returning a string or string literal, like so:

const std::string& schedule_file()
{
static const std::string file("schedule. txt");
return file;
}

or

const char* schedule_file()
{
static const char* file = "schedule.t xt";
return file;
}
Jonathan

[Joe]

"Joe" <an**@anon.co m> wrote in message
news:Kn******** *******@newsfe1-gui.server.ntli .net...

Thanks for the quick reply. That works fine, but I can't help feeling it
makes things a a little "untidy".

Is that a standard solution to a standard problem?
Or am I going about the whole problem in an unusual/bad way?

Joe.
"Jonathan Turkanis" <te******@kanga roologic.com> wrote in message
news:c2******** *****@ID-216073.news.uni-berlin.de...

"Joe" <an**@anon.co m> wrote in message
news:9Y******** ********@newsfe 1-gui.server.ntli .net...

This is a very basic question, but why can't I do the following ?

class schedule {

private:
static const string mScheduleFile = "schedule.t xt";
...
}

The language rules only permit in-class initialization of static const
members of integral type.

You can get the effect you're after with a static member function
returning a string or string literal, like so:

const std::string& schedule_file()
{
static const std::string file("schedule. txt");
return file;
}

or

const char* schedule_file()
{
static const char* file = "schedule.t xt";
return file;
}
Jonathan

Sorry for the top-post!!

(I have never understood why that is a big deal - it makes life so much
faster if you don't have to scroll, especially for a short post like this.
If anyone has a good reason for why people don't like it, can they tell me?
I will sleep better if I know)

Joe.

[Jonathan Turkanis]

"Joe" <an**@anon.co m> wrote in message
news:Kn******** *******@newsfe1-gui.server.ntli .net...

Thanks for the quick reply. That works fine, but I can't help feeling it makes things a a little "untidy".

Is that a standard solution to a standard problem?
Or am I going about the whole problem in an unusual/bad way?

It's one standard solution. Alf gave another one. I think they're both
a bit untidy.

I tend to use the one I showed you because I write a lot of
header-only libraries.

(I' not against top-posting, as such. I think it's like always driving
on the right or left side of the road; it doesn't matter as long as
everyone does the same thing. ;-) )

Jonathan

[Pete Becker]

"Alf P. Steinbach" wrote:

* "Jonathan Turkanis" <te******@kanga roologic.com> schriebt:

"Joe" <an**@anon.co m> wrote in message
news:9Y******** ********@newsfe 1-gui.server.ntli .net...

This is a very basic question, but why can't I do the following ?

class schedule {

private:
static const string mScheduleFile = "schedule.t xt";
...
}

The language rules only permit in-class initialization of static const
members of integral type.

Yes, but the OP asked why.

The answer to that seems to be "nobody knows why".

The language just turned out that way through historic accidents etc.

The reason is that in-class initialization of static const members was
added in order to support their use as compile-time constants. Arrays of
char, floats, etc. can't be used as compile-time constants, so can't be
initialized in this way.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Julie]

Joe wrote:

Sorry for the top-post!!

(I have never understood why that is a big deal - it makes life so much
faster if you don't have to scroll, especially for a short post like this.
If anyone has a good reason for why people don't like it, can they tell me?
I will sleep better if I know)

Joe.

I agree 100%. I finally caved in, not because of the people that kept harping
on me, but because it is part of the newsgroup FAQ. Makes about as much sense
to me as arguing about indentation and brace placement... NNTP is definitely
an outdated protocol.

[Alf P. Steinbach]

* Pete Becker <pe********@acm .org> schriebt:

"Alf P. Steinbach" wrote:

* "Jonathan Turkanis" <te******@kanga roologic.com> schriebt:

"Joe" <an**@anon.co m> wrote in message
news:9Y******** ********@newsfe 1-gui.server.ntli .net...
> This is a very basic question, but why can't I do the following ?
>
> class schedule {
>
> private:
> static const string mScheduleFile = "schedule.t xt";
> ...
> }
>

The language rules only permit in-class initialization of static const
members of integral type.
Yes, but the OP asked why.

The answer to that seems to be "nobody knows why".

The language just turned out that way through historic accidents etc.

The reason is that in-class initialization of static const members was
added in order to support their use as compile-time constants.

Yes, the usefulness of compile-time constants was probably the reason
why they were allowed in this context.

Arrays of
char, floats, etc. can't be used as compile-time constants, so can't be
initialized in this way.

Nope, that does not explain why other constants are not allowed. I very
much doubt that GodAllah appeared in some committee meeting and declared
"Constants That Cannot Be Used As Compile Time Constants Are So Inherently
Evil That You Must Make Them More Difficult To Use". Instead, it seems
much more plausible that the committee used a heuristic on the lines of
"add only that which is absolutely critical, _or_ championed by VIP's".

[Pete Becker]

"Alf P. Steinbach" wrote:

* Pete Becker <pe********@acm .org> schriebt:

"Alf P. Steinbach" wrote:

* "Jonathan Turkanis" <te******@kanga roologic.com> schriebt:
>
> "Joe" <an**@anon.co m> wrote in message
> news:9Y******** ********@newsfe 1-gui.server.ntli .net...
> > This is a very basic question, but why can't I do the following ?
> >
> > class schedule {
> >
> > private:
> > static const string mScheduleFile = "schedule.t xt";
> > ...
> > }
> >
>
> The language rules only permit in-class initialization of static const
> members of integral type.

Yes, but the OP asked why.

The answer to that seems to be "nobody knows why".

The language just turned out that way through historic accidents etc.
The reason is that in-class initialization of static const members was
added in order to support their use as compile-time constants.

Yes, the usefulness of compile-time constants was probably the reason
why they were allowed in this context.

It's not probably the reason. It is the reason.

Arrays of
char, floats, etc. can't be used as compile-time constants, so can't be
initialized in this way.

Nope, that does not explain why other constants are not allowed. I very
much doubt that GodAllah appeared in some committee meeting and declared
"Constants That Cannot Be Used As Compile Time Constants Are So Inherently
Evil That You Must Make Them More Difficult To Use". Instead, it seems
much more plausible that the committee used a heuristic on the lines of
"add only that which is absolutely critical, _or_ championed by VIP's".

Phrase it however you like. Regardless, no historic [sic] accidents etc.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)