In a big C++ project I would like to have a mechanism [...] to prevent such data in most parts.
There is such a mechanism. It is called code reviews - especially when done by the experienced guys in your team. Use that, and you will sucessfully avoid any unnecessary global variables in your project.
(And yes, I am aware that is probably not the answer ...
For me, I prefer having all my variables, not as pointers.
That's a good goal. If you are able to use C++11 or higher, that should be achievable for almost all use cases. The containers from the standard library and smart pointers make that possible. There will be exceptions but they should be rare.
Is it ok to keep all heap-allocated variables ...
how can I optimize my program's performance when the relevant profiler does not exist?
By profiling your code yourself. Finding GPU bottlenecks is not particularly difficult.
Assuming you have an inferior version of OpenGL (timer queries are not available), then you do what people have been doing for years: change stuff and see how it works.
There are ...
I've already adhered to best practices, like never have more than one lock locked at a time, always lock multiple locks in the same order, etc
Well, if you only hold one lock at a time, the second case never arises.
If you do actually have to acquire multiple locks, then reducing the number of locks (ideally to one) is better than making sure to acquire ...
You're focusing on the wrong code.
The point of the test isn't to prove that A or B do what they are supposed to do. The point of the test is to test that clients of A and B get what they need.
That's why you can write a test having no idea what C looks like and C should still pass this test. You can write the test before writing A, B, or C. That's because ...
You really need to learn the language. The first example doesn't compile. The second example, if Bar b is declared in a context where it compiles, allocates and constructs an object on the heap, then uses assignment to assign a copy in a local variable, and leaks the object on the heap.
You are not "keeping a pointer dereferenced", you are making a copy of ...
Is there a good method of developing a C++ program and quickly being able to switch between compiling it as a DLL and exe?
A better strategy will be:
Keep the DLL as is.
Create an EXE by linking against the LIB of the DLL. Put all the testing code in the files used to create the EXE.
In a diagrammatic form, you should have:
You also need to ask the reverse: what is the downside to using an object directly?
The answer is that the object version captures a B b and will not permit an arbitrary subclass of B to be injected — unless it offers a lossy conversion to B.
If B alone has sufficient customization for your scenario, maybe that's fine. But the pointer version ...
So in this example I wondered if I will gain better performance if I used pointer instead of an Object.
I will be very surprised if that is the case.
Also, what is the downside in the pointer-based approach?
You'll have to define ownership policy of the object that the pointer points to. If the client is expected to retain ownership of the object,
If your design complies with Liskov's Substitution Principe (LSP) (aka the L in SOLID) you can assume that class B shall pass the tests of class A. You may then structure your tests as follows:
make a first battery of tests for class A. These tests should check if the class fulfils its contrat, i.e. that for every method, given some preconditions, the ...
Since any test written for objects of type A works also for objects of type B, you can simply reuse all the tests for all methods you expect to behave similar for both classes. Obviously, you have to write new tests for those methods for which you expect a different behaviour.
The test fixtures for both classes could, for example, derive from a common base ...
Is it ok to keep all heap-allocated variables dereferenced?
There is no such thing as "heap-allocated variables". There are objects with dynamic storage duration (a.k.a. "heap-allocated"), but they are not associated with a name.
You can initialise an automatic storage duration (a.k.a. "stack-allocated variable") pointer object, from the result of a new ...
Some things can definitely be enforced by the compiler. Some other, unfortunately, cannot.
A good alternative to compiler warnings / errors is using a static analysis tool, configured appropriately according to your desires.
All "automated" solutions must be used as a tool during (the preparation of) a peer review.
As it was already suggested, the problem ...
Even in older C standards, according to Wikipedia, int is always guaranteed to have 16 bits at minimum, independently from the processor architecure. This goes along with a recommendation for int being the "the integer type that the target processor is most efficiently working with".
So for 8 or 16 bit processor architectures, I would usually expect int to ...
Elaborating on pschill idea, can I ask you why the following is not applicable to your case?
struct XItem:public ItemBase
struct YItem:public ItemBase
virtual vector<unique_ptr<ItemBase>> build () = 0;
struct XBuilder:public BuilderBase
vector <unique_ptr<ItemBase>> ...
If you're not already doing so, strict use of RAII can help make locking more deterministic. The only functions that are allowed to lock anything are constructors, and the only functions that unlock are destructors.
This may well end up with creating a "Locker" class, whose only function is to manage one lock. Creating a Locker object locks the resource, ...