Thread: memcpy

Originally Posted by brewbuck

Using memcpy() on non-POD data types is wrong. Period. Use std::copy().

Better yet, don't use memcpy at all in C++, always use std::copy() in C++.

I don't think that's quite possible all the times. Only don't use memcpy on classes. They should have a proper assignment operator for that.
But in most cases, you want to avoid memcpy in the first place.

Because all things might not be C++ and sometimes you do things the C way, and then std::copy won't work at all. I'm no expert at it, but it works on iterator principle which means the type you're copying needs to support that.

there seem to be a lot of "why do you want to do this" comments.

i'd like an all-purpose type-independent assignment function.

this is not my code, exactly, but it should demonstrate the principle of what i am trying to achieve:

Code:

class task
{
        public:
        task();
        virtual void exec()=0;
};

class setVar : public task
{
        private:
        void *src;
        void *dest;   
        const unsigned int size;    
        public:
        setVar(void *Src,void *Dest,const unsigned int Size) : task(),size(Size)
        {
                src =Src;
                dest=Dest;
        }
        virtual void exec()
        {
                memcpy(dest,src,size);
        }
};

class thread
{
        public:
        DynamicArray<task *>tasks; // similar to vector
        void Execute()
        {
                for(int i=0;i<tasks.Length;i++)
                {
                        tasks[i]->exec();
                }
        }
};

if i don't have a type-independent copy function, then i don't see how i could set a variable in this fashion without having a descendant for each type.

it sounds like std::copy is a good choice; assuming std::copy(src,src,dest) is a valid statement; i.e. (first == last) != problems

Originally Posted by phantomotap

You can't really perform a copy in a type independent way.

Another misguided soul. What gives you that impression?
Read brewbuck's post above.

m37h0d: No there are no problem with copying an empty range, i.e. where first == last.
Your ad-hoc usage of constructor inivialisation lists seems a bit unusual, and your usage of void* at any level is rather worrying.

You can't copy something without knowing its type, that's true. However, I've never yet seen the need. If you need an opaque method of data transfer, use a boost::any.

OK well obviously you didn't mean what I thought you meant when you said "type-independent". I thought you were thinking of the same thing as Elysia. I'll happily say that you are not misguided in this way here.

What I mean is for example that whatever the types passed to std::copy are, it will have the desired effect. To me, that's "type independent".
You seem to be arguing something even more fundamental, so perhaps I was just caught off guard by your terminology. I'm not so much interested in a more philisophicial discussion. I think we're well aware of what you can and can't do in regards to copying with C++.
Okay I hadn't considered slicing. I'll accept that as a counter to my thinking above. All I care is that std::copy is as good as you're going to get in C++.

"As good as you get" are copy constructor and copy assignment. std::copy can merely repeatedly execute them for a sequence.

Originally Posted by iMalc

Your ad-hoc usage of constructor inivialisation lists seems a bit unusual,

yes, i suppose it is a bad habit. i honestly didn't know there was any difference in performance until i looked it up just now.

Originally Posted by iMalc

your usage of void* at any level is rather worrying.

void * is the type accepted by memcpy. also, if i'm trying to refer to data of any type in a single, general way, how else could this possibly be achieved?