- In the end, rason will come - 11 Updates
- Is there a reason that the std::map contains() function lacks a noexcept specifier? - 3 Updates
- Geodetic Development Tool - 9 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 31 10:14AM +0200 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 31 01:25AM -0700 On 7/31/2019 1:14 AM, Bonita Montero wrote: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html The One True Representation! |
| "Öö Tiib" <ootiib@hot.ee>: Jul 31 03:48AM -0700 On Wednesday, 31 July 2019 11:14:17 UTC+3, Bonita Montero wrote: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html This feels like two major proposals. One is that all signed integers should be two's complement and other is that signed integer overflow should wrap. Majority will be happy (or at least content) with both but about second there will be likely a bit of opposition and controversy. Most of such opposition will boil down to claim that signed arithmetic should not overflow anyway in sane code and therefore some optimizations where compiler did assume that it does not overflow will be lost without any gain. I agree that that signed arithmetic should not overflow in good code but it seems hard to find (or to teach) programmers who write good code in that respect. So there are often bugs with it and so I would often prefer crash (or have SIGFPE raised) instead of wrapping. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 31 07:58AM -0400 On 7/31/19 4:25 AM, Chris M. Thomasson wrote: > On 7/31/2019 1:14 AM, Bonita Montero wrote: >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html > The One True Representation! That document claims: > It is extremely unlikely that there exist any significant code base> developed for two's complement machines that > would actually work when run on a non-two's > complement machine. I consider that implausible, unless "developed for two's complement machines" is defined as "developed with the deliberate intent of relying on two's complement", in which case it becomes a trivial tautology. Most of my code is intended to work regardless of how signs are represented, and the discipline required to achieve that result is not great: don't apply bit-wise operators (<< >> | & ~) to values of signed types. Don't use type punning. Whenever doing calculations involving signed integer types, make sure that the specific types chosen are big enough to avoid overflow - and when a calculation cannot be guaranteed to avoid overflow for all permitted values of its inputs, make sure the calculation is not performed when the values are such that overflow would occur. I'm sure that there have to be at a least a few significant code bases where such discipline has been followed - though I cannot identify any specific ones. |
| Siri Cruise <chine.bleu@yahoo.com>: Jul 31 05:14AM -0700 In article <qhrvp4$i1c$1@dont-email.me>, > I consider that implausible, unless "developed for two's complement > machines" is defined as "developed with the deliberate intent of relying > on two's complement", in which case it becomes a trivial tautology. I programmed on CDC ones complement machines and CDC twos complement machines. I never had a problem except -0. > great: don't apply bit-wise operators (<< >> | & ~) to values of signed > types. Don't use type punning. Whenever doing calculations involving > signed integer types, make sure that the specific types chosen are big It's difficult to run into differences. Even bit twiddling code on signed numbers can work fairly transparently. -0 can be a problem, but only in assembly. Compilers don't let you say -0 < +0. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 31 02:59PM +0200 On 31.07.2019 10:25, Chris M. Thomasson wrote: > On 7/31/2019 1:14 AM, Bonita Montero wrote: >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html > The One True Representation! As I recall from a novel I read, One True is a mean-spirited artifical intelligence that takes over Earth and eventually Mars, with more or less direct control over each individual human. It can convert any human to an obedient slave by just saying a few words to the person. So it's best not to create any opportunity where one might hear what it says. Cheers!, - Alf |
| David Brown <david.brown@hesbynett.no>: Jul 31 03:29PM +0200 On 31/07/2019 12:48, Öö Tiib wrote: > should wrap. > Majority will be happy (or at least content) with both but about > second there will be likely a bit of opposition and controversy. I doubt if anyone will mind about the first. Representation is implementation specific, but since I think it is fair to say that any system which will support modern C++ (or modern C) will have two's complement representation, this is pretty much a no-brainer. It will simplify several points in the standard and make some kinds of coding simpler, while having no adverse effects that I can think of. There will, I think, be quite a bit of opposition to the second. I am certainly against it, for several reasons. Some things that are currently implementation defined, such as the conversion to signed types when the value is out of range, could usefully and sensibly be defined as two's complement wrapping or modulo arithmetic. That is what happens today in most (or all) compilers, and would be a natural choice to stipulate in the standards along with the representation. > who write good code in that respect. So there are often bugs with > it and so I would often prefer crash (or have SIGFPE raised) > instead of wrapping. I see a number of reasons why two's complement wrapping for signed arithmetic is a bad idea. 1. It hinders optimisations. When you have division involved, you lose several associative properties of integer arithmetic. And you lose all sorts of basic identities that exist when you assume no overflow, such as "x > y <=> (x + z) > (y + z)". 2. It makes alternative overflow behaviour wrong and non-conforming. That means a compiler that has traps on overflows for safer coding or during debugging, is suddenly no longer correct C++. 3. It gives broken and incorrect code a defined behaviour, making it harder for compilers and static analysis tools to inform the programmer and help find mistakes. Instead of being able to tell you that you've overflowed your integer constant (or constexpr) calculations, you'd have to put the compiler in non-conforming modes first. 4. Integer arithmetic that overflows is almost always in error - even if the results are defined (by the language, compiler flags, etc.). If you have a pile of 2147483647 apples and put another apple on the pile, a result of -2147483648 is about the silliest answer you could possibly give. Raising an error or saturating would be far more likely to be correct. 5. It gives the impression that signed integer arithmetic is now "safe" and can be carried out without as much care and attention as you had to do when there were nasal demons lurking round the bend. This is, of course, nonsense - it merely hides some classes of errors under the carpet where they are harder to find. So I am against defining the results of signed integer arithmetic primarily for code safety and correctness reasons, and secondarily for performance reasons. |
| Keith Thompson <kst-u@mib.org>: Jul 31 01:05PM -0700 > On Wednesday, 31 July 2019 11:14:17 UTC+3, Bonita Montero wrote: >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html The link is to: p0907r0 Signed Integers are Two's Complement Published Proposal, 9 February 2018 > who write good code in that respect. So there are often bugs with > it and so I would often prefer crash (or have SIGFPE raised) > instead of wrapping. I have no particular objection to requiring two's complement for signed integers. I don't think this proposal addresses padding bits or the possibility that the most negative representation is a trap representation, so would still be some rare variations to worry about. Specifying wrapping behavior for signed integers could be a *big* problem. In particular, this: int n = INT_MAX + 1; would probably not produce a warning. It's not required to do so now, and compilers could produce warnings anyway, but making INT_MAX + 1 well defined where it's currently almost certainly an error would be confusing. More concretely, this: constexpr int n = INT_MAX + 1; is currently invalid and would become legal. Requiring 2's-complement representation while leaving overflow behavior alone would be a simpler and less controversial change. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| "Öö Tiib" <ootiib@hot.ee>: Jul 31 02:22PM -0700 On Wednesday, 31 July 2019 16:30:21 UTC+3, David Brown wrote: > > instead of wrapping. > I see a number of reasons why two's complement wrapping for signed > arithmetic is a bad idea. I was almost certain that you are one who is against it considering what you have written before. > several associative properties of integer arithmetic. And you lose all > sorts of basic identities that exist when you assume no overflow, such > as "x > y <=> (x + z) > (y + z)". That is true, (like I said), there are several optimizations that assume that integer arithmetic does not overflow and it will be tricky to indicate to compiler that it may do such optimizations in conforming mode. But so ... solution is same as with your #2. > 2. It makes alternative overflow behaviour wrong and non-conforming. > That means a compiler that has traps on overflows for safer coding or > during debugging, is suddenly no longer correct C++. The compiler vendors have never cared that with certain options their compiler is not conforming. Quite popular is to let to turn off exceptions, to turn off RTTI and so on. I do not think that turning off wrapping signed integers will be different in any way. > and help find mistakes. Instead of being able to tell you that you've > overflowed your integer constant (or constexpr) calculations, you'd have > to put the compiler in non-conforming modes first. Please elaborate. There are piles of warnings that a well-formed program with fully well-defined behavior will receive with -Wall and most warnings in -Wextra are such plus there are more warnings I like that neither of those settings turns on. No non-conforming modes are needed. So why should warning about potentially wrapping integer suddenly cause different situation? > result of -2147483648 is about the silliest answer you could possibly > give. Raising an error or saturating would be far more likely to be > correct. That option I would also love like I said above. > do when there were nasal demons lurking round the bend. This is, of > course, nonsense - it merely hides some classes of errors under the > carpet where they are harder to find. It is frequently same with unsigned integers. On lot of cases when these overflow then it is defect. > So I am against defining the results of signed integer arithmetic > primarily for code safety and correctness reasons, and secondarily for > performance reasons. But you put performance reason as #1 in above list. ;) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 31 10:35PM On Wed, 2019-07-31, James Kuyper wrote: > I consider that implausible, unless "developed for two's complement > machines" is defined as "developed with the deliberate intent of relying > on two's complement", in which case it becomes a trivial tautology. Yes. A really weird thing to write, now that you point it out. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: Jul 31 03:48PM -0700 On Wednesday, 31 July 2019 23:05:52 UTC+3, Keith Thompson wrote: > error would be confusing. More concretely, this: > constexpr int n = INT_MAX + 1; > is currently invalid and would become legal. I feel confused, either I misunderstand the point you are making or have misread standard. Right now (as with C++17) the std::numeric_limits<int>::is_modulo has implementation-defined constexpr value. Yes? That value can depend on compiler options if it is true or false. Yes? My reading of standard is that when it is true then INT_MAX + 1 is not undefined behavior. Do I misread? Are you saying that it should be undefined behavior? I read that the proposal was to make it true always and that I'm also unsure if it is good idea. |
| Daniel <danielaparker@gmail.com>: Jul 31 07:10AM -0700 The cppreference documentation doesn't identify any exceptions. https://en.cppreference.com/w/cpp/container/map/contains Thanks, Daniel |
| Bo Persson <bo@bo-persson.se>: Jul 31 06:12PM +0200 On 2019-07-31 at 16:10, Daniel wrote: > https://en.cppreference.com/w/cpp/container/map/contains > Thanks, > Daniel The function itself is perhaps unlikely to throw any exceptions, but any comparisons would use the Compare template parameter which is not limited to noexcept operations. Bo Persson |
| "Öö Tiib" <ootiib@hot.ee>: Jul 31 02:55PM -0700 On Wednesday, 31 July 2019 17:10:24 UTC+3, Daniel wrote: > The cppreference documentation doesn't identify any exceptions. > https://en.cppreference.com/w/cpp/container/map/contains Hmm? Be constructive. How you suggest to define it then? Let me try ... bool contains( const Key& key ) const noexcept(noexcept(key_comp()(key, key))); That? Does that work? Note that contains() is C++2020 map feature and C++2020 standard does not exist yet. I don't even understand why to add it since it does exactly same thing that std::map::count() already does. However if it is possible to add such noexcept specifications then these should perhaps be added to *lot* of other functions as well. |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 30 11:08PM -0700 On 7/30/2019 7:32 AM, Fred Killet wrote: > price. However, WINDOWS programmers have the advantage to integrate > geodetic functions as a DLL. That is already possible from 500 euros. > Fred shared object files on Linux should work fine. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 31 10:36AM +0300 On 31.07.2019 9:08, Chris M. Thomasson wrote: >> geodetic functions as a DLL. That is already possible from 500 euros. >> Fred > shared object files on Linux should work fine. It takes some knowledge and experience to prepare a binary C++ .so which would work on most Linuxes, especially if it is using a lot of third-party libraries. The default model in Linux is to use the system-installed C++ runtimes, but there have been ABI-breaking changes in those runtimes, so one just cannot compile a .so on a random Linux box and hope it will work everywhere. Third-party libraries with C++ interfaces will add many complications, one could either use system-installed ones or package them together with your own .so, both approaches have serious drawbacks. In short, the easiest way to install custom software (not included in package manager repos) in Linux is to build it directly on the target box. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 31 12:36AM -0700 On Wednesday, 31 July 2019 09:08:19 UTC+3, Chris M. Thomasson wrote: > > geodetic functions as a DLL. That is already possible from 500 euros. > > Fred > shared object files on Linux should work fine. Who knows. Majority of Windows DLL-s have actually kind of language agnostic service interface that provides remote process call objects (COM). COM might simplify linking to C#, Visual basic or Ms access but is not easily portable to other platforms. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 31 10:15AM +0200 >> geodetic functions as a DLL. That is already possible from 500 euros. >> Fred > shared object files on Linux should work fine. Maybe he estimates that there will be no customers with Linux? |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 31 01:18AM -0700 On 7/31/2019 12:36 AM, Paavo Helde wrote: > approaches have serious drawbacks. > In short, the easiest way to install custom software (not included in > package manager repos) in Linux is to build it directly on the target box. Humm... It would be wise to create the shared object API using C. The guts can be C++, exceptions aside for a moment... but the API would be all in C. A little C++ wrapping up the C shared API would work. Sound a little better? Plugin interface. |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 31 01:22AM -0700 On 7/31/2019 1:15 AM, Bonita Montero wrote: >>> Fred >> shared object files on Linux should work fine. > Maybe he estimates that there will be no customers with Linux? Perhaps. Afaict, he can do it with OpenGL for rendering, C for interface, C++ for guts? Humm... |
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 31 11:52AM +0300 On 31.07.2019 11:18, Chris M. Thomasson wrote: > guts can be C++, exceptions aside for a moment... but the API would be > all in C. A little C++ wrapping up the C shared API would work. Sound a > little better? Plugin interface. Yes, this is a good approach for some C++ libraries, but requires extra work and may hinder performance. Another good approach is to create header-only libraries, so there is no .so to link to. |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 31 02:14AM -0700 On 7/31/2019 1:52 AM, Paavo Helde wrote: > Yes, this is a good approach for some C++ libraries, but requires extra > work and may hinder performance. Another good approach is to create > header-only libraries, so there is no .so to link to. Agreed. Sometimes, its hard to beat a pure header based lib. I am quite fond of GLM: https://glm.g-truc.net/0.9.2/api/a00001.html ;^) |
| Manfred <noname@add.invalid>: Jul 31 02:44PM +0200 On 7/31/2019 9:36 AM, Paavo Helde wrote: > approaches have serious drawbacks. > In short, the easiest way to install custom software (not included in > package manager repos) in Linux is to build it directly on the target box. There is always the possibility for the vendor to provide binary packages for major distros. For the vendor this is considerably harder than delivering sources, nonetheless the process can be fairly automated, at the advantage of not having to disclose the source code - which in this case appears to be worth an order of magnitude difference in price. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment