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

Re: C++\CLI compiler

2007-09-17 07:31:38 PM
Ed Mulroy wrote:
The idea that a language feature can be abused so it
therefore should be discarded is in my opinion faulty logic.
That's not really my idea - I don't want to discard macros at all,
just to have the ability to keep them out of my code when I wish to.
As is, If I want to write a program that runs in windows I have little
practical choice but to include windows headers and the thousands of
macros they contain.
There already are modules, just use Delphi.
And because another language has a feature it should not be considered
for inclusion in C++?
Another of those aspects is the great compatibility
with C which you would willingly discard.
Not at all, and IIUC the work on adding modules to C++ would not do
so. Current C++ code would continue to work, but there would be a
file-by-file option to write code is a new way, just like old C code
is still allowed to coexist with C++ code.
Your adamancy for discarding is but a fraction of mine
for not discarding it.
Well my case may have been stated with a bit more intensity than
necessary. I should learn to be as subtle as you. But please, I don't
really want to discard anything, just add the option to have a clean
sandbox to build in for some of my code.
To me, the true beauty of C++ has been its ability to grow as our
communal understanding of the programming process develops.
- Leo

Re:Re: C++\CLI compiler

Frank J wrote:
(No need to flame me, I've already moved on to a different software
development company)
Probably one that offers MFC as framework? <g>
Rudy Velthuis [TeamB]
"Why don't you write books people can read?"
-- Nora Joyce to her husband James (1882-1941)

Re:Re: C++\CLI compiler

Leo Siefert wrote:
Rudy Velthuis wrote:

>I know. Macros are not just evil, they are evil evil evil.

Did macro expansion result in repetition in the above line of code?
Nah. I got that from "the" C++ FAQ on some site. But I had seen it
Rudy Velthuis [TeamB]
"One word sums up probably the responsibility of any Governor,
and that one word is 'to be prepared'." -- George W. Bush


Re:Re: C++\CLI compiler

Hendrik Schober wrote:
>[Leo] Not everyone. Mostly (but not only) you.
Read my posting again. This time do it without any
presumptions, if possible. The above dealt with the
reactions /Frank/ got. And he didn't get any from me
at all.
This is a rather long thread and you may need to read some of it
again. The above quote was in response to this from your posting [I
have inserted names in a few places to make it clearer]:
>>[Schobi - reply to Rudy]
>>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

>[Leo] In this case it is exactly as real as the statement it was refuting.
...which everyone here who voiced his opinion
thought a silly way to make a statement, right?
So I was referring directly to a statement by you in the post to which
I was replying. And your post was directed at Rudy, not Frank
>Yet only Rudy was attacked.

Hey, you're accusing me again.
I was referring to the discussion started somewhere back there by you
with this:
>[Rudy] 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.
Oh well. If that's the way it goes -- I merely stated
my own opinion in reaction to Rudy's. How can /that/
be inappropriate?
It's not. Suggesting that Rudy's opinion should not be given much
weight because he does not write MLoC apps is inappropriate IMO, even
if that does happen to be your opinion. You did not even state an
opinion on the issue at hand, only on Rudy.
- Leo

Re:Re: C++\CLI compiler

I think the notion that C/C++ (-based languages) have an implicit conversion
to bool in conditional tests is wrong.
C, and C++, do not have an implicit conversion to bool in conditional tests.
They are asking the question of whether the expression is zero or non-zero
(which generally matches the capabilities of the underlying assembler
instruction sets I've been exposed to.)
While there are similarities, they are not the same. (A zero/non-zero
question, can be phrased as a boolean expression. But that is not a
requirement. The INTEL instruction set allows one to "OR" a value with
itself to determine zero/non-zero. Probably the underlying microcode is
comparing each bit. But, that's still not what the "OR" operation is
about.) I'd guess many compilers that implement "bool", actually don't
really test for true/false, but actually _incorrectly_ test for
So I'd guess those who have the notion of implicit conversion to bool,
probably learned to program with a non-C based language, or were taught by
someone who learned a non-C based language, and haven't really thought about
what the language construct is doing in C-based languages.
Maybe K&&/||R can correct me if I'm wrong on this notion...
>It would catch errors like
>if (error = GetLastError()) ....
>which should have read:
>if (error == GetLastError()) ...
>So I don't see where implicit conversion to bool makes sense except
>perhaps when pointers are used: if (p) ....

It makes sense because C/C++ programmers are used to
look at integers as "booleans in disguise". Just assume
'GetLastError()' to always return '0' (zero) for no
error. Then 'if( GetLastError() )' makes sense to them.
Of course, we could all write 'if( 0 != GetLastError() )'
instead. But just look at the classical implementation
of 'strlen()' and askyourself: Is this the community
that appreciates the additional wordiness as a value? :)


Re:Re: C++\CLI compiler

Andre Kaufmann wrote:
Not yet, thanks :-).
We are using FinalBuilder for a complete build and I have to check first
if tools, like TwineCompiles integrate in FinalBuilder (make file level)
There is a FB plugin for TwineCompile, that we haven't officially released
yet, but we give it to anyone who requests it :-) It does not use makefiles,
as it basically packages the plugin build system into a FB action.
If you are using makefiles with FB, TwineCompile fully supports such builds,
you just replace bcc32 with mtbcc32.

Re:Re: C++\CLI compiler

Leo Siefert < XXXX@XXXXX.COM >wrote:
This is a rather long thread [...]
And I still think your quoting shows my interpretation
of what I wrote, not yours. Let's stop this nevertheless.
- Leo
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

Did you know that VC's default optimization is "smaller
size" rather than "faster speed", since the guys at MS
have found that optimizing for size actually makes for
faster apps than optimizing for speed? Don't laugh, it
might sound weird at first, but it makes sense if you
know that memory footprint (and data locality) are
very important speed factors today.
Does sound weird at first.
For a few of our projects, we set the optimization to
"faster speed" since the default is "smaller size."
I find that even with this, VS 2003 generates smaller
sized executables than BCB did so we effectively end up
with smaller faster apps.
We use a lot more templates with VS than we did with
Borland as with BCB the code size increased way too much.
Has Borland's optimizer improved any with their latest release?

Re:Re: C++\CLI compiler

"Leo Siefert" < XXXX@XXXXX.COM >wrote in message
Duane Hebert wrote:

>If you write relatively small Delphi apps, you may not
>have the problems that BCB users writing large apps have.

A few problems are most likely related to building large apps. In
particular, problems related to the size of .csm and .tds files come
to mind.
But I think it is far more common that a large app buries and obscures
a bug that could just as easily be reproduced in a small app. People
with large apps that run into IDE bugs may be more difficult to please
because if the app hits multiple bugs a patch that fixes one may just
seem to change but not fix the problem.
But when you get bizarre behavior that changes after a rebuild,
it's possible that the problem is not in your code.

Re:Re: C++\CLI compiler

"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >wrote in message

Ok, the fact you can't overload = anymore might be a problem indeed,
but the fact that almost any result (integers, pointers) can be
interpreted as a bool is still a problem, IMO.
But, its not, or should not be, interpreted as a bool, except by those who
only conceive of bools...
It is a question of zero/non-zero - not true or false.
And while you can ask the question is a value == to zero or != zero with
operators, such is redundant, and unnecessary, in the context of c-based
expressions. I suspect it is an artifact of some other language(s) you
learned before c-based ones. (FWIW, my "native" language was pascal. But
I've done enough assembler to at least suspect that I understand why c has
the notion of zero/non-zero in its conditional tests.)

Re:Re: C++\CLI compiler

Andre Kaufmann wrote:
We are using FinalBuilder for a complete build and I have to check first
if tools, like TwineCompiles integrate in FinalBuilder (make file level)
What doesn't FinalBuilder have a plugin for? ;-)
There's no such thing as 'one, true way;'
- Mercedes Lackey

Re:Re: C++\CLI compiler

"Duane Hebert" < XXXX@XXXXX.COM >wrote in message
I won't be flaming you. I haven't used Borland tools professionally
since the CBX b.s. I still think MS needs competition.
I agree, I wish MS had some real competition also.

Re:Re: C++\CLI compiler

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

>(No need to flame me, I've already moved on to a different software
>development company)

Probably one that offers MFC as framework? <g>

More precisely, .NET and MS C++/CLI for some nice utility type development
to integrate our .NET into our C++.

Re:Re: C++\CLI compiler

"Alex Bakaev [TeamB]" < XXXX@XXXXX.COM >wrote in message

Thanks for dropping by!

No problem, I'll still hang out to keep you guys honest :)

Re:Re: C++\CLI compiler

dhoke wrote:

"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>Ok, the fact you can't overload = anymore might be a problem indeed,
>but the fact that almost any result (integers, pointers) can be
>interpreted as a bool is still a problem, IMO.

But, its not, or should not be, interpreted as a bool
OK, it is interpreted as a boolean expression. You can say
for (x = s; *x; ++x)
and *x is interpreted as boolean. Equally,
for (n = firstnode; n; n =
will compile, and n is interpreted as a boolean. It would be a lot
safer if this were illegal, and only the following were allowed:
for (x = s; *x == '\0'; ++ x)
for (n = firstnode; n == NULL; n =
But then you should not be allowed to assign 0 to a char, or NULL to an
int, etc.
Rudy Velthuis [TeamB]
"USA Today has come out with a new survey: Apparently three out
of four people make up 75 percent of the population."
-- David Letterman.