casting?

Btw, I want to explicitely 'hide' my structure.

Let say I have a structure:

Code:

---

typedef struct
{
    void *base;
    unsigned short initialSize;
    unsigned short increment;
    unsigned int allocated;
    unsigned int elementSize;

} _MEMORY_POOL, *_PMEMORY_POOL;

---

and a typedef:

Code:

---

typedef void *MEMORY_POOL;

---

Code:

---

void *_pcheck(MEMORY_POOL p, unsigned int offset)
{
    if(offset >= ((_PMEMORY_POOL)p)->allocated)
        if((((_PMEMORY_POOL)p)->base = realloc(((_PMEMORY_POOL)p)->base, (((_PMEMORY_POOL)p)->allocated = ++((_PMEMORY_POOL)p)->increment * ((_PMEMORY_POOL)p)->initialSize) * ((_PMEMORY_POOL)p)->elementSize)) == NULL)
            abort();

    return ((_PMEMORY_POOL)p)->base;
}

---

Is it a good idea to do something like this?

I would still suggest you typedef MEMORY_POOL to just void and use MEMORY_POOL* to increase the visibility and fact that it is a pointer.
Pointer typedefs can cause headaches.

Thanks Elysia.

Btw, when we do a lot of casting, doesn't that affect performance?

Depends on what you do, where and when. And it also depends on the hardware.
I wouldn't say it's bad. It's essential to languages such as C.

Quote:

---

where and when

---

Any clue, please?

I guess you mean casting things to your structure and back? I would be surprised if that made any difference at all; the only thing I can think of that would cause problems is mis-alignment, but that shouldn't ever actually happen. (In other words, I would expect p->base, where p is a _PMEMORY_POOL, and ((_PMEMORY_POOL)p)->base, where p is a void *, to generate the exact same assembly: load p, add the offset for base, and fetch from that memory location.)

Especially if you try to change sizes of things. That means extra (maybe) instructions or cycles to convert the data.
I can't really say, though. I'm not an expert on the hardware topic.

Casting pointers only tells the compiler to interpret data differently. Casts don't actually take a performance hit on their own.
It's accessing the data in the specified format that could be more or less efficient, but no more so than if it were already of that type.

Thank you for your attention.

So, I made a conclusion:

Code:

---

pstructure --> pvoid --> pstructure

---

doesn't affect performance at all.

But...

Code:

---

pstructureA --> pvoid --> pstructureB

---

will make a mis-alignment.

...

Out of the box:
Btw, I think I will migrate to C++...
I getting problem with data types in C.
When I tried to implement stack in C, should I make str_stack()?, int_stack()?, char_stack()?, void_stack()?, arrrrrgghhhh... *confuse* I'm going crazy because of void* XP

Quote:

---

Originally Posted by iMalc

C-style casts, reinterpret_cast, and static_cast only tell the compiler to interpret data differently. They don't actually take a performance hit on their own.
It's accessing the data in the specified format that could be more or less efficient, but no more so than if it were already of that type.

---

Not true for primitive conversions. For example static or C casting an chat to a int will take performance hit, because it has to sign extend the value.

But this isn't C++, so it's better not to bring C++ terms in. Suffice to say that casting pointers in C will never take a performance hit.

As an aside: it is not allowed to cast function pointers to non function pointers. Trying to do this may result in a performance hit, assuming you compiler allows you.

Quote:

---

Originally Posted by audinue

Out of the box:
Btw, I think I will migrate to C++...
I getting problem with data types in C.
When I tried to implement stack in C, should I make str_stack()?, int_stack()?, char_stack()?, void_stack()?, arrrrrgghhhh... *confuse* I'm going crazy because of void* XP

---

Depends on the complexity and purpose of the stack. Is it merely to work with pointers, then void_stack might do, otherwise you're going to have problems and probably have to duplicate some code or create a devious work-around.
Suffice to say, C++ can handle this with ease and with more speed than C probably (if you choose to use methods with function pointers, or such).

Code:

---

//C99 :
typedef struct
{
    void *base;
    unsigned short initialSize;
    unsigned short increment;
    unsigned int allocated;
    unsigned int elementSize;

} MEMORY_POOL_INTERNAL;
struct MEMORY_POOL;
void *_pcheck(MEMORY_POOL *p, unsigned int offset)
{
    MEMORY_POOL_INTERNAL *p_i = (MEMORY_POOL_INTERNAL *) p;
    if(offset >= p_i->allocated)
        if((p_i->base = realloc(p_i->base, (p_i->allocated = ++p_i->increment * p_i->initialSize) * p_i->elementSize)) == NULL)
            abort();

    return p_i->base;
}

---

*ahem*

Corrected the above for what I was thinking.

Code:

---

#define p ((_PMEMORY_POOL)p)
/*
  ... p-> ...
*/
#undef p

---

:P

I hope you were sarcastic, because that is a very horrible hack ;)

Huh?
Something wrong with my code?
Btw, I just want to tell to robwhit that I asked "a lot of casting", not a quick solution :)

Quote:

---

Originally Posted by audinue

Huh?
Something wrong with my code?
Btw, I just want to tell to robwhit that I asked "a lot of casting", not a quick solution :)

---

Elysia's complaining about your suggested use of #define. Given robwhit's solution, there is no need to use macros in that way; Macros should always be a last resort solution to the problem of code repetition.

macros == bad programming practice?

Yeah, I think not every programming language supports macros like C.
But we are in C world now, why we are not using it?

I think it's more efficient to use macro instead of consuming more memory via new declared var.

Quote:

---

Originally Posted by audinue

macros == bad programming practice?

---

Quite possibly worse than goto, even. And nowhere up above had we "wasted" any space with extra variables (casting doesn't make any extra variables, and you never had more than one running around, that I recall).

(Okay, probably not worse than goto. But still.)

Quote:

---

Originally Posted by audinue

macros == bad programming practice?

Yeah, I think not every programming language supports macros like C.
But we are in C world now, why we are not using it?

---

Macro's arn't all bad, but they are the last resort against code repetition. And they can easily be abused.

Quote:

---

I think it's more efficient to use macro instead of consuming more memory via new declared var.

---

It isn't. Any decent compiler would use the same amount of memory. If you are worried, you can use the register key word.

Quote:

---

Originally Posted by King Mir

If you are worried, you can use the register key word.

---

I'd suggest that you ONLY use the register keyword in these cases:
1. You REALLY know what you are doing.
2. You have PROVEN that the register keyword is effective in your solution.

Generally, modern compilers (such as MS Visual Studio 6 and later or gcc 2.x and later) are pretty darn good at figuring out which register should have what in it - and usually better than you and me can figure out. In a "good bad" compiler, chances are that the compiler WILL obey you and put the value in a register, and then end up with fewer registers available for the compiler to use.

Code:

---

#define p ((_PMEMORY_POOL)p)
/*
  ... p-> ...
*/
#undef p

---

That's a REALLY HORRIBLE way to write code.

Also, have you considered this:

Code:

---

// something.h
typedef struct mystruct mystruct;

mystruct *getsomething();
void dosomething(mystruct *ptr);
...
// something.c
#include "something.h"

struct mystruct
{
  ... // data goes here
};
...
// implement functions using mystruct.

// main.c:
...
  mystruct *ptr;

...
  ptr = getsomething();
  dosomething(ptr);
...

---

This is called opaque pointers - you don't need to use void * to hide the content of a struct, and the advantage is that you don't need to do any type converting casts - you just don't tell the application code about the content of the struct.

--
Mats

I still don't get it..
Why using macro like that is "horrible"?
I think it is just like find-and-replace.

Btw, by hiding structures I think it could be a generalization... just like HANDLE in Windows API.

Because is obfuscates code.
It makes it harder to read.
It's hard to debug.
It has absolutely no type safety.
It causes headaches when it replaces things you DON'T want it to replace.

Example:

Code:

---

#define max(a, b) a > b ? a : b
int main()
{
    int max = 9999;
    /* ... */
}

---

Will cause a compile error probably along the lines of syntax error and you'll go HUH???

Quote:

---

Originally Posted by audinue

I still don't get it..
Why using macro like that is "horrible"?
I think it is just like find-and-replace.

Btw, by hiding structures I think it could be a generalization... just like HANDLE in Windows API.

---

As Elysia says: Macros make the code harder to read and debug, and in this case, the problem can be solved by a one-line cast [and most likely not any overhead, because the compiler doesn't actually NEED the variable itself, just the compile-time type information that it infers] into a new variable if you don't want to use opaque types.

MS choose the model of a HANDLE to give you an opaque pointer to MANY data types, it can be a thread, a file-search, a file, a window, a timer and a whole heap of other OS things. These are internally represented by many different data structurs [although they do share common portion so that you can for example send most of them to WaitFor[Single|Multiple]Object() and it will do the right thing (e.g. wait for the thread to finish, wait for the timer or such.

--
Mats

Or the fact that it may not have to be "hidden" at all, just you want to remind yourself that you shouldn't be playing with it ;)

Code:

---

struct mystruct_s
{
    int whatever;

    struct readonly_s
    {
        int naughty;
        int no;
    } readonly;
};

---

Or what other docs do and just mention that you shouldn't be touching x members of the struct.

Elysia:

Code:

---

define max(a, b) a > b ? a : b
int main()
{
    int max = 9999;
    /* ... */
}

---

I think this will make non-sense IF we do it carefully :)

Quote:

---

Originally Posted by audinue

Elysia:

Code:

---

define max(a, b) a > b ? a : b
int main()
{
    int max = 9999;
    /* ... */
}

---

I think this will make non-sense IF we do it carefully :)

---

No, it will generate a compiler error about "missing arguments for macro", which obviously doesn't make for a very nice error message as to what is wrong.

It is probably not quite the best example of "bad macro usage", but it will give an error message that doesn't make much sense here.

--
Mats