Constrained Forwarding(R-Value Reference) - C++ language, library and standards

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Constrained Forwarding(R-Value Reference)
Goto page Previous 1, 2, 3, 4 Next

C++Talk.NET Forum Index -> C++ language, library and standards

View previous topic :: View next topic

Author

Message

Grizlyk
Guest

Posted: Fri Mar 16, 2007 7:21 pm Post subject: Re: Constrained Forwarding(R-Value Reference)

Howard Hinnant wrote:

Quote:

In general. if anyone really want find answer (unknown to him), I think, he
is forced to answer on _each_ opposite argument in essence. There are no
other way of searching (at least i do not know other way).

Quote:

From practical life i know, that often refusing to do it (answering)
speaking only about absence of desire to obtain any answer disagreeing with

predefined wanted result, because "i do not need", "i do not want" and other
the same reasons.

In the concrete accident of auto_ptr implemented with "rvalue reference" i
can only repeat my previuos 6 arguments, because i do not know what part of
the arguments (for each concrete problem) has been rejected by you.

Also you can read my message in the thread from 15.03.07 with words: "One
can see the steps of "moveable concept" appearence". The message "in short
form" describes problems of auto_ptr implementation and problems of moveable
support in the language as C++. More detailed explanaitions can be found on
my page http://grizlyk1.narod.ru/cpp_new articles #11-#15.

Quote:

I recently wrote to another forum what I perceive as the major problem
with our current auto_ptr and why it needs to be replaced. I am
repeating that text here to answer why I believe auto_ptr needs a new
name:

My problem with auto_ptr stems from its use as a value_type in
sequence-modifying (user-written) generic code. The fear stems from
early implementations of std::sort, but I think the same type of problem
could occur in other sequence modifying algorithms:

template<class RandomAccessIterator, class Compare
void
sort(RandomAccessIterator first, RandomAccessIterator last, Compare comp)
{
...
// choose a partition element with RandomAccessIterator i
// and store it in a local
value_type median = *i;

What is problem? There is no any "move" in the expression. Also there is
pointer here.

Quote:

// Now partition sequence with respect to median
...
// median never assigned back into the range.
// Why would I? *i is still there!
}

Now when you call this with say:

std::auto_ptr<int> my_array[10];
.
std::sort(my_array, my_array+10, indirect_less<int>());

then you are likely to get a run time error (i.e. a crash). The cause
of the problem is that when the generic code author writes:

value_type median = *i;

he's thinking *copy*.
*i should remain unchanged in his mind.

And he is absolutely right, because moveable can not be compiled here,
because copy ctor is private in this context for any moveable.

Can we write like this?

moveable value_type median = *i;

It is depended, for example, from RandomAccessIterator declaration.

It is really very hard to anybody to learn more about "moveable" and
"compile time attributes" considering the complex examples with "references
to moveable" and "interactions of copyable and moveable". See my page
http://grizlyk1.narod.ru/cpp_new articles #11-#15 to learn about all of
these in "step by step" mode.

Take in account, the syntax on the page is still "draft of first proposal",
so in general it is correct and will remain unchanged, but some little (i
hope little) details can be undefined.

After reading the page you can easy write the following example yourself.

RandomAccessIterator is a kind of pointer to walk over container, if we will
make the pointer as wrapper, we can increase compile time control of the
data hidden by the interator (increase only for each step).

The possible declarations of moveable:

moveable T& RandomAccessIterator::operator*();
T::T(const moveable T&);

But this is incompatible with "T(*i)", because skipped attributes (skipped
because the are chiefly will be the same for all classes) of moveable
references is incompatible.

With explicitly declared default attributes declarations the previous
declarations will be:

moveable T& Sad

...;same) RandomAccessIterator::operator*();
T::T(const moveable T&:(ctor;dtor));

it is means "T(*i)" can not be compiled:

+ *i returns undefined attribute "..." //ok
+ "..." compared with "ctor" befor "move ctor" called //ok
and "same" is assigned to "ctor" //ok
- "same" compared with "dtor" after "move ctor" called //error
= can not compile

Now we can write to make "move" like this:

moveable T T::operator< ()const dtor;
moveable value_type median = <*i;

Quote:

But when
the type of *i is auto_ptr, then sort's author's assumptions are
incorrect.

If auto_ptr will be decared as "only moveable", the code can not be
compiled. As i can see, the example does not deny usage of correct declared
auto_ptr.

Do you want to say, that there are differences between copyable and moveable
in algorithms?

It is evidently, that moveable data type is more limited than copyable one.
You must use _special_ algorithms to support moveable.

For already existing code you probably will be forced to re-design _core_ of
your algorithms. It is not enough only to redeclare all parameters as
"moveable".

It is the same as if you will add to C++ "const" keyword and for old code
without the "const" support will try just redeclare all data as "const". It
will not work and good compiler must detect the kind of errors appered
together with new "moveable" or "const" keyword.

This is example of simplest differences of copyable and moveable core of
algorithms:

template<class T>
void foo(const T t)
{
...
const T tmp1(t);
...
const T tmp2(t);
};

template<class T>
void foo(const moveable T t)
{
...
const moveable T tmp1(t);
...
const moveable T tmp2(tmp1);
};

Quote:

So who's wrong? The author of the generic code for believing that:

value_type median = *i;

is a copy? Or is the author of type who allows a mutating copy from an
lvalue wrong?

I think the fact that (*i) is lvalue (has allocated memory and its address
can be taken) out of the question scope.

Also we no need any "mutating copy" definitions, we need only "moveable" and
"copyable" definition, so here wrong are:
- user, who pass moveable into template developed only for copyable
- C++, in which developer can not clear express what he want to do

Quote:

My belief is the latter. So "fixing auto_ptr" would involve changing it
such that:

value_type median = *i;

causes a compile time error (to prevent the run time error in the
generic code). In non-generic code, this means that:

auto_ptr<A> p1;
auto_ptr<A> p2 = p1; // must not compile

Exactly, because for moveable data type "copy ctor" is private in this
context. You must write like this:

auto_ptr<A> p1;
moveable auto_ptr<A> p2 = p1; // compile ok
*p2; // compile ok
*p1; // compile error

Here "move ctor" will be used.

Quote:

But I do not believe we can apply this fix to auto_ptr because of
backwards compatibility concerns.

Any, who is using auto_ptr in its algorithms correctly will not see any
differences excluding they must declare "moveable". Also they can continue
to use "old_std::auto_ptr".

Quote:

Instead, people who are willing to
take the backwards compatibility hit will vote by changing their usage
to unique_ptr (which is essentially just an auto_ptr with the mutating
copy disabled -- from lvalues only).

The unique_ptr is alias of "correct_auto_ptr". Do we need
"incorrect_auto_ptr" as standard "auto_ptr" tool for backwards compatibility
reasons? I am not sure.

Quote:

So, suggestions for "fixing auto_ptr" should really be clear about
exactly what is being fixed, and what that cost is in terms of backwards
compatibility is.

Imho, no matter what we do to fix it, if it moves
from lvalues with copy syntax, then the very biggest problem with it
hasn't been fixed.

No, auto_ptr uses "copy syntax" only because C++ does not support "moveable"
and "move syntax". In current version of C++ it is user responsibility to
control moveable data type.

The new correct redeclaration of "std::auto_ptr" for 'C++ with "moveable"
support' will not change core of user code (he will need to add only
"moveable" keyword to declarations), if the user code already correcltly
treats "auto_ptr" as moveable data type.

Quote:

Any other problems auto_ptr may have are trivial
annoyances in comparison.

They are not exist maybe, other problems in addition to problem of C++,
which does not support "moveable".

***
It is important to note, that speaking about "auto_ptr" in my original post
i am speaking not only about "std::auto_ptr". Anyway, it does no matter will
std::auto_ptr be correct or not (any can just ignore any incorrect
declarations from std namespace), because i am speaking mostly about
user-defined auto_ptr-like wrappers.

I want to say, that C++ must have stuffs to allow to user to write own
wrappers or freely do other work with moveable data type and i want to say,
that the concrete current form of "r-value reference proposal" as
implementation of moveable data type can not be the stuff of C++.

The opinion is explained with details in other 5 points of disagreement and
on my page (http://grizlyk1.narod.ru/cpp_new #11-#15).

--
Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

James Dennett
Guest

Posted: Sat Mar 17, 2007 9:56 pm Post subject: Re: Constrained Forwarding(R-Value Reference)

Grizlyk wrote:

Quote:

Howard Hinnant wrote:
As I can understand, auto_ptr with move semantics was called
"unique_ptr",
but really they do the same. So do we need new name for auto_ptr? I think
no.
...
( i already have listed 6 points of deisagreement with
the "r-value reference" in the thread and still no one has denied my
reasons
in essence and proved that i was wrong ).
Your first point was:

1. No auto_ptr support.
=======================
And I've reread that point several times. I'm still failing to see how
the rvalue reference package is lacking in this area.

In general. if anyone really want find answer (unknown to him), I think, he
is forced to answer on _each_ opposite argument in essence. There are no
other way of searching (at least i do not know other way).

From practical life i know, that often refusing to do it (answering)
speaking only about absence of desire to obtain any answer disagreeing with
predefined wanted result, because "i do not need", "i do not want" and other
the same reasons.

In the concrete accident of auto_ptr implemented with "rvalue reference" i
can only repeat my previuos 6 arguments, because i do not know what part of
the arguments (for each concrete problem) has been rejected by you.

By and large, I can say that I could not make any sense
of most of what you wrote. It's quite possible that
others could not understand what you meant either. If
so, it will not help to ask them what they "rejected",
except for the fact that your objections did not seem
coherent.

Maybe I can address them somewhat:

1) "No auto_ptr support"

It wasn't clear what you meant here. rvalues as proposed
*do* allow for a better solution to the problem that was
addressed by auto_ptr.

2) "No ordered definitions
for "copyable" and "moveable" C++ concepts.

It was not clear what you meant by this, or why you felt
that it was a problem with the rvalue reference proposal.

3. "Value" is not the same as "reference"

It was not clear what you meant here. It's obviously true
that "value" is not the same as "reference", but that does
not present a problem for the proposal, which does not
make any assumption that values and references are the
same.

4. "Non-const" is not the same as "moveable".

Again, this is well-known, and not a problem for the
proposal. If you believe there is a problem, you will
need to provide convincing evidence. You write that
"The ownership from auto_ptr can not be transferred
more than one time" but this is not true; ownership
can be passed along an unlimited chain of auto_ptr
objects. Was this maybe not what you meant to write?

This was also a key point in your number 5, which also
says (incorrectly) that auto_ptr must not be passed by
reference. Certainly passing auto_ptr by reference is
unusual, but it can be quite correct.

6. Interaction "copyable" and "moveable"

Again, it was not clear what you meant here; could you
be more explicit?

It's possible that these problems are mine, but in general
I find discussions on comp.std.c++ quite easy to follow
(sometimes with a little work), so it's likely that if I
do not see what points you are trying to make then there
may be others who need more clarity. I cannot make
constructive responses to most of your points as they
seem not to address the rvalue references subject. If
you can express your ideas in more concrete detail, showing
how they actually present difficulties with the current
proposals in practical situations, you may well find that
others will support your points.

-- James

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Grizlyk
Guest

Posted: Sun Mar 18, 2007 8:29 pm Post subject: Re: Constrained Forwarding(R-Value Reference)

James Dennett wrote:

Quote:

He has asked me how it can be implemented with my proposal. Try open
http://grizlyk1.narod.ru/cpp_new and find there words "lvalue". Really,
lvalue/rvalue has ablsolutely no any sense in context of data type.
Lvalue
means "address can be taken" and nothing more. "Lvalue" is unrelated to
"const", "copyable" or "moveable" data type.

The relationship is something that exists and has been
considered in quite a lot of detail.

Any term, binding several objects, as relationship do, of course can be
considered for any combinations of any objects. For example, we can consider
question about any relationships between C++ and rain in any desert.

But the possible ability of consideration is not the same, that the
considered term can be applied to binding the concrete combination of the
concrete objects. For example, there are no any relashionship between C++
and rain in any desert.

So original sentence: "there are no any relashionship between "Lvalue" and
"const", "copyable" or "moveable" data type" is correct statement at least
formally.

And logically the original sentence is also correct, because "Lvalue" means
"address can be taken, so memory of the expression always exist" and
speaking nothing related to data type. So we can easy imaging at least
conceptual "moveable" object, address of which can be taken as well as can
not, so there is "Lvalue moveable" as well as "Rvalue moveable" in C++.

Rvalue is not the term that can be used to declare any data type, including
moveable data type. The fact, that some rvalue expressions looks like
"moveable" is just accident.

--
Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Grizlyk
Guest

Posted: Sun Mar 18, 2007 8:31 pm Post subject: Re: Constrained Forwarding(R-Value Reference)

Pedro Lamarao wrote:

Quote:

lt& doesn't mean "reference to copyable", it means "reference to
lvalue".

As i can understand, temporary can not be assigned to "non-const
reference"
only due to the reference can be passed out of the temporary scope and
writing into non-existing stack of the terminated function for some
people
looks like more dangerous when reading from the non-existing memory or
calling functions with random entry point, that can be done with the
temporary assigned to "const reference".

This may have been the rationale for for the current rules for
reference binding.
The rationale being accepted the rules were set.

The current working paper has new syntax for references.
References declared with this new syntax have binding new rules.

I have said, that differences between "reference to lvalue of type" and
"reference to rvalue of type" has been introduced not due to existence of
"rvalue data type" or due to there are any real important noticable
differences between "reference to lvalue of type" and "reference to rvalue
of type", but only due to possible writing into wrong memory via "reference
to temporary".

I am sure and have listed some concrete arguments, that term "reference" and
its semantics is alredy well defined in C++, does not need to be replaced by
any other stuffs, at least in order to support moveable semantics.

Quote:

These new rules, governing this new syntax, do allow for temporaries
to be bound to references.

This is really different questions between "temporaries to be bound to
references" and "existence of moveable data type".

Quote:

It has been found that these new rules satisfy the desire for
expressing Moveable.

It is very shallow explanation ( somewhere somebody has found something ),
especially when concrete opposite agruments have been listed by me, that
these "new rules" _can not_ satisfy the desire for expressing Moveable.

Quote:

You seem to disagree and we seem to not understand why.

This is really different questions between "temporaries to be bound to
references" and "existence of moveable data type".

I am sure and have listed some concrete arguments, that "term reference" and
"semantics of reference" is alredy well defined in C++, does not need to be
replaced by any other stuffs, _at least_ in order to only support moveable
semantics.

If we want to completely support "moveable data type and semantics" we must
"change direction" of "r-value reference" proposal.

Quote:

You are telling me that "T const&" requires T to be Copyable.
If this is true, how can the following code be valid?

class resource {
public:
resource ();
private:
resource (resource const&);
resource& operator= (resource const&);
};

Here the class "resource" has been declared as non-copyable, but probably as
moveable, only if compiler can do auto generation of "move constructor:
resource (moveable resource const&)" (as for "copy constructor" do), else
the class "resource" as well non-copyable as non-moveable.

Quote:

template <typename T
void
foo (T const& t) { }

Here the function "foo<>" has no body and is declaring "t" is to be
copyable, but never used the fact.

Quote:

void
f () {
resource r1;
foo(r1);

assuming

foo<resource>(r1);

Here "probably-moveable resource" has been passed as "reference to const
copyable", and it is correct, due to "foo<>" does not used the requirement
of "t" is to be copyable.

Quote:

}

***
I think we need to allow explicit declarations of parameter of template or
function is to be exactly copyable or moveable?

template <test typename T>void foo (T const& t);
template <test moveable typename T>void foo (T const& t);

class T;
void foo (test T const& t);
void boo (test moveable T const& t);

Here compiler will test that concrete concrete "T" has public copy/move
ctor. It makes declarations more clear and more independent from its
implementation:

template <test typename T>
void
foo (T const& t);

it is the same as

template <typename T>
void
foo (test T const& t);

Here your example

foo<resource>(r1);

will not be compileable, due to "resource" is non-copyable.

--
Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

David Abrahams
Guest

Posted: Mon Mar 19, 2007 9:28 pm Post subject: Re: Constrained Forwarding(R-Value Reference)

on Mon Mar 19 2007, grizlyk1-AT-yandex.ru ("Grizlyk") wrote:

Quote:

I see ( looking on your reply "I can say that I could not make any sense of
most of what you wrote" ) my sentence "he is forced to answer on _each_
opposite argument in essence" has not found a good place in your sole.

I do not care do you agree with me or not, because the my sentence "he is
forced ..." is just translation of well-known rule of formal logic.

Well, not a very good translation, then. Your sentence, "he is forced
to answer on _each_ opposite argument in essence," really is
incomprehensible to me, as I expect it is to most native speakers of
English.

Quote:

As programmer, if you will ignore any rules of formal logic in your
programs, your programs will never do any useful, because to CPU you
never can say "Listen, hell's CPU, I could not make any sense of
most of what you doing".

During conversation it is the same, no any useful answer can be
found with refusing from rules of of formal logic, the only useful
example of conversation without the rules of formal logic is one
containing no words, only series of useless curses to address of
enemies on square meeting, producing loud "huraaa" from listeners.

All the formal logic in the world won't help your argument if your
readers can't parse it. What you intend to say could be the most
brilliant thing ever posted here, but it will have no impact if you
can't make it understandable.

James Dennet writes:

Quote:

I don't think it's a matter of like or dislike, but of communication
failure.

<snip>

Quote:

It's obviously true
that "value" is not the same as "reference", but that does
not present a problem for the proposal

I have no problem, so you are wrong.

Your answer doesn't seem to be consistent with formal (or informal)
logic. James wrote that your statement ("value is not the same as
reference") does not present a problem for the proposal; he didn't
claim that "you have a problem." Your lack of a problem has no
bearing on whether "value is not the same as reference" presents a
problem for the proposal.

So, formally speaking

You have no problem

does not imply

James is wrong

:)

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

David Abrahams
Guest

Posted: Mon Mar 19, 2007 9:28 pm Post subject: Re: Constrained Forwarding(R-Value Reference)

on Thu Mar 15 2007, grizlyk1-AT-yandex.ru ("Grizlyk") wrote:

Quote:

The auto_ptr always was not copyable (has no copy constructor).

std::auto_ptr<T> has a constructor that can accept a single argument
of std::auto_ptr<T>&. By the definition of "copy constructor" in the
C++ the standard, that is a copy constructor.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

James Dennett
Guest

Posted: Mon Mar 19, 2007 9:50 pm Post subject: Re: Constrained Forwarding(R-Value Reference)

Grizlyk wrote:

Quote:

James Dennett wrote:
He has asked me how it can be implemented with my proposal. Try open
http://grizlyk1.narod.ru/cpp_new and find there words "lvalue". Really,
lvalue/rvalue has ablsolutely no any sense in context of data type.
Lvalue
means "address can be taken" and nothing more. "Lvalue" is unrelated to
"const", "copyable" or "moveable" data type.
The relationship is something that exists and has been
considered in quite a lot of detail.

Any term, binding several objects, as relationship do, of course can be
considered for any combinations of any objects. For example, we can consider
question about any relationships between C++ and rain in any desert.

But we would not reasonably be able to consider it
"in detail", as there is no significant relationship
between C++ and weather in some specified geographical
region. On the other hand, the relationship between
rvalues and movable items is quite specific and
meaningful, arising from the basic notion that
temporary objects are rvalues (even when their
addresses can be taken), and that moving from a
temporary object is generally safe.

Quote:

But the possible ability of consideration is not the same, that the
considered term can be applied to binding the concrete combination of the
concrete objects. For example, there are no any relashionship between C++
and rain in any desert.

Right, so that would not be a useful thing for us to
discuss.

Quote:

So original sentence: "there are no any relashionship between "Lvalue" and
"const", "copyable" or "moveable" data type" is correct statement at least
formally.

How can it be correct when others have supplied specific
details of the concrete relationship that exists between
rvalues and movability?

(Also note: "rvalue references" do not apply only to
rvalues -- while they bind to rvalues, it is quite
possible and useful to use an rvalue reference to
cause a non-rvalue to be treated in the same way as
an rvalue, such as is done by std::move.)

Quote:

And logically the original sentence is also correct, because "Lvalue" means
"address can be taken, so memory of the expression always exist" and
speaking nothing related to data type.

Lvalue does not mean that; with user-defined types it is
possible to take the addresses of some rvalues, and taking
the addresses of certain lvalues can be prevented.

Quote:

So we can easy imaging at least
conceptual "moveable" object, address of which can be taken as well as can
not, so there is "Lvalue moveable" as well as "Rvalue moveable" in C++.

That's true, and the rvalue reference proposal allows for
expressing movement from lvalues via std::move. Do you
think there is an inability to express this with the
current proposals? Are you familiar with std::move?

Quote:

Rvalue is not the term that can be used to declare any data type, including
moveable data type. The fact, that some rvalue expressions looks like
"moveable" is just accident.

It's not clear to me what you mean here. It's certainly
true that there is a fundamental reason why moving from
temporaries is a reasonable thing; that is not just an
accident.

-- James

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Guest

Posted: Tue Mar 20, 2007 5:01 am Post subject: Re: Constrained Forwarding(R-Value Reference)

"Grizlyk" wrote:

Quote:

James Dennett wrote:
..
By and large, I can say that I could not make any sense
of most of what you wrote.

In comp.lang.c++ one man have told me, that it is not a good idea to discuss
"the ways of correct discussions" mixed with topic. Maybe he was right, but
only if his opinion is not obstacle to find topic's answers.

I see ( looking on your reply "I can say that I could not make any sense of
most of what you wrote" ) my sentence "he is forced to answer on _each_
opposite argument in essence" has not found a good place in your sole.

All the good will in the world won't make it possible to rebut an
argument, when you can't understand the argument well enough to figure
out what it is that you need to rebut. I have to agree with James
Dennet - I can't figure out what you're saying well enough to explain
what's wrong with it.

..

Quote:

- implicitly said, that point of "misunderstands" is my bad source, not the

Yes. that is precisely the problem. Your poor command of the English
language is presenting major communications problems. That's not
intended as a criticism; it's just a regrettable fact. My Russian is
far worse than your English; I'd have far more trouble making myself
understood in a Russian language forum than you do in this one.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

David Abrahams
Guest

Posted: Tue Mar 20, 2007 9:00 am Post subject: Re: Constrained Forwarding(R-Value Reference)

on Wed Mar 14 2007, "Grizlyk" <grizlyk1-AT-yandex.ru> wrote:

Quote:

tasjaevan (AT) gmail (DOT) com wrote:

Can you give me examples of any other possible values of the
expression "auto_ptr(unique_ptr)" in the context: "in most _very_
important cases (as for auto_ptr(unique_ptr))". I do not insist,
it is just interesting why "guess" is required here.

I read it as pseudo-C++. I thought you were talking about some kind
of conversion between the two types.

As I can understand, auto_ptr with move semantics was called
"unique_ptr", but really they do the same.

Not exactly the same, or, as you say, we wouldn't need a new name.
The differences in behavior would cause old, working, code to break if
auto_ptr were simply changed to use unique_ptr semantics.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Grizlyk
Guest

Posted: Tue Mar 20, 2007 9:00 am Post subject: Re: Constrained Forwarding(R-Value Reference)

James Dennett wrote:

Quote:

As I can understand, auto_ptr with move semantics was called
"unique_ptr", but really they do the same. So do we need new
name for auto_ptr? I think no.
...
( i already have listed 6 points of deisagreement with
the "r-value reference" in the thread and still no one has
denied my reasons in essence and proved that i was wrong ).

Your first point was:

1. No auto_ptr support.
=======================
And I've reread that point several times. I'm still failing
to see how the rvalue reference package is lacking in this area.

In general. if anyone really want find answer (unknown to him), I think,
he
is forced to answer on _each_ opposite argument in essence. There are no
other way of searching (at least i do not know other way).

By and large, I can say that I could not make any sense
of most of what you wrote.

In comp.lang.c++ one man have told me, that it is not a good idea to discuss
"the ways of correct discussions" mixed with topic. Maybe he was right, but
only if his opinion is not obstacle to find topic's answers.

I see ( looking on your reply "I can say that I could not make any sense of
most of what you wrote" ) my sentence "he is forced to answer on _each_
opposite argument in essence" has not found a good place in your sole.

I do not care do you agree with me or not, because the my sentence "he is
forced ..." is just translation of well-known rule of formal logic. As
programmer, if you will ignore any rules of formal logic in your programs,
your programs will never do any useful, because to CPU you never can say
"Listen, hell's CPU, I could not make any sense of most of what you doing".

During conversation it is the same, no any useful answer can be found with
refusing from rules of of formal logic, the only useful example of
conversation without the rules of formal logic is one containing no words,
only series of useless curses to address of enemies on square meeting,
producing loud "huraaa" from listeners.

In the my text above I am speaking, that your idea "I can say that I could
not make any sense of most of what you wrote" chiefly pointed against the
rule "he is forced to answer on _each_ opposite argument in essence" rather
than against me or my statements, because in order to disagree with me you
have violated the rule twice:
- did not list concrete error points in my text,
- implicitly said, that point of "misunderstands" is my bad source, not the
rule violation.

It is no any sense to discuss concrete problems without the rules of formal
logic. Also, i can explain the rule in the concrete case of conversation: I
never can guess what part of my statements has been wrong for you, and your
attempts to avoid concrete enumerating at least some of concrete wrong
points in my statemets often can speak that there are no wrong points there,
but you do not agree, so you are forced to search other way of "discussion".

Quote:

If so, it will not help to ask them what they "rejected",
except for the fact that your objections did not seem
coherent.

I understand: "I do not like it, I can not say why, but probably all are
totally non-coherent, because < here can be any unrelated to provement of
object of discussion >".

Quote:

Maybe I can address them somewhat:

1) "No auto_ptr support"

It wasn't clear what you meant here.

Answer to concrete unclear sentences from original post.

Quote:

2) "No ordered definitions
for "copyable" and "moveable" C++ concepts.

It was not clear what you meant by this, or why you felt

Answer to concrete unclear sentences from original post.

Quote:

3. "Value" is not the same as "reference"

It was not clear what you meant here.

Answer to concrete unclear sentences from original post.

Quote:

It's obviously true
that "value" is not the same as "reference", but that does
not present a problem for the proposal

I have no problem, so you are wrong.

Quote:

4. "Non-const" is not the same as "moveable".

Again, this is well-known, and not a problem for the
proposal.

I have no problem, so you are wrong.

Quote:

If you believe there is a problem, you will
need to provide convincing evidence.

http://grizlyk1.narod.ru/cpp_new/#12

Quote:

The ownership from _concrete object of class of_ auto_ptr can not be
transferred more than once. And context is clear speaking about it :

"Also it is easy to see, that non-const can not protect us from logically
wrong "operator move" has been applied twice to the non-const object (double
move). We can say, that move semantic required from C++ "once" support
rather than "non-const" support, it is really different things."

Quote:

http://grizlyk1.narod.ru/cpp_new/#11

"Also it means, that there are no more than one auto_ptr with the same
address simultaneously.

Unlike to auto_ptr, we can have many POD pointers with the same address
(that have been placed in an auto_ptr) and we can use the pointers while the
auto_ptr exist."

Quote:

6. Interaction "copyable" and "moveable"

Again, it was not clear what you meant here;

Answer to concrete unclear sentences from original post.

Quote:

could you be more explicit?

http://grizlyk1.narod.ru/cpp_new/#14

"Interaction "copyable" and "moveable". Today we have only
copyable/non-copyable support, that looks like boolean type. But adding new
property as moveable gives to object one of the following ordered property:
non-copyable/moveable/copyable.
And here we must define (enumerate) all strict rules also ("functions
expecting moveable value can use copyable value" and so on). "

Quote:

It's possible that these problems are mine, but in general
I find discussions on comp.std.c++ quite easy to follow
(sometimes with a little work), so it's likely that if I
do not see what points you are trying to make then there
may be others who need more clarity.

I cannot make constructive responses to most of your points

It is a pity, but i can not response instead of you.

Quote:

as they seem not to address the rvalue references subject.

Becasue r-value reference is implementation of something, so i am speaking
about the thing, the r-value reference is implementing.

Quote:

Answer to concrete unclear sentences from original post, unrelated to the
current
proposals of r-value reference in practical situations.

So, as funny result of the discussion - to be happy is much better to be
unhappy. Speaking seriously, I have made the long explanation in the post in
order to make example and to refer on the example in future, if it will be
nessesary.

--
Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

James Dennett
Guest

Posted: Tue Mar 20, 2007 9:10 am Post subject: Re: Constrained Forwarding(R-Value Reference)

Grizlyk wrote:

Quote:

James Dennett wrote:
As I can understand, auto_ptr with move semantics was called
"unique_ptr", but really they do the same. So do we need new
name for auto_ptr? I think no.
...
( i already have listed 6 points of deisagreement with
the "r-value reference" in the thread and still no one has
denied my reasons in essence and proved that i was wrong ).

Your first point was:

1. No auto_ptr support.
=======================
And I've reread that point several times. I'm still failing
to see how the rvalue reference package is lacking in this area.
In general. if anyone really want find answer (unknown to him), I think,
he
is forced to answer on _each_ opposite argument in essence. There are no
other way of searching (at least i do not know other way).

By and large, I can say that I could not make any sense
of most of what you wrote.

In comp.lang.c++ one man have told me, that it is not a good idea to discuss
"the ways of correct discussions" mixed with topic. Maybe he was right, but
only if his opinion is not obstacle to find topic's answers.

Sometimes it is vital to address "the ways of correct
discussion" and more constructive to also try to help
the topic along at the same time. That is what I have
attempted to do here. I hope you can understand that
this is an attempt to help you. Others will be more
able to help if they can first understand.

Quote:

Again, I do not quite understand what you mean, but
clearly I did answer each of your original points as
far as I could. (It's not "forced" by anything I
see, but let's ignore that.)

Quote:

I do not care do you agree with me or not, because the my sentence "he is
forced ..." is just translation of well-known rule of formal logic.

I cannot imagine how you think that formal logic forces
*anything* on a newsgroup. (My background is in
mathematics and logic; I find it minimally applicable
to this newsgroup.)

Quote:

And, clearly, we use logic when programming. Formal
logic applies to code in ways it does not apply to
discussions on newsgroups.

Quote:

During conversation it is the same, no any useful answer can be found with
refusing from rules of of formal logic, the only useful example of
conversation without the rules of formal logic is one containing no words,
only series of useless curses to address of enemies on square meeting,
producing loud "huraaa" from listeners.

It is not the same. Human conversations are not
conducted according to formal rules; even human
languages are not conducive to formal rules (which
is why we term them "natural languages" to distinguish
from formal languages). Our discussions are fruitless
if they are not at least consistent, but they do not
have to follow a formal framework.

Quote:

In the my text above I am speaking, that your idea "I can say that I could
not make any sense of most of what you wrote" chiefly pointed against the
rule "he is forced to answer on _each_ opposite argument in essence" rather
than against me or my statements, because in order to disagree with me you
have violated the rule twice:
- did not list concrete error points in my text,

I could list many errors, but that would be missing
the point. The point is that there was, to me, much
of what was there had no meaning. I hope that others
are able to guess what you meant better than I can,
but the lack of substantive replies seems to suggest
that others have also been unable to work out what
you meant.

Quote:

- implicitly said, that point of "misunderstands" is my bad source, not the
rule violation.

As I cannot even understand which rule you claim to
have been violated, I do feel that some of the problem
is the language barrier; your language skills in
English are stronger than mine in any other language,
but it is clear that English is not native.

Quote:

It is no any sense to discuss concrete problems without the rules of formal
logic. Also, i can explain the rule in the concrete case of conversation: I
never can guess what part of my statements has been wrong for you, and your
attempts to avoid concrete enumerating at least some of concrete wrong
points in my statemets often can speak that there are no wrong points there,
but you do not agree, so you are forced to search other way of "discussion".

Not so. I made no "attempt" to avoid addressing
concrete points. Rather, I simply did not do so,
as it did not occur to me that a long list of
sentences with notes saying "this is not a
meaningful English sentence in this context"
would be helpful. The issue is not that you said
things that were wrong; the issue is that some
(maybe many) people cannot understand what it
is that you meant to say.

Quote:

If so, it will not help to ask them what they "rejected",
except for the fact that your objections did not seem
coherent.

I understand: "I do not like it, I can not say why, but probably all are
totally non-coherent, because < here can be any unrelated to provement of
object of discussion >".

Maybe I can address them somewhat:

1) "No auto_ptr support"

It wasn't clear what you meant here.

Answer to concrete unclear sentences from original post.

I don't understand you response. Maybe I can be clearer:
It was not clear what your first point meant. The whole
section headed "No auto_ptr support" did not make sense
to me.

Quote:

2) "No ordered definitions
for "copyable" and "moveable" C++ concepts.

It was not clear what you meant by this, or why you felt

Answer to concrete unclear sentences from original post.

Again, I do not understand your sentence above. I meant
that your second point was unclear.

Quote:

3. "Value" is not the same as "reference"

It was not clear what you meant here.

Answer to concrete unclear sentences from original post.

(The same here.)

Quote:

It's obviously true
that "value" is not the same as "reference", but that does
not present a problem for the proposal

I have no problem, so you are wrong.

This logic is flawed; the fact that *you* have
a problem does not prove that the the fact that
the terms "value" and "reference" is a problem
for the proposal. The proposal is entirely
consistent with this fact (even though it does
give new meaning to the term reference).

Quote:

4. "Non-const" is not the same as "moveable".

Again, this is well-known, and not a problem for the
proposal.

I have no problem, so you are wrong.

That makes no sense, and does not follow. Whether
you have a problem or not, does not speak of whether
the proposal has a problem.

Quote:

If you believe there is a problem, you will
need to provide convincing evidence.

http://grizlyk1.narod.ru/cpp_new/#12

There's a large amount of material there. It does
not appear relevant, and much of what is there
suffers from stating as conclusions things that
are unproven or do not make sense. For example,
to be concrete, you state that "So in order to
support auto_ptr C++ must also define extra
attributes to controll access to "moveable".
Your argument does not show this to be true.

Quote:

You write that
"The ownership from auto_ptr can not be transferred
more than one time" but this is not true; ownership
can be passed along an unlimited chain of auto_ptr
objects. Was this maybe not what you meant to write?

The ownership from _concrete object of class of_ auto_ptr can not be
transferred more than once. And context is clear speaking about it :

"Also it is easy to see, that non-const can not protect us from logically
wrong "operator move" has been applied twice to the non-const object (double
move). We can say, that move semantic required from C++ "once" support
rather than "non-const" support, it is really different things."

It is in the nature of "moving" a resource that once it
has been moved from a place, it is no longer there. This
is a design feature of auto_ptr (an other movable types),
not a flaw. It is not clear what you think is wrong.

A resource can be passed between auto_ptr instances many
times, but at any given time it is owned by only one of
them. In general, a movable resource need be in only
one place at a time.

Quote:

This was also a key point in your number 5, which also
says (incorrectly) that auto_ptr must not be passed by
reference. Certainly passing auto_ptr by reference is
unusual, but it can be quite correct.

http://grizlyk1.narod.ru/cpp_new/#11

"Also it means, that there are no more than one auto_ptr with the same
address simultaneously.

Unlike to auto_ptr, we can have many POD pointers with the same address
(that have been placed in an auto_ptr) and we can use the pointers while the
auto_ptr exist."

That does not say anything about passing auto_ptr by
reference, does it?

Quote:

6. Interaction "copyable" and "moveable"

Again, it was not clear what you meant here;

Answer to concrete unclear sentences from original post.

I do not know what you mean by "answer to concrete unclear
sentences from original post".

Quote:

could you be more explicit?

http://grizlyk1.narod.ru/cpp_new/#14

"Interaction "copyable" and "moveable". Today we have only
copyable/non-copyable support, that looks like boolean type. But adding new
property as moveable gives to object one of the following ordered property:
non-copyable/moveable/copyable.
And here we must define (enumerate) all strict rules also ("functions
expecting moveable value can use copyable value" and so on). "

This is what I am asking you to explain, rather than repeat.

Quote:

I'm afraid I can't understand what you mean by "i can not
response instead of you".

Quote:

as they seem not to address the rvalue references subject.

Becasue r-value reference is implementation of something, so i am speaking
about the thing, the r-value reference is implementing.

I don't think that it *is* "implementation of something".
Rather, it's a new language feature which can be used to
implement a range of things. It has applications in the
areas of move semantics, of function forwarding, and no
doubt other areas too.

Quote:

If you can express your ideas in more concrete detail, showing
how they actually present difficulties with the current
proposals in practical situations, you may well find that
others will support your points.

Answer to concrete unclear sentences from original post, unrelated to the
current
proposals of r-value reference in practical situations.

Again, I'm afraid I cannot understand what you mean by
the sentence starting "Answer to concrete unclear
sentence from original post...".

Quote:

So, as funny result of the discussion - to be happy is much better to be
unhappy. Speaking seriously, I have made the long explanation in the post in
order to make example and to refer on the example in future, if it will be
nessesary.

Which long explanations? I've seen many assertions, but
I would need more explanation/evidence for the claims
you make in order to determine whether they have merit.

-- James

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Grizlyk
Guest

Posted: Tue Mar 20, 2007 6:05 pm Post subject: Re: Constrained Forwarding(R-Value Reference)

James Dennett wrote:

Quote:

He has asked me how it can be implemented with my proposal. Try open
http://grizlyk1.narod.ru/cpp_new and find there words "lvalue". Really,
lvalue/rvalue has ablsolutely no any sense in context of data type.
"Lvalue" means "address can be taken" and nothing more.
"Lvalue" is unrelated to "const", "copyable" or "moveable" data type.

The relationship is something that exists and has been
considered in quite a lot of detail.

As I can understand, you have said, that term "relationship" must be applied
to bind "Lvalue" and "const", because of either something exist or something
can be considered in quite a lot of detail.

Then i have said, that

Quote:

Any term, binding several objects, as relationship do, of course can be
considered for any combinations of any objects.

So we always can consider any term, binding several objects, and consider in
quite a lot of detail.

Quote:

For example, we can consider
question about any relationships between C++ and rain in any desert.

But we would not reasonably be able to consider it
"in detail", as there is no significant relationship
between C++ and weather in some specified geographical
region.

It does not matter here "reasonably" or not, it is only important that we
can do consider any term, binding any several objects.

Quote:

But the possible ability of consideration is not the same, that the
considered term can be applied to binding the concrete combination of the
concrete objects.

So I have said, that in spite of the fact, that we always can consider any
term, the existence of process of consideration is not the same, that the
considered term must be applied to binding the concrete combination of the
concrete objects.

If we have found after consideration process, that relationship is not exist
(objects unrelated), we can continue to apply the term "relationship" in the
form of "has no relationship" (unrelated).

Quote:

For example, there are no any relationship between C++
and rain in any desert.

Right, so that would not be a useful thing for us to
discuss.

So you have agreed with me, that "Lvalue" can be as well related (has
relationship) as unrelated (has no relationship) to "const", "copyable" or
"moveable" data type. It does not matter either can "relationship of
"Lvalue" and "const" has been considered in quite a lot of detail" or can
not in order to be able to apply "relationship" term to bind "Lvalue" and
"const".

Quote:

So original sentence: "there are no any relationship between "Lvalue" and
"const", "copyable" or "moveable" data type" is correct statement at
least
formally.

How can it be correct

_formally_ it is always correct, because you have agreed with me, that
"Lvalue" can be as well related as unrelated to "const", "copyable" or
"moveable" data type.

Quote:

when others have supplied specific
details of the concrete relationship that exists between
rvalues and movability?

As i can guess, you does not agree with concrete _form of relationship_: i
think "unrelated", you think "related".

There are differences between "rvalues", "movability" and "moveable data
type".

Conceptually "movability" or just "moveable property" is ability of _any_
concrete object to allow to process "move" to be applyed to the object, the
property can be unrelated to the type of the object and can appear only in
one concrete _place_ of code.

Conceptually "moveable data type" is data type, that in addition to
"movability", define some other important rules of behaviour for all objects
of own types _always_.

This is important difference, because "moveable data type" related to _data
type_, but "moveable property" related to _place of code_.

The conceptual difference defines differences in behaviour for "objects of
moveable data type" and "objects only with moveable property".

The example of the difference in behaviour is RVO:

1. r-value reference FAQ
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#Moving%20from%20local%20values)

Quote:

Moving from local values

A further language refinement can be made at this point. When returning a
non-cv-qualified object with automatic storage from a function, there should
be an implicit cast to rvalue:
string
operator+(const string& x, const string& y)
{
string result;
result.reserve(x.size() + y.size());
result = x;
result += y; // as if return static_cast<string&&>(result);
return result;
}The logic resulting from this implicit cast results in an automatic
hierarchy of "move semantics" from best to worst:

- If you can elide the move/copy, do so (by present language rules)
- Else if there is a move constructor, use it
- Else if there is a copy constructor, use it
- Else the program is ill formed

2. moveable concept as defined in http://grizlyk1.narod.ru/cpp_new

The example of "Moving from local values" will be:

a)
When returning #any# object with automatic storage from a function, there
should be an #explicit# cast to rvalue, #function must be declared
properly#:

string
operator+(const string& x, const string& y)
{
string result;
result.reserve(x.size() + y.size());
result = x;
result += y;

//here _always_ "copy constructor"
//never "move constructor"!
return result;
}
The logic resulting from this #explicit# cast results in an #explicit#
hierarchy of "copy semantics" from best to worst:

- If you can elide the move/copy, do so (by present language rules)

note, the question of "eliding" is unrelated to question of "data type"

- Else if there is a copy constructor, use it
- Else the program is ill formed

b)
If you need use moveable data type, function must be declared properly

moveable string
operator+(const string& x, const string& y)
{
string result;
result.reserve(x.size() + y.size());
result = x;
result += y;

//here either "move constructor"
//or "copy constructor"
return result;
}
The logic resulting from this #explicit# cast results in an #explicit#
hierarchy of "move semantics" from best to worst:

- If you can elide the move/copy, do so (by present language rules)

note, the question of "eliding" is unrelated to question of "data type"

- Else if there is a move constructor, use it
- Else if there is a copy constructor, use it
- Else the program is ill formed

***

The main differences is the fact, that:

- for "moveable data type", behaviour of objects defined only by class
_declaration_ and variable _declaration_ (as any ordinary C++ type _must_
do), "moveable data type" looks like "volatile data type" or "const data
type".

- but for "moveable property(r-value reference)", behaviour of objects
defined only by concrete _place_ of usage of variable of undefined type,
_never_ by declarations (as any ordinary C++ type _never_ must do).
"(r-value reference)" makes type of variable is secondary, but place is
primary condition of behaviour of variable.

***
Co-existance of "moveable property" and "moveable data type"

In theory, "moveable property" is just limited subset of "moveable data
type", but because "r-value reference" define own behaviour, orthogonal to
behaviour of ordynary C++ data type, the both of them can co-exist
simultaneoulsy.

Consider following declaration of class string, supporting all of them:

class string
{
//copyable data type
public:
string(const string&);
any_type operator= (const string&);

//r-value refinement of copyable data type
public:
string(const? string&&);
any_type operator= (const? string&&);

//moveable data type
public:
string(moveable const string&);
any_type operator= (moveable const string&)ctor;

//does not define copyable data type if unhided
//can override implicit copy ctor/assignment
public:
//compile time error
//string(string&) is hidden by
//string(const string&)
string(string&);

//compile time error
//operator= (string&) is hidden by
//operator= (const string&)
operator= (const string&)

//does not define moveable data type if unhided
//can override implicit move ctor/assignment
public:
//compile time error
//string(moveable string&) is hidden by
//string(moveable const string&)
string(moveable string&);

//compile time error
//operator= (moveable string&) is hidden by
//operator= (moveable const string&)
any_type operator= (const string&)ctor;
};

I am sure - "moveable data type" is more regular and important stuff, than
"r-value reference", so if C++ can not contain both, than "moveable data
type" must be selected.

Quote:

On the other hand, the relationship between
rvalues and movable items is quite specific and
meaningful

There are _no_ relationship between rvalues and "moveable data type". We can
easy imagine "conceptual moveable" as rvalue as well as lvalue.

moveable T add(const moveable T, const moveable T);

extern moveable T& src;
moveable T dst= add(src,src);

In the example above, return value of function "add" is "rvalue moveable",
but "dst" and "src" are "lvalue moveable", in spite of "src" is "reference
to moveable".

Quote:

arising from the basic notion that
temporary objects are rvalues (even when their
addresses can be taken)

I do not argue, that "temporary objects are rvalues".

But if address of "rvalue" can be taken, then the "rvalue" has been
implicitly casted into "lvalue", because by definition of "rvalue" - address
of "rvalue" never can be taken. For CPU's opcodes "rvalue" means data is
immediate:

enum { data=3 };
//3 -> %eax
movl $data,%eax
here "data" is "rvalue"

int data=3;
//3 -> %eax
movl data,%eax
here "data" is "lvalue", we can find its address as following:
//&data -> %eax
leal data,%eax

The fact of non-existence of address for any "rvalue" is unrelated to the
fact that "rvalue" can not be casted into "lvalue".

I can agree, that syntax "int&&" can be used to make explicit cast of
"temporary rvalue of type int" into "reference to temporary lvalue of type
int", but the question is unrelated to moveable data type. Absolutelly
unrelated to moveable as well as RVO unrelated to moveable.

I think, it can be better to call "r-value reference" as "reference to
temporary", because semantics of "reference" assuming "lvalue", because
reference always implemented as encapsulated "const pointer".

The "r-value reference" is sounded paradoxically: "address of something,
that has no address".

Quote:

and that moving from a
temporary object is generally safe.

I do not argue, that during temporary life time "moving from a temporary
object is generally safe".

But the fact of safe moving from temporary during temporary life is
unrelated to properties of moveable data type.

This is because "conceptual moveable" is data type, that can create new
instance from itself only by moving its internal state, insted of copying
and "conceptual copyable" is data type, that can create new instance from
itself as well by moving its internal state, as by copying.

Both "conceptual moveable" and "conceptual copyable" can be as well "lvalue"
as "rvalue" or temporary.

Quote:

(Also note: "rvalue references" do not apply only to
rvalues -- while they bind to rvalues, it is quite
possible and useful to use an rvalue reference to
cause a non-rvalue to be treated in the same way as
an rvalue, such as is done by std::move.)

I will agree with "std::move" for "moveable data type" only if you will use
in your programs "std::assing" and "std::copy" for copyable. For "r-value
reference", "r-value reference" is not going to be C++ moveable data type it
does not matter.

Quote:

And logically the original sentence is also correct, because "Lvalue"
means
"address can be taken, so memory of the expression always exist" and
speaking nothing related to data type.

Lvalue does not mean that; with user-defined types it is
possible to take the addresses of some rvalues,

Because you have made implicit cast rvalue to temporary lvalue. And the fact
that class is not POD type do not prevent compiler to make compile time copy
of the class as rvalue (at least it can be done in future).

Quote:

and taking
the addresses of certain lvalues can be prevented.

Can you write example of the prevention?

Quote:

So we can easy imaging at least
conceptual "moveable" object, address of which can be taken as well as
can
not, so there is "Lvalue moveable" as well as "Rvalue moveable" in C++.

That's true, and the rvalue reference proposal allows for
expressing movement from lvalues via std::move.

There are no relationship between "conceptual moveable" and "Rvalue". To be
moveable is defined by the class declaration, never by "std::move from
lvalue".

Quote:

Do you
think there is an inability to express this with the
current proposals? Are you familiar with std::move?

Quote:

Rvalue is not the term that can be used to declare any data type,
including
moveable data type. The fact, that some rvalue expressions looks like
"moveable" is just accident.

It's not clear to me what you mean here. It's certainly
true that there is a fundamental reason why moving from
temporaries is a reasonable thing; that is not just an
accident.

What exactly not clear? By accident means rvalue _looks_ like moveable by
accident. It is not core property of rvalue. That is just an accident,
because non-accident property of any data type can be defined _only by
declaration_, never by accident.

I think, the "r-value reference" is just not a data type, it is special set
of rules to work with copyable data type in special places of code,
unrelated to data type declaration.

The "r-value reference" never can replace ordinary moveable data type (
"r-value reference" is just limited subset of correct moveable data type and
"r-value reference" has special rules to interacts with copyable, the rules
does not dedined by class decalration ) because with the help of "r-value
reference" user never will be able to express simplest kind of algorithms
with moveable data type.

It is especially touching, when one can see, that C++ easy can support
complete moveable data type.

--
Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

David Abrahams
Guest

Posted: Tue Mar 20, 2007 6:56 pm Post subject: Re: Constrained Forwarding(R-Value Reference)

on Tue Mar 20 2007, grizlyk1-AT-yandex.ru ("Grizlyk") wrote:

Quote:

David Abrahams wrote:

As I can understand, auto_ptr with move semantics was called
"unique_ptr", but really they do the same.

Not exactly the same, or, as you say, we wouldn't need a new name.
The differences in behavior would cause old, working, code to break if
auto_ptr were simply changed to use unique_ptr semantics.

Again: I think, auto_ptr can not be good implemented without move semantics
in C++, but auto_ptr from its born was moveable, never copyable, so any old
code, already using current auto_ptr implementation correctly, will not see
any differences with new implementation, excluding old code must declare
auto_ptr as moveable

old:

auto_ptr foo(auto_ptr ptr)
{
auto_ptr tmp(ptr);
return tmp;
}

new:

moveable auto_ptr foo(const moveable auto_ptr ptr)
{
auto_ptr tmp(ptr);
return tmp;
}

That can be done often by "replace" command of any text editor. If old code
will not be able to compile after conversion like this, it means the old
code are using auto_ptr incorrectly - with UB or runtime errors.

In other words, "Again:" the differences in behavior would cause old,
working, code to break if auto_ptr were simply changed to use
unique_ptr semantics. It is taken for granted by the proposers of
unique_ptr -- who have a lot of experience with what sorts of changes
will be accepted or rejected by the C++ committee -- that such
breakage would be unacceptable even if it "can be fixed by the replace
command of any text editor."

You may disagree with us about what the commitee will accept. In that
case feel free to submit your own proposal and argue for it at the
next committee meeting.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Guest

Posted: Tue Mar 20, 2007 8:45 pm Post subject: Re: Constrained Forwarding(R-Value Reference)

"Grizlyk" wrote:

Quote:

David Abrahams wrote:
..
All the formal logic in the world won't help your argument if your
readers can't parse it.

Exellent example of violating the considered rule. What kind of
incomprehensible? Is this kind of "hidden knowledge" for "native speakers of
English"?

That knowledge is widely published in textbooks explaining the correct
usage of English. Native speakers generally don't need those textbooks
as much as non-native speakers do, but there's nothing hidden or
specific to native speakers about that knowledge.

Quote:

... This looks like kind of arguments to person, not to essence, used
when agruments to essence is absent.

You need to distinguish between yourself and your writings. You might
be a wonderful person, with some very important insights into C++.
We're not criticizing you. We are criticizing the quality of your
written English, which is simply not adequate for this discussion. If
we were to suggest that the way you write reflects the way you
actually think, that would be a personal insult; but I don't believe
that - I think your written English is simply not good enough to
express these complicated thoughts clearly in it.

When your English is so poor that we can't figure out the essence of
your arguments, it's not really possible to put together a rebuttal
that addresses that essence.

Quote:

Let's consider the sentence "he is forced to answer on _each_ opposite
argument in essence"

-he
-is forced
-to answer

-on
"to answer on" can be a kind of "control", like "find out", "go on" etc,

No, it cannot. While I know that this construct is incorrect, I don't
remember the correct grammatical jargon for explaining what's wrong
with it. However, I am quite certain that it's an incorrect English
construction. I suspect that what you should do is remove the "on",
but you seem quite certain that it modifies "answer" in a way that
conveys some distinction which is of importance to you, so that might
not be the right fix.

Quote:

changing semantics of original word "answer" and certainly i can not know
the details of english for all possible situation, but in the context "to
answer" has quite clear meaning.

-_each_ opposite argument

You probably mean "opposing" rather than "opposite".

Quote:

-in essence

This doesn't belong in this location in the sentence. Again, I don't
remember how to explain the rule, but this should be removed.
Inserting "the essence of" before the word "each" would probably
convey your intended meaning.

Quote:

All of the parts of sentence is quite correct in english grammar (rules of

No, they are not. Applying all of my suggestions, I get:

He is forced to answer the essence of each opposing argument.

Unfortunately, this was one of your clearer sentences. Most of them
are much harder to figure out.

Quote:

comnibation of words into sentence) as well as has quite "undestandable"
semantics.

I'm sorry, but even with the grammar mistakes corrected, the semantics
of your sentence do not make any sense. How is someone supposed to
answer the essence of an argument, when he can't figure out how to
parse the words that make up the argument?

Quote:

Do i need to continue to answer to so deliberate wrong questions?

These questions are not "wrong", nor are they deliberately so. You
don't need to answer them if you don't want to - you don't need to do
anything. However, you should continue to answer them if you have any
desire to actually be understood.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Howard Hinnant
Guest

Posted: Tue Mar 20, 2007 8:55 pm Post subject: Re: Constrained Forwarding(R-Value Reference)

In article <etoqpf$vlp$1 (AT) aioe (DOT) org>, "Grizlyk" <grizlyk1 (AT) yandex (DOT) ru>
wrote:

Quote:

The "r-value reference" never can replace ordinary moveable data type (
"r-value reference" is just limited subset of correct moveable data type and
"r-value reference" has special rules to interacts with copyable, the rules
does not dedined by class decalration ) because with the help of "r-value
reference" user never will be able to express simplest kind of algorithms
with moveable data type.

I would be interested in your implementation of std::remove (from
<algorithm>). As an example, it might go a long way towards explaining
your proposal.

Or if not std::move, a generic insertion_sort algorithm along the lines
of:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1771.html#insert
ion_sort

I'm looking for something that will work when the value_type has only a
copy constructor/assignment (e.g. complex<double>), when the value_type
has both copy and move constructors/assignments, e.g. string (and move
is preferred for performance reasons), and when the value_type has
disabled (private) copy semantics but public move members (like the
proposed unique_ptr).

It is not clear to me if this will require 1, 2 or 3 generic functions,
exactly what (if anything) has to be declared movable and/or const, and
if any other keywords will be needed to disable compile-time double move
detection.

-Howard

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

	C++Talk.NET Forum Index -> C++ language, library and standards	All times are GMT Goto page Previous 1, 2, 3, 4 Next
Page 3 of 4