🚀 go-pugleaf

I'll summarize the responses to date, because already the
pattern is clear.

First, there's definitely a problem: there are more recompilations than 
are logically necessary, far more than we'd like.  Although user's 
source code is protected from changes in implementation, user's binary 
code is not.

Second, there's not much point to my proposed "reopening" solution, 
which was clearly submitted without enough consideration.  My apologies.

Third, there are already several solutions becoming visible (SOM and
IDE handles everything ).  This can cause trouble not too far down the
road.  So we can hope that the question will be taken up by the 
standards effort.

Continuing -- what should be the design objectives?  I suggest one :
don't depend on an IDE or repository.  Many implementations don't have 
them available.  Why put up more barriers to entry?  

A second suggestion: easy conversion of code to the (probably more 
efficient) closely linked version.

--
rp




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]