Il make it short and quick:
what are cons and pros and whyc one should be used?
Way one:
SDL_Surface *screen = NULL,
*background = NULL,
*image1 = NULL;
Or Way two:
SDL_Surface *screen = NULL;
SDL_Surface *background = NULL;
SDL_Surface *image1 = NULL
Is Way one any more efficient then Way two? or it dosent matter?
EDIT: i forgot to mention once i was getting error i chouldnt figure out why… i changed from Way one. to Way two is done and it fixed.
This isn’t really an SDL question, but C/C++ basics.
And none of your statements allocate memory, so question is not about
memory, but about C/C++ coding style
It really doesn’t matter which one you use. But if you use C++ then
you should try to define variable and initialize variable together and
close to place you use.–
M?rti?? Mo?eiko
On Sat, Jan 28, 2012 at 10:21 AM, tw3tye wrote:
Il make it short and quick:
what are cons and pros and whyc one should be used?
Way one:
SDL_Surface *screen = NULL,
*background = NULL,
*image1 = NULL;
Or Way two:
SDL_Surface *screen = NULL;
SDL_Surface *background = NULL;
SDL_Surface *image1 = NULLIs Way one any more efficient then Way two? or it dosent matter?
EDIT: i forgot to mention once i was getting error i chouldnt figure out
why… i changed from Way one. to Way two is done and it fixed.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Hi tw3tye,
At your current level of understanding, I would advise you avoid
thinking too hard about optimisation unless you have actual
performance problems. Inventing problems and attempts to solve them,
when you do not have the skills and experience required, can have a
detrimental affect on your projects performance and delivery date.
The “real” answer is to examine the assembly output of the Release
mode build of the source code. Usually, you can pass a flag or check a
setting in your compiler to get it to output these assembly files.
Unfortunately, you also need to understand assembly to make use of
this information.
Please don’t try to benchmark the two, artifical benchmarks can be
very misleading. If you do not understand how the processor cache
works, for example, any benchmark you write is probably flawed.
Most real world efficiency is gained through profiling and algorithmic
optimisation, or changing memory access patterns. Micro-optmisations
like the kind you are wondering about rarely make any measurable
difference, except in the tightest of tight loops, where all other
optimisation techiques have been employed and are found wanting.
I’ll leave you with a thougth: if you were a compiler writer, and you
knew that these two common code patterns are interchangeable, would
you allow them to generate different assembly?
Regards,
– Brian> Is Way one any more efficient then Way two? or it dosent matter?
EDIT: i forgot to mention once i was getting error i chouldnt figure out
why… i changed from Way one. to Way two is done and it fixed.
+1 to the reply in its entirety, but especially to the point above.On Sun, 29 Jan 2012 20:35:31 +0000, Brian Barrett <brian.ripoff at gmail.com> wrote:
I’ll leave you with a thougth: if you were a compiler writer, and you
knew that these two common code patterns are interchangeable, would
you allow them to generate different assembly?
–
Vijay Varadan
AXHAM GAMES: http://axham.com
Skype: vijayvaradan
India: +1-425-956-3326 (VOIP)
India: +91-99400-13652 ©
http://vijay.axham.com
My original post was all about efficiency, but re-reading the original
question I see that that was but one point to the question.
what are cons and pros and whyc one should be used?
Most programmers find separate declarations are easier to read (I am
extrapolating “most” from the source code I’ve read on the Internet).
However, in programming languages that don’t force all declarations to
the top of the current block/scope (C++ and modern C), the preferred
solution is to actually to wait until the last possible moment to
declare a variable, and then to initialise it with a useful value.
Your example might then look like:--------------------------------------------------
SDL_Surface *screen = SDL_SetVideoMode(800, 600, 0, SDL_SWSURFACE);
if(!screen)
{
// error handling
}
SDL_Surface *background = IMG_Load(“background.png”);
if(!background)
{
// error handling
}
The idea here is that you avoid having variables in scope that aren’t
usable yet. It also makes it easier to lift a chunk of code into a
separate helper function, if necessary.
– Brian
As Brian stated, using separate statements is easier to read. Also, keep
in mind that the following statements can be ambiguous:
int a, b, c; // Creates three integers
int *a, b, c; // Three integer pointers, or one integer pointer and two
integers?
I know GCC prefers
int *a, *b, *c; // Three pointers
int *a, b, *c; // Two pointers and a regular integer
I have heard rumors that some non-standard c/c++ compilers may treat the
following as all pointers:
int* a, b, c; // Three pointers
So, for both readability and potential portability, it is best to use
separate statements:
SDL_Surface *video;
SDL_Surface *some_buffer;
// …
As far as optimizations go, Brian also pointed out that there should be no
optimization between declaring those variables in a list or separately.
I hope that helps weed out some of the issue.
-OzOn Mon, Jan 30, 2012 at 4:18 AM, Brian Barrett <brian.ripoff at gmail.com>wrote:
My original post was all about efficiency, but re-reading the original
question I see that that was but one point to the question.what are cons and pros and whyc one should be used?
Most programmers find separate declarations are easier to read (I am
extrapolating “most” from the source code I’ve read on the Internet).
However, in programming languages that don’t force all declarations to
the top of the current block/scope (C++ and modern C), the preferred
solution is to actually to wait until the last possible moment to
declare a variable, and then to initialise it with a useful value.Your example might then look like:
SDL_Surface *screen = SDL_SetVideoMode(800, 600, 0, SDL_SWSURFACE);
if(!screen)
{
// error handling
}SDL_Surface *background = IMG_Load(“background.png”);
if(!background)
{
// error handling
}SDL_Surface *image1 = IMG_Load(“image_1.png”);
if(!image1)
{
// error handling
}The idea here is that you avoid having variables in scope that aren’t
usable yet. It also makes it easier to lift a chunk of code into a
separate helper function, if necessary.– Brian
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
(Original poster: ignore this reply unless you’re feeling curious)
This is the reason that we tend to lexically bind the * to the value
rather than (much more logically) the type i.e.:
int *pointer;
…instead of…
int* pointer;
The latter arguably makes more sense but it’s incompatible with
declaring several variables one on line. The real problem is that it’s
possible to declare several variables of different types on the same line.On 30/01/2012 14:27, Alex Barry wrote:
int *a, b, *c; // Two pointers and a regular integer
Thx got my answer.
btw u dont need to flag me for being NOOB and dont know anithig =,=
“il make this simple” i stated btw.
not gona put bunch of my program here just to show off.
They should not be different to the compiler for all I know,
But there is a slight syntax error in the second way - you are missing a
semicolon, but most likely you copy+paste’d without it.
SDL_Surface *screen = NULL;
SDL_Surface *background = NULL;
SDL_Surface *image1 = NULL
should be
SDL_Surface *screen = NULL;
SDL_Surface *background = NULL;
SDL_Surface *image1 = NULL;
Hope that helps.On 1/28/2012 10:21 AM, tw3tye wrote:
Il make it short and quick:
what are cons and pros and whyc one should be used?
Way one:
SDL_Surface *screen = NULL,
*background = NULL,
*image1 = NULL;
Or Way two:
SDL_Surface *screen = NULL;
SDL_Surface *background = NULL;
SDL_Surface *image1 = NULLIs Way one any more efficient then Way two? or it dosent matter?
EDIT: i forgot to mention once i was getting error i chouldnt figure out
why… i changed from Way one. to Way two is done and it fixed.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org