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 34 8615
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
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
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.
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.
"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)
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.
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
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"
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*'
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.
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
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.
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
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.
"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
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
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
"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"
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.
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.
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.
"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
"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
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
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.
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
"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.
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
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.
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.
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.
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
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
"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:-) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: WL |
last post by:
Hey, all. I'm creating an array of strings (char **argv style) on
the fly, and using realloc to create string pointers, and malloc
for the strings itself (if that makes any sense).
I'm using the...
|
by: Steve Zimmerman |
last post by:
Esteemed contributors to clc:
Thank you for all the responses.
Experiments 2 and 3 below are identical, except that
experiment 2 does not call free(), while experiment 3 does.
With such a...
|
by: kent lavallie |
last post by:
Hi. I am an amature c hobbyist and I wish to begin using malloc as I
have been told that running executables from executables is a less
than elegant way to manage memory use. I need basic examples...
|
by: Richard Hunt |
last post by:
I'm sorry for asking such a silly question, but I can't quite get my head
around malloc. Using gcc I have always programmed in a lax C/C++ hybrid
(which I suppose is actually c++). But I have...
|
by: Chess Saurus |
last post by:
I'm getting a little bit tired of writing
if (a = malloc(...) == NULL) {
// error code
}
I mean, is it really possible that a malloc call could fail, except in
the case of running out of...
|
by: Rano |
last post by:
/*
Hello,
I've got some troubles with a stupid program...
In fact, I just start with the C language and sometime
I don't understand how I really have to use malloc.
I've readden the FAQ...
|
by: cs |
last post by:
This is the function malloc_m() that should be like malloc() but it
should find memory leak, and over bound writing in arrays.
How many errors do you see?
Thank you...
|
by: Martin Jørgensen |
last post by:
Hi,
I have a (bigger) program with about 15-30 malloc's in it (too big to
post it here)... The last thing I tried today was to add yet another
malloc **two_dimensional_data. But I found out that...
|
by: Petr Pavlu |
last post by:
Hello,
I have two questions how the functions should be written. I read the FAQ
but didn't find any answer. If there is any please point me out.
I. Cleanup code
Consider I have to open file1,...
|
by: jbholman |
last post by:
I am pretty new to C and doing my first project in C. I actually read
almost the entire FAQ, but can't seem to figure out this problem.
I have a structure. I have a list of these structures. ...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: Vimpel783 |
last post by:
Hello!
Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: ArrayDB |
last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: af34tf |
last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
| |