I don't want to start a war but why would I choose one over the other?
First and foremost I need to keep in mind marketability of the skill and
the future of the language.
I'm getting the feeling I'll be moving from VB to one or the other. I
have some say on which but perhaps not the final decision. I have used
C and C++ a little bit years ago. I have no experience in C#. I don't
expect it to be that difficult but I hate remembering the idiosyncrasies
of too many languages so I'd like to pick one C# or C++ and make the
right choice.
Jun 27 '08
151  4088 
Geesh, I sure got a lot of posts on that one. I'm not sure where I'm
headed but I appreciate the opinions.
cj wrote:
I don't want to start a war but why would I choose one over the other?
First and foremost I need to keep in mind marketability of the skill and
the future of the language.
I'm getting the feeling I'll be moving from VB to one or the other. I
have some say on which but perhaps not the final decision. I have used
C and C++ a little bit years ago. I have no experience in C#. I don't
expect it to be that difficult but I hate remembering the idiosyncrasies
of too many languages so I'd like to pick one C# or C++ and make the
right choice.
cj wrote:
Geesh, I sure got a lot of posts on that one. I'm not sure where I'm
headed but I appreciate the opinions.
lol Is become a C++ forum. Nice thread.
Learn a bit of C++ first, even just the basics you will appreciated C# more. Don't go into depth
just basics.
I knew a bit of C and C++ and currently learning C#. I love C# because it reminds me of C and has
encouraged me to learn C++. Once I am more confident in C# I will begin to dig in C++.
Also note all games are written in C & C++. Well most mainstream commercial games. C++ is not going
to die out within our lifetime.
Those who say is dying are talking rubbish and hype. C++ programmers will die out long before C++.
That is the most likely outcome, and watch salaries soar.
--
Adhal Freeware http://www.adhal.org
Hendrik Schober wrote:
Arne Vajhøj wrote:
>Hendrik Schober wrote:
>>MC <fo**************@www.ai.uga.edu.slash.mcwrote:
[...]
That is a good point. Object-oriented programming wasn't mature
when C++ came into use. There is a lot of bad C++ code in the
world, and C++ makes it easy to write bad code and create programs
that crash.
I think C will outlive C++. C is going to continue to be a good
language for small routines where performance is paramount. For
such things, I find myself writing "C-barely-plus-plus," which is C
with slight use of the C++ extensions. [...]
IMO these to paragraphs contradict each other. C makes it a lot
easier to write bad, crashing code, than C++ does.
Since C++ support practically all of C then ...
...if C++ wouldn't do so much to make it easy to write
better, safer code, my above statement wouldn't make
sense. Yes. Your point?
Should be obvious.
Arne
Cholo Lennon wrote:
Arne Vajhøj wrote:
>Cholo Lennon wrote:
>>"Arne Vajhøj" <ar**@vajhoej.dkescribió en el mensaje
news:48***********************@news.sunsite.dk.. .
Nick wrote:
Curious. I wouldn't see C# as fundamentally better for writing
Object-oriented code. I see the two languages as essentially the
same but C# has removed the need for explicit memory management
and a few other house keeping issues
More access levels, interfaces and delegates seems
to me to be features that makes good OOP easier.
Just some clarification: In C++ you have interfaces (abstract
classes) and delegates (std::tr1::function or boost::function)
C# also has abstract classes and even though abstract classes can
be used instead of interfaces, then interfaces especially when
combined with the only inherit from one class but implement
multiple interfaces rules really guide users towards good
OOP style.
It's a point of view...
>TR1 is fine, but strictly speaking it is not C++ yet (it may
be in 2009 rumors say).
Well, some compilers are distributing partial tr1 implementations and function
is included. BTW boost::function (in which std::tr1::function is based) has many
years and is widely used in modern C++ code / production code.
boost != C++
But on the other side:
- very few are using only ANSI features
- boost is widely used
- the C++ standardization process is let us call it thorough
so maybe it is a more fair comparison to include boost in C++
functionality.
Arne
Daniel James wrote:
In article news:<48***********************@news.sunsite.dk>, Arne
Vajhøj wrote:
>If you teach C++ to 50 students, then you may get 10 great
programmers and 40 that swear never to try and program again.
I'd call that a positive result! Certainly better than getting 50
mediocre programmers.
Seen from a puristic point of view I will agree. But there
is this aspect of the world called money - we need millions
of programmers to code business apps.
Arne
Don't confuse flexibility with lack of safety -- you can have the one
without the other.
How is this confused? My point was C# is not less flexible because it allows
pointer tricks, something that C++ claims as an advantage, safety or lack of
it has nothing to do with the argument. At the end of the day, you have the
best of both worlds in C#.
The single most glaringly obvious example of what I mean is that you
can't do template metaprogramming in C#, but there are others.
And what is that good for? I wouldn't go searching for obscure features to
compare against C#. What I would do is compare common code paths and
implementation. Like it or not, C++ is a dying sport. Holding on to
obscurities will not inject life into it.
more strictly, to provide a plugin replacement for Java
That's new. By the same token C++ was what to C?
It's time to let go of C++. Really, it is. It's done for.
--
Regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
-------------------------------------------------------
"Daniel James" <wa*********@nospam.aaisp.orgwrote in message
news:VA******************@nospam.aaisp.org...
In article news:<87**********************************@microso ft.com>,
Alvin Bruney [ASP.NET MVP] wrote:
>Why is it more powerful and more flexible? I thought you could write
'unsafe' code in C#.
Don't confuse flexibility with lack of safety -- you can have the one
without the other.
Why is C++ more powerful than C#? Because you can do more things with
it, in more ways. C# is designed to support the "Object Oriented"
paradigm (or, more strictly, to provide a plugin replacement for Java
-- which is an almost religiously 'pure' OO language) but C++ is a
multi-paradigm language -- it can "do OOP", but it can be used to
implement other designs as well.
The single most glaringly obvious example of what I mean is that you
can't do template metaprogramming in C#, but there are others.
Cheers,
Daniel.
What's replacing them for the real-time control portions of the code?
Real time control where? If you are talking at the switch level, that's C
code. Period. I'm not aware of any of the major telecom players who would
touch that code because it is business critical. You could interpret that as
C is superior. I'll interpret it as don't mess with it because it ain't
broke.
Anything north of the switch to include the billing platforms, call routing
on up to client reporting and statistics is not C and not C++.
I once wrote a C# proof of concept for a company just to show that C# could
outperform C for billing and summarization. It worked, hands down, because
C# has a better memory allocation model for memory intensive applications,
which billing and summarization is. However, nobody wanted me to implement
the concept in the real world because the existing application was 'mission
critical'. go figure. C at the real time portion of the code is not there
because it brings any major advantage over what we have today.
--
Regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
-------------------------------------------------------
"Michael D. Ober" <obermd.@.alum.mit.edu.nospam.wrote in message
news:ML******************************@earthlink.co m...
"Alvin Bruney [ASP.NET MVP]" <vapor dan using hot male spam filterwrote
in message news:EF**********************************@microsof t.com...
>>Huh? Our entire telecommunications industry is written in C and C++
Sleight of hand. I worked for a few years in the telecommunications
industry. C and C++ happen to be entrenched there because at the time
that was the dominant languages. As these pieces get re-written,
rest-assured they won't be re-written in these languages because there's
nothing to gain using these technologies in telecommunications. I know,
I've been there.
What's replacing them for the real-time control portions of the code?
Mike.
I agree 100%. I should have said earlier "if these pieces get re-written..."
--
Regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
-------------------------------------------------------
"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:48***********************@news.sunsite.dk...
Alvin Bruney [ASP.NET MVP] wrote:
>>Huh? Our entire telecommunications industry is written in C and C++
Sleight of hand. I worked for a few years in the telecommunications
industry. C and C++ happen to be entrenched there because at the time
that was the dominant languages. As these pieces get re-written,
rest-assured they won't be re-written in these languages because there's
nothing to gain using these technologies in telecommunications. I know,
I've been there.
Applications rarely get rewritten. I would expect most of the existing
C and C++ apps to continue running for a decade or two more. Just
think of how many 30 year old Cobol and PL/I code that are still around.
New apps will likely be written in something else (Java or .NET) unless
there are special reasons not to (hardware interfaces or real time
requirements or requirement for very low memory footprint).
Arne
Alvin Bruney [ASP.NET MVP] wrote:
>What's replacing them for the real-time control portions of the code?
Real time control where? If you are talking at the switch level, that's
C code. Period. I'm not aware of any of the major telecom players who
would touch that code because it is business critical. You could
interpret that as C is superior. I'll interpret it as don't mess with it
because it ain't broke.
Or the real time requirements and/or requirements for low
memory foot print does not lend itself to a C# solution.
[I don't know but I assume that a switch has relative
little memory]
Arne
Then, Alvin, next Windows will be done in C#?
"Alvin Bruney [ASP.NET MVP]" <vapor dan using hot male spam filterwrote in
message news:10**********************************@microsof t.com...
>Don't confuse flexibility with lack of safety -- you can have the one
without the other.
How is this confused? My point was C# is not less flexible because it
allows pointer tricks, something that C++ claims as an advantage, safety
or lack of it has nothing to do with the argument. At the end of the day,
you have the best of both worlds in C#.
>The single most glaringly obvious example of what I mean is that you
can't do template metaprogramming in C#, but there are others.
And what is that good for? I wouldn't go searching for obscure features to
compare against C#. What I would do is compare common code paths and
implementation. Like it or not, C++ is a dying sport. Holding on to
obscurities will not inject life into it.
>more strictly, to provide a plugin replacement for Java
That's new. By the same token C++ was what to C?
It's time to let go of C++. Really, it is. It's done for.
--
Regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
-------------------------------------------------------
"Daniel James" <wa*********@nospam.aaisp.orgwrote in message
news:VA******************@nospam.aaisp.org...
>In article news:<87**********************************@microso ft.com>,
Alvin Bruney [ASP.NET MVP] wrote:
>>Why is it more powerful and more flexible? I thought you could write
'unsafe' code in C#.
Don't confuse flexibility with lack of safety -- you can have the one
without the other.
Why is C++ more powerful than C#? Because you can do more things with
it, in more ways. C# is designed to support the "Object Oriented"
paradigm (or, more strictly, to provide a plugin replacement for Java
-- which is an almost religiously 'pure' OO language) but C++ is a
multi-paradigm language -- it can "do OOP", but it can be used to
implement other designs as well.
The single most glaringly obvious example of what I mean is that you
can't do template metaprogramming in C#, but there are others.
Cheers,
Daniel.
--
Microsoft Visual C++ MVP
========================
Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y programación
========================================
Una palabra mal colocada estropea el más bello pensamiento.
-- Francois Marie Arouet.
Alvin Bruney [ASP.NET MVP] wrote:
[...]
>The single most glaringly obvious example of what I mean is that you
can't do template metaprogramming in C#, but there are others.
And what is that good for? [...]
It shifts tasks from the run-time to the compile-time. IMO
the biggest advantage of this is that you catch more errors
at compile-time. OTOH, this allows C++ to rival FORTRAN's
speed for some applications, which for some people is far
more important.
I wouldn't call these obscure features.
Schobi
In article news:<48***********************@news.sunsite.dk>, Arne
Vajhøj wrote:
C# also has abstract classes and even though abstract classes can
be used instead of interfaces, then interfaces especially when
combined with the only inherit from one class but implement
multiple interfaces rules really guide users towards good
OOP style.
I think your notion of "good OOP style" is misplaced. You are saying
what Java programmers have been saying that for some time -- because
Java doesn't give them any choice.
You are, of course, free to follow that convention in C++ -- but if you
do so you will be limiting your design choices. There is nothing
inherently wrong with allowing a class to inherit from multiple
concrete base classes, and doing so can be a useful way to encapsulate
common aspects of behaviour shared by several classes. This can
simplify design and reduce code sizes.
Cheers,
Daniel.
In article news:<10**********************************@microso ft.com>,
Alvin Bruney [ASP.NET MVP] wrote:
Don't confuse flexibility with lack of safety -- you can have the
one without the other.
How is this confused? My point was C# is not less flexible because
it allows pointer tricks, ...
... and your point is misplaced because it is largely not the ability to
perform "pointer tricks" that makes C++ more flexible or more powerful.
Yes, being able to manipulate machine addresses through pointers may
make C++ a suitable choice for very low level code (firmware, drivers,
etc.) -- which C# is not -- but on most modern architectures (with
hardware memory management and address remapping) C++'s addresses don't
correspond to meaningful physical memory addresses anyway.
No, pointer manipulation is not what we're discussing, here.
The single most glaringly obvious example of what I mean is that you
can't do template metaprogramming in C#, but there are others.
And what is that good for?
If you have no conception of the answer to that question I can't hope to
persuade you that you are missing something very important.
I wouldn't go searching for obscure features to compare against C#.
What I would do is compare common code paths and implementation.
Like it or not, C++ is a dying sport. Holding on to obscurities
will not inject life into it.
There's nothing obscure about TMP. It's what makes the C++ standard
library so hugely powerful, it's what makes some of the amazingly useful
libraries in, for example, Boost possible. Modern C++ code is built on
templates and it makes the language hugely more powerful than a
classical OOP language like C# or Java could ever hope to be. Even if a
C++ programmer never writes a single template in his whole life he has
all the power of those libraries to draw upon.
more strictly, to provide a plugin replacement for Java
That's new. By the same token C++ was what to C?
C++ is based on C, but is not a simple replacement. The syntax of C++ is
almost a proper superset of that of C (i.e. most, but not all C source
will compile correctly if fed through a C++ compiler) with new semantics
and new functionality that represent an evolutionary increase in
flexibility and power.
C# is based on Java. It has a slightly different syntax and a different
set of runtime APIs, but it is semantically very similar -- a little
better, because some of the mistakes of Java were not repeated, but
largely similar. Where is the evolutionary advance here? Nowhere.
It's time to let go of C++. Really, it is. It's done for.
You really have no idea.
Cheers,
Daniel.
In article news:<48***********************@news.sunsite.dk>, Arne
Vajhøj wrote:
I'd call that a positive result! Certainly better than getting 50
mediocre programmers.
Seen from a puristic point of view I will agree. But there
is this aspect of the world called money - we need millions
of programmers to code business apps.
10 first class programmers will do more useful work in less time than
50 mediocre programmers ... and you will get fewer bugs.
In a world with concerns such as money you can't afford the mediocre.
Cheers,
Daniel.
Alvin Bruney [ASP.NET MVP] wrote:
It's time to let go of C++. Really, it is. It's done for.
Says who?
C++/CLI as a first class .NET language does indeed appear doomed. Maybe using
C++ for .NET was a bad concept from the beginning, or maybe it was done in by
the flawed initial version of MC++. But, anyway, it seems dead.
C++/CLI is great for inter-op, but that is a limited market compared to all the
things that C# can do in .NET.
But native C++ lives on, both as a cross platform language, and in many
MFC/Win32 applications that are never going to switch to .NET. The Visual C++
team is strongly committed to improve the native coding experience in the next
version of Visual Studio, after many years of neglect.
It is a pity that MFC is a bloated and not very elegant framework, but it works.
It can still be used to create applications that would be difficult to do in C#.
And if you do not like MFC, there are WTL, wxwidgets, QT ... A lot of C++ code
is non-GUI anyway.
C++ is not dead yet. And C# is not the perfect language either. Too much
influenced by Java, IMHO.
--
David Wilkinson
Visual C++ MVP
On Tue, 24 Jun 2008 08:42:43 -0400, David Wilkinson
<no******@effisols.comwrote:
>C++/CLI as a first class .NET language does indeed appear doomed. Maybe using
C++ for .NET was a bad concept from the beginning, or maybe it was done in by
the flawed initial version of MC++. But, anyway, it seems dead.
C++/CLI is great for inter-op, but that is a limited market compared to all the
things that C# can do in .NET.
what exactly can be done in C# that can't be done in C++/CLI (VS
2008)?
Daniel James wrote:
In article news:<10**********************************@microso ft.com>,
Alvin Bruney [ASP.NET MVP] wrote:
>>Don't confuse flexibility with lack of safety -- you can have the
one without the other.
How is this confused? My point was C# is not less flexible because
it allows pointer tricks, ...
.. and your point is misplaced because it is largely not the ability to
perform "pointer tricks" that makes C++ more flexible or more powerful.
Yes, being able to manipulate machine addresses through pointers may
make C++ a suitable choice for very low level code (firmware, drivers,
etc.)
-- which C# is not
Hm, why ? Singularity / Cosmos are operating systems in C#. The
MicroFramework targets embedded devices.
-- but on most modern architectures (with
hardware memory management and address remapping) C++'s addresses don't
correspond to meaningful physical memory addresses anyway.
No, pointer manipulation is not what we're discussing, here.
O.k. pointer manipulation is the main task of C ;-).
[...]
There's nothing obscure about TMP. It's what makes the C++ standard
Hm, which C++ standard library is using meta templates ? IIRC Tr1 will
use them, boost library uses them but the STL ?
library so hugely powerful, it's what makes some of the amazingly useful
Which powerful standard library in C++ can I use for file operations ?
libraries in, for example, Boost possible.
Boost is a good, cool library - sure. But these libraries get somewhat
bloated, because of all the template stuff and compilation slows down
more and more.
And for example I dare to say that boost::function has a higher
overhead, than C# delegates.
Modern C++ code is built on
templates and it makes the language hugely more powerful than a
I thought it to be so too. I have implemented discriminated unions, used
type lists as they are in Loki for example and all the nice stuff.
What I got was unreadable, hard to debug and bloated code which needed a
very long time to compile.
The one compiler emitted code with a size of 3MB, the other one compiled
the same sources to 6MB.
After I had replaced all the TMP stuff by generated code the code size
could be reduced to 1MB.
classical OOP language like C# or Java could ever hope to be. Even if a
C++ programmer never writes a single template in his whole life he has
all the power of those libraries to draw upon.
Could you give me an example (part of a library), which is more powerful.
>>more strictly, to provide a plugin replacement for Java
That's new. By the same token C++ was what to C?
C++ is based on C, but is not a simple replacement. The syntax of C++ is
almost a proper superset of that of C (i.e. most, but not all C source
will compile correctly if fed through a C++ compiler) with new semantics
and new functionality that represent an evolutionary increase in
flexibility and power.
But C++ inherited the worst from C - macros.
C# is based on Java. It has a slightly different syntax and a different
set of runtime APIs, but it is semantically very similar -- a little
better, because some of the mistakes of Java were not repeated, but
largely similar. Where is the evolutionary advance here? Nowhere.
- LINQ
- Delegates
- Library, which isn't bound to a single language
- Lambda expressions
- Implicit typed variables
- and many more
C++ will get some of these too, but then the argument that C++ hasn't
invented these could be used too.
>It's time to let go of C++. Really, it is. It's done for.
You really have no idea.
Hm, I once was a die hard C++ developer and argued the same way. But
today I'm not that sure about C++ and it's future.
I would prefer >every time< a native C# or would prefer the 'D'
language, if it would be better supported by most of the commercial
developer tools and could (directly) compile (old) C++ code.
Have you used another language than C++ too, to make a good comparison ?
I don't want to start a language war - better said continue one. But I
too think the evolution of C++ is currently too slow and heading in the
wrong direction, since modules in C++ are still delayed. If I compare
what abstraction level I can reach for example with F# and how I'm still
able to use my C# code easily, I don't think that C++ is still the
>only< way to go.
Cheers,
Daniel.
Cheers,
Andre
Andre Kaufmann wrote:
Daniel James wrote:
>Yes, being able to manipulate machine addresses through pointers may
make C++ a suitable choice for very low level code (firmware, drivers,
etc.)
>-- which C# is not
Hm, why ? Singularity / Cosmos are operating systems in C#. The
MicroFramework targets embedded devices.
An desktop/server OS is huge today.
Large parts of an OS can be written in managed code.
But some things has to be written in unmanaged code.
I don't know how much. Maybe 5%.
Even Singularity has a small amount of C++ and assembler.
If we go to embedded devices with much less features then I would
expect the percentage to go up.
And do not get me wrong - I am expecting the next major OS to have
huge part written in managed code. But as expressed in another
subthread - we may have to wait some time for the next major OS.
Boost is a good, cool library - sure. But these libraries get somewhat
bloated, because of all the template stuff and compilation slows down
more and more.
Compilation speed is usually not important.
>C# is based on Java. It has a slightly different syntax and a
different set of runtime APIs, but it is semantically very similar --
a little better, because some of the mistakes of Java were not
repeated, but largely similar. Where is the evolutionary advance here?
Nowhere.
- LINQ
- Delegates
- Library, which isn't bound to a single language
- Lambda expressions
- Implicit typed variables
- and many more
Actually the Java library is not bound to the Java language. You
can use it in Ada (jGnat), Python (Jython) etc..
Arne
David Wilkinson wrote:
C++/CLI as a first class .NET language does indeed appear doomed. Maybe
using C++ for .NET was a bad concept from the beginning, or maybe it was
done in by the flawed initial version of MC++. But, anyway, it seems dead.
C++/CLI is great for inter-op, but that is a limited market compared to
all the things that C# can do in .NET.
But native C++ lives on, both as a cross platform language, and in many
MFC/Win32 applications that are never going to switch to .NET. The
Visual C++ team is strongly committed to improve the native coding
experience in the next version of Visual Studio, after many years of
neglect.
I tend to agree.
People that want to write managed code chose C# instead of C++/CLI. It
is simply easier.
C++ will most certainly live on for many years.
I am a bit skeptical about MFC though. I think MFC will be
squeezed hard by .NET in the next 10 years. As the UI's need
to get a major rewrite then the apps will switch to .NET !
Arne
Daniel James wrote:
In article news:<48***********************@news.sunsite.dk>, Arne
Vajhøj wrote:
>>I'd call that a positive result! Certainly better than getting 50
mediocre programmers.
Seen from a puristic point of view I will agree. But there
is this aspect of the world called money - we need millions
of programmers to code business apps.
10 first class programmers will do more useful work in less time than
50 mediocre programmers ... and you will get fewer bugs.
In a world with concerns such as money you can't afford the mediocre.
If you look out in the real world, then you will see that
is not the general opinion.
Arne
RFOG wrote:
Then, Alvin, next Windows will be done in C#?
Next OS from MS could very well be done in C#.
But don't hold your breath until it hits the streets.
Arne
Daniel James wrote:
In article news:<48***********************@news.sunsite.dk>, Arne
Vajhøj wrote:
>C# also has abstract classes and even though abstract classes can
be used instead of interfaces, then interfaces especially when
combined with the only inherit from one class but implement
multiple interfaces rules really guide users towards good
OOP style.
I think your notion of "good OOP style" is misplaced. You are saying
what Java programmers have been saying that for some time -- because
Java doesn't give them any choice.
You are, of course, free to follow that convention in C++ -- but if you
do so you will be limiting your design choices.
Good OOP is about limiting choices. You encourage or force
developers to do things the right way.
There is nothing
inherently wrong with allowing a class to inherit from multiple
concrete base classes, and doing so can be a useful way to encapsulate
common aspects of behaviour shared by several classes. This can
simplify design and reduce code sizes.
Multiple inheritance has a rather bad track record.
Arne
On Jun 25, 7:12*am, Arne Vajhøj <a...@vajhoej.dkwrote:
inherently wrong with allowing a class to inherit from multiple
concrete base classes, and doing so can be a useful way to encapsulate
common aspects of behaviour shared by several classes. This can
simplify design and reduce code sizes.
Multiple inheritance has a rather bad track record.
A correction: _implementation_ multiple inheritance _in C++_ has a
rather bad track record. Implementation MI can work just fine if
properly done - Eiffel is a testament to that.
Even so, give me interfaces and syntactic sugar to delegate their
implementation to a wrapped object over implementation MI any day. The
problem is, C# has neither, and writing all those one-liner methods
that just pass the arguments on is tedious. Hm, perhaps it's worth
adding the appropriate feature request to VS Feedback.
cj,
As I often have written
VB for Net and C# are both the children of C++ and VB6.
(The VB6 part will probably be denied by people not knowing VB).
Although there is never made a VB6 for Managed code while that is there for
C++, what is of course helpfull to use both Com and Net programming, as was
often asked by dyhards from VB6, is C# made for developping in an IDE, while
C++ still is based to program using by instance a notepath.
Cor
"cj" <cj@nospam.nospamschreef in bericht
news:uK**************@TK2MSFTNGP06.phx.gbl...
>I don't want to start a war but why would I choose one over the other?
First and foremost I need to keep in mind marketability of the skill and
the future of the language.
I'm getting the feeling I'll be moving from VB to one or the other. I
have some say on which but perhaps not the final decision. I have used C
and C++ a little bit years ago. I have no experience in C#. I don't
expect it to be that difficult but I hate remembering the idiosyncrasies
of too many languages so I'd like to pick one C# or C++ and make the right
choice.
"Arne Vajhøj" <ar**@vajhoej.dkescribió en el mensaje de noticias
news:48***********************@news.sunsite.dk...
RFOG wrote:
>Then, Alvin, next Windows will be done in C#?
Next OS from MS could very well be done in C#.
We have a phrase: "confía en Dios y no corras", that will be translated as
"be confident with God and don't run".
Of course, C# can deal with LDT, GDT, vector interrupts, rings, direct
hardware access and of course microprocessors executes MSIL directly(*).
But don't hold your breath until it hits the streets.
:-)
Arne
(*) Please, read as a irony.
--
Microsoft Visual C++ MVP
========================
Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y programación
========================================
Cualquier problema sencillo se puede convertir en insoluble si se celebran
suficientes reuniones para discutirlo.
-- Regla de Mitchell.
In article news:<48***********************@news.sunsite.dk>, Arne
Vajhøj wrote:
Good OOP is about limiting choices.
No it isn't. It's about a certain kind of encapsulation.
Using OOP is itself a design choice -- a good one in some cases and a
poor one in others.
You encourage or force developers to do things the right way.
Encouragement and forcing are very different games. In solutions that
lend themselves well to OOP the benefits to be gained from OOP are
encouragement enough -- no need for the language to force the issue.
If your solution is not one that naturally lends itself to an OO
approach then forcing people to use a language that steers them
singlemindedly along an OOP path will only engender resentment and bad
programming.
Multiple inheritance has a rather bad track record.
It's certainly easy to use MI badly -- especially in C++, which doesn't
believe in restricting choices unnecessarily -- but that doesn't mean
that isn't a useful technique, or that it can't be used productively
and well.
Cheers,
Daniel.
In article news:<VA******************@nospam.aaisp.org>, Daniel James
wrote:
Ericsson's telephone exchange software is written in
Haskell, for example.
I meant Erlang, not Haskell, or course -- nice to see nobody here is
sufficiently on the ball to spot my blunder!
Cheers,
Daniel.
Arne Vajhøj wrote:
David Wilkinson wrote:
>C++/CLI as a first class .NET language does indeed appear doomed.
Maybe using C++ for .NET was a bad concept from the beginning, or
maybe it was done in by the flawed initial version of MC++. But,
anyway, it seems dead.
C++/CLI is great for inter-op, but that is a limited market compared
to all the things that C# can do in .NET.
But native C++ lives on, both as a cross platform language, and in
many MFC/Win32 applications that are never going to switch to .NET.
The Visual C++ team is strongly committed to improve the native coding
experience in the next version of Visual Studio, after many years of
neglect.
I tend to agree.
People that want to write managed code chose C# instead of C++/CLI. It
is simply easier.
C++ will most certainly live on for many years.
I am a bit skeptical about MFC though. I think MFC will be
squeezed hard by .NET in the next 10 years. As the UI's need
to get a major rewrite then the apps will switch to .NET !
Arne
The new version of MFC is just great! With the Ribbon, docking windows,
new common controls, MSN menus, and a bunch of other things... I wonder
why Microsoft is investing in MFC, if it is doomed...
Daniel James <wa*********@nospam.aaisp.orgwrote:
It's one of .NET's
significant advantages over Java (intermediate code engine targeted by more
than one source language) but that's about it.
<snip>
Um, there are *plenty* of languages targeting the JVM. Off the top of
my head:
Java (obviously)
Groovy
Scala
JRuby
Jython
That's without even bothering to think. Fortunately Wikipedia allows us
to continue not thinking and expand the list significantly: http://en.wikipedia.org/wiki/JVM_Languages
I don't think even that list is exhaustive by a long chalk though.
(Personally I'd say there are plenty of other things that C# has over
the Java language and that .NET has over the JVM/JRE; Java's
portability is its main benefit over .NET in my experience.)
--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon_skeet
C# in Depth: http://csharpindepth.com
Daniel James wrote:
I'm also disappointed that modules won't be in C++0x, but I hope we won't
have to wait too much longer for them.
If I might interrupt for a moment, I think that the *only* true
advantage of using C# rather than C++ is that C# has a big standardized
framework so that programmers have a common high-level layer, so that
they don't have to directly deal with the OS.
C++ should be moving onto something similar, IMHO. As the C++0x is doing
with threads, regex, etc.
I know it's something really difficult, but that's a wish of mine.
Regards.
Arne Vajhøj <ar**@vajhoej.dkwrote:
Daniel James wrote:
[...]
>10 first class programmers will do more useful work in less time than
50 mediocre programmers ... and you will get fewer bugs.
In a world with concerns such as money you can't afford the mediocre.
If you look out in the real world, then you will see that
is not the general opinion.
I see this when using just about every application.
And I hate it.
Arne
Schobi
-- Sp******@gmx.de is never read
I'm HSchober at gmx dot de
"I guess at some point idealism meets human nature and
explodes." Daniel Orner
Jon Skeet [C# MVP] wrote:
Daniel James <wa*********@nospam.aaisp.orgwrote:
>It's one of .NET's
significant advantages over Java (intermediate code engine targeted by more
than one source language) but that's about it.
<snip>
Um, there are *plenty* of languages targeting the JVM. Off the top of
my head:
The point is that JVM has been officially been restricted to a single
language and wasn't meant to be open for other languages - don't know
it's current state in this regard.
And it's not only the runtime that makes the difference. Can you write
code in Java and use it easily from any other language targeting the JVM ?
[...]
Andre
On Jun 26, 6:07*am, Andre Kaufmann <andre.kaufmann_re_mo...@t-
online.dewrote:
Um, there are *plenty* of languages targeting the JVM. Off the top of
my head:
The point is that JVM has been officially been restricted to a single
language and wasn't meant to be open for other languages - don't know
it's current state in this regard.
I don't think it's ever been "restricted" - I don't remember Sun ever
telling people off for developing any of these languages, for
instance. Sun now employs the JRuby folk IIRC, and gave their blessing
to Groovy too.
Heck, there's even an API (in Java 6 IIRC, but it *might* only be in
Java 7) specifically for scripting, to make binding etc consistent
between different scripting languages targeting the JVM.
And it's not only the runtime that makes the difference. Can you write
code in Java and use it easily from any other language targeting the JVM *?
Absolutely - and the reverse, in many cases. For instance, you can
easily call Groovy code from Java, should you wish to.
I can't imagine anyone designing a language to run on the JVM which
*wouldn't* take advantage of both the standard APIs and the wealth of
3rd party libraries available - and that will include any extra Java
code you write yourself.
Jon
In article news:<MP*********************@msnews.microsoft.com >, Jon
Skeet [C# MVP] wrote:
It's one of .NET's significant advantages over Java (intermediate
code engine targeted by more than one source language) but that's
about it.
<snip>
Um, there are *plenty* of languages targeting the JVM. Off the top of
my head:
Did you notice that the very next paragraph of the bit you snipped said:
... and there are compilers for languages other than Java that
target the JVM, though I understand that the design of the JVM
specifically makes it hard to taget it with C or C++.
So, yes, of course, I agree with you. The point I was making in the bit
you didn't snip is that Java is a single-language environment BY DESIGN.
The Java zealots at Sun would have you believe that you don't need any
language other than Java and that Java is all the languages that you
will ever need ... at least, that was their mantra last time I passed by
the temple.
All the same, most of the languages you list -- and those in the
Wikipedia article you cited -- are experimental "academic" languages,
which aren't likely to be anyone's first choice for commercial
application. Groovy is obviously different, as it's designed to work
alongside Java -- I've not used Groovy but I understand that the synergy
there is good. The same is true to some extent of Jython, in that I
don't think anyone would choose Jython (over Python) unless their
project also used Java.
AspectJ is interesting, but AIUI that's an extension of Java rather than
a different language.
OTOH A remember being very impressed with the AppletMagic Ada for JVM
when I first looked at it -- too long ago now -- but I'm not sure it's
still around. Ada is a real language (one that really deserves to be
better known outside the war-toys factories) and it's interesting that
you can run it well on the JVM.
(Personally I'd say there are plenty of other things that C# has over
the Java language and that .NET has over the JVM/JRE; Java's
portability is its main benefit over .NET in my experience.)
I agree. The .NET team had the benefit of seeing the JVM in action and
of learning from its shortcomings. Their runtime is better in many ways
... but Java has the market penetration and I doubt very much that .NET
will ever displace it completely, even on Windows.
Cheers,
Daniel.
In article news:<#D**************@TK2MSFTNGP06.phx.gbl>, Andre Kaufmann
wrote:
Singularity has a small amount of assembly code and it's using a
native C# compiler. Cosmos however is meant to be 100% C# code.
Interesting. I've read about Singularity but not about Cosmos (in fact,
I thought Cosmos must be another name for Singularity when you mentioned
the two together in your last post).
The question, then, is how? Presumably Cosmos must touch the metal
somehow ... or is it designed as a guest OS to be run within another,
native, OS?
The point is C++ is not (always) that fast, only if you are an
experienced (expert) C++ developer the resulting C++ application
will be much faster.
You can write bad code in any language, and C++ certainly requires a bit
of care.
Short example (I never thought C++ to be slower in writing to files):
The code is attached below and does nothing but simply writing 5000000
integers to a text file.
What are COMPILER X and COMPILER Y?
Hmm ... there has to be a reason that C# comes out looking so good ...
Do all the programs produce identical output? What, exactly, did you
time (e.g. do you close the files/streams in the timed section of the
code in each case)?
The fprintf and sprintf functions will always be slow as they have to
parse the formatting string each time as well as producing output, so I
wouldn't expect them to do well. I'd expect the iostreams version to be
a good bit quicker and the itoa version to be the fastest. If I had to
guess I'd say that the C# version would be comparable to iostreams.
You could try another benchmark with boost::format -- I bet that would
be slower than any of them.
Another point is C++ could compile (nearly) as fast as any other
language. But therefore C++ must either get rid of (global) macros, or
introduce modules.
Modules are coming, eventually.
It's not global macros that are the problem, it's the fact that there's
no mechanism for the compiler to know that any macros referenced (in
include files, especially) have the same values in all compilation
units/for all builds. If the build system were smarter it could track
that and avoid recompiling header information that had already been
compiled with the same settings.
Macros can be a pain, but they can also be very useful ... I always
advise people to avoid using them if there is an alternative (e.g. use
const int (or even an enum) rather than a #define) but sometimes there
is no alternative and their use is beneficial.
If you look at functional languages targeting .NET e.g. F# and see
what is possible in these language then delegates just look like a
simple toy
That's because they're functional languages, not because they target
NET -- take a look at Haskell or Erlang and see what they can do.
But why have they to be implemented in a library ? C++ could have
integrated delegates from the beginning and add some extensional stuff
into a library ...
They don't have to be implemented in a library, but as they're not in
the core language there's no other way to add them. You could submit a
proposal to the ISO C++ committee asking for delegates as a native
language feature, but I suspect they'd say -- after a couple of years
waiting -- that as delegate functionality can be added as a library,
without changing the core language, there's no point. C++ is already
quite a big language, and making it bigger still just to add a feature
that can be implemented in a library doesn't make good sense.
I don't want to state that boost::function is bad, it's well
written and an perfect extension, I only think a direct implementation
could perform better.
I wouldn't like to judge without seeing direct implementation and
benchmarking it ... but boost::function is pretty efficient, from what
I've seen.
the .NET runtime support system, and if they weren't there would
be no way to add them to C#.
I don't know for sure, since you can easily write a .NET compiler by
yourself using the .NET runtime compiler support. Also I've seen many
IL (the .NET assembly code) based extensions, which extend the
language or .NET framework. So I think it would be possible, ...
I think you're missing the point I was making. I wasn't saying that
there was no way you could add delegate support *to* C# if it didn't
have it, I was saying that there was no way you could add delegate
support *in* C# alone. I'm not even 100% sure that that's true, but I am
certain that the result would be a lot less neat than boost::function if
you did! The point I was making was that the C++ language was more
powerful than the C# language, not that you couldn't do stuff with IL
extensions ... you can extend C++ by writing in assembler if you want
to, but that doesn't say anything about the power of C++ as a language.
... but the big advantage is that, as the framework has implemented
delegates, you can use it in every language and pass the pointers
over dll boundaries without any hassle.
I'm sure that's true -- and it *is* an advantage of the environment, no
question ... but (again) it says nothing about the power of expression
of the C# language -- it says nothing about the ease with which *you*
can express complex concepts in *your* C# code.
The main problem about macros is that the C++ compiler has to use
them too. So if it compiles a unit with header file a, it can't use
the already preprocessed and compiled intermediate code of header in
another unit, because a simple macro could convert the whole code in
the preprocessing stage.
Yes, I understand that problem, and you're right. I do think smarter
tools could alleviate that problem to a considerable extent, though.
You can do a lot to improve compile times in Visual C++ with judicious
use of precompiled headers -- but it's tricky to get right if you need
to use more than one PCH file in a project ... and the tendency is to
use the brute force approach of putting everything into a single
monolithic PCH file and so introducing all sorts of unnecessary
dependencies. Again, it's something that better tools could do a lot to
improve.
Modules are probably the best answer, though.
[...]
Delegates and labmda have been added TO C++ IN C++ (in Boost) ...
which is something you couldn't do in C#.
Perhaps. But if you look at the library, how many code there's inside
to deal with the differences of different C++ compilers I think it
wasn't an easy task ;-).
That's true ... but if more compilers complies more closely with the
standard it wouldn't be such a problem.
Implicit typed variables are coming to C++ (auto) ... but the need
for them is mostly driven by templates -- what good are they in C#?
The same reason - >generics< and LINQ has also driven them.
OK, interesting. I should have thought about generics ... and I know
very little about how LINQ works (reinventing ODBC within the language
...???) An answer to xdoclet in Java.
There could be a Windows standard for all
Windows compilers to have the advantages for natives languages too.
Try to export a template code in C++ in a Windows DLL and use it from
another language - in .NET it's simply no problem.
I take the point that the CLI gives you a standard object representation
for all .NET languages, and lets you define an object in C# and
manipulate it in C++/CLI or VB.NET or whatever ... but you can't create
a template in a C++/CLI program and use it (instantiate it) in a C# or
VB.NET program -- because those languages have no conception of
templates.
The implementation of templates in C++/CLI is not provided by the CLI,
but by the C++ compiler. Templates are therefore not visible to other
NET languages.
That's no different from the situation with native code.
But the only standard there's in Windows, is how to export flat
functions. I wished at least the name mangling would be somewhat
standardized.
Yes, a standard ABI for C++ would be nice. I believe it's one of the
things the standards group is looking at, but don't expect to see it in
the standard in 2009.
[...]
D is interesting too ... can that not be used together with DM
C++? I must say I haven't tried ...
It somewhat supports using C++ (indirectly), but as the developer
said, if it would fully support C++ - it would be a full fledged
C++ compiler, which would be not that simple to >implement< ;-).
... but can you not compile D code with the D compiler and C++ code with
the DM C++ compiler and link the two together?
Incidentally, Andrei Alexandrescu presented a paper ...
[snip]
Hm, interesting thanks for mentioning it.
The slides are here: http://accu.org/content/conf2008/Ale...functional.pdf
I don't know how much sense they'll make to someone who wasn't at the
talk!
Cheers,
Daniel.
Daniel James <wa*********@nospam.aaisp.orgwrote:
Um, there are *plenty* of languages targeting the JVM. Off the top of
my head:
Did you notice that the very next paragraph of the bit you snipped said:
... and there are compilers for languages other than Java that
target the JVM, though I understand that the design of the JVM
specifically makes it hard to taget it with C or C++.
I didn't, actually. Sorry about that - it does sort of make a nonsense
of the sentence that I *did* quote though.
And yes, I agree that it would be pretty hard to target the JVM with C
or C++.
So, yes, of course, I agree with you. The point I was making in the bit
you didn't snip is that Java is a single-language environment BY DESIGN.
The Java zealots at Sun would have you believe that you don't need any
language other than Java and that Java is all the languages that you
will ever need ... at least, that was their mantra last time I passed by
the temple.
I wouldn't put it as strongly as that. I think there's a big difference
between a platform being deliberately designed to only have one
language targeting it, and a platform being designed explicitly for a
single language with little thought to trying to make life easier for
other languages.
I would put Java into the latter camp rather than the former. Even if
some Java fans think there's no point in having other languages
targeting it, I'm not aware of any ways they've made it *deliberately*
more difficult for other languages in a DRM-like way.
All the same, most of the languages you list -- and those in the
Wikipedia article you cited -- are experimental "academic" languages,
which aren't likely to be anyone's first choice for commercial
application. Groovy is obviously different, as it's designed to work
alongside Java -- I've not used Groovy but I understand that the synergy
there is good. The same is true to some extent of Jython, in that I
don't think anyone would choose Jython (over Python) unless their
project also used Java.
But that's the point - if their project *does* use Python or Ruby
already, or if they've already got a lot of code in Java that they want
to use later with Python or Ruby - then Jython and JRuby are a natural
fit.
If we're talking about languages which are common "first choices" for
commercial applications, even .NET's relatively thin on the ground,
with VB.NET and C# taking the lion's share and C++/CLI and F# pulling
up the rear - at an educated guess. Languages like Boo aren't exactly
commonplace.
AspectJ is interesting, but AIUI that's an extension of Java rather than
a different language.
OTOH A remember being very impressed with the AppletMagic Ada for JVM
when I first looked at it -- too long ago now -- but I'm not sure it's
still around. Ada is a real language (one that really deserves to be
better known outside the war-toys factories) and it's interesting that
you can run it well on the JVM.
Right. I'm interested in Scala, as there used to be implementations for
both .NET and the JVM - and because it looks like a nice language. I
haven't had a close look though, and I believe the .NET port is out of
date.
(Personally I'd say there are plenty of other things that C# has over
the Java language and that .NET has over the JVM/JRE; Java's
portability is its main benefit over .NET in my experience.)
I agree. The .NET team had the benefit of seeing the JVM in action and
of learning from its shortcomings. Their runtime is better in many ways
.. but Java has the market penetration and I doubt very much that .NET
will ever displace it completely, even on Windows.
Absolutely - I expect both to go on for quite some time, which is fine
by me. (I'm currently working just in Java professionally, and I have
no wish to leave my current employer - but I do hope I write some C#
professionally again at some point.)
I haven't replied to your other posts about LINQ, by the way, but I
think you'd be wise to look into it further - it sounds like you may
have the wrong end of the stick to some extent. It's certainly not like
embedding SQL into C# - there's a lot more to it than that. Personally
I think that LINQ to Objects (the "in process" handling of collections)
is of more use to most people than LINQ to SQL etc, though obviously
the latter has more of an "ooh" and "aah" quality to it.
--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon_skeet
C# in Depth: http://csharpindepth.com
Jon Skeet [C# MVP] wrote:
On Jun 26, 6:07 am, Andre Kaufmann <andre.kaufmann_re_mo...@t-
online.dewrote:
[...]
I don't think it's ever been "restricted" - I don't remember Sun ever
telling people off for developing any of these languages, for
instance. Sun now employs the JRuby folk IIRC, and gave their blessing
to Groovy too.
I only read about it some years ago. Perhaps restricted was the wrong
word. But in the past other languages haven't been officially let's say
supported by Sun.
This might have changed today however, since Java is Open Source now.
Heck, there's even an API (in Java 6 IIRC, but it *might* only be in
Java 7) specifically for scripting, to make binding etc consistent
between different scripting languages targeting the JVM.
>And it's not only the runtime that makes the difference. Can you write
code in Java and use it easily from any other language targeting the JVM ?
Absolutely - and the reverse, in many cases. For instance, you can
easily call Groovy code from Java, should you wish to.
I don't know the interfaces today. The good old JNI interface was a pain
to deal with.
Is it really that simple in Java too:
- Write a class in any language and compile
- Compile the code to a Dll
- Use the code from any other language targeting the JVM too ?
I read only about using Java classes and vice versa from other
languages, but not how different languages would interact.
I can't imagine anyone designing a language to run on the JVM which
*wouldn't* take advantage of both the standard APIs and the wealth of
3rd party libraries available - and that will include any extra Java
code you write yourself.
Jon
Andre
Andre Kaufmann <an*********************@t-online.dewrote:
Absolutely - and the reverse, in many cases. For instance, you can
easily call Groovy code from Java, should you wish to.
I don't know the interfaces today. The good old JNI interface was a pain
to deal with.
Is it really that simple in Java too:
- Write a class in any language and compile
- Compile the code to a Dll
- Use the code from any other language targeting the JVM too ?
Well you wouldn't compile to a DLL. You'd compile to class files, and
then potentially jar them up. At that point, there's no difference
between a Java-created class and a class created by a different
language, other than what it chooses to do. (A Groovy class would be
full of calls to the Groovy libraries to do dynamic calls etc.)
Of course, it depends on whether your chosen language *has* a compiler
- some may not. If it doesn't, you'll probably need to use BSF or Java
6's scripting support. It looks like that's the way to go for JRuby,
for example. Jython has jythonc, but that's basically deprecated. See http://wiki.python.org/jython/Jython...eptember2006/1
for how to run Jython code from Java without jythonc.
It looks like Groovy is one of the best integrated languages in this
respect.
I read only about using Java classes and vice versa from other
languages, but not how different languages would interact.
If you ever get hold of Groovy in Action, we've got a whole chapter
about integrating Groovy - chapter 11.
--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon_skeet
C# in Depth: http://csharpindepth.com
Daniel James wrote:
In article news:<#D**************@TK2MSFTNGP06.phx.gbl>, Andre Kaufmann
wrote:
>Singularity has a small amount of assembly code and it's using a
native C# compiler. Cosmos however is meant to be 100% C# code.
Interesting. I've read about Singularity but not about Cosmos (in fact,
I thought Cosmos must be another name for Singularity when you mentioned
the two together in your last post).
The question, then, is how? Presumably Cosmos must touch the metal
somehow ... or is it designed as a guest OS to be run within another,
native, OS?
I don't know all the internals. AFAIK Cosmos includes a compiler, which
translates the IL code generated by C# to x86 code.
No basically it is C# translated directly to native code, with some
extensions to let C# interact directly with the CPU.
[...]
>Short example (I never thought C++ to be slower in writing to files):
The code is attached below and does nothing but simply writing 5000000
integers to a text file.
What are COMPILER X and COMPILER Y?
Windows C++ compilers, I don't think that the vendors are quite
interesting and I don't want to start compiler wars ;-).
Hmm ... there has to be a reason that C# comes out looking so good ...
Do all the programs produce identical output? What, exactly, did you
time (e.g. do you close the files/streams in the timed section of the
code in each case)?
Close doesn't matter and yes all produce the identical output.
The fprintf and sprintf functions will always be slow as they have to
parse the formatting string each time as well as producing output, so I
The printf functions are commonly faster, because they don't have that
much overhead. IIRC correctly IOStreams (e.g. the ones shipped with
VC9.0) are using sprintf internally for formatting.
wouldn't expect them to do well. I'd expect the iostreams version to be
a good bit quicker and the itoa version to be the fastest. If I had to
guess I'd say that the C# version would be comparable to iostreams.
IOStreams are quite slow. At least the ones I know. The reason is that
much overhead due to localization, memory allocation for buffering and
too much code to run through for a simple task.
You could try another benchmark with boost::format -- I bet that would
be slower than any of them.
I think it was quite fast.
>Another point is C++ could compile (nearly) as fast as any other
language. But therefore C++ must either get rid of (global) macros, or
introduce modules.
Modules are coming, eventually.
It's not global macros that are the problem, it's the fact that there's
I mean with global in brackets that macros can be redefined in each and
for each header file and that the propagate to other header files.
So global was perhaps misleading, setting a macro in the compiler
affecting the whole code compiled is not a problem.
no mechanism for the compiler to know that any macros referenced (in
include files, especially) have the same values in all compilation
Yes, that is the main problem.
units/for all builds. If the build system were smarter it could track
that and avoid recompiling header information that had already been
compiled with the same settings.
Therefore it must have an overview over the whole code must distinguish
different header files with the same name etc. I think modules will be a
better solution. IIRC the IBM C++ compiler had some kind of modules
implemented and was quite fast in compilation.
Macros can be a pain, but they can also be very useful ... I always
advise people to avoid using them if there is an alternative (e.g. use
const int (or even an enum) rather than a #define) but sometimes there
is no alternative and their use is beneficial.
I know and agree. I use them too. But they could have been restricted to
have an effect on one single header file or must be globally defined.
>If you look at functional languages targeting .NET e.g. F# and see
what is possible in these language then delegates just look like a
simple toy
That's because they're functional languages, not because they target
NET -- take a look at Haskell or Erlang and see what they can do.
Yes, it hasn't something to do with .NET. F# is similar to ML, ML is
comparable with Haskell.
It should only proof that delegates can be implemented in C# directly,
as I stated in my recent post.
>But why have they to be implemented in a library ? C++ could have
integrated delegates from the beginning and add some extensional stuff
into a library ...
[...]
quite a big language, and making it bigger still just to add a feature
that can be implemented in a library doesn't make good sense.
I know that it's a big no no to change the language. Heck it's even to
complex to add "override" to the language.
I agree that a library is much better regarding compatibility. But it
makes it quite hard for tools implementors (e.g. RAD tools / code
completion etc.) to deal with huge libraries.
I have only the feeling that delegates should be supported directly by
the compiler and that the libraries to implement them got somewhat bloated.
[...]
I wouldn't like to judge without seeing direct implementation and
benchmarking it ... but boost::function is pretty efficient, from what
I've seen.
They have improved, since there aren't that many heap allocations
involved anymore.
There is a comparison on: http://www.codeproject.com/KB/cpp/Cp...mentation.aspx
[...]
I think you're missing the point I was making. I wasn't saying that
there was no way you could add delegate support *to* C# if it didn't
have it, I was saying that there was no way you could add delegate
support *in* C# alone.
A - O.k. you mean the "template magic" allows C++ to implement delegates
as a library, while you can't in C#, because generics aren't that
flexible enough. Besides I think templates could be implemented in any
other language too, why should it proof the power of C++ ?
(doesn't mean that I don't like them).
I could argue C# to be more powerful because:
- I can compile code on the fly. E.g. I can compile regular expressions
and XSL stylesheets to perform faster as any C++ could to, because
it has to evaluate the regular expressions/stylesheets always.
I can even build and compile script code on the fly.
There are more examples - all languages have pros and cons.
But C++ isn't that effective always.
[...]
>... but the big advantage is that, as the framework has implemented
delegates, you can use it in every language and pass the pointers
over dll boundaries without any hassle.
I'm sure that's true -- and it *is* an advantage of the environment, no
question ... but (again) it says nothing about the power of expression
of the C# language -- it says nothing about the ease with which *you*
can express complex concepts in *your* C# code.
O.k. yes. I only missed templates in C# for generic code. However, what
I'm badly missing in C# is RAII.
But you aren't restricted to a single language. If you want to express
complex concepts use another language like F# or C++/CLI and reuse the
code in C#.
Don't get me wrong, I still like C++ and it's my main developing
language. But I sometimes miss the developing experience of other
languages and I think the standardization process is quite slow.
[...]
Modules are probably the best answer, though.
Yes, I think that too. Unfortunately they are delayed and not part of
the upcoming standard.
[...]
I take the point that the CLI gives you a standard object representation
for all .NET languages, and lets you define an object in C# and
manipulate it in C++/CLI or VB.NET or whatever ... but you can't create
a template in a C++/CLI program and use it (instantiate it) in a C# or
VB.NET program -- because those languages have no conception of
templates.
Well, the .NET framework has Generics. They aren't that powerful as
templates, but on the other side you have the possibility to export
generic lists to other languages.
The implementation of templates in C++/CLI is not provided by the CLI,
but by the C++ compiler. Templates are therefore not visible to other
NET languages.
Yes. Besides security concerns and loosing the strong typing of
Generics, why shouldn't templates been implemented in other languages too ?
[...]
The slides are here:
http://accu.org/content/conf2008/Ale...functional.pdf
Thanks, I'll have a look at it.
I don't know how much sense they'll make to someone who wasn't at the
talk!
Cheers,
Daniel.
Cheers,
Andre
Arne Vajhøj wrote:
[...]
>Boost is a good, cool library - sure. But these libraries get somewhat
bloated, because of all the template stuff and compilation slows down
more and more.
Compilation speed is usually not important.
Why ? For RAD tools it's IMHO essential and if 1000 developers wait
daily an hour for compilation they are loosing simply 1000 hours of
development time, besides the energy wasted.
I'm simply used to quickly recompile my code after a compilation error.
In C++ is meant to compile fast code. Why can't the compiler be not that
fast ? The sad story is - it could be.
[...]
Arne
Andre
Andre Kaufmann wrote:
Arne Vajhøj wrote:
>[...]
>>Boost is a good, cool library - sure. But these libraries get somewhat
bloated, because of all the template stuff and compilation slows down
more and more.
Compilation speed is usually not important.
Why ? For RAD tools it's IMHO essential and if 1000 developers wait
daily an hour for compilation they are loosing simply 1000 hours of
development time, besides the energy wasted.
You can always throw processing power at this problem
( www.xoreax.com). This worked great for a company I used
to work for and turned 60mins into 12mins.
OTOH, you cannot throw processing power at debugging. So
easily creating correct code is more important than fast
compilation.
[...]
Andre
Schobi
Daniel James wrote:
[...]
The fprintf and sprintf functions will always be slow as they have to
parse the formatting string each time as well as producing output, so I
wouldn't expect them to do well. I'd expect the iostreams version to be
a good bit quicker [...]
Usually iostreams are implemented using the 'printf()' family,
so it's very unlikely they're faster. It's sad, because with all
the type info known at compile-time streams ought to be faster
than 'printf()', but that potential was never used. Dietmar Kühl
once had an implementation that didn't do this and was regarded
fast, but for some reason it never took off.
[...]
Daniel.
Schobi
Hendrik Schober wrote:
You can always throw processing power at this problem
(www.xoreax.com). This worked great for a company I used
to work for and turned 60mins into 12mins.
Still a long time. <g>
--
Rudy Velthuis http://rvelthuis.de
"Ignorance simplifies ANY problem." -- R. Lucke
Rudy Velthuis <ne********@rvelthuis.dewrote:
Hendrik Schober wrote:
> You can always throw processing power at this problem
(www.xoreax.com). This worked great for a company I used
to work for and turned 60mins into 12mins.
Still a long time. <g>
Yes, but this was several MLoC. And usually you don't
have to compile /everything/ during writing/fixing
code.
Schobi
-- Sp******@gmx.de is never read
I'm HSchober at gmx dot de
"I guess at some point idealism meets human nature and
explodes." Daniel Orner
In article news:<MP*********************@msnews.microsoft.com >, Jon
Skeet wrote:
I didn't, actually. Sorry about that - it does sort of make a nonsense
of the sentence that I *did* quote though.
Not really. First bit says the JVM is only meant to be for Java, second
bit says that hasn't stopped people using it for other languages
(without Sun's blessing, at least in the earlier cases).
And yes, I agree that it would be pretty hard to target the JVM with C
or C++.
Yeah ... Sun would probably say that the JVM has no opcodes that can be
used to support pointer arithmetic (a) because Java doesn't need them,
and (b) because they're potentially unsafe; but I bet they regarded the
fact that that meant you couldn't target it from C or C++ as an added
bonus.
No, I don't suppose they went out of their way to make it impossible to
implement C or C++ to target the JVM /per se/, but I do think they saw
pointer manipulations as a bad thing and deliberately left them out of
the instruction set of the JVM so people couldn't use them -- after all:
Java doesn't need them, and who would be silly enough to use anything
else.
There's a big difference in mindset, though, between what Sun did with
Java (we've just reinvented p-code and it's just for our new language
called 'Java' -- so we've called it the "Java Virtual Machine") and what
Microsoft did with .NET (we've just reinvented p-code (again) -- and we
want it to be able to run any language you like, and we want third
parties to port their languages to it ... oh, and we've just developed a
new language called C# that will target this and nothing else, but don't
you worry about that).
Now, admittedly, MS needed to shout all they could about any advantages
offered by the CLI over the JVM, so that they could attract attention
away from the JVM -- which was becoming an established standard -- so
they had some interest in gathering as much 3rd-party support as
possible in any way they could ... but it looks like a very different
attitude to mixed-language programming to me!
Does anyone actually use Eiffel.NET, BTW? I haven't heads anything about
it since it was heralded as one of the first examples of a third-party
language targeting the CLI, way back when.
But that's the point - if their project *does* use Python or Ruby
already, or if they've already got a lot of code in Java that they
want to use later with Python or Ruby - then Jython and JRuby are
a natural fit.
Yes, I agree. Sorry, I think you missed my point -- I should probably
have said "but" or "whereas" or something in there -- Most of the
languages mentioned are just research toys, BUT (I went on to say)
Jython and Groovy (and JRuby, if you say so, I know less about that) do
have real-world uses.
I hadn't seen Scala before ... it looks very Java-like (perhaps
unsurprisingly) and I'm not sure quite what makes it different, on a
first glance. I'll obviously have to read further.
I haven't replied to your other posts about LINQ, by the way, but I
think you'd be wise to look into it further ...
I certainly don't know much about it ... usually it's been discussed as
a way to bind databases to C# code (and it all seemed very reminiscent
of the hype that ODBC got when it was new). I'll look further, thanks
for the "heads up".
Cheers,
Daniel.
In article news:<uI**************@TK2MSFTNGP02.phx.gbl>, Andre Kaufmann
wrote:
I don't know all the internals. AFAIK Cosmos includes a compiler,
which
translates the IL code generated by C# to x86 code.
No basically it is C# translated directly to native code, with some
extensions to let C# interact directly with the CPU.
OK, that's interesting. It's C# but not C#.NET.
What are COMPILER X and COMPILER Y?
Windows C++ compilers, I don't think that the vendors are quite
interesting ...
I had it half in mind to repeat your tests and try to see where the C++
versions were taking their time ... I obviously can't do that very
meaningfully if I can't know that I'm using the same tools.
I guess at least the C# compiler must have been a Microsoft one <smile>
Close doesn't matter and yes all produce the identical output.
Close *does* matter ... especially if the output is buffered up to that
point and only written to disk on the close call. It could be that all
the real work actually takes place outside the timing loop in some of
your tests.
The fprintf and sprintf functions will always be slow as they have
to parse the formatting string each time as well as producing
output, so I ...
The printf functions are commonly faster, because they don't have that
much overhead. IIRC correctly IOStreams (e.g. the ones shipped with
VC9.0) are using sprintf internally for formatting.
I haven't got a VC9 installation handy ... but in VC8 the iostream
implementation certainly doesn't use sprintf. That would be a very
suboptimal implementation when you already know the type of the value
that's to be formatted. The overhead of printf is quite considerable as
the "%d" (or whatever) has to be interpreted on every call.
There is certainly some overhead associated with streams, too, but it
should be less than that with the ?printf functions, except in a very
naive implementation.
You're right that localization imposes some overhead with streams -- but
not for printing integers.
You could try another benchmark with boost::format -- I bet that
would be slower than any of them.
I think it was quite fast.
boost::format does very similar processing to that done by sprintf. It
makes use of the actual type of its arguments rather than taking that
from the format string, but still had to parse the string for layout,
etc. It's usually very slow.
It also has surprising results in some cases -- if you use a char
variable as an 8-bit integer and try to print it using
boost::format( "%d" ) % charvar
boost::format takes the type (char) from the variable and ignores the
type implied by the %d, so you get a character rather than a number. The
only way to get the result you wanted is to cast the variable to an int
(yuk).
[on macros and compilation]
If the build system were smarter it could track that and avoid
recompiling header information that had already been compiled
with the same settings.
Therefore it must have an overview over the whole code must
distinguish different header files with the same name etc. I think
modules will be a better solution.
I agree entirely that modules will be a better solution ... but I don't
think that means that we shouldn't also try to improve tool support for
efficient compilation of today's sourcecode. There are millions and
millions of lines of C++ code in use today, and that body of code won't
magically be converted to use modules one rainy day in (say) 2015 when
compilers start to support them!
[on "Macros are useful too"]
I know and agree. I use them too. But they could have been restricted
to have an effect on one single header file or must be globally
defined.
That wouldn't be compatible with C. In particular it wouldn't be
compatible with the way that C (and C++) allows you to redefine the
NDEBUG macro and include assert.h repeatedly to turn ASSERT macros on
and off throughout a compilation unit. That's a very widespread usage in
some codebases, and restricting the use of macros would break it.
(This sort of code also makes it very hard to write the sort of 'smart'
compilation system that I was talking about ... but that doesn't mean
that it's not worth trying!)
A - O.k. you mean the "template magic" allows C++ to implement
delegates as a library, while you can't in C#, because generics
aren't that flexible enough.
That's kinda what I've been saying all along, yes.
Besides I think templates could be implemented in any
other language too, why should it proof the power of C++ ?
(doesn't mean that I don't like them).
They *could*, but they haven't been. If you were to add a
metaprogramming facility to C# it wouldn't be the C# that we know today.
OTOH if you were to design a metaprogramming facility to add to C# the
resulting language might be a bit nicer to use than C++ is now ... using
C++ templates for metaprogramming (rather than just for implementing
generics) is a bit of a hack -- but it's a very powerful hack, and the
fact that it has been used so much shows how much people want to do this
sort of thing.
I'm not suggesting that C++ is the best language imaginable, just that
it is the best language available today for solving most of the
programming problems with which I find myself faced.
... the .NET framework has Generics. They aren't that powerful as
templates, but on the other side you have the possibility to export
generic lists to other languages.
The implementation of templates in C++/CLI is not provided by the
CLI, but by the C++ compiler. Templates are therefore not visible
to other NET languages.
Yes. Besides security concerns and loosing the strong typing of
Generics, why shouldn't templates been implemented in other languages
too ?
It's not that template couldn't be implemented by other languages, just
that -- at present -- they aren't.
Even if they were I'm not sure that you would be able to achieve
inter-language compatibility with templates, as (in C++, at least) they
are source-code abstractions, and you need a C++ compiler to make use of
them.
Maybe if someone were to come up with a standard for some sort of
meta-code representation then different languages would be able to share
template representations that had been compiled (or part-compiled) down
to that meta-code. The "export" feature in C++ does something along
those lines, but AIUI the intermediate form is still largely C++.
The slides are here:
http://accu.org/content/conf2008/Ale...functional.pdf
Thanks, I'll have a look at it.
I said Andrei had been talking about a mixture of C++ and functional
programming, didn't I? Well, it's D not C++. Still interesting, though.
Cheers,
Daniel.
In article news:<ut**************@TK2MSFTNGP06.phx.gbl>, Hendrik
Schober wrote:
Usually iostreams are implemented using the 'printf()' family,
That's obviously an easy-but-naive implementation, I'd hope that as C++
continued to mature quick hacks like that would disappear.
Certainly the current Visual C++ (Dinkumware) runtime doesn't seem to
use sprintf.
Cheers,
Daniel.
On Jun 27, 11:56*am, Daniel James <wastebas...@nospam.aaisp.org>
wrote:
Skeet wrote:
I didn't, actually. Sorry about that - it does sort of make a nonsense
of the sentence that I *did* quote though.
Not really. First bit says the JVM is only meant to be for Java, second
bit says that hasn't stopped people using it for other languages
(without Sun's blessing, at least in the earlier cases).
I think we'll have to agree to disagree about the wording that started
this subthread then. To me, Java *is* an "intermediate code engine
targeted by more
than one source language". It just isn't an intermediate code engine
*designed* to be targeted by more than one source language.
And yes, I agree that it would be pretty hard to target the JVM with C
or C++.
Yeah ... Sun would probably say that the JVM has no opcodes that can be
used to support pointer arithmetic (a) because Java doesn't need them,
and (b) because they're potentially unsafe; but I bet they regarded the
fact that that meant you couldn't target it from C or C++ as an added
bonus.
Not sure. I strongly suspect that treating Sun as a single entity
doesn't really work here. Different employees of Sun are likely to
have different attitudes.
<snip>
There's a big difference in mindset, though, between what Sun did with
Java (we've just reinvented p-code and it's just for our new language
called 'Java' -- so we've called it the "Java Virtual Machine") and what
Microsoft did with .NET (we've just reinvented p-code (again) -- and we
want it to be able to run any language you like, and we want third
parties to port their languages to it ... oh, and we've just developed a
new language called C# that will target this and nothing else, but don't
you worry about that).
Agreed, although I don't think MS ever claimed that they want you to
be able to run "any language you like" - it needs to have a certain
degree of similarity to the underlying platform. (Some people have
criticised it for precisely this reason, in fact.)
<snip>
Does anyone actually use Eiffel.NET, BTW? I haven't heads anything about
it since it was heralded as one of the first examples of a third-party
language targeting the CLI, way back when.
I haven't heard of much use, but that's a good example of where the
platform gets in the way of the language. From what I remember,
multiple inheritance in Eiffel.NET is a bit of a kludge with various
limitations. In other words, .NET doesn't have the same set of
limitations as Java when it comes to porting languages to it, but
there certainly *are* limitations.
But that's the point - if their project *does* use Python or Ruby
already, or if they've already got a lot of code in Java that they
want to use later with Python or Ruby - then Jython and JRuby are
a natural fit.
Yes, I agree. Sorry, I think you missed my point -- I should probably
have said "but" or "whereas" or something in there -- Most of the
languages mentioned are just research toys, BUT (I went on to say)
Jython and Groovy (and JRuby, if you say so, I know less about that) do
have real-world uses.
Righto.
I hadn't seen Scala before ... it looks very Java-like (perhaps
unsurprisingly) and I'm not sure quite what makes it different, on a
first glance. I'll obviously have to read further.
From what I've seen it has some similarities to C# 3, but taken a bit
further. It supports a functional style of programming much more
neatly than Java does. It may also have some dynamic aspects, although
I can't remember offhand.
I haven't replied to your other posts about LINQ, by the way, but I
think you'd be wise to look into it further ...
I certainly don't know much about it ... usually it's been discussed as
a way to bind databases to C# code (and it all seemed very reminiscent
of the hype that ODBC got when it was new). I'll look further, thanks
for the "heads up".
Yup, it's unfortunate that the SQL side of things is what's gained the
most attention. I wouldn't like to try to describe it in just a few
sentences - I'm sure you'll have more joy investigating it properly :)
Jon
Daniel James wrote:
In article news:<ut**************@TK2MSFTNGP06.phx.gbl>, Hendrik
Schober wrote:
>Usually iostreams are implemented using the 'printf()' family,
That's obviously an easy-but-naive implementation, I'd hope that as C++
continued to mature quick hacks like that would disappear.
Certainly the current Visual C++ (Dinkumware) runtime doesn't seem to
use sprintf.
That would have been a pleasant surprise. But outputting
an 'int' using '<<' certainly lands you in 'sprintf()'. :(
Daniel.
Schobi
Daniel James wrote:
OTOH A remember being very impressed with the AppletMagic Ada for JVM
when I first looked at it -- too long ago now -- but I'm not sure it's
still around. Ada is a real language (one that really deserves to be
better known outside the war-toys factories) and it's interesting that
you can run it well on the JVM.
Also AdaCore has recently developed a version of the GNAT Ada compiler
that targets the CLR. I haven't played with it much (yet), however.
Peter This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: William C. White |
last post by:
Does anyone know of a way to use PHP /w Authorize.net AIM without using
cURL? Our website is hosted on a shared drive and the webhost company
doesn't installed additional software (such as cURL)...
|
by: Albert Ahtenberg |
last post by:
Hello,
I don't know if it is only me but I was sure that header("Location:url")
redirects the browser instantly to URL, or at least stops the execution of
the code. But appearantely it continues...
|
by: James |
last post by:
Hi,
I have a form with 2 fields.
'A'
'B'
The user completes one of the fields and the form is submitted.
On the results page I want to run a query, but this will change
subject to which...
|
by: Ollivier Robert |
last post by:
Hello,
I'm trying to link PHP with Oracle 9.2.0/OCI8 with gcc 3.2.3 on a Solaris9
system. The link succeeds but everytime I try to run php, I get a SEGV from
inside the libcnltsh.so library.
...
|
by: Richard Galli |
last post by:
I want viewers to compare state laws on a single subject.
Imagine a three-column table with a drop-down box on the top. A viewer
selects a state from the list, and that state's text fills the...
|
by: Albert Ahtenberg |
last post by:
Hello,
I have two questions.
1. When the user presses the back button and returns to a form he filled
the form is reseted. How do I leave there the values he inserted?
2. When the...
|
by: inderjit S Gabrie |
last post by:
Hi all
Here is the scenerio ...is it possibly to do this...
i am getting valid course dates output on to a web which i have designed
....all is okay so far , look at the following web url
...
|
by: Jack |
last post by:
Hi All,
What is the PHP equivilent of Oracle bind variables in a SQL statement, e.g.
select x from y where z=:parameter
Which in asp/jsp would be followed by some statements to bind a value...
|
by: Sandwick |
last post by:
I am trying to change the size of a drawing so they are all 3x3.
the script below is what i was trying to use to cut it in half ... I
get errors.
I can display the normal picture but not the...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
