 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Digby Millikan
Guest
|
 Posted: Thu Dec 02, 2004 1:22 pm Post subject: .NET illconceived |
 |
|
..NET libraries for C++ is a step backwards, C++ is often used for scientific
and
engineering applications, it's main feature being it's high speed and
efficiency, many
applications written on Unix Workstations (one of which I have with a C++
compiler),
but with such superior development environments such as BCB and user
friendly
operating system, the Windows environment is slowly taking over from the
UNIX
market as pc power improves and Windows becomes more robust.
Managed C++ is more like interpreter basic, does not support the STL, is
this a bad
attempt for Microsoft to compete with VCL, RAD development with the
requirement
of managed overheads. Borland VCL C++ please!!
|
|
| Back to top |
|
 |
Eric Grange
Guest
|
|
| Back to top |
|
|
Jack
Guest
|
| Posted: Thu Dec 02, 2004 7:09 pm Post subject: Re: .NET illconceived |
|
|
"Digby Millikan" <digbym (AT) internode (DOT) on.net> wrote
| Quote: | .NET libraries for C++ is a step backwards, C++ is often used for scientific
and
engineering applications, it's main feature being it's high speed and
efficiency, many
applications written on Unix Workstations (one of which I have with a C++
compiler),
but with such superior development environments such as BCB and user
friendly
operating system, the Windows environment is slowly taking over from the
UNIX
market as pc power improves and Windows becomes more robust.
Managed C++ is more like interpreter basic, does not support the STL, is
this a bad
attempt for Microsoft to compete with VCL, RAD development with the
requirement
of managed overheads. Borland VCL C++ please!!
|
Managed C++ is not an interpreted language but "just in
time compiled". Not only it is relatively fast, but also
the executable is much smaller. You might be able to fit
quite advanced program on a single floppy like in the
good old days and still have a room for data :-)
I agree with you, that it has ugly syntax and lacks STL,
but you are mistaken on the speed issue. Especially for the
engineering applications managed C++ is actually way faster
than Borland C++ 6.0. I advise you to download Beta 2005
Visual C++ Express for free to test it against Borland.
MS Visual C++ 2005 Express Beta is FREE to download,
quite stable and allows you to compile both, managed and
native Win32 applications with optimization.
If you try for example natural logarithm, power function,
trygonometry or square root on a 64 bit floating point double
in a long loops you will see major differences between the
MS VC++ and Borland C++. Borland is simply no match for native
VC++ in engineering floating point functions. In managed
version MS VC++ is still faster although by a smaller margin.
Even VC# in those tests run faster than Borland although
for some reason not quite as fast as managed VC++. This
is no surprise between VC++ and VC# because engineering
functions are from "Math" library common for all .NET
languages. It is more surprising, why C# is not exactly
as fast as managed VC++ but that is a sdifferent subject
altogether.
The 2005 version of VC++ in addition supports STL and has
much more improved syntax.
Originally I thought the same as you do, that Managed
VC++ or VC# must run way slower than C++Builder especially
in engineering floating point function which were also my
primary interest. When Microsoft posted VC++ 2005 and
VC# 2005 Express Beta versions online I downloaded them to
find out how much they "must be" behind Borland. To my
surprise the opposite is true and I must admit, I'm sorry
to say so since I always liked Borland over Microsoft
products. In native MS VC++ for engineering applications
simply outclassed Borland and in managed version they still
win majority of the tests. Quite frankly the only test that
Borland C++ won over the managed C++ and C# was the large
double array manipulation - access in which the array used
in Microsoft products was a .NET array class with built in
boundary checking and the Broland win turned out to be a
miniscule one within 10% of running time margin.
If you use C++ native array even in managed VC++ instead
of managed array it again runs faster than Borland.
Borland could not even win all tests with C# except the
array access one and unlike with VC++, with C# you don't
have an option of native arrays
If you wish to check my data I can post the source
code and some test outcomes for a further discussion.
JM
|
|
| Back to top |
|
|
Tamas Demjen
Guest
|
| Posted: Thu Dec 02, 2004 10:37 pm Post subject: Re: .NET illconceived |
|
|
Digby Millikan wrote:
| Quote: | Managed C++ is more like interpreter basic, does not support the STL
|
I'm not saying .NET is superior in every aspect, but it's not as bad as
interpreted BASIC.
MC++ and C++/CLI both are extensions to the C++ language, and they can
compile conventional unmanaged code. .NET programs are not interpreted,
they're compiled to machine code before execution. The .NET Framework
caches the pre-compiled modules, although the Compact Framework does not
(it still pre-compiles, though, in the memory). So the first time a
managed method is called, it takes slightly longer. If you like, you can
pre-compile your entire application in advance, and distribute it that way.
The .NET memory manager is in fact even faster than malloc or new, at
least as long as there's enough free memory. Unforunately the GC has to
block all managed threads while doing its job, and the worst thing about
this is that it's not deterministic. Unmanaged threads are not blocked,
though. On the other hand, using reference counting instead of GC has
its own performance problems, too. This page describes exactly what kind
of difficulties the MS engineers faced while looking for a solution to
automatic garbe collection techniques:
http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572
You can still use the STL in unmanaged code, and use STL.NET in managed
code, although that's not a part of the VS2005 public beta yet. Here's
an article about STL.NET:
http://msdn.microsoft.com/visualc/default.aspx?pull=/library/en-us/dnvs05/html/stl-netprimer.asp
What I like in .NET is that finally we can put classes in DLLs, don't
worry about memory management between DLL boundaries (we can pass
strings to a DLL), and can throw exceptions between DLL boundaries, in a
portable and standard way.
| Quote: | Borland VCL C++ please!!
|
That would be nice.
Tom
|
|
| Back to top |
|
|
Oscar Fuentes
Guest
|
| Posted: Thu Dec 02, 2004 10:53 pm Post subject: Re: .NET illconceived |
|
|
Tamas Demjen <tdemjen (AT) yahoo (DOT) com> writes:
[snip]
| Quote: | What I like in .NET is that finally we can put classes in DLLs, don't
worry about memory management between DLL boundaries (we can pass
strings to a DLL), and can throw exceptions between DLL boundaries,
|
Are you implying that there is no C++ implementation that can do this?
The compilers I use does this since years ago.
| Quote: | in a portable and standard way.
|
.... as long as you use the MS compiler, right?
[snip]
--
Oscar
|
|
| Back to top |
|
|
Tamas Demjen
Guest
|
| Posted: Thu Dec 02, 2004 11:13 pm Post subject: Re: .NET illconceived |
|
|
| Quote: | Are you implying that there is no C++ implementation that can do this?
The compilers I use does this since years ago.
|
Not in a standard way. And tell me how you would load such a plugin
dynamically? Because the OS doesn't support that. There's no Win32 API
function for that. There's only LoadLibrary, and GetProcAddress, none of
which is capable of loading a class.
Of course if you use the same compiler with the same settings, and you
use the dynamic Borland memory manager, and you load DLL files
statically, then you can do anything in DLLs that you can do in a LIB
file. It's just not portable.
| Quote: | ... as long as you use the MS compiler, right?
|
As long as you use .NET -- any language, any compiler, any platform.
Borland may just create a C++ .NET development tool in the future. Then
Borland DLLs could be mixed with Microsoft ones. Right now it's very
fainful to develop a plugin architecture where the main application is
written in BCB, but the (non-visual) plugins are developed in VC++. It's
possible, but it's painful, especially when the DLL has to return
something complex, such as a vector of strings. You can't just use STLs,
and you have to pass a pointer to an allocator, because the DLL's memory
manager is not compatible with the application's.
Tom
|
|
| Back to top |
|
|
Oscar Fuentes
Guest
|
| Posted: Thu Dec 02, 2004 11:47 pm Post subject: Re: .NET illconceived |
|
|
Tamas Demjen <tdemjen (AT) yahoo (DOT) com> writes:
| Quote: | Are you implying that there is no C++ implementation that can do this?
The compilers I use does this since years ago.
Not in a standard way. And tell me how you would load such a plugin
dynamically? Because the OS doesn't support that. There's no Win32 API
function for that. There's only LoadLibrary, and GetProcAddress, none
of which is capable of loading a class.
Of course if you use the same compiler with the same settings, and you
use the dynamic Borland memory manager, and you load DLL files
statically, then you can do anything in DLLs that you can do in a LIB
file. It's just not portable.
|
But, by using the MS compiler, aren't you doing exactly that?
| Quote: |
... as long as you use the MS compiler, right?
As long as you use .NET -- any language, any compiler, any
platform.
|
You are dead wrong here. The fact that MS was forced to create a C++
*dialect* (not extension) for using C++ with .NET should give a clue
here.
| Quote: | Borland may just create a C++ .NET development tool in the
future. Then Borland DLLs could be mixed with Microsoft ones. Right
now it's very fainful to develop a plugin architecture where the main
application is written in BCB, but the (non-visual) plugins are
developed in VC++.
|
Borland's compiler were made for VC++ compatibility, as Intel was,
this would be a non-issue now.
One thing is clear: for you, "stantard" means "what MS does". I
couln't disagree more.
[snip]
--
Oscar
|
|
| Back to top |
|
|
Tamas Demjen
Guest
|
| Posted: Fri Dec 03, 2004 12:12 am Post subject: Re: .NET illconceived |
|
|
Oscar Fuentes wrote:
| Quote: | You are dead wrong here. The fact that MS was forced to create a C++
*dialect* (not extension) for using C++ with .NET should give a clue
here.
|
It's a 100% standard C++ conforming extension.
Anyway, I still develop most of my stuff in pure C++ (no managed
extensions, and no Borland extensions either).
| Quote: | One thing is clear: for you, "stantard" means "what MS does". I
couln't disagree more.
|
Well, I have to develop for Windows. I could also use Qt if I had to
develop for multiple platforms. In fact, that's something I've tried as
well. It all depends on the platform that I have to develop for. One
thing is for sure: you can't convince large corporations to develop with
Borland tools anymore. Even if the application is developed with BCB,
they want to create plugins for it using VC++. We can't do anything
about that.
..NET does what ActiveX promised to do but could never deliver. We all
know how cumbersome it is to develop COM stuff. IMO, it's all much more
civilized in .NET. I don't want to argue that the majority of the
development is still unmanaged, I just stated that .NET has advantages,
and its component model (including its events) is one of them.
Tom
|
|
| Back to top |
|
|
Oscar Fuentes
Guest
|
| Posted: Fri Dec 03, 2004 12:44 am Post subject: Re: .NET illconceived |
|
|
Tamas Demjen <tdemjen (AT) yahoo (DOT) com> writes:
| Quote: | Oscar Fuentes wrote:
You are dead wrong here. The fact that MS was forced to create a C++
*dialect* (not extension) for using C++ with .NET should give a clue
here.
It's a 100% standard C++ conforming extension.
|
Uh?
Again: the fact that MS created STLNET (or whatever they call it)
should give a clue here.
| Quote: | Anyway, I still develop most of my stuff in pure C++ (no managed
extensions, and no Borland extensions either).
|
So what?
| Quote: | One thing is clear: for you, "stantard" means "what MS does". I
couln't disagree more.
Well, I have to develop for Windows.
|
Fair enough. OTOH, I have to develop for solving my customers'
demands. I don't know what this has to do with programming language
standards, though.
[snip]
--
Oscar
|
|
| Back to top |
|
|
Tamas Demjen
Guest
|
| Posted: Fri Dec 03, 2004 2:47 am Post subject: Re: .NET illconceived |
|
|
Oscar Fuentes wrote:
| Quote: | Fair enough. OTOH, I have to develop for solving my customers'
demands. I don't know what this has to do with programming language
standards, though.
|
The way I see it is that in the long run Windows developers won't be
able to avoid programming in .NET. Standard C++ is important, because I
still want to be able to compile existing code, use very helpful
libraries such as boost, and actually do the major part of the
development in regular C++. It's also very important that I can still
program in C++, while not forcing everybody to use the same language,
and still be able to plug our modules together.
STL.NET is for the managed stuff. The managed world is significantly
different, that's the extesion we talked about. But apart from that, we
still have a standard C++ compiler. The reason they created STL.NET is
because C++ programmers are already familiar with the STL syntax, and
it's easier for us to have a familiar view to a different world. It just
makes sense to do that.
Just my 2c worth. You don't have to agree. ;-)
Tom
|
|
| Back to top |
|
|
Pavel Vozenilek
Guest
|
| Posted: Fri Dec 03, 2004 1:17 pm Post subject: Re: .NET illconceived |
|
|
"Tamas Demjen" wrote:
| Quote: | And tell me how you would load such a plugin dynamically? Because the OS
doesn't support that. There's no Win32 API function for that. There's only
LoadLibrary, and GetProcAddress, none of which is capable of loading a
class.
In almost all cases dynamically loaded plugins |
would use some form of object factory.
This factory would hide all the nastiness
of platform API.
It doesn't seem to me as huge obstacle.
There are few unsolved problems with C++ and
dynamic libraries like ODR and statics.
Such support may or may not appear in C++0x.
Unfortunate problems with different binary layout
are due to lack of coopearation between vendors.
/Pavel
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
