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

[Stewart Gordon]

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.

[Alf P. Steinbach]

* Richard Herring:

#if hypothetical::h as_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?

[Richard Herring]

In message <41************ ***@news.indivi dual.net>, Alf P. Steinbach
<al***@start.no > writes

* Richard Herring:

#if hypothetical::h as_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

[Ron Natalie]

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.

[Ron Natalie]

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.

[Ron Natalie]

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.

[Steven T. Hatton]

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

[Ioannis Vranos]

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 "Accelerate d C++".

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

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 "Accelerate d C++".

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Phlip]

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 "Accelerate d C++".

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

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