Click here to Skip to main content
15,122,845 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
When I have functions such as date conversion, data types, graphical transformations, and mathematical operations and I do not have data of those functions, there is no internal data that will survive over time. Is it necessary to create a class to group these functions? or just creating a .h and .cpp file is enough. My opinion is that in these cases creating a class is not necessary, it increases the complexity of the development, it hurts performance and it does not contribute; nothing but I would like to know the opinion of several experts or developers.

What I have tried:

I am not a computer scientist, I am an engineer and I like to analyze the whys of things. I think that creating unnecessary objects slows down and complicates development, that is, empty classes that do not encapsulate data are usually unnecessary ... but that's my opinion !! I would like to be certain about it. Thanks a lot.
Posted
Updated 14-Aug-21 19:01pm
v2
Comments
Richard MacCutchan 14-Aug-21 7:47am
   
No it is not necessary, it is purely your choice how you wish to code your application. If you do not use classes then it becomes plain C code, rather than C++; unless you are using the classes in the standard library. And unless your application spends hours in processing, the difference will be negligible.

This is an often discussed topic. Briefly spoken it is best to invest in clarity to avoid bugs and maintainability. Bugs often happen in rare and untested edge cases and so arent on the radar. Or if a collegue should add a feature or reuse the code. You wont believe my 20+ years experience: high quality code saves times by less bugs, better maintainability and more fun while coding.

Please read my How to Start the Homework or a Developer Career? for more insights about my experiences and know how.

BTW: execution time isnt a problem as compilation time too. The real problem are bugs.
   
v2
No, it's not necessary. It's perfectly OK to have "free functions" in C++: namely, ones that are declared outside of a class. Putting them in a class doesn't affect performance unless they are virtual functions. Instead, the justification is that the class would just be unnecessary boilerplate. And if such functions are added to a class that already has a legitimate purpose, they unneccesarily clutter its interface.

However, it's a good idea to define classes for things that can be measured differently. For example, a Distance class might have two members: an integral distance_, and the units_ being used (e.g., meters, kilometers, feet, miles). Here, the units_ field itself should be represented by two fields: a scale_ and the baseline unit_ ({1,m}, {1000,m}, {1,ft}, {5280,ft} for the previous examples). This recent article[^] discusses this in some detail (it's C#, not C++, but it should still make sense).

It would definitely be advisable to define a Date class to hide the details of converting a date to particular calendar or display format (e.g., should May 5th be shown as 5/6 or 6/5?). Similarly, there should be a class for Coordinate, which might even convert between Cartesian and polar coordinates.

Without these kinds of classes, the code becomes cluttered with copy-paste logic for converting between metric and Imperial, Gregorian and lunar, or Cartesian and polar.
   
v2
Back in the old days of C, before we had C++ and classes, everything was a case of "create a .H files, and a source code file" so everything was a "flat pile" of code.

And that gives problems. If for example I need to add three numbers together quite a lot, then I might create a function called Add to do it.
If I want a linked list, and want to add another struct to it, I might create a function called Add to do that.

And provided the two functions are in different projects, it works OK.
But ... if I need the "triple add" and the "linked list", suddenly I have a problem: the compiler has two functions with the same name and it doesn't know which to call when I tell it to!

This gets worse when you throw in library functions as well as many of them use the same names you want to and the same problem comes up again and again.

That's one of the problems classes solve: by keeping data and the code to process that data together in a named class you can have the same function name in multiple places because it's obvious which one you want to use: Triple.Add is not same as LinkedList.Add

Basically, although C++ retains the older C legacy globals, that doesn't mean you should use them. It contains printf and scanf as well, but you wouldn't use them in a Windows app would you?
   
Comments
Richard MacCutchan 14-Aug-21 8:05am
   
"printf and scanf as well, but you wouldn't use them in a Windows app would you?"
Mea culpa :blush:
enhzflep 14-Aug-21 8:30am
   
Nah, but I've often used the 's' prefixed versions of each. sprintf and sscanf are both rather useful. And to be pedantic... since console mode applications run under a gui OS these days, actually yeah - you would (I do) use them both in a "Windows app". (Of course I know(?) that's not what you meant)
I like Greg Utas's earlier answer. I'll repeat: No, it's not necessary to wrap standalone C++ functions with a class.

One thing you might consider is to define one or more namespaces as a guard against collisions with global names from any other library you might use. These can be nested, if needed, so there's only one top-level name to collide with any outside code.
   

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900