Board index » cppbuilder » Re: C++\CLI compiler

Re: C++\CLI compiler


2007-09-12 07:25:27 PM
cppbuilder81
Andre Kaufmann < XXXX@XXXXX.COM >wrote:
Quote
Hendrik Schober wrote:
>Andre Kaufmann < XXXX@XXXXX.COM >wrote:
>[...]
>
>So you're not one of MS' customers. What does this

I'm both Borland and MS customer, but not yet a Codegear customer.

>change to the thousends who shout for new MFC stuff
>and hail SM for delivering this?

Don't know if there are many, which hail for new MFC stuff. [...]
Someone here has posted the link to Soma's blog entry.
Have you read the repsonses?
Quote
>>[...]
>>>of new /native/ APIs in Vista(?) and IIRC it was a 5-digit
>>>number.
>>Some native API's, which they need anyway to be accessible from user
>>code, compared to all the new stuff for .NET ?
>
>Who cares? They are there and usable, and they are
[...]
>aggressively announced to assure MS customers that
>native code isn't dead. I suppose if MS still wanted
>everybody to switch to .NET ASAP, they wouldn't do
>this.

IIRC the number of new native API functions in Vista has been mentioned
because a customer has raised a question what Vista has to offer for
native development, besides all that many new managed API's.
Well, I have read/heard it many times now, always in
conjunction with the statement that Win32 isn't dead,
but well alive and evolving.
Quote
>[...]
>>The VC++ team, the VB team is another story.
>
>Just as with BCB and Delphi. Neither MS nor Borland
>dared to do this to their biggest chunk of customers.

Don't know if the VB customer base was small compared to the C++
customer base. Many stated just the opposite.
I might be wrong with this one, unless you count in
this:
Quote
But you mentioned the main reason why C++ compatibility isn't touched
(besides that C++ is an ISO standard) - Windows itself is written in
C/C++ ;-).

Andre
Schobi
--
XXXX@XXXXX.COM is never read
I'm HSchober at gmx dot de
"A patched buffer overflow doesn't mean that there's one less way attackers
can get into your system; it means that your design process was so lousy
that it permitted buffer overflows, and there are probably thousands more
lurking in your code."
Bruce Schneier
 
 

Re:Re: C++\CLI compiler

Rudy Velthuis [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
Frank J wrote:

>VCL is more productive, but it runs slower.

I have never experienced any slowness in the VCL.
Right. And since your business is to write multi-MLoC apps
with hundreds of forms, that gives considerable weight to
your statement.
Scho-deja-vu-bi
--
XXXX@XXXXX.COM is never read
I'm HSchober at gmx dot de
"A patched buffer overflow doesn't mean that there's one less way attackers
can get into your system; it means that your design process was so lousy
that it permitted buffer overflows, and there are probably thousands more
lurking in your code."
Bruce Schneier
 

Re:Re: C++\CLI compiler

Frank J wrote:
Quote
>>VCL is more productive, but it runs slower.
>
>I have never experienced any slowness in the VCL.


ok Rudy, I'm no longer going to play these little word games with you
any longer.

You know I'm saying in comparison to MFC...
Well, before you test it, it should be relevant. If no one experiences
any problems with it, why should it be of any importance if MFC is a
few nanoseconds faster doing certain things?
Additionally, we don't know your test code, and we would have to trust
you on this, and to trust that you actually measured the right things.
--
Rudy Velthuis [TeamB]
"Well done is better than well said."
-- Benjamin Franklin (1706-1790)
 

{smallsort}

Re:Re: C++\CLI compiler

In article <46e6b134$ XXXX@XXXXX.COM >, Harold Howe [TeamB] wrote:
Quote
- MFC (a shining example of everything you shouldn't do)
Speaking pragmatically, though, it works. It worked with Win16 and a
compiler so pre-standard that it didn't know what an exception was, and it
continues to work today on Win32 with exception support ... and that
migration has required very little change in the users' sourcecode.
MFC may be horrible inside, but it's a damned effective solution for a
particular set of problems.
Quote
- WTL (little known C++ library that I don't think is supported)
Microsoft released WTL to the Open Source community so, no, they don't
support it ... but it is still being supported and worked on.
sourceforge.net/projects/wtl/
One thing that WTL has over all the others is that it can produce some
exceedingly lightweight executables. I wish it has been pushed more into
the mainstream as it's a very good framework (but uses quite 'difficult'
C++ -- lots of templates -- so isn't for the bottom three quartiles of
developers).
Cheers,
Daniel.
 

Re:Re: C++\CLI compiler

In article <46e64137$ XXXX@XXXXX.COM >, Frank J wrote:
Quote
>Are you implying that VCL is Object Pascal-based it's somehow slow?
>That MFC makes things fast?

I'm implying that the VCL Framework is slower than MFC.
One would expect it to be so, as it provides a higher level of abstraction
than MFC, and runs on top of the same set of platform APIs. MFC is a
thinner layer (which is both an advantage and a curse) and so should be
expected to be add less execution overhead.
Whether that difference in speed is even noticeable in a typical
application on a typical user's PC is another matter.
This has nothing to do with VCL being in Pascal, though.
Quote
Should be rephrased from :
"How can the VCL benefit from the new processor architecture like .NET?"
to
"How can the VCL benefit from the new processor architecture like .NET
can"?
Actually, to a very great extent .NET can't. To take full advantage of a
new processor architecture you have to write native code that takes
advantages of -- and makes best use of -- its new features.
It's true that once you have implemented the .NET/Mono runtime on a new
architecture a .NET application will run on that platform without change,
so the application is protected from obsolescence by the abstract nature of
the .NET platform ... that's not really "taking advantage of" the platform,
though, I'd describe that as "being isolated from progress". The
application can only take advantage of the architecture of the .NET virtual
machine; it can't see the new underlying hardware architecture to make use
of it. Yes, the runtime itself can take advantage of the new hardware
platform, internally, but there is a limit to the extent that it can make
the features of that platform available to its client apps.
Cheers,
Daniel.
 

Re:Re: C++\CLI compiler

In article <46e6cdb6$ XXXX@XXXXX.COM >, Geikelite wrote:
Quote
>How about an interface to VCL/.NET? I don't remember seeing that on
>the roadmap either, but it seems like that might be more manageable.
>Any plans at all for that?

It would be nice to get an answer on this from CodeGear. It would help
C++ folks who are interested in .NET to plan.

I'm showing below a quote from Steve Teixeira on the MS VC++ team that
has bearing on this thread.
[snip]
There are two reasons to be interested in .NET
1. Because you specifically need to write code that will run in a uniform,
sandboxed, environment on disparate hardware platforms (and for some reason
you don't want to use Java).
2. Because Microsoft provide some neat GUI development tools for C#
3. Learning a new platform is more fun than actual work.
(Oh, sorry, forget #3)
If you are a C++ Builder or Delphi developer you have a RAD environment and
the VCL -- which is better than the WinForms stuff anyway -- so reason #2
doesn't really apply to you.
So, really, the only reason that matters to us here in
borland.public.cppbuilder.non-technical is #1. If you're specifically
writing for a sandboxed runtime -- whether it be for security or for
portability reasons -- you aren't going to be linking native C++ into your
application. That's just not the game you're in.
So ... why would you even care?
Cheers,
Daniel.
 

Re:Re: C++\CLI compiler

Hendrik Schober wrote:
Quote
Rudy Velthuis [TeamB] < XXXX@XXXXX.COM >wrote:
>Frank J wrote:
>
>>VCL is more productive, but it runs slower.
>
>I have never experienced any slowness in the VCL.

Right. And since your business is to write multi-MLoC apps
with hundreds of forms, that gives considerable weight to
your statement.
No, fortunately, my business isn't to do that. I don't quite see how
the line count of an app or the number of forms in an app changes the
speed of the VCL.
And what are you actually trying to imply, once again? That, because I
am a hobbyist, my statement should be questioned?
That's pretty cheap, IMO.
--
Rudy Velthuis [TeamB]
"Of all the enemies to public liberty, war is perhaps the most
to be dreaded because it comprises and develops the germ of
every other." -- James Madison
 

Re:Re: C++\CLI compiler

Frank J wrote:
Quote
>Did you find that your apps are UI-bound? Could you describe what
>the test parameters were? I'm curious how does one derive a test
>for a UI framework?
>
I would assume it's the same test that most of you are using to
determine .NET is slower than the VCL.
"Snappiness"? That is all? And you found the MFC "snappier" than the
VCL?
LOL!
--
Rudy Velthuis [TeamB]
"If you are going through hell, keep going."
- Sir Winston Churchill (1874-1965)
 

Re:Re: C++\CLI compiler

Daniel James wrote:
Quote
Whether that difference in speed is even noticeable in a typical
application on a typical user's PC is another matter.
Indeed. Not even the typical PC, actually. I wonder if it is noticeable
at all.
--
Rudy Velthuis [TeamB]
"Sex is like air. It's only a big deal if you can't get any."
-- Unknown
 

Re:Re: C++\CLI compiler

Frank J wrote:
Quote

"Harold Howe [TeamB]" < XXXX@XXXXX.COM >wrote in
message news:46e6af01$ XXXX@XXXXX.COM ...

>Note that C# can call plain C dlls and COM libraries without any
>special help.

But plain C++ has a more diffucult time calling a C# dll, unless you
use COM. But, this is where C++/CLI helps out greatly.
So does Delphi for .NET, actually. You can either export managed code
using unsafe exports, and they can be consumed directly, as if the .NET
assembly were a normal DLL. Or you can export several functions bound
together as interfaces, to be consumed by any code again.
--
Rudy Velthuis [TeamB]
"Real life is that big, high-res, high-color screen saver behind
all the windows." -- anonymous
 

Re:Re: C++\CLI compiler

Frank J wrote:
Quote
I'm no longer going to play these little word games
What word games? You made a unsubstantiated (and probably
unsupportable) claim and were asked to give some justification. AFAICT
you have none to offer so you dismiss the other person as not worthy
of your consideration.
- Leo
 

Re:Re: C++\CLI compiler

Frank J wrote:
Quote
I would assume it's the same test that most of you
are using to determine .NET is slower than the VCL.
As I thought then - none.
- Leo
 

Re:Re: C++\CLI compiler

"Daniel James" < XXXX@XXXXX.COM >wrote in message>
Quote
So ... why would you even care?

You are isolated on Windows, aren't you?
I guess __ will remain the place to be for now until someone with vision....
 

Re:Re: C++\CLI compiler

Rudy Velthuis [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
Hendrik Schober wrote:
>Rudy Velthuis [TeamB] < XXXX@XXXXX.COM >wrote:
>>Frank J wrote:
>>
>>>VCL is more productive, but it runs slower.
>>
>>I have never experienced any slowness in the VCL.
>
>Right. And since your business is to write multi-MLoC apps
>with hundreds of forms, that gives considerable weight to
>your statement.

No, fortunately, my business isn't to do that. I don't quite see how
the line count of an app or the number of forms in an app changes the
speed of the VCL.
I was referring to the speed of the GUI in general,
not VCL-generated ones. (And, yes, of course, the
size of the app has a considerable influence on its
speed.)
Quote
And what are you actually trying to imply, once again? That, because I
am a hobbyist, my statement should be questioned?
It's your classical way of "arguing": Someone says
something that's negative for CG/Delphi/VCL/BCB,
and you promptly come along and bluntly state you
have never seen it, as if this was a real argument
everybody should consider.
_I_ have argued in other threads in theses groups
against the idea that GUIs can be slow. But not by
saying "I have never seen a slow GUI, so it can't
exist".
Quote
That's pretty cheap, IMO.
Not quite as cheap as your "argument".
For me, here's EOD.
Schobi
--
XXXX@XXXXX.COM is never read
I'm HSchober at gmx dot de
"A patched buffer overflow doesn't mean that there's one less way attackers
can get into your system; it means that your design process was so lousy
that it permitted buffer overflows, and there are probably thousands more
lurking in your code."
Bruce Schneier
 

Re:Re: C++\CLI compiler

Hendrik Schober wrote:
Quote
>>>I have never experienced any slowness in the VCL.
>>
>>Right. And since your business is to write multi-MLoC apps
>>with hundreds of forms, that gives considerable weight to
>>your statement.
>
>No, fortunately, my business isn't to do that. I don't quite see how
>the line count of an app or the number of forms in an app changes
>the speed of the VCL.

I was referring to the speed of the GUI in general,
not VCL-generated ones.
You were? You quoted my line about the VCL, not about GUIs in general
and that was the only statement I made in that post.
And this entire subthread was about the speed of the VCL relative to
the MFC. Now you say that *you* are talking about the speed of GUIs in
general? If so, how would that be relevant WRT the differences between
VCL and MFC?
--
Rudy Velthuis [TeamB]
The "abort()" function is now called "choice()."
-- from the "Politically Correct UNIX System VI Release notes"