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

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

C Construction Problem

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

Contents

  C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 13:51 +0000
    Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-20 14:42 +0000
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 15:06 +0000
        Re: C Construction Problem Manfred <noname@invalid.add> - 2018-02-20 18:07 +0100
    Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 14:54 +0000
    Re: C Construction Problem "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-20 10:06 -0500
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 16:11 +0000
    Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-20 15:08 +0000
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 16:22 +0000
        Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-20 17:03 +0000
          Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-20 09:23 -0800
          Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-20 11:11 -0700
          Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 18:30 +0000
            Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 23:37 +0000
              Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-21 00:45 +0000
                Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-21 01:46 +0000
                  Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-21 08:49 +0100
                    Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 09:29 +0000
                      [OT] Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-21 11:24 +0000
                        Re: [OT] Re: C Construction Problem Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-21 14:41 +0300
                        Re: [OT] Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-21 15:10 +0100
                        Re: [OT] Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 12:36 -0600
                          Re: [OT] Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-21 21:04 +0000
                            Re: [OT] Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:20 -0600
                  Re: C Construction Problem Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-21 11:09 +0300
                  Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-21 02:29 -0800
                  Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-21 11:32 +0000
                  Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-26 11:02 -0800
                    Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-27 09:22 +0100
                      Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-27 11:18 -0800
                        Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-27 19:51 +0000
                          Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-28 01:54 -0600
                        Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-28 01:43 -0600
                          Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-28 12:54 -0800
                    Re: archive decompressor Noob <root@127.0.0.1> - 2018-03-04 12:34 +0100
                Re: C Construction Problem Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-21 11:04 +0300
                  Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-21 11:27 +0000
                    Re: C Construction Problem Anton Shepelev <anton.txt@gmail.com> - 2018-02-28 22:59 +0300
                  Re: C Construction Problem supercat@casperkitty.com - 2018-02-21 08:49 -0800
              Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-26 11:08 -0800
                Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-26 23:51 +0000
                  Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-27 11:24 -0800
            Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 08:07 -0800
              Re: C Construction Problem fr314159@gmail.com - 2018-02-21 09:16 -0800
                Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 21:26 -0800
              Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-21 09:43 -0800
                Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 22:47 -0800
                  Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-22 13:09 +0000
                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-24 13:37 -0800
                  Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-22 10:50 -0800
                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-24 13:58 -0800
                      Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-24 15:05 -0800
                        Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-25 03:21 -0800
                          Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 11:51 +0000
                            Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-25 04:06 -0800
                              Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 12:47 +0000
                              Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-25 13:20 +0000
                                Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 17:46 +0000
                                  Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-25 18:58 +0000
                                    Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 20:01 +0000
                                      Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 20:25 +0000
                                  Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-26 02:49 -0800
                              Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-25 20:02 +0000
                              Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-25 15:13 -0800
                          Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-25 11:50 -0600
                          Re: C Construction Problem Ian Collins <ian-news@hotmail.com> - 2018-02-26 07:38 +1300
                            Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-25 15:15 -0800
                            Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 22:02 -0800
                              Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 06:32 -0800
                                Re: C Construction Problem GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-27 16:56 +0100
                                  Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 08:27 -0800
                                    Re: C Construction Problem GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-27 18:02 +0100
                                      Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 10:23 -0800
                                        Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 01:09 -0800
                                      Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-28 10:37 +0100
                                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 01:29 -0800
                                      Re: C Construction Problem Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 02:00 -0800
                                Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-27 08:46 -0800
                                  Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 09:15 -0800
                                Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 02:08 -0800
                                  Re: C Construction Problem Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 02:31 -0800
                                  Re: C Construction Problem Ian Collins <ian-news@hotmail.com> - 2018-03-04 10:34 +1300
                                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-19 10:27 -0700
                                  Re: C Construction Problem jameskuyper@verizon.net - 2018-03-03 21:35 -0800
                                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 10:29 -0700
                                      Re: C Construction Problem Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 08:14 -0700
                          Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-25 21:49 +0100
                          Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-25 15:09 -0800
                          Re: C Construction Problem gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 13:46 +0000
                            Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-26 14:57 +0100
                        Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 22:14 -0800
              Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-22 00:11 +0000
                Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-21 17:27 -0700
      Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-20 09:30 -0800
        Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-21 00:23 +0000
    Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-20 09:11 -0700
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 16:38 +0000
        Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-20 17:07 +0000
        Re: C Construction Problem John Bode <jfbode1029@gmail.com> - 2018-02-20 09:09 -0800
        Re: C Construction Problem "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-20 12:18 -0500
          Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-20 09:38 -0800
        Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-20 11:08 -0700
        Re: C Construction Problem Gordon Burditt <gordon@hammy.burditt.org> - 2018-02-20 21:47 -0600
          Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-21 09:36 -0800
            Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-26 11:21 -0800

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

#127047

On 25/02/2018 20:01, bartc wrote:

> (As coded, it should deal with arrays up to 8 billion elements/2 billion 
> bytes, unless you put size_t everywhere.

2 billion elements/0.5 billion bytes. Capacity is 2 billion bytes, but 
you need 34 bits signed to represent length or index.

So best done with 64 bits for those values.

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

#127071

On Sunday, February 25, 2018 at 5:46:09 PM UTC, Bart wrote:
> On 25/02/2018 13:20, F. Russell wrote:
> > On Sun, 25 Feb 2018 04:06:31 -0800, Malcolm McLean wrote:
> > 
> >> As a bioinformatician, I use some very long
> >> strings to represent DNA sequences.
> >>
> > 
> > Why would you use STRINGS and not BIT FIELDS?
> 
> Because the language supports strings (as byte arrays) but not bit 
> fields? At least not in a form that is useful for this purpose.
> 
Whilst you've only got four DNA bases, you also have RNA sequences
which use uracil instead of thymine, so if you use only two bits you
need to tag as either RNA or DNA (the probability of a sequence of
any length containing no U/T is essentially zero, there aren't
thymine deserts in any known natural sequences).

Then you need a way to represent end of sequence, which in a C
string is to add a null, with two bits you need a length field.

Then sometimes you have unknown or ambiguous bases. Not chemically
ambiguous, but bases you can't sequence properly or which have
point mutations. There are standard letters for the possibilities,
so X represents an unknown base, R means C or T, and so on.

So there are lots of reasons for using strings instead of bitfields
to represent nucleotide sequences.

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

#127043

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Sunday, February 25, 2018 at 11:51:15 AM UTC, Bart wrote:
<text removed>
>> The docs for VS2015 say individual strings can be 2K, but can be 
>> concatenated up to 64K. My longest single string was 35K.
<text removed>

> You'd think they'd use a 32 bit integer to hold the string length,
> in this day and age. (As a bioinformatician, I use some very long
> strings to represent DNA sequences).

Despite the wording it is very unlikely that the problem is the length
of strings.  It is probably the length of string literals in C source
code that appears to be the problem.  BartC's use of C is not the usual
one.  Your code probably does not have long sequences as string literals
in the C source.

> The standard library is already deprecated. It transpires that it
> is now listed for total removal. I'm not quite sure what the plan
> is for the C compiler, but basically it is going.

Do you have a citation for this?  Whilst nothing MS does should really
surprise me anymore, I find this plan baffling.  For one thing, it would
prevent MS from claiming to have a conforming C++ implementation, but
maybe that too is of little interest to them these days.

> Which is depressing. It makes all my work porting Baby X to Windows
> worthless.

Unless MS is abandoning C++ too, a C++ port would probably not be hard.
You would not need to make it a "proper" C++ API, just one that compiles
and links with C++.

-- 
Ben.

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

#127052

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> The standard library is already deprecated. It transpires that it
> is now listed for total removal. I'm not quite sure what the plan
> is for the C compiler, but basically it is going.

That is an extraordinary claim.  It would mean that Microsoft could no
longer claim to have a conforming C *or* C++ compiler.  Do you have a
citation, preferably a statement from Microsoft?

If you're basing that on your earlier statement about removing support
for C89, it doesn't follow; the C99 version of the standard library
includes essentially all of the C89 standard library.

-- 
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]

#127039

On Sun, 25 Feb 2018 03:21:28 -0800 (PST), Malcolm McLean
<malcolm.arthur.mclean@gmail.com> wrote:

>On Saturday, February 24, 2018 at 11:06:12 PM UTC, Keith Thompson wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> > Keith Thompson <kst-u@mib.org> writes:
>> [...]
>> >> My own preference is to use the current standard unless there's a good
>> >> reason not to.  [...]
>> >
>> > Do you have some reasoning to offer that might explain this bias?
>> > Or do you think of it as just axiomatic?
>> 
>> Any attempt to explain my preference would likely lead to a debate that
>> I'm not interested in having.
>> 
>The main reason for sticking to C89 is that Microsoft doesn't support
>the more recent standards. But now C89 support in Visual Studio is
>going to be removed too.


Just curious, where have you heard that?

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

#127040

On 02/26/2018 12:21 AM, Malcolm McLean wrote:
> On Saturday, February 24, 2018 at 11:06:12 PM UTC, Keith Thompson wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>> [...]
>>>> My own preference is to use the current standard unless there's a good
>>>> reason not to.  [...]
>>>
>>> Do you have some reasoning to offer that might explain this bias?
>>> Or do you think of it as just axiomatic?
>>
>> Any attempt to explain my preference would likely lead to a debate that
>> I'm not interested in having.
>>
> The main reason for sticking to C89 is that Microsoft doesn't support
> the more recent standards. But now C89 support in Visual Studio is
> going to be removed too.

That sound like nonsense on both counts.  Due to C++11 using C99 rather 
than C89 as its base, C99 support in visual studio has improved.  My 
last hour on Friday afternoon was spent replacing our old platform 
specific size_t format specifier macros with %zu...

-- 
Ian.

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

#127053

Ian Collins <ian-news@hotmail.com> writes:
> On 02/26/2018 12:21 AM, Malcolm McLean wrote:
[...]
>> The main reason for sticking to C89 is that Microsoft doesn't support
>> the more recent standards. But now C89 support in Visual Studio is
>> going to be removed too.
>
> That sound like nonsense on both counts.  Due to C++11 using C99 rather 
> than C89 as its base, C99 support in visual studio has improved.  My 
> last hour on Friday afternoon was spent replacing our old platform 
> specific size_t format specifier macros with %zu...

Yes, but it's not clear what that means for support for the C89 core
language.

-- 
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]

#127113

Ian Collins <ian-news@hotmail.com> writes:

> Due to C++11 using C99 rather than C89 as its base, [...]

In C++11 and later, C++ uses the C99 library as its base
library.  It does not use the C99 language as its base
language.

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

#127130

On Tuesday, February 27, 2018 at 1:02:54 AM UTC-5, Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> 
> > Due to C++11 using C99 rather than C89 as its base, [...]
> 
> In C++11 and later, C++ uses the C99 library as its base
> library.  It does not use the C99 language as its base
> language.

"C ++ is a general purpose programming language based on the C
programming language as described in ISO/IEC 9899:2011 Programming
languages — C (hereinafter referred to as the C standard). In addition
to the facilities provided by C, C ++ provides ..." (n4659.pdf 1p2). 

n3690.pdf refers to 9899:1999 instead of 9899:2011.

Are you making a distinction between saying "C++ is ... based on ...
ISO/IEC 9899:1999", and "C99 is the base language for C++"? If so, could
you explain that distinction?

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

#127132

On Tue, 27 Feb 2018 06:32:44 -0800 (PST)
jameskuyper@verizon.net wrote:

> Are you making a distinction between saying "C++ is ... based on ...
> ISO/IEC 9899:1999", and "C99 is the base language for C++"? If so,
> could you explain that distinction?

For me the expression "C ++ is based on C99" refers to the fact C++
collects some elements of C but is not built on top of C, whence some
incompatibilities. Thus, C99 can't be the base language for C++.

-- 
GOTHIER Nathan

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

#127133

On Tuesday, February 27, 2018 at 10:59:23 AM UTC-5, GOTHIER Nathan wrote:
> On Tue, 27 Feb 2018 06:32:44 -0800 (PST)
> jameskuyper@verizon.net wrote:
> 
> > Are you making a distinction between saying "C++ is ... based on ...
> > ISO/IEC 9899:1999", and "C99 is the base language for C++"? If so,
> > could you explain that distinction?
> 
> For me the expression "C ++ is based on C99" refers to the fact C++
> collects some elements of C but is not built on top of C, whence some
> incompatibilities. Thus, C99 can't be the base language for C++.

OK, that's not how I would interpret those phrase, but if that's the distinction you see between them, then I must disagree with your
conclusion.

C++ 2011 contains virtually every feature of C99; there's a few features missing, but as a percentage of the whole, there's not many. Note: when
I refer to "features of C99", I'm referring to ALL of it's features,
including the ones that go back to C89 and earlier, such as the use of
"+" for addition. I'm not referring merely the features that were new in
C99, such as "restrict" (however, the latest versions of C++ also
incorporate many of the features that were new in C99).

Therefore, describing C99 as "the base language for C++11" would be more accurate than merely saying that "C++11 is based upon C99", because the latter phrase would imply a looser connection between the languages than
actually exists (interpreting the distinction between those phrase in
the manner you describe).

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

#127137

On Tue, 27 Feb 2018 08:27:45 -0800 (PST)
jameskuyper@verizon.net wrote:
 
> Therefore, describing C99 as "the base language for C++11" would be
> more accurate than merely saying that "C++11 is based upon C99",
> because the latter phrase would imply a looser connection between the
> languages than actually exists (interpreting the distinction between
> those phrase in the manner you describe).

Since you can't compile a C program with a C++ compiler without extra
code, consequently C can't be the base language for C++.

I believe you're a C++ promoter unwilling to see the hard reality that C
and C++ are two different languages. I'm afraid you have to live with
this fact!

-- 
GOTHIER Nathan

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

#127141

On Tuesday, February 27, 2018 at 12:04:22 PM UTC-5, GOTHIER Nathan wrote:
> On Tue, 27 Feb 2018 08:27:45 -0800 (PST)
> jameskuyper@verizon.net wrote:
>  
> > Therefore, describing C99 as "the base language for C++11" would be
> > more accurate than merely saying that "C++11 is based upon C99",
> > because the latter phrase would imply a looser connection between the
> > languages than actually exists (interpreting the distinction between
> > those phrase in the manner you describe).
> 
> Since you can't compile a C program with a C++ compiler without extra
> code, consequently C can't be the base language for C++.

I just compiled a program consisting of 92 files totaling 48561
lines and 1452382 bytes of C code. It contains not a single line that
checks whether __cplusplus is #defined. It links to several third-party
library whose headers do check that macro, but nothing in my own code
relies upon those checks in order to compile properly as C++ code. One
of those libraries has a header file that improperly provides it's own
declaration for errno, but that's equally improper in C - it matches our
implementation's own C declaration for errno, but doesn't work with C++.
When I created my own version of that header which removed that
declaration, the program compiled as C++ code with only a few warnings
about the deprecated conversion from string constants to char*, and
executes without any errors.

I won't claim that this is typical. The biggest obstacle to C=>C++
conversions are usually C's implicit conversions from void* to T*. I'm
required by rules imposed by our client to never rely on implicit
conversions (which I consider to be a horribly misguided rule), which
avoided that problem entirely. But you claimed that it was impossible.
Adding explicit casts to code not originally written that way isn't
particularly onerous. The fact that you need to add them is not
sufficient justification for rejecting the claim that C is the base
language for C++.

> I believe you're a C++ promoter unwilling to see the hard reality that C
> and C++ are two different languages.

I'm quite well aware of the fact that they are two very different
languages; but the quite large difference between those two languages
consists almost entirely of features that C++ added to C; only a small
fraction of the features of C89 were dropped, and only a small number of
features have since been added to C that weren't also added to C++,
sooner or later. And a small number of the features that were added to
create C++ have since been added to C as well.

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

#127302

jameskuyper@verizon.net writes:

>> [can C programs be compiled as C++?]
>
> I just compiled a program consisting of 92 files totaling 48561
> lines and 1452382 bytes of C code.  It contains not a single line
> that checks whether __cplusplus is #defined.  It links to several
> third-party library whose headers do check that macro, but nothing
> in my own code relies upon those checks in order to compile
> properly as C++ code.  [After a minor fixup of an incidental
> problem] the program compiled as C++ code with only a few warnings
> about the deprecated conversion from string constants to char*,
> and executes without any errors.  [...]

If I remember right you work in an environment that mandates C90
conformance (maybe only for some projects?).  Is this program one
that was written under such a mandate, or possibly written by
someone whose coding style has been influenced by working under
that constraint?  I think it's generally pretty easy to get C90
code to compile as C++.  It's much harder to get C99 code to
compile as C++ - basically, the code has to mostly be turned back
into C90 code.

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

#127157

On 27/02/18 18:02, GOTHIER Nathan wrote:
> On Tue, 27 Feb 2018 08:27:45 -0800 (PST)
> jameskuyper@verizon.net wrote:
>  
>> Therefore, describing C99 as "the base language for C++11" would be
>> more accurate than merely saying that "C++11 is based upon C99",
>> because the latter phrase would imply a looser connection between the
>> languages than actually exists (interpreting the distinction between
>> those phrase in the manner you describe).
> 
> Since you can't compile a C program with a C++ compiler without extra
> code, consequently C can't be the base language for C++.

Of course you can.  There are a few features of C (of various standards)
that are not supported by C++ (of various standards), a few cases of
conflict (like new keywords in C++ used as identifiers in C code), and a
very few cases of valid code having different behaviour (like using
sizeof('a') ).  It is not at all hard to avoid these points.  My C code
can usually be compiled flawlessly as C++, and many Windows C
programmers use MSVC in C++ mode to compile their C code.

(The infamous casting of void* issue is rarely relevant in my code, as I
rarely have any void* pointers.)


If you make use of C++ incompatible features, like designated
initialisers, then you will have to change the C code to make it C++
compatible.  And if you use certain obsoleted features from C, like
implicit function declarations, then these will need to be added.

But it is all minor stuff.  C++ is an approximate superset of C, not a
strict superset - C++ is "based on C" rather than being a pure extension
of it.



> 
> I believe you're a C++ promoter unwilling to see the hard reality that C
> and C++ are two different languages. I'm afraid you have to live with
> this fact!
> 

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

#127305

jameskuyper@verizon.net writes:

> C++ 2011 contains virtually every feature of C99;  there's a few
> features missing, but as a percentage of the whole, there's not many.

If we look at just the newly added language (as opposed to library)
features, the fraction is much higher, and also more substantial
taking into account some sense of the magnitude of the different
features.  When considering the question of whether the C++ language
is more aptly described as based on the C99 language or the C90
language, I think it fair to say that the narrower metric is more
apropos.

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

#127308

On Saturday, March 3, 2018 at 2:29:28 AM UTC-7, Tim Rentsch wrote:
> jameskuyper@verizon.net writes:
> 
> > C++ 2011 contains virtually every feature of C99;  there's a few
> > features missing, but as a percentage of the whole, there's not many.
> 
> If we look at just the newly added language (as opposed to library)
> features, the fraction is much higher, and also more substantial
> taking into account some sense of the magnitude of the different
> features.  When considering the question of whether the C++ language
> is more aptly described as based on the C99 language or the C90
> language, I think it fair to say that the narrower metric is more
> apropos.



Vennie 'The Moron' Bowden is trying ("very" hard) to project their trolling crap onto The Doctor. For some time Vennie 'The Moron' Bowden has pressed the claim that The Doctor needs 'witnesses' to point out all his BS. The fact is that nobody needs any reason to do that. So Vennie 'The Moron' Bowden pulls this laughable trolling baloney in a weak attempt to 'push' the idea that The Doctor is like him. 

Once The Doctor appreciated how effective Vennie 'The Moron' Bowden is at portraying himself as the 'injured party' he has figured out this isn't nearly as bizarre as it sounded. 

A meaningless discourse by pseudo-experts, magnified by the reciprocal of an infinite twin prime, demonstrating the vast nothingness of the main character's so-called thought process. 

What is your evidence? How is GIMP on Linux doing anything above the lowest common denominator? Linus Torvalds is a false advocate's only reason for living. 

--
Live on Kickstarter
http://www.5z8.info/php-start_GPS_tracking-user_f8h9lv_-OPEN-WEBCAM---START-RECORD--
http://tinyurl.com/kmqe66h
https://youtu.be/r7wys2JvBD0
Jonas Eklundh Communication

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

#127134

jameskuyper@verizon.net writes:
> On Tuesday, February 27, 2018 at 1:02:54 AM UTC-5, Tim Rentsch wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>> 
>> > Due to C++11 using C99 rather than C89 as its base, [...]
>> 
>> In C++11 and later, C++ uses the C99 library as its base
>> library.  It does not use the C99 language as its base
>> language.
>
> "C ++ is a general purpose programming language based on the C
> programming language as described in ISO/IEC 9899:2011 Programming
> languages — C (hereinafter referred to as the C standard). In addition
> to the facilities provided by C, C ++ provides ..." (n4659.pdf 1p2). 
>
> n3690.pdf refers to 9899:1999 instead of 9899:2011.
>
> Are you making a distinction between saying "C++ is ... based on ...
> ISO/IEC 9899:1999", and "C99 is the base language for C++"? If so, could
> you explain that distinction?

The C++ core language (excluding the library) is obviously based on
the C core language, but the C++ standard doesn't define any core
language features by reference to the C standard.  For example,
the meaning of the sizeof operator is defined separately by the
C++ standard.

On the other hand, the C++ standard library includes the C standard
library (with some tweaks).  The semantics of strcpy, for example,
are defined by the C++ standard only via reference to the C standard.

-- 
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]

#127139

On Tuesday, February 27, 2018 at 11:47:01 AM UTC-5, Keith Thompson wrote:
> jameskuyper@verizon.net writes:
> > On Tuesday, February 27, 2018 at 1:02:54 AM UTC-5, Tim Rentsch wrote:
> >> Ian Collins <ian-news@hotmail.com> writes:
> >> 
> >> > Due to C++11 using C99 rather than C89 as its base, [...]
> >> 
> >> In C++11 and later, C++ uses the C99 library as its base
> >> library.  It does not use the C99 language as its base
> >> language.
> >
> > "C ++ is a general purpose programming language based on the C
> > programming language as described in ISO/IEC 9899:2011 Programming
> > languages — C (hereinafter referred to as the C standard). In addition
> > to the facilities provided by C, C ++ provides ..." (n4659.pdf 1p2). 
> >
> > n3690.pdf refers to 9899:1999 instead of 9899:2011.
> >
> > Are you making a distinction between saying "C++ is ... based on ...
> > ISO/IEC 9899:1999", and "C99 is the base language for C++"? If so, could
> > you explain that distinction?
> 
> The C++ core language (excluding the library) is obviously based on
> the C core language, but the C++ standard doesn't define any core
> language features by reference to the C standard.

That's not quite true:
123456789012345678901234567890123456789012345678901234567890123456789012
"The signed and unsigned integer types shall satisfy the constraints
given in the C standard, section 5.2.4.2.1." (3.9.1p3). Those
constraints apply directly to the values in <limits.h> and <stdint.h>,
which are part of the standard library, but the fact that the types
themselves must satisfy those constraints (whether or not those headers
are #included) is very definitely a core language feature.
But that's the only exception I could find.

...
> On the other hand, the C++ standard library includes the C standard
> library (with some tweaks).  The semantics of strcpy, for example,
> are defined by the C++ standard only via reference to the C standard.

OK, I can see that as a reasonable distinction.

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

#127309

jameskuyper@verizon.net writes:

> On Tuesday, February 27, 2018 at 1:02:54 AM UTC-5, Tim Rentsch wrote:
>
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> Due to C++11 using C99 rather than C89 as its base, [...]
>>
>> In C++11 and later, C++ uses the C99 library as its base
>> library.  It does not use the C99 language as its base
>> language.
>
> "C ++ is a general purpose programming language based on the C
> programming language as described in ISO/IEC 9899:2011 Programming
> languages ?  C (hereinafter referred to as the C standard).  In
> addition to the facilities provided by C, C ++ provides ..."
> (n4659.pdf 1p2).
>
> n3690.pdf refers to 9899:1999 instead of 9899:2011.
>
> Are you making a distinction between saying "C++ is ... based on
> ...  ISO/IEC 9899:1999", and "C99 is the base language for C++"?
> If so, could you explain that distinction?

C99 has variable length arrays.  C++ does not.

C99 has designated initializers.  C++ does not.

C99 has compound literals.  C++ does not.

C99 has inline functions.  C++ also has inline functions,
but with different semantics.

C11 has anonymous structs and unions.  C++ does not.

C11 has _Generic.  C++ does not.

There are other differences;  those are some of the more
obvious ones.

Somewhat recently I have done some work on an interface (in
particular, a .h file) that targets C++ as well as C.  Even in
just an interface file, writing C that is acceptable to C++ meant
pretty much writing C90 rather than C99.  I was surprised by
that, because the code in the .h file wasn't doing anything very
exotic.  Yet it had to be changed (written originally assuming
C99) to make it C++ compatible.

Finally, let me point out Annex C, "Compatibility", in n4659.
Paragraph 1 of C.1 says

    This subclause lists the differences between C++ and ISO C,
    by the chapters of this document.

Despite that introduction, AFAICT no language features new to C99
or C11 are among those compared.  In fact one of the items listed
is implicit declaration of functions, which hasn't been part of
standard C for almost 20 years.  Also inline functions are not
listed.  So the C++ standard itself tacitly concedes the point
that, as far as the language goes, C++ is based on C90 and not on
C99 or C11.

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

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

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

csiph-web