Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > What has C++ become?

Reply
Thread Tools

What has C++ become?

 
 
James Kanze
Guest
Posts: n/a
 
      06-13-2008
On Jun 12, 8:30 pm, Walter Bright <(E-Mail Removed)>
wrote:
> Pascal J. Bourguignon wrote:
> > Noah Roberts <(E-Mail Removed)> writes:
> >> You're calling the STL "low level code" when it is, in fact, high
> >> level code. The find_if algorithm, for instance, is a high level
> >> algorithm that can be used with any data type that obeys the iterator
> >> abstraction.


> > No. find_if is low level.


> > Compare:


> > Key k;
> > std::vector<Element> v;
> > std::vector<Element>::iterator end=v.end();
> > std::vector<Element>::iterator found;
> > found=find_if(v.begin(),end,boost::bind(&Key::equa l,k,boost::bind(&Element::getKey,_1)));
> > if(found==end){
> > doSomething(v,NULL);
> > }else{
> > doSomething(v,*found);
> > }


> > vs.


> > (lambda (k v) (do-something v (find-if (lambda (e) (equal k (get-key e))) v)))


> The STL code is a fairly straightforward translation into the D
> programming language:


> import std.algorithm;
> Key k;
> Element[] v;
> auto found = find!("k == a.getKey()")(v);
> if (found == end(v))
> doSomething(v, null);
> else
> doSomething(v, *found);


> > In this specific example, lisp is even higher level (ie.
> > more concise):


> I'm not sure I agree with your definition of higher level
> being more concise. Doesn't higher level mean more abstract?


In the context being considered (where "highest level" ==
"application"), a rough first approximation is that "higher
level" means that it depends on some "lower level". Lowest
level is thus the compiler with its constituant libraries and
the OS. Highest level is the function main().

Although this doesn't map directly to abstraction, it is
somewhat related: at the application level, you deal with very
concrete types: ClientOrder, Affectation, etc. Types that are
very far removed from the machine hardware, or even what the
language offers directly. At the lowest level, you'd probably
be talking about electrons, but of course, you don't go down to
that level in C++; for pratical purposes, in this group, the
lowest level is C++ and the OS API.

Pascal's point is, no doubt, that Lisp is further from the
actual hardware (and thus higher level) that is C++. At least
in this one particular case---I'm not convinced that it would
generalize to all cases. And I don't quite see how it is
relevant here.

--
James Kanze (GABI Software) email:(E-Mail Removed)
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
 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      06-13-2008
On 11 Jun, 10:07, James Kanze <(E-Mail Removed)> wrote:
> On Jun 11, 4:54 am, Michael Furman <(E-Mail Removed)> wrote:
> > James Kanze wrote:


<snip>

> > > *A difference between maybe 5 seconds, and a couple of minutes
> > > [to compile]. Which is a very significant difference if you're
> > > sitting in front of the computer, waiting for it to finish.

>
> > I love when compilation takes more then a couple of seconds: I
> > have extra time to think! Sometimes it ends with killing the
> > compilation and doing something else, rather then trying the
> > result.

>
> Interesting development process. *I usually try to think before
> editing, much less compiling.


he must be using an Agile methodology




--
Nick Keighley

 
Reply With Quote
 
 
 
 
Vidar Hasfjord
Guest
Posts: n/a
 
      06-13-2008
On Jun 12, 1:27*pm, James Kanze <(E-Mail Removed)> wrote:
> Pascal J. Bourguignon wrote:
> > Noah Roberts <(E-Mail Removed)> writes:
> > > You're calling the STL "low level code" when it is, in fact,
> > > high level code. *The find_if algorithm, for instance, is a
> > > high level algorithm that can be used with any data type
> > > that obeys the iterator abstraction.

>
> This is, of course, totally ridiculous. *


Well, it seems there is confusion here stemming from two, quite
legitimate but different, uses of "high and low level" terminology. On
use is in describing system architecture layers (Kanzes' use) and one
is in describing abstraction levels (Roberts' use).

E.g. std::sort is at close to the highest possible abstraction level
for the algorithm it abstracts. Still it is probably used only at the
lower implementation layers of any system architecture.

See
http://en.wikipedia.org/wiki/High-level
http://en.wikipedia.org/wiki/Abstrac...ter_science%29

Regards,
Vidar Hasfjord
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      06-16-2008
Vidar Hasfjord wrote:
> On Jun 12, 1:27 pm, James Kanze <(E-Mail Removed)> wrote:
>> Pascal J. Bourguignon wrote:
>>> Noah Roberts <(E-Mail Removed)> writes:
>>>> You're calling the STL "low level code" when it is, in fact,
>>>> high level code. The find_if algorithm, for instance, is a
>>>> high level algorithm that can be used with any data type
>>>> that obeys the iterator abstraction.

>> This is, of course, totally ridiculous.

>
> Well, it seems there is confusion here stemming from two, quite
> legitimate but different, uses of "high and low level" terminology. On
> use is in describing system architecture layers (Kanzes' use) and one
> is in describing abstraction levels (Roberts' use).


Notice what is said in the Robert C. Martin article I liked to and used
as support. He states that the abstraction/higher level code (my use)
should be in the application code (other use). In other words the uses
are not actually different.

http://www.objectmentor.com/resources/articles/dip.pdf
http://www.objectmentor.com/resource.../stability.pdf

>
> E.g. std::sort is at close to the highest possible abstraction level
> for the algorithm it abstracts. Still it is probably used only at the
> lower implementation layers of any system architecture.


I never said that these STL routines were the highest level of
abstraction. They are specific algorithms and data container types.
Higher levels might make use of more abstraction that allows any
container to be used. These very well might make use of templates.

Kanze is trying to claim that template code belongs only in the "lower"
levels and not in "application code" and I'm trying to show that this
just isn't true. He's used as his backing to this argument that the STL
is low level code. I've tried to show that this also is not true, and I
think I've done a fairly good job of that.

STL objects and algorithms are relatively high level pieces of code.
They perform a set of abstract functionality that is not specific to any
particular data type until instantiated (and can even work with
polymorphic types with some wrapping). Unlike say operations like
strcmp or memset, which work at a low level on a particular data type
(raised only in the use of vague pointers), the templated nature of STL
operations allow them to work on any data type.

Dynamic polymorphism can be more abstract but static polymorphism can
also be quite abstract and can solve many problems at the *highest*
levels of your *application code*. It makes no sense to say that they
should only be used in low level development since they frankly don't
actually fit there too well. Low level is where you have specifics,
places where a particular non-abstraction is manipulated. This is not
what templates are. Chances are that your code will be more dynamically
than statically polymorphic but this does not mean that static
polymorphisms are for low level code nor that it isn't perfectly
appropriate in application code.

I would even go as far as saying that generic programming is a higher
level, more abstract AND higher in structure, than oop.

>
> See
> http://en.wikipedia.org/wiki/High-level
> http://en.wikipedia.org/wiki/Abstrac...ter_science%29
>
> Regards,
> Vidar Hasfjord

 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      06-16-2008
Pascal J. Bourguignon wrote:
> Noah Roberts <(E-Mail Removed)> writes:
>
>> Pascal J. Bourguignon wrote:
>>> Noah Roberts <(E-Mail Removed)> writes:
>>>> You're calling the STL "low level code" when it is, in fact, high
>>>> level code. The find_if algorithm, for instance, is a high level
>>>> algorithm that can be used with any data type that obeys the iterator
>>>> abstraction.
>>> No. find_if is low level.
>>> Compare:
>>> Key k;
>>> std::vector<Element> v;
>>> std::vector<Element>::iterator end=v.end();
>>> std::vector<Element>::iterator found;
>>> found=find_if(v.begin(),end,boost::bind(&Key::equa l,k,boost::bind(&Element::getKey,_1)));
>>> if(found==end){
>>> doSomething(v,NULL);
>>> }else{
>>> doSomething(v,*found);
>>> }
>>> vs.
>>> (lambda (k v) (do-something v (find-if (lambda (e) (equal k
>>> (get-key e))) v)))
>>> And again, here I already used boost::bind; if I had to use the stl
>>> instead it would have tripled the number of line.
>>> And again, here I transposed directly. In this specific example,
>>> lisp
>>> is even higher level (ie. more concise):
>>> (lambda (k v) (do-something v (find k v :key (function get-key)
>>> :test (function equal))))
>>> You just cannot say tht the STL is high level. You only can say
>>> that
>>> it is slightly higher level than pure C code. But it doesn't
>>> qualifies yet as "high level".
>>>

>> I'm fairly confident that the distinction between low and high level
>> code has nothing to do with whether it was written in Lisp.

>
> Indeed. It is theorically possible to write a high level library in
> C++. But strangely enough, it looks like it's so hard to do that it's
> not done often... Ok, just nagging, there's Lpp.
> http://www.interhack.net/projects/lpp/
>


What I'm saying is that you didn't actually use the find algorithm
differently. There is one key difference only and that is a consequence
of the language you are using only. That difference is that the lisp
version can return (), which is the same as returning 0 in C++. That is
possible because of lisp's fundamental list nature...all lists end in
(). In C++ it doesn't work for all container type, vectors for instance
should not return 0 for their end since that doesn't meet the
requirements of the iterator concept in the C++ language: namely that it
is not reachable from begin() with ++ operations.

This is what allowed you to avoid checking the end() iterator before
calling the do_something routine. To perform this, in C++, would
require losing some abstraction and thus getting lower in your level of
code.

In other words, the only, and I mean the only, difference between the
two pieces of code you supplied is that one is written in C++ and the
other in LISP. The C++ version is an abstraction that wraps up the
concepts within the language it is written in, the lisp version does it
the lispish way. The two versions of find_if are at the same level of
abstraction.

Now, that being the case, you could have used the ternary operator
and/or boost::lambda to put all that in one line of code if you really
wanted to, just as your use in lisp does. I for one don't happen to
like that style of coding all the time and until C++ comes out with
lambda expressions I don't encourage the use of them (boost::lambda is
not without problems). Pretty sure this is, in fact, on the way but
we'll see if they make it; I'm not on the committee I just saw them
working on it at boostcon.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      06-17-2008
On Jun 16, 8:12 pm, Noah Roberts <(E-Mail Removed)> wrote:
> Vidar Hasfjord wrote:
> > On Jun 12, 1:27 pm, James Kanze <(E-Mail Removed)> wrote:
> >> Pascal J. Bourguignon wrote:
> >>> Noah Roberts <(E-Mail Removed)> writes:
> >>>> You're calling the STL "low level code" when it is, in fact,
> >>>> high level code. The find_if algorithm, for instance, is a
> >>>> high level algorithm that can be used with any data type
> >>>> that obeys the iterator abstraction.
> >> This is, of course, totally ridiculous.


> > Well, it seems there is confusion here stemming from two,
> > quite legitimate but different, uses of "high and low level"
> > terminology. On use is in describing system architecture
> > layers (Kanzes' use) and one is in describing abstraction
> > levels (Roberts' use).


> Notice what is said in the Robert C. Martin article I liked to
> and used as support. He states that the abstraction/higher
> level code (my use) should be in the application code (other
> use).


Which only makes sense: the application is the highest level, in
the sense I'm using the words.

> In other words the uses are not actually different.


> http://www.objectmentor.com/resource.../stability.pdf


> > E.g. std::sort is at close to the highest possible
> > abstraction level for the algorithm it abstracts. Still it
> > is probably used only at the lower implementation layers of
> > any system architecture.


> I never said that these STL routines were the highest level of
> abstraction. They are specific algorithms and data container
> types. Higher levels might make use of more abstraction that
> allows any container to be used. These very well might make
> use of templates.


> Kanze is trying to claim that template code belongs only in
> the "lower" levels and not in "application code" and I'm
> trying to show that this just isn't true.


I'm not "claiming"; I'm constating. Templates, as implemented
by most compilers today, don't work well at the application
level. It's not a big problem, yet, because typically, most
polymorphism at the application level needs to be dynamic. The
need for templates is less.

Today, at least. Like most people, I'm intreged by the
possibilities of TMP. For the moment, however, it's not
generally used at the application level, and we can't really
experiment too much with it to determine whether it is relevant
or not at this level, because of the way most compilers
implement templates.

> He's used as his backing to this argument that the STL is low
> level code. I've tried to show that this also is not true,
> and I think I've done a fairly good job of that.


You've not shown anything. The STL is extremely low level, in
this sense, since it is (formally) part of the compiler; it
depends on nothing else.

Perhaps it is a problem of definition. In this case, I'm not
arguing about the level of abstraction (although the STL is
pretty low level in this respect, as well); I'm arguing about
dependencies.

Actually, even dependencies, and low level vs. high, probably
aren't the issue. Stability is. Templates don't work in code
that isn't stable, because of the dependencies they introduce.
Application level code is normally the least stable; if the
application requirements change, you have to change it, and if
the application requirements don't change, you don't have to
change anything. The STL, as part of the compiler, is the most
stable---you don't ever change anything in the STL yourself, and
of course, if you change compilers---something you don't want to
do very often---you do a complete rebuild anyway.

Anyway, the fact remains that in well run shops developing large
applications, the use of templates is strictly limited to the
most stable, lower levels, and this is really where they are
most essential.

> STL objects and algorithms are relatively high level pieces of
> code. They perform a set of abstract functionality that is
> not specific to any particular data type until instantiated
> (and can even work with polymorphic types with some wrapping).


But they still expose far too many "details". When is an
iterator valid? It depends on the type of container.

> Unlike say operations like strcmp or memset, which work at a
> low level on a particular data type (raised only in the use of
> vague pointers), the templated nature of STL operations allow
> them to work on any data type.


> Dynamic polymorphism can be more abstract but static
> polymorphism can also be quite abstract and can solve many
> problems at the *highest* levels of your *application code*.


Certainly. But that's not really the issue here. The issue is
that at the highest levels of application code---code which is
changing constantly---templates, as currently
implemented by most compilers---don't work. And at present,
it's not really an issue, because they're not that necessary.
Although TMP shows some promess of being applicable for certain
things at that level, the technology isn't stable enough or
mature enough that you'd want to use it yet.

> It makes no sense to say that they should only be used in low
> level development since they frankly don't actually fit there
> too well. Low level is where you have specifics, places where
> a particular non-abstraction is manipulated. This is not what
> templates are. Chances are that your code will be more
> dynamically than statically polymorphic but this does not mean
> that static polymorphisms are for low level code nor that it
> isn't perfectly appropriate in application code.


> I would even go as far as saying that generic programming is a
> higher level, more abstract AND higher in structure, than oop.


Which, of course, is silly, unless you redefine higher level to
mean something it has never meant.

In terms of *flexibility* (which I think is what you're really
talking about), there is the old argument of static vs. dynamic
typechecking. Languages like Smalltalk or lisp, which have
fully dynamic type checking, are more flexible than C++ or Java,
which do static type checking. This flexibility comes at a cost
in robustness, however; while people have done it, I'd be very
sceptical of writing a concrete application (as opposed to
prototyping) using a dynamically typed language. In the case of
C++ templates, we have a case of dynamically typed polymorphism,
but since the polymorphism is resolved at compile time, we do
not loose the robustness of compile time type checking. (On the
other hand, we do loose the flexibility of having it resolved at
run time. It's a different compromise.)

--
James Kanze (GABI Software) email:(E-Mail Removed)
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Some shareware has a time limit and the software will not work after the time limit has expired. anthony crowder Computer Support 20 01-16-2007 10:01 AM
When a control on form has blank value or has no items (dropdownlist) then it wont' be in Request.Forms TS ASP .Net 3 10-06-2006 01:29 PM
The printing has been stopped and this job has been add to the queu? dejola Computer Support 6 12-30-2005 03:26 AM
Downloaded document has disappeared by the time Word has opened Rob Nicholson ASP .Net 12 12-06-2005 04:59 PM
ZoneAlarm has detected a problem with your installation, and therefore has restricted Internet access from your machine for your protection. Don’t panic A Teuchter Computer Support 2 05-19-2005 09:20 PM



Advertisments