Quote:Original post by Anonymous Poster
Quote:Original post by MaulingMonkey
They're the same in terms of namespace polution, I'd argue.
Not IMO. memcpy is something cryptic you very likely wouldn't use as a function/method/whatever name yourself, whereas copy is clear english and nice and short, so it might very well be used.
When you include stdlib.h, or use the entire std namespace, you get much more than just memcpy, hence the problem.
I've run into clashes with (std::)system() vs my own system class before, the fact is that there's plenty of names you might want to use in stdlib.h
It dosn't matter if it's 20 or 100, fact is, the namespace will be poluted, period.
My solution has generally been to never write anything in the global namespace. The implementation of main usually follows this layout in my projects:
namespace project_name { int main ( int argc , char * argv[] );}int main ( int argc , char * argv[] ) { return project_name::main( argc , argv );}
EDIT: DD edited out his post after the fact it'd seem, which I realized as I started to merge two consecutive posts by myself into one... I feel like keeping my comment on the matter though:
Quote:Original post by DigitalDelusion
one could even be so bold as to advice making the code truly selfdocumenting and mind numbingly obvious by doing:
template <typename SrcItr, typename DstItr>inline DstItr copy_n(SrcItr first, DstItr out, typename std::iterator_traits<SrcItr>::difference_type count){ return std::copy( first, first + count, out);}
Bad idea IMO, argument order is not intuitive to me, plus it goes against existing practice as set by SGI (
linky) where count is the second, not the third, argument.