Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Oberon_Command

Member Since 07 May 2003
Online Last Active Today, 07:52 PM

#5213136 Non-Member Functions Improve Encapsulation?

Posted by Oberon_Command on 26 February 2015 - 12:32 PM



Specifically when if comes to C++, could someone please explain to me why creating non-member functions is said to increase encapsulation for a class?

 

I kind of don't understand that, if I have a non-member non-friend function then anything I can manipulate for that class has to be in the public sector. And the way I see it, which I could be very very wrong here, is since that everything is already out in the open (public) there is no encapsulation of that class

 

It can increase encapsulation. That doesn't mean it will - it depends on how you do it. :)

 

The case where it will increase encapsulation is where the only things the world knows about your class is that it exists and that the non-member functions exist. Having non-member functions as your public interface means that users of your class don't need to know the definition of your class to use it. Sort of like how C's FILE API works - you're not supposed to actually know what the definition of a FILE structure is, and in fact most of the time you don't, so your only access to this structure is through the functions that manipulate it.




#5212587 Getting Destroyed in Programmer Screeners

Posted by Oberon_Command on 23 February 2015 - 06:43 PM

Another thing:

 

 

I'm aware of how its important to avoid heap allocations. I've aware of various methods of how to do that. But the question in particular isn't just about that. Its about a lot of different things, and nothing is immediately clear of what they expected/wanted out of that question even months after I answered it. I still don't know what the optimal answer is. I've re implemented 3-4 different designs and I can't really tell you which one they would've liked more. Perhaps NONE of them! I have no idea and may never.

 

Writing code for a job interview isn't really about which solution they "like" more, it's about demonstrating your ability to do something. You (usually) aren't graded on how close your implementation is to some reference implementation. Oftentimes there isn't a "best" solution at all, only solutions that work and meet the requirements given. Your interviewer is likely more interested in seeing how you think - how YOU approach a problem - how well you can think on your feet. It seems like your approach tends toward trying to please your interviewer, not demonstrate your abilities and thought process and creativity. Once again, the way you're approaching this might work in school, but I don't think employers are really interested in candidates who approach everything that way. Trying excessively to "please" your interviewer might suggest someone who has trouble thinking and working independently, which is obviously undesirable in the game industry.

 

It seems to me that you really are capable of doing lots of things independently, so show that off. Again I recommend bringing a laptop with demos of projects you've done to interviews. Let your accomplishments speak for themselves. :)




#5212584 Getting Destroyed in Programmer Screeners

Posted by Oberon_Command on 23 February 2015 - 06:35 PM



 

And and day/night I'm working on improving that. I just am finding it ridiculously hard studying/juggling both high level and low level programming concepts at the same time. One interview I recently had that I referred to in the OP was WAAAAAAAAAAAY easier than that I initially anticipated and we covered so little content that I may have completely goofed some of the questions. So its like burnout. I can talk about all these little details about cache, bit twiddling, implementing the queue in a static byte array, blah blah - but then you ask something simple like.... re implementing a particular math operator without using said operator and I choke a bit. Not because I don't know it, I've done it before, I've read it before, but because I haven't done it in so long and my mind is somewhere else entirely due to preparation.
 
I don't know if maybe my issue is memory or something. Like I'm all prepared for deep technical questions but ask me a question in an area that I otherwise would be ready for, and I may likely break down. Its akin to what everyone hates in school: you have a bunch of big exams in various classes right? Then you sit down in some other class and BAM - pop quiz. The content is nothing like what you've been studying vehemently over the past week or so and its like the Twighlight Zone. Your mind is everywhere but nowhere at the time. Its so frustrating and I don't know how to combat it.

 

Stop "studying" for interviews. It seems obvious to me that it isn't actually helping you and anyway you shouldn't need to study for a job interview. I always felt that if you study too much for an interview, then it isn't a fair test of your abilities - it's a test of your abilities after studying something for a while, which by and large is not a circumstance that actually happens at work. The only studying I ever did for a job interview was my own code so that I could talk about what I've actually done with the interviewer. This isn't to say that reading up on technical things is a bad idea in general - it's always good to refresh your memory of what you are claiming to know - but my overall point is that you're approaching this like a student preparing for an exam. Your wording and analogies confirm this to me. That is not what employers are looking for. If you're coming across as having "rehearsed" your answers to questions or "crammed" your knowledge the night before, they might think you're faking your abilities to get a job and therefore you aren't actually qualified, which is really not what you want people to think. :)

 

As you've rightly pointed out, you can't you can't predict what will be asked, and trying to predict that doesn't seem to be working, so try something else. Using your knowledge to do something related to what you're interviewing for (writing a demo, for instance) is a much better use of your time, I think. Remember that "I don't know" is an acceptable answer during a job interview, particularly if you can demonstrate that you know how to find knowledge that you don't have. 

 

As for the easy vs hard questions throwing you for a loop, my advice is to stop and THINK for a bit before answering, and ask for clarification if need be. Never assume that you heard the interviewer right the first time. This will be much easier if you stay calm and relaxed during an interview. Most of the time I take before a job interview is actually relaxing, not studying. From what you're telling me, it sounds like you're quite nervous during interviews and employers are seeing that. 

 

An interview is just as much a test of your demeanour and personality as your technical abilities.




#5212173 Getting Destroyed in Programmer Screeners

Posted by Oberon_Command on 21 February 2015 - 05:34 PM



[1.] The amount of vector math theory expected has been pretty mind boggling to me. These engines almost entirely hide those theories and automate it for you, so when these screeners ask to implement them, I tend to get stuck. I eventually come up with answers that I can test and they seem right and when I look them up to check they work out.

 

[2.] If I get past the screener, I then go into the phone interviews and there its "anyone's game" it feels like. I've been asked cache->ram cycles off the top of my head on one interview, another interview asked about a plane projection algorithm to be verbatim, a different interview wanted to know specific information about mutex locks and flags. I have experience or general knowledge I can talk about in all these areas, but I really struggle to regurgitate specifics on the spot.

 

[3.] Some interviews, say for tools or generalist programmer positions, switch gears from C# to C++ to Python super fast and that throws me off too because its not like I don't know them, but to study 3 different languages in detail for an interview is seriously tough.

 

[4.] I'm not exaggerating when I say these interview topics, regardless of the position, feel like total crapshoots as to what is fair game to ask. Its SO MUCH material at varying degrees of detail. I have an upcoming interview next week and I couldn't tell you the kind of questions I might get asked despite having already spoken to someone on the job. When I went to interview with Google in person, I knew the kinds of questions they would ask which doesn't necessarily make it easier but it makes it so much more approachable and I don't feel like a panicking mess when I get asked questions.

 

0. My advice is to bring demos to interviews. That's what I've done for every one of my in-person interviews (obviously couldn't for a phone interview tongue.png) and it's worked out pretty well so far.

 

1. A lot of the math might be implemented under the hood for you, but you will almost certainly need to understand how the math works to be able to use it in an effective and efficient manner. If you can't do even basic vector math from first principles, you're probably not qualified. Though you could always say "I could easily look this up" and then give ideas on the consequences of what the math could be.

 

2.  While asking specifics of how many cycles it takes to move memory between RAM and the cache(s) seems a bit odd, I could see them asking you this if the position was for low-level development on a console, where stuff like that starts to matter. It sounds like they're just testing your knowledge to see how much you know - you don't need to know absolutely everything. Interviewers will always push you until they find some gap in their knowledge, if given enough time. I think it's more likely that they're probing you to see if you understand why cache utilization patterns are important, particularly on modern consoles.

 

3. Depending on what you're doing, you will likely need to switch between 2-3 languages on the fly in your daily work, so this makes perfect sense to me. This is particularly true if you're on some sort of infrastructure team, like a AAA tools team or a build engineer. When I was a co-op I would often find myself debugging code in C#, C++, and Python all in the same half hour. You don't need to necessarily know a language in depth for this to work, since (again) you can always look stuff up when you're actually doing it.

 

4. This is probably a good thing, honestly. If you really know in depth what sort of questions are likely to be asked, then is that really a good test of your knowledge and reasoning skills? If you can "study" for an interview by practicing answers to likely questions, then you aren't showing your ability to synthesize knowledge, you're showing your ability to memorize the answer to a question ahead of time. The latter skill is very useful in an academic setting, but it's not worth nearly as much as being able to think on your feet. 

 

The thing is, game development is a volatile field where you can expect to run into unexpected things a lot. We're in the business of inventing stuff, not building yet another business app. Being able to respond to the unexpected is a useful skill that's arguably necessary in some positions in the industry, particularly anything gameplay related (designers love to add, remove, and tinker with features at the drop of a hat). 

 

I could make several more games and it wouldn't be related at all. I could go and make a dozen games in Unity or UE. Not one of them will improve my ability to "create a queue structure that has manual alloc and dealloc methods that do not use heap, but instead, a provided 2048 char/byte array as storage" I couldn't even force a scenario like that if I wanted to into an indie game. Why would I?

 

I've worked on a couple of games that had data structures like that. That sort of thing is useful in any scenario where you want to avoid heap allocations - so quite often! Even in Unity you should be avoiding heap allocations during gameplay for the performance reasons alone. Heap allocation is slow, can lead to slowness (through cache misses), and in a managed language will eventually trigger a garbage collection run, which of course can lead to hundreds of milliseconds lost off your frame time.




#5209357 Game ethics

Posted by Oberon_Command on 07 February 2015 - 10:12 PM



I feel discussing this very topic to be pointless. 

 

I disagree. Discussing ethics very much has a point, even if appears to progress nowhere. The exposure to others' ideas is good for us, first of all. Second of all, see my point on "reality checking" - putting forth our ideas of what is right and wrong allows others to test them for validity and soundness, and others to do the same of their own even if they present none of their own points. Maybe you find that discussing this topic serves you no purpose; fine, leave the thread to us who find it interesting if not meaningful to play with each others' ideas.

 

Maybe just maybe we could have had a rousing discussion about ethics in a civilized manner and come to some interesting conclusions about the subject, perhaps even changing each others perspective on the topic, but once a conversation devolves into the unbridled shitfest we all find ourselves standing in there is no hope.

 

I would not call this thread an "unbridled shitfest." I would call it a spirited discussion where it appears people are getting rather involved in the points presented. Frankly, I see that as a good thing, as a sign that the discussion has progressed far enough to challenge preconceptions and basic, ingrained philosophical axioms; a sign that we are actually discussing things and not dancing around each other doing our best not to step on each others' toes anymore. In short, a discussion that is going somewhere interesting.




#5209287 Game ethics

Posted by Oberon_Command on 07 February 2015 - 12:02 PM


We can have a meaningful argument about whether the browning on a piece of toast is in fact an image of the virgin marry. I guess toast is art now, too.

 

I think toast can be art, just like lattes can be art. It's just that most toast isn't art because most browning patterns on toast are not created intentionally (but are a byproduct of random chance) and the browning patterns on the vast majority of toast are not meaningful to anyone. smile.png

 

 

I guess we are just going to define art in the broadest possible sense, which makes the term pointless but w/e.

 

How does that make the term pointless? If art is definable in the broadest possible sense, then a definition that excludes those things that are included in that "broadest possible sense" definition is (by definition) wrong. Besides, the definition I've given is sufficiently restrictive to cut off silly things. Consider, for example, an anecdote I heard about a modern art museum in which a glove was dropped by a visitor in the midst of the gallery. The other visitors avoided touching the glove for fear that it was an art piece! This seems obviously silly to most people, and it is - the glove was not dropped intentionally. But I think wouldn't be so silly to label it "art" if a person had intentionally thrown the glove on the ground, particularly for the purpose of putting the glove on display.

 

 

As far as know THE only meaning of GTA, I'm talking about the intended and the majority opinion. Which may or may not be the same. I'm not going to accept the fucking stupid idea that anything anyone thinks about anything is equally valid with everything anyone else thinks about anything. Why the fuck would you ever talk about anything at all given that that was the case.

 

Of course not everything anyone thinks about anything is equally (logically) valid - validity requires that a persons' thoughts be self-consistent. Furthermore, validity is not soundness - it's perfectly possible to have an interpretation that is valid (because it is consistent with its premises), but not be sound (because its premises are false, ie. the facts of the art being analyzed don't support them). But when I used the term "validity," I was referring to experience - not only "thoughts", but also emotions and general mental state. Are you saying there are cases when an emotion is invalid?

 

I can think up a zillion ways to interpret anything all on my own, what do I need you for then?

 

Reality checks. As you rightly believe, not all interpretations are valid or sound - you need us to point out any logical flaws your interpretation might make and any premises that might turn out false. Sometimes our emotions tell us that an interpretation is valid when in fact it isn't - that makes the interpretation invalid, but it does NOT make the emotion itself invalid, and the fact that the emotion is there blinding us means that we need somebody else to point out that we are blinded.

 

 

The same with Hodgman's stupid shit about anything a grown adult consents to being okay

 

Why is that stupid? Why shouldn't people do things that are dangerous, or strange, or even kinky, if their behaviour affects only themselves? You're going to have to do better than a derisive assertion if you want to convince anyone that this particular, very conventional moral axiom is "stupid" or "wrong." That's a whole separate discussion to this one, I think.

 

However I was clearly under the mistaken impression that people posting in a thread called game ethics, actually believed that it was possible to make an unethical game.

 

Of course it is possible to make an unethical game. Nobody is denying that as far as I can see. The argument I am making is that an "unethical game" refers to unethical behaviour on the part of the developer.

Games that exploit players' psychology for their money without providing value are unethical.

Games that intentionally damage players' property (via DRM and the like) are unethical.

Games that spy on players personal information are unethical.

 

Games that depict unethical behaviour are NOT "unethical" - their content is unethical. I distinguish between the two, and it appears others here agree with me.

 

I could make a game about murdering Jews in the Holocaust where you roleplay a dedicated Nazi officer, and by your definition, that's like, art.

 

Of course it could be art, just as paintings of events of the Holocaust are still art. Or are you saying that paintings and films depicting the Holocaust are not art? ;) I still wouldn't play it, because that's not an experience I'd particularly like to roleplay. Furthermore the concept of glorifying actual genocide is offensive to me, and on the face of it your notion of a game about murdering Jews in the Holocaust is that. I'd probably send funny looks at anyone who did play it. But "offensive" is not "unethical" and makes no sense to dismiss something as "not art" merely because it contains content that offends you. Of course, if nobody can present a sound interpretation of any kind of deeper meaning from the game - that is, the game doesn't "say something" either intentionally or not - then it isn't art.

 

Now, a game like that done well could very well be art and still feature that sort of gameplay. Suppose the game were built in such a way that players came to understand how the Nazis came into that mindset in the first place - how the monsters came into being, as it were. Then the game would have an educational function, and therefore would be "saying" something and therefore would be "art" according to my definition. I recall hearing of a classroom experiment that worked somewhat along those lines....

 

I'm sure you would totally play that as wicked satire if I included, like GTA, just a slight bit of faux self-awareness to give you an excuse. Because otherwise you would just be admitting that you like GTA because you like robbing fake banks and murdering fake people and not because of its oh so clever satire. Yet I suspect that the reception of this game, purely because of its topic, in a hypothetical world where its "quality" was equivalent to GTA, would not receive nearly the same reception.

 

A game like that could be satire. Very, very offensive satire that would be walking a very thin line of acceptability. From your description alone I would say that it isn't "satire", since that term is not a label that can be applied arbitrarily. I'll leave it to players of GTA to explain why it's satire, it's not a game that I play so I don't have all the facts in front of me. 

 

 

I mean, maybe you are part of the .1% of actual relativists but I've confronted the satire argument 1000 times, whether about GTA or something else and in the end my picture of reality ends up more accurate by dismissing claims of relativism as fake. I would be irrational to accept your argument without the sort of evidence Hodgman insists he needn't provide because he is on the status quo side of the argument. Well its technically true Hodgman, and/or Oberon, that you don't have to defend the status quo, not for theoretical reasons but for practical ones, a position of power needs no defense beyond itself. But such an argument says something about your character.

 

Well, I for one would like to hear this evidence myself, if only to use it in my own arguments. But I think the point being made there isn't the one you think it is. Surely you know what a null hypothesis is? Or are you one of those who advocates for abolishing methods of analysis that use null hypotheses? smile.png

 

I'm not sure what you mean by ".1% of actual relativists". So far as I am aware, the number of people worldwide (and particularly in Western cultures) who ascribe to some sort of moral relativism is far greater than .1%. At least where I'm from, and among people of my generation, reaching some sort of moral nihilism (and having the resulting existential crisis) is a fairly regular occurrence in one's teen and early adult years.

 

 

Because right now you guys disgust me. If I were you, I'd go wash off the slimy shield of faux-relativism quick, lest someone catch its stench on you.

 

First you accuse me of sucking from the teat of total relativism, now you say I'm a faux-relativist? Which is it? With all that effort going into the derision in your post I'd have thought you'd at least be consistent, though if your arguments are driven by emotional prejudice concerning the subject matter that would explain it. You certainly are being awfully derisive of rather conventional ideas, though that in itself doesn't make you wrong. I find it a little concerning that you are so easily disgusted by ideas alternative to your own.




#5209226 Game ethics

Posted by Oberon_Command on 06 February 2015 - 11:52 PM



 



For clarification, are we talking about the ethics presented by the content or by the form? If we're just talking about content, then I'd like to point out that violent video games exist because violence exists in real life. Part of the value of art is that it reflects the world in some way. Games are an artistic and imaginative medium - to constrain them to only depicting ethical behaviour would be like constraining novels or paintings or films to only depicting ethical behaviour.  If we're talking about form and presentation, I refer you to Ravyne's post above.

You're post makes no sense. The problem with games like GTA isn't that they display and simulate negative behavior to and for the player, its WHY they do this. For instance Hodgman's defense that GTA is super clever satire. That's a ridiculously indefensible decision for anyone not invested in believing that so that they can play it without feeling bad about themselves, better to just admit they like GTA for what it really is, but at least it is made with an understanding of the topic. 

 

 

Okay, which part makes no sense? I thought it made perfect sense when I wrote it in that it is clear English, asks a concise question, and attempts to concisely present a coherent and consistent point. So which of those things does it fail at? Are you saying it's off-topic? smile.png

 

Furthemore, why, in your own words, does GTA simulate negative behaviour? It seems clear to me that you think you know what the (one and only) meaning of GTA is. What do you think the purpose of GTA is and with what authority do you claim to limit GTA's meaning in that way?

 

COD serves no artistic purpose. Games can be art, as movies can be art, but not all movies and games or drawings are art in the sense that they convey a deeper meaning. Bodice-rippers are an old and popular genre of book but they aren't art just because someone also wrote an erotic novel that was art. Gone Home is art, though whether its good or bad art is up for debate. But GTA is not art.

 

I take it you're not up on your Roland Barthes. Otherwise you would surely understand that the meaning of a work to individuals in the world at large is independent of its creator's intent. COD may serve no "artistic purpose" (if that is a meaningful term) to you - it doesn't to me, either, and perhaps not to its creators - but that's irrelevant. If COD means something to someone, somewhere, then it has acted as art. The same is true of GTA - its status is art is based on perception, and some perceive it as satire, so for them that is what it is, and their experience is just as valid as your own not-experience. Furthermore, I'd argue that the very fact that we can argue about what the "meaning of GTA" is, and have that actually be a meaningful argument in and of itself, makes it art.




#5209212 Game ethics

Posted by Oberon_Command on 06 February 2015 - 08:40 PM

For clarification, are we talking about the ethics presented by the content or by the form? If we're just talking about content, then I'd like to point out that violent video games exist because violence exists in real life. Part of the value of art is that it reflects the world in some way. Games are an artistic and imaginative medium - to constrain them to only depicting ethical behaviour would be like constraining novels or paintings or films to only depicting ethical behaviour.  If we're talking about form and presentation, I refer you to Ravyne's post above.




#5207754 Comparison of STL list performance

Posted by Oberon_Command on 30 January 2015 - 03:41 PM

Behold the power of templates. To achieve similar performance in C, you'd have to write a separate list-node for each small data type you wanted to use, and the whole set of linked-list functions to operate on it.

 

Not necessarily. I can conceive of doing some sort of intrusive container using zero-length arrays. That might seem a little smelly, and you'd have to pass the size of the node type into the node allocator you were using, but I think you could make it work. Totally off the top of my head, no compiler has touched this code so it may contain typos:

 

/* intrusive linked list node - note the zero-length array */
typedef struct _IntrusiveNode {
    _IntrusiveNode* next;
    char data[0];
} INTRUSIVE_LIST;
 
INTRUSIVE_LIST* push_uninitialized_node(INTRUSIVE_LIST* head, size_t data_size) {
    INTRUSIVE_LIST* new_head;
    new_head = malloc(sizeof(INTRUSIVE_LIST) + data_size);
    new_head->next = head;
    return new_head;
}
 
INTRUSIVE_LIST* push_node(INTRUSIVE_LIST* head, void* data, size_t data_size) {
    INTRUSIVE_LIST* new_head;
    new_head = malloc(sizeof(INTRUSIVE_LIST) + data_size);
    new_head->next = head;
    memcpy(new_head->data, data, data_size);
    return new_head;
}
 
/* helper macros */
#define INTRUSIVE_LIST_PUSH(h,d) push_node(h,d,sizeof(*d))
#define INTRUSIVE_LIST_PUSH_UNINITIALIZED(h, s) push_uninitialized_node(h, sizeof(s))
 
/* usage */
head = INTRUSIVE_LIST_PUSH_UNINITIALIZED(NULL, int);
 
/* look, I can even mix and match data types!
float data = 0.0f;
head = INTRUSIVE_LIST_PUSH(head, &data);

 

Granted,you now have a memory copy step if you want it initialized, but you could elide that if you just wanted to emplace an uninitialized node on the list (as I've shown). Oh, and you don't have the typesafety of the templated version.

 

Can anyone find anything wrong with this?

 

edit: But really, depending on your platform, you shouldn't be using linked lists, anyway.




#5206997 Some programmers actually hate OOP languages? WHAT?!

Posted by Oberon_Command on 27 January 2015 - 03:23 PM



 

I'd love to see an example where an use of it has made the code more readable and easier to maintain by the way smile.png

 

I don't have any specific example for you at this time, but I will point you to some people who can expound on that subject. There's the points raised in http://www.dataorienteddesign.com/dodmain/, and the ones Mike Acton raises in his CppCon talk and "typical C++ bullshit" slides. I'll summarize what I took from both of those:

  • having your data declared in a simple, straightforward way instead of hiding it behind layers and layers of encapsulation and abstraction makes it easier to reason about what state the program has and what subsystem owns it - and I'd add that in a more data-oriented programming style, you might segregate your data by how often it is mutated, which can make it easier to understand where state changes happen
  • implementing functionality by composing transforms of collections of data allows you to more quickly find where a bug is actually happening because your state mutations occur in specific places meaning that you can quickly find where a corner case was missed or where an unintended side effect is happening
  • existence-based processing can cut down on the cyclomatic complexity of the code by reducing the number of checks for validity you need to do - and in my experience, checks for validity (ie. null pointers and such) negatively affect code readability in a huge way
  • concurrency becomes easier to implement and debug when you build your program by transforming sets of homogeneous data instead of structuring your program around transforming individual pieces of data in isolation

To me, the essence of being "readable" means that I can understand what a program is trying to accomplish and how it goes about accomplishing that with a minimum of effort. A program that is "easy to maintain" is one that is easy to debug and easy to change in such a way that I don't introduce new bugs in the process. My impression of data-oriented design is that while it might appear that these data-oriented systems take more effort to change, I think ultimately how long it takes me to make a change is more important than how much code I need to touch. Those two things are related - "effort" here means the time to make the change plus the time to debug it - but given the choice between making a larger number of small changes that I have high confidence won't break anything and a smaller number of changes that are more likely to break something elsewhere in ways that I need to think extra hard about (eg. if I fix a bug in a base class that breaks subclasses), I'll take the former.

 

My experience with my own code (which I've recently started writing in a more data-oriented way even for gameplay code) is that I tend to add new features by adding new subsystems instead of modifying big swathes of existing code to add the features to all the different classes that already exist as tends to happen with the (object-oriented) projects I've worked on and still work on at work. Most of the true object-orientation in my own code occurs at the feature subsystem level, not at the individual data object level. This not only means that it's easier to fix bugs in specific features (because the code and data for those features is all in the same place), but my confidence in the correctness of the existing codebase gets continually higher as I add new things. I already spent time to make it work, and I'm not changing it, after all.

 

It might be interesting to take a reasonably complex program and implement it in "typical OOP" and "typical DOD" and compare the two to see how easy it is to do different maintenance and implementation tasks in each system.

 

edit: And I think it's a misconception that data-oriented programming = focus on cache performance and avoiding branching. Those are things that can come out of taking a data-oriented approach, but I don't think you need to go all the way to using bitmasks instead of conditional branching for your code to be "data-oriented". Data orientation to me just implies that your code is built around how your data is laid out and your data is laid out according to what you actually need to accomplish instead of trying to model the "real world" with abstractions in code.




#5206713 Encapsulation through anonymous namespaces

Posted by Oberon_Command on 26 January 2015 - 09:19 AM

 

 


I didn't know that your could forward declear a class like that in the header and leave both declaration and definition of it's body to the source file.. thought that would cause the compiler to throw a multiple declarations error.. cool!

 

That's actually necessary in some cases. Consider the following examples of circular references:

 

struct Foo{
    Bar* x; // error, Bar is not declared
};
 
struct Wololo;
struct Bar {
    Wololo* x; // no error, Wololo was forward declared
};
 
struct Wololo {
    Bar* x; // no error, we already declared Bar above
};

 

 

Yeah, I know about foward declaration, but I thought you had to re-decleare the struct or class in another header to not get "multiple declarations" exception when more than one file uses the class/struct.

 

 

Don't forget that "headers" are not really a thing from the perspective of the compiler. When you #include something, the compiler is essentially copy-pasting that file into the current translation unit. Even if you put the class definition in a single header that gets included in multiple files, the compiler sees you as defining the same class multiple times anyway. The "multiple declarations" error only comes into play if the class definition occurs twice in the same translation unit or if you try to define a global twice in two different files (because the compiler needs to set aside some memory for the global and needs to know which translation unit the global came from, unlike class definitions which take up no memory).




#5206656 Encapsulation through anonymous namespaces

Posted by Oberon_Command on 26 January 2015 - 12:41 AM


I didn't know that your could forward declear a class like that in the header and leave both declaration and definition of it's body to the source file.. thought that would cause the compiler to throw a multiple declarations error.. cool!

 

That's actually necessary in some cases. Consider the following examples of circular references:

 

struct Foo{
    Bar* x; // error, Bar is not declared
};
 
struct Wololo;
struct Bar {
    Wololo* x; // no error, Wololo was forward declared
};
 
struct Wololo {
    Bar* x; // no error, we already declared Bar above
};




#5206237 Encapsulation through anonymous namespaces

Posted by Oberon_Command on 23 January 2015 - 12:42 PM

 

Naming conventions aside, I think this is pretty much what Ravyne is talking about?

Any feedback on this approach?

 

That's pretty good, though (again to push the point I was getting at earlier) you could make it even more encapsulated, at the expense of some extra code:

 

// Public interface of texture manager (texture.h)
namespace TextureManager
{
    class Instance;
    void IAmAPartOfTheTextureManagerInterface(Instance& textureManager);
    void DoOtherThingWithTextureManager(Instance& textureManager);
}
 
// Implementation of public interface and definition of private interface (Texture.cpp)
namespace TextureManager
{
    class Instance
    {
        public:
            void ChangeTheStateOfThisInstance()
            {
                 ++_secretVariable;
             }
 
 
            void ChangeTheStateOfThisInstanceTwo()
            {
                 --_secretVariable;
             }
 
 
            void ChangeTheStateOfThisInstanceThree()
            {
                 _secretVariable *= _secretVariable;
             }
 
         private:
             int _secretVariable = 0;
    };
 
    void IAmAPartOfTheTextureManagerInterface(Instance textureManager)
    {
        textureManager.ChangeTheStateOfThisInstance();
        textureManager.ChangeTheStateOfThisInstanceTwo();
        textureManager.ChangeTheStateOfThisInstanceThree();
    }
 
    void DoOtherThingWithTextureManager(Instance& textureManager)
    {
        textureManager.ChangeTheStateOfThisInstanceTwo();
    }
}
 
// Usage (main.cpp)
int main()
{
    TextureManager::Instance textureManager;
 
    TextureManager::IAmAPartOfTheTextureManagerInterface(textureManager);
 
    // and/or
    // no longer doing this
    //textureManager.ChangeTheStateOfThisInstanceTwo();
    // instead do this
    DoOtherThingWithTextureManager(textureManager);
    ...
 
    return 0;
}

 

Now note that only texture.cpp knows the definition of the TextureManager. All anyone else knows about is the functions in that namespace you've provided.




#5206005 Encapsulation through anonymous namespaces

Posted by Oberon_Command on 22 January 2015 - 10:15 AM

Global (mutable) data is generally a bad idea, even if inside an anonymous namespace. This is because your functions then are depending on something that the user can't see, and which may change their behavior in unexpected ways - not to mention that the whole scheme breaks down entirely when threads are involved.

 

True, but the functions themselves are stateless. Free functions is not the same thing as global state. Sometimes it makes a lot of sense to have free functions that are associated with a class but do not belong to it. For instance, you could use free functions to promote encapsulation by doing what AlanSmithee suggested where free functions would be the public interface and the actual class would be a hidden implementation detail, similar to how C's FILE structure is used. 

 

Anonymous namespaces don't really contribute to that, though. As you say, they're more for fixing naming collisions.




#5204394 I am beginning to hate the IT and gaming industry.

Posted by Oberon_Command on 14 January 2015 - 09:48 PM

 

Oberon Command, your question totally derails the discussion on the OP's question. Please start a new thread, and reference this discussion if you need to.

I think Oberon intended it as a playful jab at the OP's continued insistence that only rockstar developers get hired.

Precisely, yes. If only rockstar developers get jobs, how did I and several of my university friends get jobs in the field before we'd graduated?

I think I probably got my present job as a junior dev by demonstrating passion for what I do in the form of side projects. In my experience bringing a demo, something concrete that you can actually play or use helps immensely. Of course, actually having skills and a demonstrable ability to learn on the job helps too... learning on the job is hardly impossible.

 

edit: terrible phone autoincorrect






PARTNERS