| 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. |
- Peculiar g++ warning ?? - 2 Updates
- Slow std integer to a string conversion (to_string/sprintf) - 9 Updates
- difference - 1 Update
- difference - 6 Updates
| David Brown <david.brown@hesbynett.no>: Nov 02 11:29PM +0100 On 31/10/14 22:18, Rick C. Hodgin wrote: >>>> Re-consider it - you don't want the same expression to mean different >>>> things when it is written alone, or part of another statement. >>> David, what does *tnX++; mean when used by itself? "Nobody" gave a good answer here - my comments are near the end. > optimization mode (where one would expect it to be generated if any > were to be generated). > To me, that non-generation is telling. What it is telling you is that on its own, "*tnX++" has no effect unless there is a "volatile" somewhere. Since tnX is a value parameter, any changes made to it are not passed back to the caller - they are discarded. Therefore the compiler doesn't have to generate any code for it in the first place. Similarly, the "*tnX" bit requests a read of the value pointed at by tnX - but since that value is not read (and the access is not volatile), the compiler can ignore that too. Thus the compiler can figure out that the statement does nothing at all, and generates no code. (It is free to do this regardless of optimisation settings - optimisation settings are merely a hint.) |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 02 02:43PM -0800 On Sunday, November 2, 2014 5:29:46 PM UTC-5, David Brown wrote: > compiler can figure out that the statement does nothing at all, and > generates no code. (It is free to do this regardless of optimisation > settings - optimisation settings are merely a hint.) My point in my original reply to you was this: What is it doing? Nothing. Nobody indicated it would do something when volatile, to which I wrote a lengthy reply which can be summed up with this brief snippet: "Seriously? Somebody was use THAT feature to affect something in main memory? Sounds like it needs refactoring severely." Since *tnX++; by itself has no purpose, and arguably no purpose even under the volatile constraint, I see no reason not to have it work in the same way as ++*tnX, but it would just use the nicer syntax as *tnX++; looks nice, and ++*tnX; doesn't. :-) I'm still considering if I will support it to mean this form. I can see myself using that form in code from time to time. Best regards, Rick C. Hodgin |
| JiiPee <no@notvalid.com>: Nov 02 04:03PM On 02/11/2014 14:48, Ben Bacarisse wrote: >>> *(short*)(c-1)=*(short*)(digit_pairs+2*pos); >>> c-=2; > <snip> Can you show me exatcly what you changed so I can test that version here? |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 02 10:21AM -0600 >>>> c-=2; >> <snip> > Can you show me exatcly what you changed so I can test that version here? Probably something like // *(short*)(c-1)=*(short*)(digit_pairs+2*pos); *(c-1) = digit_pairs[2*pos]; *c = digit_pairs[2*pos+1]; |
| JiiPee <no@notvalid.com>: Nov 02 04:34PM On 02/11/2014 16:21, Paavo Helde wrote: > *(c-1) = digit_pairs[2*pos]; > *c = digit_pairs[2*pos+1]; that does not make intToStr any slower |
| JiiPee <no@notvalid.com>: Nov 02 04:41PM On 02/11/2014 12:21, Jouko Koski wrote: > actually. It is so easy to implement a function which simple, fast, > and produces incorrect results. It is so obvious that 1234 should > yield "1234" but what if the result, say, "१२३४" would be preferred? If I want to convert 1234 to a string, why would I want it to be "१२३४"? :) I guess you are talking about other languages.. but even then, we could limit this proglem to europian 123344 representation. |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 02 11:09AM -0600 >> *(c-1) = digit_pairs[2*pos]; >> *c = digit_pairs[2*pos+1]; > that does not make intToStr any slower Yes, that's the point. There was no need to mess around with short* casting. Cheers Paavo |
| Christian Gollwitzer <auriocus@gmx.de>: Nov 02 06:21PM +0100 Am 02.11.14 13:06, schrieb Jorgen Grahn: > I was going to say "sprintf() seems unlikely to be one of those > functions", but gcc apparently has it as a builtin. No idea why > though -- the documentation doesn't say. GCC can issue warnings when the format string and the actual parameters mismatch. I don't know if this just onlyissues the warning or gnerates static calls (which it could). Too lazy to check the assembly right now. Christian |
| "Jouko Koski" <joukokoskispam101@netti.fi>: Nov 02 07:48PM +0200 "JiiPee" wrote: > If I want to convert 1234 to a string, why would I want it to be "१२३४"? > :) I guess you are talking about other languages.. but even then, we could > limit this proglem to europian 123344 representation. Yes, I mean locales, or even different character encodings used by terminal devices. Standard library functions generally take these into account while most "fast" functions do not. Limiting this to Western number representation sounds as myopic as an insular Yankee insisting that everybody should be fine with 7-bit ascii encoding. -- Jouko |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 02 07:24PM > // *(short*)(c-1)=*(short*)(digit_pairs+2*pos); > *(c-1) = digit_pairs[2*pos]; > *c = digit_pairs[2*pos+1]; Yes, something like or maybe even exactly like that! -- Ben. |
| JiiPee <no@notvalid.com>: Nov 02 09:51PM On 02/11/2014 17:48, Jouko Koski wrote: > Limiting this to Western number representation sounds as myopic as an > insular Yankee insisting that everybody should be fine with 7-bit > ascii encoding. can put both in code: when normal characters, then use the fast one, otherwise the std one. |
| ram@zedat.fu-berlin.de (Stefan Ram): Nov 02 07:44PM >>Mac48Address* Mac; >It declares mutable variable 'Mac' of type 'Mac48Address*' that is raw >pointer to 'Mac48Address'. I think it depends on the context. When it appears in a struct specifier, it might declare a class member instead of a variable. (I would not go so far as to now consider the possibility that it might appear within a comment or at a place where it is forbidden ...) |
| "K' Dash" <adnanrashidpk@gmail.com>: Nov 02 10:32AM -0800 Still I am unable to understand that what you guys are saying. You guys discussing with each other instead of teaching me. :) see this link, http://www.nsnam.org/docs/release/3.21/doxygen/ptr_8h_source.html when I click (by using eclipse IDE) on Ptr<Mac48Address> Mac; it showed me the "class Ptr " at line number 60. you can see this class from above link. generic command is Ptr<classname> variable; so don't confuse yourself with Mac48Address. Now please tell me what is the difference between Mac48Address* Mac; and Ptr<Mac48Address> Mac; where Mac48Address is a class name |
| Melzzzzz <mel@zzzzz.com>: Nov 02 07:34PM +0100 On Sun, 2 Nov 2014 10:32:12 -0800 (PST) > and > Ptr<Mac48Address> Mac; > where Mac48Address is a class name First you tell me what is a difference between int* v and Ptr<int> v? -- Manjaro all the way! http://manjaro.org/ |
| "K' Dash" <adnanrashidpk@gmail.com>: Nov 02 10:36AM -0800 I don't know. :( |
| "K' Dash" <adnanrashidpk@gmail.com>: Nov 02 10:38AM -0800 int* v; v is a pointer and we can use this "v" to assign the address of int variables only. but i dont know the other thing. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 02 06:50PM On Sun, 2014-11-02, K' Dash wrote: > Still I am unable to understand that what you guys are saying. You > guys discussing with each other instead of teaching me. :) That's what we do best these days. > and > Ptr<Mac48Address> Mac; > where Mac48Address is a class name Ignore that line 60. If you look deeper in that Doxygen-generated documentation, you find: template<typename T> class ns3::Ptr< T > smart pointer class similar to boost::intrusive_ptr This smart-pointer class assumes that the underlying type provides a pair of Ref and Unref methods which are expected to increment and decrement the internal refcount of the object instance. This implementation allows you to manipulate the smart pointer as if it was a normal pointer: you can compare it with zero, compare it against other pointers, assign zero to it, etc. ... I'm not very familiar with smart pointers so I might be missing something, but this documentation seems rather poor. Am I supposed to read the documentation for boost::intrusive_ptr to understand what ns3::Ptr does? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: Nov 02 11:24AM -0800 On Sunday, 2 November 2014 20:32:25 UTC+2, K' Dash wrote: > Still I am unable to understand that what you guys are saying. You > guys discussing with each other instead of teaching me. :) Perhaps you are under necessary level of grasp of the matter so whatever answer you get you are unable to understand it? > so don't confuse yourself with Mac48Address. Now please tell me what is > the difference between > Mac48Address* Mac; It declares mutable variable 'Mac' of type 'Mac48Address*' that is raw pointer to 'Mac48Address'. > and > Ptr<Mac48Address> Mac; It declares mutable variable 'Mac' of type 'Ptr<Mac48Address>' that is class template 'Ptr' instantiated with type 'Mac48Address'. > where Mac48Address is a class name I am not sure what you expect us to tell is "different" and what you assume is "common" there. |
| 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