Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: faster than c |
| Date | 2015-04-22 17:20 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <mh96pr$d9d$1@dont-email.me> (permalink) |
| References | (16 earlier) <kfnzj66wsa1.fsf@x-alumni2.alumni.caltech.edu> <mgrvkt$av7$1@dont-email.me> <kfnh9scum0o.fsf@x-alumni2.alumni.caltech.edu> <mh3e9c$h1f$1@dont-email.me> <kfnoamgt5qp.fsf@x-alumni2.alumni.caltech.edu> |
On 4/22/2015 12:47 PM, Tim Rentsch wrote:
> Martin Shobe <martin.shobe@yahoo.com> writes:
>
>> On 4/19/2015 11:21 AM, Tim Rentsch wrote:
>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>
>>>> On 4/17/2015 12:58 PM, Tim Rentsch wrote:
>>>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>>>> On 4/15/2015 5:23 PM, Tim Rentsch wrote:
>>>>>>> [snip] Getting back to the topic from upthread, ISTM that
>>>>>>> members of the C++ community often suggest that C should adopt
>>>>>>> certain features of C++, yet there has been rather little
>>>>>>> reciprocation from C++ in terms of adopting C constructs from
>>>>>>> C99. The claim is that almost all C code is legal C++ code.
>>>>>>> However, judging by the actions of the C++ community (about
>>>>>>> which I should say that my experience in this realm is fairly
>>>>>>> limited, but based on that), it seems that they are less
>>>>>>> interested in expanding the common subset than they are in
>>>>>>> following an "embrace, extend, extinguish" type strategy. And
>>>>>>> if they want to prove that hypothesis wrong, that's easy to do:
>>>>>>> simply add those features introduced in C99 to C++.
>>>>>>
>>>>>> They did add some. E.g. __func__, variardic macros, long long,
>>>>>> extended integral types. From what I heard, the C and C++
>>>>>> committees tried to keep their the changes they made to support
>>>>>> threading reasonably compatible. From what I've seen, the C++
>>>>>> committee's attitude is keep it compatible unless it interferes
>>>>>> with the direction they want to take C++ in.
>>>>>
>>>>> This position sounds reasonable, but in terms of practical
>>>>> results it seems not too different from we'll put it in if
>>>>> we feel like it. Consider a small set of constructs present
>>>>> in C but not (AFAIK but please correct if wrong) in C++:
>>>>>
>>>>> restrict
>>>>> compound literals
>>>>> designated initializers
>>>>> variable length arrays
>>>>> complex floating point values
>>>>>
>>>>> I think these could be added to C++ as follows:
>>>>>
>>>>> restrict - accept the syntax, and add the needed rules for
>>>>> type compatibility (which are rarely transgressed), but
>>>>> without any semantic consequences (which is conforming
>>>>> for what restrict does).
>>>>
>>>> See N4150. Part of the reason that they haven't added it is that
>>>> they haven't decided what the needed rules for type compatibility
>>>> are in C++. In particular how it behaves with overloads,
>>>> functors, and templates.
>>> I looked through this briefly. AFAICT none of the problems
>>> they bring up has any effect on what I'm suggesting, which
>>> is basically to accept the syntax but do nothing with it.
>>> If it were important for what C++ wants to do later, there
>>> could also be no effect on type compatibility. And the list
>>> of compilers that already have some form of restrict as an
>>> extension is pretty comprehensive ("accepted by every major
>>> compiler" is what N4150 says).
>> Let's say that the C++ committee does what you propose. They
>> add restrict and (as far as overloads, functors, and templates
>> are concerned) it does nothing. People then write code based
>> on the fact that it does nothing. Meanwhile, the C++ committee
>> decides that it should do something, possibly to allow for
>> template writers to specify different algorithms based on
>> whether or not restrict is used. Now adding that ability to
>> the language is a breaking change.
> Two comments. First, I don't think the scenario you describe
> (ie, that code would be written based on 'restrict' doing
> nothing) is very plausible. Possible, yes, but not plausible.
> Second, if 'restrict' had no effect on type rules, then it
> wouldn't be possible to overload (or template select) based
> on 'restrict'. AFAICS this removes any incentive to add
> 'restrict' to any new C++ code.
What about people who start the process of converting C code to C++ and
leave it in an intermediate state? I find that scenario plausible.
[snip]
>>>> C++ already has std::complex.
>>>
>>> Right, but the question is would also having _Complex (as an
>>> optional feature) interfere with that? That should be the
>>> test, and I don't see how it does.
>> I don't see any technical hurdles that couldn't be overcome,
>> but would you have float _Complex be the same type as
>> std::complex<float> or would they be different? There would
>> need to be agreement here and I can see arguments for either.
> Speaking just for myself, I don't care - either choice is better
> than not having _Complex at all. Having said that, my first
> reaction is that probably they should be different, and use
> implicit conversion to get back and forth; which choice makes
> the most sense though probably depends on library issues, which I
> am not qualified to address. But either way is fine by me.
Personally, I wouldn't care either, but whatever they decide to do, the
committee would still have to agree on it.
> In
> fact, I can make a stronger statement - there could be a rule
> that any TU that uses _Complex would be precluded from using
> std::complex, and vice versa. As long as I can take a C program,
> and compile it using a C++ compiler, I don't care if std::complex
> and _Complex can interoperate (within a single TU - presumably
> different TU's could use the two independently).
I would find that annoying.
Martin Shobe
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 15:23 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-16 10:02 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 10:58 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 08:26 +1200
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-17 13:51 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 11:24 +1200
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-18 12:11 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:29 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-18 13:08 +0200
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 23:33 +1200
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-18 14:19 +0200
Re: faster than c raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:43 +0000
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-19 13:46 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-19 23:33 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:25 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-23 00:37 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 00:25 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-23 19:36 +1200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 09:10 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 09:19 +0200
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-23 13:41 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 10:36 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 09:25 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-24 04:45 -0700
Re: faster than c Bartc <bc@freeuk.com> - 2015-04-24 13:36 +0100
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-27 06:16 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 14:44 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:10 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:03 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 16:22 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:18 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 16:58 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 09:21 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-20 12:51 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:47 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 17:20 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:51 -0700
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-17 23:10 +0000
Re: faster than c raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:46 +0000
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:56 -0700
csiph-web