|
HAPPY BIRTHDAY!!!
I am just about 74 (this month on the 26th).
Glad to see that there are professionals older than I still doing the work.
Me... I'm going out like Admiral Grace Hopper, the inventor of the COBOL language.
She worked full time as an instructor at Annapolis until the day she passed away at 85 years of age...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
|
I started my software development career using FORTRAN, taught myself C, suffered through Pascal and despise Visual Basic. I'm an EE that just learned how to do this. Back in the beginning, there were no IDEs just text editors, so I naturally developed the habit of putting one function in one file. As I moved on to C++, I continued this style with my class development - one class per file. I suppose I picked up this style from the people I worked with, early source control systems I used (CMS/MMS anyone?) and what not.
Now I admit I am no C++ guru. I have seen people on stack overflow answer a C++ question with so much mind numbing detail that my eyes glaze. I view some or most of the esoteric aspects of c++ (like operator overloading) as dubious at best. Sounds good initially but later on in maintenance, ugh.
So, coding style question - do you embed classes within classes? I suppose if the object is never used outside of it's main file, it sort of makes sense. But it makes it a $itch to track things down. Then, other modules that include the header file for the parent start referencing the embedded classes, and it becomes spaghetti code. I know it's valid C++, but....
Thoughts? I'm probably just being a curmudgeon. Currently doing battle with lifting a VC6 project to VS2022. To say it's "interesting" is putting it lightly but that's for another post.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I never nest classes in any languages - one class one file ( 2 in c++ )
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Nowadays, with IDE editors having multiple tabs and search commands for traversing a large set of files, it is sort of feasible.
In the old days when an editor handled a single file at a time, and you had to use an external, command-line search-files tool, splitting a system on thousands of files was really terrible to work with.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
I've done it, I'm not proud of it.
IMO, there is no real benefits.
On of the problems is that if you have nested classes in a public header, it makes things soooo much more fun (in a bad way), especially if the inner class is public.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Pascal doesn't have classes, but defining local functions within an outer function is the common practice. If you see PROGRAM as a little more than a PROCEDURE with global initialization, every function/procedure that you write lies inside another function/procedure(/program).
You probably see great advantages of hiding some matters local to a class within that class inside the class definition. In Pascal, you would hide helper functions for a larger function inside that larger function - just like you have local variables and data structures. Also note that in Pascal, a parameterless function was called just by its name, with no empty ()s. So you could change a simple variable to a function calculating the value, without making changes to the code using it. (It took several decades before C# got properties, to do the same!) If I change a local simple variable to a calculated, but still local, value, I see no major reason for why I should have to move the declaration of it out to the global level.
During my student days, we migrated from Pascal to C, requiring all functions to be declared in a flat space. Also, the convention of creating a separate file for each function, even a three-line one, was introduced. What was a nice, closed set of a major function / procedure and its helper functions, was spread out all over the place. You couldn't use a simple editor search function to find definition and all its uses (calls) - you had to use an external 'search files' function, outside the editor. (Our editors at that time did not have a built-in 'search files'.) We did use a lot of hardcopy printouts of source code in those days, and having to print even a 3-line function as a separate file, on separate sheets, increased the amount of paper by a large factor. By Unix/C standards, conventions required a lot of formal blurb (copyleft etc.), as well as inclusion/processing of sometimes huge header files, which in turn lead to number of #ifdefs and stuff like that. In Pascal, a 3-line function was no more than a 3-line function, declared in the scope where it was used, just like the variables. Old Pascal programmers did not see C as any great progress ...
There is no principal difference between classes within classes or functions within functions. The arguments for using or not using it is the same.
One major argument against nested procedures/functions was related to Pascal visibility rules: The tiniest, innermost function doing the simplest helper function had access to all its own local variables, of course, but also everything in the enclosing function, and everything at the next outer level and so on all the way out to the program global variables and functions / routines.
Languages with static nesting was quite common in the 1970s and 80s, and it was used frequently used. (Ask someone learning compilers in those years to explain what a 'static link' is - maybe you'll learn something new!). To handle the issue of the innermost little helper function having the greatest access, to 'everything', some languages required you to export symbols not only to the outside, but also to the inner functions, and the inner functions to import them. (To reduce clutter, some languages let you export/import 'pervasively', so that no further import/export was required for the next levels.)
After shelving Pascal, I have not used much function nesting - for a couple decades, it wasn't possible in C based languages, so I got out of the habit. I cannot recall a single case of nested class definitions. But when I learned of C#, properties and accessors, I became a heavy user of that - which is certainly related.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
In C++. you can use pimpl if you want to hide something in the implementation.
or even have a class in the implementation file (cpp) if it's only used in that translation unit.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
I do, but the embedded classes are always marked private - they are only accessible within the containing class.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
yeah, no private at all listed...
it doesn't help that VS2022 has some of the most ridiculous compiler errors. One error typically generates N other gripes.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I've done this too (minus marking it as private), but only when the inner class needed access to some private members of the container class, and the internals of the inner class was nobody else's business - including the container.
Something like that anyway. I've rarely done it, but I have.
|
|
|
|
|
Every time I've embedded classes inside another class, some new requirement down the road requires I remove this embedded class and make it stand on its own.
I will occasionally put two classes in a file, especially when one is the <type t=""> for a custom collection class. The collection class is usually very short (<40 lines) and I put it at the top of the file so both classes are visible on the first screen in the IDE.
modified yesterday.
|
|
|
|
|
happy to see it's not just me.
The only two times I have seen this style, they both came from CS grads whiz kids. I'm now going through a lot of code from WK#1 where he forgot to initialize a bunch of variables.
Side note: I know VS2022 allows you to ignore uninitialized variables, but why in God's good name would you ever turn that off? Been burned to many times by everything working in debug and phantom failures in release.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
As a somewhat handicapped non- queen's English speaker I get puzzled by some expression.
I have done some embedded processor hobby type projects, and currently I am struggling with child classes as members of a parent class.
I do see the differences , but mixing up these terms , or inventing new one (?) is frustrating.
Does it really makes much difference not calling classes as "member of "
as are other member variables called ?
I have never seen usage of term "embedded variable "...
modified yesterday.
|
|
|
|
|
Different languages have different terms that are the same thing at an abstract level. Delphi has a concept of nested methods, which are either a function or procedure defined inside another (Delphi is based on Pascal, and this was explained in detail in a prior post). C# allows nested classes, where one class has another defined inside it. As others have said, this really should only be done if the nested/inner class is marked as private so only the outer class can access it. I'm avoiding the terms parent/child because those are usually used with inheritance, and this discussion has nothing to do with inheritance.
Embedded variable? It's a new one for me. I googled it:
Quote: An embedded variable in programming is not predetermined and changes, so it can't be entered ahead of time.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
embedded as a synonym for interior/inside/nested.
Java calls them inner classes.
Parent/Child class or super/sub class is more of a family tree related to class inheritance.
|
|
|
|
|
yes and I will do it again I tells you!
Enum class part of another, or groups of classes that linked, mainly object model and not really any functions/methods inside.
My mind views it like the document plan, its one piece of paper the defines the object, so why would I want to have multiple pieces of paper, individually they are useless
|
|
|
|
|
Yes. exempli gratia a method returns data related to the class. What better way than via a class. What better place to declare the returned class than embedded.
|
|
|
|
|
charlieg wrote: do you embed classes within classes?
Yes, if appropriate. The maxim "the right tool for the job" applies.
I manage visibility with private/protected as necessary if the embedded class is only used internally by the surrounding class. An example would be elements in a data structure used within the surrounding class.
If an embedded class is public, then it is embedded because it has relevance only in relation to the surrounding class. The example here would be the embedded class contains properties and state of interest to users of the surrounding class and it's either cumbersome or infeasible to have the surrounding class supply those values itself.
Software Zen: delete this;
|
|
|
|
|
I see that as a COMPLETE contradiction of encapsulation, but I freely admit to despising embedded classes. This might be because every series of embedded classes I have encountered show no reason to exist other than to be cute.
The code base I am working on actually has embedded classes within other classes that are all public. So my thought is wtf, why not make it obvious?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I mostly do C# these days. But I find that when I am designing a dialog box for a program, I usually need more than a single primitive value returned. What I seem to end up doing is writing an embedded class to handle all the returning data. I make it an embedded class because I can keep it associated with that dialog box. Using a class gives it an instance that doesn't vanish the moment the dialog closes. There have been a few occasions when I've decided that an embedded class was a good solution as a class to handle multiple issues in a project. When I get to that point, I usually elect to change the class from embedded to a separate file.
|
|
|
|
|
Question: explain to me how putting data in an embedded class solves any problem? If the instance of the dialog (which is an object) sticks around, then the public data is still available. Embedding an object within an object seems over complicated to me. Double encapsulation?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I'll have to look at some of my project code and get back with you, as it half past midnight here, and I am a bit fuzzy on why. I know that the way I write my dialogs aren't quite as trivial as textbook examples, and I have to look and see why. But what I think I was doing was not so much as embedded a class within a class, but simply putting my data class on the end of the dialogbox class, initially, rather than having a separate file for the data class. It may relate to my wanting a dialog box that had an Apply button implemented in addition to the usual OK and Cancel buttons. It may be that my dialog box does something complicated and has to stay open and effect the target form with changes as I make them on the dialog without closing and reopening the dialog repeatedly until I get the combination I want.
|
|
|
|
|
I always try to use the right tool for the right job.
|
|
|
|
|
I agree, but what I am seeing is a coding style vs a design approach.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
