469,270 Members | 1,164 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,270 developers. It's quick & easy.

C# vs. C++

cj
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 3655
Hendrik Schober wrote:
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
Thanks for the link.
>> 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.
Yes, agreed. But in a large team it's still a pain to start the build
process over and over again, because in your local project it compiled
fine but in another project some weird side effect causes a compilation
error.

Even if I use processing power, C++ still compiles way more slower than
most of the other languages do. Currently our build time is 30 minutes,
which has been 3 hours before we switched to a quad core system.

I could live with the compilation time, if the slow down would be caused
by the complex syntax of C++ only and if that would be outweighed by the
productivity increase by all the goodies of C++ (templates, RAII etc.).
But since the slow down isn't caused by the complexity, but because the
compiler has to compile code over and over again, I think it's a huge
loss of productivity for - nothing - .

I hope modules will fix the problem, at least they should if I
understood them correctly. But they have been delayed again and I think
it will need 5+ years till they will be part of the standard.

There should be IMHO something like boost is for the C++ standards
library, a fast track standard for the C++ language, which takes the
risk of changes and if the features are stable, the could be taken over
by the "stable" C++ standard. I know that GCC has taken over somewhat
this part, to see the stability of new features. But unfortunately this
doesn't help me that much, since other compilers don't support this
experimental features.
Schobi
Andre


Jun 28 '08 #101
Daniel James wrote:
In article news:<uI**************@TK2MSFTNGP02.phx.gbl>, Andre Kaufmann
wrote:
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.
You are using one of the same C++ compiler ;-). You can do a simple test
of your own, write integers to a file with iostreams and with sprintf
with the latest Microsoft VC/C# compiler. Sprintf should be faster, C#
fastest.
I guess at least the C# compiler must have been a Microsoft one <smile>
Yes, there are other alternatives, but their heap management is IMHO slower.
[...]
I haven't got a VC9 installation handy ... but in VC8 the iostream
implementation certainly doesn't use sprintf. That would be a very
I'm sorry to say, but it does.
Have a look at the file "...VS2005\VC\crt\src\xlocnum".
Search for "ld".
Set a break point on this function and then use a fstream object and
write an integer to it to see by yourself.

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.
Yes. I think it is done for consistency reasons, to use the same
formatting.
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.
The problem is only, C# (.NET) deals with localization too and the
strings are Unicode - meaning it's using 16 Bit characters.
So I'm somewhat disappointed from C++ performance (in this regard), why
do I need localization for a simple integer ?
..NET isn't (generally) faster in large projects, because the memory
footprint is still somewhat higher - IMHO.
[...]
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).
Didn't know that boost::format supports the printf formatting syntax
too. I used only the placeholder style: %1% %2%
[...]
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
[...]
Yes agreed. But on the other side I once asked in the C++ forum why C++
still doesn't support >override<, while all other languages do.
I had a huge problem, with template virtual base classes and somewhere
in the object hierarchy the base function hasn't been overridden and the
compiler logically didn't complain about it. Fortunately I had VC which
has a proprietary extension supporting override for native code too to
ensure that the compiled code does what I expected it to do.

I was only told in the forum that this is a minor problem and therefore
there is no need for override to get into the next standard.
I don't use this coding style anymore, but anyways if I have to use a
class library which uses this style I can't control it's functionality
at compile time.
[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.
Yes, but in this case and for this files I explicitly could activate the
old behavior. Or the other way round - doesn't matter.

On the other side a global definition of the assert macro and local
redefines would to the trick too.
>(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.
They are powerful for sure, but if they are used too much the code gets
unreadable and hard to debug and maintain. By the way 'D' has IMHO a
good, way more readable implementation of meta templates directly in the
language.

E.g:

template Function(long n)
{
static if (n < 0) .....
else ......
}

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.
I would perhaps migrate to 'D' if I could use my C++ more easily.
[...]
It's not that template couldn't be implemented by other languages, just
that -- at present -- they aren't.
As I wrote above, IMHO the implementation in 'D' is superior.
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.
To problem is templates aren't strong typed, in contrast to generics. If
they would be used for multiple languages e.g. in .NET and if the code
would be compiled at startup of the application, as it's done (normally)
in .NET, the code could fail to compile.
But it certainly could be done - just remove the compilation checking
from generics and you potentially would have it ;-).
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++.
Unfortunately "export" doesn't do what it's meant to be. It doesn't
separate translation units. But yes, I agree that templates could be
supported over language boundaries too.
>>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.
Hm, the headline is about the 'D' language in it's current
implementation version 2.0.
Cheers,
Daniel.
Cheers,
Andre
Jun 28 '08 #102
In article news:<uA**************@TK2MSFTNGP02.phx.gbl>, Andre Kaufmann
wrote:
I'm sorry to say, but it does.
Have a look at the file "...VS2005\VC\crt\src\xlocnum".
Search for "ld".
Set a break point on this function and then use a fstream object and
write an integer to it to see by yourself.
Took my a while to get there (I was searching for "ld" without the
quotes, which didn't help) but I see you're right.

I didn't dig deep enough before -- I got as far as the call to
_Nput_fac.put in ostream and naively assumed that that would be
implemented ... how shall I put this ... sensibly.

That explains a lot about some of those timings!
I think it is done for consistency reasons, to use the same
formatting.
Silly, really ... at the very least that call to ::sprintf_s could be
replaced by a direct call to whatever sprintf_s uses to format numbers
... no need to set up a format string and then have to run code to
interpret it!
why do I need localization for a simple integer ?
Good question ... I'm not sure whether localization covers things like
using different chars (Arabic?) for digits ...?
..NET isn't (generally) faster in large projects, because the memory
footprint is still somewhat higher - IMHO.
Yes. I've not enough .NET experience to say for certain ... but
certainly in Java projects I've noticed that the VM grabs more and more
memory as the application(s) run and the whole system gets slower and
slower -- this is apparently because garbage collection is so expensive
that the system delays it as long as possible (hoping that the app may
terminate before collection is actually needed). Memory management needs
very careful attention on server systems that have to have long uptimes
-- more so than C++ systems where memory issues are better understood
and RAII makes most aspects of its management very easy.
Didn't know that boost::format supports the printf formatting syntax
too. I used only the placeholder style: %1% %2%
It uses (something approximating) the Open Group printf syntax -- which
includes the placeholder formats.
To problem is templates aren't strong typed, in contrast to generics.
That both is and isn't true. The whole point of templates is that they
can be instantiated with arbitrary arguments (so long as that
instantiation is meaningful) but I agree that that does erode
type-safety. The answer may lie in concepts.

[on templates in other languages]
But it certainly could be done - just remove the compilation checking
from generics and you potentially would have it ;-).
I note the smiley ... there is of course much more to it than that!
Unfortunately "export" doesn't do what it's meant to be. It doesn't
separate translation units.
I don't think that's been shown conclusively. When Daveed Vandevoorde
implemented export in the EDG compiler he changed his opinion on the
usefulness of the feature ... unfortunately most people (I might say,
cynically, most of those who don't want to spend time and money
implementing the feature) still adhere to the notion that export would
not offer much advantage.

I think modules will offer more advantage, but it's not clear that
export really is as bad as most pundits seem to be saying.
But yes, I agree that templates could be supported over language
boundaries too.
That's not quite what I said ... though I do think that if two languages
had template mechanisms with identical semantics then it would be
possible to design a template intermediate format that both could be
used by compilers for both languages and which would allow
cross-labguage template support.

Notice that all-important "with identical semantics", though. In
practice I suspect it ain't gonna happen!

Cheers,
Daniel.


Jun 28 '08 #103
In article news:<ue**************@TK2MSFTNGP05.phx.gbl>, Hendrik Schober
wrote:
Daniel James wrote:
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()'. :(
Yeah, sorry, I boobed. Andre Kauffman has pointed out elsethread that I
didn't dig deep enough into the Dinkumware code to get to the
::sprintf_s call.

That's rather disappointing ... num_put::do_put knows that what it's
printing is an int, so it passes a format string to sprintf_s and gets
it to decode that to determine something its caller already knew. Why
can't do_put directly call whatever sprintf_s calls to process ints?

Maybe the efficiency gain from doing that would be trivial, but from
where I sit it looks like the code just makes work for itself.

Cheers,
Daniel.
Jun 28 '08 #104
Daniel James wrote:
In article news:<uA**************@TK2MSFTNGP02.phx.gbl>, Andre Kaufmann
wrote:

Took my a while to get there (I was searching for "ld" without the
quotes, which didn't help) but I see you're right.
Sorry, my fault - single quotes have been misleading.
[...]
>why do I need localization for a simple integer ?

Good question ... I'm not sure whether localization covers things like
using different chars (Arabic?) for digits ...?
I don't know for sure - I only know that Romans have written them
differently. I assume that all other languages use the same digits - if
I'm not totally wrong.
>
I don't think that's been shown conclusively. When Daveed Vandevoorde
implemented export in the EDG compiler he changed his opinion on the
usefulness of the feature ... unfortunately most people (I might say,
cynically, most of those who don't want to spend time and money
implementing the feature) still adhere to the notion that export would
not offer much advantage.
I too don't think export isn't worth the time (2 man years of coding).
It would be better to put the time into modules instead.
I think modules will offer more advantage, but it's not clear that
export really is as bad as most pundits seem to be saying.
Perhaps not bad, but it doesn't offer more than modules - so IMHO there
is no need to implement both - (assuming that the code base of STL and
boost must be changed either - for export support or for modules).
Cheers,
Daniel.
Cheers,
Andre
Jun 28 '08 #105
Anyone that thinks an operating system would be written in C# is seriously
in cloud cuckoo land.

Most operating systems I guess still have a lot of C code. But suspect some
parts being re-written in C++.

There are a ton of reasons why C++ is more flexible and powerful than C#.
Same reasons that C++ is more flexible and powerful than Java.

If you wanted to write a general purpose program with a small footprint,
with good performance then C++ is a great choice.


"RFOG" <no@mail.comwrote in message
news:83**********************************@microsof t.com...
"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.

Jun 28 '08 #106
In article news:<#G**************@TK2MSFTNGP06.phx.gbl>, Andre
Kaufmann wrote:
Sorry, my fault - single quotes have been misleading.
No worries. I got there in the end <smile>

I once confused someone by using [ and ] to represent the limits of
the search box (e.g. search for ["ld"]) ... you can't win!
I'm not sure whether localization covers things like
using different chars (Arabic?) for digits ...?

I don't know for sure - I only know that Romans have written them
differently. I assume that all other languages use the same digits
- if I'm not totally wrong.
I don't think you quite understand ...

The Romans used an entirely different system for writing numeric
quantities anyway. In Arabic, numbers are written in base 10 using 10
different digit symbols, but they use different symbols from ours
(and, just to be confusing, their symbol for '5', looks a bit like our
'0').

See Unicode code points U+0660 to U+0669.

But, yes, I can imagine locales (or a locales-like system) supporting
conversion to and from Roman numeral representations too (though as
the Romans had no representation for zero it might be tricky). I can
never remember just what locales do and don't support, beyond the
everyday stuff.
I too don't think export isn't worth the time (2 man years of
coding).
Does that double-negative mean you DO think it IS worth the time? I'm
guessing not, but I can't be sure.

That 2 man years figure that gets bandied about comes, I think, from
Daveed's account of the time it took him. He's a seriously smart guy
so it might take other implementors a little longer ... BUT that time,
AIUI, includes the time taken to implement two-phase lookup which he
found was needed to support export. I think two-phase lookup is going
to have to be done anyway ... so the 2-man-year figure is misleading.
It would be better to put the time into modules instead.
It would be better to do BOTH. Modules don't solve all the same
problems as export ... and export is in the standard TODAY -- all it
needs is acceptance and implementation -- we could have it next year
if there was a will. Modules won't be in any sort of standard before
2012 at the earliest.

Cheers,
Daniel.
Jun 29 '08 #107
Daniel James wrote:
In article news:<#G**************@TK2MSFTNGP06.phx.gbl>, Andre
Kaufmann wrote:
>I too don't think export isn't worth the time (2 man years of
coding).

Does that double-negative mean you DO think it IS worth the time?
I'm guessing not, but I can't be sure.

That 2 man years figure that gets bandied about comes, I think, from
Daveed's account of the time it took him. He's a seriously smart guy
so it might take other implementors a little longer ... BUT that
time, AIUI, includes the time taken to implement two-phase lookup
which he found was needed to support export. I think two-phase
lookup is going to have to be done anyway ... so the 2-man-year
figure is misleading.
I could imagine that a company with 78000 employees could actually
afford a 2 man year project, if they really wanted to. .-)

Saying that implementing this language feature is too expensive, while
simultaneously designing several other entierly new languages, doesn't
really maximize your credibility.
Bo Persson
Jun 29 '08 #108
Daniel James wrote:
[...]
I don't think you quite understand ...

The Romans used an entirely different system for writing numeric
quantities anyway. In Arabic, numbers are written in base 10 using 10
different digit symbols, but they use different symbols from ours
(and, just to be confusing, their symbol for '5', looks a bit like our
'0').
Hm, we have to translate our applications in Arabic too, but I didn't
recognize different numbers, however I don't view our applications in
Arabic that often, since I'm not involved that much in GUI applications.
I think you mean the East-Arabic numbers.

But anyways since they are base 10 too isn't it just done with either
using a different font or changing an offset for the base number,
depending on the locale settings.
I mean - it shouldn't have an negative impact effect on the performance,
since the algorithm is basically the same.
See Unicode code points U+0660 to U+0669.

[...]
>I too don't think export isn't worth the time (2 man years of
coding).

Does that double-negative mean you DO think it IS worth the time? I'm
guessing not, but I can't be sure.
Upps - sorry typo. Should read "I do not think it is...."
That 2 man years figure that gets bandied about comes, I think, from
Daveed's account of the time it took him. He's a seriously smart guy
so it might take other implementors a little longer ... BUT that time,
AIUI, includes the time taken to implement two-phase lookup which he
found was needed to support export. I think two-phase lookup is going
to have to be done anyway ... so the 2-man-year figure is misleading.
>It would be better to put the time into modules instead.

It would be better to do BOTH. Modules don't solve all the same
problems as export ... and export is in the standard TODAY -- all it
I wonder what export solves, that modules don't ?
needs is acceptance and implementation -- we could have it next year
if there was a will. Modules won't be in any sort of standard before
2012 at the earliest.
[...]
Sadly I have to agree.

Andre
Jun 29 '08 #109
Bo Persson wrote:
Daniel James wrote:
>In article news:<#G**************@TK2MSFTNGP06.phx.gbl>, Andre
Kaufmann wrote:

[...]
Saying that implementing this language feature is too expensive, while
simultaneously designing several other entierly new languages, doesn't
really maximize your credibility.
Then why do only the EDG based commercial compilers support export ?
Because all want to loose their credibility ?
Bo Persson
Andre

Jun 29 '08 #110
RFOG wrote:
"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(*).
You will need something native to do that.

But that is a microscopic part of an OS like Windows Vista.

Arne
Jun 29 '08 #111
Fernando G├│mez wrote:
Arne Vajh├Şj wrote:
>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 !

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...
There is still a lot of MFC apps out there. MS has a lot themselves.

But new apps will be done in Win Forms or WPF.

And eventually that will change the desktop landscape.

Arne
Jun 29 '08 #112
Andre Kaufmann wrote:
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.
What do you mean by "has been officially been restricted" ?

The JVM specs are public so anyone can target it. SUN has released
some other languages for the JVM themselves.
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 ?
Yes. No problem.

Arne
Jun 29 '08 #113
Daniel James wrote:
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.
That is one of the worst pieces of logic I have seen in a long time.

You can not conclude that:

the JVM is not suite dfor C/C++ =the JVM is only designed for one language

There are actually other languages than C/C++ in the world.

And your impression of SUN's policy sound totally out of touch
with reality.

SUN has released several other languages for the JVM.
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.
Ada, Python, Ruby etc. are all used commercially.

Arne
Jun 29 '08 #114
One day somebody tell something like the following:

"Work with C#, and learn C++"

I explain it in my opinion; C# is easy to learn, and I consider C++ (not
only C), is a little difficult to use for a begginer. In the other hand, the
most of programmers develop in C++; For example, I think Windows 9x,nt,xp,2k
were designed with c++6. So, with C++, you could do all you need and want,
but... there would be an easiest way to do the same with C#.

Actually there're too many platforms, devices and.... any more? Programming
languages, are not reduced to C++, C# or VB, in the other hand there're
Java, Perl, Python, Ruby. And other platforms, like Unix,Solaris,Novell.

When you use a .NET language, you're falling down to Windows OS, but ... you
know. If you're a programmer, you maybe would like to do a program that runs
at any platform. Solution? Java.

In addition, I only see a problem with Java, and is about execution time;
but the same problem is when you're running a .net app. Slow, slow, slow,
...... But the same Java app, runs on other platforms.

Learn a lot of language, think about the problem, and decide with language
must you use looking at the problem, may be C#, maybe C, maybe Java, ....

"Work with C#, and learn C++".

"Cor Ligthert [MVP]" <no************@planet.nlescribiˇ en el mensaje
news:%2*****************@TK2MSFTNGP06.phx.gbl...
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.


Jun 29 '08 #115
Andre Kaufmann wrote:
I don't know the interfaces today. The good old JNI interface was a pain
to deal with.
JNI is for JVM -native.

JVM -JVM is different.
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 ?
Yes.

See example below.

Arne

================================================== ==================

C:\>type P.py
import J
print "I am Python"
o = J()
o.test()

C:\>type J.java
public class J {
public void test() {
System.out.println("I am Java");
ada_test.adainit(); // Ada runtime need to be initialized
a.a();
}
}
C:\>type A.adb
with Ada.Text_IO; use Ada.Text_IO;

procedure A is

begin
Put_line("I am Ada");
end A;

C:\>jgnatmake -I\jgnat-1.1p\JavaAPI A.adb
jgnatbind -aO./ -aO\jgnat-1.1p\JavaAPI -I- -x a.ali
jgnatlink a.ali

C:\>javac -classpath . J.java

C:\>call jythonc P.py
processing P

Required packages:

Creating adapters:

Creating .java files:
P module

Compiling .java to .class...
Compiling with args: ['C:\\SUNJava\\jdk1.3.1\\bin\\javac', '-classpath',
'C:\\jython21\\jython.jar; ... (all my jar files cut out)]
0 Note: Some input files use or override a deprecated API.
Note: Recompile with -deprecation for details.
C:\>java -cp
..;C:\jgnat-1.1p\lib\jgnat.jar;C:\jpywork;C:\jython21\jython.j ar P
I am Python
I am Java
I am Ada
Jun 29 '08 #116
Andre Kaufmann <an*********************@t-online.dewrote:
Hendrik Schober wrote:
>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

Thanks for the link.
>>> 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.

Yes, agreed. But in a large team it's still a pain to start the build
process over and over again, because in your local project it compiled
fine but in another project some weird side effect causes a compilation
error.
I'm not sure what you're getting at.
Yes, include files and macros are a PITA. But, as I said,
it easily gets better by using more hardware resources.
And that's a cheap way to solve a problem. How much your
language supports you in writing correct code is IMO far
more important.
Even if I use processing power, C++ still compiles way more slower than
most of the other languages do. Currently our build time is 30 minutes,
which has been 3 hours before we switched to a quad core system.

I could live with the compilation time, if the slow down would be caused
by the complex syntax of C++ only and if that would be outweighed by the
productivity increase by all the goodies of C++ (templates, RAII etc.).
But since the slow down isn't caused by the complexity, but because the
compiler has to compile code over and over again, I think it's a huge
loss of productivity for - nothing - .
Yes, agreed. But still. We used to use several dozen CPUs
for one build. Since every developer has a couple of them
and since most of the time developers are thinking or
typing, their CPUs are available for this most of the time.
With this setup, /linking/ was the worst bottleneck, not
compiling.
If compile-times are your worst problem, then that's good.
Buy some IncrediBuild licenses, get over it, and focus on
writing correct code.
[snipped other points I mostly agree with]
Andre
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
Jun 29 '08 #117
Andre Kaufmann <an*********************@t-online.dewrote:
[...]
I had a huge problem, with template virtual base classes and somewhere
in the object hierarchy the base function hasn't been overridden and the
compiler logically didn't complain about it. Fortunately I had VC which
has a proprietary extension supporting override for native code too to
ensure that the compiled code does what I expected it to do.

I was only told in the forum that this is a minor problem and therefore
there is no need for override to get into the next standard.
I don't use this coding style anymore [...]
And I think that's the important statement here.
Deep inheritance hierarchies and "pure OO" are,
fortunately, not hip anymore.
[...]
>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++.

Unfortunately "export" doesn't do what it's meant to be. It doesn't
separate translation units. But yes, I agree that templates could be
supported over language boundaries too.
Google for discussions I had here with Daveed Vandervoorde
and Walter Bright about 'export'. Daveed assured that it
would solve what is my worst problem with templates: That
I not only need to put the template itself in headers, but
also all the templates it depends on. ('namespace detail',
anyone?) That makes for thousands of LoC in headers and,
according to Daveed, 'export' would solve this.
[...]
Andre
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
Jun 29 '08 #118
Daniel James <wa*********@nospam.aaisp.orgwrote:
In article news:<ue**************@TK2MSFTNGP05.phx.gbl>, Hendrik Schober
wrote:
>Daniel James wrote:
>>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()'. :(

Yeah, sorry, I boobed. Andre Kauffman has pointed out elsethread that I
didn't dig deep enough into the Dinkumware code to get to the
::sprintf_s call.

That's rather disappointing ... num_put::do_put knows that what it's
printing is an int, so it passes a format string to sprintf_s and gets
it to decode that to determine something its caller already knew. Why
can't do_put directly call whatever sprintf_s calls to process ints?

Maybe the efficiency gain from doing that would be trivial, but from
where I sit it looks like the code just makes work for itself.
As I wrote, Dietmar KŘhl used to have a stream
implementation which he claimed (I never used it) to
be much faster than the then common once and ISTR him
mentioning that one of the reasons is he doesn't use
'printf()' for outputting.
I'm sure there's other reasons why streams are slower
than other IO implementations (e.g. sentries for every
IO operation), but the idea to throw away compile-time
type info and having to find out all about it again at
run-time does seem "funny".
Daniel.
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
Jun 29 '08 #119
Daniel James wrote:
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.
Encapsulation is limiting choices.
>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.
I believe there is a reason that we use (forgive for using C# syntax):

public class FooBar
{
private int v;

and not:

public class FooBar
{
// Do not use this field directly
public int v;

Arne
Jun 30 '08 #120
Angus wrote:
If you wanted to write a general purpose program with a small footprint,
with good performance then C++ is a great choice.
And if you want to write a program that solves the business
problem with minimal cost then C# is a great choice.

Arne
Jun 30 '08 #121
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.

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.
On modern hardware I believe that 1 hours compilation per day for
each developer in most cases will be an indication of a badly structured
project and/or build.

And besides I would expect the developers to think while they wait
for the build to complete.

Arne
Jun 30 '08 #122
Hendrik Schober wrote:
Andre Kaufmann <an*********************@t-online.dewrote:
[...]
I'm not sure what you're getting at.
Simply productivity.
Yes, include files and macros are a PITA. But, as I said,
it easily gets better by using more hardware resources.
And that's a cheap way to solve a problem. How much your
Besides the energy prices are rising too ;-).
I think I know what you mean, but anyways I would prefer faster
compilation, because I wouldn't have to spend that much time to decouple
my modules with e.g. pimpl idiom and handling precompiled header files.
language supports you in writing correct code is IMO far
more important.
Agreed.
[...]
Schobi
Andre

Jun 30 '08 #123
Arne Vajh°j wrote:
Andre Kaufmann wrote:
>I don't know the interfaces today. The good old JNI interface was a
pain to deal with.

JNI is for JVM -native.

JVM -JVM is different.
>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 ?

Yes.

See example below.
Thanks for the sample.
Arne
Andre
[...]
Jun 30 '08 #124
Hendrik Schober wrote:
Andre Kaufmann <an*********************@t-online.dewrote:
[...]
Google for discussions I had here with Daveed Vandervoorde
and Walter Bright about 'export'. Daveed assured that it
would solve what is my worst problem with templates: That
I not only need to put the template itself in headers, but
also all the templates it depends on. ('namespace detail',
anyone?) That makes for thousands of LoC in headers and,
according to Daveed, 'export' would solve this.
O.k., export hides the implementation for sure. But if I use the
template the compiler still has to compile the whole code at least for
each new instantiation (new type) and I wonder how often that will be if
the exported template code uses meta templates and other templates.
The compiler then must have a kind of global overview to check if it
needs to compile the code or not, since it has to know the
implementation in contrast to "non template" code.

I like separation too. But it would be sufficient for me to separate the
template code in a single file or into to files without export, if the
compiler would compile the code faster anyways.
>[...]
Schobi
Andre
Jun 30 '08 #125
Arne Vajh°j wrote:
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.

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.

On modern hardware I believe that 1 hours compilation per day for
each developer in most cases will be an indication of a badly structured
project and/or build.
What if you have to fiddle with templates in a
several MLoC project?
And besides I would expect the developers to think while they wait
for the build to complete.
Not 90% of the day.
(Go to
http://www.joelonsoftware.com/articl...000000043.html
and read the first paragraph of #9.)
Arne
Schobi
Jun 30 '08 #126
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.

Encapsulation is limiting choices.
Encapsulation /can/ limit choices (as your example neatly shows) but
that is not its main function.

Cheers,
Daniel.
Jun 30 '08 #127
In article news:<48***********************@news.sunsite.dk>, Arne
Vajh°j wrote:
That is one of the worst pieces of logic I have seen in a long time.
If I were trying to make the argument you seem to think I am making
then you would be right about that!

I wrote:
>>>I understand that the design of the JVM specifically makes
it hard to taget it with C or C++.
... but note that "specifically" does not mean (and should not be
taken to imply) "deliberately".

(and for "taget" read "target")

The point I was making was that the JVM lacks instuctions for pointer
handling that would be needed if it were to be targeted by some other
languages than Java -- /specifically/ C-like languages.
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.

Ada, Python, Ruby etc. are all used commercially.
Yes, of course they are. I said that *most* of the cited languages
were eperimental ... and then went on to single out Jython, etc., as
the exceptions.

Saying that (say) Python is used commercially -- we ALL know that --
is is rather different from saying that Jython is used commercially
(it is, but on *nothing* *like* the same scale and only because of its
ability to interoperate with Java).

Cheers,
Daniel.


Jun 30 '08 #128
Moreover, I doubt that very big and successfull apps (like Microsoft
Office, or Visual Studio, or even non-Microsoft apps like Photoshop)
could be built using C# (or Java...). Or, if they would be built with
C# or some other "managed" language, what would be the memory
occupation and would they be as snappy as the C++ versions?
I think people have noticed exactly that.... newer versions of Visual Studio
are much slower and memory intensive than the most recent non-.NET version,
hence the "10 is the new 6" goal we hear from the MS developer tools team.

And lest you think that Visual Studio isn't written in C# since at least
2005, let me point out:

The Forms Designer works by loading and executing your custom control code
in-process.
I've gotten NullReferenceException dialogs many times from the IDE itself.
Try using the Tools-Customize command on a right-click context menu, for
example (I wanted to change the accelerator keys), and see what happens.
Jun 30 '08 #129
Rudy Velthuis wrote:
Daniel Boulerice wrote:
>>
CJ,

I guess you were surprised of how many replies you got so far!!

Anyway, if you want to move to C# or C++, know this:

a.. C# is a virtual machine - a little like java and VB already -
at run-time your program is interpreted by another program called the
CLR.

No, it isn't. At runtime, it is compiled just-in-time and it runs
natively, it is not interpreted. The CLR is not another program
either, it is the main runtime library that comes with .NET, and also
runs natively. AFAIK, most C++ products also have a runtime library.
.NET's CLR is just more extensive.
The CLR is not the same as the BCL. The BCL is comparable to the runtime
library of other languages, C++ doesn't need anything corresponding to the
CLR.
Jun 30 '08 #130
Ben Voigt [C++ MVP] wrote:
Rudy Velthuis wrote:
Daniel Boulerice wrote:
>
CJ,
>
I guess you were surprised of how many replies you got so far!!
>
Anyway, if you want to move to C# or C++, know this:
>
a.. C# is a virtual machine - a little like java and VB already -
at run-time your program is interpreted by another program called
the CLR.
No, it isn't. At runtime, it is compiled just-in-time and it runs
natively, it is not interpreted. The CLR is not another program
either, it is the main runtime library that comes with .NET, and
also runs natively. AFAIK, most C++ products also have a runtime
library. .NET's CLR is just more extensive.

The CLR is not the same as the BCL. The BCL is comparable to the
runtime library of other languages, C++ doesn't need anything
corresponding to the CLR.
The CLR is much more than a simple runtime, I agree. But it is not a
program that interprets programs as bytecode. <g>
--
Rudy Velthuis http://rvelthuis.de

"The instinct of nearly all societies is to lock up anybody who
is truly free. First, society begins by trying to beat you up.
If this fails, they try to poison you. If this fails too, the
finish by loading honors on your head."
-- Jean Cocteau (1889-1963)
Jun 30 '08 #131
Ben Voigt [C++ MVP] wrote:
I think people have noticed exactly that.... newer versions of Visual Studio
are much slower and memory intensive than the most recent non-.NET version,
hence the "10 is the new 6" goal we hear from the MS developer tools team.
VS 2008 uses a lot more memory than VS 6.

But I would argue that so do all other apps compared
to what they did 10 years ago.

Office 2007 compared with 97.

FireFox 2 compared to Netscape 4.

Etc.

I really doubt that VS is unique in that aspect.

Yes - JIT & managed tend to add to startup time.

Arne
Jul 1 '08 #132
Rudy Velthuis wrote:
Ben Voigt [C++ MVP] wrote:
>Rudy Velthuis wrote:
>>Daniel Boulerice wrote:
CJ,

I guess you were surprised of how many replies you got so far!!

Anyway, if you want to move to C# or C++, know this:

a.. C# is a virtual machine - a little like java and VB already -
at run-time your program is interpreted by another program called
the CLR.

No, it isn't. At runtime, it is compiled just-in-time and it runs
natively, it is not interpreted. The CLR is not another program
either, it is the main runtime library that comes with .NET, and
also runs natively. AFAIK, most C++ products also have a runtime
library. .NET's CLR is just more extensive.

The CLR is not the same as the BCL. The BCL is comparable to the
runtime library of other languages, C++ doesn't need anything
corresponding to the CLR.

The CLR is much more than a simple runtime, I agree. But it is not a
program that interprets programs as bytecode. <g>
It isn't "interpret + execute" which is the definition of an "interpreted
language". It is "interpret + optimize + native codegen + execute" which
has both advantages and disadvantages. In any case, .NET does target a
virtual machine, just like Java (which also does JIT compilation in several
implementations).
Jul 1 '08 #133
ajk wrote:
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)?
It's not "can't be done in C++/CLI", it's poor designer support. Sure, you
can write WPF code in C++/CLI. But you don't get to use the XAML designer,
because XAML is compatible with C# but not C++/CLI. And so on.
Jul 2 '08 #134
RFOG wrote:
Arne Vajh°j avait Úcrit le 29/06/2008 :
>RFOG wrote:
>>"Arne Vajh°j" <ar**@vajhoej.dkescribiˇ en el mensaje de noticias
news:48***********************@news.sunsite.dk.. .
RFOG wrote:

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(*).

You will need something native to do that.

But that is a microscopic part of an OS like Windows Vista.

Are you really sure you are saying?
Absolutely.
Please, take C:\WIndows and c:\windows\system32 and count what programs
are .net and what programs are native.
Try examine in EXE's in C:\DOS on a DOS 6.22 system.

They are all 16 bits, so we have hereby proven that an OS need
to consist of 16 bit executables.

Or maybe not.

How can you consider the fact that Vista is written almost
entirely in native as an indication of that is has to be so ??

Arne
Jul 4 '08 #135
Hendrik Schober wrote:
Arne Vajh°j wrote:
>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.

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.

On modern hardware I believe that 1 hours compilation per day for
each developer in most cases will be an indication of a badly structured
project and/or build.

What if you have to fiddle with templates in a
several MLoC project?
No difference.

If you constantly need to rebuild MLOC's the project structure
is fubar.
>And besides I would expect the developers to think while they wait
for the build to complete.

Not 90% of the day.
(Go to
http://www.joelonsoftware.com/articl...000000043.html
and read the first paragraph of #9.)
I know the point of view.

But I don't believe in it.

Software engineering is about thinking, analzying and
designing (plus troubleshooting if it does not work) - typing
in code and building is the least part and by far the easiest part.

Arne
Jul 4 '08 #136
Daniel James wrote:
In article news:<48***********************@news.sunsite.dk>, Arne
Vajh°j wrote:
>That is one of the worst pieces of logic I have seen in a long time.

If I were trying to make the argument you seem to think I am making
then you would be right about that!

I wrote:
>>>>I understand that the design of the JVM specifically makes
it hard to taget it with C or C++.

.. but note that "specifically" does not mean (and should not be
taken to imply) "deliberately".

(and for "taget" read "target")

The point I was making was that the JVM lacks instuctions for pointer
handling that would be needed if it were to be targeted by some other
languages than Java -- /specifically/ C-like languages.
I wrote explicit what I considered the flaw in the logic.

And it had nothing to do with specifically versus intentionally.

The discussion was whether the JVM was for one language or
many languages. None claimed that it was for all languages.

The fact that it is not for C/C++ does not prove that it was
for one language.

Arne
Jul 4 '08 #137
I'm going to stop this absurd conversation. This is my last email.

Because Windows IS kernel32.dll, gdi32.dll, user32.dll and those files are
native ones.

Because Windows IS ntoskrnl.exe, and some other .exe/.dll/.sys files that
are native ones.

Because Windows Shell IS explorer.exe and a little aux. files that are
native ones.

Bye forever.

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:48***********************@news.sunsite.dk...
RFOG wrote:
>Arne Vajh°j avait Úcrit le 29/06/2008 :
>>RFOG wrote:
"Arne Vajh°j" <ar**@vajhoej.dkescribiˇ en el mensaje de noticias
news:48***********************@news.sunsite.dk. ..
RFOG wrote:
>
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(*).

You will need something native to do that.

But that is a microscopic part of an OS like Windows Vista.

Are you really sure you are saying?

Absolutely.
>Please, take C:\WIndows and c:\windows\system32 and count what programs
are .net and what programs are native.

Try examine in EXE's in C:\DOS on a DOS 6.22 system.

They are all 16 bits, so we have hereby proven that an OS need
to consist of 16 bit executables.

Or maybe not.

How can you consider the fact that Vista is written almost
entirely in native as an indication of that is has to be so ??

Arne
--
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
========================================
Acelgas a medio dÝa y a la noche acelgas, mala comida y mala cena.

Jul 4 '08 #138
Arne Vajh°j wrote:
Hendrik Schober wrote:
[...]
> What if you have to fiddle with templates in a
several MLoC project?

No difference.

If you constantly need to rebuild MLOC's the project structure
is fubar.
I'll stop taking you serious right here. You seem to not to
know what you're talking about.
[...]
Arne
Schobi
Jul 4 '08 #139
Arne Vajh°j <ar**@vajhoej.dkwrote in news:485c5d19$0$90265$14726298
@news.sunsite.dk:
clintonG wrote:
>Microsoft developed C# specifically for the web.

I don't think so. I believe C# was developed to be a general
language.
C# was developed because Sun wouldn't allow MS to tightly couple its Java
implementation to Windows, encouraging people to build Windows-only Java
apps. (The "embrace and extend" system of locking in your customers.)

As others have pointed out, use C# for business clients, particularly GUI
stuff. With project Mono, you can even use it on other platforms. (I just
recently coded a C# wrapper for a high-performance C++ library so that the
GUI people would have an easy time of connecting to it.) It's also good for
systems with complex object lifetime management needs.

If you need to connect to non-.NET business apps, consider Java, instead.
You can even use the new open source "Iced Tea" implementation to free
yourself from vendor lock-in. Java is the real language to compare to C#,
not C++. C++ is the fussy but fast hot-rod, while C# and Java are the
comfortable but slower family sedans.

Now to go find my flame-retardent underwear.... ;)
Jul 10 '08 #140
MC
"Kenneth Porter" <sh*************@sewingwitch.comwrote in message
news:Xn**************************@207.46.248.16...
Arne Vajh°j <ar**@vajhoej.dkwrote in news:485c5d19$0$90265$14726298
@news.sunsite.dk:
>clintonG wrote:
>>Microsoft developed C# specifically for the web.

I don't think so. I believe C# was developed to be a general
language.

C# was developed because Sun wouldn't allow MS to tightly couple its Java
implementation to Windows,
If all Microsoft had wanted was their own variant of Java for the .NET API,
they could have had it. In fact they did. It was called J#.

(Incidentally, ".NET" does not have much if anything to do with networking.
It is a classic needlessly misleading name.)

C# was invented because Microsoft had a good idea for a new API for Windows
(namely .NET Framework) and Anders Hejlsberg had some good ideas for a new
programming language, similar but not identical to Java.

Of course, in the interest of Openness and Freedom, There Should Never Be
Any New Programming Language Invented. FORTRAN '58 forever! :)
Jul 10 '08 #141
On Thu, 10 Jul 2008 18:22:40 -0400, "MC"
<fo**************@www.ai.uga.edu.slash.mcwrote:
>Of course, in the interest of Openness and Freedom, There Should Never Be
Any New Programming Language Invented. FORTRAN '58 forever! :)
Real Programmers can write FORTRAN in any language.

rossum

Jul 11 '08 #142

"Kenneth Porter" <sh*************@sewingwitch.comha scritto nel messaggio
news:Xn**************************@207.46.248.16...
C# was developed because Sun wouldn't allow MS to tightly couple its Java
implementation to Windows, encouraging people to build Windows-only Java
apps. (The "embrace and extend" system of locking in your customers.)
I don't agree.

C# is more complete and more advanced than Java.
In C# Microsoft put lots of improvements over Java.
I think that in C# Microsoft put lessons learned from several languages:
C++, Java, and classic Visual Basic, too.

For example: Java has no concept of properties (you must use get/set like in
C++).
Java has no concept of delegate.
In Java all methods are virtual by default (instead, in C# you must specify
that).
And C# has a very good RAD environment with WinForm, I don't think that Java
has anything similar.

And C# has also LINQ, instead I think that in Java there is no language
support for SQL-like syntax.

And C# has the 'using' and 'IDisposable' for non-memory resources (like file
handles, etc.).
Instead I think that Java has nothing similar.

And it is very easy to use C++ code from C#, thanks to C++/CLI. Again, I
think that calling C++ code from Java is not so easy...

Giovanni
Jul 11 '08 #143
C# was invented because Microsoft had a good idea for a new API for
Windows (namely .NET Framework) and Anders Hejlsberg had some good ideas
for a new programming language, similar but not identical to Java.
No, Clinton is right. Java was falling short of what they wanted to do. See
http://blogs.msdn.com/patrick_dussud...f-the-clr.aspx

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Download OWC Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $15.00
Need a free copy of VSTS 2008 w/ MSDN Premium?
http://msmvps.com/blogs/alvin/Default.aspx
-------------------------------------------------------
"MC" <fo**************@www.ai.uga.edu.slash.mcwrote in message
news:em**************@TK2MSFTNGP03.phx.gbl...
"Kenneth Porter" <sh*************@sewingwitch.comwrote in message
news:Xn**************************@207.46.248.16...
>Arne Vajh°j <ar**@vajhoej.dkwrote in news:485c5d19$0$90265$14726298
@news.sunsite.dk:
>>clintonG wrote:
Microsoft developed C# specifically for the web.

I don't think so. I believe C# was developed to be a general
language.

C# was developed because Sun wouldn't allow MS to tightly couple its Java
implementation to Windows,

If all Microsoft had wanted was their own variant of Java for the .NET
API, they could have had it. In fact they did. It was called J#.

(Incidentally, ".NET" does not have much if anything to do with
networking. It is a classic needlessly misleading name.)

C# was invented because Microsoft had a good idea for a new API for
Windows (namely .NET Framework) and Anders Hejlsberg had some good ideas
for a new programming language, similar but not identical to Java.

Of course, in the interest of Openness and Freedom, There Should Never Be
Any New Programming Language Invented. FORTRAN '58 forever! :)

Jul 13 '08 #144
Giovanni Dicanio wrote:
"Kenneth Porter" <sh*************@sewingwitch.comha scritto nel
messaggio news:Xn**************************@207.46.248.16...
>C# was developed because Sun wouldn't allow MS to tightly couple its
Java implementation to Windows, encouraging people to build
Windows-only Java apps. (The "embrace and extend" system of locking
in your customers.)

I don't agree.

C# is more complete and more advanced than Java.
In C# Microsoft put lots of improvements over Java.
I think that in C# Microsoft put lessons learned from several
languages: C++, Java, and classic Visual Basic, too.

For example: Java has no concept of properties (you must use get/set
like in C++).
Java has no concept of delegate.
In Java all methods are virtual by default (instead, in C# you must
specify that).
And C# has a very good RAD environment with WinForm, I don't think
that Java has anything similar.
C# doesn't have. Visual Studio has, in the Forms Designer, a RAD
environment which is rather prone to crashing (i.e. less than "very good").
Quite a number of Java IDEs have RAD GUI designers as well, I'm sure. I
don't use Java for application development, but I'd start by looking at some
of the many Eclipse plugins if I needed a dialog / window design tool.
>
And C# has also LINQ, instead I think that in Java there is no
language support for SQL-like syntax.

And C# has the 'using' and 'IDisposable' for non-memory resources
(like file handles, etc.).
Instead I think that Java has nothing similar.

And it is very easy to use C++ code from C#, thanks to C++/CLI.
Again, I think that calling C++ code from Java is not so easy...

Giovanni

Jul 14 '08 #145

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamha scritto nel messaggio
news:%2***************@TK2MSFTNGP05.phx.gbl...
>And C# has a very good RAD environment with WinForm, I don't think
that Java has anything similar.

C# doesn't have. Visual Studio has, in the Forms Designer, a RAD
environment
You're correct, thanks.

which is rather prone to crashing (i.e. less than "very good").
I did not do anything big in WinForm, but I had no problem with VS2008
WinForm Designer and C#.
(Maybe it does not scale up well?)

Giovanni
Jul 14 '08 #146
Ben Voigt [C++ MVP] wrote:
Giovanni Dicanio wrote:
>"Kenneth Porter" <sh*************@sewingwitch.comha scritto nel
messaggio news:Xn**************************@207.46.248.16...
[...]
C# doesn't have. Visual Studio has, in the Forms Designer, a RAD
I think the WinForms designer is part of the .NET framework and can be
hosted in other applications too.
environment which is rather prone to crashing (i.e. less than "very good").
The C++ one is quite bad but I don't have that impression regarding the
C# (managed languages) one.

[...]
Andre
Jul 15 '08 #147
Andre Kaufmann wrote:
Ben Voigt [C++ MVP] wrote:
>Giovanni Dicanio wrote:
>>"Kenneth Porter" <sh*************@sewingwitch.comha scritto nel
messaggio news:Xn**************************@207.46.248.16...
[...]
C# doesn't have. Visual Studio has, in the Forms Designer, a RAD

I think the WinForms designer is part of the .NET framework and can be
hosted in other applications too.
The .NET framework includes support for including design-time support for
user controls, but not the design environment itself. I think the design
environment can be hosted, but you'd be using the Visual Studio
extensibility SDK and licensing Visual Studio runtime components, not just
the .NET framework.
>
>environment which is rather prone to crashing (i.e. less than "very
good").

The C++ one is quite bad but I don't have that impression regarding
the C# (managed languages) one.
I've had the C# designer (VS2005) crash numerous times. The fact that the
crash dialog for Visual Studio isn't actually modal (a serendipitous bug I
suspect) is the only thing that's saved by solution from total uselessness
on multiple occasions (i.e. I was able to close the faulting designer window
and save the solution before letting the crash window exit Visual Studio,
otherwise merely opening the solution produced a crash)
>
>[...]

Andre

Jul 17 '08 #148
Ben Voigt [C++ MVP] wrote:
Andre Kaufmann wrote:
[...]
The .NET framework includes support for including design-time support for
user controls, but not the design environment itself. I think the design
environment can be hosted, but you'd be using the Visual Studio
I'm not 100% sure about how much of the functionality of the WinForms
Designer is part of the .NET framework. I only know that it has been
hosted by some commercial applications too. However, I've hosted the
Windows Workflow Designer in my own application, but it wasn't simply
adding some controls to my main form. So I suspect the same might be
true for the WinForms Designer too.
extensibility SDK and licensing Visual Studio runtime components, not just
the .NET framework.
Since the core of the Visual Studio IDE (now) can be hosted / used for
free I don't think the runtime components have to be licenced.
However the Visual Studio Shell has to be shipped, additionally to the
..NET framework. I'm not familiar with the Visual Studio Shell and I
don't know if the WinForms designer is part of it. But I suspect it to
be so.
[...]
Andre
Jul 17 '08 #149
>extensibility SDK and licensing Visual Studio runtime components,
>not just the .NET framework.

Since the core of the Visual Studio IDE (now) can be hosted / used for
free I don't think the runtime components have to be licenced.
"for free" is assuredly not the same as "not licensed".
However the Visual Studio Shell has to be shipped, additionally to the
.NET framework. I'm not familiar with the Visual Studio Shell and I
don't know if the WinForms designer is part of it. But I suspect it to
be so.
>[...]

Andre

Jul 17 '08 #150

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by William C. White | last post: by
2 posts views Thread by Albert Ahtenberg | last post: by
3 posts views Thread by James | last post: by
reply views Thread by Ollivier Robert | last post: by
1 post views Thread by Richard Galli | last post: by
4 posts views Thread by Albert Ahtenberg | last post: by
1 post views Thread by inderjit S Gabrie | last post: by
2 posts views Thread by Jack | last post: by
3 posts views Thread by Sandwick | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.