No problem , I leave the obsoleted c++ bit for someone else who knows c++ , its been there for 8 years , it can wait :) . I'll put a note in the manual about which functions are being obsoleted , and in 10 years time we can delete them , set those alarm clocks now ;)
Now I've got those easy changes done , a slightly more controversial change! I'm tempted to remove some of the assembler code for the untested and old architectures. This is NOT removing support for this architecture , but changing it from something where we don't know if it works or still works , to plain C , where surely it must work. If we ever get access to these old systems again , we can then test the assembler code and reinstate it. Jason On Wednesday 12 August 2009 21:49:47 Bill Hart wrote: > Me too. If Sage can manage, clean away. I do think it is important to > retain all functions which appear in the documented GMP interface, as > we said we would. But anything deprecated for some time, can go. K&R > stuff screws up my autotools, so clean away there. > > Bill. > > 2009/8/12 Jason Martin <[email protected]>: > >> On Aug 12, 5:21 pm, jason <[email protected]> wrote: > >>> There is also the ansi to K&R conversion , no-one uses a K&R C > >>> compiler nowadays ? , I never have and I starting using C in 94(16bit > >>> DOS...yuck) , I propose we remove it . > >>> > >>> As only William has responded so far to this thread , I assume > >>> everyone else either doesn't care or agrees with me :) Hooray :) , or > >>> at least doesn't care enough to email. :) > > > > I tend to agree with you! Clean away!! > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
