C# vs. C++

[Daniel James]

Re: C# vs. C++

In article news:<#GZ4sLT2I HA.5472@TK2MSFT NGP06.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.

[Bo Persson]

Re: C# vs. C++

Daniel James wrote:

In article news:<#GZ4sLT2I HA.5472@TK2MSFT NGP06.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

[Andre Kaufmann]

Re: C# vs. C++

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

[Andre Kaufmann]

Re: C# vs. C++

Bo Persson wrote:

Daniel James wrote:

>In article news:<#GZ4sLT2I HA.5472@TK2MSFT NGP06.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

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

Re: C# vs. C++

RFOG wrote:

"Arne Vajhøj" <arne@vajhoej.d kescribió en el mensaje de noticias
news:4861b6ba$0 $90275$14726298 @news.sunsite.d k...

>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

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Re: C# vs. C++

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

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

Re: C# vs. C++

Andre Kaufmann wrote:

Jon Skeet [C# MVP] wrote:

>Daniel James <wastebasket@no spam.aaisp.orgw rote:

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

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

Re: C# vs. C++

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
>>specificall y 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

[Jordi Maicas]

Re: C# vs. C++

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,No vell.

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]" <notmyfirstname @planet.nlescri bió en el mensaje
news:%23%231by3 o1IHA.548@TK2MS FTNGP06.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.nosp amschreef in bericht
news:uKLx1Px0IH A.6096@TK2MSFTN GP06.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.

>
>

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

Re: C# vs. C++

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.prin tln("I am Java");
ada_test.adaini t(); // 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\\j dk1.3.1\\bin\\j avac', '-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\jyt hon.jar P
I am Python
I am Java
I am Ada

[Hendrik Schober]

Re: C# vs. C++

Andre Kaufmann <andre.kaufmann _re_move_@t-online.dewrote:

Hendrik Schober wrote:

>Rudy Velthuis <newsgroups@rve lthuis.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

--
SpamTrap@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

[Hendrik Schober]

Re: C# vs. C++

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

--
SpamTrap@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

[Hendrik Schober]

Re: C# vs. C++

Daniel James <wastebasket@no spam.aaisp.orgw rote:

In article news:<ueHnd9F2I HA.3884@TK2MSFT NGP05.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

--
SpamTrap@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

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

Re: C# vs. C++

Daniel James wrote:

In article news:<4861b785$ 0$90275$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.

>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

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

Re: C# vs. C++

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