ChaosEngineMember Since 09 Jun 2000
Offline Last Active Yesterday, 07:25 PM
- Group Crossbones+
- Active Posts 2,628
- Profile Views 12,136
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posted by ChaosEngine on 18 July 2016 - 09:40 PM
Posted by ChaosEngine on 10 July 2016 - 10:54 PM
I have the luxury and flexibility to do what I want and try to challenge conventional thinking. In so doing I've discovered pros and cons for going against the norm as well, and i will take the route of least resistance (wether it is a conventional approach, or something to the contrary).
Nothing wrong with that. Just be aware that there are often very good reasons for conventions. They frequently encode a lot of lessons learned the hard way.
By all means, challenge them, but do so understanding why they are conventions in the first place.
For me personally (and in my own subjectivity), I've found working within the confines of the C++ and OOP in general to be quite problematic.
And on the flip side to what I just said... no-one is forcing you to write C++ in an OOP manner.
If you're writing something and you think it should be a free function/struct/other "non OO" construct, write it as such.
It is one of the strengths of the language that it doesn't force you into OOP, unlike Java or C#. (I love C#, but I find it stupid that I have to create a static class to write a simple function).
Posted by ChaosEngine on 20 June 2016 - 03:40 PM
What does your debugger tell you? Not the output, the actual debugger. Step through the program until you get to the line that is causing the problem.
Look at your data.
Posted by ChaosEngine on 15 June 2016 - 10:02 PM
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.
Posted by ChaosEngine on 15 June 2016 - 06:16 AM
...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.
Posted by ChaosEngine on 09 June 2016 - 05:46 PM
i'm interested why microsoft in MFC uses C prefix, if it not correct for CPP?
MFC is a not a good example to follow when writing C++.
Aside from the actual design of the library, the coding conventions used are mostly considered bad style these days.
Posted by ChaosEngine on 09 June 2016 - 04:27 AM
justify why minus in reputation?
Because every time you whinge about your reputation, you get downvoted. It's practically tradition.
Lowercase, in some cases make code unreadeable
Once again, you need to learn the difference between your subjective opinion and an objective fact.
in C# uppercase letter is part of official code style
Yes, in C# uppercase is part of the language coding conventions, but this thread is about C++, not C#.
Posted by ChaosEngine on 07 June 2016 - 03:10 PM
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.
Posted by ChaosEngine on 06 June 2016 - 03:18 PM
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.
Posted by ChaosEngine on 06 June 2016 - 06:45 AM
as opposed to Actor actor?
I used to Put C for class, reason was so I could use the actual name of the class as the variable name.
Like CActor Actor; //works for me
Posted by ChaosEngine on 30 May 2016 - 09:01 PM
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?
Do a rebuild etc.
Posted by ChaosEngine on 29 May 2016 - 02:46 PM
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.
The idea has mostly fallen out of favour these days, but that's where it came from.
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; Row x; Column y; x = y; // error, requires cast of some sort
Posted by ChaosEngine on 26 May 2016 - 05:14 PM
Note that the original "hungarian notation" is actually recommending that you write variable names like m_xPosition vs m_yPosition
Am I going blind, what's the difference there?
That's probably not a great example from Hodgman.
Imagine you have two coordinate systems, screen coordinates and world coordinates.
It wouldn't make sense to do something like
someScreenCoordinate = someWorldCoordinate
even if they are the same type.
So the original hungarian notation proposed prefixing them with a "subsystem", so you would end up with
scrnCoord = wrldCoord
The idea was to make this look wrong. So when you were reading the code, you would see this and go "damn, that should be"
scrnCoord = WorldToScreen(wrldCoord)
The same idea would apply in a business app for example, if you had a fee that could be expressed as an absolute value or a percentage. Code like
amount *= valFee // should be amount *= rteFee
The idea has mostly fallen out of favour these days, but that's where it came from.
Posted by ChaosEngine on 26 May 2016 - 05:02 PM
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.
Posted by ChaosEngine on 26 May 2016 - 04:45 PM
Oracle has been suing Google for use of it's Java APIs in Android (looking for something like $9bn!).
Well, they just lost.
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.