- Available C++ Libraries FAQ - 1 Update
- Is this really necessary - 12 Updates
| Nikki Locke <nikki@trumphurst.com>: Aug 14 10:23PM Available C++ Libraries FAQ URL: http://www.trumphurst.com/cpplibs/ This is a searchable list of libraries and utilities (both free and commercial) available to C++ programmers. If you know of a library which is not in the list, why not fill in the form at http://www.trumphurst.com/cpplibs/cppsub.php Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website. |
| Juha Nieminen <nospam@thanks.invalid>: Aug 14 08:07AM >>would not allow efficient implementation of an integer type that was >>wide enough to store a distinct value for all possible addresses. They > Not allow efficient and not allow at all are 2 different things. Undefined behavior does not mean "this is not allowed". It simply means that the behavior isn't guaranteed, and it may depend on the compiler and the architecture (or anything else, for that matter). |
| Juha Nieminen <nospam@thanks.invalid>: Aug 14 08:13AM >> that you expect. > If the implementation provides `uintptr_t` then you're guaranteed a > correct result for roundtrip conversion. Yes, but alas, support for uintptr_t is optional, both in C and C++ (probably because of that part of the standard I quoted, which would allow an architecture where pointers are larger than any integer type). |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 14 02:28AM -0700 > difference of pointers, the result is inherently ptrdiff_t. If > this is inadequate for holding the actual difference, then it's > already too late to convert it to int64, it is already ruined. Thank you for giving this alternate formulation. I myself would not have said exactly this, but indeed it might help some people understand who would not have otherwise. > program one needs to cast the pointers themselves first to an > (u)int64 type, then subtract. But then it is not subtraction of > pointers any more. I'm extremely reluctant either to use or to recommend operating on values that result from converting pointers to integers, and this case is no exception. If it is necessary to deal with the possibility of such circumstances I think there are better ways to do that (and would rather not elaborate further just now). > This is not obvious and not trivial. Luckily it won't come up > often in practice, >2GB byte arrays in 32-bit programs are rare. Surprisingly it can come up in "garden variety" C code, and that is worth knowing and guarding against. Probably the easiest way to protect against it is to limit the sizes of malloc() calls (and other potential object allocation methods) to PTRDIFF_MAX. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 14 02:58AM -0700 > In C++03 this was perhaps more clear because then the standard > stated that the C standard "is incorporated into this Standard by > reference". Note that there is some ambiguity as to which C standard is being referenced here. The Normative References list ISO/IEC 9899:1999, but section 1.1 p2 says "C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:1990", and section 1.2 p2 (also in Normative References) says "The library described in clause 7 of ISO/IEC 9899:1990 and clause 7 of ISO/IEC 9899/Amd.1:1995 is hereinafter called the Standard C Library." |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 14 03:00AM -0700 > I don't need to verify anything, pointer values are numbers. They > may have seperate parts and addressing might not be linear on some > archaic CPUs, but they're numbers, end of. I'm sorry our conversation has not been more productive. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 14 03:20AM -0700 > which is incorporated into this Standard by reference. > That could be read to imply that the entire C standard is included > by reference, [...] There is no ambiguity in this sentence about what phrase is being referenced for incorporation, and that is the (entire) ISO C standard. If it were meant to incorporate only some portions of the ISO C standard, the sentence would have said "which _are_ incorporated" rather than "which _is_ incorporated". |
| Bart <bc@freeuk.com>: Aug 14 02:03PM +0100 > I don't need to verify anything, pointer values are numbers. They may have > seperate parts and addressing might not be linear on some archaic CPUs, but > they're numbers, end of. I assume that by numbers, you mean integers? Pointers are bit patterns. So are floating point representations, but you don't call them integers because usually you interpret the patterns very differently. It could be that on most hardware, pointers are only exposed as linear byte offsets, so share some characteristics with integers. But usually you can't meaningfully add pointers together, or multiply them. And subtraction only works between compatible pointers to the same type, of the same alignment, and, for C language (I guess C++ too), between objects within the same contiguous memory block. There is normally no such restriction on subtracting two integers. The result is not scaled either. However, when you subtract two u64 integers A and B, the A-B result will be u64 too; you have similar problems if you need a signed result, because i64 can't represent all possible results (you need i65 or i128). But the language here says that A-B is legal and the result is meaningful even when A<B. |
| mickspud@downthefarm.com: Aug 14 03:06PM On Sat, 14 Aug 2021 14:03:03 +0100 >> seperate parts and addressing might not be linear on some archaic CPUs, but >> they're numbers, end of. >I assume that by numbers, you mean integers? Ints, longs, long long, uint64_t, take your pick. >Pointers are bit patterns. So are floating point representations, but >you don't call them integers because usually you interpret the patterns >very differently. The point is they can all be assigned to and read as numbers. >It could be that on most hardware, pointers are only exposed as linear >byte offsets, so share some characteristics with integers. But usually >you can't meaningfully add pointers together, or multiply them. All sane OSs expose virtual memory as linear and essentially unlimited up to the maximum value the address registers in the MMU can operate on. >because i64 can't represent all possible results (you need i65 or i128). >But the language here says that A-B is legal and the result is >meaningful even when A<B. diff = A > B ? (A - B) : (B - A) |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Aug 14 10:38AM -0700 > On Fri, 13 Aug 2021 10:30:15 -0400 > James Kuyper <james...@alumni.caltech.edu> wrote: ... > >would not allow efficient implementation of an integer type that was > >wide enough to store a distinct value for all possible addresses. They > Not allow efficient and not allow at all are 2 different things. Agreed - which is why I was very careful to use the term that correctly conveyed the meaning that I intended. Any platform that allows implementation of C would also allow emulation of int_leastN_t for virtually any reasonable value of N, but those emulations would be unacceptably inefficient for any value of N that is too large - and the inefficiency of those emulations is a valid concern. |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Aug 14 10:40AM -0700 On Saturday, August 14, 2021 at 4:07:23 AM UTC-4, Juha Nieminen wrote: > mick...@downthefarm.com wrote: > > On Fri, 13 Aug 2021 10:30:15 -0400 > > James Kuyper <james...@alumni.caltech.edu> wrote: ... > Undefined behavior does not mean "this is not allowed". It simply means > that the behavior isn't guaranteed, and it may depend on the compiler > and the architecture (or anything else, for that matter). I was talking about what the platform would allow, not about what the standard would allow. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 14 01:24PM -0700 > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: [...] > standard. If it were meant to incorporate only some portions of > the ISO C standard, the sentence would have said "which _are_ > incorporated" rather than "which _is_ incorporated". (For those not familiar with the C standard, section 6 defines the core language and section 7 defines the library.) I agree that it *says* that the entire C standard is incorporated, but I'm not convinced that was the intent. I admittedly let my assumptions influence how I read it. In the C++11 standard, the section is: 17.5.1.5 [structure.see.also] Paragraphs labeled "See also:" contain cross-references to the relevant portions of this International Standard and the ISO C standard, which is incorporated into this International Standard by reference. In C++17 (in the draft I have), it changed to: 20.4.1.5 [structure.see.also] Paragraphs labeled "See also:" contain cross-references to the relevant portions of the ISO C standard. I don't believe any of the following "See also" references point to anything in section 6 of the C standard. Most of them refer to other sections of the C++ standard, most of the rest refer to ISO C section 7, and a handful refer to section 5, which is where the C standard defines <limits.h> and <float.h>. As far as I know, nothing in the C++ standard depends on section 6 of the C standard. The core language is defined from scratch. Whether the C++ standard incorporates the entire C standard or not, it doesn't *need* to incorporate section 6 -- and as of C++17, that wording was removed. The change was made in response to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0063r3.html "C++17 should refer to C11 instead of C99" https://github.com/cplusplus/draft commit 6b05dff5 -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Juha Nieminen <nospam@thanks.invalid>: Aug 14 08:33PM > the relevant portions of this International Standard and the ISO > C standard, which is incorporated into this International Standard > by reference. I understand that to mean "the referenced parts should be considered part of this standard as well". In other words, *only* the referenced parts. I could be wrong, of course. |
| 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