The Big Programming Thread - Page 308

On May 30 2013 06:10 3FFA wrote:
I did. Just ran it.... says it can't load the simulator because of the version for some reason. =/

On May 30 2013 11:09 Abductedonut wrote:
Okay guys - I totally need help but it's not a specific coding question.

I have an interview in two days for a software company. I just got the call - are they specifically said since it's a programming interview, a nice collared shirt would be okay by them.

First off, if I were to wear a collared shirt, should I not wear a tie? I'm still going to wear dress pants and shoes, but should I not wear a tie?

Or, should I just wear a suit anyway? Full blown - with the tie and jacket? Any advice would be very greatly appreciated.

On May 30 2013 11:09 Abductedonut wrote:
Okay guys - I totally need help but it's not a specific coding question.

I have an interview in two days for a software company. I just got the call - are they specifically said since it's a programming interview, a nice collared shirt would be okay by them.

First off, if I were to wear a collared shirt, should I not wear a tie? I'm still going to wear dress pants and shoes, but should I not wear a tie?

Or, should I just wear a suit anyway? Full blown - with the tie and jacket? Any advice would be very greatly appreciated.

On May 30 2013 12:09 BoxingKangaroo wrote:


It's an interview, wear a suit in my opinion. What you will wear at the job, and what you wear in the interview should not necessarily be the same. If it's an interview for an office job, wear a suit. No one ever got passed over for over dressing.

On May 30 2013 13:14 phar wrote:

Woah, really depends on the company. Coming to an interview in a suit at a lot of companies is gonna be viewed as kinda strange. For example, a significant percentage of the devs at my place don't even wear shoes...

Go with whatever the recruiter said. If they said collared shirt, do that (no tie imo). It is better to be overdressed than underdressed, but it's not better to be overdressed than dressed-exactly-the-way-the-recruiter-said.

On May 30 2013 06:45 Holy_AT wrote:
@klo8
Meh, people nowadays are all about their tools and auto debugging to tell them what their program does.
If the problem does not lie in the libraries you are using and it is in your code, the most likely result of your problem is that you are not disposing some of your objects or freeing memory.
I do not know how you have implemented your solution but I hope you have a separation between the model and the view, at least you can determine if your memory problems result from your model and the algorithms performed in there or the visual representation the view, by just running your program without the view(s) attached to it.

On May 30 2013 19:20 klo8 wrote:

As a programmer coming from C# and Java, I don't really have a lot of experience managing memory on my own (except for about 6 months of C programming that I did for a systems programming class). I've so far allocated all objects on the stack and did not use any pointers to objects or the new-operator, so using delete was not necessary so far. I followed your advice, and just doing the backend calculations does not seem to take up a lot of memory, the usage is around 2MB when I just run the backend. (creating the L-Systems, creating the vertex arrays for drawing) As soon as I create a SFML-RenderWindow, the usage jumps to 27 MB, so it seems to be out of my hand, at least in that regard. As for what happens when I increase the size of the curves, I'll have to check some more I guess.

On May 30 2013 19:45 misirlou wrote:


New operator doesn't exist in C. The closest is type *pointer=(type*) malloc(sizeof(type)*elements) , and using free(pointer) after you don't need the memory. I will have a look at your code to understand what you mean by "allocated all objects on the stack" and edit this post.

Edit: NVM you are using c++. Im not sure how VS handles STL containers on the garbage collection but it might be that you are allocating memory for them every time you call CreateLSystems and not clearing them after you use them on the lsystems.push_back(LSystem(...)); call.

On June 01 2013 05:17 enigmaticcam wrote:
Ok, I got a question.

I'm looking to develop a simple data warehouse solution with a SQL backend. It will be dynamic in the sense that it will support any need to house data in any format. Each set of data will be autonomous, so no need to futz around with foreign key relationships. There will be an independent business tier that will do its own data aggregation against the warehouse, but that's irrelevant for this discussion.

Think of it like when you're working in SQL, defining tables to hold data, except my solution does that job for you but uses SQL as its data store.

I can think of two ways to do this, but I'm not entirely sold on either one:
1. Have the solution actually create and manage tables for each autonomous set of data I want to add to the data warehouse. This has the benefit of visually seeing the tables in SQL and ease of management in the software solution. The problem is that tables are harder to manipulate when they change.

2. Break the data out into a stagnant set of tables that hold each autonomous set of data in parts. You would have a "Table" table that identifies each logical table, a "TableKeys" table that represents each field in each table, and a "TableRows" table that breaks down the data into rows, and for each row matches a value to a field, or "key". This has the benefit of being very dynamic. The problem is that as the data warehouse grows, this table will get very large and might slow down the system.

What do you guys think? I started building it as option 2, but now I'm leaning towards option 1.