C# vs. C++

[Hendrik Schober]

[...]
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

 

[Arne Vajhøj]

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.jar P
I am Python
I am Java
I am Ada

 

[Hendrik Schober]

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

 

[Arne Vajhøj]

No it isn't. It's about a certain kind of encapsulation.

Encapsulation is limiting choices.

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

 

[Arne Vajhøj]

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

 

[Arne Vajhøj]

[...]

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]

[...]
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]

JNI is for JVM -> native.

JVM -> JVM is different.


Yes.

See example below.

Thanks for the sample.

Arne
Andre

[...]

 

[Andre Kaufmann]

[...]
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

 

[RFOG]

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

You will need something native to do that.

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

Arne

Are you really sure you are saying?

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

And c:\program files

--
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
========================================

Nunca cause un problema para el que no tenga solución.
-- Regla de Burke.

 

[Hendrik Schober]

[...]
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

 

[Ben Voigt [C++ MVP]]

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.

 

[Ben Voigt [C++ MVP]]

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]

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)

 

[Arne Vajhøj]

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]]

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

 

[Arne Vajhøj]

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

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

 

[Arne Vajhøj]

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.

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

 

[Arne Vajhøj]

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


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

 

[RFOG]

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.

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.