On 8/22/2014 9:43 AM, Niall Douglas wrote:
On 22 Aug 2014 at 9:21, Edward Diener wrote:
OTOH if you choose to clone the library in your modularboost/libs/vmd the top-level index.html link should work perfectly.
That involves more work than I wish to do right now. Right now I merely wish to find out if I could contribute a meaningful review.
The library is on Github and I am following the modular-boost format so I do not know what else I can do to make it easy for others to use and review the library. I do not think that asking reviewers to clone a library and follow instructions in a readme file in order to use it, is asking an awful lot of reviewers.
Equally you want us to give you our time for free to look at your stuff. Some would say that putting the documentation onto its own website - like every other library in the review queue does by the way - isn't asking much of you. For you it's literally a git push to github pages and it saves all of us the hassle of cloning your repo and patching it into boost just to see if it's interesting at all to us.
How do you want me to present the documentation ? As a separate github project by itself, or as a separate branch of the VMD project ? I am willing to do either of those things. I was not aware that every other library puts its documentation on its own website outside of GitHub. In that case it seems to me that it should have been a requirement of submitting a library to Boost or at least strongly suggested somewhere.
However from what I read I ask this: why is this library useful?
The introduction explains in general the functionality in the library that would make it useful. Did you read the introduction ?
Yes. I get what it does. Not why would anyone need this.
It is a library for writing C++ macros, like Boost PP. If you do not see any use for Boost PP then naturally you would not see any use for the VMD library.
I see a use for Boost PP in interfaces, mainly to emulate variadic templates in 03. With C++ 11 I see little use for Boost PP in interfaces, but I can see it might be handy to have occasionally in internal source code away from public interfaces.
I struggle to see how variadic macros add to Boost PP in such a limited use case. This is the source of my difficulty.
The Boost TTI library ( I am the developer ) uses variadic macros in order to pass, among other things the name of the element to be introspected. Many other libraries use macros, and some variadic macros, as part of its interface. In my tests using Boost PP, since I work on fixes to it, there are about 45 other libraries that use Boost PP. There are a number of Boost libraries that use variadic macros in advanced cases. There are probably many end-users out there using variadic macros in their own programming. I can understand that your focus is on C++11/C++14. It is pretty exciting as far as the things that can be done within the C++ language itself. But macro preprocessor programming still hold my interest obviously.
The answer is no, but to enter Boost yes. It's very hard for me or I suspect anyone to vote on this if I have no idea what it's useful for. Otherwise someone could submit a randomly generated library and claim it should enter Boost, and we couldn't refuse.
I can't make you see any use for the library other than writing the documentation to explain how it is used and what it offers for macro creation.
It is you who wants the library to enter Boost. It is therefore you and only you who must argue in favour. We default to a reject answer, it is you who must persuade beyond a reasonable doubt to not reject.
I am not a politician and can only persuade based on my technical work and explanation of it.
I get this is all very clever. And if this library were being proposed for a suite of C libraries, I'd be all over this like no tomorrow.
The macro preprocessor is just as much a part of C++ as of C. If you mean that you think that C++ has such advanced facilities over C ( to which I generally agree ) that it makes macro programming obsolete ( to which I do not agree ) then VMD has no use for you.
I don't get how this is useful, or wise for C++ however. If you can show me something it can do which is a pain point for many which cannot be achieved using C++ 14, you get my vote. Otherwise I don't see the use case given the much superior alternatives.
I do not know what the superior alternatives of C++ 14 are which you see.
Neither do I. I think it is up to you as the presenter of the library to tell me why your library is useful to me. I'm not going to decide if it's useful to me on my own. I don't have the time. I suspect neither do most people here.
The documentation explains its usefulness in macro programming.
I can only guess that you do not feel that the creation of macros as part of the interface to a library should ever be necessary. But for a number of Boost libraries they still are, and for future libraries they still will be until C++ has built-in support for things which the macro prerprocessor can still do.
I think this is evading the question. You are equivocating here Edward.
I am not equivocating. You are asking a general question and I am giving you an answer as best I can. I do understand that you may be criticizing the documentation for not presenting a strong enough use case for the functionality of the library, as part of the introduction/overview in the beginning of the documentation, and I will strongly take that criticism into account and look to update the documentation based on it.
For reference, I do believe that in C++ 14 code there has to be a high bar set on the use of macros in public interfaces, especially as C++ 17 Modules will deprecate that. For that reason, macros in interfaces is a bad idea.
I do not understand the link between C++ 17 Modules and macro programming.
But I'm giving you out here Edward: give me a use case where your library solves a hard problem for others which C++ 14 cannot and you get my yes vote because I trust you to have made a good technical solution, my problem is in why it is useful. I don't think I am being unreasonable or unfair here, if your library is useful we need to see proof.
I do not want an "out" because you trust I have made a good technical solution. I only want for anyone, including yourself, to determine whether they find the library useful enough, and as an extension to Boost PP functionality when doing macro programming, to decide whether or not it should be a Boost library, just as Boost PP is a Boost library. If I have not made the point well enough of what other functionality VMD adds to macro programming on top of what is in Boost PP I am perfectly willing to update the eventual documentation. But I need particulars of what is not understood or what seems poorly documented.
I equally don't mind if anybody else chimes in here with a concrete example of where this variadic macro library solved a real problem for them. I assume that if this library got a review manager, it must have solved something for somebody somewhere. Equally, if no one chimes in, I must assume that this library has not met the popularity test and therefore has not been suffiiciently tested in real world use. And that would affect my vote for obvious reasons.