already used in a 'child' scope to denote something else

[valentin tihomirov]

{
int i = 2;
}
int i = 1;

There is no 'i' defined in the 'parent' context from the moment of
declaration on. So what is the problem? They tell us they pursue language
simplicity. The rule "do not define a variable more than once in the same
context" is natural, and simplest therefore. All normal languages obey it
therefore. Overcomplicating a grammar by injecting more barrieres is a path
right away from simplicity. Another obstacle at the plain place introduced
in C# for no reason is blocking "fall throughs" in switch -- the feature
wich can be very useful sometimes. C# designers demonstrate some excessive
zeal on 'protecting' us from doing things naturally, going strightforward
ways.

"Give a fool rope enough and he'll hang himself."

[valentin tihomirov]

Now 1 and 3 are essentially the same length and complexity. In fact, 3

eliminates a preposition. Is 3 therefore preferred?

Ok, I will not tell which of 1 and 3 is better/more beautiful. The issues is
not the numer of letters. The issue is that you should repeat the same
pattern over and over again. And duspute reduction. Which is stupid.

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

valentin tihomirov wrote:

1. He went to home.
2. A gived individual of man sex consciously performed a process of foot
transportation with normal speed in past time towards an object, which
represents a place of permanent resedence of given subject.

The first sentence doesn't specify the means of transportation, it can
just as well mean that he went by car. Neither does it specify the speed
of the transportation.

Also, "to home" doesn't even specify that it was his own home. It could
be anybodys home.

I am aware that you probably meant "He walked home", but this
demonstrates how redundancy makes a sentence clearer. Eventhough the
second sentence contains more errors than the first, it's still clear
what it means.

The same happens if a programming language is too terse. The compiler
can't help you spot faulty code, as the code may still be valid but
means something completely different.

(Isn't it funny when you can use someones example to argue the opposite
of the point he was trying to make? ;)

--
Göran Andersson
_____
http://www.guffa.com

[Ben Voigt [C++ MVP]]

"valentin tihomirov" <V_*********@best.eewrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

>This is the foundation of RAII. You will become a much better programmer
if you study some examples, before telling us about all the things C++
can't do, when in reality RAII provides them perfectly.

I fahve seen tons of C++ examples in MSDN. Do not remember if if they ever
use any exceptions. They do everything in C style (besides object
instantiation). Macros just collapse the pattern, which constituates all
the win32 code:

MSDN doesn't use C++ for examples, because Win32 API is pure C.

>
handle = Create...
if (handle == invalid) {
printf(last error)
return
}
handle2 = Create ...

to mimic exceptions.

And tell me how your RAII perfectly handles these cases and how we do not
need finally. We do not need finally for the reason nobody uses exceptions
in C++.

C++ destructors are called during exception stack unwinding. No finally
block is ever needed.

I don't understand what makes you incapable of researching RAII so that I
have to tell you about it. Try http://en.wikipedia.org/wiki/RAII

>
The case of "100% automatic destruction" on explicit (manual) destructor
call is especially funny.

That was when the _parent_ object is explicitly destructed, the child
objects are automatically destroyed.

[valentin tihomirov]

C++ destructors are called during exception stack unwinding. No finally
block is ever needed.

I speak about dynamically created objects. Your RAII does not apply to
heap-allocation.

byte* buf = allocatemesomedata(size); // will this be freed in case of
exception?
AbstractClass o = new Subclass(); // will the destructor of 'o' be called
automatically?

Anyway, RAII dow not address the problem of partially created objects.

[Andre Kaufmann]

valentin tihomirov wrote:

>C++ destructors are called during exception stack unwinding. No finally
block is ever needed.

I speak about dynamically created objects. Your RAII does not apply to
heap-allocation.

Don't think so.

Smart pointers are for example used for heap allocated objects.
E.g.: boosts shared_ptr (AFAIK will be part of the next C++ standard)

shared_ptr<byteheapAllocated = allocatemesomedata(size);

byte* buf = allocatemesomedata(size); // will this be freed in case of
exception?
AbstractClass o = new Subclass(); // will the destructor of 'o' be called
automatically?

Yes if you use boosts smart pointers or auto_ptr of the C++ library:

std::auto_ptr<AbstractClasso (new SubClass());

Anyway, RAII dow not address the problem of partially created objects.

Why ? Partially constructed objects will be destroyed partially - if you
are using RAII and not plain pointers.

RAII is very powerfull. One of the (only) reasons I still use C++.

Andre

[valentin tihomirov]

>Anyway, RAII dow not address the problem of partially created objects.

Why ? Partially constructed objects will be destroyed partially - if you
are using RAII and not plain pointers.

RAII is very powerfull. One of the (only) reasons I still use C++.

How does RAII knows how far the resourse allocation has reached? How does it
jump to the point in the destructor to free only the allocated objects? The
case switch is ideal to jump to that point.

That was the origin of this discussion branch. BTW, those who thing that the
'switch' is an n-ary variation of bivalent 'if', it would be more
reasonable embrace the conditional code into {} as it matches in Pascal
rather than using 'break's, which are loop-breaking statements. The code in
loops is normally "falls through" from one instruction to the following.

[Andre Kaufmann]

valentin tihomirov wrote:

>>Anyway, RAII dow not address the problem of partially created objects.

Why ? Partially constructed objects will be destroyed partially - if you
are using RAII and not plain pointers.

RAII is very powerfull. One of the (only) reasons I still use C++.

How does RAII knows how far the resourse allocation has reached? How does it
jump to the point in the destructor to free only the allocated
objects? The

Well I'm not that experienced in compiler technology.
Simplified I would describe it this way:

The compiler holds a list with pointers to the destructors of the
created objects and simply calls them in reverse order, if anything goes
wrong (exception) or the object is destroyed.

Andre