e38b99f7
From: grahn+nntp@snipabacken.se
On Tue, 2011-12-27, Ebenezer wrote:
> On Dec 24, 4:07 pm, Dave Abrahams wrote:
>> on Fri Dec 23 2011, Gene Bushuyev wrote:
>>
>>> I also found that automatic code generation can often be a better
>>> alternative to complicated macros.
>>
>> My experience writing Boost.Python led me to the opposite conclusion. I
>> started out with some Python scripts to generate the overload sets I
>> needed, and eventually replaced them with the use of Boost.Preprocessor
>> metaprogramming because:
>>
>> 1. Before the change, my users couldn't figure out how to run the
>> scripts when they needed to extend the number of arguments supported
>> by the library, whereas afterward all they needed was
>> -DBOOST_PYTHON_MAX_ARITY=25 on their command line.
>
> Perhaps you should have made your code generator an on line
> code generator. (That doesn't imply it is proprietary -- if
> you want you could still make the source code avaialable.)
> That way people wouldn't have had to deal with the scripts.
Personally, I would never use such a (hypothetical) service. It just
raises too many issues:
- Is the service up when someone needs to compile my code?
- Does the person who needs to compile my code have internet access?
- Is the service up, on the same host, ten years from now?
- Has the code generator been modified since last time I compiled?
- Has the code generator been compromised by an attacker?
- Are man-in-the-middle attacks possible?
- Do I want Mr Abrahams to know who compiles my code when?
- Do I want Mr Abrahams to see my code?
- ...
It's offtopic, but I feel obligated to point it out (the security
and privacy implications, at least).
/Jorgen
--
// Jorgen Grahn O o .
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
