2

I'm making a C++ OpenSource project and I want it the more understandable and clean, so I need some point of views about doing things like this :

Server.cpp:

void Server::setOption(type foo, type bar) {/* ... */}
void Server::start() {/* ... */}

App.cpp:

namespace App {
  void startServer() {
    Server s;
    s.setOption(o1, o2);
    s.start();
  }
}

Then in main function:

App::startServer();

Or should I simply write the whole code in main ?

3

There are a couple of problems with that style, the first being that Server ceases to exist at the closing brace of App::startServer. I also don't like the nullary constructor followed by a "set required things" method, followed by a "now I have my requirements" method.

Also note that a namespace is basically a (implicitly-)static-only class. I don't any need for one to wrap the starting of Server. If you had a bunch of other Server related things, they could all go into a namespace away from the rest of the program, but only if you have lots of identifiers in namespace scope and need to divide them up.

I would change it to:

class Server {
    Server(foo_t foo, bar_t bar) 
      : m_foo(foo), m_bar(bar) /*or w/e*/ 
    { /* body of start */ }
}

int main (...) {
    ... 
    Server s(o1, o2);
    ...
}
4
  • So according to you, I should pass all my params in the ctor ? – Nurrl Sep 4 '17 at 18:32
  • How am I suposed to deal with a case where I need to Construct, then start. i.e: Init Socket(Ctor) -> Bind socket (setOption) -> Start listening (start) – Nurrl Sep 4 '17 at 19:20
  • It is a great idea to put all in ctor or to split the function ? – Nurrl Sep 4 '17 at 19:29
  • If it isn't a Socket until all those steps, they should all be part of / called from the constructor – Caleth Sep 4 '17 at 20:29
6

My view is that if the code is written for one program, and is used just in one script, then you can make life easy by leaving it in the global namespace. However, if it's possible down the track that your classes and functions comprise a library (i.e.: imported by multiple programs, or released to the world as useful functions), then having them in their own namespaces is a must.

It looks like you are using multiple libraries (App.cpp and Server.cpp) already, so what I would do first is introduce a namespace for your whole project (i.e.: put everything under namespace nurrl or something more descriptive). Then if you really need you can put App and Server into their own namespaces, accessing functions like nurrl::App::startServer()

PS: with your above code, I'd have void startServer() actually be part of an App class in the App namespace, judging by the naming you've chosen

2
  • Hi @EpicWink, why would you say that I got a class App in the namespace App ? – Nurrl Sep 3 '17 at 12:37
  • @Nurrl I'm not the best object-oriented programmer out there, but ignoring all namespace considerations, App would sound like an object that you want control over. Basically, you don't want your server to be part of the global state of your program; instead you want it attached to an instance of something so you can access it more easily. – Epic Wink Sep 4 '17 at 3:37
0

I'm all up for passing data into constructors as long as constructing that data doesn't throw exceptions or the body of the constructor throwing. I think it's much cleaner to avoid exceptions altogether an have an init() method that you can return a sensible error value. This means that the implementer doesn't have to provide exception handling when constructing your object. Exceptions are also very heavy-weight in comparison to simple return values. Sure, if you need to unwind a whole lot of construction, then sure use exceptions to your hearts content, so long as your destructors also don't end up throwing. This is C++ not Java, where you're forced to do exception handling.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.