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

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

C++ forcing unnecessary changes to C?

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

Contents

  C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 20:34 +0800
    Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-18 05:09 -0800
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 21:42 +0800
        Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:14 -0800
      Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:10 -0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-19 15:26 +0100
          Re: C++ forcing unnecessary changes to C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-19 10:09 -0500
            Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-20 13:47 +0100
        Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-21 03:25 -0800
          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-21 14:15 +0100
            Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-21 05:39 -0800
    Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 14:26 +0100
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 21:41 +0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 15:20 +0100
          Re: conduct in comp.lang.c "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:23 +0800
    Re: C++ forcing unnecessary changes to C? Philipp Klaus Krause <pkk@spth.de> - 2016-11-18 15:16 +0100
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:20 +0800
        Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:18 -0800
      Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-18 07:15 -0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 16:55 +0100
          Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-18 08:31 -0800
            Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:38 +0100
    Re: C++ forcing unnecessary changes to C? John Bode <jfbode1029@gmail.com> - 2016-11-18 07:09 -0800
      Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-18 07:22 -0800
        Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-18 07:31 -0800
          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:04 +0100
    Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 16:37 +0100
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 23:53 +0800
      Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-18 08:00 -0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:34 +0100
        Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-18 09:32 -0800
      Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:09 +0100
        Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 18:02 +0100
          Re: C++ forcing unnecessary changes to C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-21 03:26 -0600
            Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 11:11 +0100
              Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-22 08:55 -0800
              Re: C++ forcing unnecessary changes to C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-25 03:25 -0600
                Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-25 10:00 -0800
                Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-25 12:30 -0800
                  Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 00:38 +0100
                    Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-26 10:44 -0800
                      Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 20:44 +0100
                        Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-26 12:38 -0800
                      Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 21:00 +0100
    Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:04 -0800
      Re: [OT] discipline and obedience "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-19 22:53 +0800
      Re: C & C++ Committee "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-19 22:55 +0800
        Re: C & C++ Committee jameskuyper@verizon.net - 2016-11-19 08:02 -0800
          Re: C & C++ Committee "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-20 00:09 +0800
            Re: C & C++ Committee jameskuyper@verizon.net - 2016-11-19 08:35 -0800
              Re: C & C++ Committee fir <profesor.fir@gmail.com> - 2016-11-19 08:51 -0800
                Re: Do you write C programs? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-20 01:00 +0800
              Re: C & C++ Committee "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-20 00:59 +0800
    Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 11:14 +0100
      Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-22 12:05 +0100
        Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 14:51 +0100
          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-22 15:50 +0100
            Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 15:01 +0000
              Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-22 08:58 -0800
                Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 18:08 +0100
                Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 18:14 +0000
                  Re: C++ forcing unnecessary changes to C? Ian Collins <ian-news@hotmail.com> - 2016-11-23 08:33 +1300
                    Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 19:42 +0000
                      Re: C++ forcing unnecessary changes to C? Ian Collins <ian-news@hotmail.com> - 2016-11-23 08:51 +1300
                      Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-22 12:13 -0800
                        Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 21:35 +0000
                          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-23 00:47 +0100
                    Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-22 12:09 -0800
                  Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-23 00:40 +0100
                    Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 01:27 +0100
                      Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-26 01:48 +0100
                Re: C++ forcing unnecessary changes to C? Nathan Wagner <nw@hydaspes.if.org> - 2016-11-24 18:09 +0000

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

#97294

On 22/11/2016 16:58, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 22/11/2016 14:50, David Brown wrote:
>>> On 22/11/16 14:51, jacobnavia wrote:
>>>> Le 22/11/2016 à 12:05, David Brown a écrit :
>>>>> So gcc certainly does not generate exception tables for C compilation.
>>>>
>>>> This is FALSE. See the thread I started "Negative effects of c++ in C".
>>>> For your convenience here is a msg:
>>>>
>>>> No, I am talking about gcc. For instance I have a program called "asm",
>>>> an assembler, featuring
>>>>
>>>> jacob@linux-mint ~/lcc/asm/asm4 $ ls -l asm
>>
>> (Thanks. I've been wondering how to get 'ls' to give me a file size in
>> bytes!)
>
> `man ls`?  `ls --help`?

(That doesn't help as it doesn't say anywhere how to display the byte 
size of a file. The closest is block size. You just have to /know/ that 
what you get with -l includes the byte size.)

> g>>> ALL the sources are in straight C and I have to pay 103,506 c++ taxes!
>>>>
>>>> For NOTHING since C has no throws!
>>>
>>> A little research shows that this is a /requirement/ of the x86-64 ABI.
>>
>> That sounds unlikely. After all Jacob produces his own compiler for
>> x64-ABI; you'd think he would know if that was the case!
>
> The ABI document is http://www.x86-64.org/documentation/abi.pdf .
> (The web site seems to be down at the moment.)  Sections 3.3.1,
> Exception Interface, and 6.3, Unwinding Through Assembler Code,
> seem relevant.  I haven't read it closely enough to know just what
> it requires.  Perhaps David can provide more details.

I generate bare code for x64 myself, and I've never had to bother with 
this stuff. However, I generally use gcc's 'ld' linker, and maybe that 
adds something. But I've just remembered I can also use an independent 
linker, which can generate small executables, so I doubt it's including 
anything unnecessary.

However the executables I get even compiling C with gcc don't appear to 
have the 100KB overhead that Jacob is suggesting.

It seems unlikely then that it is /requirement/ of x64 ABI.

-- 
bartc

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

#97298

On 11/23/16 07:14 AM, BartC wrote:
> On 22/11/2016 16:58, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>>
>>> (Thanks. I've been wondering how to get 'ls' to give me a file size in
>>> bytes!)
>>
>> `man ls`?  `ls --help`?
>
> (That doesn't help as it doesn't say anywhere how to display the byte
> size of a file. The closest is block size. You just have to /know/ that
> what you get with -l includes the byte size.)

"-l

          Lists in  long  format,  giving  mode,  ACL  indication,
          number  of  links, owner, group, size in bytes, "

-- 
Ian

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

#97300

On 22/11/2016 19:33, Ian Collins wrote:
> On 11/23/16 07:14 AM, BartC wrote:
>> On 22/11/2016 16:58, Keith Thompson wrote:
>>> BartC <bc@freeuk.com> writes:
>>>>
>>>> (Thanks. I've been wondering how to get 'ls' to give me a file size in
>>>> bytes!)
>>>
>>> `man ls`?  `ls --help`?
>>
>> (That doesn't help as it doesn't say anywhere how to display the byte
>> size of a file. The closest is block size. You just have to /know/ that
>> what you get with -l includes the byte size.)
>
> "-l
>
>          Lists in  long  format,  giving  mode,  ACL  indication,
>          number  of  links, owner, group, size in bytes, "

You must have the Extended Version. I just get (on Ubuntu):

       -l     use a long listing format

(While you're here how do you do the equivalent of:

    dir pattern/s

? Where pattern is a filename including wildcards and /s means recurse 
through sub-directories, printing all matches. ls -R pattern doesn't work.)

-- 
Bartc

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

#97302

On 11/23/16 08:42 AM, BartC wrote:
> On 22/11/2016 19:33, Ian Collins wrote:
>> On 11/23/16 07:14 AM, BartC wrote:
>>> On 22/11/2016 16:58, Keith Thompson wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>>>
>>>>> (Thanks. I've been wondering how to get 'ls' to give me a file size in
>>>>> bytes!)
>>>>
>>>> `man ls`?  `ls --help`?
>>>
>>> (That doesn't help as it doesn't say anywhere how to display the byte
>>> size of a file. The closest is block size. You just have to /know/ that
>>> what you get with -l includes the byte size.)
>>
>> "-l
>>
>>           Lists in  long  format,  giving  mode,  ACL  indication,
>>           number  of  links, owner, group, size in bytes, "
>
> You must have the Extended Version. I just get (on Ubuntu):
>
>         -l     use a long listing format
>
> (While you're here how do you do the equivalent of:
>
>      dir pattern/s
>
> ? Where pattern is a filename including wildcards and /s means recurse
> through sub-directories, printing all matches. ls -R pattern doesn't work.)

find . -name pattern

-- 
Ian

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

#97305

BartC <bc@freeuk.com> writes:
[...]
> (While you're here how do you do the equivalent of:
>
>     dir pattern/s
>
> ? Where pattern is a filename including wildcards and /s means recurse 
> through sub-directories, printing all matches. ls -R pattern doesn't work.)

Like most Unix commands, ls does not handle wildcard patterns itself, so
it can't do this particular thing.

The "find" command should do what you want, something like

    find . -name "pattern"

Append "-ls" if you want a long listing rather than just a list of file
names.  "info find" for the full documentation.  If that doesn't answer
your question, I suggest finding a forum other than this one, perhaps
comp.unix.questions.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#97313

On 22/11/2016 20:13, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> [...]
>> (While you're here how do you do the equivalent of:
>>
>>     dir pattern/s
>>
>> ? Where pattern is a filename including wildcards and /s means recurse
>> through sub-directories, printing all matches. ls -R pattern doesn't work.)
>
> Like most Unix commands, ls does not handle wildcard patterns itself, so
> it can't do this particular thing.
>
> The "find" command should do what you want, something like
>
>     find . -name "pattern"
>
> Append "-ls" if you want a long listing rather than just a list of file
> names.  "info find" for the full documentation.  If that doesn't answer
> your question, I suggest finding a forum other than this one, perhaps
> comp.unix.questions.

(That sort of works (except it searches all subdirectories include a 
mysterious ./.local/... which seems to have links everywhere).

The man page for 'find' has 1500 lines and is utterly incomprehensible.

I was thinking of knocking up a C program to do the equivalent of 
walking subdirectories checking file name patterns, but I suspect that's 
how Linux ended with so many assorted utilities! Each starting simple 
then turning into monsters.)

-- 
bartc

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

#97321

On 22/11/16 22:35, BartC wrote:
> On 22/11/2016 20:13, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> (While you're here how do you do the equivalent of:
>>>
>>>     dir pattern/s
>>>
>>> ? Where pattern is a filename including wildcards and /s means recurse
>>> through sub-directories, printing all matches. ls -R pattern doesn't
>>> work.)
>>
>> Like most Unix commands, ls does not handle wildcard patterns itself, so
>> it can't do this particular thing.
>>
>> The "find" command should do what you want, something like
>>
>>     find . -name "pattern"
>>
>> Append "-ls" if you want a long listing rather than just a list of file
>> names.  "info find" for the full documentation.  If that doesn't answer
>> your question, I suggest finding a forum other than this one, perhaps
>> comp.unix.questions.
>
> (That sort of works (except it searches all subdirectories include a
> mysterious ./.local/... which seems to have links everywhere).
>
> The man page for 'find' has 1500 lines and is utterly incomprehensible.
>
> I was thinking of knocking up a C program to do the equivalent of
> walking subdirectories checking file name patterns, but I suspect that's
> how Linux ended with so many assorted utilities! Each starting simple
> then turning into monsters.)
>

<http://lmgtfy.com/?q=what+is+the+linux+equivalent+of+dir+%2Fs>

To be a little less sarcastic, "find" is a powerful, flexible and 
complicated command.  The man page is not "utterly incomprehensible", 
but it is hard to follow.  It is /far/ easier to do a bit of googling, 
and you'll find lots of examples for different purposes.  I know this, 
because I have done so many times when doing more advanced "find" commands.

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

#97304

Ian Collins <ian-news@hotmail.com> writes:
> On 11/23/16 07:14 AM, BartC wrote:
>> On 22/11/2016 16:58, Keith Thompson wrote:
>>> BartC <bc@freeuk.com> writes:
>>>>
>>>> (Thanks. I've been wondering how to get 'ls' to give me a file size in
>>>> bytes!)
>>>
>>> `man ls`?  `ls --help`?
>>
>> (That doesn't help as it doesn't say anywhere how to display the byte
>> size of a file. The closest is block size. You just have to /know/ that
>> what you get with -l includes the byte size.)
>
> "-l
>
>           Lists in  long  format,  giving  mode,  ACL  indication,
>           number  of  links, owner, group, size in bytes, "

To be fair, neither "man ls" nor "ls --help" shows that information
(at least for the GNU Coreutils version of the "ls" command).
The full documentation is in the "info" document; the man page
contains only a subset of that information, but there's a reference
to the info manual *and* a web page at the bottom of the man page.

Try "info ls" if the coreutils documentation is installed.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#97320

On 22/11/16 19:14, BartC wrote:
> On 22/11/2016 16:58, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 22/11/2016 14:50, David Brown wrote:
>>>> On 22/11/16 14:51, jacobnavia wrote:
>>>>> Le 22/11/2016 à 12:05, David Brown a écrit :
>>>>>> So gcc certainly does not generate exception tables for C
>>>>>> compilation.
>>>>>
>>>>> This is FALSE. See the thread I started "Negative effects of c++ in
>>>>> C".
>>>>> For your convenience here is a msg:
>>>>>
>>>>> No, I am talking about gcc. For instance I have a program called
>>>>> "asm",
>>>>> an assembler, featuring
>>>>>
>>>>> jacob@linux-mint ~/lcc/asm/asm4 $ ls -l asm
>>>
>>> (Thanks. I've been wondering how to get 'ls' to give me a file size in
>>> bytes!)
>>
>> `man ls`?  `ls --help`?
>
> (That doesn't help as it doesn't say anywhere how to display the byte
> size of a file. The closest is block size. You just have to /know/ that
> what you get with -l includes the byte size.)

Google is your friend.  Google knows everything.  All you have to do is ask.

(Seriously, it should have taken no more than a half minute or so to 
find this out.)

>
>> g>>> ALL the sources are in straight C and I have to pay 103,506 c++
>> taxes!
>>>>>
>>>>> For NOTHING since C has no throws!
>>>>
>>>> A little research shows that this is a /requirement/ of the x86-64 ABI.
>>>
>>> That sounds unlikely. After all Jacob produces his own compiler for
>>> x64-ABI; you'd think he would know if that was the case!
>>
>> The ABI document is http://www.x86-64.org/documentation/abi.pdf .
>> (The web site seems to be down at the moment.)  Sections 3.3.1,
>> Exception Interface, and 6.3, Unwinding Through Assembler Code,
>> seem relevant.  I haven't read it closely enough to know just what
>> it requires.  Perhaps David can provide more details.
>
> I generate bare code for x64 myself, and I've never had to bother with
> this stuff. However, I generally use gcc's 'ld' linker, and maybe that
> adds something. But I've just remembered I can also use an independent
> linker, which can generate small executables, so I doubt it's including
> anything unnecessary.
>
> However the executables I get even compiling C with gcc don't appear to
> have the 100KB overhead that Jacob is suggesting.
>
> It seems unlikely then that it is /requirement/ of x64 ABI.
>

I haven't read the ABI document (I did once read a little of it, but not 
in this context), and as Keith says the site is down at the moment.

I found out about eh_frames by asking google "why does gcc generate 
eh_frames for C?".  The question has been asked a number of times, and 
the answer is always the same - the ABI for x86-64 requires these 
sections, but gcc can remove almost all of the contents with the 
-fno-asynchronous-unwind-tables and -fno-unwind-tables.  (Those flags 
are not well documented in the manual - but since these unwind tables 
are normally created if and only if the language or the target ABI 
require them, they are not commonly used flags.)

For example: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43232>

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

#97502

Le 23/11/2016 à 00:40, David Brown a écrit :
> the ABI for x86-64 requires these sections

Who wrote the ABI?

The gcc folks.

:-)

Why bother with C? Everyone says the same mantra, and c++ goes on 
growing and growing.

I should do like everyone else, everyone else tells me but I still do 
not want to acccept "reality" and start complexifying my programs until 
I can't read them.

A big part of this "progress" was done by the gcc team. Growth without 
bounds, leaving Algog-68 WAY back, leaving common lisp WAY back 
achieving levels of complexity so enourmous, that some c++ code needs a 
compiler.

Only a machine can understand that in all its consequences.

I have seen fads come and go. Each one, left a strata of features in 
c++. C, remained the same. That is an advantage and a bug at the same time.

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

#97507

On 26/11/16 01:27, jacobnavia wrote:
> Le 23/11/2016 à 00:40, David Brown a écrit :
>> the ABI for x86-64 requires these sections
>
> Who wrote the ABI?
>
> The gcc folks.
>
> :-)
>

No, I believe the ABI was written by AMD.  They certainly consulted the 
gcc folks, as well as a number of different *nix folks (not just Linux), 
and many others.  It is the ABI used by all x86-64 OS's except Windows.

I doubt if the gcc folks particularly wanted the eh_frame stuff in code 
in C.  But someone decided it was good for interoperability between 
different languages, or good for debugging and tracing, or things like that.

> Why bother with C? Everyone says the same mantra, and c++ goes on
> growing and growing.
>

The gcc folks are very fond of C, even though they have moved to C++ for 
the compiler.  gcc is most at home on *nix, and *nix is most at home 
with C.  And I think few groups anywhere have done more work aimed at 
improving, enhancing and extending C than gcc - a number of their 
enhancements and extensions have ended up in the standards.  (I know you 
work hard at trying to move C forward - unfortunately, you and your 
toolchain are too small to have a serious influence beyond your own users.)

> I should do like everyone else, everyone else tells me but I still do
> not want to acccept "reality" and start complexifying my programs until
> I can't read them.

/I/ don't think you should do like everyone else - I think you should do 
as you feel best.  For my own use, if I want something more than C, with 
features such as operator overloading and a containers library, I will 
go to C++.  Your compiler is never going to be an option for me anyway - 
it is Windows hosted and targeted, and I need to target small embedded 
systems (with cross-platform hosting on Windows and Linux).  But if you 
want to make a tool for an enhanced version of C, and your users want 
that, then that's great - well done.

However, you should not be dismayed that the uptake and enthusiasm for 
your changes is weak amongst most developers and compiler writers.

>
> A big part of this "progress" was done by the gcc team. Growth without
> bounds, leaving Algog-68 WAY back, leaving common lisp WAY back
> achieving levels of complexity so enourmous, that some c++ code needs a
> compiler.
>
> Only a machine can understand that in all its consequences.
>
> I have seen fads come and go. Each one, left a strata of features in
> c++. C, remained the same. That is an advantage and a bug at the same time.

Certainly the stability of C as a language is one of its most important 
assets.  And the progress and improvements in C++ is one of /its/ most 
important assets - I have no doubt that C++11 and C++14 are huge 
advances over C++98 and C++03, and are very much better languages.  C++ 
is big and complicated, C is smaller but with no shortage of subtleties. 
  They are different tools for different purposes, and you should not 
condemn C++ for being an overly complicated superset of C nor C for 
being a severely limited subset of C++.

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

#97538

On 2016-11-22, Keith Thompson <kst-u@mib.org> wrote:

> `man ls`?  `ls --help`?

Perhaps backticks aren't the best choice of quote marks for this
particular case.

-- 
nw

[toc] | [prev] | [standalone]

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

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

csiph-web