Thanks for your work so far on all this. I really appreciate the effort, and it has already paid off: the test passed yesterday and today on my Debug VS dashboard.<div><br></div><div>I will give a try to your latest patch set with the added assert calls later today.</div><div><br></div><div><br></div><div>Thanks,</div><div>David</div><div><br><br>On Tuesday, October 27, 2015, Luc Hermitte <<a href="mailto:luc.hermitte@c-s.fr">luc.hermitte@c-s.fr</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 27/10/2015 17:04, David Cole a écrit :<br>
> I do prefer a test.<br>
<br>
The alternatives are not just test+std::copy VS no-test+std::copy. But<br>
test and std::copy VS manual loop where the test is pointless as it's<br>
already part of for() invariant.<br>
<br>
> This is C++. You should always check for nullptr<br>
> if it is possible to get nullptr, and something bad could happen if<br>
> you don't check.<br>
<br>
It's the "something bad could happen if you don't check" that makes all<br>
the difference here and that explain my reluctance.<br>
<br>
i.e. nothing bad should happen with usual/naive implementations of<br>
std::copy with std::copy(p,p, nullptr) -- if memcpy is triggered, I must<br>
admit my ignorance, and as others have said, it would be very<br>
surprising:<br>
<a href="http://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0" target="_blank">http://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0</a><br>
<br>
[On a side note, it's up to the client code to check for nullity if<br>
nullity is rejected by the contract. Within the service code, we could<br>
wait for C++17, or more likely use assertions.]<br>
<br>
> If you could prove to me that there is never a<br>
> nullptr in this context, I would not care. But there is. The failing<br>
> test proves it.<br>
<br>
<br>
> Rather than thinking of this as "just to workaround the implementation<br>
> of a function in Debug mode and with a single family of compiler,"<br>
> perhaps you should instead think of it as defensive programming.<br>
<br>
That's my problem. I see it exactly as defensive programming. Unlike<br>
(narrow) Design By Contract, the (wide) defensive programming approach<br>
adds tests that make no sense (in context were the contract is<br>
respected), and complicate the nominal code.<br>
<br>
<br>
> The fact is, these debug checks from Microsoft have helped and<br>
> assisted me over the years FAR MORE than they have hurt. They help to<br>
> detect problems early on, as soon as incorrect code is introduced and<br>
> run. Yes, they're painful, and yes, sometimes slightly too aggressive.<br>
> But they're worth it.<br>
<br>
I completely agree they are worth it. This time, the test (on copy -- as<br>
I've workaround the one on fill) is as you said : too aggressive.<br>
<br>
<br>
> Let me know if you would like me to build/run your patch set after you<br>
> think you have it to the point where the Debug MS build should run<br>
> without raising these assert dialogs.<br>
<br>
Yes please, I'd like to.<br>
<br>
Here is a patched (I hope -- memset and memcpy may trigger assertions, I<br>
don't know) version of the code.<br>
<br>
<a href="http://review.source.kitware.com/#/c/20313/" target="_blank">http://review.source.kitware.com/#/c/20313/</a> (I didn't know if, and how,<br>
I could take over the previous patch set on the subject. Sorry for the<br>
inconvenience)<br>
<br>
On the way, I've added missing documentation regarding invariants,<br>
preconditions and postconditions, plus the related assertions. This is a<br>
first draft. It's likely to contains English errors. I hope, however I<br>
did not assert incorrect contracts in the documentation. I'll read it<br>
again more carefully later.<br>
<br>
I've also added code to test operations on empty VLV.<br>
<br>
<br>
Thank you.<br>
<br>
--<br>
Luc Hermitte<br>
</blockquote></div>