Print

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

[3man75]

cout << setw(15) << right << setfill('-') << "    ";

Using that on top to fix my output problem. I feel so bad about re-using my code like 5 times just to do this:

Bank   Interest     Rate
-----   ----------   -------

I mean come on it's so simple but I can't find any other way to do it that is cleaner :/

[itisnotlogical]

Well, I'm out of ideas for what could be going wrong. It crashes after calling setCellPendingAction in board.cpp more than once. Specifically, commenting out the line "liveNeighbors += 1" prevents the crash.

Code: (main.cpp) [Select]

#include <stdlib.h> //Pure C random numbers for simplicity's sake, not used yet
#include <cstring> //strcat
#include <curses.h> //PDCurses. initscr, getmaxyx, printw

#include "board.h"

//using namespace std;

int main()
{
//cout << "Beginning curses mode" << endl;
initscr();
cbreak();
noecho();
printw("Entered curses mode\n");
refresh();

int sizex;
int sizey;
getmaxyx(stdscr, sizey, sizex);
char strbutts[10];
printw(strcat(itoa(sizex, strbutts, 10), "\n"));
printw(strcat(itoa(sizey, strbutts, 10), "\n"));
refresh();

printw("Allocating board memory\n");
refresh();
board mainBoard(sizex, sizey);

printw("Board allocated\n");
refresh();
int x;
int y;

for(x = 0; x < sizex; x++)
{
for(y = 0; y < sizey; y++)
{
if((rand() % 2) == 1)
{
mainBoard.boardArray[x][y].alive = true;
}
else
{
mainBoard.boardArray[x][y].alive = false;
}
}
}

char inp = getch();

while(getch() != -1)
{
mainBoard.setAllPendingActions();
inp = getch();
refresh();
}

return 0;
}


Code: (board.cpp) [Select]

#include "board.h"
#include "cell.h"
#include <curses.h>
#include <cstring>
// Handling a two-dimensional array of cells

using namespace std;

//ctor
board::board(int rows, int cols)
{
boardArray = new cell*[rows];
boardRows = rows;
boardCols = cols;

int i;

for(i=0; i < boardRows; i++)
{
boardArray[i] = new cell[boardCols];
}
};

//dtor
board::~board()
{
int i;
for(i = boardRows; i > 0; i--)
{
delete[] boardArray[i];
}

delete[] boardArray;
};

void board::setAllPendingActions()
{
int x=0;
int y=0;
// As x goes up it goes across the columns
for(x = 0; x < boardCols; x++)
{
// As y goes up it goes down the rows
for(y = 0; y < boardRows; y++)
{
setCellPendingAction(x, y);
}
}
};

void board::setCellPendingAction(int x, int y)
{
short liveNeighbors = 0;
short i = 0;
short j = 0;

for(i = x-1; i <= x+1; i++)
{
for(j = y-1; j <= y+1; i++)
{
if(i < boardRows && j < boardCols)
{
if(boardArray[i][j].alive)
{
liveNeighbors += 1;
}
}
}
}

if(liveNeighbors < 2 || liveNeighbors > 3)
{
boardArray[x][y].setPendingAction(cell::BECOME_DEAD);
}
else
{
boardArray[x][y].setPendingAction(cell::BECOME_ALIVE);
}
};

void board::updateCells()
{
int x;
int y;
for(x = 0; x < boardCols; x++)
{
// As y goes up it goes down the rows
for(y = 0; y < boardRows; y++)
{
boardArray[x][y].update();
}
}
}


Code: (cell.cpp) [Select]

#include "cell.h"

void cell::setPendingAction(cellAction action)
{
pendingAction = action;
};

void cell::update()
{
if(pendingAction = BECOME_ALIVE)
{
alive = true;
}
else
{
alive = false;
}
}

[MagmaMcFry]

I think it crashes because you don't prevent i and j from being negative. Change this:

Code: [Select]

if(i < boardRows && j < boardCols)to this:

Code: [Select]

if(i < boardRows && i >= 0 && j < boardCols && j >= 0)

[itisnotlogical]

Ahhh, I see. I half-way thought about the edges of the screen, but what I did only accounts for the bottom and right edges. That has fixed it, thanks!

[Telgin]

Ah, today the computer lab was filled with the anguished cries of tortured bits at my hands.

In other words, I really hate makefiles.  The C and C++ compilation process is just complicated if your IDE doesn't manage the makefiles for you.  VS is fantastic.  Using a raw text editor or minimal IDE is not, and I don't know of any good fully integrated IDEs for Linux that work well with C++.  My experience with Eclipse doesn't lead me to believe that it works well with C++.

Anyway, I had a program that was crashing consistently at the same line, inside of the C++ standard library's string's length method.  That really shouldn't ever happen, and generally means you've done something to hose memory somewhere by writing past an array boundary or something.  I've done that a few times and recognized the symptoms, so I immediately went to Valgrind to tell me where I'd been stupid.

Well, Valgrind sure didn't know.  It didn't detect a single problem.

It took me a good hour to realize that I'd modified a header file and added some properties to one of the structs, but because of the simplistic makefile I was using that didn't trigger all of the modules that included it to be rebuilt.  Some did, some didn't.  Fun ensued.

Maybe I'll remember this lesson for a while.

[itisnotlogical]

I have enough trouble keeping up with just three source files when working with text + command line. I couldn't imagine working on a real-world project without IDEs; the smallest source I've seen in the wild was the DOOM source, and that had 20+ files IIRC.

[Telgin]

At least that many, probably.

This project isn't gigantic, to be fair.  It's maybe 2,000 lines long all told, spread across maybe 10 source files with the headers included.  That's almost manageable with manual makefiles, but it still leads to nonsense like that on occasion.

The other annoying thing is that I haven't taken the time to make it simple to switch between release and debug builds yet.  I have to manually comment / uncomment option lines in the make file then do a "make clean" before rebuilding the project.  As many times as I've done that so far, I really ought to fix that.

[monkey]

CMake is your friend.
A very basic CMakeLists.txt goes a long way, also it discovers headers dependencies (using gcc I believe).

Code: ("CMakeLists.txt") [Select]

project (test)
add_executable(example a.cpp b.cpp)

And then

Code: [Select]

# mkdir release && cd release
# cmake ..
# make
# cd ../ && make debug && cd debug
# cmake -DCMAKE_BUILD_TYPE=Debug ..
# make
# cd ../ && make 3rdconfig && cd 3rdconfig
# cmake -DFANCYDEFINE=isFancy  ..
# make


[Reelya]

cmake works very well with VS as well, automaticaly generating sln files and the like, so it's great to keep a project synced properly between windows and other platforms.

[Dutrius]

C# question!

What is the benefit of using get and set methods instead of just accessing the variable directly?

[Arx]

It means you can easily do validation every time you change it, mostly. As far as I understand, anyway.

[Rose]

Give a bit more control over access. You can have a private set and a public set so other classes can read the variable but not write to it.
Allows logic for what to do when it's changed
Allows different ways to read the same variable, like storing kelvin internally, but having a centigrade, kelvin, Fahrenheit, and Urist accessors that all read from the same variable.
If you're  writing a library,  you want to keep all public stuff as accessors because you can  change the logic without breaking compatibility. 

[Dutrius]

I see. It just seems to be a bit of a hassle to write out a bunch of get and set operators.

It makes sense, though.

[Rose]

It's easy to just write
public int Awesomeness {get;set;}

[Reelya]

enforcing Get and Set operators also prevents one of the most common bugs:

if(object.value = true)
  do_thing();

where you accidentally put a single-equals. Using a Get/Set paradigm would give a compiler error here, thus avoiding shipping with the bug. Writing Get/Set operators is pretty quick. Tracking down such a bug in 1000's of lines of code can take a while.

So they're not just for fun, they prevent common bugs from occuring.

There's also optimization. Say you have a bunch of bools. You make Get/Set operators for each bool. Next, you want to optimize memory use, so you want to pack all the bools into bits in one internal int. If you wrote Get and Set operators for the bools, you can modify those functions to do your fancy bit packing for you. If you were directly editing a bool, you'd have to modify the client code in many files to change this internal storage behaviour.