addToInventory(), heldTrinket(), and addToConsumables() should all take const refs instead of value arguments.
getPennies(), printInventory(), printTrinket(), and printConsumables() should all be const member functions.
heldTricket() is a bad function name. It sounds like an accessor for getting your currently held trinket, rather than a function that changes it.
Be careful about using C arrays. For one, it's very rare that it's acceptable to have your size be a magic number. Should generally have something like "const unsigned MAX_CONSUMABLES = 50;". The second thing is that you're not bounds checking in addToConsumables(). The aforementioned variable would help with that.
However, really, just use a vector instead.
Your exit logic is a bit convoluted. It's not terrible, but it's somewhat strange how you're setting flags vs doing things directly. For example, "itemFlag = true;" could just be replaced with "break;" and the program wouldn't change. It could be cleaned up a bit to make it easier to understand.
In consumables(), items(), and trinkets(), you're using a switch case for a bunch of sequential numbers. In situations like this, you can pretty easily convert it into using an array:
std::string trinkets()
{
static const unsigned NUM_TRINKETS = 5;
static const char * trinkets[MAX_TRINKETS] = { "Ace of Spades", "Counterfeit Penny", "Fish Head", "Liberty Cap", "A Missing Page" };
int x = rand()%5;
if(x >= 0 && x < NUM_TRINKETS)
{
return trinkets[x];
}
else
{
return "error";
}
}
I didn't compile this, so I hope it works! A strategy like this makes it a lot easier to add new items in the future.
Alright, so I went through and did my best to fix things up where you mentioned. I'm not sure if I did things right, but I tried my best.
I know next to nothing about vectors but I'm looking into them now, so I did my best to throw something together. The code works, so I couldn't have screwed things up too badly.
And I have no idea why I used a switch for those value-returning functions. I always forget to use arrays (or I guess vectors now) when they're most useful which is pretty silly.
Member functions are tied to an instance of an object (unless they're static), giving you an automatic and implied "this" in every call. Since this changes things a bit, there are a few things you can do to member functions that you can't do with free functions, one of which is to make them const. A const member function says "I am not going to modify my this pointer."
What you've done (for the functions I listed before) is to make their return values const. You even have a const void, which is valid syntax, but nonsensical.
In order to make a member function const, you place the const at the end of the signature, like so:
The reason this is important is that the compiler will not let you call a non-const member function on a const object. You can see this for yourself. Try writing this bit of code in your current codebase and then compile:
Now you may be thinking: "Why would I care? The Isaac class is made to be modifiable." The answer is that even objects meant to change frequently may be temporarily const. Functions may take them as const references. This is all part of the overall idea of const correctness, which makes code easier to maintain, as well as supplying intent to the compiler (which is always good, because then it can optimize better).
std::string trinkets()
{
static const unsigned NUM_TRINKETS = 5;
static const char * trinkets[MAX_TRINKETS] = { "Ace of Spades", "Counterfeit Penny", "Fish Head", "Liberty Cap", "A Missing Page" };
int x = rand()%5;
if(x >= 0 && x < NUM_TRINKETS)
{
return trinkets[x];
}
else
{
return "error";
}
}
I mean, I think he based it off of the fact that those functions originally had switch statements in them but I had a fallback option in case I messed something up, I don't know!
Re: The Thread for Programming
Posted: 10 Nov 2014, 00:09
by WhattayaBrian
RenaBeach wrote:since you have control over the value of x there's no reason to do error checking (it just makes your code look flimsy to be honest)
I disagree. There's two clashing methodologies here, but I'd always rather be oversafe than undersafe. This comes up surprisingly often in projects at work, where "pointers that can never be null" (because you set them in the constructor and never clear them) are suddenly null, and this is conceptually the same thing.
That said, it'd be perfectly fine to move the check to an assert, but I wasn't sure if he was familiar with asserts and I already had a bunch of other changes.
Although honestly as long as we're on the subject, I probably wouldn't have consumables()/items()/trinkets() in the first place. They all do exactly the same thing. You could set it up as a function that takes a list and returns a random value out of it, which you'd only need one of, and then you'd call it by passing in one of your three lists.
Re: The Thread for Programming
Posted: 10 Nov 2014, 00:46
by devil†zukin
WhattayaBrian wrote:
out of curiosity, what do you feel about C++ exceptions?
I'm wondering if I should start using them but I've never really been convinced with them
Re: The Thread for Programming
Posted: 10 Nov 2014, 00:59
by WhattayaBrian
RenaBeach wrote:e: except i saw that you were already reading it
You could set it up as a function that takes a list and returns a random value out of it, which you'd only need one of, and then you'd call it by passing in one of your three lists.
but type safetyyyyyyyy (but i guess they're already strings, lol)
Sure, it's predicated on the fact that you have repeated instances where you want to draw a random element out of a list of strings, specifically.
Otherwise there's always templates.
RenaBeach wrote:out of curiosity, what do you feel about C++ exceptions?
I'm wondering if I should start using them but I've never really been convinced with them
Personally, I feel like they get an unfairly bad rap. I can see no reason that C++ exceptions are any worse than others (they work almost exactly the same way in other languages). People often bring up efficiency, but exceptions imo should not be used in instances where you care about efficiency.
I guess the issue is that they historically weren't adopted, which means it's hard to find engines that use them (unreal doesn't, for example), so the "word on the street" is that exceptions are just something you don't use.
So, that said, it's less about "C++" exceptions and more about exceptions in general. I think try-catch blocks are...arduous to write. In addition, it can be hard to decide whether an error is "worthy" of being an exception. Failing to find an element in a vector: probably not an exception. Failing to open a file for read: maybe an exception?
And because not everything is worthy of being an exception, now you've got two different error handling mechanisms floating around, which is confusing.
Honestly, in summary, I'm not super sure. I haven't yet worked on a project that heavily used exceptions, so I haven't been able to see what works and what doesn't.
Re: The Thread for Programming
Posted: 10 Nov 2014, 01:00
by devil†zukin
same so same
my only thoughts on exceptions: "at least it's not (longjmp|checked exceptions)"
maybe one day somebody will convince me
Re: The Thread for Programming
Posted: 10 Nov 2014, 01:14
by Frozelar
I know that I wasn't asked, but I personally feel like if statements are at least as easy (if not easier) to write as try-catch blocks, can do basically the same thing, and are more widely used/renowned. So I'd always just use an if conditional for error checking/exception handling, personally.
This message brought to you by an amateur programmer who probably doesn't even know what he's talking about. EDIT: Oh wait exception handling is different than error checking
Nevermind
I should just not even say anything haha
Re: The Thread for Programming
Posted: 10 Nov 2014, 06:07
by devil†zukin
typedef system_clock high_resolution_clock;
sigh
wtf visual c++
Re: The Thread for Programming
Posted: 10 Nov 2014, 21:11
by Ashan
RenaBeach wrote:constness looks okay (except for trinkets()/items()/consumables couldnt they be const too?)
If I make them const I get errors in the IDE, like if I put
RenaBeach wrote:also now would be a good time to learn to organise your code into headers and source files (and probably stop inlining functions unless they're simple accessors or mutators)
I've messed around with headers and source files before so I don't think it should be hard to switch them over. When I started the "project" I was just planning on throwing together a little thing but I wanted to do more and more with it so it turned into what it is now, so yeah. I'll fix that.
It'll be harder to post code into pastebin now though. :c
Also I don't know how to not inline functions. I thought inlining was a thing you did manually and it wasn't automatic? Like there's a keyword for inline, so I don't know!
...you should not depend on the inline specifier to cause a function to be inlined.
My opinion is to forgo attempting to have any input on what is and is not inlined. The compiler is way better at determining that than humans are.
Re: The Thread for Programming
Posted: 11 Nov 2014, 02:17
by docopoper
Aaaaaaahhh! I am so agonisingly frustrated!
There was an online coding test for a college internship at Demonware (which has their offices in walking distance from my house, pays well and basically asks for exactly my skillset in their job requirements)... The code test had 3 questions. I found question 1 and 3 super easy. Like... Easy enough that I used 20 of my 90 minutes on them. But question 2 asked me to debug a really simple algorithm involving counting the maximum amount of pairs of the same number there are in an array of bits when you flip one of the bits. The question said that it currently worked for the test data we were given but to modify up to 3 lines because it didn't work on some other type of data. But basically it came down to me testing every single frickin edge case I could find and finding that their algorithm worked in all cases. There seemed to be nothing wrong with it and I spent 68 minutes reading the question again and again, printing the results at every step and everything and it was all fine.
In the last two minutes I finally read the problem. At the end of the second sentence of the question it said that you must flip one of the bits... Not that you may!!! The error only occurs when you have an array of all the same bits... But unless you know that detail you assume that that's it's giving you the correct outcome. So yes... I finally figured it out with 2 minutes to go. I spent one minute trying to fix the code before I went over to quickly submit my answers in the other questions just in case (I had been leaving it off so that I could check it at the end)... But clicking submit popped up this big message box saying calculating your result for 50 seconds with the timer still running!
I am so pissed off that I could easily have 100%ed that test in about a third the time we were given if I had noticed that detail.
At the very least it tells me that my coding skills are way above what they're expecting... I just hope this doesn't mean they don't bother looking at my CV because of some kind of filtering process. 0_o I really want to run and scream and then some how turn back time... But it's 2am... Turning back time is loud and I don't want to wake people up.
*head desk*
Re: The Thread for Programming
Posted: 11 Nov 2014, 03:38
by WhattayaBrian
Welcome to interviews. :)
Whether talking to a person or taking a test, the idea of "illustrate your mastery to us with a time limit" is hard.
If nothing else you have learned a lesson about carefully reading the instructions for the future!
the header use looks good but I haven't looked at it in depth
BTW I've literally switched over to #pragma once since I was sick of the perils of header guards - professors hate it but nobody else seems to
I definitely prefer it to the pervasive badly named header guards seen in a lot of code
Re: The Thread for Programming
Posted: 11 Nov 2014, 05:38
by Ashan
I actually have no idea what #ifndef #define #endif stuff in the header files mean. They were just autogenerated when I made the files so I kept them there.
-shame-
Re: The Thread for Programming
Posted: 11 Nov 2014, 05:40
by pholtos
Let's see if I can remember... Uhh... something about additional files and making sure you don't duplicate something so you put it in there in the header and something magic happens.
...this is exactly why I didn't stick with my Comp Sci degree.
Re: The Thread for Programming
Posted: 11 Nov 2014, 05:59
by WhattayaBrian
Down with header guards.
Down with pragma once.
Down with headers! (Or rather their current implementation!)
Waits for modules
Re: The Thread for Programming
Posted: 11 Nov 2014, 06:01
by WhattayaBrian
+ the time it takes for companies to actually start using that version
Re: The Thread for Programming
Posted: 11 Nov 2014, 06:41
by Ashan
q
Re: The Thread for Programming
Posted: 11 Nov 2014, 06:56
by WhattayaBrian
Typing + narrating + recording simultaneously is super fucking hard.
Explaining programming in a clear and concise way is super fucking hard (look at all the incredibly shitty C++ tutorials out there).
He may not be a good teacher, but that hardly means he's dumb. That's a vitriolic view of someone who clearly made something with the intent to help people (you don't make programming tutorials to get millions of hits).
Damn.
Re: The Thread for Programming
Posted: 11 Nov 2014, 08:29
by devil†zukin
an example of data-driven design (the main reason i'm setting this up to begin with)