Quickie Poll -- C vs. C++

So, I'm working on a spare-time project that's off the back burner for at least a day. It's a trainer, and I'd _like_ to be able to set it up so that advanced students can do their own programming. Hence, the poll.

So, since anyone who responds to a dippy poll on USENET is obviously

100% representative of the embedded software engineering public, I know that your responses will accurately reflect reality.

If you answer this poll you will _not_ be entered into a contest to win an iPod, or a free smokeless cigarette, or anything else. So do it for the glory, and to advance the state of the species.

Please don't fire up the C vs. C++ flame war -- we all know that Forth is the best language in the world next to Python, so C vs. C++ is really moot anyway.

What is your _preferred_ programming language for smallish (1000 lines of code) projects? C? C++? Something else? What?

Why?

Would you describe yourself as being competent in both C and C++? If only one, which?

What size processor(s) do you most often find yourself using? 8 bit?

16? 32?

What size of memory space do you most often find yourself using? Less than 1kbyte? 1 to 8kbyte? 8 to 64kbyte? More than 64kbyte?

If you had to use someone's library code in your smallish project and knew nothing about it other than the language it's written in, would you be happier knowing it was in C, C++ or some other language?

Are you comfortable reading schematics of digital circuits?

Are you comfortable reading schematics of mixed analog and digital circuits?

If you can't read schematics, can you find your way around a block diagram? Can you understand explanations of circuit behavior given by a sympathetic hardware engineer?

Thanks.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

l.

Neither, I use LabView for simulation or Matlab. For embedded, c I suppose cos there is nothing better at present.

Hardy

l.

I would have to say both. Since I use VC++ to build projects involving PCB, I usually end up with at least one PC/VC++ program.

Visual Studio 5.0, if you consider it a language. Because I have it and it's good enough.

Quick and dirty user interfaces.

Both, but I always stay with the C subset if possible. Just habit.

8 or 32. Nothing in between.

32K to 64K.

C is usually easier to pick up on. But once you are familiar with it, you don't feel much differences between them. I have been using MFC/C+

• libraries without thinking too much. On the micro side, it's almost always C.

Yes.

ts?

Yes.

a

Yes.

Do I get a cookie at least?

For project of such a small size I pick whatever let me finish the job faster, and that only depends on what language I've used for the previous task. (it always takes me two days to switch from C to C++..).

At the moment I would pick C.

I play country and western.. (e.g. I'm fine with C and C++ and a bunch of others as well).

32 Bit. Mostly ARM cores. Worked with other and smaller cores as well, but in my field the 32 bitters have the best price/time to market ratio, so I rarely see anything else these days.

Whatever the task requires plus some extra memory for convenience. If I do video decoding I obviously need a lot more than doing simple stream processing.

The language does not make a difference for me as long as I know that it was written by experienced guys. If I don't know who has written the lib I prefer C. That makes it easier to debug things in case I have to step into the assembly code.

Jep.

Jep.

does not apply..

Cheers, Nils

(snip)

For less than about 10 lines it is awk, otherwise usually C.

Between C++ and Java, I prefer Java.

Because I am used to it by now? About 30 years ago I would have preferred PL/I, but it was too hard to find systems with a PL/I compiler and usually used Fortran. When I started learning about C, it seemed easier to use than Fortran for many problems.

I describe myself as being competent in both, but my C++ code looks a lot like C code. I can read C++ reasonably well, though.

Usually 32, but most often it doesn't matter that much.

I don't try to write memory wasting code. If an algorithm can be implemented as a read/process/write loop in a small amount of memory, that seems the best choice to me.

Most likely, C.

Yes. I can also read them in verilog. Not so easily in VHDL, but maybe.

Yes.

I used to order the service manuals for home electronics that I bought, just in case I would need to work on them.

-- glen

Smooth talker... :-^

win

I have too many offers of this or laptops already.

Usually C

I have a lot of simple blocks (reuse) that makes it quicker to build up. Especially for proofs of principle.

Competent in C, compotent in reading C++, to understand what others have done. Very little of what I do seems to benefit from C++ for a quick turnaround. Example TWO ASIC testers from purchase order to delivery of full package built, cased and documented in under two months, that is me doing everything, as well as other jobs.

Last ten years 16 now more 32bit as even small ARMS are generally cheaper with wider choice of toolchains.

Now comes the killer question FLASH/RAM or Both?

Flash 8k to 512K, RAM from 1K to 2MB depending on type of application from simple control to video data processing.

I would be happier knowing it worked and had sufficient coverage for functionality to be useable. Efficiency also matters, not some library made by a PC for everything which can just have more RAM and larger processor to cope with bad design.

Yes

Most

I am usually the sympathetic hardware engineer to other programmers and tend to document interface hardware and/or software (or comms protocol).

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

If its low level DSP or driver code C.

For high level user space code, Haskell or Ocaml.

C is good for low level code.

For high level code I demand garbage collection, guaranteed safe string handling and strict static (ie compil time) type checking.

I'm highly compentant at C and reasonably compentant with C++. While I personally would never choose to use C++ I actually end up doing quite a lot in my day job. Fortunately, my usage of Haskell and Ocaml in my day job is growing. We basically have a rule for new code; if its low level code then use C and if its high level code, use Haskell or Ocaml.

32 and 64 bit.

512k or more. Basically embedded Linux stuff.

C. C code can be wrapped and accessed from high level langugages like Python, Ocaml and Haskell much more easily than C++ code.

Very. Can even design digital circuits if you want me to.

Yes. Can probably design as well, but is been a couple of years.

Cheers, Erik (mainly responding to be an outlier).

--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

For typical small PC projects: Perl, C, Bourne shell For embedded projects: C, assembly

For small PC projects like reformatting data, doing regex match and replace is easier in Perl than C, and Perl's associative arrays are easy to use.

Both, but prefer C to C++.

Back in the day, used 6-bit IBM 1620 a couple of years, and IBM 1130 and

1800 briefly; 12-bit PDP-8 a lot (wrote time sharing and process control), 16-bit PDP-11 a lot (and other 16-bit - DG Nova, Honeywell DDP-516), the occasional 24-bit Harris/Datacraft, some 36-bit machines (IBM 7044 and 7094, GE/Honeywell 645, Univac 1110), 48-bit CDC 3600 (wrote a CDC 6500 emulator on it, also wrote some assembly that unfortunately used a few instructions the system engineers had removed the circuitry of), 60-bit CDC 6500 (has 2 60-bit 6400-style CPU's and 10 12-bit PP's, vs the 6600's 1 faster central processor and 10 peripheral processors), Cyber 173.

Now, mostly using 8-bit micros and 64-bit PC's.

Less than 1KB on micros, 20KB - 2000KB program sizes on PC

If you mean include some code, I'd prefer C, Perl, Java, Python to C++. If you mean include compiled binaries, the programming language seems less important than the quality of documentation describing the programming interface and the methods or algorithms. Actually, that probably applies to source code packages as well.

Yes

Mostly

A what?

--
jiw

Oberon-07.

Excellent detection of errors before they lead to obscure secondary effects at runtime.

C - 10 years experience.

Only 32-bit.

8 to 64 kbyte.

1. Oberon-07
2. C
3. Assembler

Yes.

Yes.

Regards, Chris Burrows CFB Software Astrobe: ARM Oberon-07 Development System

l.

Ah.

Huh?

Right...

1) Matlab if I can - the leatherman tool of programming. Can do everything, if nothing particularly well. 2) C++. Once you get into it (which might take you decades, I know), it just *works*. Simple things are done in simple ways. 3) C. Because it avoids certain non-standardized technical issues with C++.

C++, because I seldom find need for C these days.

32 bit, approaching 64 bit and multi-cores with caution.

GBytes.

I'd prefer it to be C, because then the pros and cons of interfacing would be known. Linking to a C++ library is difficult, since one needs to untangle name mangling issues. As I understand it, name mangling is the main reason why C++ libraries are issued on a per compiler / linker combo basis.

With C you can issue libraries on a per HW/OS combo basis.

Used to be. Now not so much.

ts?

Used to be. Now not so much.

Can hardly find my way around the block...

Never had the oportunity to find out.

Rune

Scheme (racket), Matlab, Python, C, in that order. Depends on what the project is trying to achieve, and in what context.

Small projects are mostly quickie or exploratory projects, so garbage collection, high-level abstraction and safety are important levers to getting finished quickly. Racket and matlab can do (simple) GUI code portably, which is often helpful. If low-level is necessary, C is almost always the right answer.

Yes.

32 and 64, with side-orders of 16 and 24.

Amusingly, the projects with the most source code tend to use the least runtime memory, in my experience. Back-of-the envelope scheme and matlab scripts use many megabytes. Multi-thousand line C programs might use a handful of K.

C, Fortran or assembler. C++ is usually unusable from anything other than C++, for linkage and run-time support reasons. If the library is available in source, then that widens the possibilities significantly.

Yes.

Yes.

Probably.

Cheers,

--
Andrew

C with maybe some assembler, currently mostly gcc's asm statements.

Yes, and a bunch of other languages. I started in the 1960's with IBM 1620 SPS and Fortran II.

During the years, 8 to 64 bits. The current preferred order is 32 and

8 bits (ARM, AVR).

Of your list, 8 to 64 kiB for small projects.

C, but I strongly would like to have sources, too.

Yes.

Yes, even plain analog.

In most small projects, I have been the hardware engineer, too.

--

Tauno Voipio, MSEE (and OH2UG)
tauno voipio (at) iki fi

l.

100% * sqrt(-1)

To make up for all the damage caused by listening to stuff on iPods?

I once sold a design where the only software tool for it was in Forth.

Basic or C. C maps well onto reasonable assembly languages (it's been called a PDP-11 macro assembler), so it's easier to debug whatever the compiler spits out. Basic, if I don't care about any performance or reuse issues, or if I want to rewrite my Chipmunk Basic interpreter to provide better language support the problem at hand. Maybe Perl if I'm hacking up text files.

I've done a lot more C and Objective C lately, and thus mostly forgotten whatever C++ I used to code in.

32 bit, and whatever you call past and current x86 ISA cruft. Several 8-bitter many decades ago.

Yes. From 512 nibbles up to worrying about HD swap partition size even with GB's of "real" memory.

C. Less obscure syntax abuse possible. Less compiler, linker, and language lawyer issues to go wrong.

Used to debug prototypes which were wire-wrapped from many dozens of D size schematic sheets. The ones drawn by humans were far more readable (but not always) than the stuff spit out by, say, Verilog translation tools.

ts?

Only with simpler analog circuits. Say 1 or 2 vacuum tubes (metal/glass thermionic FETs), or a few submicron CMOS MOSFETs, and not too much Black Forest magic.

Welcome.

IMHO. YMMV.

-- rhn A.T nicholson d.0.t C-o-M

C++ if Python is not available or not suited for the job.

I prefer C++ to C because of the possibilities of C++ which C cannot offer:

- C++ is object oriented

- the size of code to write is smaller (templates, STL)

- the compiler is more strict

- use of constructors reduces number of errors (e.g. failures due to use of uninitialized variables)

- use of destructores reduces number of errors (e.g. memory leaks)

- the STL offers a lot of well tested functionality

- templates allow policy based design which can be very helpful when writing code which must run on more than one platform or which should be testable outside its native environment

Yes.

More than 64 kByte (usually I don't do smallish projects).

I'd be a little happier if the library would offer classes and templates, which makes it easier to adapt the libraries functionality to my personal needs - hence C++ or any other object oriented language.

Yes.

Yes.

bye Andreas

--
Andreas Hünnebeck | email: acmh@gmx.de
----- privat ---- | www  : http://www.huennebeck-online.de
Fax/Anrufbeantworter: 0721/151-284301
GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc
PGP-Key: http://www.huennebeck-online.de/public_keys/pgp_andreas.asc

In light of the above, I'll offer comments that I think are more in line with "what I would (like to) suggest for you" instead of *my* particular practices...

You've not explained what your project is so I can't determine how suitable it would be for my suggestions (following). But, can I suggest you look at Inferno? Assuming you can support it on your target... (read on)

Inferno is very compact. C-like (same folks that brought you C were behind it) with some amusing/interesting twists.

User interfaces are easy to create (the GUI is Tk based so not quite as pretty as twiddling with raw bitmaps but powerful in its own right).

Does its own GC so lots of operations are "easy" (like String classes in C++).

Inherently supports multitasking.

Has language primitives for IPC.

Open source (for everything!)

(I won't prepare a laundry list... if this looks interesting, go chase down the details)

One of the *biggest* wins (again, not knowing what you are potentially applying it against) is that you can "seemlessly" develop multiprocessor/distributed systems. Resources on any host running inferno can be exported to any *other* host (based on credentials, etc.). In the sort of environment I *envision* you working, this would allow, for example, users to have a PC running *hosted* Inferno (runs as an application under Windows, Slowaris, Irix, Linux, *BSD, etc. -- even runs

*in* an IE browser!) connected to their "target" and use the display, keyboard, etc. of the PC *as*if* it was directly part of their target (whatever that may be). I.e., instead of gluing a box onto a PC to provide a user interface, bulk storage, etc., you glue the *PC* onto the other box!

(I am not explaining this very elegantly, sorry. Read the docs for examples, etc.)

I think in a teaching environment, this can be a real win as it lets these "devices" (that you are presumabling creating) be extended -- even to talk to each *other*! It leads more towards "limitless possibilities" (to be cliche).

[there are many downsides, too. But, I think you can avoid those for your intended use]

I think the problem you are likely to find with a library is that you will have to either build it for a *specific* compiler or will have to offer it in source form (no idea where you stand on that issue).

HTH,

--don

C - but you better know C++

C is more compact and easy to understand in small progs

Both

8 for embedded.

8-64kB

C

Yes

Yes

I hope so

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.blogtalkradio.com/onetribe - Occult Talk Show

code) projects? C? C++?

C using TCC, what a great little compiler, all my tools are now built using this, no more 500Mb installs.

Speed of writing an testing

one, which? No only C, my main projects cant take the C++ overhead

All 3

1kbyte? 1 to 8kbyte? 8 to 64kbyte? More than 64kbyte? Depends on project, PICs 256 bytes, HD IPTV, 128Mb

nothing about it other than the language it's written

Not really

Yes

Yes

Can you understand

N/A

Joolz

--
--------------------------------- --- -- -
Posted with NewsLeecher v4.0 Beta 20
Web @ http://www.newsleecher.com/?usenet
------------------- ----- ---- -- -

C for embedded systems, python for PC's, servers, etc.

For a small program on an embedded system, you are typically looking for compact and efficient code. With C it is easy to get exactly what you expect.

On PC's, development time is typically more important that code size, memory usage or processing time. Python gives you a lot of power with ease, it has a pleasant syntax, and it handles the low-level stuff like memory management.

Mostly C, with just occasional C++.

Mostly 8-bit and 32-bit.

On 8-bit devices, mostly under 32 K. On 32-bit devices, typically 128K to a few MB.

C would generally make it easier to use in more systems.

I'm also comfortable making the schematics and doing the pcb design.

Yes, as long as the analogue parts are not too complicated. If there are more than three transistors in a row my eyes glaze over.

Yes

Somewhere between assembly and C. Assembly is compact and easy to understand (if dry to read and write).

If you insist on only C vs. C++, then use the asm directive. ;)

C.

8

32k

Yech, assembly. A library written in anything else is just asking for bloat...piled on top of bloat.

Yes

Yes

I can also write them ;-)

Tim

--
Deep Friar: a very philosophical monk.
Website: http://webpages.charter.net/dawill/tmoranwms