Let's get pedantic, because there are differences that can actually affect your code's behavior. Much of the following is taken from comments made to an "Old New Thing" article.
Sometimes the memory returned by the new operator will be initialized, and sometimes it won't depending on whether the type you're newing up is a POD (plain old data), or if it's a class that contains POD members and is using a compiler-generated default constructor.
- In C++1998 there are 2 types of initialization: zero and default
- In C++2003 a 3rd type of initialization, value initialization was added.
Assume:
struct A { int m; }; // POD
struct B { ~B(); int m; }; // non-POD, compiler generated default ctor
struct C { C() : m() {}; ~C(); int m; }; // non-POD, default-initialising m
In a C++98 compiler, the following should occur:
new A
- indeterminate value
new A()
- zero-initialize
new B
- default construct (B::m is uninitialized)
new B()
- default construct (B::m is uninitialized)
new C
- default construct (C::m is zero-initialized)
new C()
- default construct (C::m is zero-initialized)
In a C++03 conformant compiler, things should work like so:
new A
- indeterminate value
new A()
- value-initialize A, which is zero-initialization since it's a POD.
new B
- default-initializes (leaves B::m uninitialized)
new B()
- value-initializes B which zero-initializes all fields since its default ctor is compiler generated as opposed to user-defined.
new C
- default-initializes C, which calls the default ctor.
new C()
- value-initializes C, which calls the default ctor.
So in all versions of C++ there's a difference between new A
and new A()
because A is a POD.
And there's a difference in behavior between C++98 and C++03 for the case new B()
.
This is one of the dusty corners of C++ that can drive you crazy. When constructing an object, sometimes you want/need the parens, sometimes you absolutely cannot have them, and sometimes it doesn't matter.
If anyone would ever run into the same problems as I did, he can find the discussion and solution over at the MSDN 'forum'.
OK, I found it, LibraryPath corresponds to Library Directories property in VC++ Directories project property page. That explains what happened, that value is usually inherited so it changes automatically when you create add x64. But since you modified that value it is now local to the project and it simply gets copied when add x64... with all those x86 specific dirs.
I suppose it's simpler and safer to just add that lib dir in Linker\General\Additional Library Directories
Best Answer
Adding a new configuration never works - it's something the tools team I think never actually tried. It didn't work in eVC 3.0 or 4.0 and still doesn't in Studio.
Create a new project using the app wizard, selecting your SDK. When you are done, just use "Add Existing" to add all of your code in.
BTW, your app can probably run using the old project and binaries anyway. ARMv4i will run ARMv4 binaries without any problem. The only potential issue is that if you're moving from a Pocket PC to a generic CE device. If the app used any Pocket PC specific APIs, those call will fail under CE.