The worst things about C++

[Steven T. Hatton]

Re: The worst things about C++

John Carson wrote:

"Steven T. Hatton" <chattengau@ger mania.supwrote in message
news:EYmdnS3egq VHiubYnZ2dnUVZ_ tunnZ2d@speakea sy.net

>No, this is not a troll

>
Perish the thought.
>
The reality is that C++ is likely to be obsolete long before there is any
chance of your list of desired changes being implemented.

Did I recommend any changes in the Standard?

The next version
of the standard is still years away and won't come close to addressing
your wish list.

The version after that, if there is one, will be another
10 years or so further on, and it's anyone's guess what changes might be
made. The computing environment will have changed beyond recognition
before there is any chance of the preprocessor being abolished.
>
So what is the point of endlessly banging on about what you don't like
about C++? Learn it, live with it, and get on with it --- or use some
other language.

Uh, I am investing my time in learning C++. If C++ is considered too
difficult to be worth learning, then people and projects will move to other
languages. That means my options become more limited.

The biggest problem with all of the features I mentioned is that many C++
programmers really don't care if they abuse them. They don't even
understand what that means.

--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

[Noah Roberts]

Re: The worst things about C++


Mathias Gaunard wrote:

I see nothing really problematic with functions pointers though.

Man, you guys are spending way too much time on this...

There's nothing problematic about function pointers beyond not really
being able to interchange them. The new function object being added to
the standard is a much better abstraction. Unfortunately for the OP it
uses pounds upon pounds of template magic to do so.

[red floyd]

Re: The worst things about C++

Evan wrote:

red floyd wrote:

>Duane Hebert wrote:
>>

>>A) std::limits<Any integral type>::min() returns the
>>minimum value the type can hold but that with floating point types
>>it returns the smallest positive value. Makes it hard to write templates
>>dealing with ranges. Couldn't there be std::limits<dou ble>::smallest ?
>>>

>I'm not sure this is a wart. Since since most floating reps (does the
>Standard mandate IEEE-754?) use a separate sign bit, the minimum value
>of a floating type is -std::limits<flo ating_point_typ e_t>::max().

>
I think the poster knows that.. what Kai-Uwe is saying is that you
can't just write std::limits::mi n() for the minimum value generically.
Which means that if you have a template that takes a type T and you
need to find the minimum value T can take on, you can't do it
generically, because std::limits<T>: :min won't give it to you in all
cases.
>
It makes generic programming harder, NOT determining the minimum FP
value harder.

Ah, now I see your (and Duane's) point. Good call. My mistake.

[Steven T. Hatton]

Re: The worst things about C++

Noah Roberts wrote:

>
Mathias Gaunard wrote:
>

>I see nothing really problematic with functions pointers though.

>
Man, you guys are spending way too much time on this...
>
There's nothing problematic about function pointers beyond not really
being able to interchange them. The new function object being added to
the standard is a much better abstraction.

Care to provide a reference to the proposal?

Unfortunately for the OP it uses pounds upon pounds of template magic to
do so.

Anything like what is describe in Chapter 22 of _C++ Templates: The Complete
Guide_? I have to confess I haven't studied it closely.

--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

[Kai-Uwe Bux]

Re: The worst things about C++

Mathias Gaunard wrote:

Kai-Uwe Bux wrote:
>

>a) 8.3.5/5, in particular the rule about initialization of const
>references and the fact that one cannot bind temporaries to non-const
>references.

>
That makes perfectly sense though.
Why should you be allowed to modify rvalues?

You can already call a non-const member function of a temporary.

To help hell break loose?

No, but, e.g., to make working with proxy classes easier. Also, I just find
it silly that I can do

std::vector<int >().swap( some_int_vector );

but neither

std::swap( std::vector<int >(), some_int_vector );

nor

some_int_vector .swap( std::vector<int >() );

_Modifying_ temporaries is perfectly fine. I do it all the time. Hell does
not break loose. I do not see why _binding_ temporaries to non const
references is not fine. (I agree that there is a problem that arises from
temporaries created by automatic type conversion/promotion.)

>b) that typeid returns a by and large useless type_info object where it
>could return a full-fledged type object that would allow for
>introspectio n and allocation/construction of variables of that type.

>
To return useful information it would need to store them somewhere.

True. However, this information could be optimized away by the compiler if
global data flow analysis reveals that it's not used anywhere in the
compilation unit.

>

>c) that I cannot overload the dot operator, e.g., so that I could have
>smart references or _1.member_funct ion() in lambda.

>
That could have been nice, indeed.
But no good way was thought of.

Sad but true.

>>
>d) that C++ doesn't have virtual member templates.

>
This is not trivial to implement.
Implementors already had enough problems with export, so it is hard
asking for features needing collaborative work of both the compiler and
linker.

I know, it's tricky. Nonetheless, I'd love to have them.

>f) that the standard is worded according to the philosophy "when in
>doubt, declare the behavior undefined".
>>

>
You're confusing undefined and unspecified.

I don't think so.

And it has nothing to do with doubts.

That, maybe.

>g) that the standard library components have too restrictive
>requirements , e.g., list<Trequires the type T to be complete.

>
Variables should be perfectly workable upon declaration.
Since list<Tis a container of T's, T must be complete.
>
Recursive definitions do not really play well with this, indeed.

Well, the following compiles and works as expected with g++ (and I would
predict with most STL implementation) :

#include <iostream>
#include <iterator>
#include <algorithm>
#include <list>

class recursive_list {

std::list< recursive_list the_list;

public:

friend
std::ostream & operator<< ( std::ostream & o_str,
recursive_list const & rl ) {
if ( rl.the_list.emp ty() ) {
o_str << "[]";
} else {
o_str << "[ ";
std::copy ( rl.the_list.beg in(),
rl.the_list.end (),
std::ostream_it erator<recursiv e_list>
( std::cout, " " ) );
o_str << "]";
}
return ( o_str );
}

void push_back ( recursive_list const & rl ) {
the_list.push_b ack( rl );
}

};

int main ( void ) {
recursive_list const empty_list;
recursive_list r1;
r1.push_back( empty_list );
r1.push_back( empty_list );
r1.push_back( empty_list );
r1.push_back( r1 );
r1.push_back( empty_list );
r1.push_back( empty_list );
r1.push_back( empty_list );
std::cout << r1 << '\n';
}

Intended output: [ [] [] [] [ [] [] [] ] [] [] [] ]

So it is possible (and already usual) to implement std::list<the way I
would like. However, the code above has undefined behavior according to the
standard and is not even required to compile (but is permitted to): and
indeed, the code fails to compile when I build g++ with concept_checks
enabled.

>h) that there is no integral type or typedef guaranteed to be long enough
>to hold a void*, and that there is no useful conversion to integral types
>for function and member function pointers.

>
There is one in the next standard.

That's good to know.

>A) that there is no guarantee that one can derive from standard
>container/iterator classes.

>
Of course you can.
It's just that members aren't virtual, so you can't do polymorphism with
them.

You can in all implementations that I have seen so far, yet there is no
guarantee in the standard. The type std::vector<T>: :iterator is marked as
implementation defined: (a) it could be T* or (b) it could use a virtual
base trick to prevent derivation. At least the second point goes for all
iterator types. With regard to the container classes, I might be paranoid
in thinking that they could legally prevent derivation.

>B) that signed integral types make virtually no useful guarantees, and
>that std::limits does not provide enough information to work around that
>problem.

>
C++ only allow three ways to represent signed integrals.

Really? I recall that I once tried to deduce that from the standard and
that I failed.

>C) that there is no arbitrary precision / big integer class and no matrix
>/ tensor template in the standard.

>
Those are available in third party libraries.

True. However, this kind of thing can benefit tremendously from support by
compiler magic. In addition, standardization has more benefits that
providing availability. Anyway, the availability of third party libraries
makes this a minor nuisance, and I have already qualified this item as
such.

>D) that there is no window / gui support in the standard.

>
This is heavily platform specific.

So is IO. Yet still, the standard provides means for IO. Again, this is a
minor nuisance, and I might be argued that C++ could drop IO facilities
from the standard altogether.


Best

Kai-Uwe Bux

[Kai-Uwe Bux]

Re: The worst things about C++

Steven T. Hatton wrote:

Noah Roberts wrote:
>

>>
>Mathias Gaunard wrote:
>>

>>I see nothing really problematic with functions pointers though.

>>
>Man, you guys are spending way too much time on this...
>>
>There's nothing problematic about function pointers beyond not really
>being able to interchange them. The new function object being added to
>the standard is a much better abstraction.

>
Care to provide a reference to the proposal?

TR1 section 3, in particular 3.7 (polymorphic function wrappers).

>Unfortunatel y for the OP it uses pounds upon pounds of template magic to
>do so.

>
Anything like what is describe in Chapter 22 of _C++ Templates: The
Complete Guide_? I have to confess I haven't studied it closely.

tr1::function< some_function_c all_signature is a class that can hold any
entity that you can use as the function object in a function call
conforming to the specified signature. I don't know whether what is in
chapter 22 conforms to that description.

Here is a baby version for unary functions just to demonstrate the kind of
combination of virtual functions and templates that goes into wrappers like
this:

template < typename R, typename T >
class unary_function_ wrapper;

template < typename R, typename T >
void swap ( unary_function_ wrapper<R,T& a,
unary_function_ wrapper<R,T& b ) {
kubux::swap( a.f_ptr, b.f_ptr );
}

template < typename R, typename T >
class unary_function_ wrapper
: public std::unary_func tion< R, T >
{

friend
void swap<( unary_function_ wrapper &, unary_function_ wrapper & );

struct base
: public std::unary_func tion< R, T >
{

virtual
T operator() ( R ) = 0;

virtual
~base ( void ) {}

virtual
base* clone ( void ) const = 0;

}; // unary_function_ wrapper_base

template < typename F >
struct X : public base {

F f;

X ( F g )
: f ( g )
{}

virtual
T operator() ( R r ) {
return ( f(r) );
}

virtual
X* clone ( void ) const {
return ( new X ( f ) );
}

}; // X

base * f_ptr;

public:

template < typename F >
unary_function_ wrapper ( F f )
: f_ptr ( new X<F( f ) )
{}

unary_function_ wrapper ( unary_function_ wrapper const & other )
: f_ptr( other.f_ptr->clone() )
{}

unary_function_ wrapper & operator=
( unary_function_ wrapper const & other ) {
unary_function_ wrapper dummy ( other );
swap( *this, dummy );
return ( *this );
}

~unary_function _wrapper ( void ) {
delete ( f_ptr );
}

T operator() ( R r ) {
return ( (*f_ptr)( r ) );
}

}; // unary_function_ wrapper


Now, unary_function_ wrapper< int, void can take any object x that can be
called like x(5) and returns void.


Best

Kai-Uwe Bux

[John Carson]

Re: The worst things about C++

"Steven T. Hatton" <chattengau@ger mania.supwrote in message
news:MpGdnausLs Hi0-HYnZ2dnUVZ_oS3n Z2d@speakeasy.n et

>
Uh, I am investing my time in learning C++. If C++ is considered too
difficult to be worth learning, then people and projects will move to
other languages. That means my options become more limited.

And posting about the problems with the precompiler and C++'s compilation
model is going to change that?

The biggest problem with all of the features I mentioned is that many
C++ programmers really don't care if they abuse them. They don't even
understand what that means.

So you hope to improve programming practices in this respect. This will mean
C++ is not considered as difficult to learn and so your options will be
broader. Talk about drawing a long bow!!!!!!!!

Save yourself the trouble and focus your energies on improving your C++
expertise. It will do far more to broaden your options.

--
John Carson

[Signal9]

Re: The worst things about C++


Tony wrote:

"Signal9" <cep_81@msn.com wrote in message
news:1165701250 .306645.13320@8 0g2000cwy.googl egroups.com...
>

Also if
you are new to the technology field and want to become a developer, you
need to learn many techniques and languages. Do not stop and sit with
one language and framework/platform, learn everything you can.

>
Or instead of being a consultant of technology, be someone that can actually
build something with it. With C++, rarely do you have to look anywhere else.
All the time spent learning other languages and stuff doesn't make you as
valuable as one who can apply it to some domain, like scientific computing,
graphics/games, OLTP etc. Do survey the other stuff, but don't waste too
much time trying to learn everything and become too broad to apply anything
"professionally ". (Sure, I could learn German, Spanish and Latin. But I find
English more than adequate for my purposes and I have better things to do!).
>
Tony

and you will be on the corner asking for change when they drop the only
tool you know how to use....

i got 25cents for ya...

[Steven T. Hatton]

Re: The worst things about C++

John Carson wrote:

"Steven T. Hatton" <chattengau@ger mania.supwrote in message
news:MpGdnausLs Hi0-HYnZ2dnUVZ_oS3n Z2d@speakeasy.n et

>>
>Uh, I am investing my time in learning C++. If C++ is considered too
>difficult to be worth learning, then people and projects will move to
>other languages. That means my options become more limited.

>
And posting about the problems with the precompiler and C++'s compilation
model is going to change that?

I've seen a lot of changes take place as a result such observations. One
high-profile project I know of completely reworked their Cpp laden code
base, replacing their macros with templates.

>The biggest problem with all of the features I mentioned is that many
>C++ programmers really don't care if they abuse them. They don't even
>understand what that means.

>
So you hope to improve programming practices in this respect. This will
mean C++ is not considered as difficult to learn and so your options will
be broader. Talk about drawing a long bow!!!!!!!!

Some people do listen to reason.

Save yourself the trouble and focus your energies on improving your C++
expertise. It will do far more to broaden your options.

I would still have to deal with crappy code if I only worried about my own
coding style. It is invariably the case that the design choices other
people make impact my ability to use appropriate language features when
extending their work.

--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

[Signal9]

Re: The worst things about C++

If you invest your time in this language it will not steer you wrong.
Honestly I would say learn this as your major language, but also learn
other languages. Java and C# are very popular right now and have a
decent mature framework.

When you start as a professional developer you will end up changing
languages over the years and maybe on a project to project basis
(depending on the company you work for).

Actually I say this to you. Go learn C++ as much as possible, learn C
as well. Then for "fun" develop your own high level language. this
will teach you a lot. At this point you may want to get into some
Assembly (which is heavily used in driver and kernel development).

The world of software development is fun, do not forget that. So go
have fun !

[Tony]

Re: The worst things about C++


"Signal9" <cep_81@msn.com wrote in message
news:1165792219 .071931.294660@ 79g2000cws.goog legroups.com...

>
Tony wrote:

>"Signal9" <cep_81@msn.com wrote in message
>news:116570125 0.306645.13320@ 80g2000cwy.goog legroups.com...
>>

Also if
you are new to the technology field and want to become a developer, you
need to learn many techniques and languages. Do not stop and sit with
one language and framework/platform, learn everything you can.

>>
>Or instead of being a consultant of technology, be someone that can
>actually
>build something with it. With C++, rarely do you have to look anywhere
>else.
>All the time spent learning other languages and stuff doesn't make you as
>valuable as one who can apply it to some domain, like scientific
>computing,
>graphics/games, OLTP etc. Do survey the other stuff, but don't waste too
>much time trying to learn everything and become too broad to apply
>anything
>"professionall y". (Sure, I could learn German, Spanish and Latin. But I
>find
>English more than adequate for my purposes and I have better things to
>do!).
>>
>Tony

>
>
and you will be on the corner asking for change when they drop the only
tool you know how to use....
>
i got 25cents for ya...

But I am "they", so that's not likely.

Tony

[Tony]

Re: The worst things about C++


"Steven T. Hatton" <chattengau@ger mania.supwrote in message
news:4oGdnb84Qt mDpuHYnZ2dnUVZ_ uC3nZ2d@speakea sy.net...

I will argue that a person with one solid year of learning and working
with
C++ is (with very few exceptions) a novice who is just getting started.

I would agree with that if you change 'one' to 'five' and 'year' to 'years'.

Tony

[peter koch]

Re: The worst things about C++


Steven T. Hatton skrev:

>
That works with many languages. I had a professor who told us that a
programmer with 20 years experience in C probably didn't learn anything new
about programming languages in the past 19 years. Such a person had "one
year of experience twenty times", as he put it. Our prof suggested a
person who has exposure to many different languages will be a far better
programmer than one who has focused on only one.
>
I will argue that a person with one solid year of learning and working with
C++ is (with very few exceptions) a novice who is just getting started.

What do you mean about a "novice"? If it is a highschool student with
no programming expertise you may be right, but for someone with a
background in software engineering this is simply ridiculous. I spent
two weeks myself before I became productive, and those two weeks were
spent reading Stroustups and Lippmans books (at home), while I began
updating an existing codebase with fellow C++ programmers available for
questioning.
I had a background as a C programmer so I knew the "basics" and also
had read a bit about OO programming before. Also, my collegues were
knowledgeable and helpful, so I might have been a bit faster than
average. But one year is ridiculous.

/Peter

[Geo]

Re: The worst things about C++


peter koch wrote:

What do you mean about a "novice"? If it is a highschool student with
no programming expertise you may be right, but for someone with a
background in software engineering this is simply ridiculous. I spent
two weeks myself before I became productive, and those two weeks were
spent reading Stroustups and Lippmans books (at home), while I began
updating an existing codebase with fellow C++ programmers available for
questioning.
I had a background as a C programmer so I knew the "basics" and also
had read a bit about OO programming before. Also, my collegues were
knowledgeable and helpful, so I might have been a bit faster than
average. But one year is ridiculous.
>
/Peter

Alas, we are not all so gifted :(

(Of course that was a 'Royal' we, I speak only for myself)

[John Carson]

Re: The worst things about C++

"peter koch" <peter.koch.lar sen@gmail.comwr ote in message
news:1165828922 .647354.323000@ 79g2000cws.goog legroups.com

Steven T. Hatton skrev:

>>
>That works with many languages. I had a professor who told us that a
>programmer with 20 years experience in C probably didn't learn
>anything new about programming languages in the past 19 years. Such
>a person had "one year of experience twenty times", as he put it.
>Our prof suggested a person who has exposure to many different
>languages will be a far better programmer than one who has focused
>on only one.
>>
>I will argue that a person with one solid year of learning and
>working with C++ is (with very few exceptions) a novice who is just
>getting started.

>
What do you mean about a "novice"? If it is a highschool student with
no programming expertise you may be right, but for someone with a
background in software engineering this is simply ridiculous. I spent
two weeks myself before I became productive, and those two weeks were
spent reading Stroustups and Lippmans books (at home), while I began
updating an existing codebase with fellow C++ programmers available
for questioning.
I had a background as a C programmer so I knew the "basics" and also
had read a bit about OO programming before. Also, my collegues were
knowledgeable and helpful, so I might have been a bit faster than
average. But one year is ridiculous.
>
/Peter

Here is Stroustrup's take on the matter:

http://www.research.att.com/~bs/bs_faq.html#How-long

--
John Carson