Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #18817
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: validity of ... reasons for preferring C over C++ |
| Date | 2014-10-19 10:43 +0300 |
| Organization | Tidorum Ltd |
| Message-ID | <cah8chFoed1U1@mid.individual.net> (permalink) |
| References | (3 earlier) <m1qmvf$1d1$1@dont-email.me> <7xmw8vca32.fsf@ruckus.brouhaha.com> <m1qruv$39e$1@dont-email.me> <cad15aFlqc0U1@mid.individual.net> <m1s06p$5k2$1@dont-email.me> |
On 14-10-18 00:03 , David Brown wrote:
> On 17/10/14 19:15, Niklas Holsti wrote:
>> On 14-10-17 13:44 , David Brown wrote:
>>> On 17/10/14 11:35, Paul Rubin wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> I disagree, in the embedded world. In PC programming, I agree - very
>>>>> often you are better with a language like Python than with C or C++.
>>>>
>>>> I have to think that even in MCU programming there have to be better
>>>> alternatives to C or C++. Ada seems like a possibility except that the
>>>> toolchains are either obscure or very expensive. There have been
>>>> some C
>>>> dialects like Cyclone that were clever but never got traction. And I
>>>> guess there are some specialty EDSL's like Atom that aren't so good for
>>>> general purpose development. Forth is interesting but it's from a
>>>> different world, and still unsafe though with fewer traps than C.
>>>>
>>>
>>> In theory, one could do much better than C or C++ - but not in practice.
>>> For some systems, Ada is a possible choice. But while Ada is "safer"
>>> than C in some ways, it has its own problems
>>
>> Care to list a few of those? Just to have a good debate? Been a while...
>
> My experience with Ada is rather limited, so you might end up teaching
> me rather than getting a good debate. But of course others will no
> doubt join in.
Let the flames roar! :-)
However, I will focus all my fire on C. I don't know enough about C++ to
debate its merits.
> An obvious (but highly subjective) irritation with Ada is the verbosity
> of the language -
You may be surprised by the comparisons later in this post.
> lots of things need repeated,
Really? If you mean the repetition of "if" in the construct "if" .. "end
if" and the similar repetitions of "loop", "case", and "record" in "end
loop", "end case", "end record", I believe many programmers find them
quite useful, compared to the multiply overloaded meanings of "}" in C.
They help an Ada compiler give sensible error messages when some "end"
is omitted by mistake.
The only places where you repeat things in Ada, and you do not need to
repeat in C, that I can think of now, happen when you want to define the
internal codes used for enumeration values or the bit-fields used for
structs ("records" in Ada). In C you can specify those without repeating
the name of the enumeration literal, or the name of the struct field; in
Ada those are repeated, because the "representation clause" is a
separate syntactic unit.
C:
typedef enum {red = 4, blue = 6, green = 9} color_t;
Ada:
type color_t is (red, blue, green);
for color_t use (red => 4, blue => 6, green => 9);
To reduce repetition, the second Ada line can be written as
for color_t use (4, 6, 9);
but that loses the close connection between the name and the
corresponding value, and is therefore seldom used.
> and many of the
> constructs are more wordy than necessary. Using words rather than
> symbols is not necessarily a bad thing, within limits - C++ arguably
> relies too much on symbols, as anyone trying to read a lambda function
> will know. But sometimes Ada reads as though you are chatting to the
> computer rather than programming.
The languages certainly have a different textual appearance. But I will
stick my neck out and argue that for all but small toy programs, Ada is
*less* verbose than C.
How should we measure verbosity? By the number of non-blank characters
in the source-code file, or by the number of syntactical tokens? I think
both measures are relevant.
If we measure by syntactical tokens, for comparable language constructs
there is usually little difference between Ada and C, and in some cases
the Ada form is shorter. Let's look at some common examples, assuming
that in each case the length of the user-chosen identifiers are the same
in Ada and in C (I will argue later below that Ada identifiers should in
general be *shorter* than C identifiers, assuming equivalent naming
conventions).
The C forms below follow the usual recommendations for always using {}
in control structures and "break" in switch cases. In both Ada and C I
insert more spaces than usual, around separators, to make it easier to
count tokens.
Preparing to use another module
C: # include "sorting.h"
Ada: with Sorting ;
Same number of tokens. Ada is 7 characters shorter.
Typeless number definition
C: # define NUM_FROOS 55
Ada: Num_Froos : constant := 55 ;
C is shorter by 2 tokens and 5 characters.
Typed constant definition
C: const float x = 33.4f ;
Ada: x : constant float := 33.4 ;
C is shorter by 1 token and 5 characters.
Variable declaration
C: float x ;
Ada: x : float ;
C is one character and token shorter.
Type declaration (type naming)
C: typedef float voltage_t ;
Ada: subtype voltage_t is float ;
C is one token and 2 characters shorter.
Assignment statement
C: varname = expression ;
Ada: varname := expression ;
Same number of tokens; one character less in C.
Assignment to a variable through a pointer
C: * varname = expression ;
Ada: varname . all := expression ;
C is one token and 4 characters shorter.
Assignment to a field of a structure through a pointer to the structure
C: varname -> field = expression ;
Ada. varname . field := expression ;
Same number of tokens and characters in C and Ada.
Conditional statement
C:
if ( condition ) {
statements1
} else {
statements2
}
Ada:
if condition then
statements1
else
statements2
end if ;
Ada is shorter by two tokens (if we consider "end if" as
two tokens) but longer by 4 characters, mainly because
of the full-length words in "then" and "end if".
Counted loop from 1 to N
C:
for ( int i = 1 ; i <= N ; i ++ ) {
statements
}
Ada:
for i in 1 .. N loop
statements
end loop ;
Ada is shorter by 6 tokens, but has the same number of
characters as C because of the full-length words in
"loop" and "end loop".
The Ada and C forms are not exactly equivalent. In Ada,
the loop counter "i" automatically inherits the type of N;
in C, that is the programmer's responsibility. In C, the
incrementation of "i" might overflow or wrap around,
causing undefined behaviour or making the loop never
ending; in Ada, the loop is sure to end at i = N, even
if i+1 would overflow or wrap around.
While loop
C:
while ( condition ) {
statements
}
Ada:
while condition loop
statements
end loop ;
Same number of tokens in Ada and C, but Ada has 8
more characters because of the full-length words in
"loop" and "end loop".
Conditional exit from loop
C: if ( condition ) break ;
Ada: exit when condition ;
Ada is shorter by 2 tokens and 1 character.
Switch-case with 2 cases and a default
C:
switch ( expr ) {
case 0 : statements
break ;
case 1 : statements
break ;
default : statements
}
Ada:
case expr is
when 0 => statements
when 1 => statements
when others => statements
end case ;
Ada is shorter by 3 tokens and 2 characters.
Defining a structure/record type
C:
typedef struct {
float x , y , z ;
} triple_t ;
Ada:
type triple_t is record
x , y , z : float ;
end record ;
C 2 tokens and 7 characters shorter, mainly
because of the full words "record" and "end"
in the Ada form.
Procedure (void function) declaration
C: void foo ( float x , float * y ) ;
Ada: procedure foo ( x : float ; y : out float ) ;
C is 2 tokens (the two colons in the formal parameter
list) and 9 characters shorter.
The C and Ada forms are not exactly equivalent, because
"float * y" in the C form means pass by address,
while "y : out float" in Ada means no value is passed
in, and a value is passed out by copy. To make the Ada
form exactly the same as C, replace the "out" by
"aliased in out", or define a pointer type float_ptr
and write "y : in float_ptr".
For this last example, note that a reference to an output parameter,
within a function or procedure, is generally shorter in Ada than in C,
because in C the parameter is a pointer and therefore one must use the
"*" or "->" forms, while in Ada an "out" parameter is not seen as a
pointer and does not need the corresponding ".all" notation, even if the
compiler chooses to pass the parameter by reference.
I could go on, but I believe the conclusion so far is clear: measured by
number of tokens, sometimes the C form is shorter, sometimes the Ada
form is shorter. In this collection of examples, the difference was
largest for the counted loop, where Ada was shorter by 6 tokens.
Measured by number of non-blank characters, C is usually shorter, but
the difference comes from the English keywords in Ada, where C instead
uses special characters. For me, it is faster to type the English
keywords, partly because on my Finnish keyboard the brackets {} require
the Alt Graph key (and a careful glance at the topmost key row to avoid
typing the adjacent () or [] instead).
But, to conclude my argument, IMO the clincher in the verbosity
comparison is the name-space issue. Ignoring comments, most of the text
of a program consists of user-defined identifiers of constants, types,
variables, functions, procedures. Many of these identifiers must be
globally visible, for example the identifiers of the types,
enumerations, and functions/procedures which a client module needs to
see in other to call another module.
Because C lacks a module/namespace construct, in larger C programs one
must usually extend these identifiers with module-specific prefixes to
avoid accidental clashes of identifiers defined in different modules.
For example, the function "display" defined in module "channels" may be
called channels_display, or chan_display, or ch_display, depending on
the degree of abbreviation desired.
Unfortunately, these prefixes must then be used in every occurrence of
the identifier, even within the defining module itself.
In contrast, an identifier "display" defined within an Ada package
"channels" can be used as such within the package itself (and in all its
child packages). Only in other packages is it necessary to write
channels.display, or to open direct visibility to the channels package
by saying "use channels".
This effect should, on average, make identifiers shorter in an Ada
program than in the corresponding C program, assuming equivalent design
standards for naming (for example, abbreviation rules) and a program of
at least medium size.
Another factor that can shorten Ada identifiers is the possibility to
overload function and procedure names (including enumeration literals)
by type, while in C overloading is not possible (in C++ it is, but I am
incompetent to talk about C++).
(A long argument, perhaps, but *my* verbosity was not at issue :-))
> Ada programming encourages the use of user-defined types for all sorts
> of things. You are not supposed to hold a "day" in an "int" or
> "uint8_t", you are supposed to define "type Day_type is range 1 .. 31;".
That is entirely a matter of convention. It can hardly called a problem
of the Ada language.
> Sometimes this sort of thing can make code clearer, but it can also
> make it harder to see what is really going on in the program. When you
> see a type like "uint8_t" or "int", you know exactly what it means -
> when the type is "Day_type", you have to think about it much more, and
> perhaps look up the definition.
This is a good example of the main difference in the concept of "type"
in Ada and in C, or at least an example of how the meaning of "type" is
different for typical programmers in the two languages.
For Ada, and for the typical Ada programmer, the type of an object
describes the meaning of the object in the application world, in the
problem statement.
For C, and for the typical C programmer, the type of an object describes
the internal machine representation of the object.
"uint8_t" describes the machine representation but says nothing of the
logical role or meaning of the value, in the problem and the
application. In C, that is typically the role of the object's
identifier, such as in the declaration
uint8_t day_in_month;
"Day_type" describes the logical role, but (as such) does not say
anything about the machine representation. This means that the object
identifier can more easily be used to make the role of the particular
object more precise, as in:
Day_type pay_day;
In fact I believe that C practice is moving towards the Ada use of
types. More and more, C programmers are advised to define type names such as
typedef uint8_t day_t;
However, the rationale usually given for this advice is to help program
maintenance in case the type must be changed to something else, which is
true but trivial from the conceptual point of view.
Of course, the above does not mean that Ada programmers ignore internal
representation issues, just that the two concerns are separated. If the
Ada programmer wants to say that a Day_type uses 8 bits, she adds a Size
aspect to the type declaration:
type Day_type is range 1 .. 31 with Size => 8;
> And because type conversions have to be explicit in Ada, you need
> to add lots of them when using these types.
Well, some programmers prefer to avoid automatic conversions.
In Ada, you can control whether conversions are automatic or must be
explicit, by using subtypes in the former case and types in the latter case.
If you declare Day_type not as a type, but as a subtype:
subtype Day_type is Integer range 1 .. 31;
you are free to write computations that mix Integer and Day_type, you
can assign a Day_type variable to an Integer variable, and can assign an
Integer expression to a Day_type variable (with, in the last case, an
automatic check that the value is in the range 1 .. 31). However, you
can still use Day_type'First and Day_type'Last to ask about the range,
and you can loop over all days by
for D in Day_type loop ... end loop;
> C and C++ do more of this automatically, giving clearer code.
The code can be shorter, yes. Whether is is clearer is subjective, of
course.
> The run-time overhead in Ada can be an issue - the larger run-time
> library, the run-time checks, exceptions (I don't like them in C++ either).
Ada compilers these days give you a choice of run-times, from
zero-run-time to the full standard, with the corresponding restrictions
in the Ada code you can execute on that run-time. For the GNAT compiler,
the run-time is treated as a normal library at link-time, so any
run-time function that is not used can be eliminated from the executable.
And *of course* the run-time checks can be turned off globally or
locally, by compiler options or specific pragmas.
Benchmarks vary, but if one writes Ada code that is functionally
equivalent to C code (does not compute with dynamically sized objects,
does not use tasking, does not use exceptions, disables run-time checks,
etc.) one can expect to have close to the same machine code as for the C
code. Note that this does not mean "writing C in Ada", because one still
has all the compile-time goodies of Ada: module system, stronger typing,
object and type attributes, and so on. And the ability to test the
program with run-time checks *on*.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-17 00:00 +0100
Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 07:38 +0200
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 09:27 +0200
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 09:29 +0100
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 11:19 +0200
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 02:35 -0700
Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 11:43 +0200
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:12 +0100
Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 13:25 +0200
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:40 +0100
Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 20:12 +0300
Re: validity of ... reasons for preferring C over C++ Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-10-17 10:18 -0700
Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-17 21:53 +0300
Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 22:59 +0300
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 13:23 -0700
Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-18 17:46 +0200
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-18 11:45 -0700
Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 01:51 +0300
Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-19 12:43 +0200
Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-18 17:44 +0200
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 12:44 +0200
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:13 +0100
Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 20:15 +0300
Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 19:18 +0200
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 23:03 +0200
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 14:11 -0700
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-18 20:14 +0200
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 22:15 +0100
Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 23:07 +0000
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-19 00:36 +0100
Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 10:55 +0300
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-19 09:33 +0100
Re: validity of ... reasons for preferring C over C++ "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2014-10-20 15:04 +0200
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-19 13:32 +0200
Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 23:44 +0200
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-18 20:10 +0200
Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-18 23:38 +0300
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 22:21 +0100
Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 10:43 +0300
Re: validity of ... reasons for preferring C over C++ Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-19 09:38 +0000
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-19 14:07 +0200
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 19:47 -0700
Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-20 06:55 +0300
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 21:02 -0700
Re: validity of ... reasons for preferring C over C++ britt.snodgrass@gmail.com - 2014-10-20 04:02 -0700
Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-20 18:51 +0300
C and Ada, was: Re: validity of ... reasons for preferring C over C++ Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-21 00:30 +0000
Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-20 20:49 -0500
Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-21 09:11 +0200
Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-21 08:34 -0500
Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 21:23 +0300
Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-20 03:39 +0100
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:07 +0100
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:06 +0100
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 14:12 +0200
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 13:16 +0100
Re: validity of ... reasons for preferring C over C++ Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2014-10-17 14:13 +0200
Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 14:35 +0200
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 13:59 +0100
Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 17:06 +0200
Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-17 19:41 +0300
Re: validity of ... reasons for preferring C over C++ Clifford Heath <no.spam@please.net> - 2014-10-18 10:14 +1100
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 00:36 +0100
Re: validity of ... reasons for preferring C over C++ Clifford Heath <no.spam@please.net> - 2014-10-20 09:45 +1100
Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-18 08:52 +0300
Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 09:41 +0100
Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-20 09:46 -0700
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-20 16:26 -0700
Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-20 16:42 -0700
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-20 17:24 -0700
Re: validity of ... reasons for preferring C over C++ John Devereux <john@devereux.me.uk> - 2014-10-21 19:09 +0100
Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-24 16:38 +0200
Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:12 -0700
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-21 16:39 -0700
Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-22 01:43 +0100
Re: validity of ... reasons for preferring C over C++ Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-22 20:00 +0200
Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-22 18:49 +0200
Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:15 -0700
Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-22 04:45 -0700
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-22 09:30 -0700
Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-23 12:25 -0700
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-23 15:17 -0700
Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-23 22:59 +0000
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-23 16:02 -0700
Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-27 08:30 -0700
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-27 09:00 -0700
Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-27 09:24 -0700
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-27 09:30 -0700
Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-28 00:52 +0000
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-28 08:45 +0100
Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-28 02:00 -0700
Re: validity of ... reasons for preferring C over C++ George Neuner <gneuner2@comcast.net> - 2014-10-30 11:56 -0400
Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-28 19:59 +0200
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-28 23:46 +0100
Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-29 07:27 +0200
Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-29 10:11 +0100
Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-29 10:21 -0500
Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-29 20:15 +0000
Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-30 11:33 -0500
Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-30 19:07 +0000
Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-30 16:19 -0500
Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-31 07:32 +0000
Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 08:45 +0000
Re: validity of ... reasons for preferring C over C++ Reinhardt Behm <rbehm@hushmail.com> - 2014-10-31 18:15 +0800
Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 22:03 +0000
Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-31 09:53 -0500
Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 22:17 +0000
Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-31 17:50 -0500
Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-28 04:37 +0000
Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-21 19:12 +0200
Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:06 -0700
Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-22 19:06 +0200
csiph-web