Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 May 2003
Offline Last Active Yesterday, 11:13 PM

#5293958 Do you usually prefix your classes with the letter 'C' or something e...

Posted by Oberon_Command on 28 May 2016 - 01:28 PM

Actually, m_ for members and g_ for globals helps quite a bit while reading a lot of unknown code.

The problem is that this kind of convention is brittle. It encodes information about scope into the variable name, but if you refactor to change scope the encoding is wrong and the variable must be renamed.  Forget or neglect to rename the variable and now you've got misleading information.

Any kind of extra encoded information in a variable name can be omitted or out of date by mistake; that holds regardless of convention. I don't feel that's a strong enough argument against the practice. I would argue that if the scope of a variable has changed, then its semantics have changed enough to warrant a rename.

A far more robust convention is to require the use of this-> for members and to require full namespace naming for globals. The compiler can then help you by catching incorrect usage.

I didn't know you could ask the compiler to flag members accessed without an explicit this-> and full namespace qualification of symbols within the current namespace. How does one do so? Without that compiler enforcement, using this-> and full namespace qualification are just more conventions...

#5293881 Do you usually prefix your classes with the letter 'C' or something e...

Posted by Oberon_Command on 27 May 2016 - 05:05 PM

At this point, the only reason I'd entertain prefixing a class name with "C" is if I'm mixing structs and classes in my code and I wanted to be able to forward declare the identifier correctly without going back to look at its declaration. In a codebase sufficiently large that hitting "Go to Definition" can take longer than a minute, this can actually be quite useful, if perhaps of dubious value in the general scheme of things. For small codebases, it's basically not a problem.

#5292394 Why does this change the list to string and this doesn't do that? Python.

Posted by Oberon_Command on 18 May 2016 - 07:29 PM

You haven't told Python that it shouldn't. When your code executes the else block, it will set active to 0, but it will still be in the same block that executes if active == 1 - the condition has already been evaluated by that point in the program. Changing active to be 0 won't "rewrite history". ;)


You could either test to see if active is still 0 before you execute add_item = ..., or just put that line in the block that executes if item_holder in Items. Eg.

if item_holder in Items:
    add_item = input("Would you like to add more items? If so, enter Yes.\n")
    print("This isn't an item, sorry.")

#5290802 Quick help on const

Posted by Oberon_Command on 09 May 2016 - 08:34 AM

Alright folks! gonna use const Node* getChild(int index) const for now instead of getChildren() to get the whole thing. I literally have no use of it for iteration whatsoever outside itself anyway.

That isn't going to get you what you want. This returns a pointer to a const Node. The pointer will be mutable, but the Node itself won't be. You won't be able to modify the returned Node as you desire without removing the constness. const-correctness also won't allow this to be a const method in this case. If you want to modify something in an object through a method, that method must be non-const.

This is why I suggested returning a non-const reference or pointer above. ;)

#5290733 Quick help on const

Posted by Oberon_Command on 08 May 2016 - 07:13 PM

My goal on this code is, I want to return a private _children where everyone can only modify its values, but not the _children itself.

My suggestion is that instead of having a method that returns the collection of children itself, have a method that takes a child's index and returns a non-const reference (or maybe a pointer so that you can return nullptr if you pass in an invalid index) to that child. In this way, the clients of the class will never see the container at all. Of course, that on its own may not suit your needs if you need to iterate through the container; in which case, you might expose begin() and end() methods that delegate to those methods on _children.

#5289740 Is using the Factory or Builder pattern nessesary?

Posted by Oberon_Command on 02 May 2016 - 08:48 AM

I spent ages trying to get this through to people some years back.

I would see code often from students which referred to design patterns all over the place where it seemed like patterns had been used for patterns sake, and the names of objects purposefully renamed to the names of patterns which lead for extremely confusing source code.

No amount of explaining would get these people to understand this was wrong. It seemed to me an extreme case of ivory tower syndrome.

I'm glad I'm not the only one who realised something was out of place...

You're fighting an uphill battle. Let me tell you how my second-year "software development" course went - first we learned some things about the Java standard library. Then the prof gave us a list of patterns that we had to know for the final and assigned class assignments and homework where the sole purpose seemed to be "apply the pattern to the situation." I heard students in said class assignments say things like, "Okay, what pattern does the prof want us to apply here?" The same sort of assignment repeated itself on the exam. The course was much like many at the low-undergrad level - a memorization and regurgitation exercise.

This was in 2009 or thereabouts. Things may be different now, of course, but I surmise this approach makes homework much easier to grade for bored computer science profs/TAs who would rather be doing research than evaluating the merits of hundreds of students' software designs, so I'm not optimistic. Though my 3rd and 4th year-level software development courses were much better, if only because the 2nd year course was the second programming course for most people who took it and profs could actually talk about design without talking so much about programming in the later courses, but the "pattern-think" of the early class is never fully undone for some people.

To the OP: no, using patterns is not mandatory, and I'd say that anyone who tells you different is talking out their ass. Write your code first, then use patterns to talk about it after the fact. Using the pattern names in your class names and the like is okay, since it gives your readers information that may be useful, but never approach a problem with the attitude of "what pattern should I be using here."

#5289292 getting fired in software industry

Posted by Oberon_Command on 29 April 2016 - 01:14 PM

its not my problem to work with undocumented code

I don't mean to depress you further, but unfortunately, it is. We work in an industry where a good deal of code isn't documented; in fact, sometimes even intentionally so! I have worked with at least one group that specifically prohibited documentation comments on the ground that they often become out of sync with the code and can make the code less readable. Of course, some software is simply so poorly written that you do need documentation or "tribal knowledge" to understand it, but a good company should know that and take it into account when "on-boarding" you. But approaching work tasks with the belief that you are entitled to people doing things the way you think is best is a recipe for disappointment and nothing getting done.

I say this from personal experience; on my first day on at work after I finished school, I was given my door key, shown where my desk was, and then told to that I needed to make a feature work on the project to which I was assigned. They showed me how to access the codebase I was to work on. Then I was left alone to either ask questions or figure things out on my own. No real documentation of how the code (written in archaic, pre-standard C++) worked besides comments from about 15 years ago. Largely speaking, I was able to figure things out on my own; I did ask questions, but my coworkers were busy trying to ship a game, so I did my best not to ask too many of them. The last codebase I worked on was probably at least an order of magnitude more complicated, and though it had somewhat more documentation for some subsystems, it was large enough that most didn't have any beyond the code itself.

But keep your chin up - the good news is that working with undocumented code is a skill you can develop with practice, or at least I believe so. You can do this by reading and debugging a lot of code - especially code you didn't write. Fortunately for you, there is a lot of open-source code on the internet just waiting for you to read, download, and execute it!

The best approach I've found so far is to take a scientific route - look at code, form a hypothesis about what it does, then test that hypothesis to see if you're right. If you prove yourself wrong, change your hypothesis and try again. Keep doing that until you prove yourself correct.

edit: Note that I'm not advocating never asking questions or never documenting your code as good ideas. I'm simply pointing out that very often you can't depend on others to do things the "right" way, so it's not a good idea to get your expectations up.

#5288781 OOP and DOD

Posted by Oberon_Command on 26 April 2016 - 12:01 PM

I think I'm even more confused now than I was before. People, and even you, are saying that DOD is more efficient, but at the same time you're saying that it's not? It is but it isn't? :(

It seems like you're looking for one of us to state that one of these is always faster. That is not the case - we would be spouting dogma if we said that. It really depends on what you're trying to do, your data is (same thing), and where your latencies are. DoD can be and usually is more efficient, but it doesn't always result in more efficient code since not all algorithms can be arranged to operate on streams of contiguous data.

You should also stop thinking of DoD and OOD as opposites. Sometimes the data layout in a DoD solution is equivalent to the one in the OOP solution, meaning that the DoD and OOP solutions are the same thing, for one thing. Remember, OOP is fundamentally a modelling tool that focuses on maintaining state invariants. You can use OOP to implement a data-oriented design, if not on the usual level of granularity of typical OOD.

Is it like using a std::vector (continuous memory, faster) versus a std::list (not continuous, slower)?

That's a good example, yes. But I am reluctant to claim that every data structure can be represented efficiently with a vector (or several vectors) or something like it. Many or even most can be, but that doesn't mean there aren't cases where you need to do something different. Same thing applies to DoD.

#5288711 OOP and DOD

Posted by Oberon_Command on 25 April 2016 - 11:28 PM

Thanks so much everyone. From what I gathered it seems that DOD, or functional programming,

Not quite. Again, you have your terms mixed up. "Functional programming" is something else entirely.

I would just call it DoD. As far as I know, it doesn't have any synonym. Its more vocal proponents might just call it "engineering," but not everyone would agree with that claim.

#5288628 OOP and DOD

Posted by Oberon_Command on 25 April 2016 - 11:57 AM

DOD as I mean it here refers to structures with external functions that use them.

That isn't data-oriented design, that's procedural programming. That's not even necessarily "not object-oriented programming" - you can write "object-oriented" code in that manner.
Data-oriented design is structuring your code around your data and how your data is going to be processed, rather than focusing on code as an end in and of itself.

You may find this reading useful. And this. And this.

#5286556 I need a book (or somebody's project source code) which properly explains...

Posted by Oberon_Command on 12 April 2016 - 08:24 PM

Your terminology is off.


What you call the "abstract class" is actually just a "class" - it's a definition of the data and behaviour for an instance of that class - an "object."

What you call the "prototype" is actually the definition of a constructor - a function that is called when an object is initialized or "constructed."


Judging by the content of your posts, I suspect you don't know OOP as well as you think you do, or learned it from a source that doesn't use the same terminology as the rest of the industry. It may help us give further advice if you were to more explicitly state your understanding of what it means to be "object-oriented" and, indeed, what an "object" is. For example, what do you mean when you say "type object?" While I have no direct experience with Bjarne Stroupstrup's book (nor am I even sure which book you're referring to), I imagine it should explain the gist of what you're looking for if perhaps not in terms you're familiar with.


Also, since part of the utility of OOP is managing the complexity of larger programs, you'll find that most "practical examples" of it are likely to be much larger than 2 files - "expertly-written programs structured to be extendable" is kind of the point of object-oriented design. In a well-written object-oriented program (or really any program, for that matter), you shouldn't need to understand the entire program to understand what any given piece of it is doing. If you need to understand the whole program to understand a piece of it, then your design is a failure. ;)

#5286209 Nothing renders in windowed mode on Windows 10 with dedicated Nvidia card

Posted by Oberon_Command on 10 April 2016 - 05:04 PM

I found it!


First of all, what didn't work: I tried the set of flags AthosVG posted; no difference in behaviour. I also tried pasting Luna's equivalent code to see if that would make a difference; no difference in behaviour. I looked at compiling the full samples, but they depend on D3DX and XNAMath which I apparently don't have since I'd heard these were deprecated. Is there a more up to date version somewhere?

I had a look at the samples here and those do appear to run correctly in windowed mode. Near as I can tell, I'm not doing anything differently, though I'm using the 11.0 code path instead of 11.1. I don't think that should make a difference - I broke into the samples in the debugger and forced them down the 11.0 path to see what would happen and they still worked correctly. In fact, I took my own initialization code and pasted it into the sample code (rearranging some of the names) and everything still worked correctly!


Then I looked at the initialization code and noticed that I'm deriving the back buffer width and height from a configuration file, whereas the tutorial is computing it directly from the window's client rectangle. Changing my code to use the client rectangle bounds for the back buffer got things rendering again! I also noticed that in windowed mode, the window's client rect appeared slightly smaller than it did when I ran the program on 8.1 - as though the window borders take up more room and infringe on some of the client rectangle where they didn't before. So maybe the OS has changed the way window sizes are calculated? Strange that this would only manifest when using my dedicated card, though.


So: moral of the story, ensure that your back buffer size matches that of your client rect!


edit: And it did indeed sound like coil whine. My best guess (without being much of a graphics programmer) for what must have been happening was that the back buffer was created successfully, but with a 0 size, causing all my initialization and draw calls to succeed without actually doing anything meaningful.

#5285810 Should getters and setters be avoided?

Posted by Oberon_Command on 08 April 2016 - 09:22 AM

Map<Integer, Creature> CreatureMap = new HashMap<Integer, Creature>();
Map<Integer, Stats> statsMap = new HashMap<Integer, Stats>();
Map<Integer, Equipment> equipmentMap = new HashMap<Integer, Equipment>();

public void createCreature()
  int index = getNextIndex();
  creatureMap.put(index, new Creature())
  statsMap.put(index, new Stats());
  equipmentMap.put(index, new Equipment);

public void mutateCreature(int index)
  creatureMap.put(index, creatureMap.get(index).mutateSomething());
This looks crazy to me (but is it? I'm trying to learn something here and my assumptions or thinking pattern might be completely wrong), the creature should have it's properties inside it. Some properties can be abstracted in there own classes if that makes common sense but one can still end up with an object that has many properties. If we do what Yegor suggests we do, making all these properties final then we inevitably end up with large constructors or a builder pattern with a large amount of mandatory properties.

This looks to me like an entity-component system. We've been getting lots of questions about those recently. There are some advantages to this kind of approach as long as you don't follow it too dogmatically. In particular, it lets you not bother creating the components that don't need to exist for an object - do trees really need pathfinding, for example? Does a player character really need an AI state? What about creatures that can't (by design) carry equipment? Though, this particular point applies to composition generally.
I'd hardly call it crazy. My own side projects follow this sort of architecture because it makes it easier to add new features and because it allows me to use existence-based processing on the resulting components. In a lot of cases (not all) this makes the resulting code simpler.

#5285459 If statements are all you need

Posted by Oberon_Command on 06 April 2016 - 11:52 AM

It looks like something someone would write who had a very, very basic understanding of C#, and both a lot of time on their hands, and an unwillingness to learn more about C#.

This. 10-year-old me wrote code like this in QBASIC before he knew any better. Kudos are due for actually releasing it AND getting positive reviews.

#5285045 I am beginning to hate the IT and gaming industry (Part 2)

Posted by Oberon_Command on 04 April 2016 - 11:12 AM

I believe these sum it up nicely, as it has been my experience also.  Now, I've heard many of you say, "interviewers are more interested in your problem solving skills than how well/accurately you code the actual problem".  I always have and always will call bulls**t on that.  If that's so, then why do I NEVER get the job unless I nail the whiteboard problem on the first try with no error and at full optimization?  I've demonstrated great problem solving skills and have been commended on it multiple times, but still didn't get it because I didn't do the problem perfectly.  So you can tell me this until you are blue in the face and I will never believe it since I've been through many, many, many white board interviews.

I'm a bit on the junior side, but I've also never been asked to do whiteboard coding. While I have been asked to use whiteboards to explain my thinking, the only times I was coding were either on paper as part of a written exam or in an actual IDE, on an actual PC.

I suppose you've ruled out the notion that employers are using absurdly high standards of whiteboard coding and experience to weed you out for reasons unrelated to your actual technical competence? I wouldn't be terribly surprised at some employers having a "favored candidate" and going out of their way to make things tough for people who aren't that candidate - or don't "look" like their ideal candidate, either in terms of personality/temperament, experience level, or even (sadly) things like race or gender.

What the hell is "overqualified"? Don't you want someone that can go above and beyond for your company?

According to what I've heard, in addition to what frob said, "overqualified" means "will get bored and leave if we don't pay them a salary higher than what we want to pay."