How a C programmer is interviewed?
greenmetal
I have been studying C for some time and now time has come to apply
for the job of C programmer / software developer. But I have no idea
what kind of questions to expect. Some of you must be taking
interviews of C programmers while others were interviewed for C
programming positions. I would appreciate if you give me some pointers
as what kind of questions I should expect during an interview for C
programmer / software developer position.
Thanx for all the ideas.
Tam
Peter Ammon
There was a hefty thread about this a while back. See
<http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&safe=off&threadm=dGPyp8GjCHA.260%40newsthru.thrunet.com&rnum=1&prev=/groups%3Fq%3Dg:thl1386092088d%26dq%3D%26hl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26selm%3DdGPyp8GjCHA.260%2540newsthru.thrunet.com>
-Peter
Malcolm
"greenmetal" <tmphot...@shaw.ca> wrote in message
maybe you'll be given a program and be asked what it does, or to point out
some errors (array boundary overflows are a typical example).
Or you might be asked to write a simple program in C, maybe to read in a
series of lines from a file, sort them alphabetically, and output the result
to another file.
E. Robert Tisdale
> I have been studying C for some time and now time has come
> to apply for the job of C programmer/software developer.
Congratulations.
> But I have no idea what kind of questions to expect.
> Some of you must be taking interviews of C programmers
> while others were interviewed for C programming positions.
> I would appreciate if you give me some pointers as to
> what kind of questions I should expect during an interview
> for C programmer/software developer position.
There is no set of interview questions
that will evaluate your qualifications as a C programmer.
Your interviewers' goals will be much more modest and practical.
They will probably want to get a feeling
about your intellect and your personality.
They need to know that you understand the fundamentals of C.
They need to know how you approach a problem
that you don't know how to solve.
They need to know that you are *not* an axe murderer.
They need to know how you react under pressure.
They need to know that you can get along with other people.
They may ask you stupid questions.
There is no need to tell them that the question is stupid.
Just try to answer in the most thoughtful and polite way that you can.
They may ask you to solve a problem that you can't solve.
Just give it your best effort and try to do as much as you can.
They may ask you a question that has no correct answer.
Just give them the best answer that you can.
If they tell you something that you know is incorrect,
tell them but don't dwell on the error.
Serve Laurijssen
I remember one. The following program works, but what is a potential problem
with it?
#include <stdio.h>
#include <stdlib.h>
int main() {
char buf[128];
FILE *fp = fopen(__FILE__, "r");
if (!fp) return EXIT_FAILURE;
while(!feof(fp))
{
if (fgets(buf, sizeof buf, fp))
puts(buf);
}
fclose(fp);
return 0;
}
greenmetal
Thank you all for the all the valuable input. One thing is clear to
me that during the interview I will be asked to write some program or
take some kind of test. Because when I go for VB programmer interview,
I am not asked to write a program or take a test. So I am nervous. I
will just do the best I can. I will go through the FAQ questions and
hopefully it will give me some confidence.
Since I am a beginner to C, when I come across a question I find
myself stressed out. I don't find myself stressed out when I have to
program in VB. Is this normal? This questions is to guys who are
programming using C for couple of years. Do you feel stressed out when
you have to write a program that you don't know how to? I know that
some people do not want to program in C just because it is a low level
language compared to VB and thus one has to think harder and
differently. For example, as a VB programmer I don't remember a time
when I had to write a code for data structures where as in C, it is
more common.
Tam
Nick Keighley
> tmphot...@shaw.ca (greenmetal) wrote in message
> news:<3ac7e125.03051...@posting.google.com>...
> > I have been studying C for some time and now time has come to apply
> > for the job of C programmer / software developer
<snip>
> > [...] I would appreciate if you give me some pointers
> > as what kind of questions I should expect during an interview for C
> > programmer / software developer position.
>
> Thank you all for the all the valuable input. One thing is clear to
> me that during the interview I will be asked to write some program or
> take some kind of test.
not everyone does this (though I think they should) but you should be
prepared for it.
> [...] Because when I go for VB programmer interview,
> I am not asked to write a program or take a test. So I am nervous. I
> will just do the best I can. I will go through the FAQ questions and
> hopefully it will give me some confidence.
>
> Since I am a beginner to C, when I come across a question I find
> myself stressed out. I don't find myself stressed out when I have to
> program in VB. Is this normal?
it's normal for a new programming language to be harder than an old one.
C is not inherently stressful.
> [...] This questions is to guys who are
> programming using C for couple of years. Do you feel stressed out when
> you have to write a program that you don't know how to?
no. Not normally. But I have more than a couple of years. By the time
I'm writing C I usually have a good idea of how I'm going to do it.
If it's an algorithmic problem I'll look in an algorithm book.
> [...] I know that
> some people do not want to program in C just because it is a low level
> language compared to VB
this is a matter of opinion.
> and thus one has to think harder and
> differently.
It may be different. C can be used to write portable programs. VB can't.
> [...] For example, as a VB programmer I don't remember a time
> when I had to write a code for data structures where as in C, it is
> more common.
you lost me. What is "code for data structures"? Does VB not
have any data structures?
--
Nick Keighley
"The Real Programmer wants a "you asked for it, you got it"
text editor--complicated, cryptic, powerful, unforgiving,
dangerous. TECO, to be precise."
Arthur J. O'Dwyer
On Sun, 11 May 2003, greenmetal wrote:
>
> Thank you all for the all the valuable input. One thing is clear to
> me that during the interview I will be asked to write some program or
> take some kind of test. Because when I go for VB programmer interview,
> I am not asked to write a program or take a test. So I am nervous. I
> will just do the best I can. I will go through the FAQ questions and
> hopefully it will give me some confidence.
Maybe you won't be asked to write C code during an interview. But you'll
eventually have to write some, assuming you get the job; so practicing
your coding skills is always a good idea.
> Since I am a beginner to C, when I come across a question I find
> myself stressed out. I don't find myself stressed out when I have to
> program in VB. Is this normal?
Yes. When I program in Java, I occasionally feel "stressed out," whereas
when I program in C (which I've known longer), I don't. It's all about
whether you're comfortable in the language. It also depends on how much
you rely on "hacking" ability -- that is, the ability to sit down and
write working code from scratch, as opposed to getting a pencil and paper
and working out the details of the problem first. Hacking out code tends
to work really well for small, trivial projects, but then you get asked
to write a search engine or compiler or something and you freeze up.
That's pretty much language-independent.
> This questions is to guys who are
> programming using C for couple of years. Do you feel stressed out when
> you have to write a program that you don't know how to? I know that
> some people do not want to program in C just because it is a low level
> language compared to VB and thus one has to think harder and
> differently. For example, as a VB programmer I don't remember a time
> when I had to write a code for data structures where as in C, it is
> more common.
That's silly. How could you have written any program beyond
"Fahrenheit-to-Celsius conversion" without using any data structures?
What about arrays? Dynamically sized lists? Hash tables? Binary
trees? Sorting and searching? These are basically language-independent
ideas, and I can't believe you'd be actively looking for a programming
job if you'd never *ever* written code that used them.
Unless you just mean that VB provides library classes or something so
that you don't have to implement them from scratch. Then the answer is:
C has libraries too, but you'll have to either find one you like, or
build one from scratch. C's like that.
HTH,
-Arthur
Netizen
Hi Tam,
In an interview, I was asked to write some C programs which involved
the use of files, command line arguments, and string processing.
Be sure to have a good knowledge about functions in the standard
library: like strtok(), strpbrk(), strcspn(), strtol(), itoa(). They
will come in handy.
Always check the return value of functions (esp. for file operations)
for error conditions, and provide code for handling them. Showing
concern for error-handling may impress the interviewers.
I was also asked about the uses of the `static' keyword, operator
precedence, associativity of operators, difference between stack and
heap memory, etc.
All the best!
Netizen
--
(change post-decrement to post-increment for email)
"Military intelligence is a contradiction in terms."
-- Groucho Marx
Mike Wahler
Netizen <vsdmin...@yahoo.co.in> wrote in message
news:a35b7280.03051...@posting.google.com...
> tmphot...@shaw.ca (greenmetal) wrote in message
news:<3ac7e125.03051...@posting.google.com>...
> > Hi,
> >
> > I have been studying C for some time and now time has come to apply
> > for the job of C programmer / software developer. But I have no idea
> > what kind of questions to expect. Some of you must be taking
> > interviews of C programmers while others were interviewed for C
> > programming positions. I would appreciate if you give me some pointers
> > as what kind of questions I should expect during an interview for C
> > programmer / software developer position.
> >
> > Thanx for all the ideas.
> >
> > Tam
>
> Hi Tam,
> In an interview, I was asked to write some C programs which involved
> the use of files, command line arguments, and string processing.
>
> Be sure to have a good knowledge about functions in the standard
> library: like strtok(), strpbrk(), strcspn(), strtol(), itoa().
Also know that 'atoi()' should *not* be used.
> They
> will come in handy.
>
> Always check the return value of functions (esp. for file operations)
> for error conditions,
'atoi()' cannot be checked for erroneous input.
>and provide code for handling them. Showing
> concern for error-handling may impress the interviewers.
Yes, it should, if they're clueful.
>
> I was also asked about the uses of the `static' keyword, operator
> precedence, associativity of operators, difference between stack and
> heap memory, etc.
'stack' and 'heap' are not C concepts.
But many interviewers are clueless...
-Mike
Alan Balmer
<mkwa...@mkwahler.net> wrote:
>>
>> I was also asked about the uses of the `static' keyword, operator
>> precedence, associativity of operators, difference between stack and
>> heap memory, etc.
>
>'stack' and 'heap' are not C concepts.
>
>But many interviewers are clueless...
And some interviewers want to know if your knowledge of real
implementations goes beyond the C standard ;-)
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
Mike Wahler
Alan Balmer <alba...@att.net> wrote in message
news:ci20cvc07u85i4vcu...@4ax.com...
> On Mon, 12 May 2003 13:04:14 -0700, "Mike Wahler"
> <mkwa...@mkwahler.net> wrote:
>
> >>
> >> I was also asked about the uses of the `static' keyword, operator
> >> precedence, associativity of operators, difference between stack and
> >> heap memory, etc.
> >
> >'stack' and 'heap' are not C concepts.
> >
> >But many interviewers are clueless...
>
> And some interviewers want to know if your knowledge of real
> implementations goes beyond the C standard ;-)
I assure you that mine does. But the discussion is
about C, isn't it? The subject says 'C programmer',
not <insert platform here> programmer.
This is why I reject such terms as 'C programmer',
'C++ programmer' etc. Either someone is a programmer
or they're not. A good programmer has many tools in
his 'toolbox', some of which are programming languages.
I have more than once struck a contract where the
other party (out of ignorance) was looking for e.g.
a 'VB programmer', but ended up actually providing
the solution in some other language(s).
-Mike
Black Phantom
Reminded me of a question I got some time ago:
given two ready functions:
void *kmalloc( size_t size ); // Has the same semantic as
regular malloc()
void kfree( void *p, size_t size ); // Accepts a pointer to an
allocated area and its size and frees the area
implement the regular malloc() and free().
Not very complicated, but one of a few I really liked.
/BP
Peter Nilsson
...
> Be sure to have a good knowledge about functions in the standard
> library: like strtok(), strpbrk(), strcspn(), strtol(), itoa(). They
> will come in handy.
itoa() is not in the C Standard Library.
...
> I was also asked about the uses of the `static' keyword, operator
> precedence, associativity of operators, difference between stack and
> heap memory, etc.
The standard does not specify stacks and heaps, it specifies object lifetimes.
--
Peter
Peter Nilsson
> <mkwa...@mkwahler.net> wrote:
>
> >>
> >> I was also asked about the uses of the `static' keyword, operator
> >> precedence, associativity of operators, difference between stack and
> >> heap memory, etc.
> >
> >'stack' and 'heap' are not C concepts.
> >
> >But many interviewers are clueless...
>
> And some interviewers want to know if your knowledge of real
> implementations goes beyond the C standard ;-)
I've yet to write a C program that uses malloc (et al) where it was
ever important to know *where* the memory resides. I've only ever
needed to know *when* it exists.
--
Peter
Peter Nilsson
I dare say your answer has faults regarding alignment of the returned
pointer for *all* types. Ignoring the poorly named implementation
utility functions, the only way to portably implement a malloc wrapper
(AFAIK) is to store each and every allocated pointer, and its size, in
a separate container to be trawled later by free().
--
Peter
Christian Bau
ai...@acay.com.au (Peter Nilsson) wrote:
"Portable" comes in degrees. "Runs on every possible conforming
implementation of C, including the Deathstation 9000" is probably more
portable than required.
An interesting interview question might be: How portable is this code in
practice if you assume an alignment of 4, 8 or 16?
code_wrong
"Black Phantom" <black__...@hotmail.com> wrote in message
news:8dc5d4e5.0305...@posting.google.com...
> tmphot...@shaw.ca (greenmetal) wrote:
>
> > Hi,
> >
> > I have been studying C for some time and now time has come to apply
> > for the job of C programmer / software developer. But I have no idea
> > what kind of questions to expect. Some of you must be taking
> > interviews of C programmers while others were interviewed for C
> > programming positions. I would appreciate if you give me some pointers
> > as what kind of questions I should expect during an interview for C
> > programmer / software developer position.
>
> Reminded me of a question I got some time ago:
>
> given two ready functions:
can you explain to those that are thick what a ready function is?
ready as in implemented already?
> void *kmalloc( size_t size ); // Has the same semantic as
> regular malloc()
> void kfree( void *p, size_t size ); // Accepts a pointer to an
> allocated area and its size and frees the area
>
> implement the regular malloc() and free().
Implement a function that already exists in the standard library?
I don't understand the question. I guess I don't get the job.
code_wrong
"Serve Laurijssen" <o...@ja.nl> wrote in message
news:b9lejv$v0g$1...@news2.tilbu1.nb.home.nl...
?? Will you post the answer please
code_wrong
"Mike Wahler" <mkwa...@mkwahler.net> wrote in message
news:b9oues$v59$1...@slb2.atl.mindspring.net...
>
> Netizen <vsdmin...@yahoo.co.in> wrote in message
> news:a35b7280.03051...@posting.google.com...
> > tmphot...@shaw.ca (greenmetal) wrote in message
> news:<3ac7e125.03051...@posting.google.com>...
> > > Hi,
> > >
> > > I have been studying C for some time and now time has come to apply
> > > for the job of C programmer / software developer. But I have no idea
> > > what kind of questions to expect. Some of you must be taking
> > > interviews of C programmers while others were interviewed for C
> > > programming positions. I would appreciate if you give me some pointers
> > > as what kind of questions I should expect during an interview for C
> > > programmer / software developer position.
> > >
> > > Thanx for all the ideas.
> > >
> > > Tam
> >
> > Hi Tam,
> > In an interview, I was asked to write some C programs which involved
> > the use of files, command line arguments, and string processing.
> >
> > Be sure to have a good knowledge about functions in the standard
> > library: like strtok(), strpbrk(), strcspn(), strtol(), itoa().
>
> Also know that 'atoi()' should *not* be used.
Can we use it if we 'absolutley know' that the string can be a valid int?
pseudocode:
if string length less than 5 and greater than 0
for each element
if(!isdigit(element))
set error flag
end for
else
set error flag
end if
if not error
return atoi(string)
else
return some error flag (-1)
end if
cheers
cw
Richard Bos
> "Mike Wahler" <mkwa...@mkwahler.net> wrote in message
> news:b9oues$v59$1...@slb2.atl.mindspring.net...
> > Also know that 'atoi()' should *not* be used.
>
> Can we use it if we 'absolutley know' that the string can be a valid int?
<snip almost correct pseudocode - check your boundary condition>
Yes. But using strtol() to begin with is easier.
Richard
Serve Laurijssen
"code_wrong" <t...@tac.ouch.co.uk> wrote in message
news:b9qbes$te6$1...@newsg2.svr.pol.co.uk...
> > while(!feof(fp))
> > {
> > if (fgets(buf, sizeof buf, fp))
> > puts(buf);
>
Only use feof after an io function has returned EOF. It could also be
ferror.
Arthur J. O'Dwyer
On Tue, 12 May 2003, Peter Nilsson wrote:
>
> black__...@hotmail.com (Black Phantom) wrote...
> >
> > Reminded me of a question I got some time ago:
> >
> > regular malloc()
> > void kfree( void *p, size_t size ); // Accepts a pointer to an
> > allocated area and its size and frees the area
> >
> > implement the regular malloc() and free().
>
> pointer for *all* types. Ignoring the poorly named implementation
> utility functions, the only way to portably implement a malloc wrapper
> (AFAIK) is to store each and every allocated pointer, and its size, in
> a separate container to be trawled later by free().
That's the first way I thought of, and I can't think of any others.
How did you think 'Black Phantom' did it? How would you do it?
-Arthur
Alan Balmer
<mkwa...@mkwahler.net> wrote:
>
>Alan Balmer <alba...@att.net> wrote in message
>news:ci20cvc07u85i4vcu...@4ax.com...
>> On Mon, 12 May 2003 13:04:14 -0700, "Mike Wahler"
>> <mkwa...@mkwahler.net> wrote:
>>
>> >>
>> >> I was also asked about the uses of the `static' keyword, operator
>> >> precedence, associativity of operators, difference between stack and
>> >> heap memory, etc.
>> >
>> >'stack' and 'heap' are not C concepts.
>> >
>> >But many interviewers are clueless...
>>
>> And some interviewers want to know if your knowledge of real
>> implementations goes beyond the C standard ;-)
>
>I assure you that mine does. But the discussion is
>about C, isn't it? The subject says 'C programmer',
>not <insert platform here> programmer.
Nope. The subject is interviews (and actually off-topic here.) A
knowledge of basic no-specific-language topics such as stack and heap
is useful to a C programmer.
>
>This is why I reject such terms as 'C programmer',
>'C++ programmer' etc. Either someone is a programmer
>or they're not. A good programmer has many tools in
>his 'toolbox', some of which are programming languages.
>
Agreed. I always follow "Do you know X" with "what languages do you
know" and "how long do you think it would take you to become useful
using X." The interviewee who answers the first question with "No, but
give me a week" get extra points <g>.
>I have more than once struck a contract where the
>other party (out of ignorance) was looking for e.g.
>a 'VB programmer', but ended up actually providing
>the solution in some other language(s).
>
As have I. OTOH, I've also contracted to use a less-than ideal
language or toolset because the client had perfectly good reasons for
requiring it.
>-Mike
Joona I Palaste
> "Black Phantom" <black__...@hotmail.com> wrote in message
> news:8dc5d4e5.0305...@posting.google.com...
>>
>> given two ready functions:
> can you explain to those that are thick what a ready function is?
> ready as in implemented already?
Yes.
>> void *kmalloc( size_t size ); // Has the same semantic as
>> regular malloc()
>> void kfree( void *p, size_t size ); // Accepts a pointer to an
>> allocated area and its size and frees the area
>>
>> implement the regular malloc() and free().
> Implement a function that already exists in the standard library?
For this question, we'll pretend the functions malloc and free are not
really implemented in the standard library.
> I don't understand the question. I guess I don't get the job.
Black Phantom must have used some weird trick to be able to do this.
Most probably he had malloc() not only kmalloc() the actual needed
memory, but also kmalloc() some memory to hold its size, so free()
had somewhere to look it up at. But how did free() know *which* size
it was supposed to look at? I haven't given this question that much
thought yet, but as it is, it looks impossible without implementation
magic, or some kind of static data structure behind the scenes.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"'It can be easily shown that' means 'I saw a proof of this once (which I didn't
understand) which I can no longer remember'."
- A maths teacher
Giuseppe
Is this right?
#include <stdio.h>
#include <stddef.h>
static struct al_sz_ {
size_t size;
union {long double y; unsigned long ul;} align;
};
static size_t s_=offsetof(struct al_sz_, align);
void* malloc(size_t sz)
{char *data=kmalloc(sz+s_);
if(data==0) return 0;
*(size_t*)data=size;
data += s_;
return data;
}
void free(void* p)
{size_t size;
if(p==0) return;
size = *(size_t*)((char*)p-s_);
kfree((char*)p-s_, size);
}
Neil Cerutti
> On 12 May 2003-0700, black__...@hotmail.com (Black Phantom) wrote:
>>tmphot...@shaw.ca (greenmetal) wrote:
>>> Hi,
>>>
>>> I have been studying C for some time and now time has come to
>>> apply for the job of C programmer / software developer. But I
>>> have no idea what kind of questions to expect. Some of you
>>> must be taking interviews of C programmers while others were
>>> interviewed for C programming positions. I would appreciate
>>> if you give me some pointers as what kind of questions I
>>> should expect during an interview for C programmer / software
>>> developer position.
>>
>> Reminded me of a question I got some time ago:
>>
>>given two ready functions:
>>
>>void *kmalloc( size_t size ); // Has the same semantic as
>>regular malloc()
>>void kfree( void *p, size_t size ); // Accepts a pointer to an
>>allocated area and its size and frees the area
>>
>> implement the regular malloc() and free().
>>
>>Not very complicated, but one of a few I really liked.
>
> Is this right?
It's seems pretty close.
> #include <stdio.h>
> #include <stddef.h>
>
> static struct al_sz_ {
> size_t size;
> union {long double y; unsigned long ul;} align;
> };
> static size_t s_=offsetof(struct al_sz_, align);
>
> void* malloc(size_t sz)
You need to check for potenetial overflow of size_t, which is a
pain since SIZE_MAX is not part of the standard.
> {char *data=kmalloc(sz+s_);
> if(data==0) return 0;
> *(size_t*)data=size;
I think you mean "= sz;"
> data += s_;
> return data;
> }
>
> void free(void* p)
> {size_t size;
> if(p==0) return;
> size = *(size_t*)((char*)p-s_);
> kfree((char*)p-s_, size);
You kmalloc s_ more bytes than you kfree.
> }
--
Neil Cerutti
Chris Torek
Black Phantom <black__...@hotmail.com> writes:
> Reminded me of a question I got some time ago:
>
>given two ready functions:
>
>void *kmalloc( size_t size ); // Has the same semantic as
>regular malloc()
>void kfree( void *p, size_t size ); // Accepts a pointer to an
>allocated area and its size and frees the area
>
> implement the regular malloc() and free().
>
>Not very complicated, but one of a few I really liked.
If you implemented this one:
void *mymalloc(size_t size) {
void *p;
p = kmalloc(size + sizeof size);
if (p == NULL)
return p;
*(size_t *)p = size;
return (size_t *)p + 1;
}
void myfree(void *p) {
size_t *x = p;
kfree(x - 1, x[-1]);
}
you will find that your code crashes on, e.g., SPARCs running in
32-bit mode, when you use mymalloc() to allocate "double *".
It *is* possible to do this in Standard C, but myfree() will be
painfully slow (you must search a table of all allocations to find
the size, using == or != comparisons), and a general implementation
will be quite complicated.
The mymalloc() and myfree() functions above, which have little
overhead, can be fixed up by inserting platform-specific alignment
code -- but there is no Standard-supplied way to find the required
alignment size in bytes. (The implementation knows this number,
and uses it in malloc(), and I have argued in the past that the
Standard should require the implementation to export the number.
But it does not.)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)
email: forget about it http://67.40.109.61/torek/ (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Ben Pfaff
> It *is* possible to do this in Standard C, but myfree() will be
> painfully slow (you must search a table of all allocations to find
> the size, using == or != comparisons), and a general implementation
> will be quite complicated.
You can use a hash table based on the bytes in a pointer. If the
O(1) hash-based lookup fails, fall back to an O(n) linear search
through the hash buckets. This will work on all systems, and be
fast on reasonable systems. You can even build it such that it
is fast on some unreasonable systems, e.g. if you're concerned
about real-mode x86, just make sure that the hash function drops
everything with equal (16 * segment + offset) into the same
bucket.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Chris Torek
> size_t *x = p;
>
> kfree(x - 1, x[-1]);
> }
Oops, that should be "x[-1] + sizeof *x".
The union trick mentioned elsethread is not sufficient. What if
the alignment required for "long double" is 8, but the alignment
required for "void (*)(void)" is 32?
(If you add a void (*)(void) member to the union, I will simply
ask: what if some other type has even STRICTER alignment?)
Jeremy Yallop
> You need to check for potenetial overflow of size_t, which is a
> pain since SIZE_MAX is not part of the standard.
SIZE_MAX is in C99, but it's easy to define anyway:
#include <stddef.h>
#ifndef SIZE_MAX
# define SIZE_MAX ((size_t)-1)
#endif
Jeremy.
Hallvard B Furuseth
> You can use a hash table based on the bytes in a pointer.
Not if two pointers with different representation can point to the same
object.
> You can even build it such that it is fast on some unreasonable
> systems, e.g. if you're concerned about real-mode x86, just make sure
> that the hash function drops everything with equal (16 * segment +
> offset) into the same bucket.
If you know that much about the system, you probably know the max
alignment on the system too, so you won't need the hash.
--
Hallvard
Chris Torek
In article <8765oew...@pfaff.Stanford.EDU>
Ben Pfaff <b...@cs.stanford.edu> writes:
>You can use a hash table based on the bytes in a pointer. If the
>O(1) hash-based lookup fails, fall back to an O(n) linear search
>through the hash buckets [to handle pointers that compare equal
even though the representations differ].
Yes, this will work, but is rather complicated.
It is still a good idea for some debugging applications, since it
allows you to store the detailed allocation information "far away"
from the returned "general use" memory. And, if you are willing
to pay the price -- in system-specificity and additional overhead
-- you may even be able to write-protect that information, so that
no matter what mistakes the user makes with the returned pointers,
he is physically prohibited from modifying the tracing data.
Nonetheless, it would still be nice if Standard C required the
allocation subsystem to export its knowledge about the strictest
alignment requirement. :-)
Ben Pfaff
> Ben Pfaff wrote:
>
> > You can use a hash table based on the bytes in a pointer.
>
> Not if two pointers with different representation can point to the same
> object.
You apparently missed the following sentence, which I notice you
carefully skipped quoting:
If the O(1) hash-based lookup fails, fall back to an O(n)
linear search through the hash buckets.
The fallback will work on any system.
> > You can even build it such that it is fast on some unreasonable
> > systems, e.g. if you're concerned about real-mode x86, just make sure
> > that the hash function drops everything with equal (16 * segment +
> > offset) into the same bucket.
>
> If you know that much about the system, you probably know the max
> alignment on the system too, so you won't need the hash.
My solution will work whether the hash function is chosen
properly or not. You can't guess the max alignment portably.
--
"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield
Giuseppe
>You need to check for potenetial overflow of size_t, which is a
>pain since SIZE_MAX is not part of the standard.
>
>> {char *data=kmalloc(sz+s_);
>> if(data==0) return 0;
>> *(size_t*)data=size;
>
>I think you mean "= sz;"
>> data += s_;
>> return data;
>> }
>>
>> void free(void* p)
>> {size_t size;
>> if(p==0) return;
>> size = *(size_t*)((char*)p-s_);
>> kfree((char*)p-s_, size);
>
>You kmalloc s_ more bytes than you kfree.
>
>> }
Thanks
#include <stdio.h>
#include <stddef.h>
#ifndef SIZE_MAX
#define SIZE_MAX ((size_t)-1)
#endif
static struct al_sz_ {
size_t size;
union {long double y; unsigned long ul;} align;
};
static size_t s_=offsetof(struct al_sz_, align);
void* malloc(size_t sz)
{char *data;
size_t si=(SIZE_MAX-s_<sz)? 0 : sz+s_;
if(si==0) return 0;
data=kmalloc(si);
if(data==0) return 0;
*(size_t*)data=si;
data += s_;
return data;
}
void free(void* p)
{if(p==0) return;
kfree((char*)p-s_, *(size_t*)((char*)p-s_));
}
Giuseppe
>static struct al_sz_ {
> size_t size;
> union {long double y; unsigned long ul;} align;
> };
>static size_t s_=offsetof(struct al_sz_, align);
>
>void* malloc(size_t sz)
>{char *data;
> size_t si=(SIZE_MAX-s_<sz)? 0 : sz+s_;
size_t si=(SIZE_MAX-s_<sz||sz==0)? 0 : sz+s_;
Christian Bau
"code_wrong" <t...@tac.ouch.co.uk> wrote:
True. If you don't understand that question, most people wouldn't give
you a job as a C programmer.
Christian Bau
<Pine.LNX.4.53L-031...@unix47.andrew.cmu.edu>,
Since this is a job interview, ask "How portable do you want it to be?"
Points if it runs correctly on any intended platform. Extra points if it
can be adapted easily to platforms that are not covered. Extra points if
it is more efficient than kmalloc and kfree itself (for example, provide
eight byte alignment when kmalloc only provides four byte alignment).
Extra points if you note that kmalloc and kfree functions might be very
expensive to call while malloc and free are supposed to be very cheap,
which would mean that you would want to build your own memory allocation
scheme on top of them.
Christian Bau
gius...@giuseppe.wwwew (Giuseppe) wrote:
Close, but no cigar. This may very well kill performance on an x86
system, and introduce a terrible bug on PowerPC systems. Actually, it
might introduce the same bug on an x86 system as well, and the
performance loss could be there on PowerPC systems, but likely less
noticable.
First rule of programming: Before you start typing code, find out what
the requirements are.
Veeral Patel
http://www.amazon.com/exec/obidos/ASIN/0471383562/ref=pd_sxp_elt_l1/002-6124485-2733610
hope you find this handy.
Veeral
"Arthur J. O'Dwyer" <a...@andrew.cmu.edu> wrote in message news:<Pine.LNX.4.53L-031...@unix47.andrew.cmu.edu>...
> On Sun, 11 May 2003, greenmetal wrote:
> >
> > Thank you all for the all the valuable input. One thing is clear to
> > me that during the interview I will be asked to write some program or
> > take some kind of test. Because when I go for VB programmer interview,
> > I am not asked to write a program or take a test. So I am nervous. I
> > will just do the best I can. I will go through the FAQ questions and
> > hopefully it will give me some confidence.
>
> Maybe you won't be asked to write C code during an interview. But you'll
> eventually have to write some, assuming you get the job; so practicing
> your coding skills is always a good idea.
>
> > Since I am a beginner to C, when I come across a question I find
> > myself stressed out. I don't find myself stressed out when I have to
> > program in VB. Is this normal?
>
> Yes. When I program in Java, I occasionally feel "stressed out," whereas
> when I program in C (which I've known longer), I don't. It's all about
> whether you're comfortable in the language. It also depends on how much
> you rely on "hacking" ability -- that is, the ability to sit down and
> write working code from scratch, as opposed to getting a pencil and paper
> and working out the details of the problem first. Hacking out code tends
> to work really well for small, trivial projects, but then you get asked
> to write a search engine or compiler or something and you freeze up.
> That's pretty much language-independent.
>
> > This questions is to guys who are
> > programming using C for couple of years. Do you feel stressed out when
> > you have to write a program that you don't know how to? I know that
> > some people do not want to program in C just because it is a low level
> > language compared to VB and thus one has to think harder and
> > differently. For example, as a VB programmer I don't remember a time
> > when I had to write a code for data structures where as in C, it is
> > more common.
>
> That's silly. How could you have written any program beyond
> "Fahrenheit-to-Celsius conversion" without using any data structures?
> What about arrays? Dynamically sized lists? Hash tables? Binary
> trees? Sorting and searching? These are basically language-independent
> ideas, and I can't believe you'd be actively looking for a programming
> job if you'd never *ever* written code that used them.
>
> Unless you just mean that VB provides library classes or something so
> that you don't have to implement them from scratch. Then the answer is:
> C has libraries too, but you'll have to either find one you like, or
> build one from scratch. C's like that.
>
> HTH,
> -Arthur
guse
> tmphot...@shaw.ca (greenmetal) wrote in message news:<3ac7e125.03051...@posting.google.com>...
<snipped>
> Thank you all for the all the valuable input. One thing is clear to
> me that during the interview I will be asked to write some program or
> take some kind of test.
also bear in mind that you can probably tell a lot about the
position from the test they give. i would assume that the
test-writers at a company are usually the more senior developers,
and any senior developer who makes elementary mistakes is bound
to be a pain as a boss.
if the test-writer asks a lot of questions about your knowledge
of C, or you are asked to pick up problems in a piece of code,
then that is probably OK. anything that requires intense mental
math is just an ego-trip for the test-writer, who will in all
probability just rejoice in
"i'm-better-than-you-cos-i-can-do-mental-long-division-in-base16"
type of thinking. this actually happens, and at one interview "test"
of mine every single one of the questions were like the following:
/* something like this, dont remember exactly */
int foo (int x, int y) {
if (x<y) {
x = bar (x+1, y-2);
} else {
y = bar (x-1, y+2);
}
}
int bar (int x, int y) {
if (x>y-1) {
x = foo (x-1, y-1);
} else {
y = foo (y+1, x+1);
}
}
...
int x=200, y=400, z;
/* now what is the values of z */
z = foo (x, y);
...
try to avoid working for someone who considers the above code
a test of your programming skills. needless to say, I couldn't
answer most of the questions (got a B on that test - i'm so
used to being able to answer any C question that that test was
quite a blow :-), and told the slave-trader the next day that i
wont consider working for that company.
the other thing about the tests is you get to see what kind of
code quality standard they adhere to. you *really* dont wanna
work for any company whose motto is "why check return value of
malloc ???" ... or who just code sloppily or slovenly!!!
that will kill any love for the career, the language or the projects
at hand that you may have had. you'll be miserable without knowing
why (the reason will be cos your life becomes maintenance-hell, when
the target machines finally run out of memory, or disk-space, or
suchlike).
also avoid, like the plague, any company who gives you a test
with code like
#include <stdio.h>
main() {
...
}
or code in which their structs are typedef'ed for no good reason.
<snipped>
> differently. For example, as a VB programmer I don't remember a time
> when I had to write a code for data structures where as in C, it is
> more common.
>
i dont understand ? how can one write anything non-trivial
without data structures ?
am i just being dense again?
hth
guse, still fighting with the editor and browser for
control of my postings!!!!
Christian Bau
ru...@webmail.co.za (guse) wrote:
That should be quite easy: You get two compile time errors because the
functions don't return anything. If the compiler produces an executable
and you run it your program will crash quite quickly because there is
infinite recursion :-)
(I suppose the functions were slightly different which could make this
quite a tough question. It is probably a good idea to test how a
candidate handles a really difficult question, but only questions of
this kind and nothing else won't leave you with too many candidates left
over).
Martha H Adams
potential employer. Well, maybe. But also maybe, the potential
employer or personnel person, simply lifted the test from somewhere
else, and doesn't know squat. I have some suggestions.
First, read around. History, and current events. Guess what a
knowledgeable person would know; and then learn it for yourself.
Maybe someone here can give you some ideas.
Next, over-learn your topic. If you know only C, you don't know C.
That is basic. Find a volume of Feuer's puzzzles and work through it.
This will be hard! Find two or three Obfuscated C examples, and work
through those until you (more or less) understand them. Read up on
shell and OS programming (Linux recommended). Review your basics,
which after you have done these things, will now become very rich and
interesting. *Then* go to your interview; and concern yourself mostly
with if where you're interviewing will be a good place for you to be.
If your interviewer doesn't read between the lines you're ready, the
possibilities are pretty clear: you're not; or he's not.
Cheers -- Martha Adams
Scott Moore
> <snipped>
>
> > Thank you all for the all the valuable input. One thing is clear to
> > me that during the interview I will be asked to write some program or
> > take some kind of test.
I allways ask the same thing. "please sort this list of numbers", something
like:
typedef struct _list {
int a;
struct _list next;
} list;
void sort(list *lp)
{
...
}
The reasons are:
A. I assume everyone saw sorting at one time or 'tother.
B. I WILL NOT hire programmers who don't know how to use lists.
Also, I give the cadidate the C book to look at, and make a excuse to
leave for a while. I am not trying to sweat them.
Most pass this test in one way or another, only one to my memory failed
it, and he was a complete programming fraud, and one young lady taught
ME a new way to do it that I still use today.
--
Warning: poster of this email may be under the influence of
sleep inducing documents !
Black Phantom
[...]
> Is this right?
>
> #include <stdio.h>
You're implementing the standard library, it may not be right place
to include stdio.h (besides you never use anything defined there).
> #include <stddef.h>
>
> static struct al_sz_ {
> size_t size;
> union {long double y; unsigned long ul;} align;
> };
> static size_t s_=offsetof(struct al_sz_, align);
>
> void* malloc(size_t sz)
> {char *data=kmalloc(sz+s_);
> if(data==0) return 0;
> *(size_t*)data=size;
> data += s_;
> return data;
> }
This won't work, in principle. You seem to assume that object of
size sz has no less strict alignment requirements than size_t. If the
opposite is true, your statement (size_t*)data pointer gets
incorrectly aligned for object of type size_t.
Example: alignment requires that multi-byte objects do not cross
4-byte address boundaries and malloc(1) is called.
/BP
Black Phantom
> given two ready functions:
>
> void *kmalloc( size_t size ); // Has the same semantic as
> regular malloc()
> void kfree( void *p, size_t size ); // Accepts a pointer to an
> allocated area and its size and frees the area
>
> implement the regular malloc() and free().
>
> Not very complicated, but one of a few I really liked.
As many have gathered, the solution has to allocate more memory
than requested to hold the size for kfree() (I was told not to use
*any* data structures like lists or hash tables). The solution was to
adjust the necessary alignment with #ifdefed system-dependent macros.
An interviewed person has to recognize several points:
- You are in the position of library implementor, so you *know* the
system's requirements for alignment.
- The code doesn't have to run on other platforms than those #ifdefed.
- Alignment needs to be taken care of. There are *two* alignment
issues (misalignment the are caused by adding size and sizeof(size_t)
) - one for size_t and one for the requested object.
- It's good to give at least one example of alignment rule and how the
system-dependent macro takes care about it.
/BP
Morris Dovey
> I allways ask the same thing. "please sort this list of
> numbers", something like:
>
> typedef struct _list {
>
> int a;
> struct _list next;
>
> } list;
>
> void sort(list *lp)
>
> {
>
> ...
>
> }
Scott...
I'd be interested to see how you actually sort that "list".
8^)
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Chris Torek
Scott Moore <scott....@attbi.com> writes:
>I allways ask the same thing. "please sort this list of numbers", something
>like:
>
>typedef struct _list {
> int a;
> struct _list next;
>} list;
Two problems here. First, the tag "_list" is at best inadvisable,
and possibly even reserved to the implementation (although I would
have to look at the Standard to be sure -- and if I were the
implementor I would use a name more like __list so as to avoid the
grey area in the first place). More importantly, "struct _list"
is an incomplete type at the point where a "struct _list" is being
embedded inside a "struct _list". :-)
As for sorting lists, these are perfect candidates for writing up
a short recursive merge-sort. (Or -- better yet -- googling
comp.lang.c for previously-posted merge sorts. Chuck Falconer
and I have both posted various versions, as I recall.)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
pete
> As for sorting lists, these are perfect candidates for writing up
> a short recursive merge-sort. (Or -- better yet -- googling
> comp.lang.c for previously-posted merge sorts. Chuck Falconer
> and I have both posted various versions, as I recall.)
mgsort() is my fast one.
/* BEGIN mgsort.c */
#include <stdio.h>
#include <stdlib.h>
#define E_TYPE /**/ unsigned /*/ long double /**/
typedef E_TYPE e_type;
/*
** e_type can be almost any type. If e_type is nonscalar,
** then change the GT() macro.
*/
#define GT(A, B) (*(e_type*)(A) > *(e_type*)(B))
#define SMALL_MERGE 50 /* for merge and mgsort */
#define BUF_BYTES 512
#define SWAP(A, B) \
((void)(temp = *(e_type*)(A), \
*(e_type*)(A) = *(e_type*)(B), \
*(e_type*)(B) = temp))
#define SORT_2(A, B) \
if (GT((A), (B))) { \
SWAP((A), (B)); \
};
void merge(e_type *, e_type *, size_t);
void mgsort(e_type *, size_t);
void i_sort(e_type *, size_t);
void s3sort(e_type *, size_t);
void mgsort(e_type *array, size_t nmemb)
{
e_type *arr1;
e_type buf[BUF_BYTES > sizeof *array
? BUF_BYTES / sizeof *array : 1];
if (nmemb > SMALL_MERGE) {
if (nmemb / 2 > sizeof buf / sizeof *buf) {
arr1 = malloc(nmemb / 2 * sizeof *arr1);
if (arr1) {
merge(array, arr1, nmemb);
free(arr1);
} else {
fputs("\nmalloc failure in mgsort\n", stderr);
s3sort(array, nmemb);
/*
** mgsort is a stable sort,
** but only if malloc doesn't fail.
*/
}
} else {
merge(array, buf, nmemb);
}
} else {
i_sort(array, nmemb);
}
}
void merge(e_type *base, e_type *arr1, size_t nmemb)
{
if (nmemb > SMALL_MERGE) {
e_type *arr2;
size_t const half = nmemb / 2;
e_type *const middle = base + half;
e_type *const after1 = arr1 + half;
e_type *const after2 = base + nmemb;
merge(base, arr1, half);
merge(middle, arr1, nmemb - half);
arr1 = after1;
arr2 = middle;
do {
*--arr1 = *--arr2;
} while (base != arr2);
arr2 = middle;
do {
*base++ = GT(arr1, arr2) ? *arr2++ : *arr1++;
} while (middle != base);
while (after1 != arr1 && after2 != arr2) {
*base++ = GT(arr1, arr2) ? *arr2++ : *arr1++;
}
while (after1 != arr1) {
*base++ = *arr1++;
}
} else {
i_sort(base, nmemb);
}
}
void i_sort(e_type *array, size_t nmemb)
{
e_type temp, *last, *first, *middle;
if (nmemb > 1) {
first = middle = 1 + array;
last = nmemb - 1 + array;
while (first != last) {
++first;
if (GT(middle, first)) {
middle = first;
}
}
SORT_2(array, middle);
++array;
while (array != last) {
first = array++;
if (GT(first, array)) {
middle = array;
temp = *middle;
do {
*middle-- = *first--;
} while (GT(first, &temp));
*middle = temp;
}
}
}
}
void s3sort(e_type *array, size_t nmemb)
{
e_type temp, *i, *j, *k, *after;
after = array + nmemb;
if (nmemb > (size_t)-1 / 3) {
nmemb = (size_t)-1 / 3;
}
do {
for (i = array + nmemb; i != after; ++i) {
j = i - nmemb;
if (GT(j, i)) {
k = i;
temp = *k;
do {
*k = *j;
k = j;
j -= nmemb;
} while (k >= nmemb + array && GT(j, &temp));
*k = temp;
}
}
nmemb = nmemb != 2 ? 3 * nmemb / 8 : 1;
} while (nmemb);
}
/* END mgsort.c */
--
pete
CBFalconer
> Scott Moore <scott....@attbi.com> writes:
>
> > I allways ask the same thing. "please sort this list of numbers",
> > something like:
> >
> >typedef struct _list {
> > int a;
> > struct _list next;
> >} list;
>
> Two problems here. First, the tag "_list" is at best inadvisable,
> and possibly even reserved to the implementation (although I would
> have to look at the Standard to be sure -- and if I were the
> implementor I would use a name more like __list so as to avoid the
> grey area in the first place). More importantly, "struct _list"
> is an incomplete type at the point where a "struct _list" is being
> embedded inside a "struct _list". :-)
>
> As for sorting lists, these are perfect candidates for writing up
> a short recursive merge-sort. (Or -- better yet -- googling
> comp.lang.c for previously-posted merge sorts. Chuck Falconer
> and I have both posted various versions, as I recall.)
A third problem, even after changing the next to *next. The
original specified:
> void sort(list *lp)
> {
> ...
> }
as the prototype. This will either leave the original list
pointer pointing somewhere within the sorted list, or totally
invalid. In addition the caller has no way of accessing the
sorted list. All barring ridiculous gyrations involving much data
copying.
The interface should be executed with either:
list *lp;
lp = sort(lp);
or
sort(%lp);
A fourth problem is that there is no specification of how the list
terminates. If it uses a NULL termination the above criticism
applies, but if it uses a dummy header link it does, and the code
will have to refer to globals or pass further parameters in the
recursive portion.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer
> Chris Torek wrote:
>
> > As for sorting lists, these are perfect candidates for writing up
> > a short recursive merge-sort. (Or -- better yet -- googling
> > comp.lang.c for previously-posted merge sorts. Chuck Falconer
> > and I have both posted various versions, as I recall.)
>
> mgsort() is my fast one.
>
Here are excerpts from wdfreq.c, found as a demo of hashlib at:
<http://cbfalconer.home.att.net/download/hashlib.zip>
.....
/* This type stores individual words and their counts */
typedef struct wordlink {
char *word; /* Points to the word itself */
unsigned long count; /* of occurances */
struct wordlink *next; /* Used to create a list */
} wordlink, *wordlinkp;
.....
/* 1------------------1 */
/* split list p into 2 nearly equal lists, return 2nd part */
static wordlinkp splitlist(wordlinkp p)
{
wordlinkp p1, p2, p3;
p1 = p2 = p3 = p;
if (!p) return NULL;
do {
p3 = p2;
p2 = p2->next; /* advance 1 */
p1 = p1->next;
if (p1) p1 = p1->next; /* advance 2 */
} while (p1);
/* now form new list after p2 */
p3->next = NULL; /* terminate 1st half */
return p2;
} /* splitlist */
/* 1------------------1 */
/* Merge two ordered lists into one */
static wordlinkp mergelists(wordlinkp p1, wordlinkp p2,
hshcmpfn cmp) /* compare */
{
wordlink n;
wordlinkp p;
p = &n;
n.next = p;
while (p1 && p2) {
if (cmp(p1, p2) <= 0) {
p->next = p1; p = p1; p1 = p1->next;
}
else {
p->next = p2; p = p2; p2 = p2->next;
}
}
/* at least one list now empty, copy other */
/* one or both of these operations is null */
if (p1) p->next = p1;
if (p2) p->next = p2;
/* check for empty lists */
if (n.next == &n) return NULL;
return n.next;
} /* mergelists */
/* 1------------------1 */
/* Recursively sort a linked list. The sort is stable */
/* This is an O(NlogN) process for all lists. */
static wordlinkp mergesort(wordlinkp root, hshcmpfn cmp)
{
wordlinkp p;
if (root && root->next) { /* 2 up items in list */
p = splitlist(root); /* alters list root */
root = mergelists(mergesort(root, cmp),
mergesort( p, cmp),
cmp);
}
/* else the unit or empty list is already sorted */
return root;
} /* mergesort */
/* 1------------------1 */
/* Compare the count fields, return +1, 0, -1 */
static int countcmp(void *litem, void *ritem)
{
wordlinkp li = litem,
ri = ritem;
return (li->count < ri->count) - (li->count > ri->count);
} /* hwdcmp */
.......
which then gets called with:
wordlinkp root;
/* code to form the list */
root = mergesort(root, countcmp);
.......
and what to sort on is controlled by the comparison function.
pete
>
> pete wrote:
> > Chris Torek wrote:
> >
> > > As for sorting lists,
> > mgsort() is my fast one.
> >
> ... snip code ...
> Here are excerpts from wdfreq.c, found as a demo of hashlib at:
>
> <http://cbfalconer.home.att.net/download/hashlib.zip>
Oh, ... Lists.
Thanks.
I don't know much about hashing, yet.
--
pete
Christian Bau
pete <pfi...@mindspring.com> wrote:
> Chris Torek wrote:
>
> > As for sorting lists, these are perfect candidates for writing up
> > a short recursive merge-sort. (Or -- better yet -- googling
> > comp.lang.c for previously-posted merge sorts. Chuck Falconer
> > and I have both posted various versions, as I recall.)
>
> mgsort() is my fast one.
<snipped code>
The easiest one for the lazy programmer:
1. Iterate once through the list, counting its elements.
2. malloc () an array of pointers; fill the array with pointers to the
list elements.
3. qsort () the array.
4. Use the sorted array to reconstruct the sorted list.
Giuseppe
wrote:
>guse wrote:
>> <snipped>
>> > Thank you all for the all the valuable input. One thing is clear to
>> > me that during the interview I will be asked to write some program or
>> > take some kind of test.
>
>I allways ask the same thing. "please sort this list of numbers", something
>like:
>
>typedef struct _list {
but names like _this are not reserved?
Mark
wrote:
>On Thu, 29 May 2003 06:12:20 GMT, Scott Moore <scott....@attbi.com>
>wrote:
>>typedef struct _list {
>
>but names like _this are not reserved?
7.1.3 Reserved identifiers
...
— All identifiers that begin with an underscore and either an
uppercase letter or another underscore are always reserved for any
use.
(so you should never use underscore followed by an uppercase letter)
— All identifiers that begin with an underscore are always reserved
for use as identifiers with file scope in both the ordinary and tag
name spaces.
(so its dangerous to use a name starting with an underscore, as the
implementation may use that name somewhere. )
Wolfgang Riedel
Three Problems:
what's the sizeof() of this (recursive) type?
(including next, next.next, next.next.next ...).
What he (trivially) wants is a _list*.
Wolfgang
Giuseppe
>gius...@giuseppe.wwwew (Giuseppe) wrote:
>> Is this right?
>>
>> #include <stdio.h>
>> #include <stddef.h>
>>
>> static struct al_sz_ {
>> size_t size;
>> union {long double y; unsigned long ul;} align;
>> };
>> static size_t s_=offsetof(struct al_sz_, align);
>
>Close, but no cigar. This may very well kill performance on an x86
>system, and introduce a terrible bug on PowerPC systems. Actually, it
>might introduce the same bug on an x86 system as well, and the
>performance loss could be there on PowerPC systems, but likely less
>noticable.
>
>First rule of programming: Before you start typing code, find out what
>the requirements are.
Why is this wrong in a PowerPC?
Is there "performance loss"? Why?
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <time.h>
#define P printf
#define R return
#define W while
#define F for
#ifndef SIZE_MAX
#define SIZE_MAX ((size_t)-1)
#endif
/* This is the malloc of the system */
void* kmalloc(size_t size){return malloc(size);}
/* This is the free of the system */
void kfree(void* p, size_t size){free(p);}
static struct al_sz_ {
size_t size;
union {long double y;
unsigned long ul;
int i;
double d;
float f;
size_t s;
void* v;
char c;
short h;
int (*fun)(int);
}align;
};
static size_t s_=offsetof(struct al_sz_, align);
/* This is the malloc in exercise */
void* malloc_(size_t sz)
{char *data;
size_t si;
si=(SIZE_MAX-s_<sz)? 0 : sz+s_;
if(si==0) R 0;
if( (data=kmalloc(si)) == 0)
R 0;
*(size_t*)data=si;
R data += s_;
}
/* This is the free in exercise */
void free_(void* p)
{if(p==0) R;
kfree( (char*)p-s_, *(size_t*)((char*)p-s_) );
}
size_t get_size(void* pnt)
{if(pnt==0) return 0;
R *(size_t*)((char*)pnt-s_)-s_;
}
/* This 'main()' is only for my system */
int main()
{unsigned *ii, j;
size_t jj=s_;
char *h;
time_t ti, tf;
P("align=%lu\n", (unsigned long) jj);
ii=malloc_(9);
*ii=5672;
h=ii;
P("*ii=%u, %d %d %d %d %d *ii=%u ii=%p\n", *ii,
*(h+0), *(h+1), *(h+2), *(h+3),*(h+4), *(unsigned*) h, (void*) ii);
P("size_byte=%d %d %d %d %d\n",
*(h-8), *(h-7), *(h-6), *(h-5), *(h-4) );
j=get_size(ii);
P("size=%u\n", j);
free_(ii);
P("dopo free_\n");
/* danger, here I see ii Free-------------------------- */
h=(char*)ii-s_;
P("Free *ii=%u, %d %d %d %d %d *ii_primo=%u ii=%p\n", *ii,
*(h+0), *(h+1), *(h+2), *(h+3),*(h+4), *(unsigned*) h, (void*) ii);
/* ---------------------------------------------------- */
ii=malloc(17);
h=ii;
*ii=5672;
P("*ii=%u, %d %d %d %d %d *ii=%u ii=%p\n", *ii,
*(h+0), *(h+1), *(h+2), *(h+3),*(h+4), *(unsigned*) h, (void*) ii );
free(ii);
/* danger, here I see ii free-------------------------- */
h=ii;
P("free= *ii=%u, %d %d %d %d %d *ii_primo=%u ii=%p\n", *ii,
*(h+0), *(h+1), *(h+2), *(h+3),*(h+4), *(unsigned*)h, (void*) ii);
/* ---------------------------------------------------- */
{double *oo;
oo=malloc_(2*sizeof(double));
*oo=7.3; *(oo+1)=1.3;
j=get_size(oo);
P("2*size_double=%u altra=%u\n", j, (unsigned) sizeof(double)*2 );
P("double=%lf \n", *(oo+1));
free_(oo);
}
ii=malloc_(30 * sizeof(unsigned));
F(j=0; j<30; ++j) ii[j]=j;
ti=time(0);
F(j=0; j<30000000; ++j)
ii[j%30]=j+j%(ii[j%23]+1);
P("ii[7]=%u\n", ii[7]);
free_(ii);
tf=time(0);
P("NOT tf-ti=%u\n", (unsigned)(tf-ti) );
ii=malloc(30 * sizeof(unsigned));
F(j=0; j<30; ++j) ii[j]=j;
ti=time(0);
F(j=0; j<30000000; ++j)
ii[j%30]=j+j%(ii[j%23]+1);
P("ii[7]=%u\n", ii[7]);
free(ii);
tf=time(0);
P("tf-ti=%u\n", (unsigned)(tf-ti) );
R 0;
}
Paul Hsieh
How about this?
#define ALIGN_SZ (... whatever it is ...)
struct mallocHeader {
size_t sz;
void * p;
};
#define max(a,b) (((a) > (b)) ? (a) : (b))
#define ROUND_DN(x) ((x) - ((x) % (ALIGN_SZ)))
#define ROUND_UP(x) ROUND_DN ((x) + ALIGN_SZ-1)
#define BACK_UP max (ALIGN_SZ, ROUND_UP(sizeof (struct mallocHeader)))
#define ALIGN_EXTRA (BACK_UP + ALIGN_SZ - 1)
void * malloc (size_t s) {
void * p;
struct mallocHeader * q;
unsigned int x;
/* if (s == 0) return NULL; */
s += ALIGN_EXTRA;
p = kmalloc (s);
if (p == NULL) return NULL;
x = ((unsigned int) p) + ALIGN_EXTRA;
x = ROUND_DN (x);
q = (struct mallocHeader *) (x - BACK_UP);
q->sz = s;
q->p = p;
return (void *) x;
}
void free (void *p) {
struct mallocHeader * q;
if (p) {
q = (struct mallocHeader *) ((unsigned int) p - BACK_UP);
kfree (q->p, q->sz);
}
}
--
Paul Hsieh
http://bstring.sourceforge.net/
http://www.pobox.com/~qed/
Christian Bau
gius...@giuseppe.wwwew (Giuseppe) wrote:
> Christian Bau <christ...@cbau.freeserve.co.uk> wrote:
> >gius...@giuseppe.wwwew (Giuseppe) wrote:
> >> Is this right?
> >>
> >> #include <stdio.h>
> >> #include <stddef.h>
> >>
> >> static struct al_sz_ {
> >> size_t size;
> >> union {long double y; unsigned long ul;} align;
> >> };
> >> static size_t s_=offsetof(struct al_sz_, align);
> >
> >Close, but no cigar. This may very well kill performance on an x86
> >system, and introduce a terrible bug on PowerPC systems. Actually, it
> >might introduce the same bug on an x86 system as well, and the
> >performance loss could be there on PowerPC systems, but likely less
> >noticable.
> >
> >First rule of programming: Before you start typing code, find out what
> >the requirements are.
>
> Why is this wrong in a PowerPC?
> Is there "performance loss"? Why?
If you don't know, then you cannot assume that there is no performance
loss, so you shouldn't write code like this.
Bug: If your program uses Altivec (PowerPC) or SSE2 (x86) and relies on
malloc returning memory aligned to 16 byte boundaries then this will
fail terribly. Performance loss: If your x86 compiler uses 80 bit long
double with only four byte alignment (because they have twelve bytes and
you don't want to waste four bytes for each), then quite possibly you
add four bytes offset. Any idea what that does to the performance of 64
bit doubles that are suddenly not eight byte aligned anymore?
> #include <stdio.h>
> #include <stdlib.h>
> #include <stddef.h>
> #include <time.h>
> #define P printf
> #define R return
> #define W while
> #define F for
Anyone who uses #define's like this should not be allowed to ever write
any C software.
pete
He's been told before, repeatedly.
--
pete
CBFalconer
> gius...@giuseppe.wwwew (Giuseppe) wrote:
>
... snip ...
>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <stddef.h>
> > #include <time.h>
> > #define P printf
> > #define R return
> > #define W while
> > #define F for
>
> Anyone who uses #define's like this should not be allowed to
> ever write any C software.
He has been told before and insists. I, and most of the regulars,
never see it due to the efficiency of our PLONK mechanisms. I
suggest you do likewise.
Black Phantom
> Regarding Black Phantom's kmalloc/kfree -> malloc/free question:
>
> How about this?
[code snipped]
Seems a fine example for a system with pretty understandable rules.
BTW, one of my friends passed an interview for another company, who
"stole" (or got from the same source) that question. After he came up
with a similar idea, his next task was to educate the interviewer what
alignment was and why it had to be treated.
Happens, but better be prepared for that one on an interview, too! :-)
/BP
Richard Heathfield
<snip>
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <stddef.h>
> #include <time.h>
> #define P printf
> #define R return
> #define W while
> #define F for
This would make an excellent interview question. After all, if your
candidate thinks this kind of code is reasonable, it would be good to find
out /before/ you hire him.
<snip>
--
Richard Heathfield : bin...@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
Christian Bau
Richard Heathfield <dont...@address.co.uk.invalid> wrote:
> Giuseppe wrote:
>
> <snip>
> >
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <stddef.h>
> > #include <time.h>
> > #define P printf
> > #define R return
> > #define W while
> > #define F for
>
> This would make an excellent interview question. After all, if your
> candidate thinks this kind of code is reasonable, it would be good to find
> out /before/ you hire him.
Most employment contracts have a clause that allows both employer and
employee to quit without any reason and without any notice within lets
say one month.
I personally know of two cases where this right was used within the
first two hours; once by an employer, once by an employee.
Giuseppe
#include <stdlib.h>
#include <stddef.h>
#include <time.h>
#define P printf
#define R return
#define W while
#define F for
#ifndef SIZE_MAX
#define SIZE_MAX ((size_t)-1)
#endif
/* This is the malloc of the system */
void* kmalloc(size_t size){return malloc(size);}
/* This is the free of the system */
void kfree(void* p, size_t size){free(p); P("siz=%lu \n", size);}
size_t gcd(size_t u, size_t v)
{size_t t;
if(!v) R 0;
W(0<u)
{if(u<v)
{t=u; u=v; v=t;}
u=u%v;
}
R v;
}
size_t mcm(size_t a, size_t b)
{size_t z=gcd(a,b);
if(a==0||b==0||z==0) R 0;
z=b/z;
R a*z;
}
static size_t s_;
static size_t maxn;
/* This is the malloc in exercise */
void* malloc_(size_t sz)
{static int sk=0;
char *data, *c;
size_t si;
if(sk==0){char *pi, *qi;
if((pi=kmalloc(1))==0)
R 0;
if((qi=kmalloc(1))==0)
{kfree(pi, 1); R 0;}
s_=gcd( (size_t) pi, (size_t) qi );
kfree(pi, 1); kfree(qi, 1);
maxn=s_+sizeof(size_t);
sk=1;
}
si = ( SIZE_MAX - maxn < sz )? 0: sz + maxn;
if(si==0) R 0;
if( (data=kmalloc(si)) == 0)
R 0;
*(size_t*)data=si;
F(c=data+sizeof(size_t); ; ++c)
{if( ((size_t) c) % s_ == 0) break;
else if(c-data>maxn)
{kfree( data, si ); R 0;}
}
R c;
}
/* This is the free in exercise */
void free_(void* p)
{char *c;
size_t i, sz;
if(p==0) R;
F(c=(char*)p-sizeof(size_t);;--c)
{if( (size_t)c % s_== 0) break;
else if( (char*)p-c > maxn ) R;
}
kfree( c, *(size_t*)c );
}
size_t get_size(void* p)
{char *c;
size_t sz;
if(p==0) R 0;
F(c=(char*)p-sizeof(size_t);;--c)
{if( (size_t)c % s_==0) break;
else if( (char*)p-c > maxn)
R 0;
}
sz = *(size_t*)c;
sz -= maxn;
R sz;
}
/* This main is only for my system */
int main()
{unsigned *ii, j;
size_t jj=s_;
char *h;
time_t ti, tf;
ii=malloc_(9);
if(ii==0) exit(0);
*ii=5672;
h=ii;
P("*ii=%u, %d %d %d %d %d *ii=%u ii=%u\n", *ii,
*(h+0), *(h+1), *(h+2), *(h+3),*(h+4), *(unsigned*) h,
(unsigned)(void*) ii);
P("size_byte=%d %d %d %d %d\n",
*(h-8), *(h-7), *(h-6), *(h-5), *(h-4) );
j=get_size(ii);
P("size=%u\n", j);
free_(ii);
P("dopo free_\n");
/* danger, here I see ii Free-------------------------- */
h=(char*)ii-8;
P("Free *ii=%u, %d %d %d %d %d *ii_primo=%u ii=%u\n", *ii,
*(h+0), *(h+1), *(h+2), *(h+3),*(h+4), *(unsigned*) h, (unsigned)
ii);
/* ---------------------------------------------------- */
ii=malloc(17);
if(ii==0) exit(0);
h=ii;
*ii=5672;
P("*ii=%u, %d %d %d %d %d *ii=%u ii=%u\n", *ii,
*(h+0), *(h+1), *(h+2), *(h+3),*(h+4), *(unsigned*) h, (unsigned)
ii );
free(ii);
/* danger, here I see ii free-------------------------- */
h=ii;
P("free= *ii=%u, %d %d %d %d %d *ii_primo=%u ii=%u\n", *ii,
*(h+0), *(h+1), *(h+2), *(h+3),*(h+4), *(unsigned*)h, (unsigned)
ii);
/* ---------------------------------------------------- */
{double *oo;
oo=malloc_(2*sizeof(double));
*oo=7.3; *(oo+1)=1.3;
j=get_size(oo);
P("2*size_double=%u altra=%u\n", j, (unsigned) sizeof(double)*2 );
P("double=%lf \n", *(oo+1));
free_(oo);
}
{long double *ii;
ii=malloc_(30 * sizeof(long double));
F(j=0; j<30; ++j) ii[j]=j;
ti=time(0);
F(j=0; j<30000000; ++j)
ii[j%30]=j+ii[j%21]*(j%((unsigned)ii[j%23]+1));
P("ii[7]=%lf\n", ii[7]);
free_(ii);
tf=time(0);
P(" tf-ti=%u\n", (unsigned)(tf-ti) );
ii=malloc(30 * sizeof(long double));
F(j=0; j<30; ++j) ii[j]=j;
ti=time(0);
F(j=0; j<30000000; ++j)
ii[j%30]=j+ii[j%21]*(j%((unsigned)ii[j%23]+1));
P("ii[7]=%lf\n", ii[7]);
free(ii);
tf=time(0);
P(" sys tf-ti=%u\n", (unsigned)(tf-ti) );
}
R 0;
}
Joona I Palaste
> #include <stdio.h>
> #include <stdlib.h>
> #include <stddef.h>
> #include <time.h>
> #define P printf
> #define R return
> #define W while
> #define F for
For the umpteenth time, would you *PLEASE* stop with all this
obfuscated #define crap?
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp
Martin Ambuhl
> Giuseppe <gius...@giuseppe.wwwew> scribbled the following:
>
>>#include <stdio.h>
>>#include <stdlib.h>
>>#include <stddef.h>
>>#include <time.h>
>>#define P printf
>>#define R return
>>#define W while
>>#define F for
>
>
> For the umpteenth time, would you *PLEASE* stop with all this
> obfuscated #define crap?
Don't worry. Even with the code deobfuscated, it is replete with
incompatable pointer assignments, incorrect printf specifiers, and the
like. You miss nothing by just skipping this crap-for-code.
--
Martin Ambuhl
now exiled to
Armpit of the Universe, Texas
Christian Bau
gius...@giuseppe.wwwew (Giuseppe) wrote:
> #include <stdio.h>
> #include <stdlib.h>
> #include <stddef.h>
> #include <time.h>
> #define P printf
> #define R return
> #define W while
> #define F for
Do you think anyone reads on after crap like this?
Giuseppe
>Giuseppe wrote:
>> #include <stdlib.h>
>> #include <stddef.h>
>> #include <time.h>
>> #define P printf
>> #define R return
>> #define W while
>> #define F for
>
>This would make an excellent interview question. After all, if your
>candidate thinks this kind of code is reasonable, it would be good to find
>out /before/ you hire him.
I've decided:
I write code in that manner,
I post code in that manner HERE (don't matter who is scandalized or
who read what I write), in another contest (not in a NG) I put my mask
on, and use a program that remove these defines and indent :))
Giuseppe
>> Giuseppe <gius...@giuseppe.wwwew> scribbled the following:
>>>#include <stdio.h>
>>>#include <stdlib.h>
>>>#include <stddef.h>
>>>#include <time.h>
>>>#define P printf
>>>#define R return
>>>#define W while
>>>#define F for
>You miss nothing by just skipping this crap-for-code.
For this time you are right and there are errors that I can't
correct (in malloc_()); For P()==printf(), that is "test code" in my
pc; ("test code"==not portable and most variable) in this I'm not so
strict.
pete
>
> On Sun, Richard Heathfield <dont...@address.co.uk.invalid> wrote:
> >Giuseppe wrote:
> >> #include <stdio.h>
> >> #include <stdlib.h>
> >> #include <stddef.h>
> >> #include <time.h>
> >> #define P printf
> >> #define R return
> >> #define W while
> >> #define F for
> I write code in that manner,
It is not disputed that you write code in that manor.
It's a bad way to write code.
That's the point.
It's very easy to prove
that you have been posting code like that,
since well before it was a regular practice of yours.
Obviously, your writing style doesn't come naturally to you.
It's just deliberately dopey.
Your sedulous incredulity is incredible.
--
pete
Giuseppe
wrote:
Are you joke?
it is a year that I do code with these macros and everything is well
(and all is fast) and perhaps these my progs *calculate* better than
yours
>It's just deliberately dopey.
>Your sedulous incredulity is incredible.
Di parlare parlate molto, ma in quanto a programmazione le poche cose
veramente belle non provengono da voi che vi piace il fascio
>--
>pete
Giuseppe
wrote:
>veramente belle non provengono da voi che
>vi piace il fascio
vi piace il fascio==fascisti
>>--
>>pete
Richard Heathfield
Well, I don't speak whatever language that is (Italian?), but I think
Godwin's Law applies.
pete
I believe we can both agree that everyone's own writing style,
is the writing style which is the easiest to read.
I can group all writing style into two kinds, mine and not mine.
My trick, is that I when I change my style to more closely
match what seems to be most common, then everyone else's code
automatically becomes easier for me to read.
Believe it or not, conformity has value for it's own sake.
Your style of writing indicates that you are an individualist
and this concept must be anathema for you.
I have to tell you just how bad your style is.
I was going to respond to one of Joona's posts
and say that I thought that he was going a little overboard,
because I don't like to read posters complaining about
other posters, but that would just be me complaining
about him complaining about you, and that's even worse.
The fact is that your post literally made me grimace and cringe.
When I see your name on a post, I know that those macros are
going to be there. I hope that they're not, but then when I open
the post and there they are, time after time, it crushes all hope,
and then Joona gets upset ;)
--
pete
Christian Bau
Richard Heathfield <dont...@address.co.uk.invalid> wrote:
> Giuseppe wrote:
>
> > On Wed, 04 Jun 2003 17:26:20 GMT, gius...@giuseppe.wwwew (Giuseppe)
> > wrote:
> >
> >>veramente belle non provengono da voi che
> >>vi piace il fascio
> >
> > vi piace il fascio==fascisti
>
> Well, I don't speak whatever language that is (Italian?), but I think
> Godwin's Law applies.
Whatever language it is, it easier to understand than when he tries to
use the C language :-(
Mark McIntyre
gius...@giuseppe.wwwew (Giuseppe) wrote:
>On Sun, Richard Heathfield <dont...@address.co.uk.invalid> wrote:
>>Giuseppe wrote:
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <stddef.h>
>>> #include <time.h>
>>> #define P printf
>>> #define R return
>>> #define W while
>>> #define F for
>>
>>This would make an excellent interview question. After all, if your
>>candidate thinks this kind of code is reasonable, it would be good to find
>>out /before/ you hire him.
>
>I've decided:
>I write code in that manner,
Then you're probably unemployable. No employer isgoing to accept such
gratuitous obfuscation.
>I post code in that manner HERE (don't matter who is scandalized or
>who read what I write),
Then you're two idiots. If you want people to help you with problems
here, post in comprehensible C.
Basically, stop being clever for its own sake. Its not grown up.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Mark McIntyre
gius...@giuseppe.wwwew (Giuseppe) wrote:
>
>Di parlare parlate molto, ma in quanto a programmazione le poche cose
>veramente belle non provengono da voi che vi piace il fascio
Being rude and burbly in italian gets you killfiled just as fast as in
english. Some of us are multilingual.
*plonk*
Default User
Mark McIntyre wrote:
>
> On Wed, 04 Jun 2003 17:26:20 GMT, in comp.lang.c ,
> gius...@giuseppe.wwwew (Giuseppe) wrote:
>
> >
> >Di parlare parlate molto, ma in quanto a programmazione le poche cose
> >veramente belle non provengono da voi che vi piace il fascio
>
> Being rude and burbly in italian gets you killfiled just as fast as in
> english. Some of us are multilingual.
Oh, see now you made me go and run the paragraph through the translator:
To speak to speeches a lot, but in as far as programming the little
truly beautiful things they do not come from you that it appeals to the
bundle to you
The fiend.
Brian Rodenborn
Morris Dovey
> Whatever language it is, it easier to understand than when he
> tries to use the C language :-(
ROFL - true.
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Mark McIntyre
See, thats the problem with translation programmes, no good at the
colloquialisms :-) Try translating something english->italian->english
some time !
And no, I'm not going to translate the original colloquially, my
italian translator has gone to bed, and I can't remember what she told
me it meant, and if I woke her up to ask, then there'd be no
provengono for weeks iyswim.
Giuseppe
>> >Giuseppe wrote:
>> >> On Sun, Richard Heathfield <dont...@address.co.uk.invalid> wrote:
>> >> >Giuseppe wrote:
>> >> >> #include <stdio.h>
>> >> >> #include <stdlib.h>
>> >> >> #include <stddef.h>
>> >> >> #include <time.h>
>> >> >> #define P printf
>> >> >> #define R return
>> >> >> #define W while
>> >> >> #define F for
>> >
>> >> I've decided:
>> >> I write code in that manner,
>> >
>> >It is not disputed that you write code in that manor.
>> >It's a bad way to write code.
>> >That's the point.
>> >
>> >It's very easy to prove
>> >that you have been posting code like that,
>> >since well before it was a regular practice of yours.
>> >
>> >http://groups.google.com/groups?q=Giuseppe+merit+pete+group:comp.lang.c.*&hl=en&lr=&ie=UTF-8&group=comp.lang.c.*&selm=3E710AB9.69E3%40mindspring.com&rnum=1
>> >
>> >Obviously, your writing style doesn't come naturally to you.
>>
>> Are you joke?
'Are you joking?'
>I believe we can both agree that everyone's own writing style,
>is the writing style which is the easiest to read.
>
>I can group all writing style into two kinds, mine and not mine.
I can group all algo and tricks in two kinds: the ones that I know and
the ones that I don't know (that are a problem); 'styles' doesn't
matter for me (for majority I think too).
>My trick, is that I when I change my style to more closely
>match what seems to be most common, then everyone else's code
>automatically becomes easier for me to read.
>
>Believe it or not, conformity has value for it's own sake.
>Your style of writing indicates that you are an individualist
>and this concept must be anathema for you.
>I have to tell you just how bad your style is.
>I was going to respond to one of Joona's posts
>and say that I thought that he was going a little overboard,
>because I don't like to read posters complaining about
>other posters, but that would just be me complaining
>about him complaining about you, and that's even worse.
>
>The fact is that your post literally made me grimace and cringe.
>When I see your name on a post, I know that those macros are
>going to be there. I hope that they're not, but then when I open
>the post and there they are, time after time, it crushes all hope,
>and then Joona gets upset ;)
Perhaps I had drunk too many coffees: excuse me.
pete
>
> On Wed, 04 Jun 2003 10:57:40 -0400, pete <pfi...@mindspring.com>
> wrote:
>
> >Giuseppe wrote:
> >>
> >> On Sun, Richard Heathfield <dont...@address.co.uk.invalid> wrote:
> >> >Giuseppe wrote:
> >> >> #include <stdio.h>
> >> >> #include <stdlib.h>
> >> >> #include <stddef.h>
> >> >> #include <time.h>
> >> >> #define P printf
> >> >> #define R return
> >> >> #define W while
> >> >> #define F for
> Are you joke?
> it is a year that I do code with these macros and everything is well
> (and all is fast) and perhaps these my progs *calculate* better than
> yours
When you become a big famous programmer,
you can look back derisively on this day
and recall how I refered to your work as
"The Source Code Of A Thousand Tears."
--
pete
Richard Heathfield
We can't stop you making an idiot of yourself in public, so I for one won't
try. What I can do is draw the attention of newbies to the deficiencies in
your code. So I'll do that instead.
Using these idiotic macros makes your code hard to read and hard to
maintain. Anyone who did this in a sensible commercial organisation would
be fired fairly quickly if they didn't mend their ways.