- "C++: Size Matters in Platform Compatibility" - 1 Update
- Why does this work on Xcode ??? - 6 Updates
- About getters/setters - 1 Update
- newbie question: exceptions - 2 Updates
| David Brown <david.brown@hesbynett.no>: Aug 24 08:56PM +0200 On 23/08/2019 20:14, Richard Damon wrote: > would get ugly. That is why Unicode has currently defined that 0x10FFFF > will be the highest code point. I suspect at some point there will be > pressure to change that. It is true that UTF-16 is limited to 1,114,111 characters. (I didn't know that until recently.) However, Unicode says: <https://www.unicode.org/faq/utf_bom.html#utf16-6> """ Q: Will UTF-16 ever be extended to more than a million characters? A: No. Both Unicode and ISO 10646 have policies in place that formally limit future code assignment to the integer range that can be expressed with current UTF-16 (0 to 1,114,111). Even if other encoding forms (i.e. other UTFs) can represent larger intergers, these policies mean that all encoding forms will always represent the same set of characters. Over a million possible codes is far more than enough for the goal of Unicode of encoding characters, not glyphs. Unicode is not designed to encode arbitrary data. If you wanted, for example, to give each "instance of a character on paper throughout history" its own code, you might need trillions or quadrillions of such codes; noble as this effort might be, you would not use Unicode for such an encoding. [AF] """ > characters, as one big reason for extending the Unicode standard past 16 > bits was that there were a LOT more characters needed then expected to > handle them. Yes. The reality is that there are few documents that fall into this category, thus it is easier to stick to UTF-8 for all documents. > ignoring it and just not work right with 'esoteric' characters), is less > compact in the most common cases, and has a byte order issue for byte > streams (which most data streams are). Agreed. |
| Richard Damon <Richard@Damon-Family.org>: Aug 23 07:10PM -0400 On 8/23/19 5:07 PM, Alf P. Steinbach wrote: > That's right, but this isn't QoI, it's about correctness. > Cheers!, > - Alf The Standards unfortunately leave a LOT to QoI. For instance, as far as I know, the compiler would be free to implement unsigned i = 1; unsigned j = 5; unsigned k = i + j; as k = __add_uint(i, j); where __add_uint() was defined as: unsigned __add_uint(unsigned i, unsigned j) { if(j) return __add_uint(++i, --j); else return i; } You might even need something like this (but maybe iterative instead of recursive) for a processor with very limited arithmetic operations (just increment/decrement). One such an implementation, the program int main() { unsigned i = 1U + 65000U; } might fail due to exhaustion of resources, and that is ok by the standard. The Standard just requires that there be ONE program that reaches all of the specified resource limits that the implementation can process, any other program is allowed to fail for resource limits. This 'one program' rule is one of the big holes in the Standard (at least in my opinion). |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 23 07:49PM -0400 On 8/23/19 5:07 PM, Alf P. Steinbach wrote: > On 23.08.2019 16:37, David Brown wrote: >> On 23/08/2019 15:28, James Kuyper wrote: ... > As an example, rewriting a function with loop that uses a fixed size > storage known at compile time, to a recursive function that uses storage > proportional to the function argument, changes the behavior. It doesn't change the observable behavior. Stack usage isn't observable. The observable behavior won't occur at all if the program runs out of stack space, but that's also a possibility for the iterative version of the program, so it doesn't count as a difference in the observable behavior. > With the original code one is guaranteed that it will complete. From what do you derive that guarantee? What minimum amount of stack does the standard require an implementation to provide? What upper limit does the standard impose on the amount of stack used up by the iterative version of that program? In case you're having trouble locating the relevant clauses, let me give you a hint: they don't exist. The standard doesn't say anything about either issue. It says precisely as much about those issues for the recursive version of the program as it does about the iterative version - which is nothing at all. What the standard does say that's relevant is "If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its resource limits, accept and correctly execute 2 that program." (4.1p2). Note the key exception - "within its resource limits". That's the phrase that gives the recursive version of the program permission to fail if it runs out of stack; stack space is one of the implementation's resources, and it is in fact limited. That same phrase also gives the iterative version of the program permission to fail, for precisely the same reason. The iterative version is less likely to run out of stack space, but it's not guaranteed to have enough stack space, any more than the recursive version is. > compiler is formally permitted to change a program that guarantees a > result if it compiles and loads, into a program that almost guaranteed > does not produce a correct result. No, if the iterative version of the program was guaranteed to succeed, this would not be a permitted rearrangement of the code. The only relevant guarantee has an escape clause that can be used to justify either version of the code failing. > absurd. Somewhere in that argument there's necessarily something wrong, > and that's not a QoI issue. Having enough stack available to allow either version of the program to complete is entirely a matter of QoI - the standard says nothing about the issue, except to provide "resource limits" as a permissible reason for a program to fail. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 24 06:45AM +0200 On 24.08.2019 01:49, James Kuyper wrote: > the program, so it doesn't count as a difference in the observable behavior. >> With the original code one is guaranteed that it will complete. > From what do you derive that guarantee? The standard guarantees it. "shall ... within its resource limits ... correctly execute that program". When the resource requirements are known at compile time, there is no question about it: if the program loads, and the provided resources are sufficient for those known requirements, it will execute correctly. > What minimum amount of stack > does the standard require an implementation to provide? The standard doesn't, AFAIK, say anything about minimum storage, but that doesn't matter. When the program's resource requirements are known at compile time one can provide sufficient resources for those known requirements. In practice, as you know, that's done by specifying the minimum stack size in the build of the program, which ensures that it either loads and runs correctly, or else fails to load. But conceivably it could be done in other ways, even for each execution. However it's done, when a fixed resource requirements program produced by a conforming compiler is run, it produces a correct result. One /can/ rely on a C++ program to produce correct results. When one ensures that it will not exceed the implementation's resource limits. It's a different matter when the resource requirements are not known until run time, as with a transformation from iterative to recursive. Then one cannot in general provide guaranteed sufficient resources. Instead one may end up with a program that always or nearly always produce incorrect results, even, since this is the nature of UB, without any indication that the results are wrong. Note that such transformations include an implementation whose executables, possibly except for `int main(){}`, /never/ work. So then one /cannot/ rely on a C++ program to produce correct results. Again, that a compiler can produce only non-functioning programs and still be formally correct is absurd, only an interpretation for children or academics. Such a compiler fails all requirements on a C++ compiler: it's not a QoI issue. You're arguing that instead, like the watch that just displays "NOW", it can be the most conforming compiler ever, whose executables never do anything formally wrong, and that's meaningless. > What upper limit > does the standard impose on the amount of stack used up by the iterative > version of that program? That's an irrelevant nonsense question. When the resource requirements are known at compile time, there is no question about it: if the program loads, and the provided resources are sufficient for those known requirements, it will execute correctly. [snip] Cheers & hth., - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 24 06:49AM +0200 On 24.08.2019 01:10, Richard Damon wrote: > if(j) return __add_uint(++i, --j); > else return i; > } This is an argument by repeated assertion. True, that's been the nature of the discussion so far. But in order to break that cycle (if that's possible), I cut this sub-thread here, as far as I'm concerned. Hopefully others won't chime in. :) Cheers!, - Alf |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 24 04:58AM -0700 > The thread has been civilized so far, but now (1) Tim has added a > social silly-argument (that to disagree with him one must think of > oneself as smarter than all people on the committee), You have misunderstood me. My comment had nothing to do with whether you agree (or disagree) with me. I haven't had a chance yet to go through in detail the cascade of messages following my posting upthread, but I thought I should correct this misunderstanding right away. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 24 07:49PM +0200 > The whole point of using tail recursion is that is doesn't use up stack > space, silly boy. You can realistically rely on that a compiler will convert a tail -recursion into an iteration when the code is optimized. But with debug-code no compiler will convert the tail-recursion into an iteration. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 24 04:32AM -0700 > On Thursday, 22 August 2019 17:25:24 UTC+3, JiiPee wrote: >> On 21/08/2019 20:52, Tiib wrote: >>> Snipping possible misrepresentation of Herb Sutter and Strange comment considering that nowhere in the thread is any reference given for Herb Sutter's views. Given that you don't know what Herb Sutter writings JiiPee means to refer to here, there is no basis for claiming a misrepresentation, or even a possible misrepresentation (except in the vacuous sense that "all things are possible"). > does not conflict with it just suggest to prefer that c-style struct > to all trivial setters and getters. That is why your claim seemed > misrepresentation. For what it's worth, I think JiiPee's comments offer a more faithful representation of the core guidelines document than yours do. |
| Rosario19 <Ros@invalid.invalid>: Aug 24 08:32AM +0200 On Tue, 13 Aug 2019 16:34:10 +0200, Jivanmukta wrote: >throw exception(); >and not: >throw new exception(); i am for not use exceptions C++ can have some problems if one doesn't know how/when the memory of the program is dinamically created and free and if one doesn't know how many leak his/her progam has but for remain it seems ok |
| Melzzzzz <Melzzzzz@zzzzz.com>: Aug 24 11:30AM > is dinamically created and free > and if one doesn't know how many leak his/her progam has > but for remain it seems ok Exceptions does not produce leaks except if you use MFC. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| 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