0

I'm wondering why C++ standard decided to make regex_* functions (regex_match, regex_search, regex_replace) non-member non-friend. They all need to access basic_regex's internals in order to perform the algorithms. Why don't they make them member functions of basic_regex? What are the benefits of free functions in this case?

Cranky
  • 42
  • 1
  • 3
  • 3
    Who says they are non-`friend`? There'd be no conforming way for user code to tell if they were `friend`s. Why do they need to be member functions of `basic_regex`? – Billy ONeal Jan 27 '15 at 19:09
  • 2
    [How Non-Member Functions Improve Encapsulation](http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197) – Praetorian Jan 27 '15 at 19:11
  • 6
    The C++ standard didn't decide, the design came from Boost.Regex almost unaltered. The design rationale is at http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2003/n1429.htm#algorithm_discussion – Jonathan Wakely Jan 27 '15 at 19:17
  • Boost regex. The main objects 'regex' and 'match' are like parts of speech that are put together in a sentence via function calls. This means the objects are reusable on the fly, can be passed around, and won't lose their independent context. –  Jan 28 '15 at 01:06

1 Answers1

1

Since the regex_* functions are non-member, non-friend, they only have access to the public interface of basic_regex. If they only need access to the public interface there's not much of a gain in being a member function over a free function, since both members and free functions can access a public interface. Also, by being free functions you remove dependencies that would connect the regex_* functions with the basic_regex class. If the regex_* functions are added to or altered or removed from, users of basic_regex that don't use those specific regex_* functions shouldn't have to recompile or bat an eyelash. This will help to future proof the clients of those functions and basic_regex for any changes that are dreamed up in future standards.

The regex_* functions would need to be member functions or friend functions only if they needed access to protected or private members of the basic_regex's interface.

Why should there be an added dependency if it is not needed?

YoungJohn
  • 946
  • 12
  • 18
  • -1: They probably are `friend`s -- there's no way for user code to tell if they are or not and the standard does not specify. – Billy ONeal Jan 27 '15 at 19:16
  • fair enough, but even as `friend`s there is still a bit more freedom using the free functions over the member functions. The `basic_regex` class is no more dependent on the functions. – YoungJohn Jan 27 '15 at 19:30
  • I don't think you can implement those regex_* functions using just the public interface of basic_regex. But if they are `friend`, then what member functions are for? I don't see any benefits of making them `friend` over members. – Cranky Jan 27 '15 at 19:35
  • Non-member functions can be packaged separately from a class and changes to them can occur without affecting clients of that class. Member functions must be tied completely to a class, and any changes to any member functions will be felt at least as a recompile for all clients of that class. – YoungJohn Jan 27 '15 at 19:40
  • In this particular case, I don't think anyone would use `basic_regex` alone without considering these associated algorithms. Aren't these "free functions" implicitly tied to the class? – Cranky Jan 27 '15 at 19:51
  • The free functions are tied to the class yes, but not to each other, and the class is not tied to them. A change to how a `regex_search` is implemented does not need to impact users of `regex_match`, etc. Also, if all you need is `regex_match` you won't need to compile `regex_search`, so long as they are free functions and not members. – YoungJohn Jan 27 '15 at 19:59
  • So are there any general rules when I should prefer member functions? After all, you can "free" all member functions by making them `friend` and leave your class with just constructors and private variables. – Cranky Jan 27 '15 at 20:02