title: Is it always evil to have a struct with methods?
body: <p>I've just been browsing and spotted the following...</p>
  
  <p><a href="https://stackoverflow.com/questions/54585/when-should-you-use-a-class-vs-a-struct-in-c">When should you use a class vs a struct in C++?</a></p>
  
  <p>The consensus there is that, by convention, you should only use struct for POD, no methods, etc.</p>
  
  <p>I've always felt that some types were naturally structs rather than classes, yet could still have a few helper functions as members. The struct should still be POD by most of the usual rules - in particular it must be safe to copy using memcpy. It <em>must</em> have all member data public. But it still makes sense to me to have helper functions as members. I wouldn't even necessarily object to a private method, though I don't recall ever doing this myself. And although it breaks the normal POD rules, I wouldn't object to a struct having constructors, provided they were just initialise-a-few-fields constructors (overriding assignment or destructors would definitely be against the rules).</p>
  
  <p>To me a struct is intuitively a collection of fields - a data structure node or whatever - whereas a class is an abstraction. The logical place to put the helper functions for your collection-of-fields may well be within the struct.</p>
  
  <p>I even <em>think</em> I once read some advice along these lines, though I don't remember where.</p>
  
  <p>Is this against accepted best practice?</p>
  
  <p><strong>EDIT</strong> - POD (Plain Old Data) is misrepresented by this question. In particular, a struct can be non-POD purely because a member is non-POD - e.g. an aggregate with a member of type std::string. That aggregate must not be copied with memcpy. In case of confusion, see <a href="https://stackoverflow.com/questions/146452/what-are-pod-types-in-c">here</a>.</p>