Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Control Flow

2 (2.2%)

Arrays, Strings, Pointers, and References

8 (9%)

Functions

4 (4.5%)

Basic object-oriented programming

30 (33.7%)

A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)

18 (20.2%)

Templates

8 (9%)

Other (Explain)

4 (4.5%)

Working with files?  (Streams)

15 (16.9%)

Total Members Voted: 89

[DrPizza]

Steps to success:

You'll get much better results much sooner by actually striving to understand what you're doing from the outset.

[Siquo]

Let me rephrase/redefine: iterative (educated)guessing is what you do when debugging, not while you're writing. Writing code is 80% or more of  debugging for a beginner, however, so it doesn't matter that much.

[madk]

The trick is to not let your code get that bad in the first place. It makes writing code faster and (generally) makes debugging easier. I say generally because I know I get way to wrapped up in optimization before I cun my code a single time, so when it doesn't work, I get to bang my head against the desk for a few hours before I finally manage to spot the problem.

[Siquo]

Yeah, I got that now. De-optimalisation fixed the bugs, but is... well, unoptimal. Although usually it works to keep optimisation in the back of your head, because optimising working code usually takes longer (as in: start over) than deoptimising buggy code, at least in my current project.

[DrPizza]

Yeah, I got that now. De-optimalisation fixed the bugs, but is... well, unoptimal. Although usually it works to keep optimisation in the back of your head, because optimising working code usually takes longer (as in: start over) than deoptimising buggy code, at least in my current project.

Optiwhat?

[DrPizza]

The trick is to not let your code get that bad in the first place. It makes writing code faster and (generally) makes debugging easier. I say generally because I know I get way to wrapped up in optimization before I cun my code a single time, so when it doesn't work, I get to bang my head against the desk for a few hours before I finally manage to spot the problem.

You (surely) know what Knuth says about premature optimization....

In general, the only optimizations that are worthwhile are high-level algorithmic improvements, and these are almost invariably easier to implement when your code is clean, clear, and correct.

[qwertyuiopas]

The most worthwhile optimization, in terms of coding time and loss of clarity, is -O3 (or whatever your compiler/IDE uses).

Only when that is insufficient should you worry about code optimization, and in that case, first clearly identify where the slowest parts are, and consider how you could rework them to be faster algorithmetically, or to reduce the times it is used per second. The problem, although unlikely, could also be in a library you are using, although most of the common ones shouldn't have such problems. Understanding how certain functions work is also very useful.

[ILikePie]

I recently moved over to using gentoo, and oddly, no mater how many times I type #include <math.h>, I have to add an -lm option to gcc so compiler will notice it. Is this true with the other headers as well (IE stdio, stdlib, etc.), and is there any way around this minor inconvenience?

Now for a much more inconvenient problem, I've written a flood fill function (y'know the bucket tool in mspaint) that looks like this:

Code: [Select]

void fill (int x, int y, RGB *canvas, RGB fill_color, RGB org_color, int width) {
   if ( get_color_pt(x, y, canvas, width).red == org_color.red) {
      draw_point(x, y, canvas, fill_color, width);
      fill (x -1, y, canvas, fill_color, org_color, width);
      fill (x +1, y, canvas, fill_color, org_color, width);
      fill (x, y -1, canvas, fill_color, org_color, width);
      fill (x, y +1, canvas, fill_color, org_color, width);
   }
}
It calls itself four times, and this seems to be causing a 'segmentation fault', or, at least that's what the program says. I remove two calls and no error. What's wrong?

Also, is there a way to compare two structs, 'struct foo == struct bar' doesn't work.

[Supermikhail]

Hey, I came here with a writer's block, but it turns out that I know something (possibly).

I'm too lazy to dig into the textbook I've been studying, but the thing with structs must be that if you really want to compare two structs this way you have to write a struct operator== into the struct's definition. Like this:

Code: [Select]

struct operator== (const struct &);

~~~~~
~~~~~

bool struct::operator== (const struct & rhs)
{
if (valueA == rhs.GetValueA) && (valueB == rhs.GetValueB)
{return true;}
else {return false;}
}

At least I hope we're talking about the same thing. Because I only study C++ on and off and get easily confused.

As far as the second problem, I can only work from the Wikipedia's definition of "segmentation error", and if I remembered something about memory management, I'd probably say something clever. I'll try nonetheless. It appears to me that your computer can't handle so many recursions at the same time. It must be a thing with processor function registers. Or maybe the compiler is doing something fishy, and you'd want to fiddle with your program on a lower level.

From a guy who's programmed a single one time during the past... couple of months.

Edit: Oh, almost forgot my question.
Can I try to program games already? I've been studying this book called "Teach yourself C++ in 21 days" for about a year during vacation breaks. I've come to day 16 "Advanced Inheritance" and it's so boring, especially with the guy always repeating code when he needs to change some detail in it. What's more, I read it so much, and most of my effort goes into concentrating on new information, but there are few exercises, and I'm growing ever less confident when I encounter them. Should I finish the book, or should I try to program something fun, especially that I've finally understood some SDL?

[qwertyuiopas]

For that flood fill, ensure that the source and dest colours are not equal, or it recurses endlessly.

Also, does get_color_pt check if the point is off the edge? It should, and if it does, it should inform the caller. I don't know that much C++, but maybe that might be a good place to put an exception? Then just catch the exception and skip the rest of the loop. Unless that isn't C++...

Actually, what you need to do is have a function that checks if the colours match, and returns true or false, and let it always be false when out of bounds.

Finally, the canvas could be a struct/class containing an array of colours as well as other important data like the width/height. As it is, there is no height information passed, so it might be exceeding the bounds in that direction.

[ILikePie]

Fixed the out bounds stuff and added a function to compare two RGBs. Now I need something for the function to throw if the point is out of bounds, C doesn't use exceptions, and returning (RGB)NULL doesn't work (NULL is void pointer, and RGB is an object). What can I have it return?

Edit: generating a null rgb variable, "RGB_NULL = {(int)NULL, (int)NULL, (int)NULL}" and returning it does the trick.
I'd still like to know why I must use the -lm option when compiling in Gentoo though.

[Normandy]

@Supermikhail:
First problem, you have the basic concept down right, yes.

Second problem, a segmentation fault is when a program tries to access memory that does not 'belong' to it. Simple way to think of it is like you trying to access a file that doesn't 'belong' to you in unix. It's an OS-level safeguard that ensures that programs don't write funky things to memory it hasn't allocated.

When talking about functions only being able to recurse a certain amount of times; when your processor (I'm not actually sure if it's the processor) has too many functions called to it, you get what's called a 'stack overflow'. It's usually not an issue unless if you're doing some heavy functional programming (doubt it), or you have an infinitely recursing function (probably should fix it).

[qwertyuiopas]

I think that it would work better with something like this pseudocode:

Code: [Select]

int is_color(int x, int y, RGB color, [other args])
{
    if(!in_bounds(x,y))
      return 0;
    if(RGB_equal(color, get_RGB(x, y)))
      return 1;
    else
      return 0;
}
Also, null is usually 0, so RGB {NULL, NULL, NULL} is going to be the same as {0,0,0}, or black.

[Supermikhail]

@Supermikhail:

I was trying to reply to

I recently moved over to using gentoo, and oddly, no mater how many times I type #include <math.h>
<...>
It calls itself four times, and this seems to be causing a 'segmentation fault', or, at least that's what the program says. I remove two calls and no error. What's wrong?

Also, is there a way to compare two structs, 'struct foo == struct bar' doesn't work.

probably just because I wanted to talk to somebody, seeing that I wasn't very successful. If that's what "(doubt it)" and "(probably should fix it)" are about. But thanks for clarification. I don't think I'm ever going to use recursing functions, though, there's something fishy about them.
Then I looked up "Flood Fill" in Wikipedia. I'm dumb. So, it went out of bounds in vertical direction?

My own problems were in "Edit:", and I decided to learn some SDL.

[ILikePie]

Oh, recursive functions are very useful, not using them is missing out on a lot. Is some cases you can do the same with a loop, but for things like that flood fill, a loop can't do much.


About optimization, which would run faster, this:

Code: [Select]

int i = 0;
for ( ; i < 10; i++) {
blah
}
or this:

Code: [Select]

int i = 0;
while (i++ < 10) {
blah
}
A quick google  search yielded no results, is that because they work the same speed wise?