"Small C++" Anyone?

[Ian Collins]

Why?

See

http://www.research.att.com/~bs/bs_faq.html#EC++

for some good arguments. In my opinion, the inability to use the
standard library or any form of generic programming is a huge retrograde
step.

Sounds like passion rather than objectivity.

I'd say its the truth. Languages evolve for a reason.

Or "stagnated"? Dish it out and take it. LOL. To someone wishing to
create "a better C++" and not wanting to reinvent the wheel, cfront may save
some people some time.

But why bother? We have been there and moved on. I've used cfront
compilers, they were a good thing in their day, giving a better C. But
users wanted more, so the language grew to meet the demand, not just for
the sake of growing.

 

[Ian Collins]

But, I assume, pretty unapproachable at the source code level. You see, the
whole point is to not have to wade through the mud of complexity for
features that are undesireably in "Small C++".

It's not too bad. I have worked on a port ans once you get into the
code, it isn't any worse than any other code base.

You won't really know that until you create "that other thing", now will
you.

Can you name any EC++ only compliers, that is ones that aren't part of a
tool suite that includes a full C++ compiler? If no one wants a
standardised subset, who's going to want an ad hoc one?

 

[JohnQ]

See

http://www.research.att.com/~bs/bs_faq.html#EC++

I've read that a few times. And every time I do, I have to say "take it with
a grain of salt". Because he's "in the box" rather than outside of it. (No
offense Bjarne!). Perhaps only because "I don't know any better". But ya
never know until you try. It sounds to me it went something like this:
multi-million dollar capable implementors applauded it, but that left out
those who could not enter the market at that level. Is it necessarilly
complex or designed to be complex? Personally, I like simple and elegant
solutions. With it's implementation requirements, C++ is definitely a pile
driver in comparison. (Please remember though that I like C++ a lot. I may
be getting a bit long in the tooth though). I think C++ has evolved into
some kind of "end" instead of the "means" it should be/should have been.

for some good arguments. In my opinion, the inability to use the
standard library or any form of generic programming is a huge retrograde
step.

It kinda bothers me that there is only one. Seems stifling. I just wonder
what else could be (and even could have been) if all the eggs weren't in one
basket.

I'd say its the truth. Languages evolve for a reason.

Surely more than ONE reason. Was that a freudian?

But why bother? We have been there and moved on.

I don't think anyone "has been there" because at some point in the early
evolution, there could have been other roads to take (forks in the road!),
but the one that was chosen was the current one. So I'm curious about what's
down those other paths. And yes, I've read D&E, pretty much when it was
first published. And I agree with most of it. A lot came after that though.

I've used cfront
compilers, they were a good thing in their day, giving a better C. But
users wanted more, so the language grew to meet the demand, not just for
the sake of growing.

Well I'm not suggesting anyone go back to cfront and call it a day. I too
don't see any reason to make C an intermediate language between the C++ code
and the assembler/machine code. If I was a language implementer (pseudo
compiler developer), I think I'd want to play around with cfront though. I
guess I'm thinking (aside, now) about language development tools. Stroustrup
translated into C, which was good solution that allowed him to experiment
with his ideas. Is there something else now? Or could cfront be useful to
language designers/creators/experimentors? If so, maybe HP would like to
open source theirs?

John

 

[JohnQ]

in

Templates (generics) solve a nice set of real-world problems.
I'd expect that, were this not a part of "small-c++" a tempalte/generic
sort
of mechanism would be rather quickly requested.

I tend to agree with you. But maybe newly considered with implementation
criteria? Maybe the current templates are the 100% solution, but maybe some
would opt for the 80% solution knowing that the implementation is simple and
elegant not requiring many man years of effort to figure out how to
implement them.

Same with namespaces.

For something seemingly so "wrapped around everything else", I am very
surprised to learn that implementing namespaces is difficult.

John

 

[JohnQ]

It's not too bad. I have worked on a port ans once you get into the
code, it isn't any worse than any other code base.
Can you name any EC++ only compliers, that is ones that aren't part of a
tool suite that includes a full C++ compiler? If no one wants a
standardised subset, who's going to want an ad hoc one?

Well I certainly didn't suggest that EC++ would be enough to make it
compelling. That (or something close to that) may be the starting point of
"the fork in the road" though. Do you see what I mean?

John

 

[Ian Collins]

I've read that a few times. And every time I do, I have to say "take it with
a grain of salt". Because he's "in the box" rather than outside of it. (No
offense Bjarne!). Perhaps only because "I don't know any better". But ya
never know until you try. It sounds to me it went something like this:
multi-million dollar capable implementors applauded it, but that left out
those who could not enter the market at that level.

gcc is a $0 implementation.

Is it necessarilly
complex or designed to be complex? Personally, I like simple and elegant
solutions. With it's implementation requirements, C++ is definitely a pile
driver in comparison. (Please remember though that I like C++ a lot. I may
be getting a bit long in the tooth though). I think C++ has evolved into
some kind of "end" instead of the "means" it should be/should have been.

Don't mistake the language with its use, something which can be an
elegant one liner in C++ would be an inelegant mess in assembler. The
better a language enables the programmer to express abstract concepts,
the more elegant the programmers solution will be.

It kinda bothers me that there is only one. Seems stifling. I just wonder
what else could be (and even could have been) if all the eggs weren't in one
basket.

Feel free to roll your own, but either way, it will come down to templates.

 

[Dave Rahardja]

Beyond those "only 2" are good engineering that considers all the aspects
and creates something practical, elegantly simple. Your "there are only 2
approaches" is myopic or extremism: only seeing endpoints rather than a
range or continuum of possibility. I think maybe C++ suffers from "gold
plating" (the excess functionality of templates for example).

I admire your enthusiasm, but I am more than a little amused by your naivet.
You're not the first one to want to make a better mousetrap, and you've fallen
into the trap of seeing "a good subset" as the one that works best _for you_.

To me, a complex language such as C++ is the result of a process to conquer
complexity. It is there to capture and express concepts that reflect the
complex nature of programming. Chopping up the standard to a subset will
likely mean excluding certain programming domains as well.

C++ is very economical in its specification. Although it is difficult to
implement a compiler for it, the difficulty lies in the problem domain that
the language addresses, and not in the language itself. Again, I challenge you
to excise portions of the language and not end up excluding certain
programming domains as well.

Making things easier for compiler writers is hardly a worthy goal if it comes
at the expense of the users of the language, and it doesn't even make economic
sense. Look: Assembly language is probably the simplest language to write a
compiler for, yet you don't see scads of competition in that field. C is much
simpler to compile, yet there are about as many C compiler vendors as C++.
Programmers buy tools that help them solve _their_ problems, not the compiler
vendor's.

Of course, I could be mistaken and you could be a genius. However, I'd like to
see some concrete examples of how you would "simplify" the language before I'm
convinced.

-dr

 

[Dennis \(Icarus\)]

I tend to agree with you. But maybe newly considered with implementation
criteria? Maybe the current templates are the 100% solution, but maybe some
would opt for the 80% solution knowing that the implementation is simple and
elegant not requiring many man years of effort to figure out how to
implement them.

IIRC, some of the complexity for the compiler writer (partial template
specialization?) eased the implementation of the C++ standard library
container classes.

For something seemingly so "wrapped around everything else", I am very
surprised to learn that implementing namespaces is difficult.

It may not be. Just that if absent, it'd soon be requested to resolve
conflicts.

Dennis

 

[Ira Baxter]

(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a toolchain
for it. ...

If you want to program in a fresh new language, you are welcome to do this.
Most of the world wants to program in languages for which there are already
tools: compilers, debuggers, IDES, ..., or are forced to program in
languages
that somebody chose for the current application sometime in the past.

If you follow that line of thought, you really have to build toolchains for
the langauges
in use. And yes, C++ is a royal pain (worse because it comes in 11
different
flavors, and each flavor changes a bit every year, ... how many dialects
of C++ has MS offered...?)

It does take a "world-wide undertaking" to make a tool chain for real
languages
like C++ and all the dialects. The approach we took was to build a
tool-chain generator,
so that we could build tools for a variety of langauges, and thus amortize
the cost for everybody. You can build your tool on top of ours,
for quite a wide variety of tools.

See http://www.semdesign.com/Products/FrontEnds/CppFrontEnd.html

 

[Adrian Hawryluk]

[snip]
See http://www.semdesign.com/Products/FrontEnds/CppFrontEnd.html

The link doesn't work, and your entire site seems to be in flash. Yuck!


Adrian

--
==========================================================
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
==========================================================

 

[Roberto Waltman]

... creating a nice little
Small C++ compiler devoid of C++ language features that make toolchain
(including the compiler) a nightmare to implement (?).
...

Somebody already did. "Lightweight C++":

http://students.ceid.upatras.gr/~sxanth/lwc/

It seems the author moved on to other interests, (the mailing list
carries little traffic, mostly spam)

I though of doing something like this myself, at the time when C++
compilers were not as common as today. (In particular for the 8 bit
processors I worked with.) Never got started since either g++ or
proprietary compilers were available for almost all processors I have
used in the last 10 years.

You may take a look at Objective-C, as an easier to implement language
if you give up C++ compatibility.

Roberto Waltman

[ Please reply to the group,
return address is invalid ]

 

[JohnQ]

JohnQ wrote:
Feel free to roll your own, but either way, it will come down to
templates.

Well that's the first time I've seen someone wrap up the value of C++ into
just one of its features. Interesting. I know templates get a lot of
newsgroup space, but still.

John

 

[JohnQ]

I admire your enthusiasm, but I am more than a little amused by your
naivet.
You're not the first one to want to make a better mousetrap, and you've
fallen
into the trap of seeing "a good subset" as the one that works best _for
you_.

Indeed. So at what point does a language become too unwieldy by trying to be
all things to all people?

To me, a complex language such as C++ is the result of a process to
conquer
complexity. It is there to capture and express concepts that reflect the
complex nature of programming. Chopping up the standard to a subset will
likely mean excluding certain programming domains as well.

Just hiding the complexity or shifting it over to another group of people
(compiler developers) doesn't seem optimimum at all.

C++ is very economical in its specification. Although it is difficult to
implement a compiler for it, the difficulty lies in the problem domain
that
the language addresses, and not in the language itself. Again, I challenge
you
to excise portions of the language and not end up excluding certain
programming domains as well.

Well maybe "domain-specific languages" are a potential solution.

Making things easier for compiler writers is hardly a worthy goal if it
comes
at the expense of the users of the language, and it doesn't even make
economic
sense.

I don't know what the range of possibility is. Is there some kind of "80% of
the way there point" that would be a better compromise?

Look: Assembly language is probably the simplest language to write a
compiler for, yet you don't see scads of competition in that field. C is
much
simpler to compile, yet there are about as many C compiler vendors as C++.
Programmers buy tools that help them solve _their_ problems, not the
compiler
vendor's.

Of course, I could be mistaken and you could be a genius. However, I'd
like to
see some concrete examples of how you would "simplify" the language before
I'm
convinced.

I'm not sure I didn't just "one up" myself by bringing in the concept of
domain-specific languages. On the flip side, I don't have the resources to
go off on such an R&D quest (beyond all the time I've got into it already
that is).

John

 

[Ian Collins]

Well that's the first time I've seen someone wrap up the value of C++ into
just one of its features. Interesting. I know templates get a lot of
newsgroup space, but still.

Don't quote me out of context. The bit you removed was, in reference to
EC++:

"In my opinion, the inability to use the standard library or any form of
generic programming is a huge retrograde step."

EC++ removed templates, stripping the language of one of its core
components and forcing users to reinvent everything in the C++ standard
library.

A language with a strong type system, but without any form of generics
is doomed.

 

[JohnQ]

Somebody already did. "Lightweight C++":

http://students.ceid.upatras.gr/~sxanth/lwc/

He appears to have "created" another cfront! The one good thing about
requiring C as intermediate code is that it inherently limits complexity.
Giving someone the whole compiler space to create in will result in pushing
complexity to the limit (no limit!) of native implementation. That's what
happened with C++? Also, the complexity and lack of standards at the
implementaion level wreaks havoc with binary compatibility (read, there is
no compatibility). Instead of trying to make implementations binary
compatible after giant complex things have been built, wouldn't that have
been a good criteria the the outset? I understand that existing code bases
are tied to the complexity they built on top of. For new development though,
given the lessons learned (and still being learned) from C++, a new (well,
not entirely new at all, --C++? ) language makes sense, IMO. Surely some
codebases would also migrate if there was value. Rreduced software
maintenance costs surely would be on such possibility for migration.

You may take a look at Objective-C, as an easier to implement language
if you give up C++ compatibility.

I don't think that drastic of a departure is necessary or desireable.

John

 

[JohnQ]

It does take a "world-wide undertaking" to make a tool chain for real
languages
like C++ and all the dialects. The approach we took was to build a
tool-chain generator,
so that we could build tools for a variety of langauges, and thus amortize
the cost for everybody. You can build your tool on top of ours,
for quite a wide variety of tools.

See http://www.semdesign.com/Products/FrontEnds/CppFrontEnd.html

How would that not be just building upon the existing complexity though? (It
wouldn't).

John

 

[JohnQ]

Don't quote me out of context. The bit you removed was, in reference to
EC++:

"In my opinion, the inability to use the standard library or any form of
generic programming is a huge retrograde step."

EC++ removed templates, stripping the language of one of its core
components and forcing users to reinvent everything in the C++ standard
library.

I thought the STL was controversial anyway (?): some like it and use it,
some don't like it but use it, others don't like it and don't use it. I
did't miquote you: you are implying that templates are pivotal/most
important. Perhaps if you see everything as a template (if you just have a
hammer...). I didn't suggest removing templates or any of the things that
EC++ takes away for that matter. I only suggested that going back to that
point may be a good starting point to do things better (or, yes, perhaps
indeed eliminate some things). Do I think that the template concept in its
present incarnation would survive the axe if I was doing the chopping, no.
Just jettisoning backward compatibility may be a boon.

A language with a strong type system, but without any form of generics
is doomed.

Well that's not to say that the highly intricate C++ implementation is the
only way to skin that cat. Maybe it's just the large target market of C++
that makes some of those things so difficult and not the concepts at all.

John

 

[Ian Collins]

I did't miquote you: you are implying that templates are pivotal/most
important.

Nonsense, I was saying that EC++ made a huge mistake in removing
templates and the standard library. This sub-thread started when you
asked my why I consider EC++ to be an abomination, I answered that question.

 

[Walter Bright]

I'm not suggesting changing C++,
but rather deriving a new, VERY C++-like language.

And one exists, it's the D programming language. There's even a GPL open
source version of it (GDC).

-Walter
Digital Mars
http://www.digitalmars.com/d/ The D Programming Language

 

[JohnQ]

Nonsense, I was saying that EC++ made a huge mistake in removing
templates and the standard library. This sub-thread started when you
asked my why I consider EC++ to be an abomination, I answered that
question.

But I was responding to where you said the following:

"Feel free to roll your own, but either way, it will come down to
templates."

Whatever context it is in, to me, that sounds like you think templates are
paramount: the maker/breaker of the success of any new language.

John