Home > Coding > Breaking up is hard to do (to member functions)

Breaking up is hard to do (to member functions)

Want to bounce this off some other coders before I make a language-change proposal of it:

C#’s “partial” class type lets you spread a class definition across multiple files. But mostly people use it as a way to make private code definitions private – split large functions up into little nuggets that don’t get exposed in the primary API while still having membership status to access member variables, etc.

The downside is: it actually lets you add crap to the class in your own definitions, forming part of the need for the “sealed” accessor type in C#.

In C++ your choice is (a) huge member functions, (b) Pimpls, (c) classes that list zillions of private members in their public API.

Seems to me, a simple combination of existing keywords would let you create non-public, compilation-unit scoped temporary member functions so you can break a large member function up without all the hassles that come from breaking a member function into private local non-member functions.

Specifically the term “private”.

By marking them this way, the following constraints/restrictions/behaviors would naturally fall out of the current language definition:

  • Cannot be virtual (if it goes in the vtable, it goes in the ‘class’ def,
  • Cannot be abstract (since you’d have to declare it in the class),
  • Cannot share a name with a well-defined member function or variable,
  • Not visible to derived classes even if they are in the same compilation unit, (as applies to any ‘private’ member)
  • Cannot be an operator, (that could lead to some nightmare situations)
  • Cannot be static (static members aren’t limited to ‘public’ access, so there are actually good use cases for ‘private static’)
/// Header file Foo.h
class Foo {
public:
  Foo() : m_bar(“”), m_i(0) {}
  void bigFunction();
  void otherFunction();
private:
  void privateFunction();
};

 

/// Foo1.cpp
#include “Foo.h”

private void Foo::helper1() {
  m_bar = “hello”;
  m_i = 1;
}

private inline void Foo::helper42() const; // prototype variant.

void Foo::bigFunction() {
  helper1();      // member call
  …
  helper42();	// member call
}

void Foo::helper42() const {
  m_bar = “world”;
  m_i = 42;
}

class Bar : public Foo {
  …
  void barMember() {
    helper42(); // Error: it was private to Foo.
  }
};

 

/// Foo2.cpp
#include “Foo.h”

private void Foo::helper1() {
  // Legal, because helper1() was private-unit-scoped in Foo1.cpp and is thus not visible here.
}

private void Foo::privateFunction(const char* const message) {
  // ERROR: The finger print is different but the name conflicts with an established
  // ERROR: member function name, so this isn't legal.
}

void Foo::otherFunction() {
  helper1();	// Invokes the helper1() declared in Foo2.cpp above.
  …
  helper42();	// Error: helper42 is only unit-visible in CPP file #1.
}
Categories: Coding Tags:
  1. Victarus
    November 19, 2012 at 4:38 pm

    Yeah, I’ve run into this before: I like to divide up my functions, but it’s kind of a pain while still keeping a “proper” class. :-/

    In and of itself I don’t see any glaring problems, but I think there are two things being done that, perhaps, should be done separately:
    1) Allowing private members to be accessed outside of predeclared members.
    2) Allowing ‘implied this’ semantics outside of predeclared members.

    The reason I divided it is because I think the results are a little cleaner if it’s split into two proposals.

    1) Implicitly give each class a namespace. Namespace members can be public/protected/private, and this determines the level of access they have as well as the level of access required to use them.

    For example(*):

    class namespace Foo {
    void public_func(Foo&) ; // Defaults to public.
    private void helper(Foo&) ; // Can access Foo’s members, but can also only be called by Foo.
    }

    2) Allow a function to declare its first parameter to be “this” within the scope of the function. Calling the function via this->f(…) calls the function with the first argument as ‘this’ and the following arguments afterward. (Automatic? Seems a bit strong…)

    For example:

    void foo_helper(Foo* this, int i) { … }

    Foo::func(int i) {
    this->foo_helper(i) ;
    }

    void external_func(Foo* f) {
    foo_helper(f, 0) ;
    }

    Anyway, this is just an idea I threw together quickly. I can already think of some potential issues to consider/address, but I thought some quick feedback might help even if it’s a little undeveloped. :)

    *) Sorry, I don’t use WordPress that often and don’t have a ‘preview’ option, so I’m not going to risk trying to throw in code tags and making this *completely* unreadable. :p

  2. capsain
    November 19, 2012 at 8:15 pm

    In Foo2.cpp, with the declaration of:
    private void privateFunction(const char* const message)

    -> Question 1: Should the privateFunction declaration be Foo::privateFunction?

    -> Question 2: Why would that declaration be illegal?
    Case 1: If the function is a member function of Foo, It seems like it would just create an overload of privateFunction(), which would be private to the class.
    Case 2: If it’s not a member function of Foo, then it shouldn’t be allowed the ‘private’ keyword. Without the ‘private’ keyword, it shouldn’t conflict with any functions.

    If it’s return type was different, I could see it being invalid as an overload as well, and THEN I can see it being illegal.

    Still thinking about the rest of the treatise.

  3. November 22, 2012 at 1:11 am

    @capsain

    Answer 1: Yes, it should – oops. Edit coming up.

    Answer 2: Overloads just kind of feel wrong, especially since with templates that could cause other code to behave differently in one file than it does in another. The real aim is to let you take a 10,000 line member function and break it up into smaller, private but still member- functions without all the usual polluting of headers etc that goes on as a result.

  4. November 22, 2012 at 1:25 am

    @victarus (and in a way, thus also @capsain)

    “1) Allowing private members to be accessed outside of predeclared members.”

    So, remember: the primary goal is to let you better distribute the innards of existing member functions, consider:

    void Foo::ConnectToSMTP(const char* const hostname)
    {
     // ...
     // ...
     // ...
     // code that resolves an IP
     // ...
     // ...
     // ...
    
     // ...
     // ...
     // ...
     // code that checks the firewall
     // ...
     // ...
     // ...
    
     // ...
     // ...
     // ...
     // code that opens a connection
     // ...
     // ...
     // ...
    
     // ...
     // code that queues the "HELO" callback
     // ...
    }
    
    void Foo::ConnectToHTTP(const char* const hostname, const char* url)
    {
     // ...
     // ...
     // ...
     // [same] code that resolves an IP
     // ...
     // ...
     // ...
    
     // ...
     // ...
     // ...
     // code that checks the firewall
     // ...
     // ...
     // ...
    
     // ...
     // ...
     // ...
     // code that opens a connection
     // ...
     // ...
     // ...
    
     // ...
     // code that sends the "GET" request
     // ...
    }
    
    /* Becomes */
    
    private void Foo::Connect_ResolveIP(const char* const hostname, IPAddress& into)
    {
     // ...
     // ...
     // ...
     // code that resolves an IP
     // ...
     // ...
     // ...
    }
    
    private void Foo::Connect_CheckFirewall(const IPAddress& destination, ushort port)
    {
     // ...
     // ...
     // ...
     // code that checks the firewall
     // ...
     // ...
     // ...
    }
    
    private void Foo::Connect_TCPConnect(ushort port, uint timeout)
    {
     // ...
     // ...
     // ...
     // code that opens a connection
     // ...
     // ...
     // ...
    }
    
    void Foo::ConnectToSMTP(const char* const hostname)
    {
     Connect_ResolveIP(hostname, &m_ipAddress);
     Connect_CheckFirewall(m_ipAddress, Ports::SMTP);
     Connect_TCPConnect(Ports::SMTP, Timeouts::SMTP);
    
     // ...
     // code that queues the "HELO" callback
     // ...
    }
    
    void Foo::ConnectToHTTP(const char* const hostname, const char* url)
    {
     Connect_ResolveIP(hostname, &m_ipAddress);
     Connect_CheckFirewall(m_ipAddress, Ports::HTTP);
     Connect_TCPConnect(Ports::HTTP, Timeouts::HTTP);
    
     // ...
     // code that sends the GET request
     // ...
    }
    

    The private local functions aren’t getting any special access privileges; they can’t be called across compilation units. They are simply allowing logical reorganization of more existing member functions…

    Remember: They can’t be called from outside of the class – via friend, or anything. So, they have to be invoked from a member function and retain all the constness etc.

    That’s a big part of why I wanted to slap so many restrictions on them :)

  5. Victarus
    November 22, 2012 at 10:25 am

    I guess my problem is all those restrictions make the whole thing comes off as somewhat unnatural — kind of like “I want to code like this” was the starting point instead of “What’s the real problem here?”

    For example, the big one is limiting helpers to a single compilation unit. It makes sense from a “This is what I want to do with it” perspective, but it doesn’t really make sense from a language-design perspective. Since they can’t be virtual, helpers are essentially nothing more than a normal function with private access and an implied “this” argument. With that in mind, why treat them any differently than any other function? They can be wrapped in an anonymous namespace if that’s the desired behavior, and I’m sure coders with template/inline functions in headers and classes split across multiple compilation units would appreciate that.

  6. November 23, 2012 at 1:59 am

    “They can be wrapped in an anonymous namespace if that’s the desired behavior, and I’m sure coders with template/inline functions in headers and classes split across multiple compilation units would appreciate that.”

    That only works until the user is no-longer the author – i.e. when the code is part of a library someone else is trying to incorporate into their package.

    “it doesn’t really make sense from a language-design perspective”

    I’m not trying to design a new language, rather I’m trying to resolve a problem I’ve seen frequently over my 15 years with C++ in a C++ way.

    Even so, I think this actually makes a lot of sense from a language-design perspective – perhaps my original use of the term “restrictions” was too terse. Most of them actually just fall naturally out of the very concept of a helper class member routine. See my edit of the top of the article.

    The idea of putting them in a namespace is a bit too much like the “friend” system for me, and it doesn’t intuitively tell me why you can’t access those functions from outside – which you absolutely should not be able to do otherwise you’re simply opening a backdoor into the class, and that’s not the intent of this system.

    I actually see the CU-local scope as a benefit not a restriction. As for the other “”restrictions””:

    * Making a member virtual is, essentially, to expose it (via the vtable). That’s something you fundamentally need to do at the class-definition level so that the compiler can deal with it across CUs. So in order to make a helper virtual, you /have/ to make it part of the up-front class definition.

    Foo.cpp:sizeof(Foo): 16 bytes.
    Foo1.cpp:sizeof(Foo): 32 bytes. (Oops, private virtual Foo::herp() introduced a vtable and changed the size of the object).

    * “Friend” interaction is a gateway to backdoors so it’s something that has to be done at the class level. So in neither direction is friend interaction with these entities helpful, desirable or anything less than lots of extra lines of code (which defeats the point).

    * It can’t be abstract because that would actually make no sense.

    //// Foo.h
    class Foo {
    // No language change required to achieve this.
    private: void herp() = 0;
    };
    
    //// Bar.cpp
    private void Bar::derp = 0;
    // Ok - what does that *mean*? In this file, treat Bar as abstract.
    // How would any other module know to do the same?
    

    * Operator overloading is already messy; introducing the ability for things to quietly overload an operator away from the header file is dangerous. To allow CU-scoped operator overloading (stuff that gets called via this CU handles operator= differently) would be a real disaster. To allow it to happen cross-CU you just … put something in the header. IE that’s something you can already do. So it makes no sense for a CU-scoped member to be able to behave as an operator for a class.

    //// libFoo.h
    class Foo
    {
      std::ref_ptr<Object*> m_object;
      std::ref_ptr<char*>   m_name;
    public:
      Foo();
    };
    
    //// libfoo.cpp
    #include "libFoo.h"
    
    private void Foo::operator=(const Foo& rhs_);
    

    When I’m using libFoo in a compiled format (i.e. a library) how does the compiler know what to do in the case of

    //// fooconsumer.cpp: gcc -o fooconsumer -c fooconsumer.cpp -lfoo
    #include "libFoo.h"
    
    Foo s_myFoo;
    
    /* ... */
    void setMyFoo(const Foo& otherFoo) {
      s_myFoo = otherFoo;
    }
    

    The only possible way the compiler can cope with this is … if you declare it in the header file. Ergo, these functions cannot be operators.

    * Can’t match an existing name: For the same reason they can’t be operators. The problem is that if you allow them to, you can create messed up inconsistent situations like the following:

    //// Foo.h
    class Foo {
     void doIt(std::string);
    };
    
    //// Foo1.cpp
    private void Foo::doIt(int);
    // What does foo->doIt("10"); do here?
    
    /// Foo2.cpp
    private void std::string::operator int() {
     return atoi(c_str());
    }
    // What does foo->doIt("10"); do here?
    

    * Non-derivation:

    #include "Bar.h" // class Bar { void herp(); };
    class FooBar : public Bar {
      void derp();
    };
    

    This code should be fine. Looking at Bar tells me: there is no member “derp” in Bar.h.

    If I chose to declare “derp” as a private member in a CPP file someplace, specifically choosing not to make it part of the formally-declared class, then it shouldn’t show up in Bar’s derivation.

    Which is actually just a natural extension of the fact that they are private members — this is no different than if I had declared “private: void derp();” in Bar’s definition…

    The one case I’ll conceed is “static” – in-fact, I’m going to remove it =)

    -Ol

  7. November 23, 2012 at 2:34 am

    I’m guessing you’re imagining that you’d put these “sub-official” function definitions into a header file someplace so you could #include that when you, the library author, needed to access them.

    The problem is the compiler needs a consistent class definition across files.

  8. Victarus
    November 23, 2012 at 12:15 pm

    (Using codetags. God I hope this works. :p)

    I think the difference we’re having is you’re seeing it as a language feature with underlying mechanisms at work, while I’m looking at it as some syntactic sugar. Maybe I’m missing some key issue that needs more than just a glorified preprocessor trick, but so far I fail to really see it.

    The reason I think that’s where you’re coming from is this:

    “The problem is the compiler needs a consistent class definition across files.”

    Unless I’m misinterpreting something those new functions *aren’t* a part of the class — or, at the very least, I’m almost certain they don’t need to be. If they were, they’d have to be in the class’ definition since you shouldn’t really be able to redefine a class after that point, in which case we’re back to just adding private members in the definition again.

    If this *is* a real restriction for some reason I’m just not seeing, it opens up some real problems. Beyond just forbidding coders from splitting member functions into their own files, I think this also means any inlined members are broken for the same reason members in a second file would be.

    This means that, despite the “Foo::” syntax, they’re just normal functions that can access one class’ private members, can only *be* accessed from members of that class, and have an implicit ‘this’ as the first argument (unless they’re declared as ‘static’, of course).

    With that in mind, other than some syntactic sugar and working around the private restriction, I really don’t see any difference whatsoever between the following two functions:

    private void Foo::do_something_1(int) { ... }
    void do_something_2(Foo*, int) { ... }
    
    void Foo::actual_member(int i) {
        do_something_1(i) ;
        do_something_2(this, i) ;
    }
    

    Well, except that one could have a well-formed ‘void (Foo::*)(int)’ and the other couldn’t… I think. :-/

  9. November 25, 2012 at 1:15 am
    //// Foo.h
    class Foo
    {
    public:
      Foo() : m_name("bar"), m_value(42) {}
      ~Foo() {}
    
    private:
      void CalculateMyBankBalance(int i);
    
    public:
      void actual_member(int i);
    
    private:
      std::string m_name;
      int m_value;
    };
    
    //// Foo.cpp
    private void Foo::do_something_1(int i )
    {
      if ( i > 1000 )
      {
        CalculateMyBankBalance(i); // OK: I'm a member, so I can access it.
        m_name += " (happy)"; // OK: You're a member.
        m_value += i;
      }
    }
    
    void do_something_2(Foo* this, int i)
    {
      if ( i > 1000 )
      {
        this->CalculateMyBankBalance(i); // ERROR: You're not a member.
        this->m_name += " (happy)"; // ERROR: You're not a member.
        this->m_value += i; // ERROR: You're not a member.
      }
    }
    

    The code within these functions is absolutely part of the class, but on the other hand, they have absolutely no reason to clutter the public definition of the class.

    Taking them out of the class and putting super-internal class-member code into non-class functions is just wrong.

    To achieve what I’m describing with a non-member helper function, you’d need to declare it as a friend — in the class. At which point you may as well just put it in the class.

    This method creates a clean hybrid between the two approaches:
    . Header file is left untouched which encapsulation and privacy are kept intact,
    . Function has the entitlements of a declared member function,

    Makes it a lot easier to split out chunks of code from what would otherwise become large functions (or break up existing large functions, without polluting headers in the process) in an encapsulation-consistent fashion. Avoids back-dooring (hint: what happens if you ‘friend’ a function that’s “c-static”).

    And it re-uses existing keywords and an existing approach…

  10. Victarus
    November 25, 2012 at 11:53 am

    “To achieve what I’m describing with a non-member helper function, you’d need to declare it as a friend — in the class.”
    Or expand the language, which is what you’re proposing anyway. ;-)

    “Taking them out of the class and putting super-internal class-member code into non-class functions is just wrong.”
    But ultimately, that’s kind of what you’re doing: The only thing that makes the additional functions “members” are a “Foo::” being tacked on to their name, and I’m arguing it’s really just syntactic sugar and should be treated as such.

    For example, this is how I imagine people would often like to use this new feature:

    // Header
    class Foo {
    public:
        ~Foo() {} // (!)
        void member_1(void) ;
        void member_2(void) ;
    private:
        void helper_called(void) ;
    } ;
    
    //------
    // Source
    
    private void Foo::helper_1(void) { this->helper_called() ; }
    void Foo::member_1(void) { helper_1() ; }
    
    private void Foo::helper_2(void) { this->helper_called() ; } // (!)
    void Foo::member_2(void) { helper_2() ; }
    

    From what I gather, you’re saying helper_2 is invalid (or makes everything above it invalid) since “the compiler needs a consistent class definition”. (You mentioned across files, but just split them into different files for the example if it’s fine in a single file.) You’re also saying that the inline destructor is invalid since the class definition available to it is somehow incomplete.

    My big question here is: Why? In terms of actual underlying functionality, what’s the difference between the above and this:

    // 'Foo* this' as the first argument makes the function act as pseudo-member of Foo.
    // Adding 'private' to pseudo-member allows private access to 'Foo', but in turn restricts
    // access to this function as though it were a private member of Foo: Only Foo or Foo's
    // friends can call it.
    
    private void helper_1(Foo* this) { this->helper_called() ; }
    void Foo::member_1(void) { helper_1(this) ; }
    
    private void Foo::helper_2(void) { this->helper_called() ; }
    void Foo::member_2(void) { helper_2(this) ; }
    

    My real problem here isn’t really the syntax (although I do get this niggly little feeling that there’s some problem waiting to happen with members being renamed or something). My concern is the proposal seems to be treating these declared-outside-the-class functions as “real” members when, really, I can’t think of a reason why they should be. All of the restrictions seem to be saying “No, these aren’t real member functions” — and, indeed, the role they’re trying to play is that of a locally declared functions to help split up a larger, “real” member functions — but then you mention inconsistent class definitions and I have no idea what’s going on anymore.

  11. November 26, 2012 at 11:05 pm

    The consistent class part was actually in response to the method you were describing. Lets go back to square one:

    class Protein
    {
    public:
      Protein(const char* const genome_) ;
    
    public:
      void Fold() ;
    
    private:
      void Weigh() ;
    
    private:
      std::string m_genome ;
      std::string m_symbol ;
      std::string m_name ;
      unsigned long long m_weight ;
      std::vector<Molecule> m_molecules ;
    };
    

    If Fold is going to be long, there are a few choices right now:

    1. Use lots of static non-member functions that take a lot of arguments.

    static bool checkNeighbors(std::string& genome,
      std::vector<Molecule>& molecules,
      size_t position,
      unsigned long long& weight
      )
    {
      ...
    }
    ...
    void Foo::Fold()
    {
      ...
      if ( !checkNeighbors(m_genome, m_molecules, position, m_weight) )
        ...
    }
    
    //// Instead of
    
    private bool Foo::checkNeighbors(size_t int)
    {
      ...
    }
    
    void Foo::Fold()
    {
      if ( !checkNeighbors(position) )
        ...
    }
    

    This is a pain in the ass. One minute you’re writing nice clean member function stuff and then suddenly you are hoisting your privates out into static functions.

    Issue: Breaks if you need to call a private member function like “Weigh” from them, though.

    2. Friend lots of statics.

    See above, only add friend definitions to “Protein” such that the functions can take a “Protein&” reference and access the stuff they need.

    This /can/ call private member functions, though.

    Issue: Header bloat and boilerplating

    3. Derive a private class that simply adds functions.

    Issue: You’d have to change your privates to protecteds, which allows someone else to come along and manipulate your class when using it as a library by deriving it themselves.

    4. Break it into member functions.

    Issue: Lots of header overhead.

    Issue: Writing the code in the context of the class is correct: it is class behavior.

    However, it is private. The API – the “class { };” definition does not need to expose it.

    It also needs access not just to private member data

    5. Pimpl.

    Issue: Messy, ultra messy. A whole extra class of definitions just so that I don’t have to define them where you can see them. It’s sole purpose as a pattern is to get around this problem. Plus it has to be exposed in the API as “Hey, I have secret stuff here”. And lastly, all that needless cross-referecing (pimpl->privateFunc23() and impl->m_privateMember etc).

    6. Just write big ass functions.

    Issue: Because you wind up repeating big chunks of code but don’t want to start having to add huge lists of private functions.

    The intent of this code is to let you extend the class with private member functions only, and in return for that forego the need to declare them in the class definition.

    Unfortunately, because C++ compiles unit-at-a-time, that imposes a variety of restrictions, unlike C#s “partial” class.

    You pitched two counter solutions:

    class namespace Foo {
    void public_func(Foo&) ; // Defaults to public.
    private void helper(Foo&) ; // Can access Foo’s members, but can also only be called by Foo.
    }
    

    And yes – this comes fairly close to what I’m proposing except, if you want to declare a single function this way you have all that messy boilerplate, and you’re making objects explicitly pass themselves which some people like but it is inconsistent with class behavior: when I have to pass my object to a function, in C++, that tells me “this is not a member function I am calling”.

    Secondly, allowing *public* extension of a class is a no-no – that’s a means to allow backdoor violation of encapsulation and access restriction.

    void foo_helper(Foo* this, int i) { … }
    Foo::func(int i) {
    this->foo_helper(i) ;
    }
    void external_func(Foo* f) {
    foo_helper(f, 0) ;
    }
    

    Aside from the word “this”, what you have is existing C/C++ code. So you’re suggesting that, if I write a function which takes “Typename* this” as the first argument, it gets member-level access to the innards of the class?

    Firstly, no. It’s not decorated as a member function. That means I can’t find it by searching on “Foo::”.

    Secondly, no. It’s not a member function except by some accidental trigger mechanism that’s going to be hard to learn about,.

    Thirdly, no. “this” is a reserved keyword, and giving it special meaning like this is confusing.

    Fourth, no: if you mean that a non-member function can call this code, because that’s backdooring.

    Alternatively,

    Fifth: no. You’ve introduced a gotcha into the language by making the choice of name you give to the first parameter affect the behavior of the entire function.

    void i_just_wanna_print_a_pointer(Foo* this, const char* label)
    {
      printf("%s: %p\n", label, this);
    }
    
    int main(int argc, char* argv[])
    {
      Foo* foo = new Foo;
      i_just_wanna_print_a_pointer(foo, "My Foo"); // COMPILER ERROR
    }
    

    You have to change the name of the first parameter from “this” otherwise only member functions of Foo can call it.

    Both of the above approaches are syntactic sugar. My approach attempts to adhere to the language design. “private” is already a class-related, access-control keyword that retains meaning here – this routine is going to behave like a private member of the class Foo. It uses C/C++s storage-class-and-scope decoration metaphor:

    <scope> <return type> <attributes> <function name> ( <parameters> ) <attributes> <codeblock | ;>

    private void Foo::dosomething()
    {
      // Members of Foo in this compilation unit can call me, nobody else can see me.
      // Non-member functions here can't call me, even if they are "friend" to the class.
    }
    

    In exchange for making itself accessible only to class-members within the current compilation unit, it (a) frees itself of the need for a class{} entry and (b) grants itself all the entitlements of a true member function, saving you from having to deref -> or . to get at stuff in it.

  12. Victarus
    November 27, 2012 at 12:22 pm

    Heh, actual face-to-face conversations are so much easier. :p

    A lot of the points you brought up are actually wrong, but since that’s probably because I communicated poorly and in the interest of avoiding a forum-style quote battle, let’s just move on. :p

    The ideas I threw out initially were a kind of quick bit I threw together to invoke some thought, not an end-all proposal I poured my heart and soul into. I saw some things about the proposal I didn’t agree with and put those out there as a quick-and-sloppy way to address them in the hope they’d help communicate my issues. Unfortunately they seemed to have just distracted from them instead, although given the fact you had to deal with the WWIIOL forumites for several years, I can certainly understand why. ;)

    What I was going for is that, in my mind, the proposal *is* nothing but syntactic sugar: The entire point is to add a way to get around “private” and maintain member semantics in helpers. There’s no new underlying concepts at work, no new functionality to address; just a loophole to add to the language while still maintaining a sound design.

    So, let’s try me just tweaking the proposal directly and see where it leads us. :)

    Functions declared as follows are called pseudo-members:

    // <scope> <return> <class>::<name> (<params>) <attrib> ;
    private void Foo::fake_member(int i) const ;
    

    Pseudo-members are normal functions that are called as though they were member functions. Within the function, there is a ‘this’ argument of the proper type, just like a normal member.

    With regards to their scope, pseudo-members are treated as actual members: Code must be able to call a private member to call a private pseudo-member, for example. In addition, a pseudo-member’s scope determines what parts of its class it can access: A private pseudo-member can access private members, but a public one cannot.

    For example:

    class Foo {
    public:
        void foo_pub(void) ;
    protected:
        void foo_prot(void) ;
    private:
        void foo_priv(void) ;
    } ;
    
    class Bar : public Bar {
    public:
        void bar_pub() ;
    private:
        void bar_priv() ;
    } ;
    
    //------
    // Functions
    
    public void Foo::pub_func(void) {
        this->foo_pub() ;  // Valid: 'Foo* this' param implied.
        foo_pub() ;        // Valid: Implicit use of 'this'.
    
        foo_priv() ;       // ERROR: Public cannot access private or protected.
    }
    
    protected void Foo::prot_func(void) {
        foo_prot() ;       // Valid: Protected calling protected.
        this->pub_func() ; // Valid: Using pseudo-member w/ appropriate scope.
    }
    
    private void Foo::priv_func(void) {
        ((Bar*)this)->bar_pub() ;  // Valid, albeit unsafe.
        
        ((Bar*)this)->bar_priv() ; // ERROR: Cannot access non-public except for 'Foo'.
    }
    
    
    //------
    
    
    void generic_func(Bar* b) {
        b->pub_func() ;  // Valid
        
        b->prot_func() ; // ERROR: Cannot access non-public 'member'
    }
    
    
    void Foo::foo_pub(void) {
        pub_func() ;  // Actual member function, so all are valid.
        prot_func() ;
        priv_func() ;
    }
    
    
    void Bar::bar_pub(void) {
        pub_func() ;
        prot_func() ;
        
        priv_func() ; // ERROR: Cannot access private (pseudo-) member.
    }
    

    Limit the above to private only and you have how I see your original proposal — which is why I took issue with the compilation unit bit since, in my mind, it didn’t seem necessary.

  13. Victarus
    November 27, 2012 at 12:35 pm

    Oh, and note that again I’m not actually the above as an end-all proposal (although it *might* actually be somewhat workable with a little more thought put into it). Really, it’s less of a proposal and more of a “This is where my mind is coming from when I say I don’t really like what you originally proposed”.

  14. December 1, 2012 at 12:28 am

    It’s been pretty hectic at work – I think the bulk of the problem in this here communication is my being bursty – responding to a glut of points in one post and – frankly – probably blending them a bit. So – let me try to avoid that this time,

    You said “a way to get around private”. Its the very opposite of that – it’s a way to make something even *more* “private” and take advantage of it’s implications.

  15. Victarus
    December 1, 2012 at 10:58 am

    My problem is that, while it’s perfectly fine conceptually and would make for a good “intro to newbies” description of the feature, it’s hard to treat it as a proper part of the language since C++ doesn’t care in the slightest about how coders lay out their files: Members could be in the header, in a different header, or in twenty different source files and, from a language perspective, it’s all good. Since the only thing that makes these functions proper “members” is that they’re in foo.cpp, which the language doesn’t care about, I view them more as stand-alone functions with member semantics.

    I guess as good a place to start as any is: In terms of actual usage, what’s the difference between the latest bit I put out there (the private part only, of course) and yours? Other than the different high-level concept I only see a few (in my mind unnecessary) restrictions being taken away, but maybe there’s something glaring I’m missing. :-)

  16. December 1, 2012 at 12:50 pm

    That’s why I wanted to split it up – the original proposal, as it stands, is exactly what you wound up proposing, unless I’m missing something, aside from the fact that you re-order the wording of part of the description:

    “Pseudo-members are normal functions that are called as though they were member functions. Within the function, there is a ‘this’ argument of the proper type, just like a normal member.
    With regards to their scope, pseudo-members are treated as actual members”

    In order to achieve that, and the implicit “this” behavior, you do actually have to add at least as many new mechanics as you do to achieve allowing the addition of a transitory member.

    I also don’t see how you lose /any/ of the restrictions aside from the operator restriction, which causes a major problem with your variant:

    // Foo.h
    #include <iostream>
    #include <string>
    
    template<typename T_>
    class Foo {
    public:
      Foo(const std::string& account_) : m_account(account_) {}
      ~Foo() { cout << "~Foo(" << m_account.c_str() << ", " << m_balance << ")" std::endl;
      void Deposit(T_ amount);
      void Withdraw(T_ amount)
      {
        if ( amount < m_balance)
        {
          m_balance -= amount;
          ATMGiveCash(amount);
        }
        else
          throw OhNoYouDont(m_account, amount, m_balance);
      }
    
    private:
      std::string m_account;
      T_ m_balance;
       void ATMGiveCash(T_ amount); // Output the money.
    };
    

    My variant doesn’t allow for any interference or injection because it prohibits name collisions and operators. Your variant, however, lets a 3rd party do this:

    // Foo3.h
    #include "Foo.h"
    
    private template<typename T_> T_ void Foo::operator-(T_ amount)
    {
      // Keep your money, friend.
      return amount;
    }
    

    Now – do these two pieces of code behave the same?

    #include "Foo.h"
    
    Foo<double> myAccount(1000.0);
    
    void withdrawBenjamin() {
      myAccount.Withdraw(100);
    }
    
    #include "Foo3.h"
    
    Foo<double> myAccount(1000.0);
    
    void withdrawBenjamin() {
      myAccount.Withdraw(100);
    }
    

    Operators *have* to go in the class header itself.

    This is why I’m starting with the concept of allowing you to define a private class member outside of the class, and then simply securing it with a couple of extra restrictions – i.e. no name conflicts (avoids any issues with templates) and no operators (avoids all kinds of crazy issues that could arise from an inconsistent class definition between files).

    The rest of the restrictions I described are inherent in being a private class member.

    So you’re right – the proposal you came to is very similar to mine, I just think you need to go the step further and start with the notion of “things that ought to be made a private member function often aren’t because it’s a pain in the ass to have to clutter up the class definition with lots of little *private* functions that are only ever going to be used from one compilation unit (most of the time), or because you don’t want to expose some of the ultra-private details of implementation in 3rd party headers, and you don’t want the headache of Pimpl or the boilerplating of deriving a class just for the sake of hiding functions – which you still,have to decorate the second class definition with, and because using static member functions means all kinds of hoisting that means class-innard work is now being done in functions that don’t properly declare their genuine and honest intent to do the internal work of a class”.

    Note also that the “compilation unit” stipulation is fairly standard: it doesn’t mean “they can ONLY exist in one file” it means that as far as the compiler is concerned, they do only exist in one file and can’t conflict with a global name – i.e. you can’t override “Foo::withdraw” with a local private variant. But that doesn’t mean you can’t put one into a header file to privately declare it across multiple compilation units.

  17. Victarus
    December 1, 2012 at 3:21 pm

    “Your variant, however, lets a 3rd party do this:”

    So does the current language:

    // Foo.hpp
    template <typename T>
    class Foo {
        // ...
    } ;
    
    // Messin_with_foo.hpp
    template <typename T>
    T operator - (const Foo<T>& lhs, const T& rhs) {
        return rhs ;
    }
    
    // main.cpp
    int main(int argc, char* argv[]) {
        Foo<int> foo ;
        int i = 42 ;
    
        i = foo - i ;
    
        return i ;
    }
    

    “Now – do these two pieces of code behave the same?”
    Yes: ‘foo – t’ is never invoked in the first place. :-p

    I think you meant something more like this:

    // Foo.hpp
    class Foo {
    public:
        void func(void) ;
    } ;
    
    // Foo.cpp
    
    // Oops! Forgot to put this in an anonymous namespace!
    private void Foo::internal_logic(void) {}
    
    void Foo::func(void) { internal_logic() ; }
    
    
    // main.cpp
    private void Foo::internal_logic(void) {
        // Evil code here! Bwa ha ha!
    }
    
    int main(int argc, char* argv[]) {
        Foo foo ;
        foo.func() ;
    }
    

    Of course, if you drop the ‘private’ and ‘Foo::’ and compile it now, you end up with “ERROR: multiple definition of `internal_logic()'”.

    Likewise, any sort of “breaking” by new declarations the private code can’t see don’t do anything either:

    // Foo.hpp
    class Foo {
    public:
        void func(void) ;
    } ;
    
    // Foo.cpp
    
    void do_something(double) {}
    
    
    void Foo::func(void) {
        int i = 0 ;
        do_something(i) ;
    }
    
    // main.cpp
    void do_something(int) {
        // Ha! A closer match!
        // ...that the calling code has no idea exists,
        // so it's never called anyway.
    }
    
    
    int main(int argc, char* argv[]) {
        Foo foo ;
        foo.func() ;
    }
    

    Granted people could mess with a class’ internals from a header your class includes (as they could now with a macro or the like), but at that point I don’t think the language is really the problem anymore.

  18. December 1, 2012 at 9:15 pm

    “Yes: ‘foo – t’ is never invoked in the first place. :-p”

    Muahaha, good catch :)

  19. December 1, 2012 at 9:45 pm

    “So does the current language”

    Actually, it doesn’t – the operator in your example isn’t a member and therefore it can’t tamper with the innards of Foo.

    For the “is this what you mean’t” example, no – not quite. I was highlighting the template case where the class is evaluated at instantiation, so operators would be the one case where local, internal behavior can be overidden. It could be an example of why you would want to conflict names rather than fingerprints – since that would curtail any attempt to produce closer matches.

    Again: The goal is to let you write code that is and should-be written as member code as member code without having to annotate it in the class header. That means it needs to be compilation-unit scoped otherwise you need to implement an infrastructure for allowing object files to modify class definitions.

    // Foo.h
    class Foo { ... };
    
    // Foo.cpp
    Foo foo;
    
    // Foo1.cpp
    private void Foo::func1() { ... }
    
    // Foo2.cpp
    private void Foo::func2() { func1(); }
    

    There’s no way for this to be legal at the obejct-file/linker level because the “Foo” in Foo1.cpp is different than the Foo in Foo.cpp and the foo in Foo2.cpp.

    That doesn’t mean you can’t do

    // Foo.h
    class Foo { public: ... memberFunc();... };
    
    // FooPrivate.h
    class Foo { ... };
    private void Foo::Fart() { output(Foo::Volume::Loudly); }
    private void Foo::SBD() { output(Foo::Volume::Silent); abort(room); }
    
    // FooX.cpp
    Foo::memberFunc() {
      if ( room->isEmpty() ) {
        fart();
      } else {
        SBD();
      }
    }
    

    At the end of the day – ultimately the difference between my proposal and the one you’d arrived at is the pitch. You’re pitching it from the floor down (here’s a way we could write static functions that get promoted to a class-member like status) and I’m pitching it from a class-encapsulation perspective (lets stop encouraging people to move class code out of class members because they don’t want to put private-private stuff in headers, so they prefer to use a non-class function because it means less boiler plate).

    Swings and roundabouts. If you don’t want the restrictions I described, then you use a proper fully legitimate class member function. But for the cost of a few simple restrictions, you gain the ability to write member functions which aren’t exposed in the public API – and thus don’t count towards class bloat or any other similar concerns – and which aren’t exposed in the .obj file so – no amount of shenanigans will allow user-developers (and I’m not necessarily talking about security here, I mean the guy down the hall who will write his code differently if he thinks he knows you’re using a hash vs an unordered hash, etc).

  20. Victarus
    December 2, 2012 at 11:40 am

    “Actually, it doesn’t – the operator in your example isn’t a member and therefore it can’t tamper with the innards of Foo.”
    Well it also can’t be accessed outside of Foo either, which is why I thought the problem was the operator overloading itself. Sorry about that. :-)

    “At the end of the day – ultimately the difference between my proposal and the one you’d arrived at is the pitch.”
    Actually, I think the real difference is this:
    “That means it needs to be compilation-unit scoped otherwise you need to implement an infrastructure for allowing object files to modify class definitions.”

    I attached “pseudo-” for a reason: I simply don’t view these new functions as “real” members. Something about it just seems like a nightmare waiting to happen, and maybe more rules-lawyery people could clarify if this actually is the case or not.

    Me, I see no difference between this:

    // Foo1.cpp
    private void Foo::func1() { ... }
    
    // Foo2.cpp
    private void Foo::func2() { func1(); } // ERROR
    

    …this…

    // Foo1.cpp
    private void func1() { ... }
    
    // Foo2.cpp
    private void func2() { func1(); } // ERROR
    

    …or this:

    // Foo.cpp
    private void Foo::func2() { func1(); } // ERROR
    private void Foo::func1() { ... }
    

    In my mind, the problem isn’t the class definition is different; the problem is it’s trying to call a function that hasn’t been declared in that scope. If that *isn’t* the actual problem, then I’m afraid I don’t yet understand understand the justification for it.

    Although I worry it will devolve this into quote wars again, here are some examples of why I think the way I do on this:

    void func1(int) {}
    
    void Foo::member1(void) {
        func1(5) ;
    }
    
    
    private void Foo::func1(double) { ... }
    
    void Foo:: member2(void) {
        func1(5) ;
    }
    

    Based on the current standard (albeit extending it a bit for the new functionality), member1 calls the global func1, member2 calls the “member” func1. The “better overload” doesn’t matter: Real members come first if possible.

    I’m guessing the naming restrictions were a way to work around possible problems with the above (and, I’ll admit, it can be a little confusing if the code is a mess), but I don’t think they actually solve the problem:

    namespace Bar {
        void func(void) {}
    }
    
    private void Foo::func(void) {}
    
    void Foo::member1(void) {
        func() ; // Yay! Clear and unambiguous.
    }
    
    void Foo::member2(void) {
        using namespace Bar ;
        func() ; // ???
    }
    

    (Actually, working off the current standard it’s unambiguous — the member takes precedent — but that’s kind of my point.)

    // Foo.hpp
    class Foo { ... } ;
    private void Foo::func(void) ; // ???
    
    // Foo1.cpp
    private void Foo::func(void) { ... }
    
    // Foo2.cpp
    private void Foo::func(void) { ... }
    

    Is “func” different in Foo1 vs Foo2? Does this mean added members can’t be prototyped? Or are they calling different foos, as though an anonymous namespace was added in the header?

    Ugh, my brain kind of started to shut down as a wrote this. :-p

    Anyway, I’m not saying the proposal isn’t workable, mind you. I just think the best way to improve something is to pick it apart and put it back together again. :-)

  21. December 2, 2012 at 11:21 pm

    When I say that they can’t conflict by name – I didn’t mean “they can’t have the same name as any function anywhere else” – I mean’t that they can’t share a name with something defined formally in the class – the purpose is purely to avoid the template scenario – you can’t trick the compiler into finding your freshly-minted local function a closer match than something made more ambiguous by careful tailoring of template parameters.

    But that’s an edge case.

    Again: It seems our main point of disagreement is on whether these are local functions being promoted or member code being slightly demoted.

    I’m primarily trying to deal with the situation where people write stupidly large member functions and duplicate code because they, rightly, do not want to move the functionality of a class out into non-member functions.

    Their reasoning is bolstered by the fact that doing it requires copious amounts of bloat of the exact kind C++ originally was intended to reduce: mass parameter marshaling and passing (why are you taking it out of the struct that it calls home?), prototyping, etc.

    On the other hand, splitting function2000 into 50 little functions makes for messy “prototype classes”.

    Reality is, there’s no such thing as a member function at the object-file level, they’re just functions with weird names. What matters is at the compiler level.

    Restrictions aside, what I’ve understood of your proposal is the same thing, just phrased as “bread without a whole lot of butter” rather than my “half buttered bread” :)

    Using the pre-existing concept of a private member function actually deals with most of the potential complications for you, that’s why I chose that approach rather than a method for promoting non-member functions to near-member status – stuff like, only member functions can access it are completely intuitive for a function that is marked and decorated as a private member function, because that’s how they behave.

    If the functionality needs to be exposed for use by non-member stuff, then it needs to be moved out of the class or placed in the class definition?

    Beyond that, it’s all about localizing definitions to where they are actually needed so that it’s easier to break big member routines up without violating the tenets of encapsulation by putting code that is inherently part of a class in a container that is explicitly not part of the class.

    class Foo {
    public:
      Foo();
      void DoComplexWork();
      /* ... */
    };
    
    void Foo::DoComplexWork() {
      m_state.Lock();
      bool isRunning = m_isRunning;
      m_state.Release();
    
      if ( isRunning == false )
        return;
    
      for ( ; ; )
      {
        Task* task = NULL;
        m_state.Lock();
        if ( m_tasks.empty() != NULL )
          task = m_tasks.pop_front();
        m_state.Release();
        if ( task == NULL )
          break;
    
        task->Run();
      }
    }
    

    The bug above is intended – this is actually a paraphrase of some open source code I was looking at 2 weeks ago.

    What they SHOULD do, with current C++, is this:

    class Foo {
    public:
      Foo();
      void DoComplexWork();
    
    private:
      bool IsRunning();
      Task* GetNextTask();
    };
    
    bool Foo::IsRunning() {
      ScopedLock lock(m_state);
      return m_isRunning;
    }
    
    Task* Foo::GetNextTask() {
      ScopedLock lock(m_work);
      return ( m_tasks.empty() == false ) ? m_tasks.pop_front() : NULL;
    }
    
    void Foo::DoComplexWork() {
      while ( IsRunning() ) {
        Task* task = GetNextTask();
         if ( task == NULL )
           return;
         task->Run();
      }
    }
    

    With a private-member proposal they could do this:

    class Foo {
    public:
      Foo();
      void DoComplexWork();
    };
    
    private bool Foo::IsRunning() {
      ScopedLock lock(m_state);
      return m_isRunning;
    }
    
    private Task* Foo::GetNextTask() {
      ScopedLock lock(m_work);
      return ( m_tasks.empty() == false ) ? m_tasks.pop_front() : NULL;
    }
    
    void Foo::DoComplexWork() {
      while ( IsRunning() ) {
        Task* task = GetNextTask();
         if ( task == NULL )
           return;
         task->Run();
      }
    }
    

    Using non-members with current C++, they’d have to do this, which I personally feel is breaking the spirit and intent of encapsulation:

    class Foo {
    public:
      Foo();
      void DoComplexWork();
    };
    
    static bool IsRunning(FoosMutexT& stateMutex) {
      ScopedLock lock(stateMutex);
      return m_isRunning;
    }
    
    static Task* GetNextTask(FoosMutexT& workMutex, FoosTaskQueT& taskQueue) {
      ScopedLock lock(workMutex);
      return ( taskQueue.empty() == false ) ? taskQueue.pop_front() : NULL;
    }
    
    void Foo::DoComplexWork() {
      while ( IsRunning() ) {
        Task* task = GetNextTask();
         if ( task == NULL )
           return;
         task->Run();
      }
    }
    

    With your proposal, it would look like this, but I don’t like the fact that you’re representing class affiliation through an argument rather than thru the tried-and-true class::member designation:

    class Foo {
    public:
      Foo();
      void DoComplexWork();
    };
    
    bool IsRunning(Foo* this) {
      ScopedLock lock(m_state);
      return m_isRunning;
    }
    
    Task* GetNextTask(Foo* this) {
      ScopedLock lock(m_work);
      return ( m_tasks.empty() == false ) ? m_tasks.pop_front() : NULL;
    }
    
    void Foo::DoComplexWork() {
      while ( IsRunning() ) {
        Task* task = GetNextTask();
         if ( task == NULL )
           return;
         task->Run();
      }
    }
    

    If I’ve understood correctly – then, a point of note – at a very low level, this is how C++ member functions are actually implemented by some compilers. But, the syntax is one of the things that gnarls at me about Python/Lua/etc.

    Foo::member(Task*) gets mangled to Foo____member____Rvoid____1ATask(Foo*, Task*) or something :)

    But conversely, the compiler then has to go thru and do all the work to promote what was previously not a member function into behaving as and being perceived as a member function throughout the rest of the code. For example, consider if you do the following:

    class Foo { ... };
    
    Task* GetWork(Foo*, TaskQueue&*); // Valid prototype.
    
    void Foo::DoWork() {
      while ( (Task* task = GetWork(this, m_workQueue)) ) { // Looks legit.
        task->Run();
      }
    }
    
    Task* GetWork(Foo* this, TaskQueue& queue) { // Oops.
    }
    

    Now – this is not moses-coming-down-the-mountain-throwing-down-the-commandments terrible, it’s a discussion point: what should the error be here: is the prototype at fault, is the invocation of GetWork wrong or does it need some carefully crafted exception to allow it without breaking lots of existing code, or should the implementation of GetWork generate an error telling you that the implementation conflicts with the prototype.

    I suspect the latter and dislike it because then it’s a side-effect difference:

    // These...
    Task* GetWork(Foo*, TaskQueue&);
    Task* GetWork(Foo* This, TaskQueue&);
    // Are different than...
    Task* GetWork(Foo* this, TaskQueue&);
    // I'd rather say exactly what I mean: Treat this as a member:
    // And not have to make its argument list be an exercise in hoisting
    // private class innards into registers.
    private Task* Foo::GetWork();
    
  22. December 2, 2012 at 11:25 pm

    BTW – your tripple-func example: Actually, yes they can be prototyped; the thing about putting them outside of the class and making them work like C-static functions is that their fingerprints don’t get written to the object files – ergo, if you don’t implement them, no harm no foul, if you do, they are discrete to that compilation unit (object file).

    “Ugh, my brain kind of started to shut down as a wrote this. :-p”

    I think I was kind of the same way :)

    “Anyway, I’m not saying the proposal isn’t workable, mind you. I just think the best way to improve something is to pick it apart and put it back together again. :-)”

    Agreed, and I’m actually very glad of the chance to engage in debate on this – I hope I’m fully qualifying matters of my opinion so that it doesn’t seem like I’m just arguing for the sake of it. As I said early on – I think there is some subtle nuance of difference between the two versions of the concept, and I’m missing one – to me, that makes me caveman failreader :)

  23. Victarus
    December 3, 2012 at 5:21 pm

    Actually, I had kind of gotten away from throwing in “this” as an argument since comment #12: While using ‘Foo::’ to define something outside of Foo’s original declaration still irks me, I will admit that it’s at least pretty clear as to what exactly it’s doing. :-)

    Basically, at this point the big difference is where we both start and, consequentially, where we go afterward once we’re past the most common usage scenario. Since I hate littering headers with garbage but still can’t stand overly long functions, I’ve always tended to split up members into anonymous local functions (although they’re *usually* a little better than the ones you gave as examples above). Since that’s where I come from, I’ve been viewing this as a bit of syntactic sugar around the functions I’d normally write instead of defining a “proper” member.

    This is just a guess, but I’m assuming you’ve preferred the private member route since, like you mentioned, splitting functionality off can often feel like there’s some encapsulation being leaked. As a result, you’re treating this mostly as a way to work around declaring private members in the header instead of just moving code from function A to new function B.

    Because of this, we both agree that the most common case should look like this:

    class Foo {
    public:
        void do_stuff(int) ;
    } ;
    
    //------
    
    private void Foo::really_do_stuff(int) { ... }
    void Foo::do_stuff(int i) { really_do_stuff(i) ; }
    

    But we stare in disbelief at each other when things like the following come up:

    // foo.hpp
    class Foo {
    public:
        void do_stuff(int) ;
        void do_other_stuff(int) ;
    } ;
    
    
    // foo_helpers.hpp
    private void ensure_is_valid(void) const ;
    
    
    // foo_stuff.cpp
    ...
    private void Foo::ensure_is_valid(void) const { ... }
    
    void Foo::do_stuff(void) {
        ensure_is_valid() ;
        ....
    }
    
    
    // foo_other_stuff.cpp
     ...
    
    // #1
    private void Foo::do_stuff(string s) {
        // Often need to get 'i' from string below, but
        // not often enough to figure out val if not needed
        // and want to keep the function itself looking clean.
        int i = ... ;
        do_stuff(i) ;
    }
    
    void Foo::do_other_stuff(void) {
        ensure_is_valid() ; // #2
        ....
    }
    

    Both of our versions handle both cases, but we do it very differently because we started at different places. You outright ban #1 for fear of another header overriding expected private behavior and treat #2 as a linking error since you restricted these new functions to one compilation unit for the same reason (I think? I’m still not entirely sure on the justification for that, now that I think about it). I, on the other hand, say “Just handle it like any other function”: #1 is an overload, #2 calls the function that was defined in the first file.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 217 other followers

%d bloggers like this: