From: <bar...@t-...> - 2002-09-10 10:38:51
|
hi michael, > > still trying to adjust my mind to const. while trying to adapt > > gnome-xine i stumbled over the difficulty to store a xine_p: > > > > this->xine = xine_new(); > > > > gives me compiler warnings, no matter how i declare the xine > > component of "this" (xine_t * or xine_p). > > > > could it really be true that xine_new returns a const just to signal > > "please don't free() me" at the price of everyone casting it back to > > xine_t again? if so i strongly vote for changing it back to xine_t * > > (which, btw. my emacs will highlight correctly again as opposed to > > xine_p) and going with a header comment here. > > If you think about it a bit, it's not too difficult. (I had to make > myself familiar with it, too, before const'ing the api.) > > "const xine_t *const xine" is best read from right to left: xine is a > constant pointer to a xine_t constant. So the very left const says: You > are not allowed to write into this structure, because it's constant. > The *const says: This pointer is constant, do not make it point > elsewhere. what's the point in the second one? > xine_new gives you such a thing and if you want to store it, you have > to declare the variable "const xine_t *xine". With the const you > guarantee to the compiler to not change the content of this xine_t and > therefore the compiler let's you assign a xine_p to a const xine_t *. ...but does this make sense? xine_t is not a constant, but a opaque data structure that changes nearly with every call to libxine (which means that every public function in libxine has to cast the pointer). so what is the effect of this declaration (apart from telling some people they should not free() the pointer - which is just a strange side effect and nowhere defined that way) - uis will hopefully not try to change the contents of xine_t because to be able to do that they have to #include xine_internal.h. i really believe we better go with some header comments here - which doesn't mean that i still disagree with the use of const now - just trying to get a feeling where it makes sense and where it doesn't. for example, i could imagine declaring some char* parameters as const char * could be useful (many of the consts daniel has deleted looked like this to me, but i haven't looked any closer into the matter yet) cheers, guenter |