Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

reference of type ‘unsigned char*&’ from an rvalue of type ‘unsigned char*’

48 views
Skip to first unread message

Popping mad

unread,
Dec 10, 2016, 12:56:07 AM12/10/16
to
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

unread,
Dec 10, 2016, 1:41:36 AM12/10/16
to
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

unread,
Dec 10, 2016, 1:42:48 AM12/10/16
to
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

unread,
Dec 10, 2016, 11:15:17 AM12/10/16
to
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

unread,
Dec 10, 2016, 12:10:57 PM12/10/16
to
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

unread,
Dec 10, 2016, 12:53:40 PM12/10/16
to
On Sat, 10 Dec 2016 09:10:36 -0800, Öö Tiib wrote:


>> 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

not really

more like

t()[3] = value;

Popping mad

unread,
Dec 10, 2016, 1:03:18 PM12/10/16
to
On Sat, 10 Dec 2016 09:10:36 -0800, Öö Tiib wrote:


>> 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

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

unread,
Dec 10, 2016, 1:04:35 PM12/10/16
to
On Sat, 10 Dec 2016 06:42:39 +0000, Nobody wrote:


> 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.

spot on, I understand.

Popping mad

unread,
Dec 10, 2016, 1:07:44 PM12/10/16
to
or

*t() = value;

t() is not a class so I can not overload it the ++ operator

Öö Tiib

unread,
Dec 10, 2016, 1:48:29 PM12/10/16
to
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

unread,
Dec 10, 2016, 2:58:14 PM12/10/16
to
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

unread,
Dec 10, 2016, 4:21:17 PM12/10/16
to
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

unread,
Dec 10, 2016, 5:39:50 PM12/10/16
to
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
jstu...@attglobal.net
==================

ruben safir

unread,
Dec 10, 2016, 8:06:08 PM12/10/16
to
On 12/10/2016 01:48 PM, Öö Tiib wrote:
> unsigned char* t = t_; // can't do that either


right, hence the error message

ruben safir

unread,
Dec 10, 2016, 8:06:56 PM12/10/16
to
On 12/10/2016 05:39 PM, Jerry Stuckle wrote:
> No, Paavo is correct. It breaks encapsulation and smells of a bad design

not really, but I'm sick of discussing that since 1998 when Java came
out with the mantra of OO design.

ruben safir

unread,
Dec 10, 2016, 8:15:47 PM12/10/16
to
On 12/10/2016 05:39 PM, Jerry Stuckle wrote:
> The purpose of encapsulation is to ensure the integrity of the object.

The purpose is to make a coherent API. You do not always want to
prevent access to private data and to only pass data by value,
especially if it s a lot of data in big memory heaps.

Then I might want to assign big data to a reference to an internal
pointer to a new heap object.

ruben safir

unread,
Dec 10, 2016, 8:21:49 PM12/10/16
to
On 12/10/2016 05:39 PM, Jerry Stuckle wrote:
> and smells of a bad design.


I think that what bothers me here is this. Designs don't smell and that
Axiomatic jargon that a cadre of young coders learned when Sun pushed
Java on them in the late 1990's was wrong.

The first purpose of OO coding is to create easy to debug, maintainable
and documentable code. It is about the human coders. the computer
software could care less. It is about project management and development.

ruben safir

unread,
Dec 10, 2016, 8:22:49 PM12/10/16
to
On 12/10/2016 05:39 PM, Jerry Stuckle wrote:
> No, Paavo is correct.

he is not even on the topic.

Paavo Helde

unread,
Dec 11, 2016, 3:16:15 AM12/11/16
to
On 11.12.2016 3:15, ruben safir wrote:
> On 12/10/2016 05:39 PM, Jerry Stuckle wrote:
>> The purpose of encapsulation is to ensure the integrity of the object.
>
> The purpose is to make a coherent API. You do not always want to
> prevent access to private data

Agreed. It seems you have overlooked the words "in general" in my
previous post. There are exceptions to any rules.


ruben safir

unread,
Dec 11, 2016, 4:09:38 AM12/11/16
to
On 12/11/2016 03:16 AM, Paavo Helde wrote:
> Agreed. It seems you have overlooked the words "in general" in my
> previous post.


wow - you don't read that often on usenet ;)

Jerry Stuckle

unread,
Dec 11, 2016, 10:35:42 AM12/11/16
to
Maybe people keep discussing it because they are right and you are
wrong. You obviously do not understand encapsulation.

Maybe you should be going back to SmallTalk in the 80's. Those people
understood (and still do) proper OOD. It is more than just "making a
coherent API". It is also preventing bugs by ensuring the object is
always valid - or doesn't allow operations on invalid objects.

You can assign to any private member in an object. But to do it
correctly you need to validate the value being assigned. And that can't
be done by returning a reference to a private member.

Jerry Stuckle

unread,
Dec 11, 2016, 10:38:16 AM12/11/16
to
Oh, yes, some designs do smell. And some just plain stink. And perhaps
programmers at Sun know more about OO than you do.

Yes, OO is in part about creating easy to debug, maintainable and
documentable code. But that can be done in any language.

OO is mainly about producing code with fewer bugs.

Jerry Stuckle

unread,
Dec 11, 2016, 10:39:08 AM12/11/16
to
He is correct. As was Sun, as was Stroustrup, and as are those Java
programmers who have tried to tell you the same.

Popping mad

unread,
Dec 12, 2016, 10:11:15 AM12/12/16
to
On Sun, 11 Dec 2016 10:35:23 -0500, Jerry Stuckle wrote:

> Maybe people keep discussing it because they are right and you are
> wrong.
> You obviously do not understand encapsulation.



your right.

Popping mad

unread,
Dec 12, 2016, 10:13:29 AM12/12/16
to
On Sun, 11 Dec 2016 10:39:02 -0500, Jerry Stuckle wrote:

> He is correct. As was Sun, as was Stroustrup,

Stroustrup is barely understandable and Java is crap,

Its not that they are right. They were never right and the move away
from the paradigm has been extensive because it is too restrictive to
produce consistent APIS


And your off topic

Popping mad

unread,
Dec 12, 2016, 10:15:10 AM12/12/16
to
On Sun, 11 Dec 2016 10:38:09 -0500, Jerry Stuckle wrote:

> Oh, yes, some designs do smell. And some just plain stink. And perhaps
> programmers at Sun know more about OO than you do.
>
> Yes, OO is in part about creating easy to debug, maintainable and
> documentable code. But that can be done in any language.
>
> OO is mainly about producing code with fewer bugs.



Hahahaha

well that is a failure

OK we end this now. /dev/null
argue with the back of the hand

Jerry Stuckle

unread,
Dec 12, 2016, 1:26:26 PM12/12/16
to
Not really. Good OO programmers typically have fewer bugs than good
non-OO programmers, for a number of reasons.

The biggest one is encapsulation and message passing isolates code,
which can then be tested for correct operation as a unit (and anything
that it depends on can be tested before this class).

It also allows bad data to be rejected at the time someone tries to set
it, not perhaps thousands of lines later when someone tries to use that
code. For instance, if you're looking at a Person object with an Age
member, you can test to ensure it is less than some value such as 120
years (the oldest person in the world is, I believe, around 116).

And inheritance and polymorphism allow for the reuse of existing code,
which supposedly has been tested and debugged already. This allows for
faster code development and fewer errors because people aren't
reinventing the wheel all the time.

Everyone makes mistakes, no matter what the language, and the number of
initial errors per LOC doesn't vary much with the language (although it
varies wildly with how good the design, if any, is). But OO allows more
bugs to be caught earlier in the development and testing cycle.

But if you just code "on the fly", with no testing other than "it
compiled", then no, you won't have fewer bugs in your code.

It all depends on the programmer, the design and the development/test
process.

Jerry Stuckle

unread,
Dec 12, 2016, 1:29:02 PM12/12/16
to
On 12/12/2016 10:13 AM, Popping mad wrote:
> On Sun, 11 Dec 2016 10:39:02 -0500, Jerry Stuckle wrote:
>
>> He is correct. As was Sun, as was Stroustrup,
>
> Stroustrup is barely understandable and Java is crap,
>

Stroustrup is quote understandable. And Java is a great language for
its use.

> Its not that they are right. They were never right and the move away
> from the paradigm has been extensive because it is too restrictive to
> produce consistent APIS
>

They were quite correct. And it is quite easy to produce consistent
APIs. You just need a good design and a programmer who isn't lazy.

>
> And your off topic
>

The use of encapsulation in a C++ program is quite on target for this
newsgroup.

>
>> and as are those Java
>> programmers who have tried to tell you the same.
>

Perhaps the experts and millions of other programmers know more than you
- and are more correct than you.
0 new messages