• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ATC

The Singleton Pattern: To be or not to be [used]?

80 posts in this topic

[quote name='Caburé' timestamp='1352475204' post='4999314']
That was a rethorical question, I already knew how to create a static class in Java.[/quote]
He's not talking about a static class, he's talking about a normal class. Static data comes with many of its own pitfalls, even when that static data isn't truly global.
1

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1352475841' post='4999320']
[quote name='Caburé' timestamp='1352475204' post='4999314']
That was a rethorical question, I already knew how to create a static class in Java.[/quote]
He's not talking about a static class, he's talking about a normal class. Static data comes with many of its own pitfalls, even when that static data isn't truly global.
[/quote]

(I mean Java)

if I put a

public static final int x = 1;

in any normal class, that class is both global and static: is immutable because must hold the final value in at least one of its fields.. even without having static fields, in Java.

Every class in Java is static. Not every instance.
0

Share this post


Link to post
Share on other sites
[quote name='Caburé' timestamp='1352475204' post='4999314']
That was a rethorical question, I already knew how to create a static class in Java.
[/quote]

[img]http://public.gamedev.net//public/style_emoticons/default/dry.png[/img] who said anything about static classes?
My entire point is to avoid static stuff actually :P . What I meant was, what do you use to store your precomputed values? A standard class, plain and simple.
0

Share this post


Link to post
Share on other sites
[quote name='kunos' timestamp='1352476121' post='4999325']
[quote name='Caburé' timestamp='1352475204' post='4999314']
That was a rethorical question, I already knew how to create a static class in Java.
[/quote]

[img]http://public.gamedev.net//public/style_emoticons/default/dry.png[/img] who said anything about static classes?
My entire point is to avoid static stuff actually [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] . What I meant was, what do you use to store your precomputed values? A standard class, plain and simple.
[/quote]

Yes, you are right.
0

Share this post


Link to post
Share on other sites
[quote name='Dave' timestamp='1352502330' post='4999480']
Writing tight OOP code in studios where iteration time is important and year on year you're rewriting large portions of code is common because of new platforms and new titles is a complete waste of time and it is important that you make simple architectural decisions that:
[/quote]

Except every time I hear the 'new code because of new platforms' arguement is I can't help but think it is garbage.

Consoles have been stable for many years now and it's only recently that a nod towards the new ones has happened. We've had ~7 years of stability in that domain.
Windows is an even bigger pile of fun as DX9 was stable for the better part of a decade and again it is only in the last few years that DX11 has become 'a thing'.
Other platforms come along at a much lower frequency and, with correct abstraction, are not a case of 'rewrite large portions of code' but rework layers which are needed to get them up and running.

I would argue that by NOT taking time to design things properly up front people are wasting more time with rewrites and rebuilds of systems which don't need it. The 'get it done' mindset has its uses but hacking on things is not, in itself, a good way to go unless you want to waste time over the course of years rebuilding the problem.

[quote]
a) Allow new programmers to get on with things easily.
b) Make it easy to add features to.
[/quote]

Except none of this is an arguement against designing things properly nor, more importantly when it comes to this thread, is it an arguement in favour of singletons which, in my experiance, have only served to cause more harm than good.

A correctly designed system can allow for BOTH of those things IFF it is correctly designed.
And by that I don't mean the classic 'just out of university' OOP method of 'zomg! classes for everyone!' but a sensible division of code and responcibility. People get too hung up on 'OOP = class' and lose track of the real meaning of the design methodology. More to the point they focus purely on 'put everything in a class and give it methods' than correctly splitting things up into classes, structures and free functions as required and, more importantly, ignore data flows and how information needs to move around the system.

In short; most people in the world write utterly shit OOP but that doesn't mean it isn't useful to design larger subsystems for it.

[quote]
It is argued that you can screw things up if you start touching global variables that you shouldn't. If you hire programmers with an ounce of common sense they generally won't do that and no matter what "barriers" you put in place to protect programmers from themselves, if a shortcut is really desired then it will be found. The [i]friend[/i] keyword comes out in no time.
[/quote]

The problem is that most people AREN'T good enough to not make mistakes and do it wrong.
I have seen some wonderful things where people fresh out of university have commited crimes against code so bad it makes me wonder why they are allowed to even write code in the first place. (My favorite being the guy who decided to, in his branch without telling anyone, change the interface to our lua subsystem from function(luaObject, ....) syntax to luaObject->function(....) syntax while at the same time weaving his work around the changes. It took me 4 HOURS to get his code back into mainline for a merge and I no longer trust fresh faced programmers not to fuck up in some massive manner)

So, yes, people make mistakes and yes there are ways to hack around the 'protection' BUT with a properly designed system the immediate solution is often cleaner, easier to maintain and, more importantly, does NOT lead them down the path of thinking 'hey, others have done it so it's probably ok for me to do so...' because they learn by example.

Truth of the matter is that most people in the industry can't design for crap - unfortunately if we tried to staff an industry with people who were good at it we'd soon run out of people so in order to save time later its best to discourage bad code to start with.

And to that end... a story!

In our engine we were lacking a sane method of the game team to transfer values from the logic thread to the renderer thread (and thus the GPU).
We took a day to hash out WHAT we wanted the system to do (I'll spare you the details, because frankly they are a tad confusing at times), roughly how we wanted it to interact and then I got cracking on the design and implementation details.
The two senior members of the team feedback into the process every few days as we discussed things and by the end of a two month period we had a working solution (with some of the most complicated multi-pass binding/patch table setup code I've written in my life BUT...) which was created when the renderer started up and cleanly passed, by reference, to the subsystems which required it.

However we weren't finished there because the aim for this system was to replace ALL the variables which could be passed to shaders; this included built in tokens for things like shadow map textures as well as the post-processing system's frame buffer textures and variables.

The 'global texture cache' (as I believe it was called) had been written partly by a senior and finished off by a junior. Frankly the code was overly complex for what it did BUT more importantly it had been implemented as a global system and because of this it had inflitrated multiple levels of code with no clarity as to the flow. It took LONGER for me to remove the old code and clean up the mess it had made than it took me to write the addition to the Parameter System which had been written; Clean OO intergration 1 v Global Code 0.
(The new system also expanded the abilities of the GTC functionality bring it in line with the general parameters affording the game team more control).

Post Processing was the same story; the functionality added to the Parameter System took maybe 2 days to add with no major interface changes aside from some special casing due to the stupid way the Post Processing was implemented.

Finally a few months back we needed a feature adding to the Parameter System at the request of the game team. The conversation as to if I should even add the feature took LONGER than the time it took me to write the feature, integrate it, test it and push it into the publish queue, the system was that extendable.

The system itself was built on both OOD and DOD principles to use classes when it made sense and pay attention to the data when it didn't.
The system was written in Jan/Feb of this year with a couple of weeks in March to integrate the extra functionality and remove the old.

This system is a lynch pin in the game F1 All Stars which is coming out soon; if it breaks then we lose logic->renderer data flow so it's one of the most critical systems in the whole engine right now.

The system has had ZERO time spent on bug fixing; not a single bug has been filed against it and when suspicion has been cast it has been easy to prove (despite the mad binding code which while it looks complex does work flawlessly) it wasn't a problem.

Now, we could have hacked together a system in a month, thrown it in as a global and watched as everyone abused it and dealt with bugs left, right and centre BUT instead we decided to do it right and because of that the integration is clean, the code is robust and its freed me up to work on other bits of genius instead.
2

Share this post


Link to post
Share on other sites
[quote name='larspensjo' timestamp='1352464987' post='4999261']
[quote name='Khatharr' timestamp='1352453741' post='4999196']
I'm probably gonna get creamed for saying this, but I usually use namespaces for systems that I only want one of.
[/quote]
I hope you won't get, or people will eventually get afraid asking things.

I am not sure I understand how the use of namespaces limits the number of instances to a maximum of 1.[/quote]

Because you can only have one namespace with the same name per program.
0

Share this post


Link to post
Share on other sites
[quote name='Khatharr' timestamp='1352519216' post='4999527']
[quote name='larspensjo' timestamp='1352464987' post='4999261']
[quote name='Khatharr' timestamp='1352453741' post='4999196']
I'm probably gonna get creamed for saying this, but I usually use namespaces for systems that I only want one of.
[/quote]
I hope you won't get, or people will eventually get afraid asking things.

I am not sure I understand how the use of namespaces limits the number of instances to a maximum of 1.[/quote]

Because you can only have one namespace with the same name per program.
[/quote]

Which does nothing to enforce that a type defined within that namespace cannot be instantiated multiple times:

[code]
namespace N {
struct C {
int someMemberVariable;

void someMemberFunction ();
};
}

int main () {
C c1;
C c2;
}

// ...
[/code]

The only way you could really guarantee uniqueness out of this is to do something like:

[code]
namespace N {
namespace C {
extern int someQuoteMemberQuoteVariable;

void someQuoteMemberUnquoteFunction ();
}
}
[/code]

Is that what you mean?

That transform C from an aggregate type into a namespace containing free functions (and freestanding global "members" which presumably in a real implementation you'd not actually expose in such a fashion).

That means you have only a single thing that "C" represents, but it's no different from classical procedural programming there, and subject to the same pros and cons. Much of the C runtime library functions that maintain state -- like rand() -- are essentially an implementation of this technique sans the namespace (which just provides a name scope and some organizational stability), and have many of the same problems a singleton can. Edited by Josh Petrie
0

Share this post


Link to post
Share on other sites
If you take Khatharr's statement, and think, "[i]how can namespaces be used to provide single global systems[/i]", then there's lots of ways you can answer that question, rather than thinking of ways in which it's a nonsense statement. e.g.
[code]namespace MySystem
{
extern int someGlobalValueModifyWithCare;
void SomeGlobalProcedureWithHiddenSideEffects();
float GetSomeHiddenGlobalState();
}[/code]^^That's basically a singleton, without putting any of the implementation details regarding the singleton into your public interface. Edited by Hodgman
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1352524703' post='4999551']
If you take Khatharr's statement, and think, "[i]how can namespaces be used to provide single global systems[/i]", then there's lots of ways you can answer that question, rather than thinking of ways in which it's a nonsense statement. e.g.
[code]namespace MySystem
{
extern int someGlobalValueModifyWithCare;
void SomeGlobalProcedureWithHiddenSideEffects();
float GetSomeHiddenGlobalState();
}[/code]^^That's basically a singleton, without putting any of the implementation details regarding the singleton into your public interface.
[/quote]

That's basically what I mean. I'm not talking about nested types in a namespace. That would just be an extrapolation of a type in the global space.

I have a header that declares the public interface as a namespace and then the private "members" are statics within the code file that implements the namespace. Edited by Khatharr
0

Share this post


Link to post
Share on other sites
[quote name='Khatharr' timestamp='1352525338' post='4999552']
That's basically what I mean. I'm not talking about nested types in a namespace. That would just be an extrapolation of a type in the global space.

I have a header that declares the public interface as a namespace and then the private "members" are statics within the code file that implements the namespace.
[/quote]
The singleton pattern is meant to be used for types that are global. Your solution can be a good one, if you simply don't make the type global. It is a solution you can frequently see with "opaque data types".
0

Share this post


Link to post
Share on other sites
[quote name='larspensjo' timestamp='1352530557' post='4999568']
Your solution can be a good one, if you simply don't make the type global. It is a solution you can frequently see with "opaque data types".[/quote]Indeed, any global system can also be implemented as a non-global, e.g. for the above system:[code]namespace MyOtherSystem
{
struct System { int somePublicValueModifyWithCare; };
System* Create();
void Destroy(System*);
void SomeProcedureWithHiddenSideEffects(System*);
float GetSomeHiddenState(System*);
}[/code]And then if the user wants to, they can create a global instance of it, or a wrapper API that makes it look global ([i]e.g. the namespace MySystem from my last post could be wrapper around this one[/i]). This way your code is clean and reusable, but the application author still has the choice of being lazy with globals if they want to.

I've worked on a few engines that used templates that allowed you to use any type as a singleton -- e.g. [font=courier new,courier,monospace]Singleton<FooSystem>::Get()[/font] would return a shared global instance of a [font=courier new,courier,monospace]FooSystem[/font] object.
This wasn't a "true" singleton, because [font=courier new,courier,monospace]FooSystem[/font] would be written in such a way where it would work with many instances -- however, if a game only needed/wanted 1 global instance, they could use this singleton template to ask for one ([i]and every part of the game code using the template would get the same, single, shared instance[/i]).
If you're going to use globals, then IMHO that's a good way to design things -- keep the code sensible and allow the user to make use of it in whatever way they want ([i]that's reusability, right?[/i]). Edited by Hodgman
0

Share this post


Link to post
Share on other sites
[quote name='Dave' timestamp='1352502330' post='4999480']
I don't see that singletons or globals are particularly bad. I've worked on commercial games where singletons and globals have been used. One used them wisely and was the easiest codebase that i've ever worked on and one used it badly and it was extremely complicated and hard to ramp up on.
[/quote]

in a way, globals are always "easier" to use, because you don't have to deal with the problems of "how do I get to this data from here? Do I really need more stuff passed into my constructor so I can get in there? Can I solve it differently? Can I make my class more independent " .. these questions are all GOOD questions that promote better quality code, but they are hitting your instantaneous productivity because they have a big impact on the entire software. If you want to add occlusions to your audio subsystem you'll have to pass in an interface to raycast into the scene.. this might have HUGE impacts on the way the system is built and constructed... and the lazy solution of "ok let's make the RayCastProvider a global singleton" is a quick fix, but it's not really a solution to the problem isnt it?
Having said that, good programmers will make pretty much everything work.. software has been made in asm and C for ages.
But any decent programmer should agree that locality is a good thing because it avoids unwanted or unexpected side effect.. so, if you don't have to ship your software TONIGHT and it's 10pm, there is always a better solution other than making everything global.
0

Share this post


Link to post
Share on other sites
[quote name='phantom' timestamp='1352509331' post='4999500']
[quote name='Dave' timestamp='1352502330' post='4999480']
Writing tight OOP code in studios where iteration time is important and year on year you're rewriting large portions of code is common because of new platforms and new titles is a complete waste of time and it is important that you make simple architectural decisions that:
[/quote]

Except every time I hear the 'new code because of new platforms' arguement is I can't help but think it is garbage.

Consoles have been stable for many years now and it's only recently that a nod towards the new ones has happened. We've had ~7 years of stability in that domain.
Windows is an even bigger pile of fun as DX9 was stable for the better part of a decade and again it is only in the last few years that DX11 has become 'a thing'.
Other platforms come along at a much lower frequency and, with correct abstraction, are not a case of 'rewrite large portions of code' but rework layers which are needed to get them up and running.

I would argue that by NOT taking time to design things properly up front people are wasting more time with rewrites and rebuilds of systems which don't need it. The 'get it done' mindset has its uses but hacking on things is not, in itself, a good way to go unless you want to waste time over the course of years rebuilding the problem.

[quote]
a) Allow new programmers to get on with things easily.
b) Make it easy to add features to.
[/quote]

Except none of this is an arguement against designing things properly nor, more importantly when it comes to this thread, is it an arguement in favour of singletons which, in my experiance, have only served to cause more harm than good.

A correctly designed system can allow for BOTH of those things IFF it is correctly designed.
And by that I don't mean the classic 'just out of university' OOP method of 'zomg! classes for everyone!' but a sensible division of code and responcibility. People get too hung up on 'OOP = class' and lose track of the real meaning of the design methodology. More to the point they focus purely on 'put everything in a class and give it methods' than correctly splitting things up into classes, structures and free functions as required and, more importantly, ignore data flows and how information needs to move around the system.

In short; most people in the world write utterly shit OOP but that doesn't mean it isn't useful to design larger subsystems for it.

[quote]
It is argued that you can screw things up if you start touching global variables that you shouldn't. If you hire programmers with an ounce of common sense they generally won't do that and no matter what "barriers" you put in place to protect programmers from themselves, if a shortcut is really desired then it will be found. The [i]friend[/i] keyword comes out in no time.
[/quote]

The problem is that most people AREN'T good enough to not make mistakes and do it wrong.
I have seen some wonderful things where people fresh out of university have commited crimes against code so bad it makes me wonder why they are allowed to even write code in the first place. (My favorite being the guy who decided to, in his branch without telling anyone, change the interface to our lua subsystem from function(luaObject, ....) syntax to luaObject->function(....) syntax while at the same time weaving his work around the changes. It took me 4 HOURS to get his code back into mainline for a merge and I no longer trust fresh faced programmers not to fuck up in some massive manner)

So, yes, people make mistakes and yes there are ways to hack around the 'protection' BUT with a properly designed system the immediate solution is often cleaner, easier to maintain and, more importantly, does NOT lead them down the path of thinking 'hey, others have done it so it's probably ok for me to do so...' because they learn by example.

Truth of the matter is that most people in the industry can't design for crap - unfortunately if we tried to staff an industry with people who were good at it we'd soon run out of people so in order to save time later its best to discourage bad code to start with.

And to that end... a story!

In our engine we were lacking a sane method of the game team to transfer values from the logic thread to the renderer thread (and thus the GPU).
We took a day to hash out WHAT we wanted the system to do (I'll spare you the details, because frankly they are a tad confusing at times), roughly how we wanted it to interact and then I got cracking on the design and implementation details.
The two senior members of the team feedback into the process every few days as we discussed things and by the end of a two month period we had a working solution (with some of the most complicated multi-pass binding/patch table setup code I've written in my life BUT...) which was created when the renderer started up and cleanly passed, by reference, to the subsystems which required it.

However we weren't finished there because the aim for this system was to replace ALL the variables which could be passed to shaders; this included built in tokens for things like shadow map textures as well as the post-processing system's frame buffer textures and variables.

The 'global texture cache' (as I believe it was called) had been written partly by a senior and finished off by a junior. Frankly the code was overly complex for what it did BUT more importantly it had been implemented as a global system and because of this it had inflitrated multiple levels of code with no clarity as to the flow. It took LONGER for me to remove the old code and clean up the mess it had made than it took me to write the addition to the Parameter System which had been written; Clean OO intergration 1 v Global Code 0.
(The new system also expanded the abilities of the GTC functionality bring it in line with the general parameters affording the game team more control).

Post Processing was the same story; the functionality added to the Parameter System took maybe 2 days to add with no major interface changes aside from some special casing due to the stupid way the Post Processing was implemented.

Finally a few months back we needed a feature adding to the Parameter System at the request of the game team. The conversation as to if I should even add the feature took LONGER than the time it took me to write the feature, integrate it, test it and push it into the publish queue, the system was that extendable.

The system itself was built on both OOD and DOD principles to use classes when it made sense and pay attention to the data when it didn't.
The system was written in Jan/Feb of this year with a couple of weeks in March to integrate the extra functionality and remove the old.

This system is a lynch pin in the game F1 All Stars which is coming out soon; if it breaks then we lose logic->renderer data flow so it's one of the most critical systems in the whole engine right now.

The system has had ZERO time spent on bug fixing; not a single bug has been filed against it and when suspicion has been cast it has been easy to prove (despite the mad binding code which while it looks complex does work flawlessly) it wasn't a problem.

Now, we could have hacked together a system in a month, thrown it in as a global and watched as everyone abused it and dealt with bugs left, right and centre BUT instead we decided to do it right and because of that the integration is clean, the code is robust and its freed me up to work on other bits of genius instead.
[/quote]

Appreciate the detailed reply.

You're right, people in the games industry can't design code, generally, but more importantly they don't. There is good reason for this. If you're writing software that gets men to the moon then:

- Get the best programmers available.
- Define a rock solid coding standard.
- Design every last operation detail of the code before writing a single line.
- Code review, code review, code review.

Unfortunately very often none of these rules apply in the games industry. The only time i've ever seen code designed to any kind of level in the industry was when a new boss of mine tried to enforce it but ended up having to drop it. There simply isn't time in the games industry because:

- You're usually working through shorter development iterations.
- Management and investors these days want to see progress on your project more frequently than they used to. (related to the above)
- Your title is out in a year and no time can be afford to be "wasted" on writing design documentation that, as soon as the game hits the shelf, is irrelevant.

I will say, however, that designing code and having good OOP has its merits. I'm not trying to say that noone in the world should be writing OOP, but in the games industry and to be honest, even more importantly for the hobbyist, don't waste all your time wondering how to add something to your perfectly architected system.

The more time you spend working out how the hell you're going to integrate physics into your engine the more time you're not spending integrating physics into your engine. You have to find a good balance between writing a codebase that will be productive to work on and also decently written and unfortunately for C++ and OOP allow you to code yourself into a corner too often.

I'm not disagreeing with you here, i understand the necessity of OOP in software engineering. I'm just not convinced the games industry is a suitable domain for it. I've been full circle with writing game engines in my personal time and my current one is my most productive. Gradually i'm migrating it over to plain C with a few C++ niceties like templates here and there.
0

Share this post


Link to post
Share on other sites
Hey, I was about to go to bed and my subconscious kicked up something from years back, so I jumped back on the comp, lol.

Are you Lars Pensjo as in Mr. LPMUD Lars Pensjo? If so that's awesome. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
1

Share this post


Link to post
Share on other sites
[quote name='Khatharr' timestamp='1352545273' post='4999613']
Are you Lars Pensjo as in Mr. LPMUD Lars Pensjo?
[/quote]
That was old adventures. I got bored working as a SW project manager, so I had to go back to games business and have some fun.
1

Share this post


Link to post
Share on other sites
These are some things that I've been mulling over myself as I learn more and more about 'proper' coding. I can definitely see the benefits of all the rules and customs developed over the years, but it also strikes me that these things should be measured carefully. If I'm going to write something that needs to last for years to come then I had darn well better "do it right" because in the long run the amount of time saved will be enormous, but on the other hand I see things like "don't use C style things in C++" and in many cases I find myself asking "why the hell not?". It strikes me that rules or customs should be measured based on their effectiveness for the task at hand. In many (even most) cases there's good reasons, but sometimes an array is just a gorram array and using a vector is a waste of time both for the developer and for the CPU at runtime. If I need STL container functionality later it's not difficult to add.

A somewhat related issue, since you mentioned cowboy'ing, if I'm going to write something complex I'll usually sit down and bash it out as quickly as possible and then once its in place I can spot all the structural problems and go back over it (immediately) and write a stable system with all the bells and whistles. I don't want to get stuck spending extra hours writing something that's going to get scrapped or re-written anyway because a better design idea occurred or a structural problem emerged while the code was being written.

I guess what I mean is that I support the K.I.S.S. rule above all others. If something looks and feels complicated then I can't shake the feeling that I'm doing it wrong. I don't understand making something more complex than it needs to be, especially since it seems like complexity is easy to add and hard to remove. Sometimes I feel like the rules and culture are almost a language in and of themselves. It's like C extends to C++ and then C++ extends to 'proper' C++. I've seen criticism about using C++ as if it were C, but the fact is that vanilla C is an effective language as well. In terms of readability C-style is great, but I also find that it seems like the program likes it as well, if that makes any sense. Simple code just usually seems to run better. Algorithms, for instance. I ws looking into algorithms while familiarizing myself with the musty corners of STL and I saw that I could have used an algorithm in place of a loop for iterating through the values in a container and modifying them. Then, by chance, I looked at the code of the appropriate algorithm and saw that it was more or less exactly what I had already written. So all I would gain by implementing the loop with the algorithm is some excess stack framing. On the other hand, there are some situations where algorithms are more or less '****ing rad', to use the technical term, and in those places I gladly use them.

I don't really know where I'm going with this rambling. Like I said, it's just something that's been on my mind. Glad to see other people thinking about it as well. Edited by Khatharr
0

Share this post


Link to post
Share on other sites
[quote]It strikes me that rules or customs should be measured based on their effectiveness for the task at hand.[/quote]

**They are.**

"Don't use C style things in C++" is one of those things that has been done and found to cause issues due to odd interactions in the mixed codebase. It's one thing to question things, but many of these best practices are best practices for just this reason.
0

Share this post


Link to post
Share on other sites
Probably the biggest issue with doing things the C way in C++ code is that C++ has exceptions. Some perfectly good C code compiled by a C++ compiler can become unsafe because all of the sudden you can't be sure that call to foo() won't unwind the stack on you (and even if it can't throw an exception now that doesn't mean someone won't change things later). Hence the recommendation to use things like RAII types. Following closely on that is the fact that many of those straight forward C style techniques are actually less secure than the C++ style equivalents.
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0