Anything wrong with this function?

[Anonymous]

Came across some code summarized as follows:

char const* MyClass::errToText(int err) const
{
switch (err)
{
case 0: return "No error";
case 1: return "Not enough";
case 2: return "Too much";
default: return "Unknown error";
}
}

Someone else said it was fine - was she right?

[Grizlyk]

Thomas J. Gritzan wrote:

>
void somefunction(const char* cstr)
{
char* str = const_cast<char*>(cstr);
// write to str
}

void test()
{
char arr[] = "string1";

somefunction(arr);
somefunction("string2");
}

The compiler /cannot/ test at compile time, if memory is readonly or not.
It /may/ work in one compilation unit, but it won't work across
compilation
units or from a library.

The compiler can only warn in the cases it sees the function body, but why
should it? The programmer is supposed to know when he is allowed to use a
const_cast.

Agree, but can at link time:

[quote news:eq**********@aioe.org]
- 1.cpp -
void foo ( const int &); // foo$const_int&$

void test()
{
//readonly segment
static const int i=0;
foo(i); // foo$const_int&%readonly$

//writable segment
static int k=0;
foo(i); // foo$const_int&%writable$
}
- 1.cpp -
[/quote]

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Thomas J. Gritzan]

Grizlyk schrieb:

Thomas J. Gritzan wrote:

>The compiler /cannot/ test at compile time, if memory is readonly or not.
It /may/ work in one compilation unit, but it won't work across
compilation
units or from a library.

Agree, but can at link time:

[quote news:eq**********@aioe.org]
- 1.cpp -
void foo ( const int &); // foo$const_int&$

void test()
{
//readonly segment
static const int i=0;
foo(i); // foo$const_int&%readonly$

//writable segment
static int k=0;
foo(i); // foo$const_int&%writable$
}
- 1.cpp -

[/quote]

So the compiler/linker should track every pointer where it is from?
Thats not possible at compile time:

void test()
{
std::vector<const int*intlist;

fill_list(intlist);

for (size_t i = 0; i < intlist.size(); i++)
foo(intlist[i]);
}

Why should they do that anyway? Why have /const/ and /the_true_const/ if
you can have the same with const and non-const?

--
Thomas
http://www.netmeister.org/news/learn2quote.html

[Kai-Uwe Bux]

JLS wrote:

Reasons to use const?
1. Compiler enforced, self-documenting code.
2. Allows the compiler to automatically detect some errors.

While one could argue that the use of const is of less import, the
smaller the scope of the variable, the import is never completely
eliminated. Just because you have never noticed a bug that the
compiler would have caught with the proper use of const, does not
eliminate the possibility that those bugs exist or have existed. One
type of bug that is evidently very common (as simple stupid bugs go)
is the problem with

if (a = b)

where the programmer meant comparison, rather than assignment. If a
were const, this bug shows up like a sore thumb. Of course, this isn't
the only bug that can be prevented, by the use of const, just one of
many. Other examples I've seen are when the programmer types the wrong
variable name, let's say in an assignment. Yes, it is a stupid little
bug that will eventually be discovered by unit testing or in a code
review. By why not let the compiler catch it immediately?

In my code, local variables just tend to be modified along the way. If they
were not, there was little reasons to declare them. (One prominent counter
example is mentioned below). That's why they tend to be non-const. The tiny
fraction of those that could be const because they happen not to change
will not catch significantly many errors.

I want the code to convey intent. When I declare a local variable, my intent
is in more than 99% of all cases to modify it later.

This is my argument for using const. Some number of bugs will be
caught using const. It makes the code clearer and more understandable.
There is no down side, so why not use it?

Quick question: would you do

template < typename T >
void swap ( T & lhs, T & rhs ) {
T dummy ( lhs );
lhs = rhs;
rhs = dummy;
}

or

template < typename T >
void swap ( T & lhs, T & rhs ) {
const T dummy ( lhs );
lhs = rhs;
rhs = dummy;
}
Best

Kai-Uwe Bux

[Gavin Deane]

On 6 Feb, 15:14, "Grizlyk" <[e-mail]:

Maybe, if compiler do not inline function, it could mark function using
const_cast<for its const referenced parameter as requested the reference
to be placed in writable memory, and at link stage linker will detect the
usage of readonly memory in const_cast<>. It is better than "undefined
behaviour".

I've read several of your posts recently and I think it might help
others to understand your point of view if you could distinguish
between two different situations:
1. Occasions when you are describing how you believe C++ works.
2. Occasions when you are describing how you feel some hypothetical
future version of C++ ought to work.

For the first, there is an indisputable definition in the C++ standard
and there are enough people here familiar with it that if you make a
mistake you will be corrected.
For the second, you may well find some interest here, although
comp.std.c++ is probably be more topical. But clearly in this case
there is no concept of "correcting" what you say because there is no
concrete definition of some hypothetical future version of C++.

I have responded to posts of yours in the past by attempting to
correct an apparent misunderstanding of C++ on your part, only to
discover later in the discussion that you appear to be talking not
about C++, but about some hypothetical future version of the language.
And I get the impression that some others may have found themselves in
the same situation. I think this could be avoided if you distinguish
between the two situations I've described.

Gavin Deane

[Grizlyk]

Thomas J. Gritzan wrote:

>

>>The compiler /cannot/ test at compile time, if memory is readonly or
not.
It /may/ work in one compilation unit, but it won't work across
compilation units or from a library.

Agree, but can at link time:

[quote news:eq**********@aioe.org]
- 1.cpp -
void foo ( const int &); // foo$const_int&$

void test()
{
//readonly segment
static const int i=0;
foo(i); // foo$const_int&%readonly$

//writable segment
static int k=0;
foo(i); // foo$const_int&%writable$
}
- 1.cpp -

So the compiler/linker should track every pointer where it is from?
Thats not possible at compile time:[/quote]

Not of course, do you see the message by link? Compiler for each used
variable must create compile time list of properties, and store: "access",
"write" and "const_cast<>" attempts. And compiler alredy do it (excluding
"const_cast<>"), messsages "variable declared but never used" or "possible
usage of unassigned variable" is result of the compile time tracing.

Const_cast is exactly the same. By result of compiling of block of code
compiler generates public name for function as
- "foo$const_int&%readonly$" - if const_cast was never used
- "foo$const_int&%writable$' - if const_cast was used

void test()
{
std::vector<const int*intlist;

fill_list(intlist);

"fill_list" undeclared here

>
for (size_t i = 0; i < intlist.size(); i++)
foo(intlist[i]);

assuming "foo(*intlist[i])" due to "foo" declaration

void foo ( const int &); // foo$const_int&$

Here compiler request external foo(const int&), concrete const overloading
"%writable" or "%readonly" depended from "std::vector::operator[]"
declaration only.

If "std::vector::operator[]" return "const_int&%writable" (const reference
to writeable memory) compiler will generate request to external as for
writable segment

>//writable segment
static int k=0;
foo(i); // foo$const_int&%writable$

If "std::vector::operator[]" return "const_int&%readonly" (const reference
to readonly memory) compiler will generate request to external as for
readonly segment

>//readonly segment
static const int i=0;
foo(i); // foo$const_int&%readonly$

}

Why should they do that anyway? Why have /const/ and /the_true_const/ if
you can have the same with const and non-const?

I have written about some messages ago - to support possible hadrware
memory managers - they can disable writing to readonly memory and support
many other tests "on fly", without any overhead.

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Grizlyk]

Gavin Deane wrote:

On 6 Feb, 15:14, "Grizlyk" <[e-mail]:

>Maybe, if compiler do not inline function, it could mark function using
const_cast<for its const referenced parameter as requested the
reference
to be placed in writable memory, and at link stage linker will detect the
usage of readonly memory in const_cast<>. It is better than "undefined
behaviour".

I've read several of your posts recently and I think it might help
others to understand your point of view if you could distinguish
between two different situations:
1. Occasions when you are describing how you believe C++ works.

It is true and not true.

In some place I can not prove my opinion by concrete parts of standard and
write "i think". In other places i am sure that without any "believe C++
works" C++ doing concrete things and I do not write "i think".

2. Occasions when you are describing how you feel some hypothetical
future version of C++ ought to work.

It is because of I see C++ as C++ user, not as "C++ standard cometee", so I
look to C++ from problem side (i am just trying to solve detected
difficulty) and do not try to trim myself by strange and unexplainable
standard limitations. My goal is not to prove that standard also can be
used.

This way do not contradicts to attemts to push all to pure standard, because
i do not say, that any must use properties, that can not be compiled and do
not say that the non-standard properties is standard properties.

I have responded to posts of yours in the past by attempting to
correct an apparent misunderstanding of C++ on your part, only to
discover later in the discussion that you appear to be talking not
about C++, but about some hypothetical future version of the language.

At least when people became speak about theoretical abilities of C++ (that
compiler can not do something in theory) I do not see any obstacles to speak
about "what if".

[Grizlyk]

JLS wrote:

>
This is my argument for using const. Some number of bugs will be
caught using const. It makes the code clearer and more understandable.
There is no down side, so why not use it?

Exactly. There are tons of bugs, sucsessully detected by const. Most system
even have hardware const support, because try to do const violation is just
error. Const makes parts of programs more isolated so it is easyer to
maintain. Anyway no one man wants to write into M_PI due to save memory.

For C++ const has a special meaning, const variables can be conpile time
constants if its adress never taken.

[Gavin Deane]

On 7 Feb, 21:17, "Grizlyk" <[e-mail]:

Gavin Deane wrote:

2. Occasions when you are describing how you feel some hypothetical
future version of C++ ought to work.

It is because of I see C++ as C++ user, not as "C++ standard cometee", so I
look to C++ from problem side (i am just trying to solve detected
difficulty) and do not try to trim myself by strange and unexplainable
standard limitations. My goal is not to prove that standard also can be
used.

The topic of this newsgroup is C++, as defined by the standard, with
all its limitations - strange and unexplainable or otherwise. That's
what people here know about and expect to be discussing.

I have responded to posts of yours in the past by attempting to
correct an apparent misunderstanding of C++ on your part, only to
discover later in the discussion that you appear to be talking not
about C++, but about some hypothetical future version of the language.

At least when people became speak about theoretical abilities of C++ (that
compiler can not do something in theory) I do not see any obstacles to speak
about "what if".

If that "what if" takes you outside the C++ standard, even if that
seems strange and unexplainable, consider two things:
1. Unless you make it clear that you know you are outside the
standard, you will attract responses telling you that you are, simply
because the scope of this group is the scope of the C++ standard.
2. Your discussion may be more topical in another forum (e.g comp.std.c
++) which means that you will be discussing with people who expect you
to be talking about things outside the scope of the standard - the
opposite of what people here expect.

Gavin Deane

[Grizlyk]

Gavin Deane wrote:

>
If that "what if" takes you outside the C++ standard, even if that
seems strange and unexplainable, consider two things:
1. Unless you make it clear that you know you are outside the
standard, you will attract responses telling you that you are, simply
because the scope of this group is the scope of the C++ standard.
2. Your discussion may be more topical in another forum (e.g comp.std.c
++) which means that you will be discussing with people who expect you
to be talking about things outside the scope of the standard - the
opposite of what people here expect.

Maybe you are right and sometimes people just whant to use the group as
"fast dictionary" of standard, asking what standard required for concrete
accident. It is useful application.

But where anyone can ask ordinary C++ users about possible standard
extentions? And it seems that it is hard to understand some parts of
standards without consideration bounds of standard.

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Gavin Deane]

On 8 Feb, 00:59, "Grizlyk" <[e-mail]:

Gavin Deane wrote:

If that "what if" takes you outside the C++ standard, even if that
seems strange and unexplainable, consider two things:
1. Unless you make it clear that you know you are outside the
standard, you will attract responses telling you that you are, simply
because the scope of this group is the scope of the C++ standard.
2. Your discussion may be more topical in another forum (e.g comp.std.c
++) which means that you will be discussing with people who expect you
to be talking about things outside the scope of the standard - the
opposite of what people here expect.

Maybe you are right and sometimes people just whant to use the group as
"fast dictionary" of standard, asking what standard required for concrete
accident. It is useful application.

That's a fair summary of the purpose of this newsgroup, as described
in FAQ 5.9
http://www.parashift.com/c++-faq-lit...t.html#faq-5.9

But where anyone can ask ordinary C++ users about possible standard
extentions? And it seems that it is hard to understand some parts of
standards without consideration bounds of standard.

The first two FAQs for comp.std.c++ should give you an idea whether
your question is more likely to be topical (and therefore attract more
productive discussion) there.
http://www.comeaucomputing.com/csc/faq.html

HTH
Gavin Deane

[Sylvester Hesp]

"Grizlyk" <gr******@yandex.ruwrote in message
news:eq**********@aioe.org...

JLS wrote:

>>
This is my argument for using const. Some number of bugs will be
caught using const. It makes the code clearer and more understandable.
There is no down side, so why not use it?

Exactly. There are tons of bugs, sucsessully detected by const. Most
system even have hardware const support, because try to do const violation
is just error. Const makes parts of programs more isolated so it is easyer
to maintain. Anyway no one man wants to write into M_PI due to save
memory.

I think no one here is arguing const is useless - it's all about sementics.
Declaring every local variable you never change as const, however, can be a
bridge too far. Just declaring a local var as const because it just so
happens you never change it nearly has no semantic value whatsoever. Sure
M_PI is better as const, it's a constant - you want to keep anyone from
changing it. But local short-lived temporaries which mere use is to cache a
specific calculation or complex function call? That's just a matter of
personal taste, really. For me, const in such situations don't have any
semantic meaning, I'm the only user of the variable and I'm well aware of
what I'm doing with it. It just seems arbitrary to me ("Hey, whatta ya know,
after rearranging and rewriting these statements it turns out I don't change
that temp var anymore. Let's make it const!").

As said, this is my personal opinion, and of course you are entitled to have
your own :). I'm not _discouraging_ the use of const, not even in the
situation I described above. What started this whole discussion was the
remark that you _should_ use const whenever you're not going to change a
variable. Const, from a pure C++ perspective, is not about not _going_ to
change, but about not _wanting_ to be able to change. That's a subtle
difference, and that including this being a C++ newsgroup caused my original
remark that it doesn't matter whether a function declaration declares it's
parameters as const values.

For C++ const has a special meaning, const variables can be conpile time
constants if its adress never taken.

Actually, only integral types can be compile time constants, and they are
compile-time constants no matter whether their address has been taken.

- Sylvester

[Grizlyk]

Sylvester Hesp wrote:

>
Declaring every local variable you never change as const, however, can be
a bridge too far. Just declaring a local var as const because it just so
happens you never change it nearly has no semantic value whatsoever.

Not sure what do you mean but if variable must not be changed by its logical
goal then the variable must be declared as const, in spite of "local"
status, i think must.

>For C++ const has a special meaning, const variables can be conpile time
constants if its adress never taken.

Actually, only integral types can be compile time constants, and they are
compile-time constants no matter whether their address has been taken.

No. Even integral compile-time constants will be allocated if its address
has been taken, for example

{
const int size=5;
ptintf("%s=%u is allocated to: %p\n", "size", size, &size);
}

- NOT C++ -

By the way, for some free-standing classes compiler could have const
compile-time variables of non-integral types, executing there ctor/dtor and
methods at compile time.

struct T
{
int i;
T(const int p=0):i(p){}
~T():i(p){}
};

{
const T size(5);
ptintf("%s=%u is allocated to: %p\n", "size", size.i, &size.i);
}

- NOT C++ -

[Sylvester Hesp]

"Grizlyk" <gr******@yandex.ruwrote in message
news:eq**********@aioe.org...

>
Sylvester Hesp wrote:

>>
Declaring every local variable you never change as const, however, can be
a bridge too far. Just declaring a local var as const because it just so
happens you never change it nearly has no semantic value whatsoever.

Not sure what do you mean but if variable must not be changed by its
logical goal then the variable must be declared as const, in spite of
"local" status, i think must.

This is what I was saying. If something _must_ not be changed, you should
declare it const. You should not declare something const just because it
appears you are not changing it (again, in _my_ opinion)

>>For C++ const has a special meaning, const variables can be conpile time
constants if its adress never taken.

Actually, only integral types can be compile time constants, and they are
compile-time constants no matter whether their address has been taken.

No. Even integral compile-time constants will be allocated if its address
has been taken

I know, but that was not what we were talking about. You were saying it is a
compile-time constant unless it has it's address taken. But it does not stop
from being a compile-time constant as soon as you take it's address:

const int size = 4;
int array1[size]; // valid

const int * sizePtr = &size;
int array2[size]; // still valid, even though size has it's address
taken

By the way, for some free-standing classes compiler could have const
compile-time variables of non-integral types, executing there ctor/dtor
and methods at compile time.

I think your definition of "compile-time constant" is a bit off. A
compile-time constant is a constant that can be used in places where a
compile-time constant is expected, such as the size of an array. It has
nothing to do with whether that constant has to be allocated or whether the
expression is executed at compile-time to calculate the value - these are
merely optimizations done by the compiler.

inline int foo() { return 5; }
const int constInt = foo();

Most compilers will not generate a call to foo() to initialize constInt -
they will even just place the value '5' in the binary of the executable. Yet
constInt is not a compile-time constant (e.g., you cannot use it to define
the size of an array).

- Sylvester

[Grizlyk]

Sylvester Hesp wrote:

>Not sure what do you mean but if variable must not be changed by its
logical goal then the variable must be declared as const, in spite of
"local" status, i think must.

This is what I was saying. If something _must_ not be changed, you should
declare it const. You should not declare something const just because it
appears you are not changing it (again, in _my_ opinion)

I think that we should not declare something with unknown or indefinite
goals, if variable:

- is a kind of input parameter, then it is mostly const;
- is temp storage, then it is mostly const;

- is counter-like, then it is always non const;
- is initializing by several steps, then it is always non const (and it is
sometimes problem if I need to declare later const reference to it as
alias);
- is data transfer area between units, then it is always non const;

For classes with complex behaviour all depends from its methods, we are
going to call.

I think, no other "classes" of variables exist. At least if I am not sure
what the variable I have declared will do, I use "const", to reduce possible
variations, so it looks like "const by default".

>>>For C++ const has a special meaning, const variables can be compile
time constants if its adress never taken.

Actually, only integral types can be compile time constants, and they
are compile-time constants no matter whether their address has been
taken.

No. Even integral compile-time constants will be allocated if its address
has been taken

I think your definition of "compile-time constant" is a bit off. A
compile-time constant is a constant that can be used in places where a
compile-time constant is expected, such as the size of an array. It has
nothing to do with whether that constant has to be allocated or whether
the expression is executed at compile-time to calculate the value - these
are merely optimizations done by the compiler.
inline int foo() { return 5; }
const int constInt = foo();

Most compilers will not generate a call to foo() to initialize constInt -
they will even just place the value '5' in the binary of the executable.
Yet constInt is not a compile-time constant (e.g., you cannot use it to
define the size of an array).

You are right, probably I have used a wrong name "compile-time constant",
because i have said about memory usage - const variable often can be not
placed into memory (as enum).

The last is advantage in comparison with non-const, I agree, that current
compilers do not do great differences between const and non-const data
during optimisation, but const data have more chances to be optimised due to
nature of const.

- NOT C++ -

I think, that the fact (that there are no great differences between const
and non-const data during optimisation), can be changed in future, because
your example

inline int foo() { return 5; }
const int constInt = foo();

de facto is true "compile-time constant", and excactly as

#define constInt (5)

and the fact, that C++ compiler can not see it is just bad optimisation
rules.

I think, all execution, that can be done at compile time must be done at
compile time, else people will use preprocessor to avoid dummy runtime
execution.

The const modifier can help to compiler to start execution at compile time
and to convert result of execution into something like

#define constInt (5)

And as i have said, it is able even for so complex objects, as class.

>By the way, for some free-standing classes compiler could have const
compile-time variables of non-integral types, executing there ctor/dtor
and methods at compile time.

- NOT C++ -

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Gavin Deane]

On 8 Feb, 15:33, "Grizlyk" <[e-mail]:

Sylvester Hesp wrote:

Declaring every local variable you never change as const, however, can be
a bridge too far. Just declaring a local var as const because it just so
happens you never change it nearly has no semantic value whatsoever.

Not sure what do you mean but if variable must not be changed by its logical
goal then the variable must be declared as const, in spite of "local"
status, i think must.

I think the question is *how much* value const adds in a strictly
local scope when it is applied to an object that happens to remain
unchanged. Elsethread, Kai-Uwe Bux presented two alternatives for the
same function:

template < typename T >
void swap ( T & lhs, T & rhs ) {
T dummy ( lhs );
lhs = rhs;
rhs = dummy;
}

or

template < typename T >
void swap ( T & lhs, T & rhs ) {
const T dummy ( lhs );
lhs = rhs;
rhs = dummy;
}

Do you believe that the first is significantly poorer style than the
second?

Gavin Deane

[Kai-Uwe Bux]

Gavin Deane wrote:

On 8 Feb, 15:33, "Grizlyk" <[e-mail]:

>Sylvester Hesp wrote:

Declaring every local variable you never change as const, however, can
be a bridge too far. Just declaring a local var as const because it
just so happens you never change it nearly has no semantic value
whatsoever.

Not sure what do you mean but if variable must not be changed by its
logical goal then the variable must be declared as const, in spite of
"local" status, i think must.

I think the question is *how much* value const adds in a strictly
local scope when it is applied to an object that happens to remain
unchanged. Elsethread, Kai-Uwe Bux presented two alternatives for the
same function:

template < typename T >
void swap ( T & lhs, T & rhs ) {
T dummy ( lhs );
lhs = rhs;
rhs = dummy;
}

or

template < typename T >
void swap ( T & lhs, T & rhs ) {
const T dummy ( lhs );
lhs = rhs;
rhs = dummy;
}

Do you believe that the first is significantly poorer style than the
second?

One remark about the example: the two versions are _not_ equivalent. For
instance the first version will correctly swap auto_ptr<intobjects
whereas you will get a compile time error with the second. It is debatable
whether that is a feature or a bug. In any case it is a difference, and the
lesson to be learned is that with templates you decisions about those
little things sometimes translate into conceptual requirements for the
types you can use to instantiate your templates.
Best

Kai-Uwe Bux

[Grizlyk]

Gavin Deane wrote:

>
I think the question is *how much* value const adds in a strictly
local scope when it is applied to an object that happens to remain
unchanged. Elsethread, Kai-Uwe Bux presented two alternatives for the
same function:

template < typename T >
void swap ( T & lhs, T & rhs ) {
T dummy ( lhs );
lhs = rhs;
rhs = dummy;
}

template < typename T >
void swap ( T & lhs, T & rhs ) {
const T dummy ( lhs );
lhs = rhs;
rhs = dummy;
}

Do you believe that the first is significantly poorer style than the
second?

I think the second is better.

The first example is a kind of "freedom to make crimes", not a "freedom to
protect your base human rights" :) A man, who will maybe mainain your code
will assume, that variable "dummy" of unknown type "T" is free for writing
to it in spite of the fact, that code looks like "dummy" is readonly.

The last example "const dummy" is more explained and give a chance to the
man to reduce his work. If you say "const" you say that you have decided,
that using of the variable is limited, that better then unlimitted usage.

That is why, we even can want to have "writeonly"-like and free-used
"mutable" modifiers, just to dettect errors of usage at compile time and
ensure that we know what we are doing (do not forge to say const).

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Sylvester Hesp]

"Grizlyk" <gr******@yandex.ruwrote in message
news:eq**********@aioe.org...

>
Gavin Deane wrote:

>>
I think the question is *how much* value const adds in a strictly
local scope when it is applied to an object that happens to remain
unchanged. Elsethread, Kai-Uwe Bux presented two alternatives for the
same function:

template < typename T >
void swap ( T & lhs, T & rhs ) {
T dummy ( lhs );
lhs = rhs;
rhs = dummy;
}

template < typename T >
void swap ( T & lhs, T & rhs ) {
const T dummy ( lhs );
lhs = rhs;
rhs = dummy;
}

Do you believe that the first is significantly poorer style than the
second?

I think the second is better.

As Kai-Uwe already mentioned, a const T prevents you to swap any object that
has a copy-ctor which doesn't take a const reference, such as std::auto_ptr.
Thus while the code may look better, it is not actually better as you limit
the use of the swap function - a limitation which does not make sense at all
(you should be able to swap any copy-constructable non-const variables)

- Sylvester

[Grizlyk]

Sylvester Hesp wrote:

>
As Kai-Uwe already mentioned, a const T prevents you to swap any object
that has a copy-ctor which doesn't take a const reference, such as
std::auto_ptr.

Do not use std::auto_ptr. Write you onw with same behaviour.

(you should be able to swap any copy-constructable non-const variables)

What the reason to make copy-constructable as non-const - in order to allow
changes of internal rvalue state during copying?

I think, objects that moves own state during copying is not copyable, but
moveable. If you want to move, it does not means you want non-const, becasue
non-const allows more than only move. In other words moveable can be const.

-- NOT C++ start --

Consider, it can be better

//move
template < typename T >
void operator < (const T &) dtor;

template < typename T >
void swap ( T & lhs, T & rhs )
{
const T dummy ( <lhs );
lhs = <rhs;
rhs = <dummy;
}

template < typename T >
void operator <->(T& lhs, T& rhs){swap<T>( lhs, rhs );}

The operator<-can be builtin for POD types.

-- NOT C++ end --

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Grizlyk]

Grizlyk wrote:

>
Write you onw

means "Write your own"

-- NOT C++ start --

Consider, it can be better

//move
template < typename T >
void operator < (const T &) dtor;

as global friend operator
T::move_return_type operator < (const T &);

or as class T member
T::move_return_type T::operator < ()const dtor;

But it is clear in general.

>
-- NOT C++ end --

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Sylvester Hesp]

"Grizlyk" <gr******@yandex.ruwrote in message
news:eq**********@aioe.org...

>
Sylvester Hesp wrote:

>>
As Kai-Uwe already mentioned, a const T prevents you to swap any object
that has a copy-ctor which doesn't take a const reference, such as
std::auto_ptr.

Do not use std::auto_ptr. Write you onw with same behaviour.

Nonsense. Why do I need to do that? Aside from that, it was an example, the
argument holds for any type with a non-const copy ctor (don't deny their
existence!). If someone chose to implement swap with a const dummy, that's
the thing I wouldn't use and rewrite. I will not rewrite every nonconst copy
constructable type I use just because it so happens someone implemented
swap() in the way you described because he/she thought that was better
design, completely ignoring the fact that others might want to swap nonconst
copy constructable types as well, which makes perfect sense.

>

>(you should be able to swap any copy-constructable non-const variables)

What the reason to make copy-constructable as non-const - in order to
allow changes of internal rvalue state during copying?

See std::auto_ptr, which you still want to be able to swap.

>
I think, objects that moves own state during copying is not copyable, but
moveable. If you want to move, it does not means you want non-const,
becasue non-const allows more than only move. In other words moveable can
be const.

I said copy constructable, not copyable. Subtle but important difference.

>
-- NOT C++ start --

Consider, it can be better

Yes, but right now we have to deal with how things are.

template < typename T >
void swap ( T & lhs, T & rhs )
{
const T dummy ( <lhs );
lhs = <rhs;
rhs = <dummy;
}

C++09 will support move semantics using reference-to-r-value (&&), but that
doesn't change the implementation of our swap function as 'dummy' is not an
r-value. It's a const l-value, it doesn't make sense to move data away from
a const l-value thus changing it's state, not even with your suggested move
operator. It's const for a reason. So your suggestion is sementically
flawed.

- Sylvester

[Grizlyk]

Sylvester Hesp wrote:

>>
Do not use std::auto_ptr. Write your own with same behaviour.

Nonsense. Why do I need to do that?

If you write "nonsense" that _you_ must write "why", not I "why not". But I
can repeat, it is not hard to me because i know a sence. Because
implementation of std::auto_ptr is based on wrong invariants. There are many
invariants in the world, but not all of them are useful and std::auto_ptr is
good example of useless invariants.

The auto_ptr idiom is simplest thing in the world:
- auto_ptr is owner of unique resource (memory area)
- if you want to pass ownership, then pass auto_ptr by value
- if you want to pass address, then pass POD pointer
- you can not use any kind of auto_ptr (non-const or const) after you pass
ownership (in fact, after "move" auto_ptr must be immediately deleted)

Remove constness in order to make only move is wrong idea and does not
require by move semantic. Move semantic required "once" support, not
"non-const", it is really different things. See below.

In the case, non-constness looks as if you will refuse from static type
check and will use only void* just because any can write wrong int value to
char memory over casted pointer.

For correct auto_ptr usage compiler can easy control "once" of move
operation at compile time.

Aside from that, it was an example, the argument holds for any type with a
non-const copy ctor (don't deny their existence!).

The "non-const copy ctor" is not "copy ctor", so if you allow your class to
be copyable - make "copy ctor"("const copy ctor"). If you allow your class
to be moveable - make "move" as "once". The "non-const copy ctor" can exist
for other things. For move can be ctor with "const &&".

If someone chose to implement swap with a const dummy, that's the thing I
wouldn't use and rewrite. I will not rewrite every nonconst copy
constructable type I use just because it so happens someone implemented
swap() in the way you described because he/she thought that was better
design, completely ignoring the fact that others might want to swap
nonconst copy constructable types as well, which makes perfect sense.

The "constructable type" type is dimly defined. What is it? If object have
been created, can its type be "non-constructable"? In opposite, moveable
well-defined and means "one created - other destroyed, only one copy at time
exist".

>>(you should be able to swap any copy-constructable non-const variables)

What the reason to make copy-constructable as non-const - in order to
allow changes of internal rvalue state during copying?

See std::auto_ptr, which you still want to be able to swap.

see above

>I think, objects that moves own state during copying is not copyable, but
moveable. If you want to move, it does not means you want non-const,
becasue non-const allows more than only move. In other words moveable can
be const.

I said copy constructable, not copyable. Subtle but important difference.

see above

-- NOT C++ start --

>>

Consider, it can be better

Yes, but right now we have to deal with how things are.

My code just now use it, with limitations of current C++, the line

>const T dummy ( <lhs );

looks like
const T dummy ( lhs );

and if T has

T::T(const T& obj):ptr(obj.move()){}

as Ntest::auto_ptr<do, all works as moving, not copying.

>template < typename T >
void swap ( T & lhs, T & rhs )
{
const T dummy ( <lhs );
lhs = <rhs;
rhs = <dummy;
}

C++09 will support move semantics using reference-to-r-value (&&), but
that doesn't change the implementation of our swap function as 'dummy' is
not an r-value. It's a const l-value, it doesn't make sense to move data
away from a const l-value thus changing it's state, not even with your
suggested move operator. It's const for a reason. So your suggestion is
sementically flawed.

We must not be compatible with random "reference-to-r-value" definition, let
"reference-to-r-value" definition will be compatible with real move
semantic.

It is evidently to anybode that move has "once" argument, "once" can be
const or non-const. Consider the differences

const T dummy ( <lhs );
<lhs; //compiler must generate error here
//"double move" - "once" violation
dummy= <rhs; //compile time error

T dummy ( <lhs );
<lhs; //compiler must generate error here
//"double move" - "once" violation
dummy= <rhs; //ok

And the fact that for swap function does not strictly require const dummy,
does not say that all other functions does not require const movable.

In opposite to move, swap semantics really require non-const to its
argumets.

In addition, I think C++ must support operator <-(swap) at least because
CPUs have the swap hardware opcodes for POD, as for *p++ and < (move)
because it is useful operation for class-wrappers.

-- NOT C++ end --

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Grizlyk]

Grizlyk wrote:

-- NOT C++ --

>Aside from that, it was an example, the argument holds for any type with
a non-const copy ctor (don't deny their existence!).

The "non-const copy ctor" is not "copy ctor", so if you allow your class
to be copyable - make "copy ctor"("const copy ctor"). If you allow your
class to be moveable - make "move" as "once". The "non-const copy ctor"
can exist for other things. For move can be ctor with "const &&".

I have some questions.

I see now, that we (or I) must have clear differences between

a) copyable parameter passed by reference
b) moveable parameter passed by reference
c) copyable parameter passed by value
d) moveable parameter passed by value

and we (or I) must declare

1. what syntax must be to declare each type of parameter
2. what kind of ctor must be used

// ***
a) copyable parameter passed by reference

The declaration sign "&" say that "data" will be created as reference of src

1. foo(const T& data)
foo(T& data)

2. T::operator??? what kind of operator makes references?

{const T src; foo(src);}
{ T src; foo(src);}

// ***
b) moveable parameter passed by reference

For non-inline functions it is bad idea, because compiler will lose control
for "once" over local scope bound.

The declaration sign "&" say that "data" will be created as reference of src

1. foo(const T& data)
foo(T& data)

2. T::operator??? what kind of operator makes references?

{const T src; foo(src);} //foo::data==src
{ T src; foo(src);} //foo::data==src

// ***
c) copyable parameter passed by value

1. foo(const T data)
foo(T data)

2. T::T(const T&)
/*T::T(T&)*/

// foo::data==T::T(const T& /*src*/)==src.copy()
{const T src; foo(src);}

// foo::data==T::T(const T& /*src*/)==src.copy()
{ T src; foo(src);}

Do we allow T::T(T&) to be used for "T src; foo(src);"?
Is any class T have declared only T::T(T&) copyable?

// ***
d) moveable parameter passed by value

Let declaration sign "@" say that "data" will be created by "move" from
"src"

1. foo(const T@ data)
foo(T@ data)

2. T::T(const T@ data)
/*T::T(T@)*/

// foo::data==T::T(const T@ /*src*/)== src.move()
{const T src; foo(src);}

// foo::data==T::T(const T@ /*src*/)== src.move()
{ T src; foo(src);}

Do we allow T::T(T@) to be used for "T src; foo(src);"?
Is any class T have declared only T::T(T@) moveable?

-- NOT C++ --

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Sylvester Hesp]

"Grizlyk" <gr******@yandex.ruwrote in message
news:eq**********@aioe.org...

>
Sylvester Hesp wrote:

>>>
Do not use std::auto_ptr. Write your own with same behaviour.

Nonsense. Why do I need to do that?

If you write "nonsense" that _you_ must write "why", not I "why not". But
I can repeat, it is not hard to me because i know a sence.

I'm sorry but I don't understand anything of what you're trying to say here.

(in fact, after "move" auto_ptr must be immediately deleted)

Of course not. Yes, it holds a null pointer after it's content has been
moved to another auto_ptr or after a call to release(), but that doesn't
mean the autoptr itself has to be destructed. You can happily reassign it
with a new pointer

Remove constness in order to make only move is wrong idea and does not
require by move semantic. Move semantic required "once" support, not
"non-const", it is really different things. See below.

Actually it does require non-const for l-values. Otherwise you can easily
change all const variables by simply moving them to other variables.

>
In the case, non-constness looks as if you will refuse from static type
check and will use only void* just because any can write wrong int value
to char memory over casted pointer.

First of all, I thought the discussion whether to use const or not for local
variables was over. Secondly, this is just a bogus comparison. Of course not
using const for local vars where it does not have any semantic meaning is
way different than not using typechecking altogether.

For correct auto_ptr usage compiler can easy control "once" of move
operation at compile time.

No it can't. How can it assure it is moved only once if you're using the
variable in more than one translation unit? The compiler can't track whether
a variable already has moved. Aside from that, it's silly. As the variable
is still in a constructed state, it's state has to be well-defined (for
example, a null pointer for a std::auto_ptr). If it has a well-defined
state, that means it can be moved again. Of course, this value doesn't have
to be the same as the value you moved earlier, but still, it can be moved.
Otherwise, you'll have to restrict all access after it's contents have been
moved (which again is impossible for the compiler to enforce).

The "non-const copy ctor" is not "copy ctor", so if you allow your class
to be copyable - make "copy ctor"("const copy ctor"). If you allow your
class to be moveable - make "move" as "once". The "non-const copy ctor"
can exist for other things. For move can be ctor with "const &&".

According to the standard, a non-const copy ctor is just as well a copy ctor
as a const copy ctor (or a volatile copy ctor or a const volatile copy
ctor).

>If someone chose to implement swap with a const dummy, that's the thing I
wouldn't use and rewrite. I will not rewrite every nonconst copy
constructable type I use just because it so happens someone implemented
swap() in the way you described because he/she thought that was better
design, completely ignoring the fact that others might want to swap
nonconst copy constructable types as well, which makes perfect sense.

The "constructable type" type is dimly defined. What is it? If object have
been created, can its type be "non-constructable"? In opposite, moveable
well-defined and means "one created - other destroyed, only one copy at
time exist".

I didn't say "constructable type", I said "copy constructable type", which
is of course a type with an accessible and sensible copy constructor.

>Yes, but right now we have to deal with how things are.

My code just now use it, with limitations of current C++, the line

>>const T dummy ( <lhs );

looks like
const T dummy ( lhs );

and if T has

T::T(const T& obj):ptr(obj.move()){}

as Ntest::auto_ptr<do, all works as moving, not copying.

See above.

We must not be compatible with random "reference-to-r-value" definition,
let "reference-to-r-value" definition will be compatible with real move
semantic.

It is. Read these papers:
http://www.open-std.org/jtc1/sc22/wg...2002/n1377.htm
http://www.open-std.org/jtc1/sc22/wg...2002/n1385.htm
http://www.open-std.org/jtc1/sc22/wg...004/n1690.html

It is evidently to anybode that move has "once" argument, "once" can be
const or non-const. Consider the differences

const T dummy ( <lhs );
<lhs; //compiler must generate error here
//"double move" - "once" violation
dummy= <rhs; //compile time error

T dummy ( <lhs );
<lhs; //compiler must generate error here
//"double move" - "once" violation
dummy= <rhs; //ok

Now you are moving TO a (const) variable. We were discussing the fact that
you were moving FROM a (const) variable. Your definition:

template < typename T >
void swap ( T & lhs, T & rhs )
{
const T dummy ( <lhs );
lhs = <rhs;
rhs = <dummy;
}

dummy is const, so the statement 'rhs = <dummy' must be ill-formed. Because
with the move, you are changing the state of dummy, which you shouldn't
because it's const.

- Sylvester

[Grizlyk]

Sylvester Hesp wrote:

>>>>
Do not use std::auto_ptr. Write your own with same behaviour.

Nonsense. Why do I need to do that?

If you write "nonsense" that _you_ must write "why", not I "why not". But
I can repeat, it is not hard to me because i know a sence.

I'm sorry but I don't understand anything of what you're trying to say
here.

Nonsense.

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Sylvester Hesp]

"Grizlyk" <gr******@yandex.ruwrote in message
news:eq**********@aioe.org...

>
Sylvester Hesp wrote:

>>>>>
Do not use std::auto_ptr. Write your own with same behaviour.

Nonsense. Why do I need to do that?

If you write "nonsense" that _you_ must write "why", not I "why not".
But
I can repeat, it is not hard to me because i know a sence.

I'm sorry but I don't understand anything of what you're trying to say
here.

Nonsense.

Great point! Why didn't I see that earlier. It's all clear to me know how
you were completely right and I was totally wrong.
/end sarcasm ;)

Look, it's clear that English isn't your native language. Which is perfectly
fine, it's not mine either - as long as we can understand eachother that's
all that matters. But in this particular case I am having problems
interpreting what you are saying.

- Sylvester

[Victor Bazarov]

Sylvester Hesp wrote:

"Grizlyk" <gr******@yandex.ruwrote in message
news:eq**********@aioe.org...

>>
Sylvester Hesp wrote:

>>>>>>
>Do not use std::auto_ptr. Write your own with same behaviour.
>
Nonsense. Why do I need to do that?

If you write "nonsense" that _you_ must write "why", not I "why
not". But
I can repeat, it is not hard to me because i know a sence.

I'm sorry but I don't understand anything of what you're trying to
say here.

Nonsense.

Great point! Why didn't I see that earlier. It's all clear to me know
how you were completely right and I was totally wrong.
/end sarcasm ;)

Look, it's clear that English isn't your native language. Which is
perfectly fine, it's not mine either - as long as we can understand
eachother that's all that matters. But in this particular case I am
having problems interpreting what you are saying.

Maksim says that if you (Sylvester) use the word "nonsense", it is
your responsibility to explain why it is so, not his responsibility
to have a counter-argument. But he can repeat [what he already said]
because for him it is exactly what defines the sense of {whatever you
called 'nonsense'}. Any clearer?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Sylvester Hesp]

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:eq**********@news.datemas.de...

Sylvester Hesp wrote:

>"Grizlyk" <gr******@yandex.ruwrote in message
news:eq**********@aioe.org...

>>>>>
If you write "nonsense" that _you_ must write "why", not I "why
not". But
I can repeat, it is not hard to me because i know a sence.

I'm sorry but I don't understand anything of what you're trying to
say here.

Look, it's clear that English isn't your native language. Which is
perfectly fine, it's not mine either - as long as we can understand
eachother that's all that matters. But in this particular case I am
having problems interpreting what you are saying.

Maksim says that if you (Sylvester) use the word "nonsense", it is
your responsibility to explain why it is so, not his responsibility
to have a counter-argument. But he can repeat [what he already said]
because for him it is exactly what defines the sense of {whatever you
called 'nonsense'}. Any clearer?

Yes, thank you.

Fair enough, my choice for the word "nonsense" might have been a bit too
aggressive, but you [Maksim] didn't supply the reasoning of rewriting
std::auto_ptr in the original posting (although it was in the follow-up).
Granted, std::auto_ptr has it's quirks, but rewriting it is not always an
option (when working with code of others), and you still want to be able to
swap it, no matter how badly it is designed (and I'm not saying it's _that_
badly designed)

- Sylvester

[Richard Herring]

In message <eq**********@aioe.org>, Grizlyk <gr******@yandex.ruwrites

>
Sylvester Hesp wrote:

>>
As Kai-Uwe already mentioned, a const T prevents you to swap any object
that has a copy-ctor which doesn't take a const reference, such as
std::auto_ptr.

Do not use std::auto_ptr.

If it's the correct tool for what you're trying to accomplish, why not?

>Write you onw with same behaviour.

Then you will have the same problems.

--
Richard Herring

[Grizlyk]

Sylvester Hesp wrote:

>
Yes, thank you.

Fair enough, my choice for the word "nonsense" might have been a bit too
aggressive, but

>>>Nonsense. Why do I need to do that? Aside from that,

You must not build your answers without proving your opinion, to force me to
refute your statements without any hints. I am forced to guess what the
sources of your decision were.

The following example

1.
A: statement, statement.
B: nonsense#1.
A: nonsense#1->new statement, nonsense#1->new statement.
B: nonsense#2.
A: nonsense#2->new statement, nonsense#2->new statement.
B: nonsense#3.

is a kinds of useless dialogue between "A" and "for(;;){wait();
cout<<"nonsense";}".
--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Sylvester Hesp]

"Grizlyk" <gr******@yandex.ruwrote in message
news:er**********@aioe.org...

>
Sylvester Hesp wrote:

>>
Yes, thank you.

Fair enough, my choice for the word "nonsense" might have been a bit too
aggressive, but

>>>>Nonsense. Why do I need to do that? Aside from that,

You must not build your answers without proving your opinion, to force me
to refute your statements without any hints. I am forced to guess what the
sources of your decision were.

There are many (in my opinion) valid points in my latest reply to you
(mostly regarding moving away from const variables using move semantics). If
you have anything left to say, focus on those points like I focused on
yours. If you want to discuss how to discuss, fine, but then I will leave
the thread as it is :)

- Sylvester

[Grizlyk]

Sylvester Hesp wrote:

>
There are many (in my opinion) valid points in my latest reply to you
(mostly regarding moving away from const variables using move semantics).

All of your points about "auto_ptr" has been discussed befor, it seems to me
with "Andre Kostur" in the topic "auto_ptr". No any new events has been
added by you here. You can see my objections there. Maybe it will be better
to group all about "auto_ptr" in one place.

If you want to discuss how to discuss, fine, but then I will leave the
thread as it is :)

As you wish. I will be free to note about useless forms of any discussions.
--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Sylvester Hesp]

"Grizlyk" <gr******@yandex.ruwrote in message
news:er**********@aioe.org...

>
Sylvester Hesp wrote:

>>
There are many (in my opinion) valid points in my latest reply to you
(mostly regarding moving away from const variables using move semantics).

All of your points about "auto_ptr" has been discussed befor, it seems to
me with "Andre Kostur" in the topic "auto_ptr". No any new events has been
added by you here. You can see my objections there. Maybe it will be
better to group all about "auto_ptr" in one place.

You keep rambling on about auto_ptr while I've exited that train very long
(about 5 posts) ago. I was talking about the implications of moving away
from const variables. But, after reading the auto_ptr thread (which I
missed, thank you for bringing it to my attention), it seems you do not care
about const at all. You say you should use const as often as possible, yet
you design your classes that let you change their defined state while they
are const. That indeed makes this discussion pretty useless :). Have a good
day, we'll probably meet again in further discussions ;)

- Sylvester

[Grizlyk]

Sylvester Hesp wrote:

>>>
There are many (in my opinion) valid points in my latest reply to you
(mostly regarding moving away from const variables using move
semantics).

All of your points about "auto_ptr" has been discussed befor, it seems to
me with "Andre Kostur" in the topic "auto_ptr". No any new events has
been added by you here. You can see my objections there. Maybe it will be
better to group all about "auto_ptr" in one place.

You keep rambling on about auto_ptr while I've exited that train very long
(about 5 posts) ago. I was talking about the implications of moving away
from const variables.

It (moving from const variables) is base of life of auto_ptr, so has been
discussed closely there.

But, after reading the auto_ptr thread (which I missed, thank you for
bringing it to my attention), it seems you do not care about const at all.

I do not know what are you speaking about, you can answer at the point you
have found it in auto_ptr thread.
--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/