By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,214 Members | 1,971 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,214 IT Pros & Developers. It's quick & easy.

What has C++ become?

P: n/a
I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend. Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language. Of course, I suppose the code I was
looking at could have been deliberately obfuscated
so that the developer could maintain control over it,
but shouldn't a language (or its libraries) be designed
to prevent that?
Jun 27 '08 #1
Share this Question
Share on Google+
123 Replies


P: n/a
On May 31, 12:36 pm, plenty...@yahoo.com wrote:
I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend. Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language. Of course, I suppose the code I was
looking at could have been deliberately obfuscated
so that the developer could maintain control over it,
but shouldn't a language (or its libraries) be designed
to prevent that?
Not everybody is a good C++ writer. It's a combination of two things:

1) A person not using the language as effectively as possible (and for
many people there is nothing you can do about it other than accept it
as inevitable). A poor legal writer can produce unusually unclear
legal documents (some legalese is easier to understand than others).

2) The ability to read it well (once you see enough strange looking
code it starts to make more sense and doesn't look as confusing). An
experienced lawyer can read even the most obtuse legalese document
without much of a problem.

The best thing that can be done to prevent that is to stop the problem
at it's source (#1). Rather than trolling newsgroups with questions
like this, which don't help anything at all, instead look for people
with legitimate problems in their code and give them constructive
criticism and suggestions.

Jason
Jun 27 '08 #2

P: n/a
On 2008-05-31 18:36, pl*******@yahoo.com wrote:
I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend.
Sure, templates can be a bit hard to read before you get used to them
(and template meta-programming even harder) but considering how powerful
they are I do not think they are overly complex.

As for competing libraries, that is something that all moderately
successful languages have to deal with. There are always someone who
thinks that the standard libraries are not good enough and starts their
own. In some languages it is even worse with multiple standard libraries.
Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language.
Most code in non-trivial systems is hard to read if you are not familiar
with the specific domain and the structure of the code. Good coding
guidelines and a clear architecture will mitigate this but can never
remove it entirely.

--
Erik Wikström
Jun 27 '08 #3

P: n/a
On 31 Maj, 18:36, plenty...@yahoo.com wrote:
I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend. Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language. Of course, I suppose the code I was
looking at could have been deliberately obfuscated
so that the developer could maintain control over it,
but shouldn't a language (or its libraries) be designed
to prevent that?
Now I don't know what kind of code you did look at, but I remember
first time I looked at a C program: it looked more or less like
gibberish (I used to program in a Pascal variant with some assembly
woven in). A few days practice, and I found the code readable, and
after a few months I even liked it better than Pascal.
So what it all came up to was a need to familiarise myself with the
syntax and get acquainted to the principles behind C.
I guess it is the same stuff that troubles you. Writing templated code
is somewhat different from writing normal code: much more must take
place at compile-time, but when you learn the tricks and the way
things work, it is not so difficult again.
Also, if you did look at some code that was either library code or
code that was supposed to be supported to many (possibly old)
platforms, you will likely see code that is seemingly somewhat
obfuscated.
Probably, a few days of dissecting the code will make you well
comfortable with it: if not, you are welcome to ask questions here (or
to your collegues, of course).

/Peter
Jun 27 '08 #4

P: n/a
On May 31, 7:25 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-05-31 18:36, plenty...@yahoo.com wrote:
I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend.
Sure, templates can be a bit hard to read before you get used
to them (and template meta-programming even harder) but
considering how powerful they are I do not think they are
overly complex.
It's always a costs-benefits tradeoff. Making the code harder
to read is a definite cost. Afterwards, you have to weigh the
benefits, and see if they are worth it.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #5

P: n/a
On May 31, 10:36*am, plenty...@yahoo.com wrote:
I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend.

I think competing libraries are going to be around for
a while. Hybrid cars are selling well lately and
I don't think that is going to change anytime soon.
Perhaps surprisingly, the increased complexity and
knowledge required to develop and maintain a hybrid
doesn't overwhelm the relative total cost of ownership
given high energy prices. By relative I mean relative
to a car with only a gas engine.

For whatever reason, the gas engine/"traditional C++"
approach is not producing efficient results in some
contexts -- http://webEbenezer.net/comparison.html.
We're working on a new version of those tests that uses
Boost 1.35 and MSVC9. The preliminary results show no
significant differences from those using Boost 1.34.1 and
MSVC8. We're also planning to expand the test cases.
There are other reasons beside run-time performance that
our approach may be successful. We believe our approach
will also help improve build times. We aren't there yet,
though as no one has provided automated support for
integrating our services into the build process.
Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language.
I agree there is room for improvement with the language, but
still don't really agree with your conclusion. Your mention
of clergy is interesting... when it comes to providing
thoughtful and helpful services, a good priest is essential.
Of course, I suppose the code I was
looking at could have been deliberately obfuscated
so that the developer could maintain control over it,
Unfortunately, I think that happens. It requires good
leadership to deal with someone who behaves that way.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
Jun 27 '08 #6

P: n/a
On May 31, 3:57*pm, peter koch <peter.koch.lar...@gmail.comwrote:
Now I don't know what kind of code you did look at, but I remember
first time I looked at a C program: it looked more or less like
gibberish (I used to program in a Pascal variant with some assembly
woven in).
I recall having the same experience, the *first* time I looked
at a C program, having before that seen only Pascal,
Modula-2, Basic and assembly. But I've seen C++ many times
now, albeit mostly my own which is deliberately readable.
Jun 27 '08 #7

P: n/a
On Jun 1, 1:01*am, c...@mailvault.com wrote:
Of course, I suppose the code I was
looking at could have been deliberately obfuscated
so that the developer could maintain control over it,

Unfortunately, I think that happens. *It requires good
leadership to deal with someone who behaves that way.
I should mention that this is open source code,
so there is no leadership. Could be worse though,
could be the Linux kernel.
Jun 27 '08 #8

P: n/a
James Kanze wrote:
On May 31, 7:25 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
>Sure, templates can be a bit hard to read before you get used
to them (and template meta-programming even harder) but
considering how powerful they are I do not think they are
overly complex.

It's always a costs-benefits tradeoff. Making the code harder
to read is a definite cost. Afterwards, you have to weigh the
benefits, and see if they are worth it.
I don't believe readability is a cost benefit tradeoff. I attended Scott
Meyers' presentation at NWCPP (slides here:
http://www.nwcpp.org/Downloads/2008/code_features.pdf). Scott mentioned
that he'd had help from TMP experts in creating the code examples, so we
can discount the idea that the readability problems are caused by lack
of programmer ability in C++ TMP.

After looking at it for a while, it seems to me that there is no way to
lay out the whitespace to make it look right. C++ TMP simply eats up far
too much horizontal space.

Second of all, once you figure out what it is doing, what it is doing is
rather simple. It is just a very poor notation for that (which is
consistent with TMP for C++ being discovered rather than designed).

Is it necessary to have such a poor notation? I don't believe so. C++
TMP is an FP language, and other FP languages tend to have much better
notation.

----------
Walter Bright
Digital Mars C, C++, D programming language compilers
Jun 27 '08 #9

P: n/a
pl*******@yahoo.com wrote:
I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
"Someone's C++ code"? Are you sure that "someone" is an experienced
C++ programmer who knows how to write good-quality understandable C++?

Anyone can write incomprehensible code with any language. And what is
worse, most people actually do.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend.
What "competing libraries"?

And as for templates making a "mess of things", I'd say that's more
often than not just a myth. My personal experience is that templates
actually *simplify* things in most cases, they don't complicate things.
Just a small example:

int table[100];
....
std::sort(table, table+100);

I believe that's pretty simple and understandable code, or would you
disagree? (Never mind the "table+100" pointer trickery. That's not the
point here.)

Well, you know what? That's template code. It's precisely *because* of
templates that that code can be so simple as it is. Without templates it
would have to be much more complicated (compare to C's qsort()).

Maybe you think using <makes template code "a mess"? I don't
understand why. Is this somehow unclear:

std::vector<inttable;
table.push_back(5);

What's so unclear about that? I think it's perfectly clear and legible
code. How else would you want it to be?
Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language.
It's impossible to design a language so that it cannot be written in
an unclear way. It's always possible to write obfuscated code.

However, that doesn't mean it's impossible to write clear code.
Jun 27 '08 #10

P: n/a
On Jun 2, 7:41 am, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
James Kanze wrote:
On May 31, 7:25 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
Sure, templates can be a bit hard to read before you get used
to them (and template meta-programming even harder) but
considering how powerful they are I do not think they are
overly complex.
It's always a costs-benefits tradeoff. Making the code harder
to read is a definite cost. Afterwards, you have to weigh the
benefits, and see if they are worth it.
I don't believe readability is a cost benefit tradeoff.
It is in the sense that it's not binary. Totally unreadable
code has such high cost that nothing can outweigh it, but there
are times when you might give up a little bit of readability
(without the code becoming totally unreadable) if the other
benefits are large enough.
I attended Scott Meyers' presentation at NWCPP (slides
here:http://www.nwcpp.org/Downloads/2008/code_features.pdf).
Scott mentioned that he'd had help from TMP experts in
creating the code examples, so we can discount the idea that
the readability problems are caused by lack of programmer
ability in C++ TMP.
After looking at it for a while, it seems to me that there is
no way to lay out the whitespace to make it look right. C++
TMP simply eats up far too much horizontal space.
More to the point, the "language" isn't really designed for what
it is being used for. You need all sorts of strange constructs
to do fundamentally simple things, like loop or a conditional.
Second of all, once you figure out what it is doing, what it
is doing is rather simple. It is just a very poor notation for
that (which is consistent with TMP for C++ being discovered
rather than designed).
Is it necessary to have such a poor notation? I don't believe
so. C++ TMP is an FP language, and other FP languages tend to
have much better notation.
Exactly. Because they were designed with that in mind.

What it does mean is that you don't use TMP, at least in its
more complete forms, unless the benefits are extremely high, and
even then, probably only in contexts where you can be sure that
only real experts (who can cope with the loss of readability)
have to maintain it.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #11

P: n/a
Juha Nieminen wrote:
Maybe you think using <makes template code "a mess"? I don't
understand why.
It's because of the parsing ambiguities that come from using < as a
parameter delimiter.
Is this somehow unclear:

std::vector<inttable;
table.push_back(5);

What's so unclear about that? I think it's perfectly clear and legible
code. How else would you want it to be?
It's the wordiness of it. If the code gets more complicated than such
trivial examples, it gets rather hard to visualize. I would want it to
use a much more compact notation, like maybe:

int[] table;
table ~= 5;

To me, it's like the difference between

assign(a,add(b,c))

and

a=b+c
Jun 27 '08 #12

P: n/a
pl*******@yahoo.com wrote:
The people who are guiding the development of C++
have really made a mess of things, I mean templates
IMHO, the opposite has happened.. it has been hammered into shape over
the years. My "last" experience with C++, before I resumed my use of it
about a year ago, had been from the early 90ies and the current C++ is,
while being a larger and still not very pretty language, imho more
usable than back then (of course that might also be because my memory
betrays me, or the old compilers I used [Turbo and Zortech C++ in that
case] were Not Very Good back then, or whatever.)
Jun 27 '08 #13

P: n/a
In article <Bf******************************@comcast.com>,
Walter Bright <wa****@digitalmars-nospamm.comwrote:
>Juha Nieminen wrote:
>Maybe you think using <makes template code "a mess"? I don't
understand why.

It's because of the parsing ambiguities that come from using < as a
parameter delimiter.
>Is this somehow unclear:

std::vector<inttable;
table.push_back(5);

What's so unclear about that? I think it's perfectly clear and legible
code. How else would you want it to be?

It's the wordiness of it. If the code gets more complicated than such
trivial examples, it gets rather hard to visualize. I would want it to
use a much more compact notation, like maybe:

int[] table;
table ~= 5;
The problem with compact notation is that they can only fill a very
small number of cases.

So OK, we replace std::vector by [] and push_back by ~= What about
the rest of vector method ? What about the other containers?

std::deque<intqueue; // int @ queue ?
queue.push_back(5); // queue ~= 5; OK
queue.push_front(8); // queue =~ 8 ??
int a = queue.front(); // int a ~= queue ????

>To me, it's like the difference between

assign(a,add(b,c))

and

a=b+c
operator=() for a std::vector does exactly what one should expect.
std::vector<inta;
// fill a with some data
std::vector<intb;
b = a; // nice and intuitive.

What do you think should happen on:

std::vector<intc;
c = a + b; // ??

Various peoples will say: sum elements individually, concatenation of
the two vectors ??? The fact is that '+' for vectors have no natural
(universal?) meaning, using it as a short hand for something else is
more likely to obfuscate the code rather than a more verbose solution.

Yannick

Jun 27 '08 #14

P: n/a
Erik Wikström wrote:
On 2008-05-31 18:36, pl*******@yahoo.com wrote:
>I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend.

Sure, templates can be a bit hard to read before you get used to them
(and template meta-programming even harder) but considering how powerful
they are I do not think they are overly complex.
Both of these things simply require an understanding of the language
and, in the case of TMP, the conventions used. The authors of MPL
created and documented, quite well I think, the underlying concepts of
metafunctions and their associated algorithms and tools. An
understanding of these concepts makes TMP code completely understandable.

The problem I think that is going on here, without actually seeing any
code sample, is that people are expecting that they can just learn C++
and then work in the field for 20 years without having to learn anything
new.
Jun 27 '08 #15

P: n/a
Walter Bright wrote:
James Kanze wrote:
>On May 31, 7:25 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
>>Sure, templates can be a bit hard to read before you get used
to them (and template meta-programming even harder) but
considering how powerful they are I do not think they are
overly complex.

It's always a costs-benefits tradeoff. Making the code harder
to read is a definite cost. Afterwards, you have to weigh the
benefits, and see if they are worth it.

I don't believe readability is a cost benefit tradeoff. I attended Scott
Meyers' presentation at NWCPP (slides here:
http://www.nwcpp.org/Downloads/2008/code_features.pdf). Scott mentioned
that he'd had help from TMP experts in creating the code examples, so we
can discount the idea that the readability problems are caused by lack
of programmer ability in C++ TMP.
I also attended that discussion, but the first one in 07...Red Green.
At least in that talk it seemed to be that Meyers specifically had help
in dealing with certain aspects of the TMP library and more
specifically, with things that should have worked but did not.

Furthermore, it wouldn't surprise me if Scott initially had trouble
understanding or working in TMP because it is an utterly new technique
that is very different than anything else people normally do in C++.
The closest one might come to the kind of coding that you are doing
might be LISP or Scheme, except you are unable to assign to anything.
However, by learning the concepts behind the TMP method, what a
metafunction is and things like that, the code really becomes rather
easy to comprehend.

And I'm not a C++ "expert". There are a LOT of people that know the
language better than I do.
Jun 27 '08 #16

P: n/a
On 2008-06-02 12:27, Walter Bright wrote:
Juha Nieminen wrote:
>Maybe you think using <makes template code "a mess"? I don't
understand why.

It's because of the parsing ambiguities that come from using < as a
parameter delimiter.
>Is this somehow unclear:

std::vector<inttable;
table.push_back(5);

What's so unclear about that? I think it's perfectly clear and legible
code. How else would you want it to be?

It's the wordiness of it. If the code gets more complicated than such
trivial examples, it gets rather hard to visualize. I would want it to
use a much more compact notation, like maybe:

int[] table;
table ~= 5;
The natural interpretation of the above would in C++ be "table != 5".
Assigning non-intuitive meanings to operators is much worse than a lack
of compactness. If you really want an operator use either += or <<.

--
Erik Wikström
Jun 27 '08 #17

P: n/a
On Sun, 1 Jun 2008 16:34:58 -0700 (PDT), pl*******@yahoo.com wrote:
>I recall having the same experience, the *first* time I looked
at a C program, having before that seen only Pascal,
Modula-2, Basic and assembly. But I've seen C++ many times
now, albeit mostly my own which is deliberately readable.
You can safely ignore this geek style 'template programming' because
it will never reach the mundane area of real-world programming.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
Jun 27 '08 #18

P: n/a
On Jun 2, 12:27 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
On Sun, 1 Jun 2008 16:34:58 -0700 (PDT), plenty...@yahoo.com wrote:
I recall having the same experience, the *first* time I looked
at a C program, having before that seen only Pascal,
Modula-2, Basic and assembly. But I've seen C++ many times
now, albeit mostly my own which is deliberately readable.

You can safely ignore this geek style 'template programming' because
it will never reach the mundane area of real-world programming.
Yeah, like, you know, WTL, Loki or the Standard C++ Library. Those are
clear examples of imaginary-world programming.

:)

Hope you weren't serious about that...
Jun 27 '08 #19

P: n/a
Yannick Tremblay wrote:
What do you think should happen on:

std::vector<intc;
c = a + b; // ??

Various peoples will say: sum elements individually, concatenation of
the two vectors ??? The fact is that '+' for vectors have no natural
(universal?) meaning, using it as a short hand for something else is
more likely to obfuscate the code rather than a more verbose solution.
You're quite right. That's why the D programming language introduced the
operators ~ and ~= to mean concatenate and append, respectively. That
eliminates the meaning ambiguity in the + and += operators.
Jun 27 '08 #20

P: n/a
On May 31, 12:36 pm, plenty...@yahoo.com wrote:
I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend. Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language. Of course, I suppose the code I was
looking at could have been deliberately obfuscated
so that the developer could maintain control over it,
but shouldn't a language (or its libraries) be designed
to prevent that?

It has been said many times before. The solution (or cure) to C++ is
the KISS principle.

-RFH

Jun 27 '08 #21

P: n/a
Walter Bright wrote:
It's the wordiness of it.
I disagree. Using longer keywords and notation does not make the code
unclear, but all the contrary: It makes the code more understandable and
unambiguous. When you try to minimize the length of elements what you
end up is basically an unreadable obfuscated regexp.

I think that your suggestion itself is a perfect example of that:
table ~= 5;
Yes, that uses less characters than "table.push_back(5);". However,
why would that be any clearer and more understandable? On the contrary,
it's more obfuscated.

I have never understood the fascination some people (and almost 100%
of beginner programmers) have with trying to minimize the size of their
source code. They will sometimes go to ridiculous extents to try to make
the code as short as possible, at the cost of making it completely
obfuscated.

Brevity does not improve readability, but all the contrary.
Jun 27 '08 #22

P: n/a
Michael DOUBEZ wrote:
Another usual argument with using + for concatenation is that one expect
commutativity (a+b==b+a) but a.append(b)!= b.append(a) .
OTOH, multiplication of matrices is not commutative, yet it may make
sense to still support the * operator for matrix types...
Jun 27 '08 #23

P: n/a
Juha Nieminen wrote:
Walter Bright wrote:
>It's the wordiness of it.

I disagree. Using longer keywords and notation does not make the code
unclear, but all the contrary: It makes the code more understandable and
unambiguous. When you try to minimize the length of elements what you
end up is basically an unreadable obfuscated regexp.
Yes and no. I really like the verbosity of Modula 2 in control flow as
opposed to the use of "{" and "}". However, when it comes to template
template parameters, I have trouble getting a reasonable layout to work
simply because its using too much horizontal space. A baby case example is
something like

typedef typename
allocator_type::template rebind< ListNode >::other node_allocator;

Regardless of where I put the line break, it always looks somewhat
suboptimal.

I think that your suggestion itself is a perfect example of that:
> table ~= 5;

Yes, that uses less characters than "table.push_back(5);". However,
why would that be any clearer and more understandable? On the contrary,
it's more obfuscated.
Well, that depends, too. In D, "~" denotes concatenation. It makes perfect
sense, not to use "+" for that, and "~" feels somewhat right. Now, with
that convention in place, table ~= 5 is not obfuscated at all.

I have never understood the fascination some people (and almost 100%
of beginner programmers) have with trying to minimize the size of their
source code. They will sometimes go to ridiculous extents to try to make
the code as short as possible, at the cost of making it completely
obfuscated.
On that, I agree. But that does by no means imply that the syntax of C++ is
doing a good job in supporting clear and understandable coding of template
stuff.

Brevity does not improve readability, but all the contrary.
Overboarding use of horizontal space making it hard to put line breaks in
appropriate places also does not improve readability.
Best

Kai-Uwe Bux
Jun 27 '08 #24

P: n/a
On Jun 2, 7:27 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
On Sun, 1 Jun 2008 16:34:58 -0700 (PDT), plenty...@yahoo.com wrote:
I recall having the same experience, the *first* time I
looked at a C program, having before that seen only Pascal,
Modula-2, Basic and assembly. But I've seen C++ many times
now, albeit mostly my own which is deliberately readable.
You can safely ignore this geek style 'template programming'
because it will never reach the mundane area of real-world
programming.
First, you can't ignore anything, because you never know where
it will crop up. And like most things, it will be more or less
readable, depending on who wrote it.

What is true is that at the application level, there is very
little need for meta-programming; it is mostly used in low level
libraries (like the standard library). What is also true is
that some of its more extreme use does push readability, even
when written by an expert (but there are also some simple,
everyday idioms which even average programs should be able to
master). And what is certainly true is that it is being used
(probably too much, even in places where it isn't needed).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #25

P: n/a
On Jun 2, 4:05 pm, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article <BfCdnUj63_iCVt7VnZ2dnUVZ_vSdn...@comcast.com>,
Walter Bright <wal...@digitalmars-nospamm.comwrote:
Juha Nieminen wrote:
Maybe you think using <makes template code "a mess"? I don't
understand why.
It's because of the parsing ambiguities that come from using < as a
parameter delimiter.
Is this somehow unclear:
std::vector<inttable;
table.push_back(5);
What's so unclear about that? I think it's perfectly clear
and legible code. How else would you want it to be?
It's the wordiness of it. If the code gets more complicated
than such trivial examples, it gets rather hard to visualize.
I would want it to use a much more compact notation, like
maybe:
int[] table;
table ~= 5;
The problem with compact notation is that they can only fill a very
small number of cases.
The problem with compact notation is that it quickly leads to
obfuscation. Witness perl and APL. Many of the problems with
C++ today is that there was an attempt to make the notation too
compact in the past. Things like:
int*p;
int a[10];
rather than:
variable p: pointer to int ;
variable a: array[ 10 ] of int ;
The result is a declaration syntax which causes untold problems,
not just to human readers, but also to compilers.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #26

P: n/a
On Jun 3, 10:56 am, Juha Nieminen <nos...@thanks.invalidwrote:
Walter Bright wrote:
It's the wordiness of it.
I disagree. Using longer keywords and notation does not make
the code unclear, but all the contrary: It makes the code more
understandable and unambiguous. When you try to minimize the
length of elements what you end up is basically an unreadable
obfuscated regexp.
Yes. Typically, perl looks more like transmission noise that it
does a program.

In the (now distant) past, there was an argument for reducing
the number of characters. If you've ever heard a listing output
to a teletype, you'll understand. But I know of no programmer
today who develops code on a teletype. (But then, everyone I
know is in either western Europe or North America. Perhaps in
less priviledged regions.)
I think that your suggestion itself is a perfect example of that:
table ~= 5;
Yes, that uses less characters than "table.push_back(5);".
However, why would that be any clearer and more
understandable? On the contrary, it's more obfuscated.
From the looks of things, Walter would like APL. A language
known for read only programs.
I have never understood the fascination some people (and
almost 100% of beginner programmers) have with trying to
minimize the size of their source code. They will sometimes go
to ridiculous extents to try to make the code as short as
possible, at the cost of making it completely obfuscated.
Brevity does not improve readability, but all the contrary.
Brevity, correctly applied, can improve readability. As my high
school English teacher used to say, "good writing is clear and
concise". The problem with verbosity, however, isn't the lenght
(in characters) of the words (tokens). The problem with much
template programming is that it deals with several different
levels at the same time, each with it's own vocabulary, so you
need a lot more words. And it's a fundamental problem; I don't
think that there is a real solution.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jun 27 '08 #27

P: n/a
James Kanze wrote:
The problem with compact notation is that it quickly leads to
obfuscation. Witness perl and APL.
Those problems are the result of lack of redundancy in the language, not
compactness. See my article:
http://dobbscodetalk.com/index.php?o...html&Itemid=29

Many of the problems with
C++ today is that there was an attempt to make the notation too
compact in the past. Things like:
int*p;
int a[10];
rather than:
variable p: pointer to int ;
variable a: array[ 10 ] of int ;
The result is a declaration syntax which causes untold problems,
not just to human readers, but also to compilers.
Again, that has nothing to do with compactness and everything to do with
ambiguity in the grammars. I don't believe that replacing operators with
long words makes code clearer - didn't Cobol demonstrate that?
Jun 27 '08 #28

P: n/a
James Kanze wrote:
In the (now distant) past, there was an argument for reducing
the number of characters. If you've ever heard a listing output
to a teletype, you'll understand. But I know of no programmer
today who develops code on a teletype. (But then, everyone I
know is in either western Europe or North America. Perhaps in
less priviledged regions.)
I've had many programmers tell me that their style of programming is
based on how much they can see on their screens. As screens have gotten
bigger, their mental "unit of code" has increased to match. I know I
used to make all my functions fit in 24 lines or less, now 60 lines is
typical.

Take a look at Scott's slides again. I don't see any reasonable way of
formatting it to look decent on a screen.

> I think that your suggestion itself is a perfect example of that:
>> table ~= 5;
>Yes, that uses less characters than "table.push_back(5);".
However, why would that be any clearer and more
understandable? On the contrary, it's more obfuscated.

From the looks of things, Walter would like APL. A language
known for read only programs.
Since the D programming language looks nothing like APL (or Perl), I
don't understand your comment at all. Also, the way arrays work in D,
which includes using the ~ and ~= operators, are frequently cited by D
users as one of the main reasons they like D. Do you really believe that
~ as concatenation and ~= for append is "obfuscation" ?

The problem with verbosity, however, isn't the lenght
(in characters) of the words (tokens).
It's both the length and the fact that there are so many tokens needed
to be strung together to perform basic operations. What you're trying to
accomplish gets lost in all the < and ::.
Jun 27 '08 #29

P: n/a
Erik Wikström wrote:
> int[] table;
table ~= 5;

The natural interpretation of the above would in C++ be "table != 5".
Assigning non-intuitive meanings to operators is much worse than a lack
of compactness. If you really want an operator use either += or <<.
I agree; I associate some kind of negation with ~, not concatenation.
For ~=, I'd probably go with the C-style interpretation of = ... ~, or
interpret it as some kind of congruence operator.
Jun 27 '08 #30

P: n/a
On Jun 3, 11:12*am, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
[...]
I don't believe that replacing operators with
long words makes code clearer - didn't Cobol demonstrate that?
In my view, the essential observation is that the keywords here, 'to'
and 'of', highlights an irregularity in the language; constructs
reserved for special built-in features. Whether such irregularities
are words or operators doesn't matter.

For example, I find the C++ type constructor operators for arrays ([])
and pointers (*) just as unnecessary and cluttering. They were needed
when C was invented, but now C++ has templates for parameterized
types. Arrays are parameterized types. So are pointers. So an ideal
regular language would use the same syntax:

pointer [int] p;
array [int, 10] a;
my_2d_array [int, int, 10, 10] m;

This also allows you to reserve square brackets for all parameterized
compile-time structures (templates). That would eliminate parser
irregularities with angle brackets. Then use Fortran style syntax for
indexing, i.e. p (0), p (1). Interestingly, this extends elegantly to
multi-dimensional arrays, m (0, 1), while the current C++ square
bracket operator does not; since it accepts only one parameter. It
seems that, with regularity, less is more.

These few syntax improvements along with obolishing some of the most
problematic type system irregularities (such as array decay and other
unwise conversion rules) would go a long way in making C++ a simpler
language both syntactically and semantically.

Of course, it wouldn't be C++ anymore; but hey, why not define "C++
Level 2" and some migration path via interoperability features?
Modules, when they are introduced to the language, may make this more
feasable, perhaps.

Regards,
Vidar Hasfjord
Jun 27 '08 #31

P: n/a
On Jun 3, 10:18*am, Kai-Uwe Bux <jkherci...@gmx.netwrote:
[...]
I have trouble getting a reasonable layout to work
simply because its using too much horizontal space. A baby case example is
something like

* typedef typename
* allocator_type::template rebind< ListNode >::other node_allocator;
Getting rid of the redundant 'typename' and 'template' keywords would
help a lot. As I understand it a cleaner syntax and the use of
concepts would allow the expression to be inferred without these.

The other fundamental problem with C++ meta-functions is that it is
based on this cumbersome conventions:

typedef meta_function <arg1, arg2>::result r;

The ideal syntax would be:

alias r = meta_function <arg1, arg2>;

The problem is to distinguish between a meta-function reference and
the type (result) that it produces. (Aside: This is the same problem
as for regular functions; distinguishing the use of the function as a
function call that evaluates to the result and the value of the
function itself; which in C++ decays to a function pointer.)

It seems that the new C++09 alias syntax provides what's needed:

template <typename T1, typename T2>
alias meta_function = ...;

Are the full gamut of template features available for templated
aliases? Such as partial specialization etc.?

Regards,
Vidar Hasfjord
Jun 27 '08 #32

P: n/a
On Jun 3, 2:15*pm, Vidar Hasfjord <vattilah-gro...@yahoo.co.ukwrote:

<...>
For example, I find the C++ type constructor operators for arrays ([])
and pointers (*) just as unnecessary and cluttering. They were needed
when C was invented, but now C++ has templates for parameterized
types. Arrays are parameterized types. So are pointers. So an ideal
regular language would use the same syntax:

* pointer [int] p;
* array [int, 10] a;
* my_2d_array [int, int, 10, 10] m;
Interesting dude ... :-)
regards
Andy Little

Jun 27 '08 #33

P: n/a
On Jun 3, 2:48*pm, Vidar Hasfjord <vattilah-gro...@yahoo.co.ukwrote:

<...>
* typedef meta_function <arg1, arg2>::result r;

The ideal syntax would be:

* alias r = meta_function <arg1, arg2>;
I've been toying about with this stuff myself. I've been looking at LL
grammars for a C++ like language without the crud.

AFAICS typename is useful because the parser needs to know that a name
is a type within a template and it solves the problem in a nice LL
way. The problem is that it isnt really regular in C++ (eg also have
typedef which is rather horrible from C useage too)

In my doodlings a metafunction invocation has the same syntax as a
function:

typename r = meta_function(arg1,arg2);

Note that the context provided by typename means that initaliser must
be a type not value. In fact a metafunction can be an ordinary
function where it just gives returntype. (Can though just define the
metafunction) Also works with operators;

typename A = ...;
typename B = ...;
typename C = ..;

typename plus_type = A + B + C;

For legibility you can add an optional (or maybe required for clarity)
prefix:

typename r = typefn metafunction(arg1,arg2);

typename plus_type = typefn A + B + C;
regards
Andy Little
Jun 27 '08 #34

P: n/a
James Kanze wrote:
On Jun 2, 7:27 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
>On Sun, 1 Jun 2008 16:34:58 -0700 (PDT), plenty...@yahoo.com wrote:
>>I recall having the same experience, the *first* time I
looked at a C program, having before that seen only Pascal,
Modula-2, Basic and assembly. But I've seen C++ many times
now, albeit mostly my own which is deliberately readable.
>You can safely ignore this geek style 'template programming'
because it will never reach the mundane area of real-world
programming.

First, you can't ignore anything, because you never know where
it will crop up. And like most things, it will be more or less
readable, depending on who wrote it.

What is true is that at the application level, there is very
little need for meta-programming; it is mostly used in low level
libraries (like the standard library).
Well, first of all, I don't think that the standard library, where it
actually makes use of generic/meta programming techniques, is "low
level". It is very much application level - stacks, lists,
vectors...this isn't hardware talking stuff. There is nothing low level
about abstract data types. It is exactly the opposite of low level in
my opinion.

Second, I disagree that there's little need for it in the application
level programming. We, where I work, actually use it a moderate amount
and to great advantage. For instance, we are an engineering firm and
use a data type that uses metaprogramming techniques to provide type
safe dimensional analysis. Since adopting this it has already saved us
numerous man hours in debugging.

We use boost::units and some other stuff that I wrote on top of it.
Other areas it is used is in a variety of generic functions that use
enable_if to choose or disqualify template instantiations.

So as one that is not afraid of TMP and uses it *in the application
layer* I really have to disagree with those claiming it has no place there.
What is also true is
that some of its more extreme use does push readability, even
when written by an expert (but there are also some simple,
everyday idioms which even average programs should be able to
master).
Which is why I recommend getting and reading the TMP book by Abrahams
and Gurtovoy. Knowing the concepts that they developed enable one to
understand TMP much better, assuming the developer is using such
concepts and hasn't written their own. Even then, there's really only
so many ways you can do TMP and so learning theirs is a good step toward
understanding anyone's, including the STL that uses blobs.

It's a different kind of code. It isn't easy to do. But it isn't
readability that is the problem here, it's understanding that style of
language. It is a skill that all C++ developers should attempt to
become familiar with for it will only get more and more common as more
and more people adopt and refine the generic programming paradigm in
C++. Many of the new language features were put in specifically FOR
this kind of development.

And what is certainly true is that it is being used
(probably too much, even in places where it isn't needed).
And it is also certainly true that it is NOT being used in many places
where it should be.
Jun 27 '08 #35

P: n/a
Walter Bright wrote:
James Kanze wrote:
>In the (now distant) past, there was an argument for reducing
the number of characters. If you've ever heard a listing output
to a teletype, you'll understand. But I know of no programmer
today who develops code on a teletype. (But then, everyone I
know is in either western Europe or North America. Perhaps in
less priviledged regions.)

I've had many programmers tell me that their style of programming is
based on how much they can see on their screens. As screens have gotten
bigger, their mental "unit of code" has increased to match. I know I
used to make all my functions fit in 24 lines or less, now 60 lines is
typical.
That is way too many. It's not about what will fit on your screen, but
what fits in the brain in one go. Long functions do not.
>
Take a look at Scott's slides again. I don't see any reasonable way of
formatting it to look decent on a screen.
Well, I prefer something more like so:

template<typename S, typename T// compute index of T in S
struct IndexOf
: mpl::distance
<
typename mpl::begin<S>::type
, typename mpl::find<S, T>::type
>
{};

But to each his own. Neither is particularly difficult to understand.
Jun 27 '08 #36

P: n/a
On 2008-06-03 15:15, Vidar Hasfjord wrote:
On Jun 3, 11:12 am, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
>[...]
I don't believe that replacing operators with
long words makes code clearer - didn't Cobol demonstrate that?

In my view, the essential observation is that the keywords here, 'to'
and 'of', highlights an irregularity in the language; constructs
reserved for special built-in features. Whether such irregularities
are words or operators doesn't matter.

For example, I find the C++ type constructor operators for arrays ([])
and pointers (*) just as unnecessary and cluttering. They were needed
when C was invented, but now C++ has templates for parameterized
types. Arrays are parameterized types. So are pointers. So an ideal
regular language would use the same syntax:

pointer [int] p;
array [int, 10] a;
my_2d_array [int, int, 10, 10] m;

This also allows you to reserve square brackets for all parameterized
compile-time structures (templates). That would eliminate parser
irregularities with angle brackets.
Those have been removed in the next standard already, no need for square
brackets.
Then use Fortran style syntax for
indexing, i.e. p (0), p (1). Interestingly, this extends elegantly to
multi-dimensional arrays, m (0, 1), while the current C++ square
bracket operator does not; since it accepts only one parameter. It
seems that, with regularity, less is more.
I seriously doubt that there is any technical problem with allowing the
[] operator to accept more than one argument, it seems to me more like
an arbitrary decision once made which none bothers to challenge.

--
Erik Wikström
Jun 27 '08 #37

P: n/a
Erik Wikström wrote:
On 2008-06-03 15:15, Vidar Hasfjord wrote:
>Then use Fortran style syntax for
indexing, i.e. p (0), p (1). Interestingly, this extends elegantly
to multi-dimensional arrays, m (0, 1), while the current C++ square
bracket operator does not; since it accepts only one parameter. It
seems that, with regularity, less is more.

I seriously doubt that there is any technical problem with allowing
the [] operator to accept more than one argument, it seems to me
more like an arbitrary decision once made which none bothers to
challenge.
It has been challenged, but not enough.

I have seen published search results by people trying to find code
using an overloaded comma operator inside the brackets. None found, if
I remember correctly.

However, both C and C++ already have a defined meaning for a[x,y],
though pretty useless. The proposers of a new meaning just haven't
been persistent enough, to convince a majority.

Recent radical changes to the keyword 'auto' might have set a new
precedent though. :-)
Bo Persson
Jun 27 '08 #38

P: n/a
Noah Roberts wrote:
Well, I prefer something more like so:

template<typename S, typename T// compute index of T in S
struct IndexOf
: mpl::distance
<
typename mpl::begin<S>::type
, typename mpl::find<S, T>::type
>
{};

But to each his own. Neither is particularly difficult to understand.
Suppose we could write it as:

int IndexOf(S, T)
{
return distance(begin(S), find(S, T));
}

Would you prefer the latter? I sure would.
Jun 27 '08 #39

P: n/a
Matthias Buelow wrote:
Erik Wikström wrote:
>> int[] table;
table ~= 5;
The natural interpretation of the above would in C++ be "table != 5".
Assigning non-intuitive meanings to operators is much worse than a lack
of compactness. If you really want an operator use either += or <<.

I agree; I associate some kind of negation with ~, not concatenation.
For ~=, I'd probably go with the C-style interpretation of = ... ~, or
interpret it as some kind of congruence operator.
Since ~ and ~= are not used as binary operators in C, there really isn't
any significant baggage associated with it. It doesn't take long at all
to get used to it as concatenation.

After all, how long did it take anyone to get used to * meaning multiply
as a binary operator, and pointer indirection as a unary one? Is there
something intuitive about * meaning indirection for non-C programmers?
Or how about & meaning 'and' and 'address of' ?

Before 1990, who had ever used < to denote argument lists before?
Jun 27 '08 #40

P: n/a
Bo Persson wrote:
I have seen published search results by people trying to find code
using an overloaded comma operator inside the brackets. None found, if
I remember correctly.
There was a post of one that made use of a special type...MagicInt if I
recall correctly. Took place in a discussion on () vs. [] for matrix
abstractions a year or two ago here in this group.
Jun 27 '08 #41

P: n/a
On Jun 4, 1:07*am, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
[...]
I don't know of a property of compile time programming that requires it
to be more complex than runtime programming.
That's a good point. But an interesting follow-up question to that is:
Should it be different?

Having thought about this superficially my intuition is that the
compile-time domain and the runtime domain calls for different
programming paradigms. In a way I think C++ just stumbled upon the
holy grail: It found the ideal domain for functional programming
languages; the compile-time domain.

Meta-programming operates in a formal domain; the domain of the type-
system of the language. Functional programming is a perfect fit here
as it is suited for formal proofs etc. Hence I don't think imperative
features, such as mutating constructs and side-effects, belong at
compile-time.

C++ has introduced a new era where the compiler is an execution
platform in itself. So the challenge for future language development
is to make the meta-language; the functional programming language that
runs in the compiler, optimal both for programmer expressiveness and
clarity and for efficient compile-time execution.

Regards,
Vidar Hasfjord
Jun 27 '08 #42

P: n/a
On Jun 3, 3:16*pm, kwikius <a...@servocomm.freeserve.co.ukwrote:
[...]
I've been toying about with this stuff myself. I've been looking at LL
grammars for a C++ like language without the crud.
That is very interesting. Do you have any published work, or links to
other work in this area, that I can look at?

I am only aware of SPECS (Significantly Prettier and Easier C++
Syntax) by Werther and Conway. I think that syntax could be made even
simpler by dropping the type constructor operators for pointers and
arrays. That would free the square brackets for template use (SPECS
uses <[]>; unambiguous, but verbose). It is still a good effort.

Regards,
Vidar Hasfjord
Jun 27 '08 #43

P: n/a
Vidar Hasfjord wrote:
Having thought about this superficially my intuition is that the
compile-time domain and the runtime domain calls for different
programming paradigms.
That means that the programmer needs to learn two languages instead of
one. To ask for this one must have some pretty compelling benefits of it
to justify it.
In a way I think C++ just stumbled upon the
holy grail: It found the ideal domain for functional programming
languages; the compile-time domain.
I don't understand why, for instance:

int foo(int x)
{
x = 3 + x;
for (int i = 0; i < 10; i++)
x += 7;
return x;
}

is inappropriate for compile time execution. Of course, it could be
rewritten in FP style, but since I'm programming in C++, why shouldn't
straightforward C++ work?

Meta-programming operates in a formal domain; the domain of the type-
system of the language. Functional programming is a perfect fit here
as it is suited for formal proofs etc. Hence I don't think imperative
features, such as mutating constructs and side-effects, belong at
compile-time.
Regardless of the merits of FP programming, regular C++ programming is
not FP and it is not necessary for compile time evaluation to be FP.
C++ has introduced a new era where the compiler is an execution
platform in itself. So the challenge for future language development
is to make the meta-language; the functional programming language that
runs in the compiler, optimal both for programmer expressiveness and
clarity and for efficient compile-time execution.
C++ has opened the door on that, I agree. Where I don't agree is that
C++ has stumbled on the ideal way of doing compile time programming, or
that FP is ideal for it, or that compile time programming should be in a
different language than runtime programming.

I am not an expert in C++ TMP. But when I do examine examples of it, it
always seems like a lot of effort is expended doing rather simple things.

Furthermore, because every step in evaluating TMP requires the
construction of a unique template instantiation, this puts some rather
onerous memory and time constraints on doing more complicated things
with TMP. Perhaps these are merely technical limitations that will be
surmounted by advancing compiler technology, but I just don't see how
the result could be better than thousands of times slower than executing
the equivalent at run time.
Jun 27 '08 #44

P: n/a
On Jun 4, 6:01*am, Vidar Hasfjord <vattilah-gro...@yahoo.co.ukwrote:
On Jun 3, 3:16*pm, kwikius <a...@servocomm.freeserve.co.ukwrote:
[...]
I've been toying about with this stuff myself. I've been looking at LL
grammars for a C++ like language without the crud.

That is very interesting. Do you have any published work, or links to
other work in this area, that I can look at?
I havent got anything publishable on my own doodlings, however for LL
grammar I seriously recommend SLK

http://home.earthlink.net/~slkpg/

It has nice properties. Various languages supported.. The actions are
largely separated from the grammar source and this puts more emphasis
on the grammar than semantics, which should I conjecture lead to a
cleaner grammar than e.g Bison. Also grammar source files are nice and
compact to pass around for discussion...
I am only aware of SPECS (Significantly Prettier and Easier C++
Syntax) by Werther and Conway. I think that syntax could be made even
simpler by dropping the type constructor operators for pointers and
arrays. That would free the square brackets for template use (SPECS
uses <[]>; unambiguous, but verbose). It is still a good effort.
I will certainly take a look. Unfortunately I have a lot of other work
currently so I can't spend the time I would like to on it.... but IMO
it has to be done as I have hit the C++ wall (e.g TMP complexity long
compile times etc. I think that will only get worse with C++0x
Concepts (which also dont seem to play too well with TMP).

regards
Andy Little

Jun 27 '08 #45

P: n/a
Vidar Hasfjord wrote:
C++ has introduced a new era where the compiler is an execution
platform in itself.
This isn't anything new; Lisp macros have been doing that for uhm..
decades, if I'm right. A C++ template is a special kind of compiler
macro where the expansion is controlled by the type parameters, whereas
a Lisp macro, for example, can use the full language to produce code to
substitute in its place, by any computation conceivable (including side
effects). I agree that compiler macros (including C++ templates) are a
useful tool for extending the language.
Jun 27 '08 #46

P: n/a
On Jun 3, 12:27 pm, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
James Kanze wrote:
In the (now distant) past, there was an argument for reducing
the number of characters. If you've ever heard a listing output
to a teletype, you'll understand. But I know of no programmer
today who develops code on a teletype. (But then, everyone I
know is in either western Europe or North America. Perhaps in
less priviledged regions.)
I've had many programmers tell me that their style of
programming is based on how much they can see on their
screens. As screens have gotten bigger, their mental "unit of
code" has increased to match. I know I used to make all my
functions fit in 24 lines or less, now 60 lines is typical.
Help. I find that if a function is more than about 10 lines,
it's a warning sign that it's getting too complex. There are
exceptions, of course. A function which consists of a single
switch statement with a lot of entries, for example. The real
criteria is complexity, but in my own work, I find that ten
lines generally means that its time to watch out.
Take a look at Scott's slides again. I don't see any
reasonable way of formatting it to look decent on a screen.
That's not my argument. I'm certainly not going to argue that
C++ syntax is clear, concise or elegant. Just that less isn't
always better either---had there been a little more wordiness in
C's declaration syntax, we'd have a lot less problems today, for
example.
I think that your suggestion itself is a perfect example of that:
> table ~= 5;
Yes, that uses less characters than "table.push_back(5);".
However, why would that be any clearer and more
understandable? On the contrary, it's more obfuscated.
From the looks of things, Walter would like APL. A language
known for read only programs.
Since the D programming language looks nothing like APL (or
Perl), I don't understand your comment at all.
Humor, mostly. But when you start arguing that something is
better just because it requires less characters to write, you're
definitly moving in the direction of APL.
Also, the way arrays work in D, which includes using the ~ and
~= operators, are frequently cited by D users as one of the
main reasons they like D. Do you really believe that ~ as
concatenation and ~= for append is "obfuscation" ?
In C++, it definitely would be. In another language... I don't
know. I can see the need for a generic concatenation operator
(rather than just overloading +), and I don't see any good
spelling for it (unlike "or" for |). And it's probably frequent
enough that you can live with some arbitrariness (i.e. it not
being based on established mathematical use, like +). So I
guess it would fit in like << does for output in C++.

But even then, only as a special case. I certainly hope you
don't try to define single character special operators for every
single operation on a container.
The problem with verbosity, however, isn't the lenght (in
characters) of the words (tokens).
It's both the length and the fact that there are so many
tokens needed to be strung together to perform basic
operations. What you're trying to accomplish gets lost in all
the < and ::.
I guess it depends on what you are trying to accomplish. That's
certainly the case for TMP. And I have nothing against some
shorter syntax, per se, if it's reasonably readable. Note,
however, that part of the added length comes from longer names
and namespaces. But I would certainly prefer vector< string >
to v<s>. I don't have a simple solution; for better or for
worse, we're dealing in a larger solution space than in the old
days, the amount of information that needs to be communicated
has gone up significantly, some redundancy is necessary for
human comprehension, and the result does require more characters
(each of which can only hold so much information).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #47

P: n/a

"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:tN******************************@comcast.com. ..
Vidar Hasfjord wrote:
>Having thought about this superficially my intuition is that the
compile-time domain and the runtime domain calls for different
programming paradigms.

That means that the programmer needs to learn two languages instead of
one. To ask for this one must have some pretty compelling benefits of it
to justify it.
library versus application writing
>In a way I think C++ just stumbled upon the
holy grail: It found the ideal domain for functional programming
languages; the compile-time domain.

I don't understand why, for instance:

int foo(int x)
{
x = 3 + x;
for (int i = 0; i < 10; i++)
x += 7;
return x;
}

is inappropriate for compile time execution. Of course, it could be
rewritten in FP style, but since I'm programming in C++, why shouldn't
straightforward C++ work?
It would potentially make a type mutable (different) in different
translation units I think.

regards
Andy Little
Jun 27 '08 #48

P: n/a
On Jun 4, 11:48*am, Matthias Buelow <m...@incubus.dewrote:
Vidar Hasfjord wrote:
C++ has introduced a new era where the compiler is an execution
platform in itself.

This isn't anything new;
True, that statement of mine was sloppy and incorrect. It should read
"Template meta-programming has brought C++ into a new era...". I was
thinking narrowly about the evolution of C++ and compiling C++
programs.
Lisp macros have been doing that for uhm.. decades, if I'm right.
Yes, and Lisp's powerful yet small and regular language definition
should be an inspiration to every programming language designer.

Regards,
Vidar Hasfjord
Jun 27 '08 #49

P: n/a
On Jun 4, 6:27 am, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
Vidar Hasfjord wrote:
Having thought about this superficially my intuition is that the
compile-time domain and the runtime domain calls for different
programming paradigms.

That means that the programmer needs to learn two languages instead of
one. To ask for this one must have some pretty compelling benefits of it
to justify it.
I look at it as two paradigms instead of two languages; the functional
paradigm and the imperative paradigm. C++ supports both; as does D; so
I'm sure you agree that's a good thing.

The question is whether all features (paradigms) of the language
should be available both for meta-programming and ordinary
programming. There has been work done on C++ extensions that allows
the full language for meta-programming (see Metacode by Vandevoorde),
but I lean towards restricting compile-time processing to the side-
effect free parts only, i.e. a functional subset.
I don't understand why, for instance:

int foo(int x)
{
x = 3 + x;
for (int i = 0; i < 10; i++)
x += 7;
return x;
}

is inappropriate for compile time execution.
Here I assume that you actually propose a very limited subset of
imperative features for compile-time processing; not that the whole
language should be available for processing at compile-time. A subset
of imperative features can be supported, as seen by constexpr function
in C++09 and by CTFE in D, but they are limited and required to live
by the rules of functional programming. For example, compile-time
functions must be 'pure', ie. the result must only depend on the
arguments, the function can have no side-effects and no state can
escape the function. I intuitively think this is good.

Or did you actually mean that you think the ideal would be something
akin to Metacode?
Furthermore, because every step in evaluating TMP requires the
construction of a unique template instantiation, this puts some rather
onerous memory and time constraints on doing more complicated things
with TMP. Perhaps these are merely technical limitations that will be
surmounted by advancing compiler technology, but I just don't see how
the result could be better than thousands of times slower than executing
the equivalent at run time.
Yes, these are the challenges I alluded to in my post. While limited
imperative features such as CTFE can ease some of this, I think C++
compilers will start looking more like execution environments for
functional languages as they evolve to handle meta-programs
efficiently. A lot of work on efficient processing of functional
languages has been done with good results. How feasable it is to bring
the results of this work into the construction of a C++ compiler I
don't know; but I can imagine the scale of the challenge.

Regards,
Vidar Hasfjord
Jun 27 '08 #50

123 Replies

This discussion thread is closed

Replies have been disabled for this discussion.