{"action":"created","issue":{"url":"https://api.github.com/repos/pfultz2/Fit/issues/126","repository_url":"https://api.github.com/repos/pfultz2/Fit","labels_url":"https://api.github.com/repos/pfultz2/Fit/issues/126/labels{/name}","comments_url":"https://api.github.com/repos/pfultz2/Fit/issues/126/comments","events_url":"https://api.github.com/repos/pfultz2/Fit/issues/126/events","html_url":"https://github.com/pfultz2/Fit/issues/126","id":138743012,"number":126,"title":"Question: Why do you use MACROS for intrinsics?","user":{"login":"viboes","id":721225,"avatar_url":"https://avatars.githubusercontent.com/u/721225?v=3","gravatar_id":"","url":"https://api.github.com/users/viboes","html_url":"https://github.com/viboes","followers_url":"https://api.github.com/users/viboes/followers","following_url":"https://api.github.com/users/viboes/following{/other_user}","gists_url":"https://api.github.com/users/viboes/gists{/gist_id}","starred_url":"https://api.github.com/users/viboes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/viboes/subscriptions","organizations_url":"https://api.github.com/users/viboes/orgs","repos_url":"https://api.github.com/users/viboes/repos","events_url":"https://api.github.com/users/viboes/events{/privacy}","received_events_url":"https://api.github.com/users/viboes/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/pfultz2/Fit/labels/invalid","name":"invalid","color":"e6e6e6"},{"url":"https://api.github.com/repos/pfultz2/Fit/labels/question","name":"question","color":"cc317c"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":19,"created_at":"2016-03-06T01:42:51Z","updated_at":"2016-03-07T05:31:31Z","closed_at":"2016-03-06T23:20:02Z","body":"I suspect that not all the compiler you support don't provides provide those traits. Which one doesn't support those traits?\r\n\r\nI know that this is an implementation detail, but why do you use macros as\r\n\r\n```\r\n#define BOOST_FIT_IS_EMPTY(...) __is_empty(__VA_ARGS__)\r\n```\r\n\r\nor\r\n```\r\n#define BOOST_FIT_IS_EMPTY(...) std::is_empty<__VA_ARGS__>::value\r\n```\r\n\r\ninstead of using a trait\r\n\r\n```\r\ntemplate <class T> \r\nstruct is_empty {\r\n    static const bool value = __is_empty(T)\r\n};\r\n```\r\n\r\nIt is in order to avoid the `::value`?\r\n\r\nThose macros are distracting the reading of the code. Could you consider to replace the macros?\r\n\r\nBTW, this should belong to the type_traits library, isn't it?\r\n"},"comment":{"url":"https://api.github.com/repos/pfultz2/Fit/issues/comments/193110594","html_url":"https://github.com/pfultz2/Fit/issues/126#issuecomment-193110594","issue_url":"https://api.github.com/repos/pfultz2/Fit/issues/126","id":193110594,"user":{"login":"pfultz2","id":1306044,"avatar_url":"https://avatars.githubusercontent.com/u/1306044?v=3","gravatar_id":"","url":"https://api.github.com/users/pfultz2","html_url":"https://github.com/pfultz2","followers_url":"https://api.github.com/users/pfultz2/followers","following_url":"https://api.github.com/users/pfultz2/following{/other_user}","gists_url":"https://api.github.com/users/pfultz2/gists{/gist_id}","starred_url":"https://api.github.com/users/pfultz2/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pfultz2/subscriptions","organizations_url":"https://api.github.com/users/pfultz2/orgs","repos_url":"https://api.github.com/users/pfultz2/repos","events_url":"https://api.github.com/users/pfultz2/events{/privacy}","received_events_url":"https://api.github.com/users/pfultz2/received_events","type":"User","site_admin":false},"created_at":"2016-03-07T05:31:31Z","updated_at":"2016-03-07T05:31:31Z","body":"> IDK. Given the current mess when it comes to reusing C++ code, I can't say for sure whether I would. It's less for me than for potential users that have to install the library. All I know is that it's a major putoff for me when I see a library with external dependencies, because I'm always like \"oh god what am I getting into?\". My dream (until we get a proper way to use other people's code in C++) would be a single header that I can copy/paste into my own library, no strings attached. Then, I would only have to update this single header to match its latest version on important releases of Hana.\r\n\r\nI understand where you are coming from, but I think its the wrong direction to go. I've started to write a tool that will fetch, build, and install cmake libraries, called [cget](https://github.com/pfultz2/cget). Its still a WIP, but you can already do `cget install boostorg/hana` to get the latest hana version installed, or `cget install boostorg/hana@v0.7.0` to get version 0.7.0. I am currently working on having it automatically install dependencies by reading a requirements.txt file as well. I plan in the future to add channels which will have better support for versions and checksums. We can discuss this tool more on cget's page, if you like. I think a tool like that will help manage the dependency problem with C++.\r\n\r\n> This. My opinion is that we need to move away from the monolithic Boost monster. Not that we can't keep shipping a monolithic package as we do currently (which is useful for several reasons), but individual libraries should IMO be usable on their own too, provided their dependencies are satisfied. With this vision, explicitly stating the dependencies of each library is the only way to go.\r\n\r\nIdeally, it would be nice to at least get the core libraries to support cmake and pkg-config. This way libraries can start transferring to a modern build and packaging system, and it doesn't need to be a big jump."}}