| comp.lang.c++@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
- Instead of writing getter and setter methods, could a g/setter template be used? - 7 Updates
- sscanf and 0x80000000 - 18 Updates
| Richard Damon <Richard@Damon-Family.org>: Oct 31 09:34PM -0700 On 10/31/14, 3:11 PM, Rick C. Hodgin wrote: > I suppose so. It is my first offering. And I am doing this alone. > They tell authors to write what they know. I suppose it works for > developers as well. I suggest you think about Luke 14:28. Yes, a developer should develop with what they know, and aim the extent of their development to what they are comfortable with. It is one thing to develop a tool for your own use, one can be a bit more haphazard in this. When one one puts forth to the world that one is trying to make an improvement on an existing environment, one needs to be sure that one really has the chance to achieve this. (It takes much more than just good intentions). > Are you ready to come on board and help me code this UNICODE support? > Best regards, > Rick C. Hodgin If I had more interest in this project, it might be a possibility. I personally don't see a value in the changes I have heard you wanting to make to the C language. I also am a bit put off by some of your behavior. I think you should consider 1 Peter 2:20, and compare your behavior to whom you claim to follow, and to who exhibited that behavior to. I don't see him getting into the sort of arguments you seem to get into. Consider Luke 18:9 and think you you act more like. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 31 10:43PM -0700 On Saturday, November 1, 2014 12:34:55 AM UTC-4, Richard Damon wrote: > [snip] When I was a younger Christian I used to wonder why these verses were in scripture. They seemed so out of place for a Christian, and a Holy God of Love: http://biblehub.com/revelation/6-10.htm http://biblehub.com/revelation/20-15.htm I do not wonder any more. God has shown me the necessity of what He has done, and is doing. And I am so very thankful for who He is. I am thankful that He is called Faithful and True, and it is in Him I pin all my hopes. The plans He has for my life are His plans, and because He is who He is, I am able to rest confidently there, in that place, secure in the knowledge that He really is in control, and that all of our Earthly struggles are but for a season. I wish you well, Richard. Best regards, Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 31 10:56PM -0700 On Saturday, November 1, 2014 1:44:21 AM UTC-4, Rick C. Hodgin wrote: > http://biblehub.com/revelation/20-15.htm > I do not wonder any more. God has shown me the necessity of what > He has done, and is doing. To be clear about what I mean here, it is a reference to putting away sin and all falseness forever, that those who are in Heaven may dwell with Him forever apart from such things as evil and falseness, in only the goodness He has prepared for His dwelling. There's a line in the movie, The Encounter, when "Nick" asks "Jesus" if He commanded that the Canaanites be killed, to which He replies, "I commanded they kill the Canaanites." "Including women and children?" "Including women and children." "Today we have a word for that: genocide. Is that any way for a God of Love to behave?" "Jesus" goes on to explain, "I am Love. But I am also Holy. And that's not just for my benefit, but for yours as well. Nick, I don't want you to wallow in sin and regret, but to prosper in the plans I've made for you..." http://biblehub.com/proverbs/3-6.htm "6 In all thy ways acknowledge him, and he shall direct thy paths." Continually. Prayerfully. And prayerfully again. > that place, secure in the knowledge that He really is in control, > and that all of our Earthly struggles are but for a season. > I wish you well, Richard. Best regards, Rick C. Hodgin |
| Daniel <danielaparker@gmail.com>: Nov 01 03:34AM -0700 On Saturday, November 1, 2014 1:56:35 AM UTC-4, Rick C. Hodgin wrote: > "I commanded they kill the Canaanites." "Including women and children?" > "Including women and children." "Today we have a word for that: > genocide. Is that any way for a God of Love to behave?" Those are "Old Testament" values, where obedience to a god becomes the motivating factor for killing and enslaving the "others", a modern day example of Old Testament values in Iraq and Syria is isis. It's not a good thing, and thankfully the modern world has moved on, but there are still flickers in the ashes, even in the west the gods are not entirely dead. But they not as powerful as they used to be. Daniel |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 01 03:54AM -0700 On Saturday, November 1, 2014 6:34:49 AM UTC-4, Daniel wrote: > Those are "Old Testament" values, where obedience to a god... > thankfully the modern world has moved on, but... > Daniel God has demonstrated His resolve as a witness to us. He, in the Old Testament, had entire peoples killed. In the days of Noah He destroyed the entire Earth except for eight people. Will He really throw people into Hell forever? Yes. In no uncertain terms yes. It is not His desire that any should perish in Hell, but rather that all would repent and be saved. He came here to make the way for that to happen, and He succeeded. Men and women like me speak about Jesus because, as our Lord desires, we also want people to be saved. It's not for other reasons. Eternity is heading at every one of us. Everybody dies. What happens after we die goes on forever. The warnings that I, and others like me, give are given for that purpose -- so that people will not enter in to that most horrible place. Best regards, Rick C. Hodgin |
| red floyd <no.spam.here@its.invalid>: Nov 01 09:39AM -0700 On 10/31/2014 8:35 AM, Robert Wessel wrote: > Whatever your goals are, setting up extra roadblocks to the use of > your language seems like a bad idea. Especially when they accomplish > so little. What, again, is so horrible about underscores? Will his language also put biblical references into the output? Even if I'm not a member of ANY Christian denomination? |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 01 09:55AM -0700 On Saturday, November 1, 2014 12:39:50 PM UTC-4, red floyd wrote: > Will his language also put biblical references into the output? Even > if I'm not a member of ANY Christian denomination? My license model (public domain, accountable to God): http://www.libsf.org/licenses/ A sample splash screen from my IDE (the cross of love): http://www.visual-freepro.org/images/vjr_054.png I am explicitly a Christian offering this product unto the Lord, and unto men. I am not doing it for other reasons. As such, I convey that through my product. Best regards, Rick C. Hodgin |
| Geoff <geoff@invalid.invalid>: Oct 31 04:55PM -0700 On Fri, 31 Oct 2014 22:43:23 +0100, Marcel Mueller >binary, octal, hex) from a string. The string does not necessarily end >after the number. I did not find format specifier that does the job. >Marcel I like Christopher's solution, stay with C++ instead of C but this would appear to be a bug in gcc 4.8.2. on that version of Linux. The question is, is it a problem in sscanf or in printf? Breakpoint at the printf line and examine the value of i in the debugger, is it -2147483648 or 2147483647? If the former, you have a bug in printf that is supposed to be taking an /unsigned/ i and outputting the hex string. If the latter, then sscanf is interpreting 0x8000000 as -1. |
| Andrew Cooper <amc96@cam.ac.uk>: Nov 01 03:02AM On 31/10/2014 21:43, Marcel Mueller wrote: > could bet that this has been working with %i for many years. > I just tested with gcc 4.8.2 for OS/2 - works with %i. > But with gcc 4.8.2 Linux (Mint 17) the result is the bitwise not. You are presumably on a 32bit system? The unsigned value 0x80000000 is out of range for a 32bit signed integer. > The goal is to read an unsigned number in all common formats (decimal, > binary, octal, hex) from a string. The string does not necessarily end > after the number. I did not find format specifier that does the job. strtoull() is your friend. ~Andrew |
| Geoff <geoff@invalid.invalid>: Oct 31 09:22PM -0700 On Sat, 01 Nov 2014 03:02:52 +0000, Andrew Cooper <amc96@cam.ac.uk> wrote: >> But with gcc 4.8.2 Linux (Mint 17) the result is the bitwise not. >You are presumably on a 32bit system? The unsigned value 0x80000000 is >out of range for a 32bit signed integer. Then why does it work on gcc 4.8.2 for OS/2 and not on Linux? Why does it work on Visual Studio 2010 and LLVM on OSX 10.10? |
| Ian Collins <ian-news@hotmail.com>: Nov 01 05:38PM +1300 Andrew Cooper wrote: >> But with gcc 4.8.2 Linux (Mint 17) the result is the bitwise not. > You are presumably on a 32bit system? The unsigned value 0x80000000 is > out of range for a 32bit signed integer. As it would be on a 64 bit system where the code was compiler for 64 bit. > strtoull() is your friend. It is. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Nov 01 05:45PM +1300 Ian Collins wrote: >> You are presumably on a 32bit system? The unsigned value 0x80000000 is >> out of range for a 32bit signed integer. > As it would be on a 64 bit system where the code was compiler for 64 bit. Oops, not enough 0s to be out of range, I should learn to count. -- Ian Collins |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 01 04:55AM On Fri, 2014-10-31, Christopher Pisz wrote: >>>>> (decimal, binary, octal, hex) from a string. The string does not >>>>> necessarily end after the number. I did not find format specifier >>>>> that does the job. ... > If that is the case use istringstream and operator >> > Just Google c++ streams in general. Much prettier than scanf and printf. I would have used strtoul() and friends instead -- I don't like sscanf(), and I don't like operator >>. > I've found doing format specifiers inside of string literals is just > plain error prone. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Nov 01 08:15AM +0100 On 31.10.14 23.48, Geoff wrote: > To be equivalent to the C code it needs to be > std::cout<< "0x"<< std::hex<< i<< std::endl; This is by far not equivalent. Note that the requirement is to read an unsigned number in all common formats (decimal, binary, octal, hex). Using iostream is on of the last things I would do to parse strings. First I would need to copy each string into a stringstream because the tokenizer returns slices with start/length rather than individual strings. Secondly I need to discover the number basis on my own. With sscanf there is a quite simple pattern: unsigned u; int tmp_len; if (sscanf(line + start, "%i%n", &u, &tmp_len) != 1 && tmp_len != len) throw some error; // got it line points to the start of current line, start and len denote a slice in line. Then I can also write my own parser as Rick suggested. Only for the conversion of digits and the multiplication with the number basis I do not introduce stringstream. Marcel |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Nov 01 08:23AM +0100 On 01.11.14 05.55, Jorgen Grahn wrote: > I would have used strtoul() and friends instead Interesting hint. Any Ideas how to check for parser errors with strtoul? AFAIK it simply stops reading on unparsable input and returns 0 in doubt. Basically I need to check whether strtoul has read exactly all characters in the part of the string that is to be converted. Marcel |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 01 01:44AM -0700 On Saturday, November 1, 2014 3:23:50 AM UTC-4, Marcel Mueller wrote: > Basically I need to check whether strtoul has read exactly all > characters in the part of the string that is to be converted. > Marcel Is there some reason you don't want to write your own? You would then have total control over the conversion, able to report in whatever manner you require. Best regards, Rick C. Hodgin |
| Alain Ketterlin <alain@dpt-info.u-strasbg.fr>: Nov 01 09:57AM +0100 > Interesting hint. > Any Ideas how to check for parser errors with strtoul? AFAIK it simply > stops reading on unparsable input and returns 0 in doubt. and stores a pointer to the first invalid character. See the manual: | unsigned long int strtoul(const char *nptr, char **endptr, int base); | [...] | If endptr is not NULL, strtoul() stores the address of the first | invalid character in *endptr. If there were no digits at all, str‐ | toul() stores the original value of nptr in *endptr (and returns 0). | In particular, if *nptr is not '\0' but **endptr is '\0' on return, the | entire string is valid. -- Alain. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Nov 01 10:15AM +0100 On 01.11.14 09.57, Alain Ketterlin wrote: >> Any Ideas how to check for parser errors with strtoul? AFAIK it simply >> stops reading on unparsable input and returns 0 in doubt. > and stores a pointer to the first invalid character. See the manual: Opps, sorry, for some reason I confusion strtoul with atoul. But the problem with the number basis still exists. Marcel |
| Alain Ketterlin <alain@dpt-info.u-strasbg.fr>: Nov 01 10:52AM +0100 >> and stores a pointer to the first invalid character. See the manual: > Opps, sorry, for some reason I confusion strtoul with atoul. > But the problem with the number basis still exists. What problem? From the man: | The strtoul() function converts the initial part of the string in nptr | to an unsigned long int value according to the given base, which must | be between 2 and 36 inclusive, or be the special value 0. | | The string may begin with an arbitrary amount of white space (as deter‐ | mined by isspace(3)) followed by a single optional '+' or '-' sign. If | base is zero or 16, the string may then include a "0x" prefix, and the | number will be read in base 16; otherwise, a zero base is taken as 10 | (decimal) unless the next character is '0', in which case it is taken | as 8 (octal). -- Alain. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Nov 01 11:14AM +0100 On 01.11.14 09.44, Rick C. Hodgin wrote: > Is there some reason you don't want to write your own? Reinvention of the wheel? I simply could not believe that such simple task is not part of the standard library. > You would > then have total control over the conversion, able to report in > whatever manner you require. In fact I ended up with the following code returning the number of parsed characters: size_t Parser::parseUInt(const char* src, uint32_t& dst) { dst = 0; const char* cp = src; uint32_t basis = 10; uint32_t limit = UINT32_MAX / 10; for (char c; (c = *cp) != 0; ++cp) { uint32_t digit = c - '0'; if (digit >= 10) { digit = toupper(c) - 'A'; if (digit < 6) digit += 10; else { if (dst == 0 && cp - src == 1) switch (c) { case 'b': basis = 2; limit = UINT32_MAX/2; continue; case 'o': basis = 8; limit = UINT32_MAX/8; continue; case 'x': basis = 16; limit = UINT32_MAX/16; continue; case 'd': continue; } break; } } if (dst > limit) break; dst *= basis; if (dst > UINT32_MAX - digit) break; dst += digit; } return cp - src; } Maybe there are more elegant solutions, but at least it seems to work. Marcel |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Nov 01 11:19AM +0100 On 01.11.14 10.52, Alain Ketterlin wrote: >> But the problem with the number basis still exists. > What problem? From the man: The user of a compiler expects to be able to put constants in the for 1234 (decaimal), 0x1234 (hex) as well as octal and binary. If I want to implement this I need to parse the string before strtoul. At that point strtoul does no longer help very much. So I ended up with Rick's suggestion: I wrote my own parser for uint32_t. Marcel |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 01 11:10AM On Sat, 2014-11-01, Marcel Mueller wrote: >> I would have used strtoul() and friends instead > Interesting hint. > Any Ideas how to check for parser errors with strtoul? Yes -- read the documentation. The man page on Linux is very clear on the subject. > AFAIK it simply > stops reading on unparsable input and returns 0 in doubt. You're probably thinking of atoi() or something. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 01 11:33AM On Sat, 2014-11-01, Marcel Mueller wrote: > The user of a compiler expects to be able to put constants in the for > 1234 (decaimal), 0x1234 (hex) as well as octal and binary. If I want to > implement this I need to parse the string before strtoul. You dodge Alain's question, but you're really just saying strtoul() doesn't have support for binary input, right? Decimal, octal and hex are all there. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Alain Ketterlin <alain@dpt-info.u-strasbg.fr>: Nov 01 01:18PM +0100 > In fact I ended up with the following code returning the number of > parsed characters: > size_t Parser::parseUInt(const char* src, uint32_t& dst) [buggy code removed] > Maybe there are more elegant solutions, but at least it seems to work. Have you tried with "0f"? It fails. If you need binary, it is trivial to wrap strtoul to check for leading "0b" (after optional spaces if you need that). I leave it to you do decide whether it is elegant. At least, it will work. -- Alain. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 01 12:34PM >>out of range for a 32bit signed integer. > Then why does it work on gcc 4.8.2 for OS/2 and not on Linux? > Why does it work on Visual Studio 2010 and LLVM on OSX 10.10? When the behaviour is undefined, pretty much anything can happen. If the string scanned represents a value that is out of range for the target type, the behaviour is undefined. (The code then passes an int where printf expects an unsigned int. This, again, is technically undefined, though I image the number of implementations that do anything but the obvious thing is zero.) Many people think of hex numbers as representing bit patterns, but in this context, 0x80000000 just means 2147483648 and that can't be represented in the target type. Storing the maximum positive value seems like a reasonable choice for an implementation, but it is permitted to store whatever it likes. In practice, this behaviour is a property by the library your code is linked with, and the library version is often only very loosely tied to the compiler version. That's the general explanation for why the same compiler produces different result on different systems. -- Ben. |
| 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