Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

Should you dereference function pointers?

Name: Anonymous 2009-11-04 19:33

#include <stdio.h>

void func() {
  printf("hello world\n");
}

void (*go)() = func;

int main() {
  go();    // number 1...
  (*go)(); // or number 2
  return 0;
}

Which is correct ANSI C89? GCC accepts both, even in -ansi -pedantic; it outputs hello world twice.

Name: Anonymous 2009-11-04 19:35

Oh, also, should you take the address of the function or no?


void (*a)() = func;
void (*b)() = &func;

Name: Anonymous 2009-11-04 19:46

>>1
Number 1 is the preferred method. If you had the address of a function pointer, you would have to use number 2, even though as you pointed out number 2 works fine for just a regular function pointer as well.

>>2
I would use the second line, since it's making clear that you're taking the address of something

Name: Anonymous 2009-11-04 20:43

>>1,2
Shouldn't that be == instead of =?

Name: Anonymous 2009-11-04 20:47

ITT: bitches don't know C

Name: Anonymous 2009-11-04 20:50

>>4
Disregard that, I don't know what I was thinking about.

Name: Anonymous 2009-11-04 21:09

HACKERS AND ANAL RAPISTS

Name: Anonymous 2009-11-05 4:31

>>1
Use 1.
>>2
Use a.

Name: Anonymous 2009-11-05 4:38

what would you do with a pointer if you didn't dereference it?
>>1,2
first one is superior.

Name: Anonymous 2009-11-05 6:17

>>9
test it's NULL

Name: Anonymous 2009-11-05 13:33

>>10
What about it is null?

Wait.

Name: Anonymous 2009-11-05 18:16

int array[20];
int *p1 = array;
int *p2 = &array;
int *p3 = &array[0];

Choose wisely.

Name: Anonymous 2009-11-05 18:22

>>12
p1
what kind of cubic anus would use the other choices?

Name: Anonymous 2009-11-05 18:37

>>13
i lol'd

Name: Anonymous 2009-11-05 18:48

int array[20];
int **p1 = *array;

Name: Anonymous 2009-11-05 19:06

>>15
An array of pointers to strings?

Name: Anonymous 2009-11-05 19:27

>>13
int *p3 = &array[0] is valid. So a jerk, really.

Name: Anonymous 2009-11-05 19:50

>>17
That is actually a way to make pointer arithmetic on arrays a lot less obtuse.

int *p3 = &array[4]

is easier to read and faster to type than

int *p3 = array + (sizeof(int) * 4)

Name: Anonymous 2009-11-05 20:15

>>18
errrr... i think you mean
int *p3 = array + 4;
if you use
int *p3 = array + (sizeof(int) * 4)
you get the 16th element of the array.

Name: Anonymous 2009-11-05 20:22

>>19
maybe he meant
int *p3 = ((void) array) + (sizeof(int) * 4);

Name: Anonymous 2009-11-05 20:42

>>13
As a Seppler, &array[0] can be useful for accessing a std::vector as a C array.
It's probably considered harmful but I don't give a rat's ass.

Name: Anonymous 2009-11-05 21:23

>>21
Well, vector<T>::operator[] is overloaded to simply return a reference. Depending on how the underlying container is implemented, it can indeed be harmful. Invalid pointers, for instance, can occur if the vector's memory is relocated upon resizing.

Other containers, like deque<T> and list<T> are implemented as linked lists, so trying to access them as a C array doesn't even make sense.

Name: Anonymous 2009-11-06 4:00

>>18
Yeah, you're doing it wrong. It's array + 4, which is nicer than &array[4].

>>21
It's not harmful at all. The vector is required to be contiguous. In fact it's quite normal to do this with vectors of POD, as long as you don't keep the pointer around when you modify the vector (that should be obvious; the spec defines exactly which modifications invalidate pointers if you want more specifics). Typically you should check that the vector is non-empty though, because otherwise the access might be out of bounds. (The compiler optimizes away the dereferencing in return, but it's still technically undefined behaviour because you're dereferencing invalid memory. In some implementations, if you haven't put anything in the vector yet it won't even have allocated any memory, and the pointer could point anywhere!)

http://www.parashift.com/c++-faq-lite/containers.html#faq-34.3

Name: Anonymous 2009-11-06 4:09

>>22
Oh wow, I didn't realize deque<T> wasn't continuous until you mentioned. At work we wrote our own deque which is contiguous, and we use the &array[0] trick for memcpy and shit; I just assumed deque<T> worked the same way.

Anyway as a side note, the only other container in STL that is contiguous is basic_string<T>.

Name: Anonymous 2009-11-06 4:15

>>23
>>22 here, I would edit my post to reflect that information, but I /prog/ doesn't seem to have an edit post button

Name: Anonymous 2009-11-06 6:49

>>24
That's because basic_string is implemented as a vector.

Name: Anonymous 2009-11-06 10:41

>>25
I would edit your post to reflect DICKS, but I /prog/ doesn't seem to have an edit post button

Name: Anonymous 2009-11-06 11:23

>>24
At work we wrote our own deque which is contiguous
Am I correct to assume that your pop() works in linear time but you don't even know what that means because you are cool hackers who implement their own super-fast deque with direct element access and can't be bothered with abstract bullshite that makes stl so slow (not that you ever actually compared performance)?

Name: Anonymous 2009-11-06 11:32

>>6
you were dreaming of cocks drifting across the blue sky.

Name: !7IrmLLKrk2 2009-11-06 12:05

No.

Name: Anonymous 2009-11-06 12:27

oh yes !

Name: Anonymous 2009-11-06 12:29

sex, dftl

Name: Anonymous 2009-11-06 19:29

>>28
No, pop() is O(1) from either end obviously. We didn't write it to be faster than STL; we wrote it because we don't *have* STL, because it's for embedded devices (and existing solutions like ustl just plain suck).

Name: Anonymous 2009-11-07 6:53

>>33
c++ for embedded devices? my mind has just blown

Name: Anonymous 2009-11-07 14:01

Function pointers are special in C.  Any value with function type is automatically converted to the pointer to that function.

[code]
#include <stdio.h>
void func(void) { }

int main(int argc, char *argv[])
{
    if (func == *func) puts("func == *func");
    if (func == &func) puts ("func == &func");
    return 0;
}
[\code]

Compile the above.  No type errors.  Run it.  It prints both messages.

Name: Anonymous 2009-11-07 14:03

>>34
How else would one follow Enterprise Best Practices in an embedded environment?

Name: Anonymous 2009-11-07 14:29

>>35
special
U MENA RETARDED
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -