const correct ofImage

feature requests
#1

I feel like this is kind of minor – I tried to find another thread to tack it onto, but didn’t see anything obvious.

I just noticed a bunch of functions in ofImage don’t have const a lot of places that are definitely constant. The first place I noticed is getWidth() and getHeight(). This means that if I pass an ofImage by a const reference to a method, I can’t access most of the ofImage’s methods.

If only width and height are important, those fields are actually public… on the other hand, myPixels is private and therefore inaccessible.

It’d be great to see these methods (getPixels, getWidth, getHeight, etc) made const.

#2

well getPixels is a problem as you get a pointer to the internal pixels.
that pointer is designed to be two way so you can modify the pixels with it if you call update() afterwards.

if we made getPixels() const then we would only be able to read with the pointer and not change the values with it anymore.

Theo

#3

Wow, you’re right – that’s kind of obvious, I hadn’t thought of that!

I wonder what the regular design pattern is for that kind of thing, then?

Anyway, even if getPixels() isn’t const, getWidth(), getHeight(), etc. should be.

#4

I’m running into this again. Let’s say I want to grab a frame of video from a video player or video grabber. I extend ofImage and add this method:

  
  
ofImage& operator= (const ofBaseVideo& video) {  
	int w = (int) video.getWidth();  
	int h = (int) video.getHeight();  
	allocate(w, h, OF_IMAGE_COLOR);  
	setFromPixels(video.getPixels(), w, h, OF_IMAGE_COLOR);  
	return *this;  
}

I feel like getWidth() and getHeight() should definitely be const, otherwise this doesn’t work (since video is const).

#5

I’m have to admit I’m pretty suspicious of const, primarily because I don’t truly understand what the benefits are. I’ve always seens it as something that propagates through code and limits what you can do.

could you not overwrite the = operator, and make a function that takes a ofBaseVideoGrabber non const as input, and do what you are trying to do here without the fuss?

doesn’t this:

Another time when returning a const reference may not a good idea is when you are returning a reference to member data of an object. Although returning a const reference prevents anyone from changing the data by using it, it means that you have to have persistent data to back the reference–it has to actually be a field of the object and not temporary data created in the function. Once you make the reference part of the interface to the class, then, you fix the implementation details. This can be frustrating if you later wish to change your class’s private data so the result of the function is computed when the function is invoked rather than actually be stored in the class at all times.

apply in this case? making getWidth() const correct means we are prevented from doing things in the future, like computing the width on the fly?

just trying to read up a bit to understand more about this: http://www.cprogramming.com/tutorial/co-…-tness.html

take care,
zach

Why there's no const correctness in OF getters?
#6

The example you just gave relates more to a seperation in interfaces and implementation, exposing implementation data directly, even through a constant reference, is a bad idea because if your implementation changes so too does your interface.

Theres two differing const useages in this thread:

  
const aClass myVar;   
  
class myClass{  
  int myMemberFunction() const;  
}

And variations on the first including return’s and parameters.

What the first say is “I promise not to change this value or call any non-const methods it may have”

The 2nd says “I promise not to change any data in myClass or call any non of my own non-const member functions inside of myMemberFunction()”

Neither of these things affect getHeight() and getWidth(). If they were to be set const, this does not affect their ability to calculate values in the future, only the ability for them to set data, and call non const methods (which they dont do, because they’re accessors).

This is also one of the reasons why const is a bit infectious though but thats not necessarily a bad thing if you know exactly which functions should be const, and which should not be.

It’s a hard sell because in the abstract setting methods as const allows you to set some objects as const and still let you use the methods. What you gain is protection against accidently changing something in the objects you pass in.

In relation to the topic though, if it’s interfering too much, then dont set the video to const when being passed in, that’s a fix enough until it’s decided whether the API will be changed to allow for that, you dont lose much considering it’s your own function you’re writing.

edit: spelling :expressionless:

#7

Yes, this is how I understood it too.

That’s exactly what I did for now :slight_smile:

Zach, I can relate to the problem of const as limiting. But the only time I’ve run into that problem is when I try to write const-correct code while using a library that isn’t const-correct. So I see it like this:

Making more of the core (including ofImage) const-correct doesn’t limit our ability to write const-incorrect/“sloppy” code. But it does limit our ability to write const-correct/“clean” code.

#8

I almost puked from reading this thread. C++ member-functions can have both const and non-const overloads.

That is:

  
  
class ofImage {  
  unsigned char* getPixels();  
  const unsigned char* getPixels() const;  
};

Then:

  
  
ofImage img;  
const ofImage cimg;  
img.getPixels();  // unsigned char* getPixels();  
cimg.getPixels(); // const unsigned char* getPixels() const;

Besides that, and if you really want to do something as nasty as modifying the internals of ofImage form its getHeight function then google “C++ mutable”.

#9

Wow, really interesting Imhotep… I didn’t know you could have both const and non-const methods like that. It’d be really nice to have both options in ofImage. I’ll remember to use that in my own work when applicable, too. Thanks!