C++ Handling Objects System Wide

[xenos]

Just use static functions, not TTY.write() but TTY::write()

...or take this idea even further and don't use an object at all, but make TTY a namespace instead. Currently I work on refactoring my kernel so that all classes, of which there exists always exactly one object, are turned into namespaces. The disadvantage is that you cannot make functions / data members of a namespace private to this namespace, in order to enforce encapsulation. (IMHO it would be a nice extension to the C++ standard if you could - but you can achieve it with a class that only has static members.)

[OSwhatever]

It sounds like what you want is either a Singleton class, where there is only a single instance of the class is created and every subsequent instantiation via the c'tor is just a pointer or reference to that one instance, or Object Pool class, which creates a pool of existing objects and returns a reference to one of those pooled objects wherever a new one is needed, then returns the object to the pool when it is finished.

Singleton classes are very useful for me at least. Using globally declared classes doesn't work well for kernel development as you have no control over the order the global objects will be initialized. Instead with singletons the object will be initialized when calling the initialization method which calls the constructor. This way you have full control over the initialization order.

[dozniak]

Just use static functions, not TTY.write() but TTY::write()

...or take this idea even further and don't use an object at all, but make TTY a namespace instead.

Correct, this works.

To make functions/etc private inside a namespace, put them into an anonymous namespace, e.g.

Code: Select all

namespace TTY {
  void publicInterface();

  namespace {
    void privateFunc();
  }
}

[Octacone]

I don't want to call my functions like MyClass::Some_Function(); I prefer Object.Some_Function();. Is it a smart idea to just make a file and put all the object definitions inside it? Then I would only have to include that specific file. No additional initializations etc...

[gerryg400]

Octacone, the problem with system-wide objects is that every class that uses one of those objects becomes dependent on it. You don't want that because it limits re-use (every project that uses that class will need to have all those system-wide objects present) and means that your code is difficult to unit test because again the system-wide objects need to be present in every unit test. Using namespaces doesn't help it's just more global variables partially obscured in a different way.

This question needs an architectural solution. What exactly is the TTY object? Is it your system logger? Temporary debug logger?

[Octacone]

Octacone, the problem with system-wide objects is that every class that uses one of those objects becomes dependent on it. You don't want that because it limits re-use (every project that uses that class will need to have all those system-wide objects present) and means that your code is difficult to unit test because again the system-wide objects need to be present in every unit test. Using namespaces doesn't help it's just more global variables partially obscured in a different way.

This question needs an architectural solution. What exactly is the TTY object? Is it your system logger? Temporary debug logger?

Hmm, it seems easy but it is not. TTY stands for Text Type Interface. It was just an example. I want to keep my OS as secure as possible. What do you mean by projects?

[Octacone]

Just use static functions, not TTY.write() but TTY::write()

...or take this idea even further and don't use an object at all, but make TTY a namespace instead.

Correct, this works.

To make functions/etc private inside a namespace, put them into an anonymous namespace, e.g.

Code: Select all

namespace TTY {
  void publicInterface();

  namespace {
    void privateFunc();
  }
}

Static functions seem to be okay, I don't know about namespaces. I do not need to hide any functions currently. It doesn't quite matter because that is why system calls exist. (speaking of security) Why would I put it inside another namespace when I can just put it under private. All in all I think I will stick with the standard objects and static functions for things are repeatable.

[dozniak]

I don't want to call my functions like MyClass::Some_Function(); I prefer Object.Some_Function();

Use Pascal or Java then...

[dozniak]

TTY stands for Text Type Interface. It was just an example.

It should be a TTI then.

[Octacone]

I don't want to call my functions like MyClass::Some_Function(); I prefer Object.Some_Function();

Use Pascal or Java then...

Nope, I guess I will have to live with it.

[Octacone]

TTY stands for Text Type Interface. It was just an example.

It should be a TTI then.

My whole life was a lie! So TTY != text type interface... Oh, bummer! How could I have missed this? I guess I mixed TUI with TTY, that is how this was born. I knew that a TTY had to do something with the terminal and meanwhile I was looking at the "Text User Interface" page...

[Roman]

First, you should know the language you use for OS development better.

Second, you should do it like this:

• tty.h – Teletype (or whatever way you name it) class declaration.
• tty.cpp – Teletype class definition.

I'm not sure I correctly understand what you're asking about, though.

[Octacone]

First, you should know the language you use for OS development better.

Second, you should do it like this:

• tty.h – Teletype (or whatever way you name it) class declaration.
• tty.cpp – Teletype class definition.

I'm not sure I correctly understand what you're asking about, though.

Why are you saying that? I was doing the exact same thing. This is more of an "architectural" design choice really.

[dozniak]

So, are you content with using

Code: Select all

::

or you will have to instantiate TTY just to satisfy your whim desire to use

Code: Select all

.

?

[Schol-R-LEA]

TTY stands for Text Type Interface. It was just an example.

It should be a TTI then.

I was going to say something myself, but let's be honest, it is a more accurate name for most TTY systems these days. When was the last time you saw an actual teletypewriter of the sort that printed directly to a roll or fanfold of paper?

(To answer my own question, it was in the machine room at Southern Connecticut State U. sometime around 1987. It was next to the VAX's HVAC system for some reason, and I got the impression that it had been left there since before the mainframe was installed. IIRC it wasn't connected to anything - I am pretty sure no one still working for the college remembered why it was there in the first place, as it looked like it hadn't been touched in at least fifteen years. I only got to see it because students who needed to get accounts on the VAX had to submit an application at the sysadmin's 'office', which was a cubicle on the other side of the security cage opposite the VAX itself. At least, that's how I recall it, it has been quite a while.)