I am trying to write a helper function that will be used across several classes. In c#, I would create a static class, allowing me to access the function(s) from anywhere, usually across multiple unrelated classes. In c++, I know I can do the same thing, but I am wondering if it would be better to just create a pure c file and do the function there. I would put it in a separate file, but it would not be contained in a class. Would I create the file as a cpp and just not declare a class (but still use a header to avoid including the whole cpp file)?
The function in question is one to compile shaders, with different classes asking for different shaders, but my question applies in general.
C helper functions in c++
C++ is a multi paradigm language. You don't have to make everything OOP, and you don't have to use OOP at all. If it makes sense to you to have a library of loose functions, go for it!
In other languages, it can be a pain in the ass to shoehorn things into an OOP design when it's not needed. You don't have that problem in C++.
In other languages, it can be a pain in the ass to shoehorn things into an OOP design when it's not needed. You don't have that problem in C++.
Author
Is there a "right way"? Like if I were asked this at a job interview, what should I say?
I do enjoy the flexibility of c++, but I'm still getting used to all the power and technicality.
Edit: The right answer probably starts with "C++ is a very flexible language..."
I do enjoy the flexibility of c++, but I'm still getting used to all the power and technicality.
Edit: The right answer probably starts with "C++ is a very flexible language..."
Yes, the right way is whatever makes sense for you and your project. You don't design a multi-paradigm language, and then say that any method that isn't the OOP one is the wrong way to go about something. 
Even in C++ itself, most of the standard library is a bunch of loose global functions.
As for a job interview. That would be a pretty useless question to ask. It's like asking what color of t-shirt is the right one to wear on Thursday? Stupid question with no right answer.
Even in C++ itself, most of the standard library is a bunch of loose global functions.
As for a job interview. That would be a pretty useless question to ask. It's like asking what color of t-shirt is the right one to wear on Thursday? Stupid question with no right answer.
Author
You don't design a multi-paradigm language, and then say that any method that isn't the OOP one is the wrong way to go about something.
It's sad how much this exact mindset is pushed in school. After all the time I've spent trying to understand and use OOP, I've started to hate it. A part of me wants to join Torvalds and use pure C for everything.
OOP is easy to understand, and a great way to program. It has it's pros and cons, just like any other programming method.
Try reading the free ebook "Thinking in C++". It will explain objects to you.
Try reading the free ebook "Thinking in C++". It will explain objects to you.
Is there a "right way"? Like if I were asked this at a job interview, what should I say?
The right answer requires more context i would say.
If i have a bunch of related static functions that do not have any reason for a class then i do something like this (exceptions excepted):
namespace SomethingRelevant {
void something1(...);
void something2(...);
namespace detail {
// put relevant, but "private" / "internal" helper stuff here for 'something1' to use - in case there is any such code
};
}
This is fairly common approach - not just my doing. One should always avoid/minimize namespace pollution (especially global namespace).
The C++ Standard Library uses both classes and standalone functions. (Containers = classes, Algorithms = standalone functions, for the most visible example)
There was an interesting article I read a year or so ago about how std::strings should be redesigned, to move more of their member-functions to stand-alone functions, and which ones make sense to be member-functions and which ones make sense as standalone functions.
[s]Does anyone have the link to that? I can't find the article.[/s] Here's the article.
[hr]
Another gamedev user, quoting Bjarne Stroustrop, made a really interesting comment last year that I saved for myself:
There was an interesting article I read a year or so ago about how std::strings should be redesigned, to move more of their member-functions to stand-alone functions, and which ones make sense to be member-functions and which ones make sense as standalone functions.
[s]Does anyone have the link to that? I can't find the article.[/s] Here's the article.
[hr]
Another gamedev user, quoting Bjarne Stroustrop, made a really interesting comment last year that I saved for myself:
"My rule of thumb is that you should have a real class with an interface and a hidden representation if and only if you can consider an invariant for the class." - Bjarne Stroustrup[/quote]
"It took me years to really appreciate the depth of this insight. Free functions are incredibly valuable, as they have the minimum amount of coupling. They're the most reuseable thing in the toolbox. Classes are incredibly valuable as a way to enforce invariants over a group of functions and data. Without invariants to enforce, grouping functions in a class just makes the functions slightly more difficult to reuse." - mrbastard (GameDev.net user)[/quote]
"(Not to mention, functions are much easier to use in multi-threaded environments, since all the data is self-contained except those passed in through parameters... unless you have crappy globals, and muck everything up)" - an additional note I added for myself, a year ago.
[hr]
More notes from my personal collection that are relevant to this conversation, this time these are a few things (amongst many) I wrote down from watching the Going Native 2012 conference videos (which I highly recommend to intermediate to advanced C++ users).
Methods of writing cleaner, faster, stabler code:
- Stay as high level in C++ as you can.
- Use the standard library.
- Think in terms of algorithms operating on data structures
- Don't just make everything a class.
- Free floating functions are fine, if they make sense.
- Classes should only be a class if it makes sense for them to be.
- Prefer functions operating on structs, and algorithms operating on containers, except where classes need to, for safety, prevent some data from being operated on.
- Lower level code is NOT faster. Cleaner code is faster, and cleaner is usually higher level.
- Think generalized code, don't just hack code together, but think out clean generalized solutions.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
