Hi Vasek, Hi all,<br><br>although your technical proposition is funny, I am not sure it makes a serious difference and a big advantage compared to simple getter/setter function calling.<br>Moreover, I am not sure that this code will be really used widely. So the user can call methods instead of using variable assignation.<br>

<br>Regards,<br><br>Emilien<br><br>PS: Sure your example/way is very interesting for C++ theory and exercises ;)<br><div class="gmail_extra"><br><br><div class="gmail_quote">2012/12/4  <span dir="ltr"><<a href="mailto:VaclavKrpec@eaton.com" target="_blank">VaclavKrpec@eaton.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello fellow developers,<br>
<br>
yesterday, I was thinking about how to implement specific config.<br>
attributes accessors in section-based nut config. files so that<br>
it's nice to use and consistent with NutConfiguration, UpsmonConfiguration<br>
and UpsdConfiguration config. classes (where it's done via Settable attributes).<br>
<br>
The GenericConfiguration class provides generic access to name/value<br>
items of config. sections. The specialised classes (like e.g. UpsConfiguration)<br>
shall inherit the mechanism from GenericConfiguration and are supposed to<br>
provide specialised (and typed) access to the config. attributes.<br>
Now, the obvious choice is to write getters/setters for them; however,<br>
this way, the access will be different than access to section-less config.<br>
files attributes.<br>
What I came with is a template class (see "redirect" in the sample code attached)<br>
that overloads the cast operator and the assignment operator (and possibly others)<br>
and therefore gives the user the possibility to execute code (the getters/setters)<br>
while the code looks just like r/w access to a variable (with certain restrictions, though).<br>
<br>
Now, the mechanism looks kind of cool, but is also a bit technically complex,<br>
not to mention that it's disputable whether such masking of code execution<br>
is a good idea.  I can imagine that it can be quite confusing for an outsider...<br>
So, do you think that it's worth it or should I better keep the code less "smart"<br>
but more simple (now, when I'm writing that, it seems to answer itself...)?<br>
<br>
Thanks for the consult,<br>
<br>
Regards,<br>
<br>
--<br>
Václav Krpec<br>
Network UPS Tools project<br>
Eaton Opensource Team<br>
<br></blockquote></div></div>