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 only
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't assign it
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 equivalent to char[]) that
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 a
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 with a NUL
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 for
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 there is
Eric G. Miller wrote:
...
merely a subset of them (0=ilength). The problem is that today's
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
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 difference? the point
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 - i.e. the
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
|
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?
If I'm
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 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 almost
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;
...
|
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 its
argument
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 have one of
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 gives
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 len =
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_t length;
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 more than the
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 trick
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_t length;
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 almost
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 has
|
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 of
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 object
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
pointer
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
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 what
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 of. Perl's types
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 Perl
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
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 dynamic
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 related;
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
| dereference
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.
|
|
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
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 storage
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 *has* to have some
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 (plus
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
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 question, but
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, 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
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 is
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 more robust as far as
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 a
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, numbers, and
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, python, and java
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 languages
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
* scalars (no
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
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) *are*
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 is
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 here, none of which
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
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 the
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, which
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 meaning to
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. In
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 too!
Oh
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 assignment that
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 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
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
not a
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 individual
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 *should* the programmer concern
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
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 Wilson ([EMAIL PROTECTED]) spake
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
* 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 and
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 not, his
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
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++, which
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++ Programming
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 egm2@jps.net
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
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, 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
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! More like
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
82 matches
Mail list logo
