Random C++0x impressions: TASM - the object oriented assembler! :-)

[Alf P. Steinbach]

When I read about C++0x nested closures or the extension of lvalues/rvalues to
five kinds or whatever it is, with very hard to grok subtleties involved and
syntax that reads more like Perl or perhaps APL than anything else, well, I feel
like grappling with Borland's old TASM assembler again.

TASM was really Really REALLY nice, compared to any other x86 assembler, as long
you used only the basics. But, someone at Borland noted that Object Oriented
Programming was becoming quite popular, and hey, /of course/ TASM should support
OOP! And so they did. You could do OOP in TASM! Yay!

Every self-respecting assembly programmer tried to at least be aware of
assembler's OOP features, for one wouldn't like to appear as an ignorant. But as
far as I know just about nobody used them for real. For much of the point of OOP
is to simplify things, and obtain safety, at the cost of some reduced
efficiency, while doing it in assembly is sort of the opposite in all three
respects...


Cheers,

- Alf (overwhelmed by C++0x)

 

[Öö Tiib]

When I read about C++0x nested closures or the extension of lvalues/rvalues to
five kinds or whatever it is, with very hard to grok subtleties involved and
syntax that reads more like Perl or perhaps APL than anything else, well, I feel
like grappling with Borland's old TASM assembler again.

TASM was really Really REALLY nice, compared to any other x86 assembler, as long
you used only the basics. But, someone at Borland noted that Object Oriented
Programming was becoming quite popular, and hey, /of course/ TASM should support
OOP! And so they did. You could do OOP in TASM! Yay!

Every self-respecting assembly programmer tried to at least be aware of
assembler's OOP features, for one wouldn't like to appear as an ignorant. But as
far as I know just about nobody used them for real. For much of the point of OOP
is to simplify things, and obtain safety, at the cost of some reduced
efficiency, while doing it in assembly is sort of the opposite in all three
respects...

It is fun that you compare C++ and assembler. About C++0x i have
actually similar emotions. Worst way i dislike the crap that may be
written in square brackets between function name and '('. How can be
good things made to look so ugly? Of course ... they are running out
of separators ... AFAIC only 3 symbols from ASCII are currently not
used in language: dollar, spermatosaurus and back-tick.

Well. C++ is multiple paradigm language and so we already use policies
to extract the (fitting to task and team size) paradigms from that
pile. One can throw lot of features of it aside without hurting it at
all. That work (writing policies) will become lot harder.

Other issue is with tools. Tools that can fully parse, reverse
engineer, forward engineer and modify C++ code are quite rare and
agonizingly slow. These will become more rare and more slow while need
for such tools will actually be growing.

I secretly hope that i am simply getting old and so more conservative.

 

[Jorgen Grahn]

It is fun that you compare C++ and assembler. About C++0x i have
actually similar emotions. Worst way i dislike the crap that may be
written in square brackets between function name and '('. How can be
good things made to look so ugly? Of course ... they are running out
of separators ... AFAIC only 3 symbols from ASCII are currently not
used in language: dollar, spermatosaurus and back-tick.

And breaking existing code is a no-no.

I haven't read much about C++0x, but aren't most of those new things
tools to make template meta-programming easier? Then we can continue to
ignore them, and get the benefits from more and better libraries.

Well. C++ is multiple paradigm language and so we already use policies
to extract the (fitting to task and team size) paradigms from that
pile. One can throw lot of features of it aside without hurting it at
all. That work (writing policies) will become lot harder.

Other issue is with tools. Tools that can fully parse, reverse
engineer, forward engineer and modify C++ code are quite rare and
agonizingly slow. These will become more rare and more slow while need
for such tools will actually be growing.

Personally I haven't yet seen the need for such tools. "Refactoring
tools" are a hot topic, but I suspect that (like so many other things)
come from the dynamic typing crowd. If you don't have a compiler to
tell you your code is broken, you need more help from your other
tools.

I secretly hope that i am simply getting old and so more conservative.

Fortunately C++ is a good language for conservative people (those of
us who perfer things that work to things that happen to be in vogue
this year).

/Jorgen

 

[Anthony Williams]

I haven't read much about C++0x, but aren't most of those new things
tools to make template meta-programming easier? Then we can continue to
ignore them, and get the benefits from more and better libraries.

Yes, lots of the new stuff *will* make writing libraries easier, so
application developers will get the benefit of more and better
libraries. However, there is also a lot that benefits the application
developer too. e.g. my favourite C++0x feature this week is the new use
of auto to deduce the type of a variable:

auto x=some_expression();

This can save a considerable amount of typing, and means you no longer
have to worry about whether a function returns an iterator or a
const_iterator, for example. It works really well in loops over
containers:

for(auto it=container.begin();it!=container.end();++it)
{
do_stuff(*it);
}

Lambdas are also really great, and there's a plethora of new libraries:
regular expressions, smart pointers, hash containers, random numbers,
etc., not to mention the thread library (which I personally am rather
excited by ;-)

Personally I haven't yet seen the need for such tools. "Refactoring
tools" are a hot topic, but I suspect that (like so many other things)
come from the dynamic typing crowd. If you don't have a compiler to
tell you your code is broken, you need more help from your other
tools.

Refactoring tools make it easier to develop, whatever your
language. e.g. they can make it considerably easier to rename a variable
or function without having to manually hunt down all the uses. I agree
that C++ does quite well without them though.

Fortunately C++ is a good language for conservative people (those of
us who perfer things that work to things that happen to be in vogue
this year).

It certainly is a good language for that, and C++0x doesn't change
that. You can still use all the existing stuff that works, and
supplement it with new stuff that works better in the relevant
circumstances.

Anthony

 

[SG]

I haven't read much about C++0x, but aren't most of those new things
tools to make template meta-programming easier?

I don't think that's true. But maybe you have a different idea about
what "template meta-programming" is. There's probably a gray area as
to what can be considered generic programming and what meta-
programming. You may want to check those laundry lists of C++0x
features to see what portion of new features has little to do with
template meta-programming.

Then we can continue to
ignore them, and get the benefits from more and better libraries.

You certainly can. But -- as Scott Meyers would say -- there are also
new features for everybody.

Cheers,
SG