data members

[asdf]

data members defined after a private label are not accessible to code
that uses the class.
So, can I define the private data members as const?

[Ian Collins]

asdf wrote:

data members defined after a private label are not accessible to code
that uses the class.
So, can I define the private data members as const?

Have you tried it? Why do you think you could not?

--
Ian Collins.

[Alf P. Steinbach]

* asdf:

data members defined after a private label are not accessible to code
that uses the class.

You seem to have the right idea, roughly, but consider:

* What if after a "private:" I put a "public:" and some data member
declarations? Then they are certainly /after/ the "private:".

* What if the code that uses the class is in member functions of
the class itself?

So, can I define the private data members as const?

Yes. But generally you should only use const members for a class that's
designed to be non-copyable (less imprecisely: for a class whose
instances are non-copyable by design). Using a const or reference
member prevents ordinary assignment (the member can not be changed) but
not copy construction (the member can be copied to a new instance), and
since that's not entirely intuitive to all, it can be surprising and
thus lead to bugs.

So the simple answer is, to keep things simple, don't use const or
reference members.

On the other hand it can often be a good idea to disable copying, which
you can do (for client code) by declaring a private copy constructor and
a private copy assignment operator, like

class Foo
{
private:
Foo( Foo const& ); // No such.
Foo& operator=( Foo const& ); // No such.
public:
// Whatever.
};

Disabling copying -- non-copyable class -- removes problems with
e.g. copying handles or dynamically allocated objects "owned" by each
instance.

But it has problems of its own, e.g. with current C++, C++2003, it
prohibits passing a temporary as actual argument to a 'Foo const&'
formal argument.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[asdf]

I see, but my idea is quite simple, may I define:

class Foo
{
const int x;
public:
Foo();
};

?

Alf P. Steinbach wrote:

* asdf:

data members defined after a private label are not accessible to code
that uses the class.

You seem to have the right idea, roughly, but consider:

* What if after a "private:" I put a "public:" and some data member
declarations? Then they are certainly /after/ the "private:".

* What if the code that uses the class is in member functions of
the class itself?

So, can I define the private data members as const?

Yes. But generally you should only use const members for a class that's
designed to be non-copyable (less imprecisely: for a class whose
instances are non-copyable by design). Using a const or reference
member prevents ordinary assignment (the member can not be changed) but
not copy construction (the member can be copied to a new instance), and
since that's not entirely intuitive to all, it can be surprising and
thus lead to bugs.

So the simple answer is, to keep things simple, don't use const or
reference members.

On the other hand it can often be a good idea to disable copying, which
you can do (for client code) by declaring a private copy constructor and
a private copy assignment operator, like

class Foo
{
private:
Foo( Foo const& ); // No such.
Foo& operator=( Foo const& ); // No such.
public:
// Whatever.
};

Disabling copying -- non-copyable class -- removes problems with
e.g. copying handles or dynamically allocated objects "owned" by each
instance.

But it has problems of its own, e.g. with current C++, C++2003, it
prohibits passing a temporary as actual argument to a 'Foo const&'
formal argument.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[asdf]

Foo
{
private:
const int x;
};

error : no appropriate default constructor available

I am curious about this error, I know the constant data must be defined
(initialized).
I didn't define the constructor explicitly, but the default
constructor, which is automatically generated by the compiler, should
work.

Thanks.

Ian Collins wrote:

asdf wrote:

data members defined after a private label are not accessible to code
that uses the class.
So, can I define the private data members as const?

Have you tried it? Why do you think you could not?

--
Ian Collins.

[Ian Collins]

asdf wrote:

Please don't top-post.

Ian Collins wrote:

>>asdf wrote:

>>>data members defined after a private label are not accessible to code
that uses the class.
So, can I define the private data members as const?

Have you tried it? Why do you think you could not?

Foo
{
private:
const int x;
};

error : no appropriate default constructor available

I am curious about this error, I know the constant data must be defined
(initialized).
I didn't define the constructor explicitly, but the default
constructor, which is automatically generated by the compiler, should
work.

You must initialise a const member from an initialiser in the
constructor. There isn't another way to assign a value to a const member.

Foo
{
private:
const int x;

public:

Foo() : x(42) {}
};

--
Ian Collins.

[Nate Barney]

asdf wrote:

Foo
{
private:
const int x;
};

error : no appropriate default constructor available

I am curious about this error, I know the constant data must be defined
(initialized).
I didn't define the constructor explicitly, but the default
constructor, which is automatically generated by the compiler, should
work.

Since x is constant, you have to initialize it. Since it's a class
member, that means you have to use member initialization syntax in the
constructor.

Try:

class Foo
{
private:

const int x;

public:

// default ctor
Foo() : x(0) {}

// parameterized ctor
explicit Foo(int x) : x(x) {}
};

If I'm not mistaken, you can leave the 0 out of the initializer, because
a default-initialized int is equal to 0. Someone please correct me if
I'm wrong here.

Nate

[asdf]

Thanks. My question is, since I didn't define any constructor, the
compiler will define the default constructor, which could initialize
the data member in the default way.

I don't know why the default constructor doesn't work.

Ian Collins wrote:

asdf wrote:

Please don't top-post.

Ian Collins wrote:

>asdf wrote:

data members defined after a private label are not accessible to code
that uses the class.
So, can I define the private data members as const?
Have you tried it? Why do you think you could not?

Foo
{
private:
const int x;
};

error : no appropriate default constructor available

I am curious about this error, I know the constant data must be defined
(initialized).
I didn't define the constructor explicitly, but the default
constructor, which is automatically generated by the compiler, should
work.

You must initialise a const member from an initialiser in the
constructor. There isn't another way to assign a value to a const member.

Foo
{
private:
const int x;

public:

Foo() : x(42) {}
};

--
Ian Collins.

[Ian Collins]

asdf wrote:

Thanks. My question is, since I didn't define any constructor, the
compiler will define the default constructor, which could initialize
the data member in the default way.

I don't know why the default constructor doesn't work.

Please don't top post!

--
Ian Collins.

[Erik Wikström]

First of, don't top-post! To make my point I'll quote Alf's signature
which demonstrates why top-posting is bad.

Alf P. Steinbach wrote:

>A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

I see, but my idea is quite simple, may I define:

class Foo
{
const int x;
public:
Foo();
};

Yes, but whether it will work or not depends on what more code you have.
You have declared the Foo-constructor but not defined it, and it's the
definition of the constructor that determines if the code will work or
not. If you define it something like this:

Foo::Foo()
{ }

Then it will not work since the member x has not been initialized, the
compiler won't do this for you since it does not know what to initialize
x to, so you need:

Foo::Foo()
: x()
{ }

at the very least, more useful would be

Foo::Foo(int xin)
: x(xin)
{}

--
Erik Wikström