- standard error messages in a std::string or in a const char * - 2 Updates
- Provably unprovable eliminates incompleteness - 2 Updates
- On stateful allocators and GCC - 6 Updates
| Soviet_Mario <SovietMario@CCCP.MIR>: Sep 11 12:35AM +0200 I'm striving with the translation of standard error codes (returned by runtime functions), like "errno" codes in the corresponding TEXTUAL DESCRIPTIONS. I've seen perror () functions knows how to translate errno, but it does not allow to return that description as a string. Instead it "prints" to stderr, which is useless if ones tries to bubble error messages in a chain of function calls (with the aim : me, callee, don't know how to handle, I bubble the message to you, the caller, and maybe you know or THE USER might know). perror must lookup some internal table where errno's values are translated and the text returned (or copied to stderr). How to get it in a string ? thanks -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Soviet_Mario <SovietMario@CCCP.MIR>: Sep 11 12:37AM +0200 Il 11/09/19 00:35, Soviet_Mario ha scritto: > are translated and the text returned (or copied to stderr). > How to get it in a string ? > thanks merd ! sorry ... I find this just now https://linux.die.net/man/3/strerror maybe will work ... :\ -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| David Brown <david.brown@hesbynett.no>: Sep 10 09:01AM +0200 On 09/09/2019 17:01, peteolcott wrote: > https://en.wikipedia.org/wiki/Continuum_hypothesis > It turns out that the basis concept of cardinality is ill-formed. No, it is not. Cardinality is a mathematical concept with a mathematical definition. It turns out that we can do useful and interesting things depending on certain extra features that we can choose to define, or not to define, but that does not make the definition ill-formed in any sense. > All infinities are the same size. Absolute drivel. > The number of real numbers is the number of adjacent geometric > points on a number line, countable using integers. The cardinality of the set of real numbers is /easily/ shown to be bigger than the cardinality of the integers (countable infinity). (Well, /easily/ if you know that kind of mathematics.) Since you posted a link to the Wikipedia article on the Continuum Hypothesis, did you actually attempt to read it? The second line sums up the hypothesis: """ There is no set whose cardinality is strictly between that of the integers and the real numbers. """ The implication from this is that you have at least two different sizes of infinity, the cardinality of integers (aleph_0) and the cardinality of real numbers (2 ^ aleph_0). Whether you accept the continuum hypothesis or not, you can't get past that sentence and still think those two cardinalities are the same size. |
| peteolcott <Here@Home>: Sep 10 10:38AM -0500 On 9/10/2019 2:01 AM, David Brown wrote: > The cardinality of the set of real numbers is /easily/ shown to be > bigger than the cardinality of the integers (countable infinity). > (Well, /easily/ if you know that kind of mathematics.) Yes I am aware of diagonal argument. You did not pay attention that I just refuted this: >> The number of real numbers is the number of adjacent geometric >> points on a number line, countable using integers. The next real number after 3.0 is the geometric point on the number line that is immediately adjacent to 3.0 on its right side. This geometric point is an infinitesimally larger than 3.0: encoded as the first point in the interval: (3,4] https://en.wikipedia.org/wiki/Bracket_(mathematics) > Since you posted a link to the Wikipedia article on the Continuum > Hypothesis, did you actually attempt to read it? The second line sums > up the hypothesis: If the concept of cardinality is bogus, then any theorem based on a bogus concept is also bogus. -- Copyright 2019 Pete Olcott All rights reserved "Great spirits have always encountered violent opposition from mediocre minds." Albert Einstein |
| Daniel <danielaparker@gmail.com>: Sep 09 08:54PM -0700 Has anyone attempted to use stateful allocators with GCC basic_string? My attempts with versions up to 9 result in a compile time error /usr/include/c++/9/bits/basic_string.tcc:596:30: error: no matching function for call to 'my_alloc::my_alloc()' 596 | if (__n == 0 && __a == _Alloc()) My example allocator my_alloc doesn't have a default constructor, which I don't think you would ever want on a stateful allocator. So why would GCC want to compare the passed allocator __a with the default constructed allocator _Alloc()? I have no issues with vs or clang. Thanks, Daniel |
| Melzzzzz <Melzzzzz@zzzzz.com>: Sep 10 04:00AM > My example allocator my_alloc doesn't have a default constructor, which I don't think you would ever want on a stateful allocator. So why would GCC > want to compare the passed allocator __a with the default constructed > allocator _Alloc()? Don't know about allocator requirements, but if default constructor is not one of them it is a bug in gcc... -- 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 |
| "Öö Tiib" <ootiib@hot.ee>: Sep 10 12:25AM -0700 On Tuesday, 10 September 2019 06:54:37 UTC+3, Daniel wrote: > want to compare the passed allocator __a with the default constructed > allocator _Alloc()? > I have no issues with vs or clang. Bugzilla say it is RESOLVED FIXED for gcc 5 ages ago. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437 Is it regression so someone had added the _Alloc() back, or are you using very old gcc? |
| "Öö Tiib" <ootiib@hot.ee>: Sep 10 01:04AM -0700 On Tuesday, 10 September 2019 10:25:40 UTC+3, Öö Tiib wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437 > Is it regression so someone had added the _Alloc() back, > or are you using very old gcc? Demo: http://coliru.stacked-crooked.com/a/823d838b73d969b4 |
| Daniel <danielaparker@gmail.com>: Sep 10 04:51AM -0700 On Tuesday, September 10, 2019 at 4:04:36 AM UTC-4, Öö Tiib wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437 > > Is it regression so someone had added the _Alloc() back, > > or are you using very old gcc? Sounds plausible, but I'm at a loss to understand how. The builds are being done under travis, and the entries in .travis.yml look like, e.g. - os: linux addons: apt: sources: - ubuntu-toolchain-r-test packages: - g++-8 env: COMPILER=gcc VERSION=8 CXXFLAGS="-std=c++17 > Demo: http://coliru.stacked-crooked.com/a/823d838b73d969b4 But will double check. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 10 08:56AM -0400 On 9/10/19 12:00 AM, Melzzzzz wrote: >> allocator _Alloc()? > Don't know about allocator requirements, but if default constructor is > not one of them it is a bug in gcc... I couldn't find any such requirement. |
| 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