By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,110 Members | 990 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,110 IT Pros & Developers. It's quick & easy.

Things I hate about C++

P: n/a

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
Jul 22 '05 #1
Share this Question
Share on Google+
111 Replies


P: n/a
JKop wrote:
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:
Oh, dear. You have not shown much promise respecting C++, yet you want C++
to respect you.
1) The whole "function declaration Vs object definition" fiasco, which
results in the following (temporary creating) syntax:

Blah poo = Blah();
A> you don't need to do that.

B> the compiler can optimize the temporary away

C> the compiler cannot optimize the = away, so if it's
private that should not compile outside Blah's
internal scope.
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");
}
That's to avoid breaking poor quality C code (like I used to write).
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];
Acolyte of the Week question:

What's this for?

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

Where can you use it? Where can't you use it? How can you improve it?
That's all I can think of right now!


There are plenty of serious issues beyond these things that one could 'lint'
away.

For example, the 'new' you wrote will leak.

(I know I know - the OS Memory Fairy will clean it up...)

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
Jul 22 '05 #2

P: n/a
* JKop:

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

Blah poo = Blah();
A good compiler will not create a temporary here, but you're right: the
C syntax is a fiasco, and IIRC acknowledged as such by the creators.

2) How string literals are not const (even though they are!),
Right. That's old C compatibility for you.

for instance:

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

int main()
{
Blah("Hello");
}
Incorrect. The argument of function Blah should be

void Blah( char const* p_k )

for the intended const'ness effect.
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];
A better (or worse!) example is perhaps
typedef unsigned UnsignedArray[10];

UnsignedArray &r = *(new UnsignedArray);
Again, that's the C heritage.

That's all I can think of right now!


Uhm, well, there's much more. That's the price for compatibility.
Without the compatibility I doubt that C++ would have been very
successful.

--
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?
Jul 22 '05 #3

P: n/a
Oh, dear. You have not shown much promise respecting C++, yet you want
C++ to respect you.
I neither give respect to, nor wish to receive respect from, what does not
qualify as an organism.
1) The whole "function declaration Vs object definition" fiasco, which
results in the following (temporary creating) syntax:

Blah poo = Blah();


A> you don't need to do that.

No comment. No, actually, comment: Bullshit.

B> the compiler can optimize the temporary away

The compiler *may* optimize the temporary away.

C> the compiler cannot optimize the = away, so if it's
private that should not compile outside Blah's
internal scope.

If "what" is private? I presume you're on about the copy contructor.

If you're referring to "=", as in the assignment operator, then don't
respond.

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"); }


That's to avoid breaking poor quality C code (like I used to write).

.. . .and this makes it non-bullshit because?

For example, the 'new' you wrote will leak.

Please don't be stupid. I also didn't mention in my last post that I'd drunk
water in the last 3 days. Does that mean I'm on my way out soon?
-JKop
Jul 22 '05 #4

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

int main()
{
Blah("Hello"); }


Incorrect. The argument of function Blah should be

void Blah( char const* p_k )

for the intended const'ness effect.

You misinterpreted my intention. Here's what I'm doing:
void Blah(char* p_k)
{
*p_k = '4';
}

int main()
{
Blah("Hello");
}
The only reason I put:

void Blah(char* const p_k);
in my previous post is that I put in "const" wherever I can.
Regarding:
char* const p_k
The variable itself is "const", (my function may not and does not change
it), but what it points to is "non-const", (my function is free to change it
if it wishes... and it does!). The thing here is that while "Hello" is in
essence const, it still gets passed as a non-const argument.

So, in summation:

"Hello"

It's type is "char[6]". Note the absence of "const".

While contradictorily (...need me a dictionary...)

char* p = "Hello";

*p = '4';
-JKop
Jul 22 '05 #5

P: n/a

Any thoughts on why the following is illegal?:
struct Blah
{
int a;
char b;

double* p_c;
};
int main()
{
double r;

Blah* p_poo =

new Blah = {5, 't', &r};
}
-JKop
Jul 22 '05 #6

P: n/a
In message <uy*******************@news.indigo.ie>, JKop <NU**@NULL.NULL>
writes
1) The whole "function declaration Vs object definition" fiasco, which
results in the following (temporary creating) syntax:

Blah poo = Blah();


A> you don't need to do that.


No comment. No, actually, comment: Bullshit.
B> the compiler can optimize the temporary away


The compiler *may* optimize the temporary away.


If you're really so concerned about this non-issue, why not just give
your class a constructor that takes a (dummy) argument? Then you can
just write

Blah foo(99);

and all your problems are over.

--
Richard Herring
Jul 22 '05 #7

P: n/a
B> the compiler can optimize the temporary away


The compiler *may* optimize the temporary away.


If you're really so concerned about this non-issue, why not just give
your class a constructor that takes a (dummy) argument? Then you can
just write

Blah foo(99);

and all your problems are over.


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.
Then comes the argument: If the copy constructor is private, then there's a
constructor defined and so it's not a POD and so it doesn't matter if you
value initialize or not. But I want a universal syntax, such that the
following template will work with ALL types. It's not much to ask...

template<class T>
void GiveMeAnyType()
{
T t = T();
}
int main()
{
GiveMeAnyType<std::ostringstream>();
}
Compile error: Copy constructor is private.

-JKop
Jul 22 '05 #8

P: n/a
template<class T>
void GiveMeAnyType()
{
T t = T();
}
int main()
{
GiveMeAnyType<std::ostringstream>();
}
Compile error: Copy constructor is private.

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

Jul 22 '05 #9

P: n/a
In message <vm*******************@news.indigo.ie>, JKop <NU**@NULL.NULL>
writes
B> the compiler can optimize the temporary away

The compiler *may* optimize the temporary away.
If you're really so concerned about this non-issue, why not just give
your class a constructor that takes a (dummy) argument? Then you can
just write

Blah foo(99);

and all your problems are over.


I want to be able to define a value-intialized object of *any* type.

AnyTypeUnderTheMoon poo = AnyTypeUnderTheMoon();
achieves this.


Ah. Now I see the problem - it isn't "your" class at all.
But there's two problems:

A) A temporary.

B) The copy constructor may be private.
Then comes the argument: If the copy constructor is private, then there's a
constructor defined and so it's not a POD and so it doesn't matter if you
value initialize or not. But I want a universal syntax, such that the
following template will work with ALL types. It's not much to ask...


Take a look at boost::type_traits. It may not do exactly what you
require, but some work on those lines may yield what you need -
something on the lines of

#if hypothetical::has_public_copy_ctor<T>::value
T t = T();
#else
T t;
#endif

maybe?
--
Richard Herring
Jul 22 '05 #10

P: n/a
Phlip wrote:
<snip>
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");
}

That's to avoid breaking poor quality C code (like I used to write).

<snip>

And to keep already broken poor quality C code broken.

Actually, whether this works tends to be platform independent. AIUI in
DOS/Windows it tends to work but on Unix-based platforms it tends to bus
error. But even when it does work, it's a bit undefined when the same
string literal may be reused. The compiler ought to at least issue a
warning whenever a string literal is passed into a non-const char *.

Stewart.
Jul 22 '05 #11

P: n/a
* Richard Herring:

#if hypothetical::has_public_copy_ctor<T>::value
T t = T();
#else
T t;
#endif

maybe?


The preprocessor does its processing first, then the "real"
compiler (or, the compiler must ensure a result as if that
was the case).

--
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?
Jul 22 '05 #12

P: n/a
In message <41***************@news.individual.net>, Alf P. Steinbach
<al***@start.no> writes
* Richard Herring:

#if hypothetical::has_public_copy_ctor<T>::value
T t = T();
#else
T t;
#endif

maybe?


The preprocessor does its processing first, then the "real"
compiler (or, the compiler must ensure a result as if that
was the case).

True. Well, I did say "maybe" ;-)

Any suggestions for using template trickery to get the same effect?

--
Richard Herring
Jul 22 '05 #13

P: n/a
JKop wrote:
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();
Actually the real problem is that the
Blah poo;
should universally declare a default initalized Blah, regardless of
what type Blah really is.

None of your headstanding would be necessary if C++ was consistant
in it's behavior.

2) How string literals are not const (even though they are!), for instance:
Yes, the deprecated conversion to lose the const, was a bone thrown to
the whiners in the standardization process. Some didn't want string
literals to be const at all.


3) How arrays decay to pointers...
More specifically, that arrays are bastard types. They don't behave
like other types, in regard to copying and assignment. Once upon a
time both array's and structs lacked proper behavior in this regard.
Dennis fixed structs but the array-to-pointer decay workaround had
already been instituted and rather than bite the bullet and fix it,
C stuck with it.

The following is possible:

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

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


Actually, the bigger issue here is also that C++ dynamic allocation is
also braindead in that it was designed to model the stupid-assed
behavior of malloc / free in a slightly more type safe manner.

Jul 22 '05 #14

P: n/a
Phlip wrote:
Blah poo = Blah();

A> you don't need to do that.


You do if you want a default initalized poo and Blah is of POD type.
B> the compiler can optimize the temporary away
Perhaps.

C> the compiler cannot optimize the = away, so if it's
private that should not compile outside Blah's
internal scop
Huh?

The problem JKop is tripping over is that despite the changes
in the 2003 update to the language, you STILL have to know the
exact nature of Blah to figure out how to default initailize
it properly. We now have three freaking different initialzation
schemes:
1. POD
2. non-POD without a user defined default construcotr
3. non-POD with a user defined default constructor.

There is not even a syntactic device (which JKop has been chasing)
that allows you to universally work around this insanity. It makes
template programming in general a bit difficult if you don't PUNT like
the STL does and insist that you should always be able to copy/assign
a default constructed object to do the initailization.

That's to avoid breaking poor quality C code (like I used to write).

It doesn't avoid breaking it, it just avoids keeping it from compiling
allowing the undefined behavior present to latently sneak by.

Jul 22 '05 #15

P: n/a
Richard Herring wrote:
If you're really so concerned about this non-issue, why not just give
your class a constructor that takes a (dummy) argument? Then you can
just write

Blah foo(99);

and all your problems are over.


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.
Jul 22 '05 #16

P: n/a
JKop wrote:

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:


You really need to look at things in perspective. C has been hugely
successfull. When it was created, the ideas and technology that exists
today were not even dreamed of. A Gig of RAM? A 180 Gig harddrive? Most
people would have laughed in your face if you told them that was possible.
Sure there are some less than ideal features, but to describe these as
"bullshit" is kind insulting to the creators of C.

1) The time it takes to find information such as which function raises an
unsigned int to an exponent of unsigned int, returning unsigned int.

2) The # symbol, and all that is associated with it.

3) No support for introspection.

4) The lack of standard file name extensions.

5) The flat namespace of the Standard Library.

6) The lack of a library resolution mechanism

That's all I can think of right now. The second item is by far the biggest
gripe I have.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

Jul 22 '05 #17

P: n/a
JKop wrote:
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();

You do not have to use that. Use Blah poo; If you want to zero
initialise a POD type do it explicitly,
E.g.

Blah poo = {0};


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");
}
char * const p; is a const pointer, which cannot point anywhere else.

const char *p; is a pointer which points to a const object.
const char * const p; is a const pointer which cannot point anywhere
else, and points to a const object.




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];

What's that suppose to mean? You can do:

unsigned &r = *new unsigned[10];
However why do this tricky stuff?
That's all I can think of right now!

My suggestion is have a slow thorough read of an up to date ISO C++
book, like "Accelerated C++".

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #18

P: n/a
JKop wrote:
Any thoughts on why the following is illegal?:
struct Blah
{
int a;
char b;

double* p_c;
};
int main()
{
double r;

Blah* p_poo =

new Blah = {5, 't', &r};
}

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

Not supported by the language.
My suggestion is have a slow thorough read of an up to date ISO C++
book, like "Accelerated C++".

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #19

P: n/a
Ioannis Vranos wrote:
JKop wrote:
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();

You do not have to use that. Use Blah poo; If you want to zero
initialise a POD type do it explicitly,
E.g.

Blah poo = {0};


A POD non-virtually inheriting a POD is still a POD, but can't use that
notation.

JKop is recommended to write complete constructors, and to encapsulate
low-level things that need PODs behind interfaces that ensure they are used
correctly.

And if Blah::operator=(Blah const &); were private, that expression wouldn't
compile outside Blah's internal scope, even though operator= should not
during construction.
My suggestion is have a slow thorough read of an up to date ISO C++
book, like "Accelerated C++".


Jee, I don't think we ever recommended this to JKop before!!

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
Jul 22 '05 #20

P: n/a
Ron Natalie wrote:
Actually the real problem is that the
Blah poo;
should universally declare a default initalized Blah, regardless of
what type Blah really is.

Check this:

http://groups.google.com/groups?hl=e...rldnet.att.net


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #21

P: n/a
Phlip wrote:
E.g.

Blah poo = {0};

A POD non-virtually inheriting a POD is still a POD, but can't use that
notation.

May you provide an example?
JKop is recommended to write complete constructors, and to encapsulate
low-level things that need PODs behind interfaces that ensure they are used
correctly.

And if Blah::operator=(Blah const &); were private, that expression wouldn't
compile outside Blah's internal scope, even though operator= should not
during construction.

I don't understand what you mean here too. May you provide an example?

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #22

P: n/a
Phlip wrote:
A POD non-virtually inheriting a POD is still a POD, but can't use that
notation.

It is not still a POD. A POD class must meet the requirements
of an aggregate. An aggregeate can not have base classes.

It is because it is no longer an aggregate that you can't use the
aggregate initializer { 0 } to initialize it.
Jul 22 '05 #23

P: n/a
Ioannis Vranos wrote:

Check this:

http://groups.google.com/groups?hl=e...rldnet.att.net

I am well aware that is the argument. I even alluded to it in one of JKop's
other postings. I still do not agree. If you want to have data types that
violate the general language conventions by skipping initialization, my assertion
is that you should have to designate that explicitly.

The concept that C++ is just a C compiler with extra class stuff has been
left behind long ago. While that argument held back in the ARM days, I
contend it isn't valid anymore.

NOTHING prohibits the compiler from initalizing data now, so there is no
performance guarantee. The small number of applications that RELY on
the performance of uninitialized data would have a way of explicitly
speicifying this under the new scheme which they do not have now.
Jul 22 '05 #24

P: n/a
Ioannis Vranos wrote:
Phlip wrote:
E.g.

Blah poo = {0};

A POD non-virtually inheriting a POD is still a POD, but can't use that
notation.

May you provide an example?


Nope - I ain't got The Standard, so all I would have is a
POD-which-can't-be-aggregate-initialized, which Ron would claim is a
non-POD.
JKop is recommended to write complete constructors, and to encapsulate
low-level things that need PODs behind interfaces that ensure they are used correctly.

And if Blah::operator=(Blah const &); were private, that expression wouldn't compile outside Blah's internal scope, even though operator= should not
during construction.


I don't understand what you mean here too. May you provide an example?


You are thinking too hard. Start with this:

"if operator= is private, you can't initialize with = notation"

class Blah
{
Blah & operator=(Blah const &); // <-- private
...
};
...

Blah foo = Blah(); // <-- compiler error

If operator= were public, it should not be called (and some compilers will
call it). If it were private, the line should not compile.

However, my quoted text is still incomplete. You could write a method on
Blah, and call = inside it. So, my earlier text is more accurate and more
confusing.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
Jul 22 '05 #25

P: n/a
Phlip wrote:

Nope - I ain't got The Standard, so all I would have is a
POD-which-can't-be-aggregate-initialized, which Ron would claim is a
non-POD.
POD classes have to be aggregates (see paragraph 2 of Chapter 9 of
the standard). Aggregates can't have base classes (8.5.1).
If you have a base class, it is NOT POD.
"if operator= is private, you can't initialize with = notation"


operator= has nothing to do with it. Despite the fact that the symbol
= is there, the operation isn't assignmenbt it's COPY INITIALIZATION.
This means that if the copy constructor is private, you can't initalize
with the = notation.
Jul 22 '05 #26

P: n/a
JKop wrote:
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:
Have you tried decaf?
1) The whole "function declaration Vs object definition" fiasco, which
results in the following (temporary creating) syntax:

Blah poo = Blah();
Is it *that* hard to learn? I bet you have not every tried to declare a
pointer to a function returning a pointer to a member function returning a
function pointer. Without typedefs.
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");
}
??? No compiler should compile the above without giving proper diagnostics.
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];
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.
That's all I can think of right now!


Then you better get a life.

--
WW aka Attila
:::
I keep trying to lose weight but it always finds me.
Jul 22 '05 #27

P: n/a
Phlip wrote:
You are thinking too hard. Start with this:

"if operator= is private, you can't initialize with = notation"

class Blah
{
Blah & operator=(Blah const &); // <-- private
...
};
...

Blah foo = Blah(); // <-- compiler error

If operator= were public, it should not be called (and some compilers will
call it). If it were private, the line should not compile.

However, my quoted text is still incomplete. You could write a method on
Blah, and call = inside it. So, my earlier text is more accurate and more
confusing.

Ron Natalie explains it well in his answer.
Assignment upon definition (initialisation) for non-POD types calls
*always* the copy constructor.

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #28

P: n/a
JKop wrote:
Oh, dear. You have not shown much promise respecting C++, yet you want
C++ to respect you.
I neither give respect to, nor wish to receive respect from, what does
not qualify as an organism.


People who have designed it do.

[SNIP] No comment. No, actually, comment: Bullshit. [SNIP] . . .and this makes it non-bullshit because?


Do you have some special relation to that word? Like is it your family name
or something? Or are you simply trolling, because you feel like it.

--
WW aka Attila
:::
One of the few things that rivals a sore loser is an arrogant winner.
Jul 22 '05 #29

P: n/a
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.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
Jul 22 '05 #30

P: n/a
White Wolf wrote:
=

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

int main()
{
Blah("Hello");
}

??? No compiler should compile the above without giving proper diagnostics.


No diagnostic is required above. It's well-formed but undefined behavior.

Jul 22 '05 #31

P: n/a
Ron Natalie wrote:
White Wolf wrote:
=

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

int main()
{
Blah("Hello");
}

??? No compiler should compile the above without giving proper
diagnostics.


No diagnostic is required above. It's well-formed but undefined
behavior.


Did I say it is required? ;-) You take my fun away! :-)

--
WW aka Attila
:::
Life's unfair - but root password helps!
Jul 22 '05 #32

P: n/a
Phlip 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.

No it does not. It doesn't give a hoot about the assignment operator.
It doesn't check it's accessibility and is NOT allowed to call it.
It tests the access of the copy constructor (even if it doesn't end up
having to use it).

Jul 22 '05 #33

P: n/a
Ron Natalie wrote:
Phlip 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.

No it does not. It doesn't give a hoot about the assignment operator.
It doesn't check it's accessibility and is NOT allowed to call it.
It tests the access of the copy constructor (even if it doesn't end up
having to use it).


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.

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

Jul 22 '05 #34

P: n/a
Ron Natalie posted:
Richard Herring wrote:
If you're really so concerned about this non-issue, why not just give
your class a constructor that takes a (dummy) argument? Then you can
just write

Blah foo(99);

and all your problems are over.


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.

I like you!
-JKop
Jul 22 '05 #35

P: n/a
White Wolf posted:
JKop wrote:
Oh, dear. You have not shown much promise respecting C++, yet you
want C++ to respect you.


I neither give respect to, nor wish to receive respect from, what does
not qualify as an organism.


People who have designed it do.

[SNIP]
No comment. No, actually, comment: Bullshit.

[SNIP]
. . .and this makes it non-bullshit because?


Do you have some special relation to that word? Like is it your family
name or something? Or are you simply trolling, because you feel like
it.


I feel that that word acurately conveys my attitude, perogative and general
feeling about particular subjects.

-JKop
Jul 22 '05 #36

P: n/a
Ioannis Vranos posted:
JKop wrote:
Any thoughts on why the following is illegal?:
struct Blah
{
int a;
char b;

double* p_c;
};
int main()
{
double r;

Blah* p_poo =

new Blah = {5, 't', &r}; }

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

Not supported by the language.
My suggestion is have a slow thorough read of an up to date ISO C++
book, like "Accelerated C++".


I'll rephrase the question:

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

And please for the love of God don't direct me to comp.lang.standard.c++ (or
whatever it's called)
-JKop

Jul 22 '05 #37

P: n/a
Actually the real problem is that the
Blah poo;
should universally declare a default initalized Blah, regardless of
what type Blah really is.


I disagree.

Efficiency all the way. If you don't need it to be default initialized,
value initialized (whatever you want to call it), then I believe that you
should have the choice.

Consider the following:

Blah poo;

SomeFunctionThatTotallyAltersObjectRegardlessOfIts OriginalState(poo);
A default initialization in the above would be inefficient.

3) How arrays decay to pointers...


More specifically, that arrays are bastard types. They don't behave
like other types, in regard to copying and assignment. Once upon a
time both array's and structs lacked proper behavior in this regard.
Dennis fixed structs but the array-to-pointer decay workaround had
already been instituted and rather than bite the bullet and fix it,
C stuck with it.


Bastards!

The following is possible:

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

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


Actually, the bigger issue here is also that C++ dynamic allocation is
also braindead in that it was designed to model the stupid-assed
behavior of malloc / free in a slightly more type safe manner.


hmm...

Well I would agree that there's not much reason for it to return a pointer
instead of a reference... "*new AnyClass" is the next best thing. I myself
*always* use references where I can ( I also specify "const" wherever I can
).
-JKop

Jul 22 '05 #38

P: n/a
NOTHING prohibits the compiler from initalizing data now, so there is
no performance guarantee. The small number of applications that RELY
on the performance of uninitialized data would have a way of explicitly
speicifying this under the new scheme which they do not have now.


Sounds good:

AnyClass uninit poo;
-JKop

Jul 22 '05 #39

P: n/a
Blah poo = {0};

struct Blah
{
std::string a;

int* b;
};

int main()
{
Blah poo = {0};
}
Opps!
-JKop
Jul 22 '05 #40

P: n/a
JKop wrote in news:xL*******************@news.indigo.ie in comp.lang.c++:
Blah poo = {0};

struct Blah
{
std::string a;

int* b;
};

int main()
{
Blah poo = {0};
}


#include <iostream>
#include <string>

struct Blah
{
std::string a;

int* b;
};

int main()
{
Blah poo = {};
std::cout << poo.b << '\n';
}
Rob.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #41

P: n/a
Nope - I ain't got The Standard, so all I would have is a
POD-which-can't-be-aggregate-initialized, which Ron would claim is a
non-POD.


There is no POD which cannot be aggregate initialized.

#include <string>

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

int main()
{
Blah poo = { std::string("Hello!"), 0 };
}
Jul 22 '05 #42

P: n/a
Phlip posted:
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.


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

-JKop
Jul 22 '05 #43

P: n/a
Blah poo = {};

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

P: n/a
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.
-JKop
Jul 22 '05 #45

P: n/a
* 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.

--
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?
Jul 22 '05 #46

P: n/a
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;
}

--
Regards,
Tobias
Jul 22 '05 #47

P: n/a
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.

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:

struct value_initialized Blah
{
int x;
}
and whenever a Blah is created by the default constructor,
x is set to 0.
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.
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?
But the following is not:

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


'new unsigned' returns a pointer to unsigned.
So you clearly cannot bind a reference-to-array to it.
Arrays are not pointers.

Also you should not whinge about C++ 'bullshit' when C++ has
provided an improvement over the behaviour inherited from C.
Your complaints 2 and 3 are best solved by use of std::string
and std::vector. Would you call Windows bullshit because you
can't write green text in Notepad? No, you would load Wordpad
or some other editor.
Jul 22 '05 #48

P: n/a
JKop <NU**@NULL.NULL> wrote in news:0x*******************@news.indigo.ie:
Nope - I ain't got The Standard, so all I would have is a
POD-which-can't-be-aggregate-initialized, which Ron would claim is a
non-POD.


There is no POD which cannot be aggregate initialized.

#include <string>

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

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


Uh... that's not a POD.....
Jul 22 '05 #49

P: n/a
JKop <NU**@NULL.NULL> wrote in
news:uG*******************@news.indigo.ie:
Actually the real problem is that the
Blah poo;
should universally declare a default initalized Blah, regardless of
what type Blah really is.


I disagree.

Efficiency all the way. If you don't need it to be default
initialized, value initialized (whatever you want to call it), then I
believe that you should have the choice.

Consider the following:

Blah poo;

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.
Jul 22 '05 #50

111 Replies

This discussion thread is closed

Replies have been disabled for this discussion.