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

2007-09-12 07:25:27 PM
cppbuilder81
Andre Kaufmann < XXXX@XXXXX.COM >wrote:
Have you read the repsonses?
conjunction with the statement that Win32 isn't dead,
but well alive and evolving.
this:
--
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
 

Rudy Velthuis [TeamB] < XXXX@XXXXX.COM >wrote:
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
 

Frank J wrote:
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}

In article <46e6b134$ XXXX@XXXXX.COM >, Harold Howe [TeamB] wrote:
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.
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.
 

In article <46e64137$ XXXX@XXXXX.COM >, Frank J wrote:
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.
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.
 

In article <46e6cdb6$ XXXX@XXXXX.COM >, Geikelite wrote:
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.
 

Hendrik Schober wrote:
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
 

Frank J wrote:
VCL?
LOL!
--
Rudy Velthuis [TeamB]
"If you are going through hell, keep going."
- Sir Winston Churchill (1874-1965)
 

Daniel James wrote:
at all.
--
Rudy Velthuis [TeamB]
"Sex is like air. It's only a big deal if you can't get any."
-- Unknown
 

Frank J wrote:
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
 

Frank J wrote:
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
 

Frank J wrote:
- Leo
 

"Daniel James" < XXXX@XXXXX.COM >wrote in message>
I guess __ will remain the place to be for now until someone with vision....
 

Rudy Velthuis [TeamB] < XXXX@XXXXX.COM >wrote:
not VCL-generated ones. (And, yes, of course, the
size of the app has a considerable influence on its
speed.)
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".
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
 

Hendrik Schober wrote:
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"