Board index » cppbuilder » Re: Will C++ compiler makers add C++/CLI features to native compilers?

Re: Will C++ compiler makers add C++/CLI features to native compilers?


2006-02-03 01:52:39 AM
cppbuilder41
Peter Agricola wrote:
Quote
"Andre Kaufmann" wrote:
>>[...]
>>I do not agree. Features should not be added just for the sake of it.
>I think they should, why not ?. Other languages do that too - more rapidly
>and they don't have that much problems.

You are the only one who can decide C++ is the right language for you. If it
isn't then choose _another_ language eg C++/CLI or Delphi or Python. But
don't force other people who find C++ the best language for _their_ job to
use your language too.
Which language ? What are you speaking of ?
I speak for example of the Intel extensions known as OPEN MP, which adds
some features to C++ to execute parts of the code parallel without
handling threads by yourself.
It's only an example of an extension that is not C++ standard. Another
one are VCL extensions, C++/CLI etc.
I only have the odd feeling that C++ does not evolve fast enough, so
that more and more of these extensions will be added and none of them
are C++ standard.
I just wanted to discuss this fact, I don't want to force other people
to use another language and I don't think just because we are discussing
here some features of other languages that will bring people to move to
another language.
A language that cannot be criticized and discussed about and does not
evolve will die, sooner or later.
Quote
Peter
Andre
 
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

Rudy Velthuis [TeamB] wrote:
Quote
Andre Kaufmann wrote:

>>>I have no problem with there being yet another C++-like language,
>>>but I just want to ensure that there is no confusion about what
>>>is and isn't C++, and currently I do worry that people will not
>>>know where the true boundaries stand.
>>As we have already seen in the other thread about C++/CLI.
>I don't really see the point. The confusion was about which compiler
>can already compile "for each".

No, the confusion was about that "for each" is not standard C++, only
C++/CLI. People who use VC++ will slowly lose perspective about the
differences.
Will that happen to BCB users too, since BCB will also support C++/CLI ?
I'm using both compilers and still know which extensions are supported
by which compiler. BCB has also non C++ standard extensions. For example
the construction of VCL objects is differently to C++ standard and they
don't support multiple derivation. Nobody complains about that fact and
that BCB users will slowly lose perspective.
Please forget about the VC discussion in this thread, I tried to prevent
to name this compiler explicitly as I've wrote before.
All I'm interested in is that BCB will support C++/CLI too.
I try to keep my projects in sync with at least 2 compilers.
Andre
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

Rudy Velthuis [TeamB] wrote:
Quote
Andre Kaufmann wrote:

>>No, the confusion was about that "for each" is not standard C++,
>>only C++/CLI. People who use VC++ will slowly lose perspective
>>about the differences.
>Will that happen to BCB users too, since BCB will also support
>C++/CLI ?

Who said that? I must have missed the news.
Quote from:
community.borland.com/article/0,1410,33383,00.html#5DelphiLonghorn
Quote:
"In addition to supporting Longhorn, Avalon, Indigo, and the WinFX APIs
from Microsoft, this release will introduce managed C++ support"
End of Quote:
Managed C++ is surely C++/CLI - or am I wrong ?
It's this fact that brought me to jump into the thread and into this
(wild) discussion. If C++/CLI would have been only bound to a Microsoft
compiler I wouldn't have argued that aggressively for C++/CLI.
Quote
Anyway, since it is not C++, it should not be called C++.
It's called C++/CLI, I don't have a problem with a new name.
Perhaps C++++ :-9
Sorry (just a joke) *g*
Andre
 

{smallsort}

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

AlisdairM wrote:
Quote
Maybe the problem is C++ needs fewer features, not more? ;?
It needs a few new features that allow programmers to avoid using many older features.
Quote
The problem is C++ already carries a legacy of many features that cause
problems today. Any new feature you add to the language is another set
of interactions with this already over-complex system.
If it is overly complex maybe it is going to start down the slow path toward becoming
an also-ran.
Quote
It is simply
much harder to add cool new features without breaking something, and
that is why new languages can succeed. If the new cool feature is so
great and stunning, you can design a lightweight language to take
advantage without that annoying legacy of backwards compatibility and
support.
Well, if the lightweight language gets that feature and C++ doesn't then people will
be less inclined to use C++.
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

"Andre Kaufmann" wrote:
Quote
Which language ? What are you speaking of ?
[snip]
I only have the odd feeling that C++ does not evolve fast enough, so that
more and more of these extensions will be added and none of them are C++
standard.
Extensions are by definition not standard. What is your point?
Quote
I just wanted to discuss this fact, I don't want to force other people to
use another language and I don't think just because we are discussing here
some features of other languages that will bring people to move to another
language.
If you see another language wich you like more than your current language,
switch. Don't critizice your old language for not being the new language. I
don't say C++ should not be improved, but it has to be done carefully.
Adding features because other languages have them is not a good reason IMO.
After all, that's why that other language is a different language.
Quote
A language that cannot be criticized and discussed about
It can and it should and it happens with C++.
Quote
and does not evolve will die, sooner or later.
Yes, what's wrong with that? When people got better alternatives they moved
away from COBOL. Starting over again from scratch is sometimes the best one
can do.
Peter
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

Andre Kaufmann wrote:
Quote
Quote from:

community.borland.com/article/0,1410,33383,00.html#5DelphiLongh
orn

Quote:

"In addition to supporting Longhorn, Avalon, Indigo, and the WinFX
APIs from Microsoft, this release will introduce managed C++ support"

End of Quote:
Managed C++ is surely C++/CLI - or am I wrong ?
Managed C++ is the name for a different set of Microsoft extensions. I
would hope Borland look into C++/CLIO instead ;? [whatever it is
finally called!]
Remember, these roadmaps are not concrete plans, but stated aims.
Delphi Longhorn is a long way off yet, and the IT industry can change a
lot in that time. I would hate to hold Borland to the letter of a
roadmap, rather than respond to change.
--
AlisdairM(TeamB)
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

"AlisdairM" wrote:
Quote
Managed C++ is the name for a different set of Microsoft extensions. I
would hope Borland look into C++/CLIO instead ;? [whatever it is
finally called!]
I think the name C++/CLIO will meet the same resistance as C++/CLI, and I
think TeamB members should refrain from clandestine adevertising in Borlands
newsgroups <g>
Peter
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

Peter Agricola wrote:
Quote
I think the name C++/CLIO will meet the same resistance as C++/CLI,
and I think TeamB members should refrain from clandestine
adevertising in Borlands newsgroups <g>
I'm sure he doesn't renault what you're talking about :D
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

At 13:02:15, 03.02.2006, Andrue Cope [TeamB] wrote:
Quote
Peter Agricola wrote:

>I think the name C++/CLIO will meet the same resistance as C++/CLI,
>and I think TeamB members should refrain from clandestine
>adevertising in Borlands newsgroups <g>

I'm sure he doesn't renault what you're talking about :D
LOL!
--
Rudy Velthuis [TeamB] rvelthuis.de/
"Ever notice that anyone going slower than you is an idiot, but anyone
going faster is a maniac?" -- George Carlin
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

Edward Diener wrote:
Quote
It can change when the members of the C++ standards commitee change
their way of thinking about the necessity about being compatible with
the C programming language. When they do C++ can move forward more
rapidly as a language of its own.
I pretty much agree with that. It is sometimes nice to be able to
find some old C code on the web and incorporate it into a program, but
when I do I almost always update it to C++ anyway, if that has not
already been done.
And while I'd like to see C++ move forward more rapidly, I'd hate to
see it become too much of a moving target. It's frustrating waiting
for the new features to be hammered into shape, but it's even more
frustrating waiting for BCB to fully support BOOST.
Even as it is, I think C++ is a pretty useful and satisfying
language. I'd really hade to see it diluted by accommodations to CLI
or whatever.
- Leo
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

"Andrue Cope wrote:
Quote
I'm sure he doesn't renault what you're talking about :D
We don't know who Mr. X is...
Peter
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

At 07:26:24, 02.02.2006, Andre Kaufmann wrote:
Quote
I agree totally. It's already beginning. C++ had always the advantage
to be a language which compiles to the most effective code.
I'm not so sure of that, actually.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"For if he like a madman lived, At least he like a wise one died."
-- Cervantes.
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

Rudy Velthuis [TeamB] wrote:
Quote
At 07:26:24, 02.02.2006, Andre Kaufmann wrote:

>I agree totally. It's already beginning. C++ had always the advantage
>to be a language which compiles to the most effective code.

I'm not so sure of that, actually.
That it had or that it still has ?
C++ compiler do generate highly optimized code. But that doesn't mean
that the application in general is the fastest, compared to other ones
written in other languages nor does it mean that it's significant (anymore)
Andre
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

At 18:14:33, 03.02.2006, Andre Kaufmann wrote:
Quote
Rudy Velthuis [TeamB] wrote:
>At 07:26:24, 02.02.2006, Andre Kaufmann wrote:
>
>>I agree totally. It's already beginning. C++ had always the
>>advantage to be a language which compiles to the most effective
>>code.
>
>I'm not so sure of that, actually.

That it had or that it still has ?
Both.
Quote
C++ compiler do generate highly optimized code.
Dunno. A few benchmarks done by John Jacobson on his website showed that
BCB was generally a little slower than Delphi, when solving the same
problem. Everyone could send a solution in their favourite language.
I think that it is a myth that C++ compilers generate more optimized code
than compilers of other languages. C++ users may think so, though.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"Science is like sex: sometimes something useful comes out, but that is
not the reason we are doing it" -- Richard Feynman
 

Re:Re: Will C++ compiler makers add C++/CLI features to native compilers?

At 07:04:19, 02.02.2006, Andre Kaufmann wrote:
Quote
Nicola Musatti wrote:
>Randall Parker wrote:
>[...]
>Consider this: which non win32 C++ compiler do you know which added
>MS extensions/libraries? I know none.
>

AFAIK BCB has some Microsoft specific extensions, to compile MFC source.
I didn't know such extensions were required for MFC, except of course the
MFC libraries and headers.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"There is only one nature - the division into science and engineering is
a
human imposition, not a natural one. Indeed, the division is a human
failure; it reflects our limited capacity to comprehend the whole."
-- Bill Wulf