September 28, 2013 Re: C locale | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 9/27/2013 6:36 PM, Walter Bright wrote:
> On 9/27/2013 5:28 PM, "Luís Marques" <luis@luismarques.eu>" wrote:
>> BTW, I have for more than once wondered why there was no way to specify more
>> than one version identifier (is there?), like this:
>>
>> version(Windows, OSX)
>> {
>
> For the reason you mentioned earlier. If you are changing the OSX values, you'll
> likely mess up the Windows ones.
>
> I've been at this for 30 years, and am quite fed up with the bugs from attempts
> to save a few keystrokes. The practice of separating the os sections into
> distinct ones has been a big win in reliability.
>
And, of course, as you discovered, when they are defaulted they are usually wrong, and they are wrong in a most pernicious, hard to discover way. The code looks right, and may even sort of behave itself. The only way you can tell if it's wrong is to laboriously and tediously go through the system's .h files.
|
September 28, 2013 Re: C locale | ||||
---|---|---|---|---|
| ||||
Posted in reply to Luís Marques | On 9/27/2013 4:44 PM, "Luís Marques" <luis@luismarques.eu>" wrote: > On Friday, 27 September 2013 at 19:23:12 UTC, Walter Bright wrote: >> static assert(0); > > Do you prefer assert(0) instead of assert(false)? Do whichever you prefer. > Is it not worth to put a > message after the 0/false? (static assert(0, "foo missing"); ) I find assert messages to be redundant, pointlessly repeating what is obvious from the context, and saying things an extra time. But I'm in the minority with that opinion. > BTW, does that mean that gcc also defines capitalized "OSX", "Posix", etc.? > (otherwise I don't understand your argument) If you're looking for gcc naming consistency, you'll be badly disappointed. |
September 28, 2013 Re: C locale | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 28 September 2013 at 01:42:52 UTC, Walter Bright
wrote:
>> For the reason you mentioned earlier. If you are changing the OSX values, you'll
>> likely mess up the Windows ones.
>>
>> I've been at this for 30 years, and am quite fed up with the bugs from attempts
>> to save a few keystrokes. The practice of separating the os sections into
>> distinct ones has been a big win in reliability.
>
> And, of course, as you discovered, when they are defaulted they are usually wrong, and they are wrong in a most pernicious, hard to discover way. The code looks right, and may even sort of behave itself. The only way you can tell if it's wrong is to laboriously and tediously go through the system's .h files.
Sure, I think it was unwise to "default" the locale enums if the
values do not have standard definitions across all systems
(although I still thank Sean Kelly for the headers, without them
porting code would have been an even greater chore).
But the issue of version(X, Y) is not a case of default, it is
something where you say explicitly that you want the same code
for two explicitly stated systems, without having to copy-paste
the block of code for both systems.
You mention that one disadvantage of such construct is that it
will increase the probability of developers changing both X and Y
when they only want to change X. But with two version blocks (and
copy-pasted code) you increase the probability that you only
change X when you should change X and Y. And with version()
blocks that is even less likely to be noticed, because the code
only has to be syntactically correct.
My point here is not to argue against your choice for the
standard library. My issues of version(X, Y) arose in client code
(non-lib), where it seems to me that the second kind of bug is
probably more likely to occur than the first kind. So, I politely
ask, are you sure the language should not support something like
version(X, Y), for cases where developers think that it is a
better trade-off than multiple version() blocks?
|
September 28, 2013 Re: C locale | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 28 September 2013 at 01:52:10 UTC, Walter Bright
wrote:
>> BTW, does that mean that gcc also defines capitalized "OSX", "Posix", etc.?
>> (otherwise I don't understand your argument)
>
> If you're looking for gcc naming consistency, you'll be badly disappointed.
It really is not my intention to start an argument over something
inconsequential, but I understood your point was: "´linux´ is the
only OS identifier that is not capitalized because that's what's
consistent with gcc". But if the other OS identifiers are not
consistent with gcc then I don't understand your point.
|
September 28, 2013 Re: C locale | ||||
---|---|---|---|---|
| ||||
Posted in reply to Luís Marques | On 9/27/2013 7:18 PM, "Luís Marques" <luis@luismarques.eu>" wrote: > My point here is not to argue against your choice for the > standard library. My issues of version(X, Y) arose in client code > (non-lib), where it seems to me that the second kind of bug is > probably more likely to occur than the first kind. So, I politely > ask, are you sure the language should not support something like > version(X, Y), for cases where developers think that it is a > better trade-off than multiple version() blocks? I understand your point and reasoning, and it has come up repeatedly. It's not obvious why, but that feature (in C and C++) leads to wretched, unmaintainable, buggy, coding horrors. You don't have to take my word for it - do a grep for #if across some C or C++ code that's been maintained by multiple people over a period of years. I include the source code of dmd itself as a (bad) example of #if hell. I've gone to some effort to beat that disease out of the front end, but like barnacles on a boat, they always come back and threaten to sink the ship. The back end is far worse. There are other ways of doing versioning that do not have this result, and I recommend giving them a chance long before reaching for this particular one. |
September 28, 2013 Re: C locale | ||||
---|---|---|---|---|
| ||||
Posted in reply to Luís Marques | On 9/27/2013 7:50 PM, "Luís Marques" <luis@luismarques.eu>" wrote:
> It really is not my intention to start an argument over something
> inconsequential, but I understood your point was: "´linux´ is the
> only OS identifier that is not capitalized because that's what's
> consistent with gcc". But if the other OS identifiers are not
> consistent with gcc then I don't understand your point.
If you're looking for consistency, there isn't any consistent consistency. It's all just a bikeshed issue. I explained why it's "linux", and for better or worse, it is not worth all the grief & disruption changing it.
|
September 28, 2013 Re: C locale | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 28 September 2013 at 04:31:41 UTC, Walter Bright
wrote:
> If you're looking for consistency, there isn't any consistent consistency. It's all just a bikeshed issue. I explained why it's "linux", and for better or worse, it is not worth all the grief & disruption changing it.
Let's use some lateral thinking. How about a compiler warning if,
say, a version statement does not match any defined version
identifier but it would if a case-insensitive comparison was made?
|
September 28, 2013 Re: C locale | ||||
---|---|---|---|---|
| ||||
Posted in reply to Luís Marques | On 9/27/2013 9:46 PM, "Luís Marques" <luis@luismarques.eu>" wrote:
> Let's use some lateral thinking. How about a compiler warning if,
> say, a version statement does not match any defined version
> identifier but it would if a case-insensitive comparison was made?
Having some of the language be case sensitive and others case insensitive? Please no.
|
September 28, 2013 Re: C locale | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 9/27/13 6:52 PM, Walter Bright wrote: >> Is it not worth to put a >> message after the 0/false? (static assert(0, "foo missing"); ) > > I find assert messages to be redundant, pointlessly repeating what is > obvious from the context, and saying things an extra time. > > But I'm in the minority with that opinion. On my team we found this to be the case for static asserts. Dynamic asserts are more often preceded by an explanatory comment. A couple of quick examples from a grep search, revealing a grab bag: // missing token! always_assert(false); // should be handled in onfunction / onmethod always_assert(false); // where do we output n_HEREDOC? always_assert(false); // unexpected assert(IS_STRING_TYPE(cell->m_type)); assert(IsValidKey(k)); // Array escalation must not happen during these reserved // initializations. assert(newp == m_data); static_assert(!(KindOfBoolean & KindOfStringBit), ""); static_assert(keyType != KeyType::Any, "KeyType::Any is not supported in arraySetMImpl"); Andrei |
September 28, 2013 Re: C locale | ||||
---|---|---|---|---|
| ||||
Posted in reply to Luís Marques | On 2013-09-27 19:25, "Luís Marques" <luis@luismarques.eu>" wrote: > What should I do? Do you want me to submit this? Does anyone have > another Posix system laying around and want to check the locale constants? Any file dealing with platform specific functionality need to at least support the following platforms: Mac OS X Linux Windows FreeBSD 32 and 64bit on all of the above platforms. It should be possible to find headers or documentation for all of these online. -- /Jacob Carlborg |
Copyright © 1999-2021 by the D Language Foundation