I've found a few methods online on how to implement property-like functionality in c++. There seems to be some sound work-arounds for getting it to work well.
My question is, with the prevalence of properties in managed langues, should I spend the effort and the possibilty of code-breakage (or whatever) to implement properties in my code?
Say I'm going to dev up a library of calls for someone else to use, would properties be desired enough to validate the extra code?
What can you gain from doing this that you can't get from just using accessor functions? It seems to me that while coding you ought to play to a language's strengths instead of getting it to emulate another language. So I'd vote no on this one. However, if you are writing in MANAGED C++ and are going to be using this code to interface with C# on a regular basis, and if for some reason you wanted to make the backend more usable by a native C# programmer, it might be worthwhile.
Properties actually prevent code breakage if done properly. It allows you to change the implementation of the property underneath without the caller having to change his code or even worry about it.
For instance, say you have a Socket class that takes a socket number. Implement as a property to just take an int and store it.
However your boss says that you should not accept socket numbers lower than 1024. Your property can change to scan for that and not accept the value.
No change to caller code.
Edit: A slight mis-understanding of the question...I took properties to mean normal accessor functions.
Unless you add reflection to the mix (being able to identify at runtime what properties exist on an object), properties are nothing more than syntactic sugar for getters and setters. Might as well just use getters and setters, in that case.
Properties with reflection can indeed be useful for C++ programs, though. Qt handles this quite nicely.
Properties are not idiomatic Standard C++ - as evidenced by the fact that there's no single "property-like" library in widespread use. The complexity of properly implementing them in conformant C++ is significant, while the benefits compared to direct invocation of accessor methods are small, and mostly stylistic. In my opinion, it's not worth the bother.
I have once tried to implement something similar to Matlab structures in C++, i. e. structures to which one can add named fields. After that I became a firm believer in the "Do Not Fight the Language" principle.
Efforts to make one programming language behave like another are often a special case of the inner platform effect.
I agree with others - just use getters and setters.
If you really need properties in C++, perhaps you already have them as a language extension. I think Visual C++ does - almost certainly for managed C++, but maybe for unmanaged too. Personally, the only reason I'd use them is in managed C++ to fit with .NET conventions.
Outside of that, creating an inner platform for this will almost certainly cause more problems than it solves.