C# vs. C++

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: C# vs. C++

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

[Andre Kaufmann]

Re: C# vs. C++

Hendrik Schober wrote:

Andre Kaufmann <andre.kaufmann _re_move_@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

[Andre Kaufmann]

Re: C# vs. C++

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

[...]

[Andre Kaufmann]

Re: C# vs. C++

Hendrik Schober wrote:

Andre Kaufmann <andre.kaufmann _re_move_@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

[Hendrik Schober]

Re: C# vs. C++

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/articles/fog0000000043.html

and read the first paragraph of #9.)

Arne

Schobi

[Daniel James]

Re: C# vs. C++

In article news:<486827b1$ 0$90267$1472629 8@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.

[Daniel James]

Re: C# vs. C++

In article news:<4867fd62$ 0$90263$1472629 8@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 "specifical ly" does not mean (and should not be
taken to imply) "deliberate ly".

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

[Ben Voigt [C++ MVP]]

Re: C# vs. C++

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 NullReferenceEx ception 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.

[Ben Voigt [C++ MVP]]

Re: C# vs. C++

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.

[Rudy Velthuis]

Re: C# vs. C++

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)

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: C# vs. C++

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

[Ben Voigt [C++ MVP]]

Re: C# vs. C++

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
>correspondin g 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 "interprete d
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 ).

[=?ISO-8859-15?Q?Arne_Vajh=F8j?=]

Re: C# vs. C++

RFOG wrote:

Arne Vajhøj avait écrit le 29/06/2008 :

>RFOG wrote:

>>"Arne Vajhøj" <arne@vajhoej.d kescribió en el mensaje de noticias
>>news:4861b6ba $0$90275$147262 98@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\syst em32 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

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: C# vs. C++

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.
>>>Compilatio n 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/articles/fog0000000043.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

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: C# vs. C++

Daniel James wrote:

In article news:<4867fd62$ 0$90263$1472629 8@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 "specifical ly" does not mean (and should not be
taken to imply) "deliberate ly".
>
(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