Const correctness for SDL video

Originally my goal was to change SDL’s draw functions to allow the inputted
source to be const. I quickly found out that project would take far more
knowledge than I had, but I did manage to make all of the source rectangles
const. I’m done with 1.2, but 1.3 isn’t finished. Can anyone think of any
problems that would be caused by making the source rectangles const?
Assuming that it does compile.

If there aren’t any problems, I’m planning to do the same for 1.3.

Legal Info:
Everything in this patch in licenced under the same licenced as SDL.

PS is this the wrong place to post?
-------------- next part --------------
A non-text attachment was scrubbed…
Name: const_patch12.patch
Type: application/octet-stream
Size: 2885 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070214/918f1135/attachment.obj

Won’t that break binary compatibility in SDL 1.2?On 2/14/07, Patrick Mohr wrote:

Originally my goal was to change SDL’s draw functions to allow the inputted
source to be const. I quickly found out that project would take far more
knowledge than I had, but I did manage to make all of the source rectangles
const. I’m done with 1.2, but 1.3 isn’t finished. Can anyone think of any
problems that would be caused by making the source rectangles const?
Assuming that it does compile.

  • SR

Won’t that break binary compatibility in SDL 1.2?

I don’t know. Is making SDL binary compatible across minor versions a
requirement? I had assumed that this would happen often.

Would doing this for 1.3 be a problem since 1.3 isn’t released yet?On 2/14/07, Simon Roby <simon.roby at gmail.com> wrote:

I don’t think that is a problem.

Just curious, why do you care enough about this to bother with doing all
this work? I teach C++ and I really don’t see the point? Could you
educate me on this subject?

	Bob PendletonOn Wed, 2007-02-14 at 13:17 -0500, Simon Roby wrote:

On 2/14/07, Patrick Mohr wrote:

Originally my goal was to change SDL’s draw functions to allow the inputted
source to be const. I quickly found out that project would take far more
knowledge than I had, but I did manage to make all of the source rectangles
const. I’m done with 1.2, but 1.3 isn’t finished. Can anyone think of any
problems that would be caused by making the source rectangles const?
Assuming that it does compile.

Won’t that break binary compatibility in SDL 1.2?


±-------------------------------------+

Just for background, I usually program in c++. By consting the input
arguments, you help reduce bugs. The reason is because you can’t
accidentally change something by accident.

Here is an example. (I’m going to ignore const_cast since that defeats the
entire point of my example.) If I find out that for some reason an object
is being accidentally changed, I can immediately rule out any functions that
it is passed into as const. I’m not claiming that there are bugs that this
would help because of bugs in the SDL. The problem is that I can’t pass it
into my functions as const because those functions then need to pass into
SDL’s functions. If I had been using a const rect, I would have caught a
very annoying bug involving if( 0 = rect.h ) instead of if( 0 == rect.h ).
Also from what I understand, using const can help performance a little
because the compiler can assume that the argument won’t change. That is
just a side point thought. Const is mostly helpful because it can help
track down bugs.

One more example. If I use a global variable as a color declaration, about
it accidentally being changed. If the var is const, it won’t be changed
unless I have a something like a buffer overrun.

Sorry if this post seems alittle scattered.On 2/14/07, Bob Pendleton wrote:

On Wed, 2007-02-14 at 13:17 -0500, Simon Roby wrote:

On 2/14/07, Patrick Mohr <@Patrick_Mohr> wrote:

Originally my goal was to change SDL’s draw functions to allow the
inputted

source to be const. I quickly found out that project would take far
more

knowledge than I had, but I did manage to make all of the source
rectangles

const. I’m done with 1.2, but 1.3 isn’t finished. Can anyone think
of any

problems that would be caused by making the source rectangles const?
Assuming that it does compile.

Won’t that break binary compatibility in SDL 1.2?

I don’t think that is a problem.

Just curious, why do you care enough about this to bother with doing all
this work? I teach C++ and I really don’t see the point? Could you
educate me on this subject?

            Bob Pendleton


±-------------------------------------+


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If you use:

If ( 0 = rect.h )

You will get a compiler error since you cannot assign rect.h to the constant
0.

So this particular example is not valid. There may be other places where
using const can help, but this is not one of them

  • Ken_____

From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Patrick Mohr
Sent: Wednesday, February 14, 2007 2:02 PM
To: A list for developers using the SDL library. (includes SDL-announce)
Subject: Re: [SDL] Const correctness for SDL video

Just for background, I usually program in c++. By consting the input
arguments, you help reduce bugs. The reason is because you can’t
accidentally change something by accident.

Here is an example. (I’m going to ignore const_cast since that defeats the
entire point of my example.) If I find out that for some reason an object
is being accidentally changed, I can immediately rule out any functions that
it is passed into as const. I’m not claiming that there are bugs that this
would help because of bugs in the SDL. The problem is that I can’t pass it
into my functions as const because those functions then need to pass into
SDL’s functions. If I had been using a const rect, I would have caught a
very annoying bug involving if( 0 = rect.h ) instead of if( 0 == rect.h ).
Also from what I understand, using const can help performance a little
because the compiler can assume that the argument won’t change. That is
just a side point thought. Const is mostly helpful because it can help
track down bugs.

One more example. If I use a global variable as a color declaration, about
it accidentally being changed. If the var is const, it won’t be changed
unless I have a something like a buffer overrun.

Sorry if this post seems alittle scattered.

On 2/14/07, Bob Pendleton <HYPERLINK "mailto:bob at pendleton.com"bob at pendleton.com> wrote:

On Wed, 2007-02-14 at 13:17 -0500, Simon Roby wrote:

On 2/14/07, Patrick Mohr <HYPERLINK "mailto:kc7zzv at gmail.com"kc7zzv at gmail.com> wrote:

Originally my goal was to change SDL’s draw functions to allow the
inputted

source to be const. I quickly found out that project would take far
more

knowledge than I had, but I did manage to make all of the source
rectangles

const. I’m done with 1.2, but 1.3 isn’t finished. Can anyone think of
any

problems that would be caused by making the source rectangles const?
Assuming that it does compile.

Won’t that break binary compatibility in SDL 1.2?

I don’t think that is a problem.

Just curious, why do you care enough about this to bother with doing all
this work? I teach C++ and I really don’t see the point? Could you
educate me on this subject?

            Bob Pendleton


±-------------------------------------+


SDL mailing list
HYPERLINK "mailto:SDL at lists.libsdl.org"SDL at lists.libsdl.org
HYPERLINK
"http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org"http://lists.libsdl.org
/listinfo.cgi/sdl-libsdl.org


No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.17.39/687 - Release Date: 2/14/2007
4:17 PM


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.17.39/687 - Release Date: 2/14/2007
4:17 PM

I used to do that, but not even that makes much sense these days. Any
serious compiler should be able to give you a warning if you do:
if ( x = y )

rather than:
if ( x == y )

(To actually do the first operation, you do this:
if ( (x = y) )

to tell the compiler that you actually mean that. At least that’s how
it works with GNU gcc.)

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Wednesday 14 February 2007 21:25, Ken Rogoway wrote:

If you use:

If ( 0 = rect.h )

You will get a compiler error since you cannot assign rect.h to the
constant 0.

Just curious, why do you care enough about this to bother with doing all
this work? I teach C++ and I really don’t see the point? Could you
educate me on this subject?

Some C++ frameworks use the const keyword very much, and in such cases the
code interfacing with C-libraries (e.g. SDL) will need lots of ugly casts
unless the libraries actually have parameters marked const where needed.

Const in C++, correctly used, can really give nice strictness of the code,
which easily points out bad design decisions. And complicates things when
one wants to do quick hacks, of course. :wink: As to how much it actually
reduces the amount of bugs, I’ve got no clue…

Const in C++ can e.g. be used on class methods, e.g.:

int MyClass::getValue() const {
return value;
}

const MyClass* someObject;
int value = someObject->getValue();
someObject->setValue(42); // probably disallowed unless setValue also
// would be marked const…

The only methods which can be called on a const object (or object pointer)
are the methods marked const. And within these methods, all member
variables are regarded const, so you can only call the const methods of
the member objects, etc. Using this is usually quite an
all-or-nothing-effort, when wanting to mark a method const, one usually
have to fix the same for all methods called within that method,
recursively.

And in some cases, e.g. when overriding methods from some base class from
some other library, one can’t even decide oneself whether to enforce this
design in the application. Another example where this is required is when
defining operators for classes. The operands to e.g. the + operator have
to be const, naturally.

Of course, I won’t try to say anything about whether adding casts to the
code interfacing to e.g. SDL or actually cleaning up the const-ness of SDL
is easier…

// MartinOn Wed, 14 Feb 2007, Bob Pendleton wrote:

Martin Storsj? wrote:

Of course, I won’t try to say anything about whether adding casts to the
code interfacing to e.g. SDL or actually cleaning up the const-ness of SDL
is easier…

Cleaning SDL is easier because once someone does that, everybody who uses it
and had that const problem before will have that problem mostly fixed for
them :slight_smile: It’s a case where doing it isn’t probably worth it for one person
but is worth it for all users.

Won’t that break binary compatibility in SDL 1.2?

Not in these cases. You can flag data passed to functions as const and
not break binary compatibility…C function signatures don’t change, and
all you’ve done is guarantee that you won’t change the data passed in to
the function, and previously-compiled code would have assumed you might
do so and have coded appropriately.

C++ is a different story: adding a “const” changes the function
signature and then your program won’t be able to find the function
without a recompile. SDL’s public API is all C, though…there’s a
little C++ in the BeOS port, but none of that is publicly exposed.

–ryan.

Just curious, why do you care enough about this to bother with doing all
this work? I teach C++ and I really don’t see the point? Could you
educate me on this subject?

It allows better error checking…if the implementation promises const
safety and then modifies a field, the compiler can catch it.

It also promotes good interface design. A programmer can tell
immediately what they can pass to a function without fear of it being
modified between calls…the blit() thing in the patch is a good
example…the developer knows that it can reuse srcrect in a loop, but
dstrect will need to be reset between calls.

It also allows optimization…the compiler can make decisions about what
is safe to leave in registers, what needs to be copied before use, etc
by what it knows won’t be changed in a function.

(and a few more rules for C++: you can’t construct a temporary object in
a function call unless the function wants a const reference:

  void myfunc(const blah &x);

  myfunc(blah(1, 2));  // only works if there's a "const" up there.

).

Making things “const correct” is always worth it in my opinion…the
problem is that in legacy code it can be really really hard to retrofit it.

–ryan.

If you use:

If ( 0 = rect.h )

You will get a compiler error since you cannot assign rect.h to the
constant 0.

So this particular example is not valid.

How about “if (rect.h = 0)”, then?

It’ll also catch things like passing arguments to memcpy() in the wrong
order, etc, too.

–ryan.

How about “if (rect.h = 0)”, then?

This is exactly what I meant. I just made a typo in my typo.On 2/14/07, Ryan C. Gordon wrote:

Here is an updated copy of 1.2 and one for the trunk. Should this topic be
posted here or to bugzilla?
-------------- next part --------------
A non-text attachment was scrubbed…
Name: const_patch12.patch
Type: application/octet-stream
Size: 5723 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070214/f17dae1a/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed…
Name: const_patch-trunk.patch
Type: application/octet-stream
Size: 6840 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070214/f17dae1a/attachment-0001.obj

Hello !

How about “if (rect.h = 0)”, then?

Every modern compiler should print out a
warning or an error. GCC does it, don’t
know if VC also.

CU

Every modern compiler should print out a
warning or an error. GCC does it, don’t
know if VC also.

In my experience with SDL, there’re lots of platforms that don’t have a
"modern compiler." :slight_smile:

Also, the latest Platform SDK for Windows gives no warning for this in
the SDL project files.

int testme(int y)
{
if (y = 1)
y = 0;
return y;
}

If you crank it up from Warning Level 3 (what SDL uses) to Warning Level
4 (the maximum), it’ll warn you about it…but Warning Level 4 in
Microsoft’s compiler tends to flood you with useless warnings, so no one
uses it…enabling Level 4 in SDL moves us from 0 warnings to 1550 warnings.

It’s much stricter, in a bad way, than gcc’s -Wall.

–ryan.