I would go for roughly the second option - define a common interface in a header file, but instead of having #ifdefs sprinkled throughout the implementation, consider having separate .cpp files for each platform. So you might have memory.h, memory_win32.cpp, memory_linux.cpp, memory_x360.cpp, etc. Your compiler toolchain(s) should allow you to make some files compile in some configurations but not in others.
This. and possibly also a memory_common.cpp for platform-agnostic code.
...it's use case is obviously for data that needs to be globally accessed, but is NOT expected to mutate much at runtime.
That is NOT what a Singleton is. The Singleton pattern is about insuring there is only ONE instance of an object in a given code space (project/application/library/whatever).
That's it. The pattern has NOTHING to do with global access or mutability of state.
The problem is that idiot programmers see a singleton and think "oh, this is the OO way of doing globals", when that's not the intent of the pattern at all.
Global mutable state is bad (the reasons should be pretty obvious by now).
But singletons are bad in a completely orthogonal way, because they enforce a completely unnecessary restriction. If you only want one object, just create one bloody object!
If you need a global object (mutable or otherwise), first ask yourself if you REALLY need a global object. If you're satisfied that you do, then take responsibility for that decision and don't pretend it's somehow better because it's a singleton.
At least then in the future, when you realise that thing that you knew there would only be one of turns out to require more than one of, you haven't shot yourself in the foot.
Interesting, can't say I've ever worked at that level, most people I've worked with is 10. Half of them were UI/UE designers.
That's ok. Most people don't work on that kind of project. It's typically for a really large desktop or enterprise application.
Most software is written at an SME level.
To answer your question, I suppose it's simply something I'm most comfortable at of doing and knowing low level of things. i.e I would much rather build the server software that runs the website and dealing with worker threads, logging, and learning the HTTP protocol extensively then actually putting together the PHP and HTML that shows up.
Those kinds of jobs are relatively rare. To take your specific example, you're talking about writing a web server. There are basically only a few web servers that people use: Apache, nginx and IIS are most of the market. It's not easy to get a job working on them.
Of course, if you mean writing web applications that run on a server then....
I'm definitely noticing that where I live with all the .NET positions cropping up. Perhaps I'm stubborn, and should just pick up a few books on .NET and deal with the current market to adapt. Not to start any flame wars, or no offense to any die hard fans, I just found .NET a very limited platform, which is why I don't bother with it and I do see why companies use it. Something breaks then there is someone else to yell at. ;)
.Net is actually a really good platform for the kinds of work you describe, and C# is a very nice language that's getting better with every version (IMO).
In all honesty, I'm looking for something rewarding in the long run. (health insurance, retirement, salary). Just something a little more stable, where I work I get no benefits, just pay by the hour. Got a few people telling me they get 40k a year and work 50-60 odd hours a week in the game dev world, seems a lot of stress for nothing.
Then stick with web programming. Try to get onto bigger teams. In a few years, see if you can lead the team, maybe even manage the project. Eventually, ditch coding altogether and move into management. If you want rewards and stability, that is the way to go.
Hate to say it, but I'm kinda leaning towards the self start up idea of opening a online marketing business that will evolve into other areas. Definitely will need a bit of time and money, before that can get rolling. Of course one thing at a time. ;) You can't be a "astronaut, doctor, and president at the same time".
As long as you're aware that you're getting into one of the most cut-throat, competitive industries out there. Online marketing, SEO, etc is a dog-eat-dog world.
If you can succeed at it, more power to you, but if stability matters to you, stay away from it.
Your distinction between developer and engineer doesn't really exist in the real world. What you're describing is basically the difference between junior and senior positions.
There's no industry standard, but titles are generally along the lines of
junior developer: simple tasks, minimal decision making. Basically, you're there to learn.
developer: more complex tasks, some decision making.
senior developer: most complex tasks, some high-level design work
technical lead: responsible for the technical direction of the project, chooses technologies (frameworks, engines, etc) for the rest of the devs.
architect: doesn't do much (if any) programming. purely responsible for the high level design of the project.
Those are VERY broad strokes and highly dependent on the size and nature of the company and the project you're working on. A small project might have one person covering all of those roles, whereas a massive project will have teams of people at each level for various components/subsystems.
Anyway, why do you want to be a C++ programmer? Do you have a specific end goal in mind (e.g. games, high-performance computing, etc)?
This might be kind of a big question, but have a think about what you want out of your career (and by extension, your life). In terms of money, you can do just as well (probably better) as a competent web developer. If you want to do game dev, then C++ is pretty much required for the big AAA studios, but understand that it often comes with less pay for more hours.
Moving code into a lib shouldn't affect your virtual functions at all. Try setting a breakpoint right before your Draw function gets called, and step into the call to see what happens / where it goes (in visual studio, F9 to set a breakpoint, F10 for "step over", F11 for "step into").
Right before, fine it hits it. Break point inside the Draw function misses.
Have a look at the object you're calling Draw on (use a watch window). Is it the type of object you expect?
Step into the draw function (F11), which function does it call?
Finally, check your compiler/project settings. Are you sure that your code in the lib is being called?
The idea has mostly fallen out of favour these days, but that's where it came from.
I'd say that the idea is pretty much just common sense and gets used everywhere. Except instead of as abbreviated prefixes, people use all sorts of forms of it, e.g. scrnCoordSomething
Sorry yes, I meant the abbreviated prefixes rather than the concept as a whole.
I think ideally, as SeanMiddleditch pointed out, we have strong typedefs so you couldn't do
typedef int Row;
typedef int Column;
x = y; // error, requires cast of some sort
1) Prefix class names with 'C'
2) Type 'C' in an IDE with code completion
3) Regret 1 as your code completion list fills up with a billion unrelated class names
5) End up being found 2 weeks later, living in a cave as far from the coast as possible ranting about the ocean coming to get you...
The same applies to "m_", "g_", "lpsz" and similar wretched nonsense.
If you're using "m_" for members, then it should only bring up member variables that are in scope (i.e. in whatever class you're editing). It's really no different than using "this->", but less error prone and an easy way to distinguish members from parameters.
If you have fifty squillion members in a class, you're doing it wrong.
Same goes for "g_". I'm with Promit in that globals should be ugly and stick out like a sore thumb.
But agreed using lpsz or whatever is beyond pointless.
So, on one hand, this seems like a victory for common sense (also Oracle are just the worst).
But I'm not sure I completely agree with Googles argument of "it's just the API". Leaving aside the question of copyrighted code (let's just accept that regardless of your personal opinions on the subject, we live in a world where code can and is copyrighted), I think a well-designed API is actually a big part of writing any software project/library.
Even if it's just (in C++ parlance) the "headers", that still represents a significant amount of work. I know that I spend a lot of time thinking about my APIs and how they fit together.
In fact, now that I think about it, I would say I almost spend more time designing the API than I do writing the implementation.
Interested to hear other peoples thoughts on the subject.
Based on your question, I think you should step back and evaluate your ability to complete this project.
Honestly, you are building a space shuttle and you've just asked about spray painting the NASA logo on the side.
The OP is (according to their profile) thirteen. Personally, for that age group I find it advisable to just give them the information desired and let the empirical values of something deceptively simple-sounding become a huge problem be a first-hand experience. We get a lot of older people who really should have learned that lesson earlier.
It's not even wasted time (especially at that age). You will be gaining skill points all over the place while working on it even with the originally intended goal not achievable.
I disagree. When I was that age, I was constantly trying to build things way beyond my ability, and similarly, I would focus on the "fun stuff", because the actual work frustrated me.
This was before the internet, so I didn't really have any help other than whatever books I could find. So I basically gave up in frustration, and didn't get back to programming until years later.
I really wish someone would have said to me "look, try something more manageable".