 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
George Tihenea
Guest
|
 Posted: Thu Dec 08, 2005 3:31 am Post subject: new C++ compiler conformance to the standard |
 |
|
Hi
I used C++ Builder from v1 to v5 then I switched to vs.net. There were a
few reasons for the switch but the important ones were a) lack of serious
support and clear future direction and b) the standard conformance of the
C++ compiler. Now that Borland seems to support again (are they serious?)
C++, can anyone say if the compiler is as compliant to the standard as it is
vs.net 2005? This is critical for us.
Also, in vs.net (both 2003 & 2005) there is a wizard to create web
services using ATL Server feature. It is not the simplest thing to program
BUT, it is powerful and working very well. Is there something similar in the
new Borland C++ 2006? And again, is there a way to write (if needed) C++
code in .net (ala managed C++ in vs.net)?
G.
|
|
| Back to top |
|
 |
Edward Diener
Guest
|
| Posted: Thu Dec 08, 2005 5:30 am Post subject: Re: new C++ compiler conformance to the standard |
|
|
George Tihenea wrote:
| Quote: | Hi
I used C++ Builder from v1 to v5 then I switched to vs.net. There were a
few reasons for the switch but the important ones were a) lack of serious
support and clear future direction and b) the standard conformance of the
C++ compiler. Now that Borland seems to support again (are they serious?)
C++, can anyone say if the compiler is as compliant to the standard as it is
vs.net 2005? This is critical for us.
|
I have already asked the exact same question on the language NG and the
answer was: Borland has said nothing certain about this prior to
releasing BDS C++ Builder 2006 and anybody else that knows is under an
NDA not to say anything about it. In other words, prior to the release
of the C++ product absolutely no information will be made available
about the standard C++ compliance of the product. How's that for
brilliance and marketing prowess ! And that's all she wrote, as of now
since C++ Builder 2006 has not been officially released.
My answer was: that's fine but I have decided, given this wealth of
information, not to upgrade to C++ Builder 2006 unless I find out that
the C++ standard compliance of the compiler has significantly improved.
Good luck in your finding information about this from anyone who might know.
|
|
| Back to top |
|
|
George Tihenea
Guest
|
| Posted: Thu Dec 08, 2005 11:58 pm Post subject: Re: new C++ compiler conformance to the standard |
|
|
Thanks.
From what you are saying it looks like the old attitude is still there...
The standard compliance of the compiler is so important to me that without a
compiler on the same level with vs.net 2003 we cannot even consider going
back...
George.
"Edward Diener" <eddielee_no_spam_here (AT) tropicsoft (DOT) com> wrote
| Quote: | George Tihenea wrote:
Hi
I used C++ Builder from v1 to v5 then I switched to vs.net. There
were a few reasons for the switch but the important ones were a) lack of
serious support and clear future direction and b) the standard
conformance of the C++ compiler. Now that Borland seems to support again
(are they serious?) C++, can anyone say if the compiler is as compliant
to the standard as it is vs.net 2005? This is critical for us.
I have already asked the exact same question on the language NG and the
answer was: Borland has said nothing certain about this prior to releasing
BDS C++ Builder 2006 and anybody else that knows is under an NDA not to
say anything about it. In other words, prior to the release of the C++
product absolutely no information will be made available about the
standard C++ compliance of the product. How's that for brilliance and
marketing prowess ! And that's all she wrote, as of now since C++ Builder
2006 has not been officially released.
My answer was: that's fine but I have decided, given this wealth of
information, not to upgrade to C++ Builder 2006 unless I find out that the
C++ standard compliance of the compiler has significantly improved. Good
luck in your finding information about this from anyone who might know.
|
|
|
| Back to top |
|
|
ZJ
Guest
|
| Posted: Sun Dec 11, 2005 3:19 am Post subject: Re: new C++ compiler conformance to the standard |
|
|
"George Tihenea" <a@b.com> wrote
| Quote: | Thanks.
From what you are saying it looks like the old attitude is still there...
The standard compliance of the compiler is so important to me that without
a compiler on the same level with vs.net 2003 we cannot even consider
going back...
|
Hi,
I wonder what's wrong with vs 2003 ?
Why you even consider going back ?
Regards,
Zenon
|
|
| Back to top |
|
|
Edward Diener
Guest
|
| Posted: Sun Dec 11, 2005 4:11 am Post subject: Re: new C++ compiler conformance to the standard |
|
|
ZJ wrote:
| Quote: | "George Tihenea" <a@b.com> wrote in message
news:4398c863$1 (AT) newsgroups (DOT) borland.com...
Thanks.
From what you are saying it looks like the old attitude is still there...
The standard compliance of the compiler is so important to me that without
a compiler on the same level with vs.net 2003 we cannot even consider
going back...
Hi,
I wonder what's wrong with vs 2003 ?
Why you even consider going back ?
|
VS 2002/2003 ( .NET 1.0 and 1.1 ) has a serious bug, documented by MS
but cowardly unmentioned in the computer programming press, which
affects all managed C++ developers of components, essentially destroying
the ability of C++ developers to reliably create components for those
first two releases of .NET. Therefore using C++ in VS2002/2003 is
equivalent to using MFC, ATL et al and not .NET.
This has been fixed in VS 2005 ( .NET 2.0 ) and with C++/CLI, and C++
developers are finally on the same level as C# and VB .NET developers
when it comes to the creation of components for .NET. That may be one
reason, as a C++ developer, that the OP might have considered going back
to BCB from VS 2003.
In BCB of course .NET programming is not currently supported and will
not be for another 2 years minimum at least as projected by Borland, and
in BCB components created there can not be used by Delphi. So MS's move
of actually supporting it in .NET 2.0, after "bugging" it in .NET
1.0/.NET 1.1, is actually "better" than what Borland has done in its
treatment of C++ IMHO, although I greatly prefer BCB/VCL to VC++/MFC.
I find it sad that both MS and Borland have so mistreated one of the
most widely used and best programming languages in the world, in favor
of inferior, but decent, simpler languages ( C# and Delphi ), but since
C# is MS's language and Delphi is Borland's language and C++ is no
company's language, it is regrettably understandable in the corporate world.
|
|
| Back to top |
|
|
Andre Kaufmann
Guest
|
| Posted: Sun Dec 11, 2005 4:31 pm Post subject: Re: new C++ compiler conformance to the standard |
|
|
Edward Diener wrote:
| Quote: | ZJ wrote:
I wonder what's wrong with vs 2003 ?
Why you even consider going back ?
[...]
VS 2002/2003 ( .NET 1.0 and 1.1 ) has a serious bug, documented by MS
but cowardly unmentioned in the computer programming press, which
|
MSN search returns 3,028 hits for "loader lock" and google about 928.
Perhaps it's not that often mentioned because only few developers write
components for .NET by using mixed mode DLL's in C++.
Because:
a) Manged C++ is very ugly - compared to C++/CLI
b) Commonly components are shipped with source, thus requiring
others to read and understand native C++ / managed C++
c) C++ is not the appropriate language for RAD GUI components (IMHO)
| Quote: | affects all managed C++ developers of components, essentially destroying
|
It would affect all languages, supporting mixed mode Dlls. Since C++ is
currently the only one it's the only language affected.
| Quote: | the ability of C++ developers to reliably create components for those
first two releases of .NET. Therefore using C++ in VS2002/2003 is
equivalent to using MFC, ATL et al and not .NET.
|
Executables are not affected and you still can consume native C++ code
by manually initializing your mixed mode Dlls or use PInvoke to use a
native DLL in any language.
You can use the BCB native DLL's in your Delphi .NET components - no big
deal.
| Quote: | [...]
when it comes to the creation of components for .NET. That may be one
reason, as a C++ developer, that the OP might have considered going back
to BCB from VS 2003.
|
Back ? Why ? I'm using both for the same executables. It's not a
question of going back but to choose freely ;-)
| Quote: | In BCB of course .NET programming is not currently supported and will
not be for another 2 years minimum at least as projected by Borland, and
in BCB components created there can not be used by Delphi. So MS's move
|
Do you mean managed components in .NET 2.0 in a future release of BCB
cannot be consumed by Delphi ?
| Quote: | [...]
I find it sad that both MS and Borland have so mistreated one of the
most widely used and best programming languages in the world, in favor
[...]
|
"best programming languages". Do you dare to repost that in the Delphi
newsgroup ? ;-)
I like C++ very much and it's my main programming language, but
regarding RAD applications it's IMHO not the >best< language for that
purpose, though BCB does RAD very well.
Andre
|
|
| Back to top |
|
|
Edward Diener
Guest
|
| Posted: Sun Dec 11, 2005 6:00 pm Post subject: Re: new C++ compiler conformance to the standard |
|
|
Andre Kaufmann wrote:
| Quote: | Edward Diener wrote:
ZJ wrote:
I wonder what's wrong with vs 2003 ?
Why you even consider going back ?
[...]
VS 2002/2003 ( .NET 1.0 and 1.1 ) has a serious bug, documented by MS
but cowardly unmentioned in the computer programming press, which
MSN search returns 3,028 hits for "loader lock" and google about 928.
Perhaps it's not that often mentioned because only few developers write
components for .NET by using mixed mode DLL's in C++.
Because:
a) Manged C++ is very ugly - compared to C++/CLI
|
Beauty is in the eye of the beholder.
| Quote: | b) Commonly components are shipped with source, thus requiring
others to read and understand native C++ / managed C++
|
Nothing requires components to be shipped with source. Only open source
fanatics insist on such nonsense as an absolute rule.
| Quote: | c) C++ is not the appropriate language for RAD GUI components (IMHO)
|
IMHO it is as much an appropriate language for RAD components as
anything else.
None of your arguments mitigate against producing .NET components for
1.0 and 1.1 in Managed C++ but the "loader lock" bug obviously does.
| Quote: |
affects all managed C++ developers of components, essentially destroying
It would affect all languages, supporting mixed mode Dlls. Since C++ is
currently the only one it's the only language affected.
|
You are correct in that it affects only mixed mode development, but have
you ever heard of a C++ developer restricting himself to not using the
C++ standard library and 3rd party C++ libraries, ala Boost etc. ? Of
course not. Using any of those is mixed mode development in .NET as I am
sure you know. In fact IJW in .NET was developed specifically to make
C++ mixed mode development easier, but the "loader lock" bug destroyed
that in .NET assembles for 1.0 and 1.1.
| Quote: |
the ability of C++ developers to reliably create components for those
first two releases of .NET. Therefore using C++ in VS2002/2003 is
equivalent to using MFC, ATL et al and not .NET.
Executables are not affected
|
True.
I do not consider a language implementation in which one can write
executables, and not shared libraries, worthy of use in modern day
programming. Maybe it was 20-30 years ago but not now.
| Quote: | and you still can consume native C++ code
by manually initializing your mixed mode Dlls or use PInvoke to use a
native DLL in any language.
|
The mixed mode C++ Dll is prey to the "loader lock" bug no matter what
you do. I do not roll dice when I program. Do you ?
| Quote: | You can use the BCB native DLL's in your Delphi .NET components - no big
deal.
|
Can you use BCB components in Delphi ? Can you use BCB classes in DLLs
in Delphi ? Can you write BCB .NET components with BCB ? No, no, and no.
What you can do using BCB code in Delphi is so negligible as not to be
worth mentioning.
| Quote: | [...]
when it comes to the creation of components for .NET. That may be one
reason, as a C++ developer, that the OP might have considered going
back to BCB from VS 2003.
Back ? Why ? I'm using both for the same executables. It's not a
question of going back but to choose freely 
|
Great choice you have ( see above ) <g>. Be real.
| Quote: |
In BCB of course .NET programming is not currently supported and will
not be for another 2 years minimum at least as projected by Borland,
and in BCB components created there can not be used by Delphi. So MS's
move
Do you mean managed components in .NET 2.0 in a future release of BCB
cannot be consumed by Delphi ?
|
The term "created there" refers to current BCB. I do not conjecture on a
product which is 2+ years in the future.
| Quote: |
[...]
I find it sad that both MS and Borland have so mistreated one of the
most widely used and best programming languages in the world, in favor
[...]
"best programming languages". Do you dare to repost that in the Delphi
newsgroup ?
|
I dare to repost that in any NG.
| Quote: |
I like C++ very much and it's my main programming language, but
regarding RAD applications it's IMHO not the >best< language for that
purpose, though BCB does RAD very well.
|
Again the "not the best language to do RAD" is just your opinion. C++
currently lacks one feature for RAD, run-time reflection, but that does
not mean that it can not be implemented successfully through extensions,
as Microsoft in .NET and Borland in BCB have proved.
|
|
| Back to top |
|
|
Andre Kaufmann
Guest
|
| Posted: Sun Dec 11, 2005 8:26 pm Post subject: Re: new C++ compiler conformance to the standard |
|
|
Edward Diener wrote:
| Quote: | Andre Kaufmann wrote:
[...]
Beauty is in the eye of the beholder.
|
Please don't tell me that __underscore keywords and pointers which
cannot be distinguished to be native or managed in templates are (more)
beautiful compared to the C++/CLI syntax.
"eye of the beholder" -> nice Amiga RPG *g*
| Quote: | b) Commonly components are shipped with source, thus requiring
others to read and understand native C++ / managed C++
Nothing requires components to be shipped with source. Only open source
fanatics insist on such nonsense as an absolute rule.
|
I'm not an open source fanatic. It's not a requirement but common, at
least for most Delphi components I know - the others I just don't want
to use, because I cannot change (slightly) the component I like to or
fix / debug bugs. Another issue is using a new compiler - different
compiler settings - debug code etc.
The STL itself is a component library -> so you would call P.J Plauger
also a fanatic open source developer ?
And how do you ship your template based code ? Precompile it with the
client's template parameters ?
If you don't want your code to be read or copied you can use code
obfuscators, this will be the same level of code returned by (good)
decompilers of your compiled components.
I would use a good compiled component too, but if there's an equivalent
component with source I would choose the one with source code.
| Quote: | c) C++ is not the appropriate language for RAD GUI components (IMHO)
IMHO it is as much an appropriate language for RAD components as
anything else.
|
C++ is the perfect back end language, but IMHO it's too slow in
compilation to be the "best" RAD language.
| Quote: | None of your arguments mitigate against producing .NET components for
1.0 and 1.1 in Managed C++ but the "loader lock" bug obviously does.
|
You just have to initialize the DLL and C++ runtime by your own. Tedious
work but it's possible.
| Quote: | [...]
You are correct in that it affects only mixed mode development, but have
you ever heard of a C++ developer restricting himself to not using the
|
Ever heard of "(web) safe code components" ?
| Quote: | C++ standard library and 3rd party C++ libraries, ala Boost etc. ? Of
course not. Using any of those is mixed mode development in .NET as I am
sure you know.
|
Nope - not in C++/CLI. I can compile boost code to MSIL code. Which is
not mixed code, but doesn't imply that it will be safe or CLI compliant.
| Quote: | In fact IJW in .NET was developed specifically to make
C++ mixed mode development easier, but the "loader lock" bug destroyed
that in .NET assembles for 1.0 and 1.1.
|
I don't want discuss workarounds for the loader lock bug, because this
is not the appropriate group for such issue.
Doesn't mean that I found the situation good, but it's a general
architecture problem of .NET 1.1 not of the C++ compiler alone.
| Quote: | [...]
and you still can consume native C++ code by manually initializing
your mixed mode Dlls or use PInvoke to use a native DLL in any language.
The mixed mode C++ Dll is prey to the "loader lock" bug no matter what
you do. I do not roll dice when I program. Do you ?
|
No. But if you don't call any code in DllMain you won't dice, but the
user of your DLL has to call initialization code and you have to set
some compiler switches. Nevertheless I would call it a "show stopper" too.
| Quote: | You can use the BCB native DLL's in your Delphi .NET components - no
big deal.
Can you use BCB components in Delphi ? Can you use BCB classes in DLLs
in Delphi ? Can you write BCB .NET components with BCB ? No, no, and no.
What you can do using BCB code in Delphi is so negligible as not to be
worth mentioning.
|
I know the restrictions of BCB VCL components. If BCB will be able to
compile C++/CLI code the .NET components will be usable in each language
- at least under the .NET platform. And even better each C++/CLI
compliant compiler will be able to compile the code.
And by the way I know the complete BCB story - I've bought CBX !!
| Quote: | [...]
"best programming languages". Do you dare to repost that in the Delphi
newsgroup ? ;-)
I dare to repost that in any NG.
|
Ok. Repost C++ is the best programming language for RAD in the Delphi
newsgroup, will be happy to count the flame posts ;-9
| Quote: | Again the "not the best language to do RAD" is just your opinion.
|
Yes. But I'm not alone.
| Quote: | C++
currently lacks one feature for RAD, run-time reflection, but that does
not mean that it can not be implemented successfully through extensions,
as Microsoft in .NET and Borland in BCB have proved.
|
It misses for example object function pointers, patented by Borland.
..NET uses delegates for that purpose. There are libraries implementing
that feature, by using "dirty" hacks or template based solutions like
"boost". But boost function pointers have a rather large overhead to
implement an 8 byte object function pointer.
With C++/CLI C++ can be tightly coupled to any .NET language. Therefore
I would prefer a Delphi/C#/C++ combo over a native C++ solution.
Why ? Just because they (C#, Delphi) compile much faster and are better
supported with additional IDE features (code insight etc.)
Don't get me wrong, I like C++, STL boost templates and most of my code
is C++, but that doesn't mean that I'm perfectly happy with C++.
C++ is for example ill designed regarding it's compatibility to C, it
could compile C code, but IHMO it was a big mistake to allow macros to
affect other code and not to support a unit concept. IIRC Stroustroup
also called it a mistake (Macros). At least this is why C++ still
compiles that slow and needs quirky workarounds like "precompiled
header" files.
If C# could compile my C++ code (extern "C++" ) and would support
templates, stack objects, RAII this would be my perfect language.
The world is not perfect, so I choose the language which best fits (for me).
Mostly this will be C++ for me, so I'm not against C++, but your
statement "best language" (for everything) bothered me somewhat .
Andre
|
|
| Back to top |
|
|
Rudy Velthuis [TeamB]
Guest
|
| Posted: Sun Dec 11, 2005 8:35 pm Post subject: Re: new C++ compiler conformance to the standard |
|
|
At 21:26:16, 11.12.2005, Andre Kaufmann wrote:
| Quote: | b) Commonly components are shipped with source, thus requiring
others to read and understand native C++ / managed C++
Nothing requires components to be shipped with source. Only open
source fanatics insist on such nonsense as an absolute rule.
I'm not an open source fanatic. It's not a requirement but common, at
least for most Delphi components I know
|
And apparently customary in the .NET world.
--
Rudy.Velthuis {TeamB} http://velthuis.homepage.t-online.de/
"Do you program in Assembly ?" she asked. "NOP," he said.
|
|
| Back to top |
|
|
Edward Diener
Guest
|
| Posted: Sun Dec 11, 2005 10:21 pm Post subject: Re: new C++ compiler conformance to the standard |
|
|
Andre Kaufmann wrote:
| Quote: | Edward Diener wrote:
Andre Kaufmann wrote:
[...]
Beauty is in the eye of the beholder.
Please don't tell me that __underscore keywords and pointers which
cannot be distinguished to be native or managed in templates are (more)
beautiful compared to the C++/CLI syntax.
|
Please stop misquoting me and my intentions. If you are going to argue
issues with people, pretending to argue with them based on misquotes of
what they say simply marks you as someone with whom no one is going to
want to discuss anything on NGs.
First misquotation: nowhere do I say anything about the ease of using
managed C++ compared with C++/CLI.
If you think Managed C++'s syntax made it difficult or impossible to use
in .NET 1.0/1.1 that is your opinion. Having worked for a long time on a
..NET 1.0/1.1 component using Managed C++, before I abandoned it when MS
published the "loader lock" bug, I can only say on my part that it was
not overly difficult to use or understand although it was a learning
curve. But so is .NET a learning curve also.
| Quote: |
"eye of the beholder" -> nice Amiga RPG *g*
b) Commonly components are shipped with source, thus requiring
others to read and understand native C++ / managed C++
Nothing requires components to be shipped with source. Only open
source fanatics insist on such nonsense as an absolute rule.
I'm not an open source fanatic. It's not a requirement but common, at
least for most Delphi components I know - the others I just don't want
to use, because I cannot change (slightly) the component I like to or
fix / debug bugs. Another issue is using a new compiler - different
compiler settings - debug code etc.
|
Your reason for b) above holds no value because one may neither choose
to ship source nor may one care whether or not the source is
understandable to others. I have never chosen to ship source, and never
will for any commercial product and even for some non-commercial
implementations. I have the perfect right to protect my intellectual
property as I see fit.
| Quote: |
The STL itself is a component library -> so you would call P.J Plauger
also a fanatic open source developer ?
|
Second misquotation: Do I say above that anyone who ships an
implementation with open source is a fanatic ? Do you know what
predicate logic is, or are you just willfully being ignorant of it ? Can
you read English ?
| Quote: | And how do you ship your template based code ? Precompile it with the
client's template parameters ?
|
I do not create template code for shipping in a product. I admire
template programming very much, especially the brilliant things Boost
programmers do, and if I were to give freely a code implementation I
would use templates if necessary and ship the source. But because
templates require source code, I will not create templates for any
commercial implementation I may do.
I do look forward to the day when C++ comes up with a way to hide
template source in shipping implementations. The "export" keyword is not
it but hopefully the C++ standard committe will one day come up with a
way to do it similar to their intentions with "export".
| Quote: |
If you don't want your code to be read or copied you can use code
obfuscators, this will be the same level of code returned by (good)
decompilers of your compiled components.
I would use a good compiled component too, but if there's an equivalent
component with source I would choose the one with source code.
|
Good for you. It's a free world and we can all do as we wish.
| Quote: |
c) C++ is not the appropriate language for RAD GUI components (IMHO)
IMHO it is as much an appropriate language for RAD components as
anything else.
C++ is the perfect back end language, but IMHO it's too slow in
compilation to be the "best" RAD language.
|
I do not worry much about compile times. I do not personally think it is
that important for anything in programming anymore, and especially
unimportant for determining whether some language can be used for RAD or
not.
| Quote: |
None of your arguments mitigate against producing .NET components for
1.0 and 1.1 in Managed C++ but the "loader lock" bug obviously does.
You just have to initialize the DLL and C++ runtime by your own. Tedious
work but it's possible.
|
If there is an actual workaround for the "loader lock" bug, I have
missed it. Initializing the C++ runtime, as far as I understand, does
not solve the problem, nor do I even understand what you mean by doing
it "by your own". MS made it very clear when publishing the issue that
there is NO workaround for it in .NET 1.0/1.1 no matter what you do in
mixed mode C++ assemblies. If there was, I am sure they would have
published it and been glad to tell C++ programmers about it. Even if the
chance of the "loader lock" occurring were a very small percent, if
there is no sure workaround for it, I would not do mixed mode Managed
C++ programming in .NET 1.0/1.1, since I don't play dice with customers.
| Quote: |
[...]
You are correct in that it affects only mixed mode development, but
have you ever heard of a C++ developer restricting himself to not
using the
Ever heard of "(web) safe code components" ?
|
Means nothing to me. When I use C++ I want to use the full C++ languages
and libraries.
| Quote: |
C++ standard library and 3rd party C++ libraries, ala Boost etc. ? Of
course not. Using any of those is mixed mode development in .NET as I
am sure you know.
Nope - not in C++/CLI. I can compile boost code to MSIL code. Which is
not mixed code, but doesn't imply that it will be safe or CLI compliant.
|
You can not compile calls to the C++ standard library using templates
and Boost implementations and libraries using templates into pure mode
CLI code in .Net 1.0/1.1. If you can do it in C++/CLI and .NET 2.0,
bravo for MS.
| Quote: |
In fact IJW in .NET was developed specifically to make C++ mixed mode
development easier, but the "loader lock" bug destroyed that in .NET
assembles for 1.0 and 1.1.
I don't want discuss workarounds for the loader lock bug, because this
is not the appropriate group for such issue.
|
There are no absolutely foolproof workarounds to the "loader lock" bug
AFAIK. If there are I would be very glad to know about it. If the
workaround merely reduces the probability of the bug but it may still
occur, it is a complete waste of time IMO.
| Quote: | Doesn't mean that I found the situation good, but it's a general
architecture problem of .NET 1.1 not of the C++ compiler alone.
|
Agreed. And of .NET 1.0 also of course. It is a problem for the C++
compiler, however, since mixed mode programming in .NET is easily the
most natural idiom for C++. If one were purely restricted to what the
..NET assemblies allowed and could not use the facilities of C++ and the
standard C++ library/3rd party C++ libraries, at least internally, why
would want to use C++ over C# in .NET programming ?
| Quote: |
[...]
and you still can consume native C++ code by manually initializing
your mixed mode Dlls or use PInvoke to use a native DLL in any language.
The mixed mode C++ Dll is prey to the "loader lock" bug no matter what
you do. I do not roll dice when I program. Do you ?
No. But if you don't call any code in DllMain you won't dice, but the
user of your DLL has to call initialization code and you have to set
some compiler switches. Nevertheless I would call it a "show stopper" too.
|
I think you have misunderstood the implications of the "loader lock"
bug. You do not have to call anything in DllMain for the "loader lock"
bug to occur. The user calling initialization code, which I do know
about, does not stop the "loader lock" bug from possibly occurring.
Please re-read what MS has to say about it. Once again, if there were an
absolute sure workaround to this bug, MS would have published it. There
is none AFAIK. The cowardice of the computer programming press is not
taking MS to task about this, even though MS has admitted there is no
sure workaround for it.
MS killing C++ development of components/shared assemblies for .NET for
the first 4 years of .NET's existence ( not to promote C# and VB .NET of
course but just as an "undiscovered" bug, har, har, har ) is something
which the computer programming press has assiduously ignored. It is
equivalent of Borland making sure that BCB components can not be used by
Delphi programmers for the first 10 years of VCL's existence ( not to
promote Delphi but because it is very "difficult" to do, har, har, har
). But whereas MS, having given C# and VB .NET a large headstart, has
finally equalized the playing surface, Borland continues to slant the
field toward Delphi in nearly everything they do despite C++ being a
richer and far more widely used programming language. But after all
Delphi is their language and C++ is not.
| Quote: |
You can use the BCB native DLL's in your Delphi .NET components - no
big deal.
Can you use BCB components in Delphi ? Can you use BCB classes in DLLs
in Delphi ? Can you write BCB .NET components with BCB ? No, no, and
no. What you can do using BCB code in Delphi is so negligible as not
to be worth mentioning.
I know the restrictions of BCB VCL components. If BCB will be able to
compile C++/CLI code the .NET components will be usable in each language
- at least under the .NET platform.
|
In two years time at the least in BCB. How generous of Borland ! Whereas
I can finally write C++ components/assemblies in VS Studio 2005 write
now and have them work with other .NET langauges including Delphi. This
interoperability has nothing to do with Borland.
| Quote: | And even better each C++/CLI
compliant compiler will be able to compile the code.
|
Sound like a great reason for C++ programmers to chuck the VCL and BCB.
| Quote: | And by the way I know the complete BCB story - I've bought CBX !!
|
Fool <g> !
| Quote: |
[...]
"best programming languages". Do you dare to repost that in the Delphi
newsgroup ? ;-)
I dare to repost that in any NG.
Ok. Repost C++ is the best programming language for RAD in the Delphi
newsgroup, will be happy to count the flame posts ;-9
|
Third misquotation: Do I say that C++ is the best programming language ?
I could care less who flames my posts but I have no reason to post a
message to a Delphi NG just for the purpose of saying that C++ is one of
the best programming languages. I program in Delphi also and post things
to the Delphi NGs to get help and information.
| Quote: |
Again the "not the best language to do RAD" is just your opinion.
Yes. But I'm not alone.
|
All the original thinkers and creators of mankind are inevitably alone.
Only the mob takes pride in doing and thinking what everybody else does.
| Quote: |
C++ currently lacks one feature for RAD, run-time reflection, but that
does not mean that it can not be implemented successfully through
extensions, as Microsoft in .NET and Borland in BCB have proved.
It misses for example object function pointers, patented by Borland.
|
See boost::function.
| Quote: | .NET uses delegates for that purpose.
|
See boost::signals.
| Quote: | There are libraries implementing
that feature, by using "dirty" hacks or template based solutions like
"boost".
|
Glad you know about it. But lumping "dirty" hacks with perfectly legal
template solutions is wrong.
| Quote: | But boost function pointers have a rather large overhead to
implement an 8 byte object function pointer.
|
In the world of gigabyte memory chips I do not worry about it very much.
| Quote: |
With C++/CLI C++ can be tightly coupled to any .NET language.
|
You are making an admirable case for VS 2005 now. But this does not
apply to VS 2002/2003 obviously, and that was the subject of my initial
reply. Thanks for supporting my viewpoint.
| Quote: | Therefore
I would prefer a Delphi/C#/C++ combo over a native C++ solution.
Why ? Just because they (C#, Delphi) compile much faster and are better
supported with additional IDE features (code insight etc.)
Don't get me wrong, I like C++, STL boost templates and most of my code
is C++, but that doesn't mean that I'm perfectly happy with C++.
C++ is for example ill designed regarding it's compatibility to C, it
could compile C code, but IHMO it was a big mistake to allow macros to
affect other code and not to support a unit concept. IIRC Stroustroup
also called it a mistake (Macros). At least this is why C++ still
compiles that slow and needs quirky workarounds like "precompiled
header" files.
|
Macros have little do to with C++'s slower compilation time, but even if
C++ compiles slower it means far less to me than to you.
| Quote: |
If C# could compile my C++ code (extern "C++" ) and would support
templates, stack objects, RAII this would be my perfect language.
The world is not perfect, so I choose the language which best fits (for
me).
|
Good. I do too.
| Quote: |
Mostly this will be C++ for me, so I'm not against C++, but your
statement "best language" (for everything) bothered me somewhat .
|
Since I did not say that anywhere ( third misquotation ), I suggest you
try re-reading what I did say, or curbing your imagination in this regard.
|
|
| Back to top |
|
|
Edward Diener
Guest
|
| Posted: Sun Dec 11, 2005 10:31 pm Post subject: Re: new C++ compiler conformance to the standard |
|
|
Rudy Velthuis [TeamB] wrote:
| Quote: | At 21:26:16, 11.12.2005, Andre Kaufmann wrote:
b) Commonly components are shipped with source, thus requiring
others to read and understand native C++ / managed C++
Nothing requires components to be shipped with source. Only open
source fanatics insist on such nonsense as an absolute rule.
I'm not an open source fanatic. It's not a requirement but common, at
least for most Delphi components I know
And apparently customary in the .NET world.
|
But not required. If it were MS would have a large scale revolt of
programmers on their hand.
My point was not being against those who ship the source, if they like,
but against those who act as if it must be a rule to do so, that it must
be required. These are the fanatics of the open source world. Once it
becomes required of me to ship my own code for any implementation I have
done, I will be through with computer programming.
|
|
| Back to top |
|
|
Rudy Velthuis [TeamB]
Guest
|
| Posted: Sun Dec 11, 2005 10:40 pm Post subject: Re: new C++ compiler conformance to the standard |
|
|
At 23:31:25, 11.12.2005, Edward Diener wrote:
| Quote: | I'm not an open source fanatic. It's not a requirement but common,
at least for most Delphi components I know
And apparently customary in the .NET world.
But not required.
|
Required or not depends on the wishes of the customers. In the .NET
world, many customers do require it.
--
Rudy.Velthuis {TeamB} http://velthuis.homepage.t-online.de/
"People demand freedom of speech to make up for the freedom of thought
which they avoid."
-- Soren Aabye Kierkegaard (1813-1855)
|
|
| Back to top |
|
|
Edward Diener
Guest
|
| Posted: Mon Dec 12, 2005 12:24 am Post subject: Re: new C++ compiler conformance to the standard |
|
|
Rudy Velthuis [TeamB] wrote:
| Quote: | At 23:31:25, 11.12.2005, Edward Diener wrote:
I'm not an open source fanatic. It's not a requirement but common,
at least for most Delphi components I know
And apparently customary in the .NET world.
But not required.
Required or not depends on the wishes of the customers. In the .NET
world, many customers do require it.
|
Then "many customers" will not buy software which does not have it.
Funny that "many customers" buy Windows, and Word, and BCB, and Visual
C++ without the source code to the actual implementations, and use them
successfully every day. I guess there are some "customers", poor souls,
who do not require it. What is the world coming to ?
There are even reusable libraries and components which do not ship with
any source code and are yet considered usable and important and
supported and well documented. As I recall this is what header files and
libraries in C++ are all about. I even recall that one of the precepts
of C++ is that one should not need to have source code in order to use
classes and libraries successfully. Eventually this will be extended to
C++ templates whenever the C++ standard committee realizes how important
this is.
|
|
| Back to top |
|
|
Michael McCulloch
Guest
|
| Posted: Mon Dec 12, 2005 7:48 am Post subject: Re: new C++ compiler conformance to the standard |
|
|
On Sun, 11 Dec 2005 19:24:31 -0500, Edward Diener
<eddielee_no_spam_here (AT) tropicsoft (DOT) com> wrote:
| Quote: | There are even reusable libraries and components which do not ship with
any source code and are yet considered usable and important and
supported and well documented.
|
Yes, but access to source code, all other things being approximately
equal, is a big plus for most developers.
I found a bug in the version 4 VCL that was causing an appreciable
number of my customers to experience a severe memory leak. Without the
source code for the VCL, I would have had little shot at finding and
fixing the issue (I was able to subclass the offending VCL class and
do a workaround that duplicated code in a member function minus the
memory leak). Without a fix, I would be at a significant disadvantage
in the marketplace.
I have seen both sides of the coin, and the availability of source
code is not a minor issue to consider. In fact, it is one my biggest
complaints with Apple's OS X developer kits.
---
Michael McCulloch
|
|
| Back to top |
|
|
Rudy Velthuis [TeamB]
Guest
|
| Posted: Mon Dec 12, 2005 11:54 am Post subject: Re: new C++ compiler conformance to the standard |
|
|
At 01:24:31, 12.12.2005, Edward Diener wrote:
| Quote: | Required or not depends on the wishes of the customers. In the .NET
world, many customers do require it.
Then "many customers" will not buy software which does not have it.
Funny that "many customers" buy Windows, and Word, and BCB, and Visual
C++ without the source code to the actual implementations
|
That is different. Programmers who buy components might be more
interested in the code (especially as insurance for future situations --
so they can recompile it if necessary) than users who use Word or
Windows. Note that the compilers for most of these components (C# and
VB.NET, yes, even C++) are freely available (Borland even uses the free
C# and VB.NET compilers in Delphi 2005 and BDS 2006). That is why it is
probably important that Borland also releases a free Delphi and C++
compiler, IMO.
--
Rudy.Velthuis {TeamB} http://velthuis.homepage.t-online.de/
"Victory goes to the player who makes the next-to-last mistake."
-- Chessmaster Savielly Grigorievitch Tartakower (1887-1956)
|
|
| 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
