BitMaster

As I already said: if you find having the need to write an explicit copy constructor and and assignment operator you are in nearly all cases in one of two scenarios:

1) you are doing something wrong

2) you are writing a small RAII wrapper similar in task to std::shared_ptr/std::unique_ptr but with a more specialized focus.

 

The one major problem with writing unnecessary copy constructors and assignment operators happens is this: You have a class/structure containing a bunch of data member and all works well. And then you have to add one. Suddenly you have to remember modifying two functions. If you don't you might end up with an extremely annoying to find bug.

And of course no one likes writing code they don't need to. It costs time to write. It costs time to read it again when you are in the area. It costs time to modify when something changes. It costs time to debug.

And if you want to use a std::vector please add a copy constructor and the == and = operators.
 
Greetings,
Kim

In general, that is bad advise. The class originally posted by the OP does not need an explicit copy constructor or operator =. The compiler will generate one that does a perfectly fine job. Needlessly implementing copy constructors and assignment operators is one of the major sources of errors.
There are largely two types of classes: those that are noncopyable (in this case use something like inheriting from boost::noncopyable or the = delete syntax in C++11) or classes that should be able to copy themselves using the automatically generated functions.
If you find more than a tiny fraction of your classes need an explicit copy constructor and assignment operator you are probably doing something wrong with your class design. There are std::shared_ptr/std::unique_ptr that solve a lot of problems (alternatively their pre-C++11 counterparts in Boost). Similar, more specialized classes similar to these might have to be written by yourself, but these will be a tiny fraction of the classes written.

Having an operator == is nice, but not required for storage in a vector. If searching for elements in a container is a common use case I would rather worry about operator < (or a functor which can take that job) so I can store my elements in an always-sorted container like std::set/std::map or apply std::sort on my vector.

std::string is not a POD type. A pointer is. You cannot just write a pointer to a file though. A simple way to serialize a string would be to write an uint32_t to the file first which contains the length of the string followed by length chars as returned by myString.data().

If the type of objects you try to write to the file is not known at compile time then you first need to write something to the file identifying the type, be it an enum or an actual class name (the reader must then be able to create an instance of the appropriate class and deserialize it).

 

The whole issue of serialization is an extremely complex issue. There is no "this fits all" solution either. It can be quiet simple and become arbitrarily complex depending on what exactly needs to be serialized.

 

There is of course Boost Serialization but I doubt you have knowledge of sufficient to work with it.

Also, using plain delete after new[] is undefined behavior. Sadly it generally does not cause problems on MSVC but will as soon as you switch compilers, platforms or maybe next version.

First, using a map or four 1D arrays for simulating cards is probably the worst way to do it. Second, if you feel the need to new any C++SL container (like a vector), you are probably doing something very wrong. Third, I highly doubt you can random_shuffle iterators into a container which has order as something intrinsic to its very being, like a map.

I would say this question is a bit too broad to be answered. What exactly is causing you difficulties? Doing something like that is usually just a more or less annoying chore, depending on what exactly you have to work with, not something really difficult.

I don't have GLEW in front of me right now to check, but defining GLEW_BUILD sounds fishy. Typically, that sounds like a symbol that should only be defined while building the GLEW library itself, not anything depending on it.

You might have to define (or not define) GLEW_STATIC though depening on how you plan to link GLEW.

I think I oversimplified there. There is actually some very ingenious bit of template magic happening in the default deleter functor. It probably would have been more accurate to say the default deleter functor does something effectively like

delete static_cast<Type_originally_used_to_initialized_the_shared_ptr*>(pointer);

That's still a simplification of course, for a more complete picture the documentation and even the code of std::shared_ptr.

Indirectly yes.

MyMapType it = myMap.begin();
std::advance(it, index);

However, this is something you generally should not do. Unlike indexing an array (which is O(1)), indexing into a map is much more expensive (O(n)). Worse, most map implementations will have to traverse something like a linked list to do that which will often produce lots of cache misses.
If you need to access all map elements rather do something like this:
 

MyMapType::iterator it, it_end = myMap.end();
for (it = myMap.begin(); it != it_end; ++it)
   doSomethingWithKeyValue(it->first, it->second);

Or, if you are on C++11:

for (const auto& value : myMap)
   doSomethingWithKeyValue(value.first, value.second);

By the way, since the type can get annoying to write out, it is common to typedef your map types, so that you only have to write

MyMapType::const_iterator it = ...

Since templates in non-trivial systems can get very verbose this could replace lines of typing but also makes it possible to efficiently refactor your code. An std::map has at least four template parameters. If any of them change, you would have to modify every place where you use an iterator or similar construct. If you properly typedef'ed it, you just have to change one line.

 

Of course if you have C++11, it's just

auto it = key.find(...);

operator [] is only defined for non-const maps. operator [] inserts a new entry into the map if the key does not exist, which is not possible for a const map. For const maps use something like this:

std::map<std::string, Bone*>::const_iterator it = key.find("whatever");
if (it != key.end())
   doSomething(it->second);

Unless you can absolute guarantee that the key exists in the map (calling the map key is not exactly a good naming convention by the way) you should not try to access a result of find without this test.

No one can remotely help you there. Just attach the debugger and debug it as you would any other problem. If you do no know how to debug yet, you have to make it your single most important priority to learn it.

 

That said, I would advise against just turning any non-trivial x86 project into an x64 project. There is far too much that can systematically cause problems when x64-compatibility was not a design decision from the start.

you and renega_666 misunderstand what i mean, for example, i do not know rsa, but i can use it easily with CryptoAPI, of course rsa is important

And here you misunderstand what we mean. Homogeneous coordinates are not some arcane detail of graphics programming - they are central to it and no one can seriously use a graphics API without knowing about them.

Just to reinforce what renega_666 already said: in the context of any graphics programming (and if you have to touch shaders, you are way in), not knowing about homogeneous coordinates is like taking a job as a driver, then get into the car, point at the steering wheel and ask 'What's that?'. 

It's the homogeneous coordinate. I would strongly suggest reading more graphics theory before proceeding.