Re: Java's performance far better that optimized C++
From: valentin tihomirov (valentin_NOSPAM_NOWORMS_at_abelectron.com)
Date: 06/21/04
- Next message: Alf P. Steinbach: "Re: void * instead of bool"
- Previous message: Razvan: "What is wrong with the following code ?"
- In reply to: tom_usenet: "Re: Java's performance far better that optimized C++"
- Next in thread: tom_usenet: "Re: Java's performance far better that optimized C++"
- Reply: tom_usenet: "Re: Java's performance far better that optimized C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 21 Jun 2004 23:08:24 +0300
> You are right that #include is the biggest problem for C++. OTOH, it
> makes writing make tools much easier, since dependency checking tools
> don't need to be able to parse the code beyond checing #include
> statements. Java dependency checkers have to be
Nevertheless, java tools are capable of analyzing code much more smartly
(you'told you use Idea).
> >> > try/ finally. This is a must to deallocate a dynamic resource. AFAIK,
> >> > enabled only in .Net VC++ .
> >>
> >>
> >> You mean the Finalizer. In the case of C++, Finalizer is defined as a
> >> regular destructor which of course will be called when the garbage
> >> collector destroys the object (for managed objects).
> >It is surprise for me that OOP programmer does not aware of finally
> >"clause".
>
> Why? "finally" has nothing to do with OOP - it's just an resource
> management feature of some languages that don't have deterministic
> object destructors.
Yes, but in systems which relay their error handling on exceptions (which
ensure you do not forget to handle the error) the finally clause is a-must.
It it needed for programmers not to forget to deallocate resources.
In C, most dynamic resources are allocated on the stack, exceptions are
rarely used. Not surprisingly, that C++ experts are not aware about this
critical feature. In OOP, objects are typically allocated dynamically on the
heap; therefore,
resourceObject = new Object();
try
use(recource)
fianlly
resource.free();
end;
is written as a prayer.
In C++ where objects are created on the stack, it is less topical issue.
> operator overloading, etc.).
Hardly this feature will make programs more reliable. Should we pull
properties and indexers from Delphi? I don't know.
> I'm sure there must exist a language that combines the strengths of
> can't access package private members of outer packages, for some
> ...
> strange reason).
Lately, the same desire visits me. I have a similar vision on the lang of
my dream. And when I think about it, "D" always comes to the mind.
- Next message: Alf P. Steinbach: "Re: void * instead of bool"
- Previous message: Razvan: "What is wrong with the following code ?"
- In reply to: tom_usenet: "Re: Java's performance far better that optimized C++"
- Next in thread: tom_usenet: "Re: Java's performance far better that optimized C++"
- Reply: tom_usenet: "Re: Java's performance far better that optimized C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
