Re: Go ahead. Stop programming. This ensures you from any mistakes.


In C macros may be O.K. In C++ the compiler is forced to compile every
header file again and again, only because a macro could be redefined and
expand completely to different code. This has nothing to do with copy /
paste

If you do not want the compiler to unwind the macros generating C code, you
can avoid using macros and generate the code by your hands.



Also readable - IMHO, without using macros. Same applies to C#.

It is not surprising -- in case of error, you leave resources unreleased.

Don't think so why should resources be unreleased ?

They should not be unreleased. They must be released. And in your example
you forget todo so leaving them allocated (leaked).



Yes, but what about a function: (in C)

void WIN32_CHECK(HRESULT value, char* log)
{
if (value != S_OK) ....
}
The code would be the same. The only difference would be that the macro
may expand to different code in release / debug versions. Which is
addressed in C# by conditional compilation, which IMHO is better, since
you can ship your application as both - debug and release in a single
executable.

Don't you understand that you need to exit the function in case of error.
And this is the function which invokes the checking routine rather than the
checking routine. You cannot raise an exception in C/C++ in the ellipsys.




[...]
RAII is the feature allocating resources in the stack? The object you
construct will be destroyed automatically right after the constructor
completes. Happy constructing.

Not only. It means (abstractly) that allocations and deallocations are
done in the destructor automatically.
If you embed objects in C++ in another object, they are destroyed too if
the parent object is destroyed.

You simply don't have to care about allocation / deallocation !!!

Abstragating from reality we can speak about anything. But the issue was
rolling back resourses in constructors in case of errors. The pattern

resourse = allocate();
try {
use(resourse);
} finally {
free(resourse);
}

where allocation and deallocation occurs in one routine is not applicable.


[...]
There is nothing about style mapping. There are guidelines of a company.
One of them is we do not use ternary operators. Instead of
func(cond ? a : b, cond2 ? x : y)
we write
if (cond)
{
if (cond2)
{
func(a, x);
}
else
{
func(a, y);
}
[....]
This is a perverse, redundant and thus moderen art.

It's not modern, but IMHO perhaps too much expanded.

The code above could be rewritten for example:

int v1, v2;
if (cond) v1 = a; else v1 = b;
if (cond2) v2 = x; else v2 = y;
func(v1, v2);

You have omited the braces -- one per line -- the authority demands :) The
important thing is that the code pile upers do not understand that the
ternary operator means you want to assign one or another value depending on
a codition. When you write the redundant code: "if (cond) v1 = a; else v1 =
b;" (variable to be assigned is specified twice), you may run into
inconsistency: "v1 = a; else v2 = b;". If you give a user a button telling
"never push it", they will one day. I suspect that the ternary op expands to
if-then-else at machine code level. However, the good design does not
exhibit any redundant parts.


.

Loading