Re: C++ Homework. Please help :-)
On Mar 18, 9:12 pm, Seungbeom Kim <musip...@bawi.org> wrote:
Marsh Ray wrote:
On Mar 9, 3:10 am, Seungbeom Kim <musip...@bawi.org> wrote:
Unfortunately that's how those things are usually implemented, but
that's not an essential part of their meanings.
++preincrement : you start with one value and end up with one value
postincrement++ : you start with one value and end up with two
distinct values
By using the phrase "end up", you're emphasizing the value *after*
the increment. However, taking the value *before* the increment is
also a totally natural thing to do.
I wasn't trying to emphasize either the before or after states. Just
to point out that, assuming the variable is referenced later
(otherwise postincrement becomes a no-op) postincrement requires
construction of a new object somewhere. The dataflow diagrams are
different. To me that difference is essential and interesting, but I
may be just weird that way.
a a a a
| | | |
"++a" "a++" "a += 1" "a + 1"
| / \ | / \
a' a a' a' a b
Hmm, preincrement looks more like the += assignment, while
postincrement looks more like a traditional nonmutating binary
operator (albeit with the result slots reversed)!
In light of this, I may just have to reconsider my opinion that one is
more natural than the other.
(Maybe more natural; generally,
starting with the first stuff, you process something *and then*
advance to the next, not the other way round. That's what the 'for'
loop models, after all.)
Sure, but in order for that analogy to hold, the object being
postincremented has to be referenced exactly once during the
processing, and it can't do anything except return its per-iteration
value.
So how often does one re-implement strcpy() these days?
Is there any way to implement the some reasonable semantics for
postincrement that doesn't somehow involve construction of a new
value?
[]
I had suggested one in the thread I mentioned earlier in this thread.http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thr...
That is an interesting thread. You still involve the construction of a
new value, but one of a different lighter-weight type.
Looks like it would be difficult to ensure that the proxy's members
~proxy() { ++*subject; }
operator big&() const { return *subject; }
are executed in the correct order.
void f() {
big b;
auto const & c = b++; // c is the proxy, no?
cout << b << endl;
cout << c << endl;
// b incremented here
}
people tend to avoid writing
operations that look naively simple but turn out to be expensive
Wait.. isn't that what object-oriented operator overloading
abstraction is all about?
Maybe, and it certainly allows an elegant expression of the concept.
But then we may have to pay the "abstraction penalty" sometimes.
For example, with std::string objects, (s += a + b + c) is certainly
elegant,
I dunno, does it bother anyone else to use '+' for an operation that
is not commutative?
Still, somehow "string s = hello - world" doesn't have quite the same
appeal to it :-)
but it may not be as efficient as (s += a, s += b, s += c).
Therefore, sometimes the choice is made to sacrifice the elegance and
encourage^Wforce the client to use a less elegant but more efficient
form.
Thankfully with C++ you can choose how much abstraction you want to
pay for, and frequently it costs very little.
- Marsh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]