- reference of type 'unsigned char*&' from an rvalue of type 'unsigned char*' - 13 Updates
- X operator=(const &X) - 3 Updates
- Initializer clauses as arguments - 1 Update
- implementation of daemon thread - 2 Updates
- Tutorial on threaded binary tree part 1: simple unthreaded tree - 1 Update
- Random Device initialization is platform dependant? - 1 Update
| Popping mad <rainbow@colition.gov>: Dec 10 05:55AM Hello I'm getting this error message reference of type 'unsigned char*&' from an rvalue of type 'unsigned char*' and I'm not sure exactly what it is trying to tell me. unsigned char * & t(){ return t_ //4 byte type }; and t is defined unsigned char t_[4]; |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 10 07:38AM +0100 On 10.12.2016 06:55, Popping mad wrote: > }; > and t is defined > unsigned char t_[4]; Post a complete and minimal example that readers can try. At a guess both the "t" and the missing semicolon are mistakes you made by typing the code and description manually. Copy and paste. |
| Nobody <nobody@nowhere.invalid>: Dec 10 06:42AM On Sat, 10 Dec 2016 05:55:58 +0000, Popping mad wrote: > }; > and t is defined > unsigned char t_[4]; t_ isn't a pointer, it's an array. It decays to a pointer when used as an rvalue, but you can't return a mutable (non-const) reference to an rvalue. You can return a const reference, but the compiler will (reasonably) warn you that you're returning a reference to a temporary. I suggest simply returning the pointer. What's the point of returning a reference here? |
| ruben safir <ruben@mrbrklyn.com>: Dec 10 11:15AM -0500 On 12/10/2016 01:42 AM, Nobody wrote: > I suggest simply returning the pointer. What's the point of returning a > reference here? to use it as an lvalue |
| "Öö Tiib" <ootiib@hot.ee>: Dec 10 09:10AM -0800 On Saturday, 10 December 2016 18:15:17 UTC+2, ruben safir wrote: > > I suggest simply returning the pointer. What's the point of returning a > > reference here? > to use it as an lvalue From where you took an idea that you can use array as pointer lvalue? It feels that you initially wanted to do something like that: unsigned char t_[4]; ++t_; // can't do that And then you wanted to "fix" it like that: unsigned char t_[4]; unsigned char*& t = t_; // can't do that either ++t; And now you are unsure what it is trying to tell you. |
| Popping mad <rainbow@colition.gov>: Dec 10 05:53PM On Sat, 10 Dec 2016 09:10:36 -0800, Öö Tiib wrote: > It feels that you initially wanted to do something like that: > unsigned char t_[4]; > ++t_; // can't do that not really more like t()[3] = value; |
| Popping mad <rainbow@colition.gov>: Dec 10 06:03PM On Sat, 10 Dec 2016 09:10:36 -0800, Öö Tiib wrote: > It feels that you initially wanted to do something like that: > unsigned char t_[4]; > ++t_; // can't do that I have a more fundamental question that actually I was trying to figure out that brought me to that idiom. This should clarify the problem What is the difference between these two statements unsigned char * &index(unsigned char * value){ index_ = value; return index_; }; and without the reference: unsigned char * index(unsigned char * value){ index_ = value; return index_; }; |
| Popping mad <rainbow@colition.gov>: Dec 10 06:04PM On Sat, 10 Dec 2016 06:42:39 +0000, Nobody wrote: > mutable (non-const) reference to an rvalue. You can return a const > reference, but the compiler will (reasonably) warn you that you're > returning a reference to a temporary. spot on, I understand. |
| Popping mad <rainbow@colition.gov>: Dec 10 06:07PM On Sat, 10 Dec 2016 17:53:32 +0000, Popping mad wrote: > not really > more like > t()[3] = value; or *t() = value; t() is not a class so I can not overload it the ++ operator |
| "Öö Tiib" <ootiib@hot.ee>: Dec 10 10:48AM -0800 On Saturday, 10 December 2016 20:07:44 UTC+2, Popping mad wrote: > or > *t() = value; > t() is not a class so I can not overload it the ++ operator You need reference to pointer for neither. You can return just pointer and it works on both cases: unsigned char t_[4]; unsigned char* t = t_; // can't do that either t[3] = 5; *t = 42; |
| Paavo Helde <myfirstname@osa.pri.ee>: Dec 10 09:58PM +0200 On 10.12.2016 20:03, Popping mad wrote: > index_ = value; > return index_; > }; Assuming that these are member functions of some class: One returns a mutable reference to the inners of the class - this in general smells bad design, as it breaks encapsulation. The other returns a copy of a raw pointer value held by the class - this smells a bit less bad, but not good either, raw pointers should in general appear only in very low-level class interfaces. |
| Popping mad <rainbow@colition.gov>: Dec 10 09:21PM On Sat, 10 Dec 2016 21:58:05 +0200, Paavo Helde wrote: > One returns a mutable reference to the inners of the class - this in > general smells bad design, as it breaks encapsulation. good thing for the rest of us, then, that you weren't in charge of the design committee since encapsulation doesn't have much value of you can't manipulate things. |
| Jerry Stuckle <jstucklex@attglobal.net>: Dec 10 05:39PM -0500 On 12/10/2016 4:21 PM, Popping mad wrote: > good thing for the rest of us, then, that you weren't in charge of the > design committee since encapsulation doesn't have much value of you can't > manipulate things. No, Paavo is correct. It breaks encapsulation and smells of a bad design. The purpose of encapsulation is to ensure the integrity of the object. The object should either always be valid or reject operations that use an invalid object. If you return a reference to a private or protected member, that is the same as making the member public. It violates the concept of encapsulation and there is no longer a way to ensure the validity of the object. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| ruben safir <ruben@mrbrklyn.com>: Dec 10 11:17AM -0500 On 12/09/2016 03:37 AM, Ralf Goertz wrote: > X(const int &cr_) : cr(cr_),var(0) {} what is this? |
| "Öö Tiib" <ootiib@hot.ee>: Dec 10 09:13AM -0800 On Saturday, 10 December 2016 18:17:54 UTC+2, ruben safir wrote: > On 12/09/2016 03:37 AM, Ralf Goertz wrote: > > X(const int &cr_) : cr(cr_),var(0) {} > what is this? It is called implicit conversion constructor from int to X. Experienced C++ programmers tend to avoid implicit conversions like the plague. |
| Richard Damon <Richard@Damon-Family.org>: Dec 10 04:41PM -0500 On 12/9/16 5:09 AM, Ralf Goertz wrote: >> } > Thanks, that seems to work. Do I need to worry about memory leakage > since I use new without delete? Since you are using placement new, it isn't going to create a memory leak, as placement new doesn't itself allocate any memory. Note, that this is an old hack for reseating a reference, and one with a number of know dangers. First, you need to check for self assignment, that will blow up with your code. Second, you may never derive a class from X now (or at least any class derived from X can't chain to this operator=, unlike the normal, and default, assignment operators). |
| ram@zedat.fu-berlin.de (Stefan Ram): Dec 10 05:09PM >int main(){ ::std::cout << ::std::floor( { 2.0 } )<< "\n"s; } >main.cpp:8:48: error: call of overloaded 'floor(<brace-enclosed initializer list>)' is ambiguous Ok, so, I was, like, totally confused. What I wanted to show was this: ::std::cout << ::std::isalpha( 64.9 ) 0 ::std::cout << ::std::isalpha( { 64.9 } ) error: narrowing conversion . But I confused double-to-int with int-to-double when I used »floor« in my previous post. Still, it is interesting that ::std::cout << ::std::floor( 2.0 ) 2 ::std::cout << ::std::floor( { 2.0 } ) 2 warning: braces around scalar initializer . Why do I get a warning from some programs, when the braces make perfect sense to express my intention to forbid narrowing? And then, ::std::cout << ::std::floor( 2 ) 2 ::std::cout << ::std::floor( { 2 } ) errror: call of overloaded 'floor(<initializer list>)' is ambiguous . I am not sure whether I know all of the details that would have allowed me to predict this error message. In C++03, IIRC, ::std::floor( 2 ) alone was ambiguous. They then changed some wording to make it non-ambiguous, but this might apply only to the case without the initializer list. |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Dec 09 10:19PM -0800 so,what should i do in this scenario |
| Paavo Helde <myfirstname@osa.pri.ee>: Dec 10 09:26AM +0200 On 10.12.2016 8:19, kushal bhattacharya wrote: > so,what should i do in this scenario Fix the bugs in the code, obviously. Any time your app crashes, there is a bug somewhere, and with a probability of at least 99.999% it is a bug created by yourself. |
| Tim Rentsch <txr@alumni.caltech.edu>: Dec 09 10:05PM -0800 > There's no attempt at balancing, so this code does not deal nicely > with sorted input in the big O sense. Random input is the thing > here. I used the digits of pi. I'm wondering if/when you might show a version with threaded trees and/or balancing. The iterative algorithm for AVL trees is somewhat tricky. Combining that with threaded leaves is trickier still. I was able to do a recursive AVL-like insertion fairly easily (with nodes having an explicit height field) but a more traditional iterative algorithm proved to be more difficult. |
| Tim Rentsch <txr@alumni.caltech.edu>: Dec 09 09:57PM -0800 > [...] > I recommend Knuth's "The Art of Computer Programming", I think it > was vol I. [on random number generators] The chapter on random numbers is in TAOCP vol. II, "Seminumerical Algorithms". But vol. I does discuss threaded trees. :) |
| 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