OT:C/C++ Opinion Poll

Hi,

A little OFF-TOPIC this is for the Brazilians that are in the Brazil, mainly the near to S=E3o Paulo that are C/C++ developers here:

Please, would be important if you answered the opinion poll about C/C++ in wiki

formatting link
mainly to first question.

Also there is poll about embedded systems and this is in [PT-BR]

++thx;

Ed

Reply to
Ed
Loading thread data ...

I'm sorry, that poll is written in Brazillian, being sesquilingual* I can't understand it.

C++ is:

- The single most useful thing ever to come from a guy named Byorn.

- A failed fix to a failed language.

- A terrible way to ruin a beautiful language.

- A marvelously thoughtful extension of a hideously limited language.

- Fine for desktop developers, but a bane to embedded systems.

- A wonderful language for embedded software development, even in moderately resource constrained environments.

- Too complex.

- Too simplistic.

- Too wild and woolly for serious programming.

- Too heavily typed and constrained for serious programming.

- Too much like assembly.

- Too removed from assembly.

- Just use Ada.

- Just use Java.

- Just use Python**.

- Just use C.

- Just use Fourth.

- I can develop that faster in assembly.

I'm sure I've missed some aspect of C++ that's been discussed here, but I suspect that I've caught all the major points.

  • I only half speak German.

** really -- I've had this suggested to me as a serious notion.

--
Tim Wescott
Control systems and communications consulting
 Click to see the full signature
Reply to
Tim Wescott

Yet C++ is still the best language out there. Al the rest are just bad C++ clones (Java and C# for example).

To my horrid amazement C is still too widely used and has resulted in a world where security bugs are rampant. None of this would be the case if C++ was used and used properly.

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Jim Relsh

Excellent answer, Tim! There are couple more aspects:

  • No language can replace the experience, the intelligence, the common sense and the good taste
  • No matter what you do, you will be screwed

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

That's kind of a weird statement. If security bugs are your concern, then C++ has exactly the same kind of limitations as C. "Used properly", both can make secure code. Other languages do have fewer ways to create certain classes of security flaw, but errors can be expressed in any language.

Cheers,

Andrew.

Reply to
Andrew Reilly

Smart approaches (like C++, preemptive multitasking, etc.) help preventing a lot of dumb mistakes. Actually, they exchange many small and dumb mistakes for the lesser amount of intricate bugs which are difficult to find.

VLV

Reply to
Vladimir Vassilevsky

"Jim Relsh" schreef in bericht news:474da617$0$26115$ snipped-for-privacy@free.teranews.com...

This all depends on the skills of the programmer. C++ can hide a lot of things that C programmers should be (more) concerned with. But as you say yourself: "if used properly". Hiding details in an embedded environment can be a total disaster (examples: unhandled exceptions, bloated memory usage).

Embedded programmers should focus on a solid method of programming. Software construction is far more important than semantics (= the actual programming language).

There is no "better" programming language. Just know what you are doing (and why)!!

Frank

PS. To stir up the discussion: C requires that you know what you are doing!

Reply to
FD

That sums it up very nicely.

LOL.

--
Regards,
Richard.
 Click to see the full signature
Reply to
FreeRTOS.org

Having spent some time in both hardware, firmware and desktop I concur.

Agreed. Spot on.

So does c++, epsecially so if you are doing embedded stuff.

I have seem some really good embedded c++, and I have seen some really bad c, likewise asm. I have my opinions where c should cross over to c++, but its exactly that, and opinion.

BTW, i need to do some maintenace on an embedded device in the very near future. The firmware is in c++. In this circumstance it was a poor choice, and was simpy used because a few engineers wanted to try their hand at c++. It should have been written in C, but it wasn't. I see a lot of this, and perhaps this is where c++ gets a bad name with firmware engineers.

Reply to
The Real Andy

I seldom have seen "good C++", meaning: I could reuse someone elses objects blindly. Most C++ programmers nowadays have not done the "real thing" before (assembly and C) and therefore lack practical knowledge of structured programming. I believe this is a requirement for embedded programming, where there are a lot of globals around (variables, registers, IO ports) and asynchonous code (interrupts, threads) that need to run 24/7.

For me personally C++ has a bad name because of exceptions and garbage collection. Lots of people love this, I hate it. These features allow programmers to focus more on the coding itself and less on the proper handling of unforeseen situations and object usage. Unfortunately in embedded programming there are no "unforeseen situations", there must always be a solution (remember: 24/7 code). Objects should be destructed by the programmer to release locks on globals (avoiding deadlocks) and stay in control of memory usage (which is often limited).

Frank

Reply to
FD

I might start using C++ if it acquired garbage collection... Not for embedded stuff, though.

--
Pertti
Reply to
Pertti Kellomäki

For my part, I prefer C code written by C++ programmers. You should understand the object model, and then eschew the compiler. Also good is C code written by Scheme programmers.

Worst is C++ code written by VB programmers or LISP written by Fortran programmers.

--
	mac the naïf
Reply to
Alex Colvin

C++ doesn't have garbage collection, unless you use a 3rd party library.

--
Jyrki Saarinen
http://koti.welho.com/jsaari88/
Reply to
Jyrki Saarinen

A language with pointers can't have garbage collection. C++ without pointers and with garbage collection is called Java.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

The Boehm garbage collector works just fine with C++, unless you're particularly weird, and hide pointers in files or encrypting them. It's conservative, which mean that it won't collect every last scrap, but it is used in some pretty hard-core applications.

Clifford Heath.

Reply to
Clifford Heath

Well c++ itself does not have garbage collection. You do get full control of memory management, but like C, one can allocate memory and not release it. The mistake can be made in both. Now when you say 'often limited', the usually indicates one of my preferences for using c as opposed to c++, but once again, this is my opinion.

As for 24/7 code, I have plenty of c++ code with uptime of years. Its how you code, not what you use.

Reply to
The Real Andy

Right. That was my very first arguments.

Frank

Reply to
FD

That is simply not true.

GC in general with C or C++:

formatting link

The GC gurus page:

formatting link

"Performance of the nonincremental collector is typically competitive with malloc/free implementations. Both space and time overhead are likely to be only slightly higher for programs written for malloc/free (see Detlefs, Dosser and Zorn's Memory Allocation Costs in Large C and C++ Programs.) For programs allocating primarily very small objects, the collector may be faster; for programs allocating primarily large objects it will be slower. If the collector is used in a multithreaded environment and configured for thread-local allocation, it may in some cases significantly outperform malloc/free allocation in time."

(for the people think that GC implies a problem in performance; there are even JVM implementations for hard real-time systems, where there is a guaranteed upper bound for GC CPU usage, though these seem to be implementations done in the research, at least last time when I looked)

--
Jyrki Saarinen
http://koti.welho.com/jsaari88/
Reply to
Jyrki Saarinen

I think you meant, "a language with pointers that can be diddled can't have garbage collection". For instance, Ada has pointers (called access types), and many Ada implementations have supported garbage collection.

Even when the pointers can be diddled (e.g., C, C++), it's still possible to the Boehm-Demers-Weiser conservative garbage collector or equivalent.

Reply to
Eric Smith

This paints a rather optimistic picture. In reality pointer chasing many megabytes of memory is what costs you - no matter what GC you choose, GC performance is directly proportional to the amount of allocated memory. The only case where garbage collection can be competitive is when you give it enough memory so that the collector never needs to run...

For a real-world example of the overhead of GC look at GCC. It got twice as slow when they moved from region based allocation to GC. Furthermore, despite all the claims, most collectors don't reduce fragmentation at all or improve locality. Only compacting collectors do, but they are even slower.

Wilco

Reply to
Wilco Dijkstra

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.