Things I hate about C++

[JKop]

Okay here we go, I feel it's about time people conversed about the bullshit
aspects of C++ (including the bullshit stuff brought forward from C). I'll
begin with a few of my own grievances:
1) The whole "function declaration Vs object definition" fiasco, which
results in the following (temporary creating) syntax:

Blah poo = Blah();
2) How string literals are not const (even though they are!), for instance:

void Blah(char* const p_k)
{
*p_k = '4'; //Opps!
}

int main()
{
Blah("Hello");
}
3) How arrays decay to pointers...
The following is possible:

unsigned &r = *new unsigned;
But the following is not:

unsigned (&r)[10] = *new unsigned[10];

That's all I can think of right now!
-JKop

[josh]

JKop wrote:

So far I have the following work-arounds:
Work-around 1:

template<class T>
void GiveMeAnyType()
{
T const &t = T();
}

Problem: It has to be const.
Work-around 2:

template<class T>
void GiveMeAnyType()
{
T &t = *new T();

delete &t;
}

Problem: I'm not sure if there's an efficiency or performance issue.

-JKop

Aw, you didn't like my placement new idea?

template<class T>
void GiveMeAnyType()
{
char garbage[sizeof T];
T &t = *new(garbage) T();

t.~T();
}

Same as work-around 2, but without no performance issues.

-josh

[Phlip]

Andre Kostur wrote:

struct Blah
{
std::string k;
void* p_t;
};

int main()
{
Blah poo = { std::string("Hello!"), 0 };
}

Uh... that's not a POD.....

Well, I found my 1998 Standard, but I refuse to read it on behalf of this
b.. you know what...

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Rob Williscroft]

JKop wrote in news:Yz*******************@news.indigo.ie in comp.lang.c++:

Blah poo = {};

Yes, it's preferrable over:
Blah poo = { 0 };
But...
it doesn't work with non-PODs.

Blah is a non-POD as it containes a std::string which isn't a POD.

But yes it doesn't work with non-aggregates, the best you can get
is:

#include <iostream>

template < typename T >
struct default_initialized
{
T item;
default_initialized() : item() {}
};

int main()
{
default_initialized< int > dii;
int &i = dii.item;
std::cout << i << '\n';
}

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Ioannis Vranos]

Ron Natalie wrote:

Until you want to write a template and don't know what the
nature of Blah really is. There's no way to univerally default
initialize an automatic variable in C++. It's a language defact.

Perhaps you mean something like:

template <class T>
inline T add(const T &a = T(), const T &b = T())
{
return a+b;
}
It works for both PODs and non-PODs. Actually this is why the T()
notation was invented for PODs, it makes them work well with templates.

A more useful example of this is std::vector.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

JKop wrote:

I'll rephrase the question:

"Any thoughts on *why* the following is illegal?"

And again, because this is not supported by the language. That
initialisation notation is for structs (and arrays) in the stack.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Phlip wrote:

The CUJ "Bug of the Month" I remember is not available online, but Philip
Staite reported this one. VC++ should not permit the call.

I could be wrong: we could be thinking of a draft Standard or something.

Yes you are wrong. Consider the code:
class SomeClass
{
SomeClass & operator=(const SomeClass &);
};

int main()
{
SomeClass obj = SomeClass();
}
It compiles with GCC 3.3.1, VC++ 7.1 (2003) and VC++ 2005 Beta 1+.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

JKop wrote:

1) The whole "function declaration Vs object definition" fiasco, which
results in the following (temporary creating) syntax:

Blah poo = Blah();

Since I have been confused, may you state explicitly what do you want to
do exactly:

Default initialise PODs to 0? Default initialise everything to 0?
Something else?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Phlip]

Ioannis Vranos wrote:

It compiles with GCC 3.3.1, VC++ 7.1 (2003) and VC++ 2005 Beta 1+.

Me too. I just didn't want to be so crass as to say "but my compiler still
has the alleged bug" when one should not set a bad example for newbies, such
as testing ones compiler to learn language law. It might still be wrong.

I remember the "Bug++ of the Month" because I recognized Philip Staite's
name from this newsgroup, and then I discussed the alleged bug here. Nobody
complained then. The closest citation I can find in the Standard just says a
program is ill-formed if the matching copy operation is "implicitly" called
and is private, and I'm not capable of reading the whole thing to see if I
overlooked something.

Everyone: Rely on what your compiler permits here.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Old Wolf]

"Phlip" <ph*******@yahoo.com> wrote:

Ioannis Vranos wrote:

Assignment upon definition (initialisation) for non-POD types calls
*always* the copy constructor.

I'm not talking about POD-ness (here). The statement Blah foo = Blah();
tests operator= for access before calling the copy constructor.

WRONG. (How many times a week does this issue come up?)

The situation (where 'bar' is some expression):
T foo = bar;
is initialization, NOT assignment. operator= does not come into
this. Don't believe it? Write a class with a private assignment
operator and public copy constructor, and watch it compile.

If 'bar' has type T then foo is created using its copy constructor
with 'bar' as the parameter. If not then first a temporary T
is created with 'bar' as the parameter, and then foo is created
using its copy constructor with that temporary as the parameter.

[Ioannis Vranos]

Phlip wrote:

Me too. I just didn't want to be so crass as to say "but my compiler still
has the alleged bug" when one should not set a bad example for newbies, such
as testing ones compiler to learn language law. It might still be wrong.

I remember the "Bug++ of the Month" because I recognized Philip Staite's
name from this newsgroup, and then I discussed the alleged bug here. Nobody
complained then. The closest citation I can find in the Standard just says a
program is ill-formed if the matching copy operation is "implicitly" called
and is private, and I'm not capable of reading the whole thing to see if I
overlooked something.

Everyone: Rely on what your compiler permits here.

Check 12.8 in the standard, especially where it says:

class X {
// ...
public:
X(int);
X(const X&, int = 1);
};

X a(1); // calls X(int);
X b(a, 0); // calls X(const X&, int);

==> X c = b; // calls X(const X&, int);

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Phlip]

Ioannis Vranos wrote:

Check 12.8 in the standard, especially where it says:

class X {
// ...
public:
X(int);
X(const X&, int = 1);
};

X a(1); // calls X(int);
X b(a, 0); // calls X(const X&, int);

==> X c = b; // calls X(const X&, int);

I have never once said it didn't call that.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Phlip]

Old Wolf wrote:

I'm not talking about POD-ness (here). The statement Blah foo = Blah();
tests operator= for access before calling the copy constructor.

WRONG. (How many times a week does this issue come up?)

You are answering "does = during initialization call operator=". I have
never once said it did.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Ioannis Vranos]

Phlip wrote:

I have never once said it didn't call that.

Yes, I mean the copy-constructor is called always, and operator= has not
anything to do with it, and thus it is never checked.
If some old MS compiler had problem, then under view of C++98 it is a
bug, but since VC++ 7.x works and does not check for operator= in this
occasions, you are referring to pre-ANSI C++ ones (like VC++ 6) which
also had the for-loop scope problem too:
for(int i=0; i<whatever; ++x)
//...
int i had scope outside the loop until the end of the enclosing scope.
To fix these problems, you must upgrade to an up to date C++ compiler.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[JKop]

template<class T>
void GiveMeAnyType()
{
char garbage[sizeof T];
T &t = *new(garbage) T();

t.~T();
}

Same as work-around 2, but without no performance issues.

-josh

Are you sure about that?!
If it's true that there's no performance issues then it looks like we have a
winner!
-JKop

[JKop]

SomeFunctionThatTotallyAltersObjectRegardlessOfIts OriginalState(poo);

Then that function is likely a factory of some description and it's
design is flawed. It should be a function taking no parameters, and
returing a Blah object. *Poof*, no extra constructors with any sort of
decent compiler.

hmm... perhaps.
I'll take an example from Win32.

There's a function called GetVersionEx, like so:

int GetVersionEx(OSVERSIONINFO* p_osv);

where "OSVERSIONINFO" is a POD.

You use the function as follows:

int main()
{
OSVERSIONINFO osv;

GetVersionEx(&osv);
}
It would be inefficient if you did:

int main()
{
OSVERSIONINFO osv = OSVERSIONINFO();

GetVersionEx(&osv);
}
But then again you have the argument that it should be:

OSVERSIONINFO GetVersionEx();
But... that can create a temporary.
-JKop

[JKop]

Alf P. Steinbach posted:

* JKop:

B
U
L
L
S
H
I
T of the highest order.

Please think about whether such language has the same meaning for all
who read it. Now I'm not one who shies from using the occasional strong
word (and I've had to apologize when it turned out to be uncalled for),
and I think you're being Not Nice (TM) here. Phlip seems to have vaguely
remembered an article, and perhaps that article was wrong or the memory
was wrong, but it's OK to be wrong: correcting factual errors in a, well,
bit more civilized manner, is one main purpose of this newsgroup, and if
people feel that they will be chastized in public just for writing what
they think and believe to be true, then erronous beliefs will propagate.

Okay, point taken.

But at the same time, I've learned *a lot* in this newsgroup about C++; I'm
safe in the knowledge that what I've learned is correct. If for instance, I
was a novice and I'd read (past tense, gotta hate english spelling) Philip's
post, then I would've been thinking that:

AnyClass poo = 5;
Called:

AnyClass();

and then:

AnyClass& operator=(AnyClass const &);
When in actual fact it calls:

AnyClass(int);
-JKop

[JKop]

Rob Williscroft posted:

JKop wrote in news:Yz*******************@news.indigo.ie in comp.lang.c++:

Blah poo = {};

Yes, it's preferrable over:
Blah poo = { 0 };
But...
it doesn't work with non-PODs.

Blah is a non-POD as it containes a std::string which isn't a POD.

But yes it doesn't work with non-aggregates, the best you can get
is:

#include <iostream>

template < typename T >
struct default_initialized
{
T item;
default_initialized() : item() {}
};

int main()
{
default_initialized< int > dii;
int &i = dii.item;
std::cout << i << '\n';
}

Rob.

Genuis!

I think that's the one!

-JKop

[JKop]

Tobias Güntner posted:

JKop wrote:

1) The whole "function declaration Vs object definition" fiasco, which
results in the following (temporary creating) syntax:

Blah poo = Blah();

What about this?

struct A
{
int i;
};

template<typename T>
struct DefaultConstruct : public T
{
DefaultConstruct() : T() {}
};

int main()
{
DefaultConstruct<A> a;
assert(a.i == 0);
return 0;
}

Another good suggestion!
-JKop

[JKop]

Old Wolf posted:

JKop <NU**@NULL.NULL> wrote:

1) The whole "function declaration Vs object definition" fiasco, which
results in the following (temporary creating) syntax:

Blah poo = Blah();

How about:
Blah moo;

It's impractical to rely on value-initialization anyway since it
was only introduced in 2003 and compilers may not support it.

I don't subscribe to that.

2) How string literals are not const (even though they are!)

Actually they are. The type of "Hello" is: char const [6].
Try going: "Hello"[1] = 'a';

void Blah(char* const p_k)

Blah("Hello");

You see this result because of the (braindead) rule that
a char const[] can be converted to a (char *) without warning,
if it came from a string literal.

I see!

(Another reason "Hello"[2] = 't'; doesn't work is because it's an r-value)

3) How arrays decay to pointers...

Would you rather write: &foo[0] everywhere you write foo now?

The following is possible:

unsigned &r = *new unsigned;

You have to be mental to write: *new ...
Have you noticed how nobody does it but you?

It's perfectly legal code.
-JKop

[Alf P. Steinbach]

* JKop:

SomeFunctionThatTotallyAltersObjectRegardlessOfIts OriginalState(poo);

Then that function is likely a factory of some description and it's
design is flawed. It should be a function taking no parameters, and
returing a Blah object. *Poof*, no extra constructors with any sort of
decent compiler.

hmm... perhaps.
I'll take an example from Win32.

There's a function called GetVersionEx, like so:

int GetVersionEx(OSVERSIONINFO* p_osv);

where "OSVERSIONINFO" is a POD.

You use the function as follows:

int main()
{
OSVERSIONINFO osv;

GetVersionEx(&osv);
}
It would be inefficient if you did:

int main()
{
OSVERSIONINFO osv = OSVERSIONINFO();

GetVersionEx(&osv);
}
But then again you have the argument that it should be:

OSVERSIONINFO GetVersionEx();
But... that can create a temporary.

If I understand you correctly you want a mechanism that lets
the function produce an object with no extra initialization since
the function will be providing that. I.e., for a non-POD the function
should be the one calling the constructor, being given just the raw
storage, and for a POD the function will be initializing everything.
And presumably this should be type-safe, i.e. not placement new.

A type-safe solution requires a logical OUT-argument, and currently the
only C++ mechanism for that which the compiler recognizes as such is the
function return value. Since the argument passing syntax of C++ is at a
lower level than IN, OUT or INOUT it's not likely that any future versions
of the language will add support for other arguments. However it could
happen, e.g. via function attributes, which I think would be a Good Idea.

The problem with a possible temporary can be solved by new language
features such as Named Return Value Optimization. Compilers that
implement NRVO such as g++ already solve this problem, but it's not
yet standard. I'd hoped that NRVO plus a host of other things such as
non-returning function, DBC statements, calling convention etc., would be
incorporated into a general function/class attribute scheme, but...

Another more practical solution is to note that for many classes of
interest, such as std::vector, there is construction to a natural
default state (e.g. empty vector) that is efficient.

For such classes the problem is more of an academic one.

--
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?

[Chris Theis]

"JKop" <NU**@NULL.NULL> wrote in message
news:IB*******************@news.indigo.ie...

Snipped loads and loads and loads of bullshit.

So you hate C. Your examples have no C++ in them. You must learn to
live with it, and be a happy Java/C#/Perl/other-scripting-language
programmer. It's not so bad. They say.

C is irrelevant here.
I'm talking about C++. Get with the program (no pun intended).
Asshole.

Probably, you SHOULD consider revising your attitude towards other people
and your elocution here. Well, C++ is not perfect and the issues you
mentioned are nothing new, can be found on various websites and the majority
of the people around here are well aware of these problems. However, nobody
forces you to subject to the language and its deficencies, which are
sometimes arguable as you can see from the various replies.

Cheers
Chris

P.S.: BTW, ever heard of anger management?

[Chris Theis]

"Alf P. Steinbach" <al***@start.no> wrote in message
news:41***************@news.individual.net...
[SNIP]

The problem with a possible temporary can be solved by new language
features such as Named Return Value Optimization. Compilers that
implement NRVO such as g++ already solve this problem, but it's not
yet standard. I'd hoped that NRVO plus a host of other things such as
non-returning function, DBC statements, calling convention etc., would be
incorporated into a general function/class attribute scheme, but...

[SNIP]

NRVO is implemented on the optimization level of the compilers (like GNU, VS
2003, Zortech, etc.), but are there really intentions to incorporate this as
a language feature, that go beyond disucssions? I haven´t yet heard of such
plans but if you know more, please let me know.

Cheers
Chris

[Alf P. Steinbach]

* Chris Theis:

"Alf P. Steinbach" <al***@start.no> wrote in message
news:41***************@news.individual.net...
[SNIP]

The problem with a possible temporary can be solved by new language
features such as Named Return Value Optimization. Compilers that
implement NRVO such as g++ already solve this problem, but it's not
yet standard. I'd hoped that NRVO plus a host of other things such as
non-returning function, DBC statements, calling convention etc., would be
incorporated into a general function/class attribute scheme, but...

[SNIP]

NRVO is implemented on the optimization level of the compilers (like GNU, VS
2003, Zortech, etc.), but are there really intentions to incorporate this as
a language feature, that go beyond disucssions? I haven´t yet heard of such
plans but if you know more, please let me know.

First, it was perhaps wrong of me to state that g++ implements NRVO. g++ had
that feature in version 2.95, see <url:
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC106>, but it's now
deprecated and according to the documentation "removed". However there's
RVO, the automatic optimization without any special syntax.

Regarding plans for NRVO-like things I don't have time to check this out but
the most likely route is probably via moving constructors, for which I believe
there is at least one proposal on the table -- as I understood it at the
time several approaches sort of converged following the debate on Andrei
Alexandrescu's MOJO implementation (which ran into language level problems).

If you care to research the current state I think many would be interested in
reading the results... ;-)

--
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?

[Ron Natalie]

JKop wrote:

struct Blah
{
std::string k;
void* p_t;
};

Blah is not a POD. It is an aggregate.

All POD classes are aggregates.
Not all aggregates are POD.

[Ron Natalie]

Old Wolf wrote:

How about:
Blah moo;

It's impractical to rely on value-initialization anyway since it
was only introduced in 2003 and compilers may not support it.
Value initialization vs. the pre-2003 default initialization is NOT
the issue here. There's no difference in the two for POD types.
The only change was that non-POD types without user declared default
constructors now get their members initialized.

My preferred solution would be for it to be part of the class
definition (because what you are really doing is simulating
a constructor which value-initializes each of its members), eg:

My preferred solution would be for default (or value) initialization to happen
for ALL types consistantly without the current kludge. An explicit
kludge should be used to bypass initialization.

3) How arrays decay to pointers...

Would you rather write: &foo[0] everywhere you write foo now?

Yes I would. Since array's are braindamaged types, I pretty
much write the above anyhow since I use vectors instead. I'd
gladly trade the kludge shortcut conversion from array to pointer
if it meant that arrays followed the rules for copy and assignment
that EVERY other type follows:

int a[3];
int b[3] = { 1,2,3 };
a = b; // ASSIGNMENT
int f(int [3]); // pass by value!
etc..

[Ron Natalie]

Phlip wrote:

Andre Kostur wrote:

struct Blah
{
std::string k;
void* p_t;
};

int main()
{
Blah poo = { std::string("Hello!"), 0 };
}

Uh... that's not a POD.....

Well, I found my 1998 Standard, but I refuse to read it on behalf of this
b.. you know what...

It is an aggregate. The above aggregate initialization is legal. You
can even omit the explicit initializer for p_t.

[Ron Natalie]

Ioannis Vranos wrote:

Since I have been confused, may you state explicitly what do you want to
do exactly:

Default initialise PODs to 0? Default initialise everything to 0?
Something else?

Default initialize the POD. Period.

Other than "that's the way C does it" there isn't any argument
for why it should make a difference if Blah is a pod type or not
as to whether we are going to iniialize it or not,

[Tom Widmer]

On Thu, 14 Oct 2004 11:55:16 GMT, al***@start.no (Alf P. Steinbach)
wrote:

* Chris Theis:

"Alf P. Steinbach" <al***@start.no> wrote in message
news:41***************@news.individual.net...
[SNIP]

> The problem with a possible temporary can be solved by new language
> features such as Named Return Value Optimization. Compilers that
> implement NRVO such as g++ already solve this problem, but it's not
> yet standard. I'd hoped that NRVO plus a host of other things such as
> non-returning function, DBC statements, calling convention etc., would be
> incorporated into a general function/class attribute scheme, but...
> [SNIP]

NRVO is implemented on the optimization level of the compilers (like GNU, VS
2003, Zortech, etc.), but are there really intentions to incorporate this as
a language feature, that go beyond disucssions? I haven´t yet heard of such
plans but if you know more, please let me know.

First, it was perhaps wrong of me to state that g++ implements NRVO. g++ had
that feature in version 2.95, see <url:
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC106>, but it's now
deprecated and according to the documentation "removed".

That was a GCC extension, not NRVO. NRVO is basically the optimization
described in 12.8/15 (IIRC).

However there'sRVO, the automatic optimization without any special syntax.

I believe that G++ does indeed implement NRVO, since 3.2 or 3.3 IIRC.
e.g.

std::string f()
{
std::string s("foo");
return s; //returning named local
}

std::string s = f(); //compiler optimizes away *all* copies.

Tom

[Alf P. Steinbach]

* Tom Widmer:

On Thu, 14 Oct 2004 11:55:16 GMT, al***@start.no (Alf P. Steinbach)
wrote:

* Chris Theis:

"Alf P. Steinbach" <al***@start.no> wrote in message
news:41***************@news.individual.net...
[SNIP]
> The problem with a possible temporary can be solved by new language
> features such as Named Return Value Optimization. Compilers that
> implement NRVO such as g++ already solve this problem, but it's not
> yet standard. I'd hoped that NRVO plus a host of other things such as
> non-returning function, DBC statements, calling convention etc., would be
> incorporated into a general function/class attribute scheme, but...
>
[SNIP]

NRVO is implemented on the optimization level of the compilers (like GNU, VS
2003, Zortech, etc.), but are there really intentions to incorporate this as
a language feature, that go beyond disucssions? I haven´t yet heard of such
plans but if you know more, please let me know.
First, it was perhaps wrong of me to state that g++ implements NRVO. g++ had
that feature in version 2.95, see <url:
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC106>, but it's now
deprecated and according to the documentation "removed".

That was a GCC extension, not NRVO. NRVO is basically the optimization
described in 12.8/15 (IIRC).

Reality is exactly opposite.

The N in NRVO stands for "Named", and the "RV" stands for "Return Value";
the optimization allowed by the standard is RVO.

NRVO is (so far) a language extension, not supported in any way or
allowed for by the standard.
However there's

RVO, the automatic optimization without any special syntax.
I believe that G++ does indeed implement NRVO, since 3.2 or 3.3 IIRC.
e.g.

Reality is exactly opposite.

However, as mentioned in my previous posting, I got that wrong the
first time I mentioned g++.

g++ _had_ NRVO, it doesn't anymore (at least according to the doc).
std::string f()
{
std::string s("foo");
return s; //returning named local
}

std::string s = f(); //compiler optimizes away *all* copies.

Named local has nothing to do with the "N" in "NRVO"; it does not
matter whether the object resides in a named variable or not.

Hth.,

- Alf

--
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?

[Phlip]

Ron Natalie wrote:

Andre Kostur wrote:

struct Blah
{
std::string k;
void* p_t;
};

int main()
{
Blah poo = { std::string("Hello!"), 0 };
}

Uh... that's not a POD.....

Well, I found my 1998 Standard, but I refuse to read it on behalf of this b.. you know what...

It is an aggregate. The above aggregate initialization is legal. You
can even omit the explicit initializer for p_t.

k.

;-)

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Tom Widmer]

On Thu, 14 Oct 2004 15:27:48 GMT, al***@start.no (Alf P. Steinbach)
wrote:

Reality is exactly opposite.
Is not! :b
The N in NRVO stands for "Named", and the "RV" stands for "Return Value";
the optimization allowed by the standard is RVO.

NRVO is (so far) a language extension, not supported in any way or
allowed for by the standard.

I'm afraid your definition of NRVO is wrong. e.g.
http://gcc.gnu.org/ml/gcc/2002-05/msg00272.html
http://gcc.gnu.org/ml/gcc/2002-05/msg00273.html
http://groups.google.co.uk/groups?hl...ws.csrlink.net
or do a search for nrvo or "named return value optimization". I
haven't found a link supporting your definition of NRVO...

Tom

[Ioannis Vranos]

Ron Natalie wrote:

My preferred solution would be for default (or value) initialization to
happen
for ALL types consistantly without the current kludge. An explicit
kludge should be used to bypass initialization.
If you want to default initialise an object to some value consistently,
you can do it.
What we are discussing here are non-sense of the style:
"I want to be able to define a value-intialized object of *any* type.
AnyTypeUnderTheMoon poo = AnyTypeUnderTheMoon();
achieves this. But there's two problems:
A) A temporary.

B) The copy constructor may be private."

Answer:

A) At first we shouldn't initialise like that, but initialise with
values for POD types and nothing else is needed for non-POD types.
The above style initialisation was added for PODs for consistency with
non-PODs when working with templates.

B) If the copy constructor is private, then there is a sound reason for
that.
Yes I would. Since array's are braindamaged types, I pretty
much write the above anyhow since I use vectors instead. I'd
gladly trade the kludge shortcut conversion from array to pointer
if it meant that arrays followed the rules for copy and assignment
that EVERY other type follows:

int a[3];
int b[3] = { 1,2,3 };
a = b; // ASSIGNMENT
int f(int [3]); // pass by value!
etc..

An array name is resolved to a pointer to the first element, and this
represents the truth, there is no separate built in array object in the
memory, but only the sequence of the elements.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ron Natalie wrote:

Default initialize the POD. Period.
As I stated in another message, you can initialise any POD to *any*
value already.

Other than "that's the way C does it" there isn't any argument
for why it should make a difference if Blah is a pod type or not
as to whether we are going to iniialize it or not,

Efficiency, safety, logical consistency.

In particular, you are talking about 0 initialisation of a POD and all
its members, and of a non-POD type and its members even in cases where
the constructors provided do otherwise? This does not make sense.

About non-POD types, if you want them simply to be default initialised
to what the provided constructor does, you can simply define the object
without any initialisation syntax.

For syntax consistency in a template function signature for example, you
can default initialise everything with the syntax
T x=T();
What happens if the copy constructor is private? Well, there must be a
sound reason for having that!
In summary, we discuss non-sense here.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ron Natalie]

Ioannis Vranos wrote:

An array name is resolved to a pointer to the first element, and this
represents the truth, there is no separate built in array object in the
memory, but only the sequence of the elements.

No, the array name resolves to the array. The array is a distinct
object, it has a size, you can aggregate them together, make typedefs
of them, etc..

There is an implicit array to pointer conversion that fires off for
almost every practical use.

[Phlip]

Ron Natalie wrote:

Ioannis Vranos wrote:

An array name is resolved to a pointer to the first element, and this
represents the truth, there is no separate built in array object in the
memory, but only the sequence of the elements.

No, the array name resolves to the array. The array is a distinct
object, it has a size, you can aggregate them together, make typedefs
of them, etc..

There is an implicit array to pointer conversion that fires off for
almost every practical use.

Arrays are objects, if you can get around the "decays to a pointer when the
wind blows" issue:

template<class foo, size_t max>
inline size_t
get_count(foo const (&array)[max])
{
return max;
}

(Oh, and my compiler accepts it, so it must be Kosher...;)

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Ioannis Vranos]

Ron Natalie wrote:

No, the array name resolves to the array. The array is a distinct
object, it has a size, you can aggregate them together, make typedefs
of them, etc..

Actually it is a distinct type and not object.

There is an implicit array to pointer conversion that fires off for
almost every practical use.

Yes this "array name to pointer to first element" implicit conversion I
was talking about.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Alf P. Steinbach]

* Tom Widmer:

On Thu, 14 Oct 2004 15:27:48 GMT, al***@start.no (Alf P. Steinbach)
wrote:

Reality is exactly opposite.

Is not! :b

The N in NRVO stands for "Named", and the "RV" stands for "Return Value";
the optimization allowed by the standard is RVO.

NRVO is (so far) a language extension, not supported in any way or
allowed for by the standard.

I'm afraid your definition of NRVO is wrong. e.g.
http://gcc.gnu.org/ml/gcc/2002-05/msg00272.html
http://gcc.gnu.org/ml/gcc/2002-05/msg00273.html
http://groups.google.co.uk/groups?hl...ws.csrlink.net
or do a search for nrvo or "named return value optimization". I
haven't found a link supporting your definition of NRVO...

Well I gave a strongly suggestive one earlier (the GCC docs), but after
checking around I think you're probably right regarding what the acronym
stands for. The gcc docs only talk about "Named Return Value". So then
should we call that NRV? Alfabet soup, grr.

I stand corrected on that, which means what I first wrote about g++
was correct, and my later correction of that, incorrect... :-o

And learned something: §12.8/15 allows NRVO in _addition_ to RVO, that is,
it first allows optimization of any copy construction from a temporary, which
includes the return of a temporary from a function, and then in addition
allows optimization of the return of a named local variable by allowing
the implementation to not create a temporary for the function result. I
thought (mistakenly) these two optimizations were covered by the same text.
I.e. that the standard allowed
T a;
f( T(a) );
to be optimized to
T a;
f( a );
which would have covered the NRVO case. The difference with a return
statement is that without the optimization only the temporary survives,
so there is no possible aliasing problem.

--
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?

[josh]

JKop wrote:

template<class T>
void GiveMeAnyType()
{
char garbage[sizeof T];
T &t = *new(garbage) T();

t.~T();
}

Same as work-around 2, but without no performance issues.

-josh

Are you sure about that?!

Well it's probably a QOI issue, but I would expect the main penalty of
new/delete would be in managing the heap. (The only other thing being
construction and destruction, without which your objects won't work.)
With this you're allocating space on the stack, and telling it to use
that. No heap management.

But no, I'm not 100% sure. :)

-josh

[Ioannis Vranos]

josh wrote:

JKop wrote:

template<class T>
void GiveMeAnyType()
{
char garbage[sizeof T];
T &t = *new(garbage) T();

t.~T();
}

Same as work-around 2, but without no performance issues.

-josh

Are you sure about that?!

Well it's probably a QOI issue, but I would expect the main penalty of
new/delete would be in managing the heap. (The only other thing being
construction and destruction, without which your objects won't work.)
With this you're allocating space on the stack, and telling it to use
that. No heap management.

But no, I'm not 100% sure. :)

Now that I see it, the above is erroneous. It is equivalent to:
T *t=new(garbage) T();

t->~T();

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Old Wolf]

"Phlip" <ph*******@yahoo.com> wrote:

Old Wolf wrote:

I'm not talking about POD-ness (here). The statement Blah foo = Blah();
tests operator= for access before calling the copy constructor.

^^^^^^^^^^^^^^^^^^^^^^^^^^
WRONG. (How many times a week does this issue come up?)

You are answering "does = during initialization call operator=". I have
never once said it did.

You wrote "tests operator= for access". Why would it do that
if it did not (conceptually) call operator= ?

If your compiler fails to compile
T foo = T();
because operator= is private, then it is broken.

If you disagree then please cite a Standard reference.

[Alf P. Steinbach]

* Alf P. Steinbach:

* Tom Widmer:

On Thu, 14 Oct 2004 15:27:48 GMT, al***@start.no (Alf P. Steinbach)
wrote:

Reality is exactly opposite.

Is not! :b

The N in NRVO stands for "Named", and the "RV" stands for "Return Value";
the optimization allowed by the standard is RVO.

NRVO is (so far) a language extension, not supported in any way or
allowed for by the standard.

I'm afraid your definition of NRVO is wrong. e.g.
http://gcc.gnu.org/ml/gcc/2002-05/msg00272.html
http://gcc.gnu.org/ml/gcc/2002-05/msg00273.html
http://groups.google.co.uk/groups?hl...ws.csrlink.net
or do a search for nrvo or "named return value optimization". I
haven't found a link supporting your definition of NRVO...

Well I gave a strongly suggestive one earlier (the GCC docs), but after
checking around I think you're probably right regarding what the acronym
stands for. The gcc docs only talk about "Named Return Value". So then
should we call that NRV? Alfabet soup, grr.

I stand corrected on that, which means what I first wrote about g++
was correct, and my later correction of that, incorrect... :-o

Latest update: when I suggested that RVO and NRVO be included in Bjarne's
C++ glossary he replied NRVO _used_ to refer to (the concept of) the g++
2.95 extension, with AFAHR RVO the term he coined for §12.8/15. So what's
happened seems to have been a change of meaning, e.g. the way it's now used in
the Boost documentation. But now I'm through with correcting my corrections
of my corrections of my corrections of myself -- whatever new info comes to
light re this acronym I promise to not correct this any further!

--
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?

[Old Wolf]

Ron Natalie <ro*@sensor.com> wrote:

Old Wolf wrote:

How about:
Blah moo;

It's impractical to rely on value-initialization anyway since it
was only introduced in 2003 and compilers may not support it.

Value initialization vs. the pre-2003 default initialization is NOT
the issue here. There's no difference in the two for POD types.
The only change was that non-POD types without user declared default
constructors now get their members initialized.

The issue is about all types. For POD types you can go:
Blah moo = { 0 };

3) How arrays decay to pointers...

Would you rather write: &foo[0] everywhere you write foo now?

Yes I would. Since array's are braindamaged types, I pretty
much write the above anyhow since I use vectors instead. I'd
gladly trade the kludge shortcut conversion from array to pointer
if it meant that arrays followed the rules for copy and assignment
that EVERY other type follows:

int a[3];
int b[3] = { 1,2,3 };
a = b; // ASSIGNMENT
int f(int [3]); // pass by value!
etc..

Interesting. Would that break backwards compatibility at all?
(Currently that assignment requires a diagnostic).

[Phlip]

Old Wolf wrote:

You wrote "tests operator= for access". Why would it do that
if it did not (conceptually) call operator= ?
I can think of a reason. I want to deprecate operator=, so I make it private
and compile.

Under the terms of the "Bug++ of the Month" article I read last decade, the
compiler would flag all calls to operator=, and all calls to initializations
that used = even though they directly called copy constructors.

Other than that exceptional case, which implies more support for typesafety
than C++ tends to permit, I can't think of a reason to enforce the rule.
If your compiler fails to compile
T foo = T();
because operator= is private, then it is broken. sigh< The Bug++ article implied VC++ had a bug because it did _not_ flag the access issue.
If you disagree then please cite a Standard reference.

I don't "disagree". I read a Bug++ article, and reported it here, and I
don't have the latest Standard. If I turn out to be right (about the article
or the Standard), I promise not to gloat, but without a real language lawyer
in the house that's unlikely.

I'l write a new post to the moderated newsgroup, untainted by all the
snarling and thrashing here.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Ioannis Vranos]

Alf P. Steinbach wrote:

Latest update: when I suggested that RVO and NRVO be included in Bjarne's
C++ glossary he replied NRVO _used_ to refer to (the concept of) the g++
2.95 extension, with AFAHR RVO the term he coined for §12.8/15. So what's
happened seems to have been a change of meaning, e.g. the way it's now used in
the Boost documentation. But now I'm through with correcting my corrections
of my corrections of my corrections of myself -- whatever new info comes to
light re this acronym I promise to not correct this any further!

It looks like you have fallen into a recursion, and I hope you will not
end up with a stack overflow. :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Tom Widmer]

On Thu, 14 Oct 2004 18:17:39 GMT, al***@start.no (Alf P. Steinbach)
wrote:

And learned something: §12.8/15 allows NRVO in _addition_ to RVO, that is,
it first allows optimization of any copy construction from a temporary, which
includes the return of a temporary from a function, and then in addition
allows optimization of the return of a named local variable by allowing
the implementation to not create a temporary for the function result.

I wrote something like that in my last post, but then deleted it so as
not to muddy the issue of your wrongness. ;)

I also had mentioned that it might have used to be what NRVO referred
to (I didn't know either way), but that this was certainly no longer
the case; I deleted that too.

Damn my overzealous post trimming!

Tom

[JKop]

The issue is about all types. For POD types you can go:
Blah moo = { 0 };

or:

Blah moo = {};
Both work. I myself would prefer the latter, for consistency, as you can
also use it with non-POD aggregates, as in the following:
#include <string>

struct Blah
{
std::string a;
int* b;
};
int main()
{
Blah me = {};
}

[Alf P. Steinbach]

* Tom Widmer:

* Alf P. Steinbach:

And learned something: §12.8/15 allows NRVO in _addition_ to RVO, that is,
it first allows optimization of any copy construction from a temporary, which
includes the return of a temporary from a function, and then in addition
allows optimization of the return of a named local variable by allowing
the implementation to not create a temporary for the function result.
I wrote something like that in my last post, but then deleted it so as
not to muddy the issue of your wrongness. ;)

Well, even though it's OK to be wrong I'm glad it was only an acronym
that had acquired a slightly different meaning the last few years.

I also had mentioned that it might have used to be what NRVO referred
to (I didn't know either way), but that this was certainly no longer
the case; I deleted that too.

Damn my overzealous post trimming!

Too bad...

Now we must all wonder about this...

Cheers,
- Alf

--
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?

[Ron Natalie]

Old Wolf wrote:

Interesting. Would that break backwards compatibility at all?
(Currently that assignment requires a diagnostic).

Unfortunately the major thing it will break is the functions
taking arrays hokum that currently exists.

This really isn't even a C++ issue...the stupidity about arrays
is as equally valid for C. As I said, Dennis addressed almost
the same issues for structs back in 1977. Why he avoided also
fixing arrays at the same time I don't know.

[Ioannis Vranos]

JKop wrote:

The issue is about all types. For POD types you can go:
Blah moo = { 0 };

or:

Blah moo = {};
Both work. I myself would prefer the latter, for consistency, as you can
also use it with non-POD aggregates, as in the following:
#include <string>

struct Blah
{
std::string a;
int* b;
};
int main()
{
Blah me = {};
}

It is the first time I hear something like this. May someone confirm
this possibly providing a reference in the standard?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Carl Muller]

Ioannis Vranos <iv*@guesswh.at.grad.com> wrote in message news:<1097679154.307217@athnrd02>...

JKop wrote:

Any thoughts on why the following is illegal?:
[...]

For the same reason that 6=5; is illegal too.

Not supported by the language.

Hmm, was it Fortran or PL/1 that let you do that, with amusing results? :-)
i.e. numeric literals were converted into (non-const) variables,
like C++ does with string literals.