Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #58881

Re: New directions in C: References

From BGB <cr88192@hotmail.com>
Newsgroups comp.lang.c
Subject Re: New directions in C: References
Date 2015-03-24 16:54 -0500
Organization albasani.net
Message-ID <mesmm9$rer$1@news.albasani.net> (permalink)
References <me2bsd$62t$4@speranza.aioe.org> <55056e43.749593@news.xs4all.nl> <T3jNw.19534$pp5.4819@fx29.iad>

Show all headers | View raw


On 3/15/2015 12:12 PM, Greg Martin wrote:
> On 2015-03-15, Richard Bos <raltbos@xs4all.nl> wrote:
>> jacob navia <jacob@spamsink.net> wrote:
>>
>>> 1.7 References
>>
>> *Shudder* See my reply to operator overloading.
>>
>> Really, jacob, we _don't_ need tentacles coming out of everywhere. C is
>> not C++, let alone Perl. Its simplicity is its _best_ feature, not, as
>> you seem to think, its worst.
>>
>
> I think you're exactly right.
>
> I like C++ and this isn't meant as a knock on it but Stroustrup took C
> and added some stuff that he thought would make it better and they have
> just never stopped.
>
> If only C was more like <insert your favorite language here> it would be
> great seems to be the clarion cry!
>
> When Stroustrup called it a better C he really screwed up. It wasn't C
> then and it's farther from C now. Oh well. At least Java didn't go with
> MorePortableAndSafeThenCPP or we would have had
> MorePortableAndSafeThenCPPScript.
>

back when Java was new, a lot of people promoted it as "C++ done right", 
except it was neither C++ nor really "done right".


yeah, this is a problem...

some extensions could be nice, but in a way, we don't necessarily need 
another C++.

likewise a drawback with extensions (or writing code which depends on 
them), is that they tend to be implementation specific. in some cases, 
this matters more than others.


for example, for code targeting a particular piece of hardware (such as 
a microcontroller), one may already be stuck using some implementation 
specific code and/or dealing directly with hardware specific features, 
so it is almost a "may as well use some of the available language 
extensions".

but, for portable code, there may good reason to stay well and clear 
from depending on extensions.

but, in a way, this also means that the implementation should ideally be 
designed such that it doesn't force its extensions on the code 
(hindering people from writing portable code, or from possibly writing 
code to allow them to simulate the HW on their PC, with other code 
effectively taking the place of the external electronics, ...).

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

New directions in C: References jacob navia <jacob@spamsink.net> - 2015-03-14 23:14 +0100
  Re: New directions in C: References raltbos@xs4all.nl (Richard Bos) - 2015-03-15 11:35 +0000
    Re: New directions in C: References Melzzzzz <mel@zzzzz.com> - 2015-03-15 12:51 +0100
    Re: New directions in C: References Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-15 17:12 +0000
      Re: New directions in C: References BGB <cr88192@hotmail.com> - 2015-03-24 16:54 -0500
        Re: New directions in C: References Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-03-24 19:48 -0400
          Re: New directions in C: References Keith Thompson <kst-u@mib.org> - 2015-03-25 08:58 -0700
            Re: New directions in C: References David Brown <david.brown@hesbynett.no> - 2015-03-25 21:34 +0100

csiph-web