By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,194 Members | 838 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,194 IT Pros & Developers. It's quick & easy.

malloc and free

P: n/a
If I allocate a block of memory
char *p = (char*)malloc(sizeof(char)*10);
afterward I want to free a number of them, say the first 3 blocks, how do I
do so? If I tried free(p), the whole 10 blocks are being freed. Is there a
method to free only the first few blocks without having to malloc a new
block and copy the remaining ones?

Thank you


Nov 13 '05 #1
Share this Question
Share on Google+
34 Replies


P: n/a
Kelvin Leung wrote:

If I allocate a block of memory
char *p = (char*)malloc(sizeof(char)*10);
afterward I want to free a number of them, say the first 3 blocks, how do I
do so? If I tried free(p), the whole 10 blocks are being freed. Is there a
method to free only the first few blocks without having to malloc a new
block and copy the remaining ones?


No.

--
Er*********@sun.com
Nov 13 '05 #2

P: n/a

On Thu, 30 Oct 2003, Kelvin Leung wrote:

If I allocate a block of memory
char *p = (char*)malloc(sizeof(char)*10);
char *p = malloc(10 * sizeof *p);

is the more idiomatic way to do that. Or for 'char'
specifically, if you're actually using the pointer to
point to a string (and thus not expecting 'char' to
change to 'short' or 'int' in future code reviews),

char *p = malloc(10);

as I do below.
(See the FAQ and Google Groups for reasons why.)
afterward I want to free a number of them, say the first 3 blocks, how do I
do so? If I tried free(p), the whole 10 blocks are being freed. Is there a
method to free only the first few blocks without having to malloc a new
block and copy the remaining ones?


Nope. Sorry.
To free the first three 'char's, write:

{
char *p = malloc(10); /* NB: sizeof(char) is 1 by definition */
char *temp;

if (p == NULL) exit(EXIT_FAILURE);

temp = malloc(7);
if (temp == NULL) exit(EXIT_FAILURE);

memcpy(temp, p, 7);
free(p);
p = temp;

[...]

free(p);
}

HTH,
-Arthur
Nov 13 '05 #3

P: n/a
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> spoke thus:
To free the first three 'char's, write: {
char *p = malloc(10); /* NB: sizeof(char) is 1 by definition */
char *temp; if (p == NULL) exit(EXIT_FAILURE); temp = malloc(7);
if (temp == NULL) exit(EXIT_FAILURE); memcpy(temp, p, 7);
free(p);
p = temp; [...] free(p);
}


Is that preferable to the following (untested) code?

{
const int size=10;
char *p=malloc( size );
char *tmp=p;

if( !p ) exit( EXIT_FAILURE );

memmove( p, p+3, size-3 ); /* assumes p has at least four members */
if( (tmp=realloc(p,size-3)) == NULL ) {
free( p ); /* not strictly necessary */
exit( EXIT_FAILURE );
}
...
free( p );
}

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 13 '05 #4

P: n/a
Arthur J. O'Dwyer wrote:
is the more idiomatic way to do that. Or for 'char'
specifically, if you're actually using the pointer to
point to a string (and thus not expecting 'char' to
change to 'short' or 'int' in future code reviews),

char *p = malloc(10);


This is just as bad as using
char *p = malloc(10 * sizeof char);

You are in both cases explicitly relying on the type of p.

In the first case you might be said to implicitly explicitly
rely on the type of p. :p

--
Thomas.

Nov 13 '05 #5

P: n/a
"Kelvin Leung" <kw******@csis.hku.hk> wrote:
If I allocate a block of memory
char *p = (char*)malloc(sizeof(char)*10);
Better:

char *p = malloc(10);

The cast is spurious and may hide errors, and sizeof(char) equals 1 by
definition.

Even better:

char *p = malloc(10 * sizeof *p);

This way you don't even have to care about the malloc expression when
the type p points to is ever going to change in the future.
afterward I want to free a number of them, say the first 3 blocks, how do I
do so? If I tried free(p), the whole 10 blocks are being freed. Is there a
method to free only the first few blocks without having to malloc a new
block and copy the remaining ones?


No, but you may use the realloc function to cut off the tail, so to say.

Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #6

P: n/a
Irrwahn Grausewitz <ir*******@freenet.de> spoke thus:
No, but you may use the realloc function to cut off the tail, so to say.


Considering that OP wanted to free the *first* three elements, realloc()
can't do the job alone.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 13 '05 #7

P: n/a
In <bn**********@www.csis.hku.hk> "Kelvin Leung" <kw******@csis.hku.hk> writes:
If I allocate a block of memory
char *p = (char*)malloc(sizeof(char)*10);
The right way of doing it is:

char *p = malloc(10);

The cast is a bad idea and the size of a char is not going to change from
1 anytime in the foreseeable future.
afterward I want to free a number of them, say the first 3 blocks, how do I
do so? If I tried free(p), the whole 10 blocks are being freed. Is there a
method to free only the first few blocks without having to malloc a new
block and copy the remaining ones?


They are called "bytes", not "blocks". You can either free the whole
block (by calling free()) or the last part of it (by calling realloc()).

There is no way of freeing the beginning of the block, while preserving
the data at its end. What you can do is use memmove() to move the data
at the beginning of the block and free its last part, with a realloc call.
Note, however, that if the realloc() call succeeds, the remaining smaller
block may be moved to a new address (but its contents is preserved).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #8

P: n/a
Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:
Irrwahn Grausewitz <ir*******@freenet.de> spoke thus:
No, but you may use the realloc function to cut off the tail, so to say.


Considering that OP wanted to free the *first* three elements, realloc()
can't do the job alone.


Which is probably why Irrwahn's answer started with "No, but".

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #9

P: n/a
Dan Pop wrote:
Kelvin Leung writes:

If I allocate a block of memory char *p = (char*)malloc(sizeof(char)*10);

The right way of doing it is:

char *p = malloc(10);

The cast is a bad idea
and the size of a char is not going to change from 1
anytime in the foreseeable future.


This is bad advice if you need to compile with a C++ compiler:
cat malloc.c #include <stdlib.h>
#include <stdio.h>

int main(int argc, char* argv[]) {
const
int n = 10;
int* p = malloc(n*sizeof(int));
for (int j = 0; j < n; ++j)
p[j] = j;
for (int j = 0; j < n; ++j)
fprintf(stdout, "%2d = p[%2d]\n", p[j], j);
return 0;
}
g++ -x c++ -Wall -ansi -pedantic -O2 -o malloc malloc.c

malloc.c: In function `int main(int, char**)':
malloc.c:7: warning: invalid conversion from `void*' to `int*'

Nov 13 '05 #10

P: n/a
On Wed, 29 Oct 2003 12:00:13 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:
Dan Pop wrote:
Kelvin Leung writes:
char *p = (char*)malloc(sizeof(char)*10);
The cast is a bad idea


This is bad advice if you need to compile with a C++ compiler:
> cat malloc.c

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char* argv[]) {
const
int n = 10;
int* p = malloc(n*sizeof(int));
for (int j = 0; j < n; ++j)
p[j] = j;
for (int j = 0; j < n; ++j)
fprintf(stdout, "%2d = p[%2d]\n", p[j], j);
return 0;
}
> g++ -x c++ -Wall -ansi -pedantic -O2 -o malloc malloc.c

malloc.c: In function `int main(int, char**)':
malloc.c:7: warning: invalid conversion from `void*' to `int*'


So what? C++ programs should be using the `new' operator anyway. And C++ is
offtopic in c.l.c.
Nov 13 '05 #11

P: n/a
Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> spoke thus: Is that preferable to the following (untested) code? {
const int size=10;
char *p=malloc( size );
char *tmp=p;

if( !p ) exit( EXIT_FAILURE ); memmove( p, p+3, size-3 ); /* assumes p has at least four members */
if( (tmp=realloc(p,size-3)) == NULL ) {
free( p ); /* not strictly necessary */
exit( EXIT_FAILURE );
}
...
free( p );
I'm assuming that here you mean free(tmp);
}

I havn't been able to make it core dump but shouldn't it?
When you realloc to a large enough size that you have to create a
whole new area, shouldn't the vm_struct be destroyed and memory be
copied on write to the new region? Assuming linux is posix compliant
for realloc, then it *should* apply in a similar manner to all other
posix compliant os's. I'm not certain about linux's functionality,
my book is at home.
--
Harrison Caudill | .^ www.hypersphere.org
Computer Science & Physics Double Major | | Me*Me=1
Georgia Institute of Technology | '/ I'm just a normal guy
Nov 13 '05 #12

P: n/a
rihad wrote:
E. Robert Tisdale wrote:
Dan Pop wrote:
Kelvin Leung writes:

char *p = (char*)malloc(sizeof(char)*10);

The cast is a bad idea


This is bad advice if you need to compile with a C++ compiler:
> cat malloc.c

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char* argv[]) {
const
int n = 10;
int* p = malloc(n*sizeof(int));
for (int j = 0; j < n; ++j)
p[j] = j;
for (int j = 0; j < n; ++j)
fprintf(stdout, "%2d = p[%2d]\n", p[j], j);
return 0;
}
> g++ -x c++ -Wall -ansi -pedantic -O2 -o malloc malloc.c

malloc.c: In function `int main(int, char**)':
malloc.c:7: warning: invalid conversion from `void*' to `int*'


So what?
C++ programs should be using the `new' operator anyway.
And C++ is offtopic in c.l.c.


I don't want to discuss C++.
But *real* C programmers can't afford to ignore C++.
They must write C code which can be compiled by C++ compilers
as well as by C compilers.

Nov 13 '05 #13

P: n/a
E. Robert Tisdale wrote:
Dan Pop wrote:
The cast is a bad idea
and the size of a char is not going to change from 1
anytime in the foreseeable future.


This is bad advice if you need to compile with a C++ compiler:


If you need to compile with a C++ compiler, you're in the wrong newsgroup.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #14

P: n/a
E. Robert Tisdale wrote:
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char* argv[]) {
const
int n = 10;
int* p = malloc(n*sizeof(int));
for (int j = 0; j < n; ++j)
p[j] = j;
for (int j = 0; j < n; ++j)
fprintf(stdout, "%2d = p[%2d]\n", p[j], j);
return 0;
}


I made the obvious fix and it _still_ would not compile with my
Fortran compiler. To add insult to injury the above is not even
valid Perl syntax. And I though any kind of line noise would go
in Perl.

Well, I guess my multilingual skills are not what they should
be.

--
Thomas.

Nov 13 '05 #15

P: n/a
"E. Robert Tisdale" wrote:
I don't want to discuss C++.
But *real* C programmers can't afford to ignore C++.

*Real* newsgroup trolls can't keep from mentioning it either,
apparently.


Brian Rodenborn
Nov 13 '05 #16

P: n/a

On Wed, 29 Oct 2003, Charles Harrison Caudill wrote:

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
Is that preferable to the following (untested) code?
Well, I didn't think of your way, but both ways work. :)
I think the use of 'memmove' instead of 'memcpy' is a little
more obscure, and I personally try to avoid 'realloc' in
general, just because of the contortions through which one
has to go in order to do proper error-checking.
But your (Chris's) way works, and I bet there are sane
people out there who prefer it over mine.
{
const int size=10;
char *p=malloc( size );
char *tmp=p;

if( !p ) exit( EXIT_FAILURE );
memmove( p, p+3, size-3 ); /* assumes p has at least four members */
if( (tmp=realloc(p,size-3)) == NULL ) {
free( p ); /* not strictly necessary */
exit( EXIT_FAILURE );
}
...
free( p );


I'm assuming that here you mean free(tmp);


Probably Chris meant to insert an

else { p = tmp; }

three lines up, instead.
}


I havn't been able to make it core dump but shouldn't it?


Of course not!
When you realloc to a large enough size that you have to create a
whole new area,
Strictly speaking, you may never *ever* have to "create a whole new
area." malloc() could just give you these really gi-normous blocks
of memory to begin with. :-)
shouldn't the vm_struct be destroyed
C has no concept of "vm_struct", unless you, the programmer,
decide to define one in your own code.
and memory be
copied on write to the new region? Assuming linux is posix compliant
for realloc,
Linux is off-topic for c.l.c. So is POSIX. And as far as I know,
the behavior of 'realloc' is not defined or extended in any way by
POSIX anyway. [No, I *don't* care.]
then it *should* apply in a similar manner to all other
posix compliant os's. I'm not certain about linux's functionality,
my book is at home.


Turns out you don't need it in this newsgroup; the Book here
is K&R2, and the Final Authority is the ISO standard. You wanna
talk POSIX or vm_structs or whatever, go to a newsgroup where
people talk about that stuff.

HTH,
-Arthur
Nov 13 '05 #17

P: n/a

On Wed, 29 Oct 2003, Thomas Stegen wrote:

Arthur J. O'Dwyer wrote:

is the more idiomatic way to do that. Or for 'char'
specifically, if you're actually using the pointer to
point to a string (and thus not expecting 'char' to
change to 'short' or 'int' in future code reviews),

char *p = malloc(10);
This is just as bad as using
char *p = malloc(10 * sizeof char);


Not quite as bad, because it's less verbose. (Also, because
it does compile; but I'm sure you meant to add parentheses
around 'char' in your example. If you really didn't, then I
would strongly disagree that my version is "as bad." ;-)
You are in both cases explicitly relying on the type of p.
Yes, that is correct. However, C does several clever things
with arrays of 'char' that it doesn't do with any other type
of array, so if you're going to start passing 'p' to 'strlen'
or 'fputs', odds are that the type of 'p' isn't going to
change anytime in the foreseeable future (to steal Dan Pop's
phrase).
In the first case you might be said to implicitly explicitly
rely on the type of p. :p


If the next line of the function is

strcpy(p, "hello");

then IMHO that assumption is perfectly justifiable.

-Arthur

Nov 13 '05 #18

P: n/a
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
[...]
I don't want to discuss C++.
Then don't.
But *real* C programmers can't afford to ignore C++.
They must write C code which can be compiled by C++ compilers
as well as by C compilers.


That's complete nonsense, as I'm sure you know.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #19

P: n/a
On Wed, 29 Oct 2003 17:23:18 -0500 (EST)
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:

On Wed, 29 Oct 2003, Charles Harrison Caudill wrote:

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
Is that preferable to the following (untested) code?
Well, I didn't think of your way, but both ways work. :)
I think the use of 'memmove' instead of 'memcpy' is a little
more obscure,
I don't find memmove any more obscure than memcpy, if anything I find it
less obscure because it gives defined results then memcpy invokes UB and
when memcpy does not invoke UB memmove behaves the same.
and I personally try to avoid 'realloc' in
general, just because of the contortions through which one
has to go in order to do proper error-checking.
Write a realloc wrapper, then you only have to worry about this once.
But your (Chris's) way works, and I bet there are sane
people out there who prefer it over mine.
{
const int size=10;
char *p=malloc( size );
char *tmp=p;

if( !p ) exit( EXIT_FAILURE );

memmove( p, p+3, size-3 ); /* assumes p has at least four
members */ if( (tmp=realloc(p,size-3)) == NULL ) {
free( p ); /* not strictly necessary */
exit( EXIT_FAILURE );
}
...
free( p );


I'm assuming that here you mean free(tmp);


Probably Chris meant to insert an

else { p = tmp; }

three lines up, instead.


<snip>

The advantage I see in the memmove/realloc version written by
Christopher over the memcpy/malloc/free version written by Arthur is
that it potentially has lower memory requirements and may fragment
memory less. After all, if you have only 5 bytes available for mallocing
by the C environment the malloc(10) will fail but the realloc(p,size-3)
could succeed since it does not need any more memory.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Nov 13 '05 #20

P: n/a
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> spoke thus:
Probably Chris meant to insert an
else { p = tmp; }
three lines up, instead.


Why, yes, yes I did ;( Thanks!

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 13 '05 #21

P: n/a
Mark Gordon <sp******@flash-gordon.me.uk> spoke thus:
I don't find memmove any more obscure than memcpy, if anything I find it
less obscure because it gives defined results then memcpy invokes UB and
when memcpy does not invoke UB memmove behaves the same.


On the other hand, I imagine memmove requires some amount of extra processing
time in exchange for defined behavior...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 13 '05 #22

P: n/a
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
Dan Pop wrote:
Kelvin Leung writes:
If I allocate a block of memory char *p = (char*)malloc(sizeof(char)*10);

The right way of doing it is:
char *p = malloc(10);
The cast is a bad idea and the size of a char is not going to
change from 1
anytime in the foreseeable future.


This is bad advice if you need to compile with a C++ compiler:


But in that case, it would not be C code anymore. The advice is
perfectly fine for anyone writing C code.

(Great, not this discussion again...)

--
Micah J. Cowan
mi***@cowan.name
Nov 13 '05 #23

P: n/a
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
I don't want to discuss C++.
But *real* C programmers can't afford to ignore C++.
They must write C code which can be compiled by C++ compilers
as well as by C compilers.


sez you. There are many "*real* C programmers" on this NG that
sez otherwise. Unless you have a unique definition for "real" (or
"C programmer").

--
Micah J. Cowan
mi***@cowan.name
Nov 13 '05 #24

P: n/a
In article <m3************@localhost.localdomain>,
Micah Cowan <mi***@cowan.name> wrote:
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
I don't want to discuss C++.
But *real* C programmers can't afford to ignore C++.
They must write C code which can be compiled by C++ compilers
as well as by C compilers.


sez you. There are many "*real* C programmers" on this NG that
sez otherwise. Unless you have a unique definition for "real" (or
"C programmer").


The ones who aren't complex, of course.

It's the simple C programmers that can't ignore C++.
dave
(gratuitiously abusing language since... maybe 1982?)

--
Dave Vandervies dj******@csclub.uwaterloo.ca
We maintain a healthy fiction here that we don't know anything about off-topic
subjects, except for such things as food, music, and when to call Lawrence
Kirby "Fred". --Martin Ambuhl in comp.lang.c
Nov 13 '05 #25

P: n/a
Dave Vandervies wrote:
The ones who aren't complex, of course.

It's the simple C programmers that can't ignore C++.


I think you mean irrational C programmers.

--
Thomas.

Nov 13 '05 #26

P: n/a
In <3F**************@jpl.nasa.gov> "E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
Dan Pop wrote:
Kelvin Leung writes:

If I allocate a block of memory char *p = (char*)malloc(sizeof(char)*10);

The right way of doing it is:

char *p = malloc(10);

The cast is a bad idea
and the size of a char is not going to change from 1
anytime in the foreseeable future.


This is bad advice if you need to compile with a C++ compiler:


What is a C++ compiler? If it is anything behaving like a conforming
standard C compiler, then my advice is excellent. If it is anything else,
it is off-topic in this newsgroup.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #27

P: n/a
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<3F**************@jpl.nasa.gov>...

[snip]

I don't want to discuss C++.
But *real* C programmers can't afford to ignore C++.
They must write C code which can be compiled by C++ compilers
as well as by C compilers.


This is the single most asinine thing I've read all week.

Either you're writing C (in which case you use a C compiler) or C++
(in which case you use a C++ compiler). They're completely different
languages. You wouldn't require someone to write C code that also
compiles as Java, would you? How about C#?

I've worked on a number of projects that had both C and C++
components; we simply used the appropriate compiler for the given
language. I would have thought that was the obvious, logical
solution, rather than deliberately crippling our code to meet the
demands of two different compilers.
Nov 13 '05 #28

P: n/a
In <3F**************@jpl.nasa.gov> "E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
But *real* C programmers can't afford to ignore C++.
They must write C code which can be compiled by C++ compilers
as well as by C compilers.

_____________________
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `'
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #29

P: n/a
In article <3f********@nntphost.cis.strath.ac.uk>,
Thomas Stegen <ts*****@cis.strath.ac.uk> wrote:
Dave Vandervies wrote:
The ones who aren't complex, of course.

It's the simple C programmers that can't ignore C++.


I think you mean irrational C programmers.


That works too, but it doesn't follow quite as nicely from "not complex".
(Unless you can find another way to get from "real" to "irrational"?)
dave

--
Dave Vandervies
dj******@csclub.uwaterloo.ca

Si tu hoc leger scis, tu nimis argutior es.
Nov 13 '05 #30

P: n/a
On Thu, 30 Oct 2003 00:48:41 +0000 (UTC)
Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
Mark Gordon <sp******@flash-gordon.me.uk> spoke thus:
I don't find memmove any more obscure than memcpy, if anything I
find it less obscure because it gives defined results then memcpy
invokes UB and when memcpy does not invoke UB memmove behaves the
same.


On the other hand, I imagine memmove requires some amount of extra
processing time in exchange for defined behavior...


Yes, it does require extra checks so I still use memcpy when
performance matters *and* I can be certain not to have overlapping
source & destination.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Nov 13 '05 #31

P: n/a
Dave Vandervies wrote:
In article <3f********@nntphost.cis.strath.ac.uk>,
Thomas Stegen <ts*****@cis.strath.ac.uk> wrote:
Dave Vandervies wrote:

The ones who aren't complex, of course.

It's the simple C programmers that can't ignore C++.


I think you mean irrational C programmers.

That works too, but it doesn't follow quite as nicely from "not complex".
(Unless you can find another way to get from "real" to "irrational"?)


I just thought real numbers, complex numbers and irrational numbers.

Maybe that is what you thought as well :)

--
Thomas.

Nov 13 '05 #32

P: n/a
In article <3f********@nntphost.cis.strath.ac.uk>,
Thomas Stegen <ts*****@cis.strath.ac.uk> wrote:
Dave Vandervies wrote:
In article <3f********@nntphost.cis.strath.ac.uk>,
Thomas Stegen <ts*****@cis.strath.ac.uk> wrote:
Dave Vandervies wrote:
[about "real C programmers"]
The ones who aren't complex, of course.

It's the simple C programmers that can't ignore C++.

I think you mean irrational C programmers.

That works too, but it doesn't follow quite as nicely from "not complex".
(Unless you can find another way to get from "real" to "irrational"?)


I just thought real numbers, complex numbers and irrational numbers.

Maybe that is what you thought as well :)


Well, almost. I thought real and complex numbers (the complex numbers
are generally treated as the ones that aren't real, even though they
contain the reals as a subset), and then went from complex to simple
(to undo the "opposite meaning", y'see).

The problem with using irrational there is that irrational numbers
aren't generally considered as "not <something that's not real>", so
using that distinction didn't leave the same opportunity to get in some
mathematically rigorous wordplay at Tisdale's expense.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca

Not yet; give it another century or so. As of now, it's still sloppy speech.
--Eric the Read in the scary devil monastery
Nov 13 '05 #33

P: n/a
E. Robert Tisdale wrote:
But *real* C programmers can't afford to ignore C++.
They must write C code which can be compiled by C++ compilers
as well as by C compilers.


A perfect occasion for that fine phrase, "arrant nonsense".

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

Nov 13 '05 #34

P: n/a
"Dave Vandervies" <dj******@csclub.uwaterloo.ca> wrote in message
news:bn**********@rumours.uwaterloo.ca...
In article <3f********@nntphost.cis.strath.ac.uk>,
Thomas Stegen <ts*****@cis.strath.ac.uk> wrote:
Dave Vandervies wrote:
In article <3f********@nntphost.cis.strath.ac.uk>,
Thomas Stegen <ts*****@cis.strath.ac.uk> wrote:

Dave Vandervies wrote:
[about "real C programmers"]
The ones who aren't complex, of course.
>
>It's the simple C programmers that can't ignore C++.

I think you mean irrational C programmers.
That works too, but it doesn't follow quite as nicely from "not complex". (Unless you can find another way to get from "real" to "irrational"?)


I just thought real numbers, complex numbers and irrational numbers.

Maybe that is what you thought as well :)


Well, almost. I thought real and complex numbers (the complex numbers
are generally treated as the ones that aren't real, even though they
contain the reals as a subset), and then went from complex to simple
(to undo the "opposite meaning", y'see).

The problem with using irrational there is that irrational numbers
aren't generally considered as "not <something that's not real>", so
using that distinction didn't leave the same opportunity to get in some
mathematically rigorous wordplay at Tisdale's expense.

What about "surreal" ? Doesn't involve heavy:-) math and triple indirection.
Should be good enough even for simple ones (programmers || trolls:-)
Nov 13 '05 #35

This discussion thread is closed

Replies have been disabled for this discussion.