«

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 >:ther 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

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

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.com> 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<int> table;
> >> 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:
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

On Jun 3, 10:56 am, Juha Nieminen <nos...@thanks.invalid> 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. 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:
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

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.

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

On Jun 3, 10:18*am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> [...]
> 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 >:ther 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

On Jun 3, 2:15*pm, Vidar Hasfjord <vattilah-gro...@yahoo.co.uk> wrote:

<...>

> 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

On Jun 3, 2:48*pm, Vidar Hasfjord <vattilah-gro...@yahoo.co.uk> wrote:

<...>

> * 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

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.