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]

Ioannis Vranos wrote:

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();

Well, yeah. I don't understand, does the reference make it invalid?

-josh

[Ioannis Vranos]

josh wrote:

Now that I see it, the above is erroneous. It is equivalent to:

T *t=new(garbage) T();

t->~T();

Well, yeah. I don't understand, does the reference make it invalid?

No the reference itself. However, as far as I have understood, the
manual destruction approach you use is used when you provide a
definition of the placement new yourself, and thus you have to provide
the destruction details in a destruction function, such as the one you
provided along with other ones. For example, consider creating a char
array with new in your explicit placement new definition, and in the
destruction function e.g. Delete() you do
t->~T();

delete charArray[];

When you do not provide a placement new definition explicitly a simple
call to (placement) delete will suffice:

#include <new>
class SomeClass{};

int main()
{
using namespace std;

char garbage[sizeof(SomeClass)];

SomeClass *t = new(garbage) SomeClass;

delete t;
}

Others may provide more insight on this.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Rob Williscroft]

Ioannis Vranos wrote in news:1097866747.581840@athnrd02 in comp.lang.c++:

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?

8.5.1/7 & 8. I searched for aggregates, took about two minuites.

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

[Ioannis Vranos]

Rob Williscroft wrote:

8.5.1/7 & 8. I searched for aggregates, took about two minuites.

OK, thanks a lot.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Richard Herring]

In message <2d**************************@posting.google.com >, Carl
Muller <ca********@hotmail.com> writes

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

Neither of the above IIRC - both languages have far too much syntax to
allow that kind of error. But I recall this trick being used in one of
those languages with almost no syntax (probably a variety of Lisp, or
possibly Forth) where it was faster to treat small integers as "const
variables".
i.e. numeric literals were converted into (non-const) variables,
like C++ does with string literals.

And BCPL did for labels ;-)

--
Richard Herring

[Jerry Coffin]

ca********@hotmail.com (Carl Muller) wrote in message news:<2d**************************@posting.google. com>...

[ ... ]

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.

Neither supported it this directly. OTOH, FORTRAN (this LONG before
anybody considered it proper to use lower-case of its name) did allow
you to do it indirectly. To make it happen, you had to write a
function that modified a parameter, and then pass a constant as the
parameter. It only supported something along the lines of pass by
reference, so modifying the value in the function/subroutine modified
it elsewhere...

--
Later,
Jerry.

The universe is a figment of its own imagination.

[JKop]

Found another one!
int a = 5; //This is a definition

extern int a; //This is a declaration

extern int a = 5; //This is a definition
And there I was thinking that "extern" always meant declaration!
To mess things up even further:
int const a = 5; //This is a definition, but...
//it has the same effect as:

static int const a = 5;
extern int const a; //This is a declaration
extern int const a = 5; //This is a definition
So... if you want to have a const global string to hold the name of your
application, it looks like so:
//gobalobjects.hpp

#ifndef INCLUDE_GLOBAL_OBJECTS
#define INCLUDE_GLOBAL_OBJECTS

extern char const g_application_name[];

#endif
//globalobjects.cpp

#include "globalobjects.hpp"

extern char const g_application_name[] = "ChocolateMonkey";
-JKop

[JKop]

Spoke too soon!

Scenario:

You want a const global variable. You want to use the default constructor
(ie. no arguments) for this object.
Attempt:
#include <string>

extern std::string const poo;

int main()
{
std::string k = poo;
}
It can't be done!

(BTW, Microsoft's compiler *does* compile this with no errors. Funny though,
as there's no definition of "poo".)
Note that the following:

extern std::string const poo();

is a function declaration.

-JKop

[JKop]

Yet another work-around:
#include <string>

template<class T>
class DefaultConstructed_DummyParameter : public T
{
public:

DefaultConstructed_DummyParameter(int) : T() {}
};
extern DefaultConstructed_DummyParameter<std::string> const poo;
//Declaration

extern DefaultConstructed_DummyParameter<std::string> const poo(0);
//Definition
int main()
{
std::string k( poo );
}

But hey, it works!
-JKop

[Ron Natalie]

JKop wrote:

And there I was thinking that "extern" always meant declaration!
Nope, it's a linkage specification. The real confusing one is static,
that keyword has multiple meanings in different contexts.

To mess things up even further:
int const a = 5; //This is a definition, but...
//it has the same effect as:

static int const a = 5;
Correct, the const integrals have internal linkage by default. That is
inconsistant but the C++ standardizers were loath to have to type an
extra word. The language assumes compilers can deal with integers
all the time, even in cross-compilation environments. Floats however,
aren't required to have compile-time calculation support.
So... if you want to have a const global string to hold the name of your
application, it looks like so: extern char const g_application_name[] = "ChocolateMonkey";

What is the issue? You don't need to repeat the extern.
This is no different than any other external linkage object declaration
and definition?

Do you understand that declaration / definition and linkage are distict
concepts?

[JKop]

extern char const g_application_name[] = "ChocolateMonkey";
What is the issue? You don't need to repeat the extern.
This is no different than any other external linkage object declaration
and definition?

Do you understand that declaration / definition and linkage are distict
concepts?

OOkkaayy, I'm getting a bit lost here...

"You don't need to repeat the extern"

I take it that you're refering to a declaration of the object. If so, I
don't understand. If you have the following:

//a.cpp

extern char const g_application_name[] = "ChocolateMonkey";

//b.cpp

extern char const g_application_name[];
Then all is well, "a.cpp" defines the object, while "b.cpp" merely declares
it. But... if (as you suggested... I think) you omit "extern", as follows:

//a.cpp

extern char const g_application_name[] = "ChocolateMonkey";

//b.cpp

char const g_application_name[];
then... Compile Error!
-JKop

[Ioannis Vranos]

JKop wrote:

Found another one!
int a = 5; //This is a definition

extern int a; //This is a declaration

extern int a = 5; //This is a definition

Consistency, see below.



And there I was thinking that "extern" always meant declaration!
To mess things up even further:
int const a = 5; //This is a definition, but...
//it has the same effect as:

static int const a = 5;
extern int const a; //This is a declaration
extern int const a = 5; //This is a definition

There is a reason for this. It is about the same thing with inline
functions. If it is not extern, the compiler can easily optimise away
the variable with the value itself when the constant is assigned to
another object.
Check my other message in the thread "Global const strings" where it is
mentioned that global constants are better to be placed in header files.

--
Ioannis Vranos

http://www23.brinkster.com/noicys