Warning when building!

This is a discussion on Warning when building! within the C Programming forums, part of the General Programming Boards category; Originally posted by Polymorphic OOP yup, my mistake, sorry about that. It's too late at night here, heh unsigned char* ...

  1. #16
    Registered User
    Join Date
    Feb 2003
    Posts
    63
    Originally posted by Polymorphic OOP
    yup, my mistake, sorry about that. It's too late at night here, heh

    unsigned char* thru_ptr;

    thru_ptr = map[PartIndex]+1;

    Why were you adding 4!? that would put you four pointers ahead, not 1 pointer ahead. Pointer arithmetic goes by the size of the type being pointed to. Using + 1 will move you sizeof( unsigned char* ) bytes ahead, which will usually be 4 bytes. If you add 4 like your example, you'd actually be adding 4 * sizeof( unsigned char* ) bytes, whihc would usually be 16 bytes.
    The only code that is working properly is:

    unsigned char* thru_ptr;

    * (int *) thru_ptr = (int)(map[PartIndex]+4 );

    I am adding 4 because thru_ptr is defined as char, at least I think so and it works ;-)
    You cantīt teach an old dog new tricks.

  2. #17
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    if thru_ptr is defined as a char, then you are not coding properly. Also, that wouldn't affect the arithmetic part on the right.

  3. #18
    Registered User
    Join Date
    Feb 2003
    Posts
    63
    Originally posted by Polymorphic OOP
    if thru_ptr is defined as a char, then you are not coding properly. Also, that wouldn't affect the arithmetic part on the right.
    It's defined as char because 99% of the things I want to save (read MIDI events) is bytes.

    Here is the memory area with the pointer to the part and another pointer that points to the first byte after itself (where the first MIDI bytes is to be saved):

    (gdb) x/32 map
    0x15a1030: 0x01893000 0xffffffff 0xffffffff 0xffffffff
    0x15a1040: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
    0x15a1050: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
    0x15a1060: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
    0x15a1070: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
    0x15a1080: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
    0x15a1090: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
    0x15a10a0: 0xffffffff 0xffffffff 0xffffffff 0xffffffff

    (gdb) x/32 map[0]
    0x1893000: 0x01893004 0x00000000 0x00000000 0x00000000
    0x1893010: 0x00000000 0x00000000 0x00000000 0x00000000
    0x1893020: 0x00000000 0x00000000 0x00000000 0x00000000
    0x1893030: 0x00000000 0x00000000 0x00000000 0x00000000
    0x1893040: 0x00000000 0x00000000 0x00000000 0x00000000
    0x1893050: 0x00000000 0x00000000 0x00000000 0x00000000
    0x1893060: 0x00000000 0x00000000 0x00000000 0x00000000
    0x1893070: 0x00000000 0x00000000 0x00000000 0x00000000
    You cantīt teach an old dog new tricks.

  4. #19
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    You are missing the point completely. The right side of that assigment does NOT result in a char, it results in a POINTER to an unsigned char. If you want the data to be a an unsigned char, then map should be defined as a pointer to an unsigned char NOT a pointer to a pointer to an unsigned char. Either that or you should dereference the pointer before assigning. Your typecasting makes absolutely no logical sense.

    edit:

    pointer that points to the first byte after itself
    Why would you have a pointer always point to the first byte after itself? that doesn't really make any sense to do.
    Last edited by Polymorphic OOP; 02-12-2003 at 05:30 AM.

  5. #20
    Registered User
    Join Date
    Feb 2003
    Posts
    63
    Originally posted by Polymorphic OOP
    You are missing the point completely. The right side of that assigment does NOT result in a char, it results in a POINTER to an unsigned char. If you want the data to be a an unsigned char, then map should be defined as a pointer to an unsigned char NOT a pointer to a pointer to an unsigned char. Either that or you should dereference the pointer before assigning. Your typecasting makes absolutely no logical sense.

    edit:



    Why would you have a pointer always point to the first byte after itself? that doesn't really make any sense to do.
    Well, I can't comment the first thing you wrote because I am new to C programming and don't understand at this moment what you mean.

    But I can tell why I have a pointer that points to the first byte after itselfs.

    First of all, the pointer does NOT always point to the first byte after itselfs. Example:

    CoreMIDI works by asigning a timestamp value to the MIDI message. I send that timestamp and MIDI message to CoreMIDI. That's the only thing my app must do. To send this MIDI message out to my interfaces is a thing Mac OS X does all by itself. So I can que a lot of MIDI events at different timestamps and OS X just sends them out at exactly the right time. I don't even have to que them in timestamp order. OSX does that for me.

    So why the pointer? I have a timer that wake up once every second. This code is que'ing MIDI messages to be sent out by OS X sometime in the near future (within 2 sec). There are at least 2 options to do that. Either search all timestamps from the beginning until we find the right one to send out (I will not need the pointer in that case, but it will take a long time to search every part from the beginning). Or save a pointer so the next time the timer fire we just get that pointer and we are at the right place in the part very quick.

    I hope that makes sense to you :-)
    You cantīt teach an old dog new tricks.

  6. #21
    Registered User
    Join Date
    Feb 2003
    Posts
    63
    Originally posted by electrolove
    Well, I can't comment the first thing you wrote because I am new to C programming and don't understand at this moment what you mean.

    But I can tell why I have a pointer that points to the first byte after itselfs.

    First of all, the pointer does NOT always point to the first byte after itselfs. Example:

    CoreMIDI works by asigning a timestamp value to the MIDI message. I send that timestamp and MIDI message to CoreMIDI. That's the only thing my app must do. To send this MIDI message out to my interfaces is a thing Mac OS X does all by itself. So I can que a lot of MIDI events at different timestamps and OS X just sends them out at exactly the right time. I don't even have to que them in timestamp order. OSX does that for me.

    So why the pointer? I have a timer that wake up once every second. This code is que'ing MIDI messages to be sent out by OS X sometime in the near future (within 2 sec). There are at least 2 options to do that. Either search all timestamps from the beginning until we find the right one to send out (I will not need the pointer in that case, but it will take a long time to search every part from the beginning). Or save a pointer so the next time the timer fire we just get that pointer and we are at the right place in the part very quick.

    I hope that makes sense to you :-)
    Maybe it's a better idea to have 2 separate pointer lists. First list for 1024 pointers to different memory areas where the part is recorded. And the second list for 1024 pointers that is the actual play pointer?

    Better or worse?
    You cantīt teach an old dog new tricks.

  7. #22
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    just make a struct which has both and make a single array of those

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 10
    Last Post: 07-10-2008, 04:45 PM
  2. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 03:39 PM
  3. <Gulp>
    By kryptkat in forum Windows Programming
    Replies: 7
    Last Post: 01-14-2006, 01:03 PM
  4. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 07:39 AM
  5. Interface Question
    By smog890 in forum C Programming
    Replies: 11
    Last Post: 06-03-2002, 06:06 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21