Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #7938 > unrolled thread

Why your next language better be C++

Back to article view | Back to comp.lang.c++

Contents

  Why your next language better be C++ Lynn McGuire <lmc@winsim.com> - 2011-07-18 11:18 -0500
    Re: Why your next language better be C++ "Paul" <pchristor@yahoo.co.uk> - 2011-07-18 19:46 +0100
    Re: Why your next language better be C++ Goran <goran.pusic@gmail.com> - 2011-07-19 00:03 -0700
      Re: Why your next language better be C++ "Bo Persson" <bop@gmb.dk> - 2011-07-19 17:19 +0200
      Re: Why your next language better be C++ Noah Roberts <dont@email.me> - 2011-07-19 09:39 -0700
      Re: Why your next language better be C++ Paavo Helde <myfirstname@osa.pri.ee> - 2011-07-19 13:35 -0500
        Re: Why your next language better be C++ James Kanze <james.kanze@gmail.com> - 2011-07-21 05:31 -0700
      Re: Why your next language better be C++ Lynn McGuire <lmc@winsim.com> - 2011-07-19 13:59 -0500
      Re: Why your next language better be C++ Rui Maciel <rui.maciel@gmail.com> - 2011-07-21 01:42 +0100
    Re: Why your next language better be C++ BGB <cr88192@hotmail.com> - 2011-07-19 03:00 -0700
      Re: Why your next language better be C++ Rui Maciel <rui.maciel@gmail.com> - 2011-07-21 01:28 +0100
        Re: Why your next language better be C++ BGB <cr88192@hotmail.com> - 2011-07-21 00:37 -0700
          Re: Why your next language better be C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-07-21 15:53 +0000
            Re: Why your next language better be C++ BGB <cr88192@hotmail.com> - 2011-07-21 12:31 -0700
              Re: Why your next language better be C++ Rui Maciel <rui.maciel@gmail.com> - 2011-07-22 10:21 +0100
                Re: Why your next language better be C++ BGB <cr88192@hotmail.com> - 2011-07-22 10:43 -0700
    Re: Why your next language better be C++ James Kanze <james.kanze@gmail.com> - 2011-07-20 13:12 -0700
      Re: Why your next language better be C++ "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-20 15:52 -0500
        Re: Why your next language better be C++ James Kanze <james.kanze@gmail.com> - 2011-07-21 05:39 -0700
          Re: Why your next language better be C++ "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 14:54 -0500
            Re: Why your next language better be C++ Noah Roberts <dont@email.me> - 2011-07-21 13:47 -0700
            Re: Why your next language better be C++ Rui Maciel <rui.maciel@gmail.com> - 2011-07-22 10:30 +0100
            Re: Why your next language better be C++ James Kanze <james.kanze@gmail.com> - 2011-07-22 12:35 -0700
            Re: Why your next language better be C++ "Bo Persson" <bop@gmb.dk> - 2011-07-23 16:30 +0200
              Re: Why your next language better be C++ BGB <cr88192@hotmail.com> - 2011-07-23 12:04 -0700
              Re: Why your next language better be C++ Werner <werasm@gmail.com> - 2011-07-25 00:00 -0700
      Re: Why your next language better be C++ Lynn McGuire <lmc@winsim.com> - 2011-07-20 17:36 -0500
        Re: Why your next language better be C++ "Bo Persson" <bop@gmb.dk> - 2011-07-21 20:42 +0200
      Re: Why your next language better be C++ Ebenezer <woodbrian77@gmail.com> - 2011-07-20 22:36 -0700
      Re: Why your next language better be C++ Michael DOUBEZ <michael.doubez@free.fr> - 2011-07-21 04:52 -0700
      Re: Why your next language better be C++ "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 17:54 -0500

Page 1 of 2  [1] 2  Next page →

#7938 — Why your next language better be C++

Why your next language better be C++:
    http://www.i-programmer.info/professional-programmer/i-programmer/2674-why-your-next-language-better-be-c.html

"It looks as if the war between C++ and C# is over
and C++ has won."

"If I was asked to write an advertising poster for C++
it would go something like:

"Do you want to write applications that run directly on
the CPU without interpreters or VMs getting in the way?"

"Do you want make use of the operating system interfaces
as if you owned them?"

"Do you want to use a language that isn't going to be
crippled by an evil proprietor?"

"Then you need C++"

Lynn

[toc] | [next] | [standalone]

#7943

"Lynn McGuire" <lmc@winsim.com> wrote in message 
news:j01me4$fq6$1@dont-email.me...
> Why your next language better be C++:
> 
> http://www.i-programmer.info/professional-programmer/i-programmer/2674-why-your-next-language-better-be-c.html
>
> "It looks as if the war between C++ and C# is over
> and C++ has won."
C# was never a rival of C++, it sounds crazy but its biggest rival was VB :)
>
> "If I was asked to write an advertising poster for C++
> it would go something like:
>
> "Do you want to write applications that run directly on
> the CPU without interpreters or VMs getting in the way?"
>
> "Do you want make use of the operating system interfaces
> as if you owned them?"
I take it you mean API's here.
>
> "Do you want to use a language that isn't going to be
> crippled by an evil proprietor?"
>
> "Then you need C++"
>
C# is ok if you are a C, C++ or Java programmer and you find yourself in 
dotnet environment. Its quite easy to pick up because its syntaxically 
similar. When MS made a big push with the dotnet framework they needed to 
accomodate for non VB'ers for it to appeal to a wider market so they 
invented C# to accompany the dotnet framework. The thing I didn't like about 
it all was that VB for applications didnt evolve to allow the use of C# , 
which would've been nice for doing fancy stuff with excel spreadsheets. If 
they'd done this I would've kept using C# , but as it was I only found it 
usefull for doing dotnet assemblies which I used for Business logic between 
Database and ASP's. I guess it would only be any use if you were a windows 
server porgrammer of sorts, which I'm not, so I have a couple of partially 
read books lying in the bottom of a cupboard someplace since the big dotnet 
thing came along. Oh yes and the MSDN subscriptions that we had for doing 
that project did not come cheap, VS.net pro edition was about £800 when it 
first came out.

Its not comparable to C++, but it was more fun to learn probably because of 
more productivity. :)

[toc] | [prev] | [next] | [standalone]

#7951

On Jul 18, 6:18 pm, Lynn McGuire <l...@winsim.com> wrote:
> "Do you want to write applications that run directly on
> the CPU without interpreters or VMs getting in the way?"

Nobody should care whether an app run directly on the CPU. There's
nothing wrong with a VM per se. There's lots wrong in certain
scenarios, just like there's lots wrong with absence of VM in other
scenarios.

>
> "Do you want make use of the operating system interfaces
> as if you owned them?"

Any language can make use of OS interfaces, because OS interface
always boils down to C, and any language has "foreign function
interface" that binds to C (or at worst, C++, needing a C++ wrapper
for a C library). This argument is, rather: do you need to make a lot
of OS calls? That's most easily done with C an C++ and you'd be
hampered using something else.

> "Do you want to use a language that isn't going to be
> crippled by an evil proprietor?"

There's lots of languages that don't have an evil proprietor. In fact,
I am not sure that C# has an evil proprietor (AFAIK, CLR and C# spec
are ECMA standards). I think, at best you can say that C# has an evil
__implementor__.

> "Then you need C++"

IMHO, current state of affairs is that for many applications,
__sticking to one language__ is the worst thing to do. For example,
there's a very slim chance that you'll be writing C++ code that runs
inside a browser (or inside an HTTP server). Or whatever.

Goran.

[toc] | [prev] | [next] | [standalone]

#7972

Goran wrote:
> On Jul 18, 6:18 pm, Lynn McGuire <l...@winsim.com> wrote:

>> "Do you want to use a language that isn't going to be
>> crippled by an evil proprietor?"
>
> There's lots of languages that don't have an evil proprietor. In
> fact, I am not sure that C# has an evil proprietor (AFAIK, CLR and
> C# spec are ECMA standards). I think, at best you can say that C#
> has an evil __implementor__.
>

The evil implementor also wrote the standards, which is a real 
limitation.

Any day they feel like it, they can provide an "improved standard" for 
ECMA to rubber stamp. Or implement it anyway.


Bo Persson

[toc] | [prev] | [next] | [standalone]

#7977

On 7/19/2011 12:03 AM, Goran wrote:
> On Jul 18, 6:18 pm, Lynn McGuire<l...@winsim.com>  wrote:
>> "Then you need C++"
>
> IMHO, current state of affairs is that for many applications,
> __sticking to one language__ is the worst thing to do. For example,
> there's a very slim chance that you'll be writing C++ code that runs
> inside a browser (or inside an HTTP server). Or whatever.

There's actually a fairly nice C++ API for doing that now.  I gather it 
has all the nice bells and whistles that people who write web 
applications need.  I've played with it a little bit.  Implements drag 
and drop as well as a bunch of other stuff.  Uses Boost.Signals to 
implement event processing.  It's almost exactly like writing a normal 
application.

[toc] | [prev] | [next] | [standalone]

#7982

Goran <goran.pusic@gmail.com> wrote in news:a6df52ad-ccd2-4e9a-93ea-
56c30194ef86@ei5g2000vbb.googlegroups.com:

> IMHO, current state of affairs is that for many applications,
> __sticking to one language__ is the worst thing to do.

Agreed.

> For example,
> there's a very slim chance that you'll be writing C++ code that runs
> inside a browser (or inside an HTTP server). 

There is a lot of C++ code running inside our HTTP server (also written in 
C++). To be honest, there is also a lot of script code running inside the 
HTTP server, but the script language interpreter and many of its functions 
are implemented in C++ again.

Cheers
Paavo

[toc] | [prev] | [next] | [standalone]

#8035

On Jul 19, 7:35 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> Goran <goran.pu...@gmail.com> wrote in news:a6df52ad-ccd2-4e9a-93ea-
> 56c30194e...@ei5g2000vbb.googlegroups.com:

> > IMHO, current state of affairs is that for many applications,
> > __sticking to one language__ is the worst thing to do.

> Agreed.

> > For example,
> > there's a very slim chance that you'll be writing C++ code that runs
> > inside a browser (or inside an HTTP server).

> There is a lot of C++ code running inside our HTTP server (also written in
> C++). To be honest, there is also a lot of script code running inside the
> HTTP server, but the script language interpreter and many of its functions
> are implemented in C++ again.

From what I've seen recently, the usual model seems to be to
provide components written in C++ to do the "hard" work (heavy
maths, data manipulation, etc.), and use other languages to glue
the components together.

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#7983

>> "Do you want to use a language that isn't going to be
>> crippled by an evil proprietor?"
>
> There's lots of languages that don't have an evil proprietor. In fact,
> I am not sure that C# has an evil proprietor (AFAIK, CLR and C# spec
> are ECMA standards). I think, at best you can say that C# has an evil
> __implementor__.

This blog is talking about the battle between C# and C++.

>> "Then you need C++"
>
> IMHO, current state of affairs is that for many applications,
> __sticking to one language__ is the worst thing to do. For example,
> there's a very slim chance that you'll be writing C++ code that runs
> inside a browser (or inside an HTTP server). Or whatever.

All of my http server side code is in C++.  I have some
fairly large (200+ MB) databases and I need all the speed
that I can get.

Lynn

[toc] | [prev] | [next] | [standalone]

#8018

Goran wrote:

>> "Do you want to use a language that isn't going to be
>> crippled by an evil proprietor?"
> 
> There's lots of languages that don't have an evil proprietor. In fact,
> I am not sure that C# has an evil proprietor (AFAIK, CLR and C# spec
> are ECMA standards). I think, at best you can say that C# has an evil
> __implementor__.

The current version of C# is 4.0, while the last version of C# which has 
been covered by a standardization attempt was C# 2.0, back in 2006.  As C# 
developers tend to develop their software based on the features which are 
provided by their copy of Microsoft Visual Studio instead of what has been 
standardised, I don't believe it is reasonable to assume C# as being 
something other than a proprietary programming language implemented through 
a proprietary software product.  And even when some third-party 
implementation tries to implement some non-standard feature provided only by 
Microsoft through Microsoft's products then we have to deal with patent 
threats.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#7958

On 7/18/2011 9:18 AM, Lynn McGuire wrote:
> Why your next language better be C++:
> http://www.i-programmer.info/professional-programmer/i-programmer/2674-why-your-next-language-better-be-c.html
>

sadly, matters are not this simple.

admittedly, C is my main-used language, although C++ and ASM are also in 
my top 3, probably with my own custom language (BGBScript, presently 
most similar to ActionScript) in 4th place, and Java in 5th place.


>
> "It looks as if the war between C++ and C# is over
> and C++ has won."
>

possibly, both C++ and C# have merits do, and each can be used for 
things which are problematic in the other.

ultimately, although more work may be needed to do some things in C or 
C++, there is a little less of a problem with running into a "glass 
ceiling" as in C# or Java.


> "If I was asked to write an advertising poster for C++
> it would go something like:
>
> "Do you want to write applications that run directly on
> the CPU without interpreters or VMs getting in the way?"
>

VMs in turn have good and bad points.

I wouldn't want to be stuck in a world where I *had* to use a VM as the 
primary/sole development environment, however, VMs still have merits 
which make their use worthwhile in addition to native code.


a recent idea of mine (revived from an older idea of mine from 2009) is 
to use a modified/fudged version of x86 machine code in a VM (the design 
was altered slightly to make it better suited to a VM interpreter/JIT 
and to variable address-word sizes).

a proof-of-concept would be to use it on an ARM-based target.

I already have a plain x86 interpreter (from 2009 or so) which I have 
successfully tested on ARM, however, what I was imagining above would be 
technically different (it would operate much closer to the metal, 
operating in the same address space and with likely sharing data 
structures/... with the native code, whereas the existing interpreter 
uses virtual address spaces and a partially synthesized "OS").

sadly, I have many more important things to do, so may not have time to 
do much with this idea...


note that most of my other stuff is built on other, more specialized, 
bytecode formats (high-level bytecodes, whereas a modified x86 variant 
would be more of a lower-level byte code).


> "Do you want make use of the operating system interfaces
> as if you owned them?"
>

any VM with a competent FFI should allow this, although sadly many HLL 
VMs (including the JVM) have been relatively incompetent at doing this 
"well" (for example, Java tends to require much evil boilerplate, as do 
the majority of existing HLL VMs AFAICT).

.NET does a little better.

in my case, I have managed to largely gloss over this issue (typically, 
relatively little boilerplate is needed). I have wondered though why 
others have not done so, as the problems are not *that* hard, and it is 
not like I have corporate levels of developer resources at-hand.


say, we devide FFIs into levels:

level 1: no real FFI, stuff is hard-coded into or registered with the VM 
or similar and may have to deal with VM internals and/or complex 
interfacing rules;

level 2: one writes boilerplate in C or C++, but the VM can locate the 
functions on its own (for example, JVM with JNI);

level 3: one writes boilerplate or signatures in the HLL, but the VM 
manages the native calls (Java JNA, .NET P/Invoke, ...);

level 4: one uses a tool which reads C or C++ headers and similar and 
spews out the boilerplate (for example, Swig);

level 5: one references the headers, with any needed glue-code being 
generated on-the-fly and behind-the-scenes.

level 6: there is no noticeable seam (code running inside and outside 
the VM is indistinguishable, and cross-language interfaces are entirely 
transparent).


my own VM is presently mostly at around 4.5, where a tool is needed to 
process the C headers, but this was mostly for performance reasons 
(processing the C headers during program startup was relatively 
expensive, and would require keeping them around). however, most 
interface code is dynamically generated (calls to C are automatic, but 
direct calls from C or C++ may require generated stubs).


> "Do you want to use a language that isn't going to be
> crippled by an evil proprietor?"
>
> "Then you need C++"
>

fair enough.

C# is, theoretically standardized, but MS currently holds the only 
really "good" implementation.

Mono is not nearly as good, and is IMO written on some of the most nasty 
code I have probably ever seen (it could use some level of code-cleanup 
and fixing up its overall architecture).

most other implementations are far less feature-complete.


Java is a little better on this front in that it tends to have more 
mature open-source implementations, at the cost of Java itself being a 
"not very impressive" language.


ultimately, I much rather write code mostly in C and C++, and develop my 
own technology for what doesn't work as well in C or C++.

granted, it is probably not like my own VM technology would be winning 
any awards any time soon anyways.


or such...

[toc] | [prev] | [next] | [standalone]

#8017

BGB wrote:

>> "It looks as if the war between C++ and C# is over
>> and C++ has won."
>>
> 
> possibly, both C++ and C# have merits do, and each can be used for
> things which are problematic in the other.
> 
> ultimately, although more work may be needed to do some things in C or
> C++, there is a little less of a problem with running into a "glass
> ceiling" as in C# or Java.

And planned obsolescence.  Let's not forget the ever-present planned 
obsolescence problem associated with using non-standardized, proprietary, 
tightly controlled software development tools.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#8024

On 7/20/2011 5:28 PM, Rui Maciel wrote:
> BGB wrote:
>
>>> "It looks as if the war between C++ and C# is over
>>> and C++ has won."
>>>
>>
>> possibly, both C++ and C# have merits do, and each can be used for
>> things which are problematic in the other.
>>
>> ultimately, although more work may be needed to do some things in C or
>> C++, there is a little less of a problem with running into a "glass
>> ceiling" as in C# or Java.
>
> And planned obsolescence.  Let's not forget the ever-present planned
> obsolescence problem associated with using non-standardized, proprietary,
> tightly controlled software development tools.
>

well, this is (slightly) less of a problem with Java, as developer tools 
are available from several sources:
the Sun/Oracle JDK;
IBM; Eclipse; GCJ; ...

for C#, there are also the Mono and .GNU compilers, but the problem for 
them is if one compares them with the MS tools, they sort of fall on 
their face.

but, yes, if either Oracle or MS pulled official support for the 
languages, it is unclear if the community would remain, or if it would 
all start to erode relatively quickly, given how closely the languages 
are associated with their parent companies.


misc:

in fact, I have my own parser support for for both Java and C#, but if I 
will use them for much is uncertain.

most of my recent activity is focusing on my BGBScript language, which 
uses a different parser and compiler backend, as well as a different AST 
format (BGBScript uses S-Expression/List based ASTs, whereas my C / Java 
/ C# / BS2 frontend uses XML/DOM-based ASTs, and a compiler which 
produces a different IL).

ultimately, I am having to shrink the scope of my projects some, as my 
effort was spread to thin (and most of the parts originally intended for 
my Java and BS2 efforts have since ended up being migrated over to BS).

probably most of my existing Java code will end up ported to BS as well.

or such...

[toc] | [prev] | [next] | [standalone]

#8045

On Thu, 2011-07-21, BGB wrote:
...

> but, yes, if either Oracle or MS pulled official support for the 
> languages, it is unclear if the community would remain, or if it would 
> all start to erode relatively quickly, given how closely the languages 
> are associated with their parent companies.

To be fair, if the GCC people started mistreating g++, I'm not sure I
would stick around. (Not that they are likely to.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#8055

On 7/21/2011 8:53 AM, Jorgen Grahn wrote:
> On Thu, 2011-07-21, BGB wrote:
> ...
>
>> but, yes, if either Oracle or MS pulled official support for the
>> languages, it is unclear if the community would remain, or if it would
>> all start to erode relatively quickly, given how closely the languages
>> are associated with their parent companies.
>
> To be fair, if the GCC people started mistreating g++, I'm not sure I
> would stick around. (Not that they are likely to.)
>

but, GNU doesn't own C++, and even if G++ went away, there are still 
other compilers (both free and commercial).


granted, if not for GCC, maybe most compilers now would have still cost 
money?...


> /Jorgen
>

[toc] | [prev] | [next] | [standalone]

#8085

BGB wrote:

> but, GNU doesn't own C++, and even if G++ went away, there are still
> other compilers (both free and commercial).

Adding to this, the fact that GCC is released under the GPL means that if 
GNU happens to screw with GCC then it is always possible to fork it from 
where it matters and re-streer the project in a better direction.  It 
happened before (EGCS) and, if needed, I bet it can and will happen again.


> granted, if not for GCC, maybe most compilers now would have still cost
> money?...

Indeed.  That's one of the biggest virtues of FLOSS projects: even if you 
don't use them they still represent an economic pressure on those who 
provide proprietary tools that are intended to play the same role, both in 
terms of price and in features offered.  And for the consumer that's always 
a good thing.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#8095

On 7/22/2011 2:21 AM, Rui Maciel wrote:
> BGB wrote:
>
>> but, GNU doesn't own C++, and even if G++ went away, there are still
>> other compilers (both free and commercial).
>
> Adding to this, the fact that GCC is released under the GPL means that if
> GNU happens to screw with GCC then it is always possible to fork it from
> where it matters and re-streer the project in a better direction.  It
> happened before (EGCS) and, if needed, I bet it can and will happen again.
>

yep, it can happen, even despite sometimes the level of pain required to 
coerce gcc to rebuild from source (albeit, then again, I have usually 
done so on Windows-based targets, such as Cygwin, and it may well be 
much easier to get it to rebuild on Linux).


>
>> granted, if not for GCC, maybe most compilers now would have still cost
>> money?...
>
> Indeed.  That's one of the biggest virtues of FLOSS projects: even if you
> don't use them they still represent an economic pressure on those who
> provide proprietary tools that are intended to play the same role, both in
> terms of price and in features offered.  And for the consumer that's always
> a good thing.
>

yep.

I remember back in the early 90s, when most compilers cost money. 
eventually, I found DJGPP, and messed with this for a while (before 
going and spending the next several years mostly in Linux-land).

in the early 2000s, I eventually returned to Windows land, being 
probably in the minority who used Win2k on a home system, rather than Win98.

by this point, IIRC, there was Cygwin and similar, so I carried on 
mostly as before.


meanwhile Linux has gotten better (drivers are much better and tend to 
now actually work), and the GUI has improved much since those days.

or such...

[toc] | [prev] | [next] | [standalone]

#8008

On Jul 18, 5:18 pm, Lynn McGuire <l...@winsim.com> wrote:
> Why your next language better be C++:
>    http://www.i-programmer.info/professional-programmer/i-programmer/267...

> "It looks as if the war between C++ and C# is over
> and C++ has won."

More idiot ramblings.,  There was never a war between C++ and
C#, so there can't be any winner or looser.  The languages
address different problems: C# isn't actually that bad---for
what it is designed to do.  C++ is better, for what it was
designed to do (and that's a lot of things) than any of the
alternatives; most of the other languages one sees today are
designed for much smaller niches, where they're often very good.
(We use C++, C#, Java, Python, and Perl, in different places.
Not to mention GMake, Solution and project files, etc., etc.)

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#8011

James Kanze wrote:
> On Jul 18, 5:18 pm, Lynn McGuire <l...@winsim.com> wrote:
>> Why your next language better be C++:
>>
>> http://www.i-programmer.info/professional-programmer/i-programmer/267...
>
>> "It looks as if the war between C++ and C# is over
>> and C++ has won."
>
> More idiot ramblings.,  There was never a war between C++ and
> C#, so there can't be any winner or looser.

Since I have eval'd C# as a potential replacement for my use of C++ I am 
sure that many others have also. Just because C++ has low-level 
capabilities, that doesn't mean you have to use it that way. If not a 
war, a battle for sure. Idiots are people who think they know everything.

> The languages
> address different problems: C# isn't actually that bad---for
> what it is designed to do.  C++ is better, for what it was
> designed to do (and that's a lot of things) than any of the
> alternatives; most of the other languages one sees today are
> designed for much smaller niches, where they're often very good.
> (We use C++, C#, Java, Python, and Perl, in different places.
> Not to mention GMake, Solution and project files, etc., etc.) 

[toc] | [prev] | [next] | [standalone]

#8037

On Jul 20, 9:52 pm, "JBarleycorn" <jbn...@newsnet.org> wrote:
> James Kanze wrote:
> > On Jul 18, 5:18 pm, Lynn McGuire <l...@winsim.com> wrote:
> >> Why your next language better be C++:

> >>http://www.i-programmer.info/professional-programmer/i-programmer/267...

> >> "It looks as if the war between C++ and C# is over
> >> and C++ has won."

> > More idiot ramblings.,  There was never a war between C++ and
> > C#, so there can't be any winner or looser.

> Since I have eval'd C# as a potential replacement for my use of C++ I am
> sure that many others have also.

There are certainly things that one might have written in C++
some years ago, and that one would perhaps write in Java or C#
today.  But C# isn't really applicable for most of what C++
does.

> Just because C++ has low-level
> capabilities, that doesn't mean you have to use it that way.

It has nothing to do with low level capabilities, and everything
to do with the ability to manage large projects, over multiple
platforms.

> If not a war, a battle for sure.

There was never a battle, because C# never tried to be what C++
is: a portable language for large scale applications.

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#8056

James Kanze wrote:
> On Jul 20, 9:52 pm, "JBarleycorn" <jbn...@newsnet.org> wrote:
>> James Kanze wrote:
>>> On Jul 18, 5:18 pm, Lynn McGuire <l...@winsim.com> wrote:
>>>> Why your next language better be C++:
>
>>>> http://www.i-programmer.info/professional-programmer/i-programmer/267...
>
>>>> "It looks as if the war between C++ and C# is over
>>>> and C++ has won."
>
>>> More idiot ramblings.,  There was never a war between C++ and
>>> C#, so there can't be any winner or looser.
>
>> Since I have eval'd C# as a potential replacement for my use of C++
>> I am sure that many others have also.
>
> There are certainly things that one might have written in C++
> some years ago, and that one would perhaps write in Java or C#
> today.  But C# isn't really applicable for most of what C++
> does.

Oh? So what does "C++ do"? (rhetorical, for you answered that question 
below... stay tuned...).

>
>> Just because C++ has low-level
>> capabilities, that doesn't mean you have to use it that way.
>
> It has nothing to do with low level capabilities, and everything
> to do with the ability to manage large projects, over multiple
> platforms.
>
>> If not a war, a battle for sure.
>
> There was never a battle, because C# never tried to be what C++
> is: a portable language for large scale applications.

At least you marketeers are getting off of that "general purpose 
language" thing now and trying to sell it as still good for some niche. 
Basically, you just said: don't use it unless you have a "large project, 
over multiple platforms"... way to go Mr. C++ Salesman... I sure hope you 
don't work on a commission basis! I wonder how many of these so called 
"large projects, over multiple platforms" wouldn't have cost a boatload 
less if they just would have made sure that the deployment spaces were 
all Microsoft platforms, where they could have been on MS platforms, that 
is.. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web