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

Groups > comp.lang.c > #20108 > unrolled thread

Re: How would you design C's replacement?

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: How would you design C's replacement? lawrence.jones@siemens.com - 2012-04-30 14:25 -0400
    Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-04-30 22:19 +0200
      Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-04-30 14:04 -0700
        Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-01 00:33 +0200
          Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-04-30 15:43 -0700
            Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:17 +0100
        Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:15 +0100
          Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-01 07:12 -0700
        Re: How would you design C's replacement? lawrence.jones@siemens.com - 2012-05-01 10:41 -0400
        Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 17:39 +0100
          Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 12:46 -0400
      Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 21:41 -0700
      Re: How would you design C's replacement? gwowen <gwowen@gmail.com> - 2012-05-01 00:22 -0700
      Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-01 15:53 -0400
      Re: How would you design C's replacement? Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2012-05-09 21:06 +0000
        Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-10 00:32 +0200
          Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-10 10:35 +1200
        Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-09 16:18 -0700
          Re: How would you design C's replacement? gazelle@shell.xmission.com (Kenny McCormack) - 2012-05-10 02:45 +0000
            Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-10 16:18 +0100
              Re: How would you design C's replacement? Robert Wessel <robertwessel2@yahoo.com> - 2012-05-11 03:21 -0500
                Re: How would you design C's replacement? gazelle@shell.xmission.com (Kenny McCormack) - 2012-05-11 15:55 +0000
                  Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-13 17:39 +0100
                    Re: How would you design C's replacement? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-05-14 00:08 -0700
                  Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-13 21:24 +0100
                    Re: How would you design C's replacement? Marco <prenom_nomus@yahoo.com> - 2012-05-20 06:50 -0700
            Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-10 00:08 -0700
            Re: How would you design C's replacement? gwowen <gwowen@gmail.com> - 2012-05-10 04:04 -0700
          Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-10 10:38 -0700
            Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-10 11:15 -0700
              Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 08:36 -0700
                Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 17:49 +0200
                  Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-11 09:34 -0700
                  Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 09:41 -0700
                    Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 19:42 +0200
                      Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-11 10:50 -0700
                        Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 20:16 +0200
                          Trigraphs (was Re: How would you design C's replacement?) Kenneth Brody <kenbrody@spamcop.net> - 2012-05-14 11:49 -0400
                            Re: Trigraphs (was Re: How would you design C's replacement?) James Kuyper <jameskuyper@verizon.net> - 2012-05-14 12:21 -0400
                              Re: Trigraphs Ben Pfaff <blp@cs.stanford.edu> - 2012-05-14 09:50 -0700
                                Re: Trigraphs James Kuyper <jameskuyper@verizon.net> - 2012-05-14 13:05 -0400
                                  Re: Trigraphs Ben Pfaff <blp@cs.stanford.edu> - 2012-05-14 10:24 -0700
                                    Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-14 11:56 -0700
                                      Re: Trigraphs jacob navia <jacob@spamsink.net> - 2012-05-14 21:00 +0200
                                        Re: Trigraphs Robert Wessel <robertwessel2@yahoo.com> - 2012-05-14 16:37 -0500
                                          Re: Trigraphs James Kuyper <jameskuyper@verizon.net> - 2012-05-14 17:58 -0400
                                            Re: Trigraphs Keith Thompson <kst-u@mib.org> - 2012-05-14 21:05 -0700
                                              Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-17 13:19 -0700
                                        Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-17 13:05 -0700
                                        Re: Trigraphs jgk@panix.com (Joe keane) - 2012-05-17 22:04 +0000
                                      Re: Trigraphs Walter Banks <walter@bytecraft.com> - 2012-05-14 16:22 -0400
                                        Re: Trigraphs "BartC" <bc@freeuk.com> - 2012-05-14 22:05 +0100
                                          Re: Trigraphs Walter Banks <walter@bytecraft.com> - 2012-05-14 22:31 -0400
                                            Re: Trigraphs Ben Pfaff <blp@cs.stanford.edu> - 2012-05-14 21:17 -0700
                                        Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-17 13:42 -0700
                                  Re: Trigraphs Keith Thompson <kst-u@mib.org> - 2012-05-14 13:33 -0700
                                    Re: Trigraphs Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-14 23:02 +0200
                                      Re: Trigraphs James Kuyper <jameskuyper@verizon.net> - 2012-05-14 17:35 -0400
                      Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 18:49 -0700
                    Re: How would you design C's replacement? Gareth Owen <gwowen@gmail.com> - 2012-05-11 18:49 +0100
                      Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 20:14 +0200
                        Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 18:56 -0700
            Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-10 11:31 -0700
              Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 08:38 -0700
                Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-11 09:36 -0700
                  Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 19:12 -0700
                    Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-14 11:56 -0400
                      Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-14 11:34 -0700
      Re: How would you design C's replacement? jgk@panix.com (Joe keane) - 2012-05-10 20:05 +0000
        Re: How would you design C's replacement? "J. J. Farrell" <jjf@bcs.org.uk> - 2012-05-11 06:19 +0100
    Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:33 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#20584

On Thu, 10 May 2012 16:18:20 +0100, Rui Maciel <rui.maciel@gmail.com>
wrote:

>Kenny McCormack wrote:
>
>> I think if you set out to design a replacement for C - that is, a C
>> without all the defects - you'd end up with something very close to D
>> (from Walter Bright).  From what I've read, D is what C should have been.
>
>The same is said about C++ (the language's motto was something like "a 
>better C"), and the fact of the matter is that the C++ programming language 
>is one of the most popular programming languages ever devised.
>
>
>> That D hasn't taken the world by storm should tell us (all of us)
>> something about what the market thinks of the idea of a replacement for C.
>
>Yes, it should tell us that the C++ programming language exists, and that 
>the D programming language doesn't offer any meaningful improvement over C++ 
>while presenting some disadvantages as well.


Either that or the advantages of being a mainstream language compared
to something as fringe a D are almost always overwhelming, no matter
what the technical merits are.  D might well be the greatest thing
since sliced bread (or not), but I don't know enough to judge.

Consider what your boss would say if you said you wanted to do the
next project in D rather than in C++.  Even if your boss is open
minded, what argument would you make?  D may be wonderful, but there
are (as a first order approximation) no tools, no programmers, no user
community, no standard, no support from major vendors.  Only if you
can argue that D is *so* wonderful that all that pales in comparison,
do you even have a chance.  And picking fairly pointless fights that
you're probably going to lose is not generally a positive career move.

Of course there are exceptions - Apple's choice of Objective-C, for
example, although it's hard to see how much they've actually gained
from that.  But for those outside Apple, Object-C's advantages *do*
outweigh the negatives of being a non-mainstream language - notably
that you need to use it to live well in the Apple environment, which
is important if you want to actually write products for that
environment (but that's really not a *technical*advantage).

[toc] | [prev] | [next] | [standalone]

#20594

In article <jmhpq75muo4p0s51hasi7hcir3vfk2fshl@4ax.com>,
Robert Wessel  <robertwessel2@yahoo.com> wrote:
...
>Either that or the advantages of being a mainstream language compared
>to something as fringe a D are almost always overwhelming, no matter
>what the technical merits are.  D might well be the greatest thing
>since sliced bread (or not), but I don't know enough to judge.

Rui completely missed the point, as I've come to expect from him.

But just to make it clear, what I was arguing was that *if* you were going
to set out to replace C, you'd end up with something like D.  That it hasn't
happened, tells you something about the wisdom of trying to replace C.

To be clear, the whole point is that D is C without the bugs, while C++ is C
embraced, expanded, enhanced, while keeping (most of) the bugs.

The bugs are what make C C.  And, no, I'm not here to argue about what is
and isn't a bug in C - except to say that I do agree with what Walter says
about it on his site (which I haven't read in several years, so don't bother
nitpicking me on specifics).  But the one I remember the best is the idea
that there should be no warnings.  A construct should either be correct or
wrong (a syntax error); that C has so much stuff that is "warning" level is
(in this view) a bug.

-- 
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy  of the church so decides." 

    - Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

[toc] | [prev] | [next] | [standalone]

#20684

"Kenny McCormack" <gazelle@shell.xmission.com> wrote in message 
news:jojcpt$rao$1@news.xmission.com...
> In article <jmhpq75muo4p0s51hasi7hcir3vfk2fshl@4ax.com>,

> To be clear, the whole point is that D is C without the bugs, while C++ is 
> C
> embraced, expanded, enhanced, while keeping (most of) the bugs.

D isn't C without bugs. There's a whole bunch of language enhancements in 
there too. It's more of a redesigned C++, so it's a much more complex 
language.

Also it deliberately breaks backwards compatibility, and not in minor ways 
either (for example, there's no macro preprocessor, so that's 99% of 
existing C that don't work even after translating #includes and simple 
#defines).

As for why it is not yet mainstream: it if really is that much better, then 
those companies that do use it, will have a competitive advantage; they 
would probably rather everyone else stuck to C or C++!

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#20763

Bart於 2012年5月14日星期一UTC+8上午12時39分09秒寫道：
> "Kenny McCormack" <gazelle@shell.xmission.com> wrote in message 
> news:jojcpt$rao$1@news.xmission.com...
> > In article <jmhpq75muo4p0s51hasi7hcir3vfk2fshl@4ax.com>,
> 
> > To be clear, the whole point is that D is C without the bugs, while C++ is 
> > C
> > embraced, expanded, enhanced, while keeping (most of) the bugs.
> 
> D isn't C without bugs. There's a whole bunch of language enhancements in 
> there too. It's more of a redesigned C++, so it's a much more complex 
> language.
> 
> Also it deliberately breaks backwards compatibility, and not in minor ways 
> either (for example, there's no macro preprocessor, so that's 99% of 
> existing C that don't work even after translating #includes and simple 
> #defines).
> 
> As for why it is not yet mainstream: it if really is that much better, then 
> those companies that do use it, will have a competitive advantage; they 
> would probably rather everyone else stuck to C or C++!
> 
> -- 
> Bartc

There are p2c and f2c programs available long time ago. 
Tiny C is good to be embeded in some risc architectures. 
One can't assume that programs in a system with HDs in tera bytes can 
work with i-phone or i-pad.

[toc] | [prev] | [next] | [standalone]

#20691

Kenny McCormack wrote:

> Rui completely missed the point, as I've come to expect from him.
> 
> But just to make it clear, what I was arguing was that if you were going
> to set out to replace C, you'd end up with something like D.  That it
> hasn't happened, tells you something about the wisdom of trying to replace
> C.

Speaking of missing the point:

You, again, failed to notice that in a significant number of applications, 
C++ already replaced C.

And C++ was developed as "a better C". 

So, by missing this fact, you failed to notice that a language was already 
"set out to replace C", and was quite successful at that. Or do you actually 
believe that C++ wasn't successful?

Then, regarding the D programming language.

It D was developed to try to replace C++, not C.  In fact, in the overview 
section of the official site[1], C++ is mentioned about 50 times in a 
section which contains about 250 lines of text.

So, you end up with something like D if you set out to replace C++. That's 
extensively covered in D's overview section.

The only thing we can take from D's relative popularity shortcomings is 
that, as a replacement for C++, it failed to provide any meaningful benefits 
over C++.

But that says nothing about C, doesn't it?

<snip/>


Rui Maciel

[1] http://dlang.org/overview.html

[toc] | [prev] | [next] | [standalone]

#21065

On Sunday, May 13, 2012 1:24:25 PM UTC-7, Rui Maciel wrote:
> 
> So, you end up with something like D if you set out to replace C++. That's 
> extensively covered in D's overview section.
> 
> The only thing we can take from D's relative popularity shortcomings is 
> that, as a replacement for C++, it failed to provide any meaningful benefits 
> over C++.

I disagree and feel that folks that would have adopted D probably committed to Java/JVM or C#/CLR already (in lieu of C++). D language stabilization may have been too late. 

Vala is another interesting language in the applications area.

> 
> But that says nothing about C, doesn't it?

 agreed - leave C alone 

> 
> [1] http://dlang.org/overview.html

[toc] | [prev] | [next] | [standalone]

#20736

On Thursday, May 10, 2012 3:45:58 AM UTC+1, Kenny McCormack wrote:

> Some of the more common characteristics of Asperger syndrome include: 
> 
> * Inability to think in abstract ways (eg: puns, jokes, sarcasm, etc)

odd, that computer programmers are often characterised as being "aspergers", I'd have thought programming involved a lot of abstract thinking.

you'll be giving us the definitions of "thlig" and "spas" next

[toc] | [prev] | [next] | [standalone]

#20738

On May 10, 3:45 am, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> I think if you set out to design a replacement for C - that is, a C without
> all the defects - you'd end up with something very close to D (from Walter
> Bright).

Something very close to D-with-typesafe-containers, or C++ with most
of the baroque insanity removed.

> That D hasn't taken the world by storm should tell us (all of us) something
> about what the market thinks of the idea of a replacement for C.

True.  C is good enough for nearly everything that requires C's mix of
portability and proximity to bare metal.  Higher level languages are
better for almost everything else.  Despite C's many peculiarities and
misfeatures, there is almost no demand for "C done right", because
almost nobody uses C to do things at which C is not very good.

[toc] | [prev] | [next] | [standalone]

#20569

Keith Thompson <kst-u@mib.org> writes:

> Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:
>> On Mon, 30 Apr 2012 22:19:23 +0200, jacob navia wrote:
>>> Le 30/04/12 20:25, lawrence.jones@siemens.com a @C3{A9}crit :
>>>> Rui Maciel<rui.maciel@gmail.com>  wrote:
>>>>> If you were given the task to design a replacement for the C
>>>>> programming language intended to fix all its problems and
>>>>> shortcomings, what would you propopose?
>>>>
>>>> That the person assigning the task get their head examined.  :-)
>>> 
>>> C is perfect?
>>> 
>>> Trigraphs included?
>>> 
>>> Now, come on...
>>
>> The ignorant words of someone who hasn't spent any time using a 3270 
>> terminal.
>
> Surely there were better ways to address that issue.

That's probably true, but I think the underlying point is valid.
Trigraphs were made part of C to overcome an important limitation
for a significant (undoubtedly small, but still significant) part
of its intended audience.  Granted, trigraphs are ugly, but given
that they were made part of the Standard they can't just be
discarded without regard to those for whom trigraphs were put in
to C in the first place.  Even though most developers never use
trigraphs (I know I don't), they are important to some code
development.  Has anyone made an effort to find out how much
legacy code there is that uses trigraphs?  I'm not aware of any.

Personally, I don't see why anyone (who doesn't use trigraphs)
would care much one way or the other whether C has them.  If
someone is concerned that trigraphs may occur unintentionally
in, eg, strings, it takes all of maybe 30 minutes to write
a tool to scan for them (or less if we can just use grep).
Just run the tool as part of regular compilation, flagging
the "error".  Problem solved.

[toc] | [prev] | [next] | [standalone]

#20571

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Personally, I don't see why anyone (who doesn't use trigraphs)
> would care much one way or the other whether C has them.  If
> someone is concerned that trigraphs may occur unintentionally
> in, eg, strings, it takes all of maybe 30 minutes to write
> a tool to scan for them (or less if we can just use grep).
> Just run the tool as part of regular compilation, flagging
> the "error".  Problem solved.

If you use GCC, -Wtrigraphs (part of -Wall) solves the problem
without even spending those 30 minutes.

[toc] | [prev] | [next] | [standalone]

#20589

Ben Pfaff <blp@cs.stanford.edu> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Personally, I don't see why anyone (who doesn't use trigraphs)
>> would care much one way or the other whether C has them.  If
>> someone is concerned that trigraphs may occur unintentionally
>> in, eg, strings, it takes all of maybe 30 minutes to write
>> a tool to scan for them (or less if we can just use grep).
>> Just run the tool as part of regular compilation, flagging
>> the "error".  Problem solved.
>
> If you use GCC, -Wtrigraphs (part of -Wall) solves the problem
> without even spending those 30 minutes.

Right.  In fact I have -Wtrigraphs set in my own standard build
environment, and it's been there so long I'd forgotten that I did.
And I presume most other implementations provide a similar option.
So I guess the suggestion was made just for those unfortunate
souls whose compiler isn't so equipped.

[toc] | [prev] | [next] | [standalone]

#20592

Le 11/05/12 17:36, Tim Rentsch a écrit :
> Ben Pfaff<blp@cs.stanford.edu>  writes:
>
>> Tim Rentsch<txr@alumni.caltech.edu>  writes:
>>
>>> Personally, I don't see why anyone (who doesn't use trigraphs)
>>> would care much one way or the other whether C has them.  If
>>> someone is concerned that trigraphs may occur unintentionally
>>> in, eg, strings, it takes all of maybe 30 minutes to write
>>> a tool to scan for them (or less if we can just use grep).
>>> Just run the tool as part of regular compilation, flagging
>>> the "error".  Problem solved.
>>
>> If you use GCC, -Wtrigraphs (part of -Wall) solves the problem
>> without even spending those 30 minutes.
>
> Right.  In fact I have -Wtrigraphs set in my own standard build
> environment, and it's been there so long I'd forgotten that I did.
> And I presume most other implementations provide a similar option.
> So I guess the suggestion was made just for those unfortunate
> souls whose compiler isn't so equipped.

So, you propose to mask the bug in the language by making all compilers
be non-conformant.


GREAT!

[toc] | [prev] | [next] | [standalone]

#20597

jacob navia <jacob@spamsink.net> writes:

> Le 11/05/12 17:36, Tim Rentsch a écrit :
>> Ben Pfaff<blp@cs.stanford.edu>  writes:
>>
>>> Tim Rentsch<txr@alumni.caltech.edu>  writes:
>>>
>>>> Personally, I don't see why anyone (who doesn't use trigraphs)
>>>> would care much one way or the other whether C has them.  If
>>>> someone is concerned that trigraphs may occur unintentionally
>>>> in, eg, strings, it takes all of maybe 30 minutes to write
>>>> a tool to scan for them (or less if we can just use grep).
>>>> Just run the tool as part of regular compilation, flagging
>>>> the "error".  Problem solved.
>>>
>>> If you use GCC, -Wtrigraphs (part of -Wall) solves the problem
>>> without even spending those 30 minutes.
>>
>> Right.  In fact I have -Wtrigraphs set in my own standard build
>> environment, and it's been there so long I'd forgotten that I did.
>> And I presume most other implementations provide a similar option.
>> So I guess the suggestion was made just for those unfortunate
>> souls whose compiler isn't so equipped.
>
> So, you propose to mask the bug in the language by making all compilers
> be non-conformant.

A compiler is allowed to issue a diagnostic for anything it
likes.

[toc] | [prev] | [next] | [standalone]

#20600

jacob navia <jacob@spamsink.net> writes:

> Le 11/05/12 17:36, Tim Rentsch a @C3{A9}crit :
>> Ben Pfaff<blp@cs.stanford.edu>  writes:
>>
>>> Tim Rentsch<txr@alumni.caltech.edu>  writes:
>>>
>>>> Personally, I don't see why anyone (who doesn't use trigraphs)
>>>> would care much one way or the other whether C has them.  If
>>>> someone is concerned that trigraphs may occur unintentionally
>>>> in, eg, strings, it takes all of maybe 30 minutes to write
>>>> a tool to scan for them (or less if we can just use grep).
>>>> Just run the tool as part of regular compilation, flagging
>>>> the "error".  Problem solved.
>>>
>>> If you use GCC, -Wtrigraphs (part of -Wall) solves the problem
>>> without even spending those 30 minutes.
>>
>> Right.  In fact I have -Wtrigraphs set in my own standard build
>> environment, and it's been there so long I'd forgotten that I did.
>> And I presume most other implementations provide a similar option.
>> So I guess the suggestion was made just for those unfortunate
>> souls whose compiler isn't so equipped.
>
> So, you propose to mask the bug in the language by making all compilers
> be non-conformant.

Please read my comments again.  I didn't propose, nor do I
propose, any such thing.  What I did say was that anyone
who is concerned about undesired trigraphs can easily prevent
them while still using compilers that accept trigraphs.  I
am not advocating making any changes to any compilers.

> GREAT!

That's sarcasm, isn't it?  If you have something to say,
I'd prefer you say it straight out.

[toc] | [prev] | [next] | [standalone]

#20602

Le 11/05/12 18:41, Tim Rentsch a écrit :
.  What I did say was that anyone
> who is concerned about undesired trigraphs can easily prevent
> them while still using compilers that accept trigraphs.

Easily?

Who knows about trigraphs?

How can you knwow that a trigraph in a comment van make for a syntax
error 365 lines later?


int fn(void)
{
   for (int i=0; i<100;i++) // is this is correct??/
    {
     .. 365 lines of code
    }
}

This code produces
/tmp $ g++ trigraphs.c
trigraphs.c:4:49: warning: trigraph ??/ ignored, use -trigraphs to enable

So the compiler is non conforming

Most compilers do ignore trigraphs but many don't. You are just saying:

Instead of correcting the bug at the source (the bad specifications)
let's accept a workaround that masks the bug

[toc] | [prev] | [next] | [standalone]

#20604

jacob navia <jacob@spamsink.net> writes:

> /tmp $ g++ trigraphs.c
> trigraphs.c:4:49: warning: trigraph ??/ ignored, use -trigraphs to enable
>
> So the compiler is non conforming

You have to add -trigraphs to run in conforming mode (in that
respect).  So?

[toc] | [prev] | [next] | [standalone]

#20610

Le 11/05/12 19:50, Ben Pfaff a écrit :
> jacob navia<jacob@spamsink.net>  writes:
>
>> /tmp $ g++ trigraphs.c
>> trigraphs.c:4:49: warning: trigraph ??/ ignored, use -trigraphs to enable
>>
>> So the compiler is non conforming
>
> You have to add -trigraphs to run in conforming mode (in that
> respect).  So?

So, it would be better if the bug was corrected at its source: the
badly specified C standard, that specifies those trigraphs!

That is what I am arguing. Mr Rentsch says that it is
"
  What I did say was that anyone
who is concerned about undesired trigraphs can easily prevent
them while still using compilers that accept trigraphs.
"
No, it is not easy (you have to KNOW about trigraphs in the first place)
then it is not the task of compilers to correct the bugs in the
language!

The fact that that option EXISTS is already the proof that the bug in 
the language exists.

[toc] | [prev] | [next] | [standalone]

#20700 — Trigraphs (was Re: How would you design C's replacement?)

On 5/11/2012 2:16 PM, jacob navia wrote:
[... trigraphs ...]
> So, it would be better if the bug was corrected at its source: the
> badly specified C standard, that specifies those trigraphs!
[...]

With all due respect, there's a world of difference between "bug" and "bad 
design choice".  While some might call the latter "broken as designed", it's 
not a "bug".

Note that, years ago, I was "bitten" by trigraphs.  I forget the specifics, 
but I believe that it was a filename wildcard which contained a valid 
trigraph sequence, which wasn't "working".  Once I found out what trigraphs 
were, I fixed my code, and didn't give them a second thought.


Now, if you were to propose eliminating them from the language (by default, 
at least), you still need a way to handle source that contains them.  I 
would suggest something like:

     #pragma STDC TRIGRAPH (ON|OFF)

The default would be "OFF".  Any source file that used trigraphs would 
simply put:

     #pragma STDC TRIGRAPH ON

at the top, and any conforming compiler would be compelled to enable them.

This might be extended to include some sort of "push/pop" ability, so that 
you could wrap trigraph-related code without forcing a particular setting 
afterward.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#20702 — Re: Trigraphs (was Re: How would you design C's replacement?)

On 05/14/2012 11:49 AM, Kenneth Brody wrote:
...
> Now, if you were to propose eliminating them from the language (by default, 
> at least), you still need a way to handle source that contains them.  I 
> would suggest something like:
> 
>      #pragma STDC TRIGRAPH (ON|OFF)
> 
> The default would be "OFF".  Any source file that used trigraphs would 
> simply put:
> 
>      #pragma STDC TRIGRAPH ON

A platform where trigraphs are actually needed (rare as those might be
nowadays) is likely to be one where "#" is not an available character.
That should be

	??=pragma STDC TRIGRAPH ON

[toc] | [prev] | [next] | [standalone]

#20705 — Re: Trigraphs

James Kuyper <jameskuyper@verizon.net> writes:

> On 05/14/2012 11:49 AM, Kenneth Brody wrote:
> ...
>> Now, if you were to propose eliminating them from the language (by default, 
>> at least), you still need a way to handle source that contains them.  I 
>> would suggest something like:
>> 
>>      #pragma STDC TRIGRAPH (ON|OFF)
>> 
>> The default would be "OFF".  Any source file that used trigraphs would 
>> simply put:
>> 
>>      #pragma STDC TRIGRAPH ON
>
> A platform where trigraphs are actually needed (rare as those might be
> nowadays) is likely to be one where "#" is not an available character.
> That should be
>
> 	??=pragma STDC TRIGRAPH ON

But that would only work if trigraphs were already on!

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web