memcpy

Quote:

---

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.

Quote:

---

Originally Posted by Elysia

I don't think that's quite possible all the times.

---

Why do you think that?

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.

Quote:

---

Originally Posted by Elysia

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.

---

The iterator principle is a superset of the pointer principle. This is perfectly valid:

Code:

---

int array[1000];
int dest[1000];

std::copy(array, array + 1000, dest);

---

In fact, the STL library in all likelihood has a specialization of std::copy() which just invokes memcpy() when dealing with POD types.

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

Yuck.

You can't really perform a copy in a type independent way. (Further, you can't treat an array polymorphically. Not that you would, but that code allows for the possibility.)

That said, templates were born to perform the same operation in a type dependent manor. With a combination of templates/polymorphisms/traits you can use much the same source you've proposed without writing a class for each type.

Soma

Quote:

---

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.

Quote:

---

Another misguided soul.

---

^_^

This is going to be fun.

Quote:

---

What gives you that impression?

---

Reality.

Quote:

---

Read brewbuck's post above.

---

I've done. He said nothing about 'std::copy' providing a type-independent way to perform a copy, but even if he did he would be wrong. (What he actually said, and is absolutely correct, is that 'std::copy' should be used in favor of 'memcpy' even for POD. He may have even have meant what you think he said, but he would be wrong even in the implication.)

A type-independent copy can not be performed in C++. You can, so long as you have the exact type, use a type-independent interface, but that is all.

Further more, if you could implement any type-independent copy then, by definition, you would never need another one... for any type regardless of polymorphic properties. (The closest you can come to this is to use traits and polymorphisms.) The moment you must query the exact type in order to tell that type to perform the copy you have failed--the copy logic must be written for each type and so the implementation is no longer type-independent.

Soma

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.

Quote:

---

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.

Quote:

---

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?

wow. ok. obviously templates are the way to go.

i had tried this in the past, but i ran into some problems, and i ended up thinking that i couldn't derive a template class from a non-template base class.

this will serve my purposes very well.