how to design a replacement for C++

[Lynn McGuire]

Interesting article on why C++ development may be fading but it
will never go away: http://apenwarr.ca/log/?m=201007#22

Lynn

 

[Balog Pal]

Interesting article on why C++ development may be fading but it

will never go away: http://apenwarr.ca/log/?m=201007#22

Very good stuff.

 

[Francesco S. Carta]

Interesting article on why C++ development may be fading but it
will never go away: http://apenwarr.ca/log/?m=201007#22

Uhm, some good stuff, some bad.

I've gone through and I've read the precedent post too, a rant about C++
(not that the one you linked isn't a rant, it also is, somewhat).

Although his rants contain a fair bit of good speech (as for the
contents), it's a shame he shapes it interleaving gratuitous vulgarities
and insults: that's the drop that moved the needle from "towards" to
"away", for me.

[ aside:

I wonder why, in the 17 years he used C++ (and I suppose he used C for
longer) he didn't discover that one doesn't need to dereference and
enclose in parentheses a pointer to function in order to make the call.

- notice that I'm speaking about the syntax to make calls via pointers
to function; pointers to member function need the parentheses and that
is somewhat ugly, but I could easily work around it (and I'm not Jack
TopCoder) -

I suppose he still has some gaps to fill, maybe other basic ones too,
regardless of his long experience.

end aside ]

 

[Ian Collins]

Uhm, some good stuff, some bad.

I've gone through and I've read the precedent post too, a rant about C++
(not that the one you linked isn't a rant, it also is, somewhat).

Although his rants contain a fair bit of good speech (as for the
contents), it's a shame he shapes it interleaving gratuitous vulgarities
and insults: that's the drop that moved the needle from "towards" to
"away", for me.

I gave up at "C and C++ both get the job done in their respective
niches. And those niches are shrinking dramatically". I assume he
hasn't heard of embedded devices.

 

[Francesco S. Carta]

I gave up at "C and C++ both get the job done in their respective
niches. And those niches are shrinking dramatically". I assume he hasn't
heard of embedded devices.

Well, if you resisted to that, you would have filled the measure and
would have left in a further couple of paragraphs if not earlier - but
maybe I would be better shutting up right now, I would not feel fine
dissecting his articles here if he doesn't happen to read this ng. I
could drop him a message though...

uhm... no. I'll just shut up.

Il gioco non varrebbe la candela.

 

[Jonathan Lee]

I gave up at "C and C++ both get the job done in their respective
niches. And those niches are shrinking dramatically".  I assume he
hasn't heard of embedded devices.

Not just that. Look at http://www.langpop.com/
C, C++, and Java are consistently in the top 3 by all kinds of
metrics. I've seen similar stats elsewhere.

More than that, but I think Java's numbers are a bit inflated.
Not sure about universities elsewhere, but in Canada Java is
the "intro" programming language. So statistics like "most
discussions on site _____" will include a lot of 1st and 2nd
years asking generic questions about how to make a stack and
such (in Java).

--Jonathan

 

[Öö Tiib]

I gave up at "C and C++ both get the job done in their respective
niches. And those niches are shrinking dramatically".  I assume he
hasn't heard of embedded devices.

His further opinion seems to be that these niches are shrinking since
C (or C++) + script (his favorite is Python) are taking over. Odd. I
do not remember any market share that we had as pure without scripts.
All successful C++ projects some sort of scripts have been always
used. It all started with C + Perl and has always stayed like that.
Even for developing embedded systems the scripts are used massively
(but they remain less in end product). For tools, configuring,
testing, build system, prototyping, deploying, emulating/fakeing parts
(or whole external entities) under development, customizing ... etc.
Even when one views scripts as temporary solution, these stay often
there forever for practical reasons, because there is always better
way to use budget than to replace scripts in less critical/often
changing part with compiled code.

 

[Balog Pal]

Although his rants contain a fair bit of good speech (as for the
contents), it's a shame he shapes it interleaving gratuitous vulgarities
and insults: that's the drop that moved the needle from "towards" to
"away", for me.

Well, is the other guy is right, and there's nothing to do about it, one can
still use call up some stilistic issue do dismiss the content... :-o

 

[Francesco S. Carta]

Well, is the other guy is right, and there's nothing to do about it, one
can still use call up some stilistic issue do dismiss the content... :-o

Too bad you snipped the parts where I said that some of that content is
_bad_.

I've not dismissed it just because of its style: had it been more right
than wrong, I would have kept a reference to that website, but since
it's 50/50 (at best) and since it's pretty bad style, I feel I can
safely dismiss it.

There are tons of more knowledgeable people that write in a far more
pleasant way, my spare time is limited by definition and I _have_ to
make a choice about what to read: wrong information, vulgarities and
insults tell me I can safely drop that source, whatever "right" things
that source could give me.

 

[Öö Tiib]

Interesting article on why C++ development may be fading but it
will never go away:  http://apenwarr.ca/log/?m=201007#22

Sort of whiny.

Does not like
* std::string (template gibberish).
* boost::format (template gibberish).
* boost::bind (template gibberish).
* std::map (operator [] and template gibberish).

Especially long he goes on about std::map's operator []. His long
speech about its "Ha-ha" downsides felt longer than to read the <map>
header (350 lines or so).

So seems ordinary whiner. If that Avery Pennarun could code he could
write some pennarun::map behaving like he wants quicker than all the
obsenities he wrote about standard one.

 

[Francesco S. Carta]

Interesting article on why C++ development may be fading but it
will never go away: http://apenwarr.ca/log/?m=201007#22

Sort of whiny.

Does not like
* std::string (template gibberish).
* boost::format (template gibberish).
* boost::bind (template gibberish).
* std::map (operator [] and template gibberish).

Especially long he goes on about std::map's operator []. His long
speech about its "Ha-ha" downsides felt longer than to read the<map>
header (350 lines or so).

So seems ordinary whiner. If that Avery Pennarun could code he could
write some pennarun::map behaving like he wants quicker than all the
obsenities he wrote about standard one.

Further than the complaints you pointed out, that are all about the STL
and as such can completely be worked around (as you correctly said), he
pushed himself that far as to say that a pointer to member function
should hold a "this" pointer - that is, a complaint about the language
itself: he would prefer those pointers to be tied to one specific
instance instead of pointers that can be applied to whichever object.

This would completely defeat the purpose of that feature.

Well, if someone can't see how "less is more" in cases like this (and
even more in a flexible and extensible language as C++ is) one can't
really appreciate the full power of a programming language - and in
fact, seems like he's not aware that one can easily create a class that
ties an object with a pointer to one of its member functions.

 

[Ian Collins]

Further than the complaints you pointed out, that are all about the STL
and as such can completely be worked around (as you correctly said), he
pushed himself that far as to say that a pointer to member function
should hold a "this" pointer - that is, a complaint about the language
itself: he would prefer those pointers to be tied to one specific
instance instead of pointers that can be applied to whichever object.

In practice, how often are pointers to member functions used? I don't
think I've ever had cause to use one except for exotic RPC applications.

 

[Francesco S. Carta]

In practice, how often are pointers to member functions used? I don't
think I've ever had cause to use one except for exotic RPC applications.

I can think of different ways to use those pointers, though, I have no
idea of how (in)frequent those usages could be, compared to the average
real-life programmer workday.

Given, I can think of them but I didn't try to implement them to see how
easily I could re-implement them without using pointers to member
functions (in order to see if they would be a real advantage or just a
"I want to use /that/ feature" mind-trip).

I think I'll give it a shot, I'm really curious because it seems to be
an undervalued feature.

 

[Bo Persson]

Not just that. Look at http://www.langpop.com/
C, C++, and Java are consistently in the top 3 by all kinds of
metrics. I've seen similar stats elsewhere.

More than that, but I think Java's numbers are a bit inflated.
Not sure about universities elsewhere, but in Canada Java is
the "intro" programming language. So statistics like "most
discussions on site _____" will include a lot of 1st and 2nd
years asking generic questions about how to make a stack and
such (in Java).

Yes, what does "popular" really mean?

I do some of my work in Cobol, where most of the guys are 50+ years
old and hardly ever have any beginner's questions. And if they did,
wouldn't ask them on an internet forum anyway. .-)



Bo Persson

 

[Balog Pal]

Too bad you snipped the parts where I said that some of that content is
_bad_.

IMO more like too good -- we both know that your away speach is mere
notpicking on a randomly selected sendence, that is quite irrelevant wrt.
the content.

I've not dismissed it just because of its style: had it been more right
than wrong, I would have kept a reference to that website, but since it's
50/50 (at best) and since it's pretty bad style, I feel I can safely
dismiss it.

I'd be really interested how you calculated that 50% bad figure. Do you
think std::string is not a monster? That std::map is not broken in the
interface? That C++ lacks lots of undamental support for trivial things that
we struggle to cover with template magic with all its painful consequences
(what btw after stripping concepts is bound to stay for another decade?)

There are tons of more knowledgeable people that write in a far more
pleasant way, my spare time is limited by definition and I _have_ to make
a choice about what to read: wrong information, vulgarities and insults
tell me I can safely drop that source, whatever "right" things that source
could give me.

When I'm concerned about tinme spent on nonintertesting stuff, I start by
NOT writing about in in a forum. ;-)

 

[Balog Pal]

Especially long he goes on about std::map's operator []. His long
speech about its "Ha-ha" downsides felt longer than to read the <map>
header (350 lines or so).

Length of <map> is quite irrelevant. Do you defend its interface design?
In my experience it is pretty broken. Sure why stop at std::map, MOST of the
standard lib is poor quality, and it is very sad. I try to think a list of
what is good, and nothing emerges except for vector. And guess how many of
us had vector-like classes before the standard.

The point f the standard lib would have been to give good support out of the
box -- and it more like creates pain only. At least if used "alone".
Sure you can patch it up with your own exrtensions or popular existing
libs -- but that we could do without standard lib, could we?

I recall back in 96-97 most voces pushed "give us a standard NOW", whatever
it takes. Possibly me too. Did not turned up as a good idea in retrospect.
:-((((

So seems ordinary whiner. If that Avery Pennarun could code he could
write some pennarun::map behaving like he wants quicker than all the
obsenities he wrote about standard one.

Sure, I have bunch of my classes that are good, and used many libraries,
just if you work on a project where using the standard lib was decided, it
is pretty hard to go ahead. Either having different classes side-by-side,
or replacing the existing ones. (certainly the story of map is a dwarf
compared to std::string)

 

[Balog Pal]

In practice, how often are pointers to member functions used? I don't
think I've ever had cause to use one except for exotic RPC applications.

I use them time to time. But most frequently they are goning into
std::mem_fun or sigc::mem_fun or boost::bind, that well indicates that
having a bound pointer is something of need.

But the guy's other point is more right. We had a ton of discussion on
unified function calls' usability ( i.e. the language make
obj.foo(param) callable as foo(obj, param) ). For both functions and
operators. Clearing up a big mess. there is normally an agreement that it
would be fine. But it will never go into the standard as that would make
name lookup different, and have possibility to change existing code.
Checkmate.

 

[Balog Pal]

I think I'll give it a shot, I'm really curious because it seems to be an
undervalued feature.

The landscape is pretty simple.

STL introduced iterators, algorithms, and stuff tso you can supposedly write
in that style.

But those ideas are hanging in the air, and turn not usable at all. For the
very issues mentioned, there is no working way to call your functions.

The minimum would have needed:
- something that is usable like boost::bind, with native support
- built-in support that is now covered by boost::ref and boost::cref
- perfect forwarding
- iterator that in modeled like GOF iterator rather than on simple ponter
- resolving the error: 'reference to reference' issue. At least for the
natural const& to const&. :-((
- allowing definiton of local functions, or at least local classes usable
with templates

just what pops up in a few minutes

 

[Francesco S. Carta]

IMO more like too good -- we both know that your away speach is mere
notpicking on a randomly selected sendence, that is quite irrelevant
wrt. the content.

Interesting, since when were you capable of telepathy?

Mine was not just a pure nitpick: he directly sent to hell the reader -
to use an euphemism - implying the reader wanted to remove the
preprocessor from that "new language" and he called names on the
standardization committee just because he doesn't like the way they
designed the STL.

And that's not "one randomly selected sentence": those are two well
selected - and heavy - ones.

I'd be really interested how you calculated that 50% bad figure. Do you
think std::string is not a monster? That std::map is not broken in the
interface? That C++ lacks lots of undamental support for trivial things
that we struggle to cover with template magic with all its painful
consequences (what btw after stripping concepts is bound to stay for
another decade?)

That 50% was a fair figure - fair towards the article author. I don't
know your method: I happen to give more importance to quality than to
quantity, and a few really bad arguments can outweigh a bigger number of
good points, as for what regards the overall evaluations of some writing.

As for what concerns what is good and what is bad, it's clear that we
have different points of view and different tastes.

As for what concerns the "template magic" that you seem to be missing,
why don't you simply post your issues here and see if somebody can give
you some nice solution for your problem(s)?

When I'm concerned about tinme spent on nonintertesting stuff, I start
by NOT writing about in in a forum. ;-)

Well, I couldn't really say anything about that, because you have been
smart enough to put the sentence in the first singular person.

_I_ spoke about an offensive person with limited views that writes
articles containing wrong and biased information (the fact that he says
something correct is a secondary point).

Writing a follow-up on such a subject has a well defined purpose for me:
steer people away from such kind of crap.

I must take note that your comment on that article was a plain "Very
good stuff."

....note taken.

 

[Francesco S. Carta]

The landscape is pretty simple.

STL introduced iterators, algorithms, and stuff tso you can supposedly
write in that style.

But those ideas are hanging in the air, and turn not usable at all. For
the very issues mentioned, there is no working way to call your functions.

Please elaborate here. I have no problems calling my functions, of
either type.

The minimum would have needed:
- something that is usable like boost::bind, with native support
- built-in support that is now covered by boost::ref and boost::cref
- perfect forwarding
- iterator that in modeled like GOF iterator rather than on simple ponter
- resolving the error: 'reference to reference' issue. At least for the
natural const& to const&. :-((
- allowing definiton of local functions, or at least local classes
usable with templates

just what pops up in a few minutes

I will not enter into this kind of discussion, I still have a long way
to go before fully understanding the power of what C++ already gives me.

If you feel strong enough on your feet as to suggest improvements and
additions to the language and its library, I'm sure you'll find a lot of
knowledgeable people ready to discuss them, refine them and eventually
consider them for inclusion: comp.std.c++