On Tue, 28 Sep 1999, S.D.Mechveliani wrote:
> >> I understand this so, that this particular task allows to set
> >> `const'. Because first, condition1, condition2 apply to the
> >> vector x; as they do not modify x, next_permutation(x)
> >> yields the correct value when applied after them.
> >>
> >> Probably, other tasks and `condition1' variants would not allow to
> >> set `const' like here.
> >> Do i understand right?
> >> And for these cases the ratio is smaller, say, 6, as showed the
> >> earlier test - ?
>
>
> > No. `const' here probably has no effect on the efficiency.
> > The difference in efficiency is due to the copying, which is
> > because your original C++ program unwisely used pass-by-value,
> > rather than pass-by-const-reference. Most likely pass-by-reference
> > and pass-by-const-reference will have exactly the same performance.
>
>
> Sorry, this C so so difficult ...
> What i wrote on `const', probably it refers to `&'.
> Because in the initial program x of type vector was passed to
> `condition1' (if i recall right).
> And now appears `&' (right?). That is passed is the pointer to the
> vector.
> Now, if i reformulate my last assertion `>> .. '
> replacing `const' with `&' will it be true?
I think you're in an unfortunate position Sergey: you sound like you
learned C for `extensive' use and have only picked up C++ informally,
whereas the distinction we're talking about here is unique to C++.
(This is because C uses only raw pointers rather than giving also the
option of safer references.) To try and answer your question:
* making arguments const refs is possible precisely when the function only
looks at the class, not if modification is desired
* if you used just &x and modified x then you're right: next_permutation
would generate different values and you'd lose the neat guarantee that you
will cycle through all permutations
* when Fergus talks about copying this is in the C++ sense of invoking the
copy constructor; this actually consists of allocating memory and making a
copy of the vector's contents. _IF_ most of the time is spent allocating
as opposed to copying, you might be able to get almost the same efficiency
by having x and temp_x as vectors defined in main, copying the contents of
x into temp_x before each call and then using &temp_x (in an imperative
language overwriting existing allocated memory isn't unreasonable if it's
a simple case, as this is); _IF_ the copying overhead is big then having
condition[1|2] need to modify a version of x will slow down the C++
significantly, as you suggest in your question.
* however if condition[1|2] can't easily be written in C++ without needing
to modify a copy of it's argument then the Haskell equivalent will also
need to do this, so the Haskell program will be slower too. Because the
haskell run-time will allocate the memory one-list element at a time
whereas the C++ most natural allocates the worst-case memory requirement
at the beginnig, I'd guess you get a smaller ratio if on average you only
build a small part of the new list before you know what the outcome of the
test is but you get a bigger ratio if on average you need to look at
almost the entire new list before you know the outcome of the test.
* from where i sit, further `adjustments' to such a small fragment of code
are unlikely to occur `in the real world'
hope this helps.
PS: I'm on the list so feel free to remove my name from the Reply To line
:-)
___cheers,_dave_________________________________________________________
email: [EMAIL PROTECTED] "He believed in substitions
www.cs.bris.ac.uk/~tweed/pi.htm sometimes things just
work tel: (0117) 954-5253 just happen" -- Terry Pratchett, Jingo
