Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > is C++ worth it ?

Reply
Thread Tools

is C++ worth it ?

 
 
Jorgen Grahn
Guest
Posts: n/a
 
      08-09-2012
On Thu, 2012-08-09, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> On 7 Aug 2012 18:19:56 GMT
> Jorgen Grahn <(E-Mail Removed)> wrote:
>>On Tue, 2012-08-07, (E-Mail Removed) wrote:
>>> On Mon, 6 Aug 2012 10:45:33 -0700 (PDT)
>>> Noah Roberts <(E-Mail Removed)> wrote:
>>>>I think the problem comes when people pay too much attention to the C part =
>>>>of C++. Raw arrays and such are mostly a thing of the past in C++. There'=
>>>
>>> Not if you do any low level or network programming.

>>
>>OK, but there's no excuse not to isolate and encapsulate arrays so
>>they are largely invisible. If you want potential buffer overflows
>>everywhere, you might as well use C.

>
> If you know the exact size of the data you're dealing with , eg a packet
> header, then you won't get any buffer overflows because you'll only ever
> read in that amount.


The key here is "/if/ you know". Usually you don't.

>>> For quite competetive read not as fast as.

>>
>>Given the beginner's mistake you did with std::set in another current

>
> What beginners mistake? I was quite well aware of the built in find() in
> set, I'd just never used the standard version on it and was surprised it
> wasn't optimised.


The "beginner's mistake" was to assume algorithms like std::find can
and will do anything clever. Perhaps you're right: perhaps it's not
obvious that that won't happen. It was obvious to /me/, but I can't
recall how I learned it.

>>thread[0], your opinion doesn't have much weight yet. Work with the
>>library for a year or so, and you may change your mind.

>
> Thanks, I've been using it for 10 years or so. Go take your patronising
> bullshit somewhere else.


I was not trying to be patronizing. I got the firm impression that
you hadn't used the standard library a lot.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
Mark
Guest
Posts: n/a
 
      08-13-2012
On Fri, 03 Aug 2012 12:49:15 -0500, BGB <(E-Mail Removed)> wrote:

>I once saw an episode of Nova talking about a plane that crashed.
>basically, something went wrong (wind speed sensor froze, started
>returning 0 wind-speed, causing control software to crash), the plane
>sent a crash dump back to the manufacturer over radio, and then the
>plane promptly crashed into the ocean.


I am horrified that this software was ever certified. I used to work
on safety critical software for the aerospace industry. All software
should be tested to see how it copes with sensor failure. Generally
such systems will have multiple sensors and redundant
software/hardware that can still work even if significant parts stop
working.
--
(\__/) M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?

 
Reply With Quote
 
 
 
 
unnamed
Guest
Posts: n/a
 
      08-19-2012
Use the right tool for the job. For certain use cases, although considerably less as time goes on, you need the low level features of C, C++, or Ada. JITs are getting so good, though, that for typical 32-bit programming, using C++ amounts to a micro-optimization. High level constructs like virtuals or exceptions are often better handled by a JIT.

That said, if you're a developer working on the JIT, you're probably going to be using C++. The language will always remain dominant for infrastructural software. Another good area for C++ is embedded platforms. It's not a good idea to run a JIT on a smartphone.

I'm sorry to say that "modern C++" is still not as safe as managed languages. Ref counting, for instance, is not as safe as GC. Programming is about tradeoffs. Would you take a 10% to 30% performance hit for an easier, safer development environment?
 
Reply With Quote
 
Tobias Müller
Guest
Posts: n/a
 
      08-19-2012
unnamed <(E-Mail Removed)> wrote:
> Use the right tool for the job. For certain use cases, although
> considerably less as time goes on, you need the low level features of C,
> C++, or Ada. JITs are getting so good, though, that for typical 32-bit
> programming, using C++ amounts to a micro-optimization. High level
> constructs like virtuals or exceptions are often better handled by a JIT.


Our products written in C++ are almost always faster than those of our
competitors (often written in Java) often by a factor of 100 or similar.
There are probably also other causes, but the language is surely one of
them.

> That said, if you're a developer working on the JIT, you're probably
> going to be using C++. The language will always remain dominant for
> infrastructural software. Another good area for C++ is embedded
> platforms. It's not a good idea to run a JIT on a smartphone.
>
> I'm sorry to say that "modern C++" is still not as safe as managed
> languages. Ref counting, for instance, is not as safe as GC. Programming
> is about tradeoffs. Would you take a 10% to 30% performance hit for an
> easier, safer development environment?


We have almost never any problems with memory leaks, they are rather easy
to detect.
Actually from what I hear from Java programmers, they have more problems
with GC (GC pauses, nondeterminism) than we have with refcounting/manual
management. And those problems are not as easy to solve as memory leaks.

IMO, the biggest advantage of Java or .Net are not GC or managed code, but
the huge standard libraries.

Tobi
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-19-2012
On Sunday, August 19, 2012 2:32:50 AM UTC+1, unnamed wrote:

> I'm sorry to say that "modern C++" is still not as safe as managed languages.
> Ref counting, for instance, is not as safe as GC.


Not using dynamic allocation at all can be safer than GC. And while GC
can allow a higher degree of safety than other systems which manipulate
pointers, the code I've seen in Java and C# doesn't implement this
higher degree of safety (and you can use GC in C++, if you need it).

In the end, it depends on what you mean by safety. If you're handling
web reqests on an open server, and you're worried about viruses, then GC
is a must, even in C++; you simply cannot run the risk of a block of
memory being reused as long as there are pointers around which refer to
it in it's previous use. (Of course, this safety is really only useful
if you actively mark the memory as invalid, and crash the code if it is
accessed.) For a lot of applications, however, C++ is far simpler and
safer than Java or C#. (Overloaded operators and value semantics are
almost necessary for anything mathematical, for example. You just
cannot do mathematical software in Java.)

--
James Kanze
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-19-2012
On Sunday, August 19, 2012 6:54:56 AM UTC+1, Tobias Mller wrote:
> unnamed <(E-Mail Removed)> wrote:
>
> > Use the right tool for the job. For certain use cases, although

>
> > considerably less as time goes on, you need the low level features of C,

>
> > C++, or Ada. JITs are getting so good, though, that for typical 32-bit

>
> > programming, using C++ amounts to a micro-optimization. High level

>
> > constructs like virtuals or exceptions are often better handled by a JIT.

>
>
>
> Our products written in C++ are almost always faster than those of our
>
> competitors (often written in Java) often by a factor of 100 or similar.
>
> There are probably also other causes, but the language is surely one of
>
> them.
>
>
>
> > That said, if you're a developer working on the JIT, you're probably

>
> > going to be using C++. The language will always remain dominant for

>
> > infrastructural software. Another good area for C++ is embedded

>
> > platforms. It's not a good idea to run a JIT on a smartphone.

>
> >

>
> > I'm sorry to say that "modern C++" is still not as safe as managed

>
> > languages. Ref counting, for instance, is not as safe as GC. Programming

>
> > is about tradeoffs. Would you take a 10% to 30% performance hit for an

>
> > easier, safer development environment?

>
>
>
> We have almost never any problems with memory leaks, they are rather easy
>
> to detect.
>
> Actually from what I hear from Java programmers, they have more problems
>
> with GC (GC pauses, nondeterminism) than we have with refcounting/manual
>
> management. And those problems are not as easy to solve as memory leaks.
>
>
>
> IMO, the biggest advantage of Java or .Net are not GC or managed code, but
>
> the huge standard libraries.
>
>
>
> Tobi


 
Reply With Quote
 
ootiib@hot.ee
Guest
Posts: n/a
 
      08-19-2012
On Sunday, August 19, 2012 4:32:50 AM UTC+3, unnamed wrote:
> Use the right tool for the job. For certain use cases, although considerably less as time goes on, you need the low level features of C, C++, or Ada.. JITs are getting so good, though, that for typical 32-bit programming, using C++ amounts to a micro-optimization. High level constructs like virtuals or exceptions are often better handled by a JIT.


So the JIT handles your bugs well? So what? Even embedded debuggers are quite good these days. When there are no bugs then it still loses 2 - 5 times of efficiency to well-written C++. It does not stop there. When the C++ guyuses GPU for processing too then it is often orders of magnitude ahead.

>
> That said, if you're a developer working on the JIT, you're probably going to be using C++. The language will always remain dominant for infrastructural software. Another good area for C++ is embedded platforms. It's not a good idea to run a JIT on a smartphone.


For certain limited use cases scripts run fast enough. Even in embedded environment. So on these cases there are no need to burden with overhead from JIT compiler or the like just a lightweight script interpreter is fine. That makes most powerful is code compiled to native instructions + script.

>
> I'm sorry to say that "modern C++" is still not as safe as managed languages. Ref counting, for instance, is not as safe as GC. Programming is abouttradeoffs. Would you take a 10% to 30% performance hit for an easier, safer development environment?


As a developer or as end user? End user does not care about your development environment at all. Why he should care how soft is your chair is or how large coffee mug you got?

The end user notices good performance. 10%-30% is the modern wishful thinking trend. In practice it is 200%-500%. Sure i can write trash Assembler that loses to Python but in reality best competes with best and rest of the **** is dead.

So what mattes is how fast it starts, how fast it runs, how responsive it is. It is end user's (life)time that the good performance saves. Native compiled languages like C++ or C or Objective C are the winners. Nothing to do.It is quite narrow market where performance does not matter. Like the freeFlash puzzle games for kids, (but Flash is again script not JIT AFAIK).

For some panicked marketroids (they can impact the minds of your bosses) itis time-to-market that matters everything, despite (unless it is some sortof short-term trend software) you can take the market over later by betterperforming product anyway.

To please such marketroids it is still better to make a part of software using scripts (like Python) and rewrite them in version 2.0. Yes the scripts might reveal things to your competitors but also the JIT stuff is so easy to reverse engineer that no much difference there.

If something is worth writing at all it is worth writing it in C++. If you really need GC, stack tracing or what not then just link a library that does it. There simply are no tricks or technologies that you can not use from C++ if you want that so much.
 
Reply With Quote
 
ootiib@hot.ee
Guest
Posts: n/a
 
      08-19-2012
On Sunday, August 19, 2012 2:08:15 PM UTC+3, James Kanze wrote:
> On Sunday, August 19, 2012 2:32:50 AM UTC+1, unnamed wrote:
>
>
>
> > I'm sorry to say that "modern C++" is still not as safe as managed languages.

>
> > Ref counting, for instance, is not as safe as GC.

>
>
>
> Not using dynamic allocation at all can be safer than GC. And while GC
>
> can allow a higher degree of safety than other systems which manipulate
>
> pointers, the code I've seen in Java and C# doesn't implement this
>
> higher degree of safety (and you can use GC in C++, if you need it).


Sometimes a jump in efficiency and safety can be gained by turning off
dynamic de-allocation and by multiprocessing. No special idioms needed like with GC versus ref-counting, just turn operator delete() or free() into NOP.

Have a separate process for highly demanding complex calculation, clone it for
processing, pipe out the results and terminate for freeing all the resources at
once. The highest peak of memory that such a process needs does not usually
differ much if you free up memory on the way or not but it will be lot quicker
if you don't.

Further advantage is that it is easier to measure the memory that is needed by
a separate process. So it is simpler to learn to predict resource usage that
way and so to turn off dynamic allocation as well and it also allows to refuse
to take too demanding tasks before even starting those.

Such trick also scales very well since such processes can be later spread all
over the farm when the problems grow and a single PC stops satisfying. I am not
sure what Java or C# can offer as competition there, not too familiar with
those.
 
Reply With Quote
 
Melzzzzz
Guest
Posts: n/a
 
      08-19-2012
On Sun, 19 Aug 2012 13:47:52 -0700 (PDT)
(E-Mail Removed) wrote:

> On Sunday, August 19, 2012 2:08:15 PM UTC+3, James Kanze wrote:
> > On Sunday, August 19, 2012 2:32:50 AM UTC+1, unnamed wrote:
> >
> >
> >
> > > I'm sorry to say that "modern C++" is still not as safe as
> > > managed languages.

> >
> > > Ref counting, for instance, is not as safe as GC.

> >
> >
> >
> > Not using dynamic allocation at all can be safer than GC. And
> > while GC
> >
> > can allow a higher degree of safety than other systems which
> > manipulate
> >
> > pointers, the code I've seen in Java and C# doesn't implement this
> >
> > higher degree of safety (and you can use GC in C++, if you need it).

>
> Sometimes a jump in efficiency and safety can be gained by turning off
> dynamic de-allocation and by multiprocessing. No special idioms
> needed like with GC versus ref-counting, just turn operator delete()
> or free() into NOP.
>

That would be possible only if memory cannot be exhausted


 
Reply With Quote
 
Melzzzzz
Guest
Posts: n/a
 
      08-19-2012
On Sun, 19 Aug 2012 04:08:15 -0700 (PDT)
James Kanze <(E-Mail Removed)> wrote:

> On Sunday, August 19, 2012 2:32:50 AM UTC+1, unnamed wrote:
>
> > I'm sorry to say that "modern C++" is still not as safe as managed
> > languages. Ref counting, for instance, is not as safe as GC.

>
> Not using dynamic allocation at all can be safer than GC. And while
> GC can allow a higher degree of safety than other systems which
> manipulate pointers, the code I've seen in Java and C# doesn't
> implement this higher degree of safety (and you can use GC in C++, if
> you need it).
>
> In the end, it depends on what you mean by safety. If you're handling
> web reqests on an open server, and you're worried about viruses, then
> GC is a must, even in C++;


Why?

you simply cannot run the risk of a block
> of memory being reused as long as there are pointers around which
> refer to it in it's previous use.


Aha. You mean deallocating block of memory while still being used.
I think that's a bug in software. Does not happens usually...


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Worth buying modem router? =?Utf-8?B?QmFkQW5nbGVy?= Wireless Networking 2 07-05-2005 02:33 PM
How much is Bill worth right now? Me_and_you ASP .Net 18 02-12-2005 03:21 AM
Market worth? Nickolas Microsoft Certification 2 12-10-2004 12:06 AM
Is it worth it? Russ McKenna ASP .Net 5 12-06-2003 06:47 PM
MCSE Cert. Is it still worth it? Dominique Feteau Microsoft Certification 3 11-05-2003 08:43 PM



Advertisments