| 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. |
- unordered_multimap and equivalent element order - 2 Updates
- Slow std integer to a string conversion (to_string/sprintf) - 2 Updates
- data type class and variable also a class. what does this mean? - 1 Update
- argv - 9 Updates
- sscanf and 0x80000000 - 2 Updates
- C++ name mangling. - 1 Update
- "Polymorphism and Overloading in C++" - 1 Update
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Nov 05 11:10PM +0100 Does unordered_multimap preserve the order of elements /with the same key/? The documentation does not directly answer this question, at least I did not find the answer. But when elements with the same key are stored in the same bucket it should be straight forward to keep the sequence. Marcel |
| Luca Risolia <luca.risolia@linux-projects.org>: Nov 06 12:26AM +0100 Il 05/11/2014 23:10, Marcel Mueller ha scritto: > Does unordered_multimap preserve the order of elements /with the same key/? Rehashing and other operations that internally change the order of elements preserve the relative order of elements with equivalent keys. |
| Luca Risolia <luca.risolia@linux-projects.org>: Nov 04 12:11PM +0100 Martijn Lievaart wrote: > To make it simple, assume 8 bits. std::numeric_limits<unsigned>::digits10 > == 3 => Y should be 1000, but that cannot be represented in 8 bits. (I > know an unsigned cannot be 8 bits, that is not the point). No. Again, this case is not possible. By standard an 8-bit unsigned type cannot have std::numeric_limits<unsigned>::digits10 == 3. A concrete example on my C++ implementation is unsigned char, for which CHAR_BIT is 8 and std::numeric_limits<unsigned char> is 2, as it should be. |
| Martijn Lievaart <m@rtij.nl.invlalid>: Nov 05 11:33PM +0100 On Tue, 04 Nov 2014 12:11:41 +0100, Luca Risolia wrote: > cannot have std::numeric_limits<unsigned>::digits10 == 3. A concrete > example on my C++ implementation is unsigned char, for which CHAR_BIT is > 8 and std::numeric_limits<unsigned char> is 2, as it should be. Brainfart on my part. You are right. M4 |
| "K' Dash" <adnanrashidpk@gmail.com>: Nov 05 10:41AM -0800 Fred K; Thanx. you are a good teacher. :) |
| agent@drrob1.com: Nov 04 07:40PM -0500 On Tue, 04 Nov 2014 15:26:26 -0800, red floyd <no.spam@its.invalid> wrote: >It's not array bounds overflow. The value of argv[argc] is well >defined. It's NULL. The issue the OP is seeing is dereferencing >a NULL pointer. I am trying to access that value of NULL, not dereference it. How do I do that? |
| Ian Collins <ian-news@hotmail.com>: Nov 05 01:43PM +1300 >> a NULL pointer. > I am trying to access that value of NULL, not dereference it. How do > I do that? The value of NULL is NULL. char* ch = argv[argc]; if( ch != nullptr) the_end_of_the_world_is_nigh(); -- Ian Collins |
| agent@drrob1.com: Nov 04 08:05PM -0500 On Wed, 05 Nov 2014 13:43:20 +1300, Ian Collins <ian-news@hotmail.com> wrote: >char* ch = argv[argc]; >if( ch != nullptr) > the_end_of_the_world_is_nigh(); Still not clear to me. NULL pointer has to have a value; I'm assuming it's zero, as that is what gdb showed me. I know I can assign ch='\0' which is the same except for type. Is it possible for me to convert this 0 byte to an int for inspection? I tried atoi and type casting, but I don't understand this well enough yet. |
| Ian Collins <ian-news@hotmail.com>: Nov 05 02:18PM +1300 > Is it possible for me to convert this 0 byte to an int for inspection? > I tried atoi and type casting, but I don't understand this well enough > yet. That's what I did in the test above. There isn't a "0 byte", there is a NULL pointer, a pointer to nothing, a pointer you can't dereference. Maybe the confusion is down to ch being a char*? That's not the same thing as a char with a value of zero. -- Ian Collins |
| Reinhardt Behm <rbehm@hushmail.com>: Nov 05 10:08AM +0800 > Is it possible for me to convert this 0 byte to an int for inspection? > I tried atoi and type casting, but I don't understand this well enough > yet. I think you are mixing up the pointers in argv[] and the value pointed to. Assume you invoke your program name "ab" with parameter "cd" The OS + C-runtime will have setup argc, argv and storage for the values pointed to by argv[] when main() is called Somewhere in memory there is: 'a', 'b', 0, 'c', 'd', 0 These are the values pointed to by argv[] argc has the value 2 argv[0] contain the address of the byte containing 'a' argv[1] contain the address of the byte containing 'c' argv[2] contains a NULL pointer. It points to _nothing_. It might have the bit pattern 0, but the meaning is "points to nothing". argv[argc] is NULL (shown by gdb as 0) argv[argc][0] tries to access that _nothing_ pointed to by argv[2] This gives the segfault. -- Reinhardt |
| Barry Schwarz <schwarzb@dqel.com>: Nov 04 08:35PM -0800 >Still not clear to me. NULL pointer has to have a value; I'm assuming A pointer has to have a value. (Pointers with automatic storage class can be indeterminate but that is not relevant to this discussion.) One of the values a pointer can have is NULL. (Any attempt to dereference a NULL pointer, using either * or -> operators, results in undefined behavior. A seg fault is one of the best manifestations of undefined behavior because it immediately eliminates any delusions that the code is working properly.) >it's zero, as that is what gdb showed me. I know I can assign ch='\0' NULL is a macro that is usually defined in C++ to be 0 (C tolerates other definitions). You can test a pointer to see if its value is NULL with expressions of the form ptr == NULL and ptr != NULL but that does not mean the bits that make up the pointer are all set to 0. You normally don't care what the bit pattern is in a pointer and if you do it is system specific and non-portable. It is the compiler's job to generate the correct code so the two expressions evaluate correctly regardless of the bit pattern. >which is the same except for type. Setting a char to '\0' has nothing to do with the value of a pointer. >Is it possible for me to convert this 0 byte to an int for inspection? You can convert the value of a pointer to an int with the appropriate cast. It might be better to use intptr_t. In any case, I don't think the result is guaranteed to be 0 if the pointer happens to be NULL. But there is no need. The expressions above will always tell you if the value is or is not NULL. >I tried atoi and type casting, but I don't understand this well enough >yet. As noted, there is no need. -- Remove del for email |
| "Osmium" <r124c4u102@comcast.net>: Nov 05 08:55AM -0500 > tough time of it. > To my understanding, the expression argv[argc][0] returns a char. > Why is this wrong? The following link may be helpful, it deals with what I think of as "C magic" Yes it is C but most of it pertains to C++ as well. I particularly had in mind NULL, EOF,stdin, stdout, stderr. EOF, in particular, might well cause you similar problems as you continue the learning process. Keep in mind that C is case sensitive. Also remember there is an ASCII character named NUL or something similar to that, but a different thing. And pervading computer "science" is the *concept* of null, e.g. the last link in a linked list or a tree element without any children. As I post this I have read the answers I can see on my server at 13:50 GMT on Wednesday. http://icecube.wisc.edu/~dglo/c_class/stdio.html |
| Geoff <geoff@invalid.invalid>: Nov 05 08:40AM -0800 >tough time of it. >To my understanding, the expression argv[argc][0] returns a char. >Why is this wrong? It's wrong because the /address of/ argv[argc][0] at that time is NULL. It points to nothing, therefore you can't dereference it. The pointer doesn't just point to a NUL it _is_ NULL. The value of a pointer is the value in memory the pointer points to, the address of the pointer is the address in memory to which it points. C makes it the responsibility of the programmer to make sure his pointers are always valid before he dereferences them. |
| Barry Schwarz <schwarzb@dqel.com>: Nov 05 10:27AM -0800 On Wed, 05 Nov 2014 08:40:00 -0800, Geoff <geoff@invalid.invalid> wrote: >>Why is this wrong? >It's wrong because the /address of/ argv[argc][0] at that time is >NULL. It points to nothing, therefore you can't dereference it. Surely you meant the address in argv[argc]. >The pointer doesn't just point to a NUL it _is_ NULL. >The value of a pointer is the value in memory the pointer points to, The value of a pointer is the address of the memory it points to except when the value is NULL since in that case it doesn't point to memory at all. The value pointed to can be obtained by dereferencing the pointer (applying the [0] operator to the pointer achieves this) but this is only valid if the pointer actually points to memory. >the address of the pointer is the address in memory to which it >points. The address of a pointer is the address in memory that the pointer occupies. It is obtained by applying the & operator to the pointer name. -- Remove del for email |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 05 07:05AM On Mon, 2014-11-03, Paavo Helde wrote: >> Is the preference due to performance, plain hatred of streams, or >> something else? > The former. Among other things. strtofoo() has a simple, general interface, so if you know how to use them, you can use them everywhere. The only problem I've had is that they need a '\0'-terminated string. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| peter koch <peter.koch.larsen@gmail.com>: Nov 05 06:58AM -0800 Den onsdag den 5. november 2014 08.05.39 UTC+1 skrev Jorgen Grahn: > Among other things. strtofoo() has a simple, general interface, so if > you know how to use them, you can use them everywhere. > The only problem I've had is that they need a '\0'-terminated string. I must admit that I also like iostreams. The concept is fine even if performance might stink. But then conversion to/from string do not occur in any performance sensitive parts of my code. boost::lexical_cast does have very nice performance for the trivial stuff, by the way. My dislike of strtoX functions is that they do not fit well with templates, that they are restricted to conversion from char* and that they have a to C-like interface. /Peter |
| "Erdoeban Zsukloff zu Brecher Zhuang" <no@contact.com>: Oct 31 11:56PM -0400 >"Truth" wrote in message news:m2gkjs$ab9$1@speranza.aioe.org... On 10/24/2014 10:44 AM, Paavo Helde wrote: > these people. And of course, the irony is these people never even > recognize this trait. > Watch and listen. Here it comes now. I find rather repulsive when a legitimate prima facie technical question is met with derision expressed by "Why do you care?", especially on open forum. That said, sometimes this very question - "Why do you care?" - does not bear derisive emotional load, and is a genuine interest in the subject . --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| see.my.homepage@gmail.com: Nov 04 12:28AM -0800 > "A reader sent me an interesting question the other day. They asked if polymorphism and overloading were essentially the same thing." > "My initial reaction was Huh?" They are very closely related and in some contexts might be equivalent. For the sake of mental exercise imagine that there is no distinction between "member functions" and "non-member functions" - that is, all functions are defined outside of the class and the "this" parameter is not implicit, but explicit. So, instead of this: class MyClass { public: void foo(int i) { /* ... */ } private: /* data fields */ }; you would have this: class MyClass { /* data fields */ }; void foo(MyClass & this, int i) { // ... } (you can replace "this" with "self" or some other name, if "this" seems uncomfortable) Now, create some simple hierarchy (Shape, Circle, Triangle, etc.) and rewrite it as above and compare all function signatures - see how close is the relation between polymorphism and overloading. If you think that the difference is in static vs. dynamic resolution (this would be convincing in C++ and would explain the "virtual" nature of the function dispatch), then as the next step imagine that this is a scripting language where everything is dynamic anyway and is always based on the dynamic type of all actual parameters. Now, where's the difference? ;-) Note that in some literature templates are also considered to be a kind of polymorphism, which then becomes a very broad concept that can be shortly explained as: the ability of the code to work with data of different types. -- Maciej Sobczak * http://www.inspirel.com |
| 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