Quickie Poll -- C vs. C++

On Fri, 27 Aug 2010 11:04:39 -0400, Phil Hobbs
pcdhSpamMeSenseless_at_electrooptical.net> wrote:

Warren wrote:
Phil Hobbs expounded in news:4C76E962.9070508_at_electrooptical.net:

...
What is your _preferred_ programming language for smallish (1000
lines of code) projects? C? C++? Something else? What?
REXX or C++, except when programming microcontrollers.
...
Phil Hobbs
REXX on a MCU would be perverse indeed.

Warren
I don't know--the statically linked executable is about 393k on Windows,
so if you built it for an ARM Cortex M3, say, you could probably slim
it down to below 256k, which is less than half the flash available.

Of course scripting usually needs a bunch of I/O, so it usually won't
make sense without a disk.

I used to really love HP Basic on the HP9816--it had really great
built-in GPIB support, which made instrument control a breeze.

Cheers

Phil Hobbs

I got my introduction to Rocky Mountain BASIC for instrument control
on the HP 9845B, the predecessor to the 9816, in 1978.

On 27 Aug, 20:08, Randy Yates<ya...@ieee.org> wrote:
spop...@speedymail.org (Steve Pope) writes:
Randy Yates<ya...@ieee.org> wrote:

Tim Wescott<t...@seemywebsite.com> writes:

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

C.

Why?

Simpler.

With some familiarization, C++ feels simpler now to me. If it's
code I'm writing myself. If I'm analyzing/applying someone else's
code, all bets are off.

Of course it's subjective, but I don't see how it could possibly be
simpler to have to make decisions on class layout as well as
structuring/organizing functions within a class as opposed to
structuring a small group of functions. Even if you are only using one
class, just carrying around the class baggage is a negative, in my
opinion.

You need to see this from the right angle: A class is a type.
This allows you, the programmer, to cooperate with the
compiler in very powerful ways.

You *might* want to expand the class ito a hierarchy, using
all sorts of inheritance, virtual functions and all kinds of
stuff that add a lot of overhead, but you don't need to.

Once you, the programmer, is free to declare your own
types - classes - you all of a sudden get access to the
most powerful featiures of C++ right now: Templates.
This means that you can use the standard functionality of
the STL merely by ensuring that your custom data type - the
class - has some basic functionality.

As long as you make sure your class has a operator<() function
(and maybe a couple of other detail regarding constructors),
you can immediately use the std::sort functions from the STL.

You need to try it to see the power. Forget about OO. Classes
in C++ today is at least as much about types.

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?

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?

On 27 Aug, 20:08, Randy Yates <ya...@ieee.org> wrote:
spop...@speedymail.org (Steve Pope) writes:
Randy Yates  <ya...@ieee.org> wrote:

Tim Wescott <t...@seemywebsite.com> writes:

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

C.

Why?

Simpler.

With some familiarization, C++ feels simpler now to me.  If it's
code I'm writing myself.  If I'm analyzing/applying someone else's
code, all bets are off.

Of course it's subjective, but I don't see how it could possibly be
simpler to have to make decisions on class layout as well as
structuring/organizing functions within a class as opposed to
structuring a small group of functions. Even if you are only using one
class, just carrying around the class baggage is a negative, in my
opinion.

You need to see this from the right angle: A class is a type.
This allows you, the programmer, to cooperate with the
compiler in very powerful ways.

You *might* want to expand the class ito a hierarchy, using
all sorts of inheritance, virtual functions and all kinds of
stuff that add a lot of overhead, but you don't need to.

Once you, the programmer, is free to declare your own
types - classes - you all of a sudden get access to the
most powerful featiures of C++ right now: Templates.
This means that you can use the standard functionality of
the STL merely by ensuring that your custom data type - the
class - has some basic functionality.

As long as you make sure your class has a operator<() function
(and maybe a couple of other detail regarding constructors),
you can immediately use the std::sort functions from the STL.

You need to try it to see the power. Forget about OO. Classes
in C++ today is at least as much about types.

spop...@speedymail.org (Steve Pope) writes:
Randy Yates  <ya...@ieee.org> wrote:

Tim Wescott <t...@seemywebsite.com> writes:

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

C.

Why?

Simpler.

With some familiarization, C++ feels simpler now to me.  If it's
code I'm writing myself.  If I'm analyzing/applying someone else's
code, all bets are off.

Of course it's subjective, but I don't see how it could possibly be
simpler to have to make decisions on class layout as well as
structuring/organizing functions within a class as opposed to
structuring a small group of functions. Even if you are only using one
class, just carrying around the class baggage is a negative, in my
opinion.

Randy Yates <yates_at_ieee.org> wrote:

Rune Allnor <allnor_at_tele.ntnu.no> writes:

[snip]

I don't disagree with anything you've stated except perhaps the main
point. There are just some projects that don't need the power, and thus
the complexity, of C++. Simpler is better. Always.

But since C is a subset of C++, there's nothing preventing you
from writing just as simple a program in C++.

If you're using some C++ feature that is not in C, you are
doing so for a reason. In a not insignificant number of
cases, the reason is that the C++ feature makes the program
even simpler. (e.g. not having to use function pointers,
having complex number already in the language standard, etc.)

You need to see this from the right angle: A class is a type.
This allows you, the programmer, to cooperate with the
compiler in very powerful ways.

You *might* want to expand the class ito a hierarchy, using
all sorts of inheritance, virtual functions and all kinds of
stuff that add a lot of overhead, but you don't need to.

Once you, the programmer, is free to declare your own
types - classes - you all of a sudden get access to the
most powerful featiures of C++ right now: Templates.
This means that you can use the standard functionality of
the STL merely by ensuring that your custom data type - the
class - has some basic functionality.

As long as you make sure your class has a operator<() function
(and maybe a couple of other detail regarding constructors),
you can immediately use the std::sort functions from the STL.

You need to try it to see the power. Forget about OO. Classes
in C++ today is at least as much about types.

Rune Allnor <allnor_at_tele.ntnu.no> writes:

[snip]

I don't disagree with anything you've stated except perhaps the main
point. There are just some projects that don't need the power, and thus
the complexity, of C++. Simpler is better. Always.

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?

JosephKK wrote:
On Fri, 27 Aug 2010 11:04:39 -0400, Phil Hobbs
pcdhSpamMeSenseless_at_electrooptical.net> wrote:

Warren wrote:
Phil Hobbs expounded in news:4C76E962.9070508_at_electrooptical.net:

...
What is your _preferred_ programming language for smallish (1000
lines of code) projects? C? C++? Something else? What?
REXX or C++, except when programming microcontrollers.
...
Phil Hobbs
REXX on a MCU would be perverse indeed.

Warren
I don't know--the statically linked executable is about 393k on Windows,
so if you built it for an ARM Cortex M3, say, you could probably slim
it down to below 256k, which is less than half the flash available.

Of course scripting usually needs a bunch of I/O, so it usually won't
make sense without a disk.

I used to really love HP Basic on the HP9816--it had really great
built-in GPIB support, which made instrument control a breeze.

Cheers

Phil Hobbs

I got my introduction to Rocky Mountain BASIC for instrument control
on the HP 9845B, the predecessor to the 9816, in 1978.

I even had a FP accelerator board that came with a RMB-compatible
*compiler*. For the time, that one _flew_. IIRC it used some obscure
Intel iapx432 or i860 floating point chip, not a 68881.

Cheers

Phil Hobbs

On Sun, 29 Aug 2010 14:29:02 -0400, Phil Hobbs
pcdhSpamMeSenseless_at_electrooptical.net> wrote:

JosephKK wrote:
On Fri, 27 Aug 2010 11:04:39 -0400, Phil Hobbs
pcdhSpamMeSenseless_at_electrooptical.net> wrote:

Warren wrote:
Phil Hobbs expounded in news:4C76E962.9070508_at_electrooptical.net:

...
What is your _preferred_ programming language for smallish (1000
lines of code) projects? C? C++? Something else? What?
REXX or C++, except when programming microcontrollers.
...
Phil Hobbs
REXX on a MCU would be perverse indeed.

Warren
I don't know--the statically linked executable is about 393k on Windows,
so if you built it for an ARM Cortex M3, say, you could probably slim
it down to below 256k, which is less than half the flash available.

Of course scripting usually needs a bunch of I/O, so it usually won't
make sense without a disk.

I used to really love HP Basic on the HP9816--it had really great
built-in GPIB support, which made instrument control a breeze.

Cheers

Phil Hobbs
I got my introduction to Rocky Mountain BASIC for instrument control
on the HP 9845B, the predecessor to the 9816, in 1978.
I even had a FP accelerator board that came with a RMB-compatible
*compiler*. For the time, that one _flew_. IIRC it used some obscure
Intel iapx432 or i860 floating point chip, not a 68881.

Cheers

Phil Hobbs

Could it have been the Weitek 1167(?)?

On Sun, 29 Aug 2010 14:29:02 -0400, Phil Hobbs
pcdhSpamMeSenseless_at_electrooptical.net> wrote:

JosephKK wrote:
On Fri, 27 Aug 2010 11:04:39 -0400, Phil Hobbs
pcdhSpamMeSenseless_at_electrooptical.net> wrote:

Warren wrote:
Phil Hobbs expounded in news:4C76E962.9070508_at_electrooptical.net:

...
What is your _preferred_ programming language for smallish (1000
lines of code) projects? C? C++? Something else? What?
REXX or C++, except when programming microcontrollers.
...
Phil Hobbs
REXX on a MCU would be perverse indeed.

Warren
I don't know--the statically linked executable is about 393k on Windows,
so if you built it for an ARM Cortex M3, say, you could probably slim
it down to below 256k, which is less than half the flash available.

Of course scripting usually needs a bunch of I/O, so it usually won't
make sense without a disk.

I used to really love HP Basic on the HP9816--it had really great
built-in GPIB support, which made instrument control a breeze.

Cheers

Phil Hobbs
I got my introduction to Rocky Mountain BASIC for instrument control
on the HP 9845B, the predecessor to the 9816, in 1978.
I even had a FP accelerator board that came with a RMB-compatible
*compiler*. For the time, that one _flew_. IIRC it used some obscure
Intel iapx432 or i860 floating point chip, not a 68881.

Cheers

Phil Hobbs

Could it have been the Weitek 1167(?)?