casting?

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