3 ms·

I'd also prefer "intersect(s1, s2)" if C++ had multimethods... But to follow the line of Bjarne's advice (I've also heard same from Stepanov): One should prefe

by zura 12y ago

I'd also prefer "intersect(s1, s2)" if C++ had multimethods... But to follow the line of Bjarne's advice (I've also heard same from Stepanov): One should prefer non-member functions. i.e. there must be some real reason for some function to become a member of a class.

nly 12y ago
> I'd also prefer "intersect(s1, s2)" if C++ had multimethods... Bjarne has wanted multi-methods for decades.
throwawayaway 12y ago
The problem with non member functions is that, once you start preferring them, you are basically writing C. They are contagious. There's very little reason for class members unless you want inheritance or polymorphism. Scott Meyers has also promoted them: http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 http://www.drdobbs.com/cpp/how-non-member-functions-improve-... With non member functions declared in the header and defined in a .C file, and suddenly you don't have RIAA any more or exceptions. Your .C files end up being your division of concerns, not classes. The only time you end up using any C++ features is interacting with a library that prefers member functions.
- JoeAltmaier 12y ago
  This idea that 'files' are an organizing principle is bankrupt. In an editor I don't even know what file a method is in. Including header files is an annoyance, and should be automated. In fact all code should be in a database, not a file, so changes can be tracked and attributed properly. So a tool can distinguish between 'lines being edited' and 'one function deleted and another added'. And so on. So what organizing principle is left, since files are largely invisible during the coding process? Well, classes spring to mind.
  - throwawayaway 12y ago
    I think you need a better editor if you don't know what file a method is in. There will be very few classes in your project if you decide to prefer non member non friend functions as suggested here. The question being, whether you go along with that suggestion or not?
    - JoeAltmaier 12y ago
      I guess that wasn't clear. I surf methods, not by opening files, but by going directly to the definition or declaration as needed. Sure its in some file, but I deal with 1000 methods and sure don't make any effort to memorize where they are - since its entirely irrelevant to the correctness of the code. To make it clear: I favor factoring APIs into classes.
      - throwawayaway 12y ago
        I think factoring api's into classes makes a lot of sense too, I think this idea of preferring non member functions undoes a lot of the functionality and team building cohesiveness that C++ offers. It's strange that C++ luminaries like Stepanov, Meyers and Stroustrup favour non member functions.
- zura 12y ago
  Well, the key thing is the `reason` here. In C++ we use RAII, so this is the reason to have a member constructor/destructor functions instead of non-member create_something(...)/destroy_something(...) (aka C style). But, for instance, `sort` is a good candidate to have outside of a class - and it actually is a global function - std::sort.
  - throwawayaway 12y ago
    RAII is your reason. When you start preferring non member functions, you tend allocate on the stack. There are rare items that require heap allocation and other resources. For those you can have classes. What I am saying is that when you prefer non member functions you end up with very few classes.
    - nikbackm 12y ago
      You don't use classes only to get RAII. They are also useful when you have data with invariants, which the constructor establishes. And of course, if you want to use private data.
      - throwawayaway 12y ago
        by invariants do you mean constant values? there's many ways to implement private data. if you prefer non member functions, a class is a bunch of extra keystrokes to achieve the same as the old fashioned C private data. if you prefer non member functions to member functions, your private data becomes a global variable or struct in a file, and the private data is not accessible by getter/setter functions that are externalised.
        zura 12y ago
        Having access to private data (implementation details) is another reason to have a member function. Unless you're a fan of `friend` keyword ;)
        12y ago

by zura 12y ago

nly 12y ago

> I'd also prefer "intersect(s1, s2)" if C++ had multimethods... Bjarne has wanted multi-methods for decades.

throwawayaway 12y ago

The problem with non member functions is that, once you start preferring them, you are basically writing C. They are contagious. There's very little reason for class members unless you want inheritance or polymorphism. Scott Meyers has also promoted them: http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 http://www.drdobbs.com/cpp/how-non-member-functions-improve-... With non member functions declared in the header and defined in a .C file, and suddenly you don't have RIAA any more or exceptions. Your .C files end up being your division of concerns, not classes. The only time you end up using any C++ features is interacting with a library that prefers member functions.

JoeAltmaier 12y ago
This idea that 'files' are an organizing principle is bankrupt. In an editor I don't even know what file a method is in. Including header files is an annoyance, and should be automated. In fact all code should be in a database, not a file, so changes can be tracked and attributed properly. So a tool can distinguish between 'lines being edited' and 'one function deleted and another added'. And so on. So what organizing principle is left, since files are largely invisible during the coding process? Well, classes spring to mind.
- throwawayaway 12y ago
  I think you need a better editor if you don't know what file a method is in. There will be very few classes in your project if you decide to prefer non member non friend functions as suggested here. The question being, whether you go along with that suggestion or not?
  - JoeAltmaier 12y ago
    I guess that wasn't clear. I surf methods, not by opening files, but by going directly to the definition or declaration as needed. Sure its in some file, but I deal with 1000 methods and sure don't make any effort to memorize where they are - since its entirely irrelevant to the correctness of the code. To make it clear: I favor factoring APIs into classes.
    - throwawayaway 12y ago
      I think factoring api's into classes makes a lot of sense too, I think this idea of preferring non member functions undoes a lot of the functionality and team building cohesiveness that C++ offers. It's strange that C++ luminaries like Stepanov, Meyers and Stroustrup favour non member functions.
zura 12y ago
Well, the key thing is the `reason` here. In C++ we use RAII, so this is the reason to have a member constructor/destructor functions instead of non-member create_something(...)/destroy_something(...) (aka C style). But, for instance, `sort` is a good candidate to have outside of a class - and it actually is a global function - std::sort.
- throwawayaway 12y ago
  RAII is your reason. When you start preferring non member functions, you tend allocate on the stack. There are rare items that require heap allocation and other resources. For those you can have classes. What I am saying is that when you prefer non member functions you end up with very few classes.
  - nikbackm 12y ago
    You don't use classes only to get RAII. They are also useful when you have data with invariants, which the constructor establishes. And of course, if you want to use private data.
    - throwawayaway 12y ago
      by invariants do you mean constant values? there's many ways to implement private data. if you prefer non member functions, a class is a bunch of extra keystrokes to achieve the same as the old fashioned C private data. if you prefer non member functions to member functions, your private data becomes a global variable or struct in a file, and the private data is not accessible by getter/setter functions that are externalised.
      - zura 12y ago
        Having access to private data (implementation details) is another reason to have a member function. Unless you're a fan of `friend` keyword ;)
        12y ago