valentin said:
[...]
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.
The problem is the compiler / standard has to support macros (which
affect multiple files). So to be compliant they cannot be simply removed
and in C++ commonly some proprietary workarounds like precompiled header
files are used.
[...]
They should not be unreleased. They must be released. And in your example
you forget todo so leaving them allocated (leaked).
To make the example more complete:
Instead:
CHECK(resource1 = allocate1())
CHECK(resource2 = allocate2())
CHECK(resource3 = allocate1())
in my example you would write:
if (!create()) destroy();
or assuming that exceptions are thrown:
try { create(); } catch(System.Exception e) { destroy(); }
Don't you understand that you need to exit the function in case of error.
Where is the difference if a macro returns an error or throws an
exception or a function ?
Your macro will only reduce code like:
if (!WIN32_CHECK(value, "log function")) return false;
if (!WIN32_CHECK(value, "log function")) return false;
if (!WIN32_CHECK(value, "log function")) return false;
to (Macros used):
WIN32_CHECK(value, "log function");
WIN32_CHECK(value, "log function");
WIN32_CHECK(value, "log function");
The problem is - if you read the code you can't see what the macro is
doing. How do I know if it leaves the function ?
In C++ I won't care (normally - but there are exceptions too), in C and
C# I have to care. Therefore it's IMHO not an good idea to write macros,
which simply are leaving a function.
For this kind of error handling IMHO exceptions have to be used.
The big problem IMHO in C# and C is that a programmer has to care about
exceptions too much, if a locally allocated object uses resources.
Meaning that you have to call Dispose manually.
Fortunately there is
using (....) {}
in C# which at least helps for local function scope.
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.
Why not ? And in C++ you don't have to care if an exception is raised.
The compiler calls destructors automatically. In C# you don't have to
care only about objects holding resources (file handles, etc.).
In C you have to care about everything.
Abstragating from reality we can speak about anything. But the issue was
rolling back resourses in constructors in case of errors. The pattern
Sorry my newsreader has cut down the whole thread. Hmpf, not the first
time of my open source reader doing this.
In C++ resources are also freed if an exception is thrown in an objects
constructor. Though I wouldn't do this anyways. Neither in C# nor in any
other program language. Just because of the problems we are discussing
about.
resourse = allocate();
try {
use(resourse);
} finally {
free(resourse);
}
where allocation and deallocation occurs in one routine is not applicable.
I have simply matched your macros with functions using a simple boolean
instruction or null as default value for my objects.
You claimed that in OOP you have to write:
##[start of quote]
void create() {
allocate1();
try {
allocate2();
try {
allocate3();
try {
allocate_last();
} catch {
destroy(label3);
throw;
}
} catch {
destroy(label2);
throw;
}
} catch {
destroy(label1);
throw;
}
"
##[end of quote]
I just claimed that you can do it:
Object o1 = null;
Object o2 = null;
try
{
.....
}
catch(System.Exception)
{
o1.Dispose(); // destroy - meaning freeing resources
o2.Dispose(); //
}
But commonly in C# you don't have to care about, if the objects don't
hold any resources which immediately have to be freed.
[...]
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
It should only prevent the multiple if then else clauses. Which IMHO
aren't more readable than the ternary operator.
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.
I think rather the ternary operator would not directly match to
if-then-else but rather to a helper function:
func(Select(cond, a, b), Select(cond, x, y));
int Select(bool condition, int a, b)
{
if (condition) return a;
return b;
}
But when your authority demands it to expand to if - then - else, it may
be so. We could continue the discussion but that won't help you changing
the mind of your authority ? ;-/
Andre
