Richard Cobbe wrote:
> C:
> int x;
>
> x = "foo";
>
> You'll get a type error here at compile time, for obvious reasons.
> Question: how can this be a type error if only variables have types?
> You need to realize that "foo" has type (const) char * before you can
> determine that you can
Lo, on Sunday, January 13, Erik Steffl did write:
> type is a propert of variable.
Not exclusively. Two counter-examples, one in C, and one in Scheme.
C:
int x;
x = "foo";
You'll get a type error here at compile time, for obvious reasons.
Question: how can this be a type error if on
dman wrote:
>
> On Sun, Jan 06, 2002 at 04:51:14PM -0800, Erik Steffl wrote:
> | dman wrote:
> | >
> | > On Sat, Jan 05, 2002 at 09:38:01PM -0800, Erik Steffl wrote:
> | > | dman wrote:
> | > ...
> | > | > In C/C++ there is an invariant on strings ("char*", which is
> | > | > essentially equivalen
On Mon, Jan 07, 2002 at 03:56:45PM -0600, Richard Cobbe wrote:
| Lo, on Monday, January 7, dman did write:
| > Have you read "The Hobbit"? Do you remember what Treebeard told Bilbo
| > about his name?
|
| (Actually it was _The Two Towers_, and it was Merry & Pippin, not Bilbo,
Oops. It's been
"Eric G. Miller" wrote:
...
> > merely a subset of them (0<=i > programming languages don't provide a mechanism to express this so
> > programmers approximate it with types that describe supersets of the
> > set they want. (this explains why I dislike java and its type system
> > so much; for C it
On Mon, 7 Jan 2002 11:27:10 -0500, dman <[EMAIL PROTECTED]> wrote:
[snip]
> When you say that, in C, something is an 'int', is it possible to have
> a bit pattern there that is not a valid 'int'? No. 'int' describes
> the set of all valid values and every possible bit pattern you can
> stick the
Lo, on Monday, January 7, dman did write:
> I've just come up with a good description of what a 'type' is :
> A "type" is the set of all valid values.
*DING*DING*DING*DING*DING*DING*
Got it in one. Types are sets of values. That's all. C, C++, and Java
provide a fairly limited language fo
On Sun, Jan 06, 2002 at 04:51:14PM -0800, Erik Steffl wrote:
| dman wrote:
| >
| > On Sat, Jan 05, 2002 at 09:38:01PM -0800, Erik Steffl wrote:
| > | dman wrote:
| > ...
| > | > In C/C++ there is an invariant on strings ("char*", which is
| > | > essentially equivalent to "char[]") that they end w
On Sun, 6 Jan 2002 16:48:31 -0500 (EST), William T Wilson <[EMAIL PROTECTED]>
wrote:
> On Sat, 5 Jan 2002, Eric G.Miller wrote:
>
> > is one of the reasons pointers to char are so common. However, there
> > is a little trick that's guaranteed to always work:
> >
> > struct foo {
> > size_
On Sun, Jan 06, 2002 at 04:48:24PM -0800, Eric G. Miller wrote:
| On Sun, 6 Jan 2002 16:48:31 -0500 (EST), William T Wilson <[EMAIL PROTECTED]>
wrote:
|
| > On Sat, 5 Jan 2002, Eric G.Miller wrote:
| >
| > > is one of the reasons pointers to char are so common. However, there
| > > is a little
dman wrote:
>
> On Sat, Jan 05, 2002 at 09:38:01PM -0800, Erik Steffl wrote:
> | dman wrote:
> ...
> | > In C/C++ there is an invariant on strings ("char*", which is
> | > essentially equivalent to "char[]") that they end with a NUL byte.
> |
> | no, that's not true.
>
> It is true. A type is
On Sun, 6 Jan 2002 16:48:31 -0500 (EST), William T Wilson <[EMAIL PROTECTED]>
wrote:
> On Sat, 5 Jan 2002, Eric G.Miller wrote:
>
> > is one of the reasons pointers to char are so common. However, there
> > is a little trick that's guaranteed to always work:
> >
> > struct foo {
> > size_
On Sat, 5 Jan 2002, Eric G.Miller wrote:
> is one of the reasons pointers to char are so common. However, there
> is a little trick that's guaranteed to always work:
>
> struct foo {
> size_t length;
> char str[1];
> };
>
> ...
>
> struct foo * str_to_foo(char *a)
> {
> size_t
On Sat, Jan 05, 2002 at 09:38:01PM -0800, Erik Steffl wrote:
| dman wrote:
...
| > In C/C++ there is an invariant on strings ("char*", which is
| > essentially equivalent to "char[]") that they end with a NUL byte.
|
| no, that's not true.
It is true. A type is more than the name a compiler gi
Lo, on Friday, January 4, David Jardine did write:
> On Thu, Jan 03, 2002 at 05:34:00PM -0600, Richard Cobbe wrote:
> >
> > Yes, it *is* types. Remember the definition of type-safety:
> >
> > If an expression E is determined at compile time to have type T,
> > then evaluating E will hav
Lo, on Friday, January 4, David Teague did write:
> On Thu, 3 Jan 2002, Richard Cobbe wrote:
>
> > Not in the general case, no.
> >
> > std::string *s = new string("foo");
> > std::string *s2 = s;
> >
> > delete s;
> >
> > If we assume a variant of C++ that extends delete to set it
dman wrote:
>
> On Thu, Jan 03, 2002 at 09:39:09PM -0600, Gary Turner wrote:
> | On Thu, 03 Jan 2002 17:34:00 -0600 (CST), Richard Cobbe wrote:
...
> | >char str[] = { 'b', 'a', 'd', ' ', 's', 't', 'r', 'i', 'n', 'g' };
> | >// note the lack of a terminating '\0'!
> | >cout << str;
...
On Fri, 04 Jan 2002 14:28:46 -0500, dman wrote:
>On Thu, Jan 03, 2002 at 09:39:09PM -0600, Gary Turner wrote:
>| On Thu, 03 Jan 2002 17:34:00 -0600 (CST), Richard Cobbe wrote:
>| >
>| >Lo, on Thursday, January 3, Erik Steffl did write:
>| >
>| >> what's the difference? the point is you can assign
On Fri, Jan 04, 2002 at 11:50:04PM -0600, Gary Turner wrote:
| On Fri, 04 Jan 2002 14:28:46 -0500, dman wrote:
| >On Thu, Jan 03, 2002 at 09:39:09PM -0600, Gary Turner wrote:
| >| On Thu, 03 Jan 2002 17:34:00 -0600 (CST), Richard Cobbe wrote:
| >| >Lo, on Thursday, January 3, Erik Steffl did write:
On Fri, 04 Jan 2002 23:50:04 -0600, Gary Turner <[EMAIL PROTECTED]> wrote:
[snip]
> >He did define a string. In C++ there are 3 ways of defining a string
> >(in C there are 2). There is "char[]", "char*" and "std::string".
> Isn't 'char*' redundant, since an array var is a pointer by definition?
On Fri, 4 Jan 2002 20:17:08 -0500, dman <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 03, 2002 at 08:43:55AM -0800, Craig Dickson wrote:
> | dman wrote:
> |
> | > However the thing to remember about macros is that they are textual
> | > substituation. It is effectively the same thing as writing the
>
dman wrote:
>
> On Thu, Jan 03, 2002 at 09:10:56PM -0800, Erik Steffl wrote:
> | Richard Cobbe wrote:
> | >
> | > Lo, on Thursday, January 3, Erik Steffl did write:
> | >
> | > > what's the difference? the point is you can assign almost anything to
> | > > anything, and yet there is no segfault -
Gary Turner wrote:
>
> On Fri, 04 Jan 2002 14:28:46 -0500, dman wrote:
>
> >On Thu, Jan 03, 2002 at 09:39:09PM -0600, Gary Turner wrote:
> >| On Thu, 03 Jan 2002 17:34:00 -0600 (CST), Richard Cobbe wrote:
> >| >
> >| >Lo, on Thursday, January 3, Erik Steffl did write:
> >| >
> >| >> what's the di
On Thu, Jan 03, 2002 at 08:43:55AM -0800, Craig Dickson wrote:
| dman wrote:
|
| > However the thing to remember about macros is that they are textual
| > substituation. It is effectively the same thing as writing the
| > assignment yourself.
|
| So?
The point there was that it isn't a feature
On Thu, Jan 03, 2002 at 09:10:56PM -0800, Erik Steffl wrote:
| Richard Cobbe wrote:
| >
| > Lo, on Thursday, January 3, Erik Steffl did write:
| >
| > > what's the difference? the point is you can assign almost anything to
| > > anything, and yet there is no segfault - i.e. the strength of types
On Fri, 04 Jan 2002 14:28:46 -0500, dman wrote:
>On Thu, Jan 03, 2002 at 09:39:09PM -0600, Gary Turner wrote:
>| On Thu, 03 Jan 2002 17:34:00 -0600 (CST), Richard Cobbe wrote:
>| >
>| >Lo, on Thursday, January 3, Erik Steffl did write:
>| >
>| >> what's the difference? the point is you can assign
On Thu, Jan 03, 2002 at 09:39:09PM -0600, Gary Turner wrote:
| On Thu, 03 Jan 2002 17:34:00 -0600 (CST), Richard Cobbe wrote:
| >
| >Lo, on Thursday, January 3, Erik Steffl did write:
| >
| >> what's the difference? the point is you can assign almost anything to
| >> anything, and yet there is no s
On Thu, 3 Jan 2002, Richard Cobbe wrote:
> Lo, on Thursday, January 3, William T Wilson did write:
>
> Not in the general case, no.
>
> std::string *s = new string("foo");
> std::string *s2 = s;
>
> delete s;
>
> If we assume a variant of C++ that extends delete to set its argument
On Thu, Jan 03, 2002 at 05:34:00PM -0600, Richard Cobbe wrote:
>
> Yes, it *is* types. Remember the definition of type-safety:
>
> If an expression E is determined at compile time to have type T,
> then evaluating E will have one of two results:
>
> 1) The value of E is a valid
Richard Cobbe wrote:
>
> Lo, on Thursday, January 3, Erik Steffl did write:
>
> > what's the difference? the point is you can assign almost anything to
> > anything, and yet there is no segfault - i.e. the strength of types has
> > nothing (sort of) to do with segfaults... the resource allocation
On Thu, 03 Jan 2002 17:34:00 -0600 (CST), Richard Cobbe wrote:
>
>Lo, on Thursday, January 3, Erik Steffl did write:
>
>> what's the difference? the point is you can assign almost anything to
>> anything, and yet there is no segfault - i.e. the strength of types has
>> nothing (sort of) to do with
Phil Beder wrote:
...
> I wish I was a good enough programmer to contribute to this great project.
> Maybe one day when I understand more about Linux I could write a more user
> friendly help interface with clear syntax, option, and flag usage.
by that time you'll swear by man pages! :-))
On Thu, Jan 03, 2002, Phil Beder wrote:
> Thank you!!
>
> The diversity of point of view and depth of knowledge of the participants
> of this group is truly phenomenal. A simple question (in essence "where
> should I start") yielded me not only an interesting variety of response to
> that questio
Thank you!!
The diversity of point of view and depth of knowledge of the participants
of this group is truly phenomenal. A simple question (in essence "where
should I start") yielded me not only an interesting variety of response to
that question, but a road map, complete with pitfalls and milest
Lo, on Thursday, January 3, Erik Steffl did write:
> what's the difference? the point is you can assign almost anything to
> anything, and yet there is no segfault - i.e. the strength of types has
> nothing (sort of) to do with segfaults... the resource allocation is
> crucial...
Type safety (plu
Richard Cobbe wrote:
>
> Lo, on Thursday, January 3, William T Wilson did write:
>
> > On Wed, 2 Jan 2002, Richard Cobbe wrote:
> >
> > > I'll agree that the two are related; in fact, I'd go so far as to say
> > > that if a language supports dynamic memory allocation and type-safety,
> > > it *ha
Lo, on Thursday, January 3, William T Wilson did write:
> On Wed, 2 Jan 2002, Richard Cobbe wrote:
>
> > I'll agree that the two are related; in fact, I'd go so far as to say
> > that if a language supports dynamic memory allocation and type-safety,
> > it *has* to have some sort of automatic sto
dman wrote:
> However the thing to remember about macros is that they are textual
> substituation. It is effectively the same thing as writing the
> assignment yourself.
So? You could say the same of C++ templates, but that doesn't mean they
aren't useful. You can't even use the "code bloat" arg
On Thu, Jan 03, 2002 at 07:04:38AM -0800, Eric G. Miller wrote:
| On Thu, 3 Jan 2002 09:31:16 -0500, dman <[EMAIL PROTECTED]> wrote:
| > However the thing to remember about macros is that they are textual
| > substituation. It is effectively the same thing as writing the
| > assignment yourself.
On Thu, 3 Jan 2002 09:31:16 -0500, dman <[EMAIL PROTECTED]> wrote:
[snip]
> | > If you wrote a wrapper around free() that took a pointer to a pointer
> | > you _could_ then assign NULL to the second pointer, but that, of
> | > course, assumes that inside free() you have a valid pointer to
> | > de
On Thu, Jan 03, 2002 at 05:01:50AM -0800, Eric G. Miller wrote:
| On Thu, 3 Jan 2002 07:22:59 -0500, dman <[EMAIL PROTECTED]> wrote:
|
| > On Thu, Jan 03, 2002 at 12:19:25AM -0500, William T Wilson wrote:
| > | On Wed, 2 Jan 2002, Richard Cobbe wrote:
| > |
| > | > I'll agree that the two are rel
On Thu, 3 Jan 2002 07:22:59 -0500, dman <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 03, 2002 at 12:19:25AM -0500, William T Wilson wrote:
> | On Wed, 2 Jan 2002, Richard Cobbe wrote:
> |
> | > I'll agree that the two are related; in fact, I'd go so far as to say
> | > that if a language supports dyn
On Thu, Jan 03, 2002 at 12:19:25AM -0500, William T Wilson wrote:
| On Wed, 2 Jan 2002, Richard Cobbe wrote:
|
| > I'll agree that the two are related; in fact, I'd go so far as to say
| > that if a language supports dynamic memory allocation and type-safety,
| > it *has* to have some sort of auto
On Thu, Jan 03, 2002 at 01:33:29AM -0500, Michael P. Soulier wrote:
| On 02/01/02 Richard Cobbe did speaketh:
|
| > > > Perl does have strong types, but they don't really correspond to the
| > > > types that most people are used to thinking of. Perl's types are
|
| Personally, I wouldn't call Pe
Richard Cobbe wrote:
>
> Lo, on Wednesday, January 2, Erik Steffl did write:
>
> > Richard Cobbe wrote:
> > >
> > > Lo, on Monday, December 31, Erik Steffl did write:
> > >
> > > Perl does have strong types, but they don't really correspond to the
> > > types that most people are used to thinking
On 02/01/02 Richard Cobbe did speaketh:
> > > Perl does have strong types, but they don't really correspond to the
> > > types that most people are used to thinking of. Perl's types are
Personally, I wouldn't call Perl strongly-typed at all. I code all day
in Perl, and I love it, but I also know
On Wed, 2 Jan 2002, Richard Cobbe wrote:
> I'll agree that the two are related; in fact, I'd go so far as to say
> that if a language supports dynamic memory allocation and type-safety,
> it *has* to have some sort of automatic storage management system.
I don't think that necessarily follows; a
Lo, on Wednesday, January 2, Erik Steffl did write:
> Richard Cobbe wrote:
> >
> > Lo, on Monday, December 31, Erik Steffl did write:
> >
> > Perl does have strong types, but they don't really correspond to the
> > types that most people are used to thinking of. Perl's types are
> >
> > *
Lo, on Wednesday, January 2, Ben Collins did write:
> Just because in C it can cause a segfault doesn't mean the other
> languages are any better.
No, it doesn't. However, IMNSHO, the fact that C and C++ have many
*more* undefined constructs that other languages does mean that the
other language
On Tue, Jan 01, 2002 at 09:44:17PM -0600, Richard Cobbe wrote:
>
> Lo, on Tuesday, January 1, Ben Collins did write:
>
> > On Tue, Jan 01, 2002 at 10:12:09AM -0600, Richard Cobbe wrote:
> > >
> > > > Secondly, you can make this mistake with any language that allows
> > > > references (perl, pyth
on Wed, 02 Jan 2002 12:43:56AM -0800, Erik Steffl insinuated:
> Richard Cobbe wrote:
> >
> > Perl does have strong types, but they don't really correspond to the
> > types that most people are used to thinking of. Perl's types are
> >
> > * scalars (no real distinction between strings, numbe
William T Wilson wrote:
>
> On Mon, 31 Dec 2001, Erik Steffl wrote:
>
> > consider perl which doesn't have strong types but it's quite
> > impossible to make it segfault and C++ on the other side which is
>
> That is true but it doesn't mean that type safety won't prevent it
> also. Consider
Richard Cobbe wrote:
>
> Lo, on Monday, December 31, Erik Steffl did write:
>
> > "Eric G. Miller" wrote:
> > >
> > > On Mon, 31 Dec 2001 13:46:15 -0800, Erik Steffl <[EMAIL PROTECTED]> ...
> > > > it's the resource allocation that's important, not types. garbage
> > > > collectors are generally
On Tue, Jan 01, 2002 at 09:39:18PM -0600, Richard Cobbe wrote:
| Lo, on Tuesday, January 1, dman did write:
|
| > On Tue, Jan 01, 2002 at 10:34:25AM -0600, Richard Cobbe wrote:
| > | Lo, on Tuesday, January 1, dman did write:
| > |
| > | > The strength and staticness of typing are two independent
Lo, on Tuesday, January 1, Ben Collins did write:
> On Tue, Jan 01, 2002 at 10:12:09AM -0600, Richard Cobbe wrote:
> >
> > > Secondly, you can make this mistake with any language that allows
> > > references (perl, python, and java all allow it). Just replace free()
> > > with some other assignme
Lo, on Tuesday, January 1, dman did write:
> On Tue, Jan 01, 2002 at 10:34:25AM -0600, Richard Cobbe wrote:
> | Lo, on Tuesday, January 1, dman did write:
> |
> | > The strength and staticness of typing are two independent properties.
> |
> | Also agreed.
>
> Cool, I'm glad you know this stuff
William, Richard, and all:
Stroustrup has said that if you find you have to cast, (much) your
design is flawed.
--David Teague
On Tue, 1 Jan 2002, William T Wilson wrote:
> On Tue, 1 Jan 2002, Richard Cobbe wrote:
>
> > > | Casting you can't really get away from nor do you really need to. I
On Tue, 1 Jan 2002, Richard Cobbe wrote:
> > | Casting you can't really get away from nor do you really need to. In fact
> > | the more strongly typed the language is, the more casting you have to do.
> >
> > This statement is incorrect.
>
> Agreed.
I suppose I will agree as well, I was not me
On Tue, Jan 01, 2002 at 10:12:09AM -0600, Richard Cobbe wrote:
>
> > Secondly, you can make this mistake with any language that allows
> > references (perl, python, and java all allow it). Just replace free()
> > with some other assignment that changes what a is, and ultimately you
> > change b, w
On Tue, Jan 01, 2002 at 10:34:25AM -0600, Richard Cobbe wrote:
| Lo, on Tuesday, January 1, dman did write:
|
| > On Mon, Dec 31, 2001 at 09:27:36PM -0500, William T Wilson wrote:
| >
| > | Casting you can't really get away from nor do you really need to. In fact
| > | the more strongly typed t
Lo, on Tuesday, January 1, dman did write:
> On Mon, Dec 31, 2001 at 09:27:36PM -0500, William T Wilson wrote:
>
> | Casting you can't really get away from nor do you really need to. In fact
> | the more strongly typed the language is, the more casting you have to do.
>
> This statement is inc
Lo, on Tuesday, January 1, Ben Collins did write:
> On Mon, Dec 31, 2001 at 09:15:26PM -0600, Richard Cobbe wrote:
>
> > Consider the following:
> >
> > char *a, *b;
> >
> > a = strdup("This is a sample string");
> > b = a;
> >
> > free(a);
> >
> > /* Much code follows her
On Mon, Dec 31, 2001 at 03:46:38PM -0800, Eric G. Miller wrote:
>
> Well, I dare you to remove 'ld' or 'libc.so' and see how many programs
> run ;-) I think it's fair to characterize required language libraries
> as part of the "run time" system. Whether or not a program is statically
> compiled
On Mon, Dec 31, 2001 at 09:15:26PM -0600, Richard Cobbe wrote:
>
> > most of the segfaults are because of the resource allocation mistakes,
> > not because of mistaken types... at last that's my impression.
>
> Resource allocation mistakes (at least, the kind that typically lead to
> seg faults)
On Mon, Dec 31, 2001 at 09:27:36PM -0500, William T Wilson wrote:
| Casting you can't really get away from nor do you really need to. In fact
| the more strongly typed the language is, the more casting you have to do.
This statement is incorrect. The strength and staticness of typing
are two i
Lo, on Monday, December 31, Erik Steffl did write:
> "Eric G. Miller" wrote:
> >
> > On Mon, 31 Dec 2001 13:46:15 -0800, Erik Steffl <[EMAIL PROTECTED]> wrote:
> >
> > > Richard Cobbe wrote:
> > > >
> > > > Lo, on Sunday, December 30, Dimitri Maziuk did write:
> > > >
> > > > > * William T Wilso
On Mon, 31 Dec 2001, Erik Steffl wrote:
> consider perl which doesn't have strong types but it's quite
> impossible to make it segfault and C++ on the other side which is
That is true but it doesn't mean that type safety won't prevent it
also. Consider a hypothetical language that doesn't have
"Eric G. Miller" wrote:
>
> On Mon, 31 Dec 2001 13:46:15 -0800, Erik Steffl <[EMAIL PROTECTED]> wrote:
>
> > Richard Cobbe wrote:
> > >
> > > Lo, on Sunday, December 30, Dimitri Maziuk did write:
> > >
> > > > * William T Wilson ([EMAIL PROTECTED]) spake thusly:
> > > > ...
> > > > > So... why *s
On Mon, 31 Dec 2001 13:46:15 -0800, Erik Steffl <[EMAIL PROTECTED]> wrote:
> Richard Cobbe wrote:
> >
> > Lo, on Sunday, December 30, Dimitri Maziuk did write:
> >
> > > * William T Wilson ([EMAIL PROTECTED]) spake thusly:
> > > ...
> > > > So... why *should* the programmer concern himself with
Richard Cobbe wrote:
>
> Lo, on Sunday, December 30, Dimitri Maziuk did write:
>
> > * William T Wilson ([EMAIL PROTECTED]) spake thusly:
> > ...
> > > So... why *should* the programmer concern himself with individual
> > > bytes of memory? (Assuming he is writing an ordinary application and
> >
Lo, on Sunday, December 30, Dimitri Maziuk did write:
> * William T Wilson ([EMAIL PROTECTED]) spake thusly:
> ...
> > So... why *should* the programmer concern himself with individual
> > bytes of memory? (Assuming he is writing an ordinary application and
> > not a hardware driver or something s
Hi
Joyner's article is very old. Has he updated it recently?
I didn't care much for Joyner's article either, but I learned a
great deal about C++ from reading it.
If you want or need to deal with the hardware, then you should use a
language that permits this access. If not, then by what ever y
Dimitri Maziuk wrote:
> * William T Wilson ([EMAIL PROTECTED]) spake thusly:
> ...
> > So... why *should* the programmer concern himself with individual bytes of
> > memory? (Assuming he is writing an ordinary application and not a hardware
> > driver or something similar).
>
> Because if he does
* William T Wilson ([EMAIL PROTECTED]) spake thusly:
...
> So... why *should* the programmer concern himself with individual bytes of
> memory? (Assuming he is writing an ordinary application and not a hardware
> driver or something similar).
Because if he does not, his application will segfault a
William T Wilson wrote:
> But then no one derives any real
> benefit from having 0x37 placed at offset 0.
That depends what memory address 0 is used for in the target platform.
It may be a significant thing to the CPU, or to some memory-mapped
peripheral, and therefore to the kernel. This is one
On Sat, 29 Dec 2001 16:39:48 -0800 (PST), "Jeffrey W. Baker" <[EMAIL
PROTECTED]> wrote:
>
>
> On Sat, 29 Dec 2001, Eric G. Miller wrote:
>
> > For a good explanation of how C++ took all the problematic issues of C and
> > added new sources of errors, see http://www.elj.com/cppcv3/.
>
> Hah!
On Sat, 29 Dec 2001, Jeffrey W. Baker wrote:
> about C++ (and C) and I don't think I can take it any longer. "Be
> like me, use a language with imperceptible market penetration." I
Why does market penetration matter? It's like saying Windows is superior
because everyone uses it; but if you bel
On Saturday 29 December 2001 04:55 pm, Craig Dickson wrote:
> That language shootout didn't really mean much.
Not the shootout specifically, but simple benchmarks can mean something.
Depends on who you ask. If you are doing numerical analysis, like me, or
artificial neural networks, or genetic
On Sat, 29 Dec 2001, Eric G. Miller wrote:
> For a good explanation of how C++ took all the problematic issues of C and
> added new sources of errors, see http://www.elj.com/cppcv3/.
Hah! More like this:
"For a vivid example of how much free time ivory tower academics have to
weep and moan ab
For a good explanation of how C++ took all the problematic issues of C and
added new sources of errors, see http://www.elj.com/cppcv3/.
--
Eric G. Miller
Alec wrote:
> > You say that as if C were merely an 'unreal' C++, which is just not
> > true. They are two different languages, though obviously C++ is a
> > derivative of C.
>
> With minor exceptions, a valid C program is also a valid C++ program
> (See appendix B, chapter B.2.2 of "The C++ Pro
On Saturday 29 December 2001 01:13 pm, Craig Dickson wrote:
> wsa wrote:
> > As others have said stear clear of OS specific topics...
> > Even if you want to start using OS specific stuff later on i think it's
> > best to start out with real C++.
>
> You say that as if C were merely an 'unreal' C++
82 matches
Mail list logo
