[algorithm] aesthetic question about cxx11
Hello all, I have an aesthetic question. Boost.Algorithm puts C++11 algorithms like all_of into a directory boost/algorithm/cxx11. Would the directory name boost/algorithm/cpp11 be preferred? I think for file names .cpp and .hpp are Boost choice over .cxx and .hxx. But for directory names instead cxx11 is Boost choice over cpp11? Similarly, shall macros that refer to C++11 be named BOOST_..._CPP11_... or BOOST_..._CXX11_...? In general, shall Boost refer to C++11 as cpp11/CPP11 or cxx11/CXX11? Given that .cpp/.hpp is Boost choice for file names over .cxx/.hxx, I'd think cpp11/CPP11 would be Boost choice over cxx11/CXX11... P.S. I have a similar situation in Boost.Contract where I want to put macros to parse C++11 keywords (override, final, etc) in a separated directory and I want to name that directory cxx11 or cpp11 consistently with other Boost libraries (so users don't have to remember different conventions). Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-algorithm-aesthetic-question-about-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Feb 26, 2012, at 10:50 AM, lcaminiti wrote:
Hello all,
I have an aesthetic question. Boost.Algorithm puts C++11 algorithms like all_of into a directory boost/algorithm/cxx11. Would the directory name boost/algorithm/cpp11 be preferred?
I think for file names .cpp and .hpp are Boost choice over .cxx and .hxx. But for directory names instead cxx11 is Boost choice over cpp11? Similarly, shall macros that refer to C++11 be named BOOST_..._CPP11_... or BOOST_..._CXX11_...? In general, shall Boost refer to C++11 as cpp11/CPP11 or cxx11/CXX11? Given that .cpp/.hpp is Boost choice for file names over .cxx/.hxx, I'd think cpp11/CPP11 would be Boost choice over cxx11/CXX11...
P.S. I have a similar situation in Boost.Contract where I want to put macros to parse C++11 keywords (override, final, etc) in a separated directory and I want to name that directory cxx11 or cpp11 consistently with other Boost libraries (so users don't have to remember different conventions).
Just to let you know, the directory boost/algorithm/cxx11 has not been a part of any boost release yet (it will be part of1.50), so changing it should not break any existing code. As to using cxx11 vs cpp11, I don't really have a preference. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Marshall Clow wrote:
On Feb 26, 2012, at 10:50 AM, lcaminiti wrote:
I have an aesthetic question. Boost.Algorithm puts C++11 algorithms like all_of into a directory boost/algorithm/cxx11. Would the directory name boost/algorithm/cpp11 be preferred?
I think for file names .cpp and .hpp are Boost choice over .cxx and .hxx. But for directory names instead cxx11 is Boost choice over cpp11? Similarly, shall macros that refer to C++11 be named BOOST_..._CPP11_... or BOOST_..._CXX11_...?
Just to let you know, the directory boost/algorithm/cxx11 has not been a part of any boost release yet (it will be part of1.50), so changing it should not break any existing code.
As to using cxx11 vs cpp11, I don't really have a preference.
As Lorenzo notes, the suffixes suggest that the directory names should use "cpp", too, but there is a difference. In "cxx11", the "cxx" is in reference to a standard version, rather than to the language itself, so a distinction might be appropriate. I, too, don't really have a preference. However, the directories and corresponding macros should use p/P or x/X consistently. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote
Marshall Clow wrote:
On Feb 26, 2012, at 10:50 AM, lcaminiti wrote:
I have an aesthetic question. Boost.Algorithm puts C++11 algorithms like all_of into a directory boost/algorithm/cxx11. Would the directory name boost/algorithm/cpp11 be preferred?
I think for file names .cpp and .hpp are Boost choice over .cxx and .hxx. But for directory names instead cxx11 is Boost choice over cpp11? Similarly, shall macros that refer to C++11 be named BOOST_..._CPP11_... or BOOST_..._CXX11_...?
Just to let you know, the directory boost/algorithm/cxx11 has not been a part of any boost release yet (it will be part of1.50), so changing it should not break any existing code.
As to using cxx11 vs cpp11, I don't really have a preference.
As Lorenzo notes, the suffixes suggest that the directory names should use "cpp", too, but there is a difference. In "cxx11", the "cxx" is in reference to a standard version, rather than to the language itself, so a distinction might be appropriate.
I, too, don't really have a preference. However, the directories and corresponding macros should use p/P or x/X consistently.
1. Yes, I should have pointed out that Algorithm uses cxx11 only in trunk so all options are on the table (no user code will brake if we change that). 2. Yes, as a user I'd be OK with "I use .cpp/.hpp for file names but cxx/CXX for naming the language standard". In the ScopeExit improvements I used a macro BOOST_SCOPE_EXIT_CONFIG_NO_CPP11 to force disabling implementation that uses C++11 features (lamba functions and auto declarations) even on C++11 compilers. That's also just in the trunk so I can easily change it to BOOST_SCOPE_EXIT_CONFIG_NO_CXX11. Are there other Boost libraries (better if already released) that have used cpp/CPP over cxx/CXX to refer to the standard name? That could be used as a precedence to make a decision keeping consistency while braking no existing code. Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-algorithm-aesthetic-question-about-... Sent from the Boost - Dev mailing list archive at Nabble.com.
lcaminiti wrote
Stewart, Robert wrote
Marshall Clow wrote:
On Feb 26, 2012, at 10:50 AM, lcaminiti wrote:
I have an aesthetic question. Boost.Algorithm puts C++11 algorithms like all_of into a directory boost/algorithm/cxx11. Would the directory name boost/algorithm/cpp11 be preferred?
I think for file names .cpp and .hpp are Boost choice over .cxx and .hxx. But for directory names instead cxx11 is Boost choice over cpp11? Similarly, shall macros that refer to C++11 be named BOOST_..._CPP11_... or BOOST_..._CXX11_...?
Just to let you know, the directory boost/algorithm/cxx11 has not been a part of any boost release yet (it will be part of1.50), so changing it should not break any existing code.
As to using cxx11 vs cpp11, I don't really have a preference.
As Lorenzo notes, the suffixes suggest that the directory names should use "cpp", too, but there is a difference. In "cxx11", the "cxx" is in reference to a standard version, rather than to the language itself, so a distinction might be appropriate.
I, too, don't really have a preference. However, the directories and corresponding macros should use p/P or x/X consistently.
1. Yes, I should have pointed out that Algorithm uses cxx11 only in trunk so all options are on the table (no user code will brake if we change that).
2. Yes, as a user I'd be OK with "I use .cpp/.hpp for file names but cxx/CXX for naming the language standard".
In the ScopeExit improvements I used a macro BOOST_SCOPE_EXIT_CONFIG_NO_CPP11 to force disabling implementation that uses C++11 features (lamba functions and auto declarations) even on C++11 compilers. That's also just in the trunk so I can easily change it to BOOST_SCOPE_EXIT_CONFIG_NO_CXX11.
Are there other Boost libraries (better if already released) that have used cpp/CPP over cxx/CXX to refer to the standard name? That could be used as a precedence to make a decision keeping consistency while braking no existing code.
Thanks. --Lorenzo
It looks like other Boost libraries are using CXX (and not CPP): BOOST_NO_CXX11_HDR_INITIALIZER_LIST. Then I think we can proclame Boost convention to be .[ch]pp for file names, CXX for macros, and cxx for directories (and also cxx for code symbol names other than macros?). Boost.Algorithm keeps cxx11 as the directory name and I change BOOST_SCOPE_NO_CPP11 to BOOST_SCOPE_EXIT_NO_CXX11 in my Boost.ScopeExit extensions in trunk. Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-algorithm-aesthetic-question-about-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Mar 10, 2012, at 8:44 AM, lcaminiti wrote:
lcaminiti wrote
Stewart, Robert wrote
Marshall Clow wrote:
On Feb 26, 2012, at 10:50 AM, lcaminiti wrote:
I have an aesthetic question. Boost.Algorithm puts C++11 algorithms like all_of into a directory boost/algorithm/cxx11. Would the directory name boost/algorithm/cpp11 be preferred?
I think for file names .cpp and .hpp are Boost choice over .cxx and .hxx. But for directory names instead cxx11 is Boost choice over cpp11? Similarly, shall macros that refer to C++11 be named BOOST_..._CPP11_... or BOOST_..._CXX11_...?
Just to let you know, the directory boost/algorithm/cxx11 has not been a part of any boost release yet (it will be part of1.50), so changing it should not break any existing code.
As to using cxx11 vs cpp11, I don't really have a preference.
As Lorenzo notes, the suffixes suggest that the directory names should use "cpp", too, but there is a difference. In "cxx11", the "cxx" is in reference to a standard version, rather than to the language itself, so a distinction might be appropriate.
I, too, don't really have a preference. However, the directories and corresponding macros should use p/P or x/X consistently.
1. Yes, I should have pointed out that Algorithm uses cxx11 only in trunk so all options are on the table (no user code will brake if we change that).
2. Yes, as a user I'd be OK with "I use .cpp/.hpp for file names but cxx/CXX for naming the language standard".
In the ScopeExit improvements I used a macro BOOST_SCOPE_EXIT_CONFIG_NO_CPP11 to force disabling implementation that uses C++11 features (lamba functions and auto declarations) even on C++11 compilers. That's also just in the trunk so I can easily change it to BOOST_SCOPE_EXIT_CONFIG_NO_CXX11.
Are there other Boost libraries (better if already released) that have used cpp/CPP over cxx/CXX to refer to the standard name? That could be used as a precedence to make a decision keeping consistency while braking no existing code.
Thanks. --Lorenzo
It looks like other Boost libraries are using CXX (and not CPP): BOOST_NO_CXX11_HDR_INITIALIZER_LIST.
Thats because I just changed all those macros from BOOST_NO_0X_* to BOOST_NO_CXX11_* last weekend.
Then I think we can proclame Boost convention to be .[ch]pp for file names, CXX for macros, and cxx for directories (and also cxx for code symbol names other than macros?).
Boost.Algorithm keeps cxx11 as the directory name and I change BOOST_SCOPE_NO_CPP11 to BOOST_SCOPE_EXIT_NO_CXX11 in my Boost.ScopeExit extensions in trunk.
Works for me. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Sat, Mar 10, 2012 at 5:44 PM, lcaminiti <lorcaminiti@gmail.com> wrote:
Then I think we can proclame Boost convention to be .[ch]pp for file names, CXX for macros, and cxx for directories (and also cxx for code symbol names other than macros?).
Why cxx for dirs? Then we've got cpp for one path component and cxx for another? -- Olaf
Olaf van der Spek-3 wrote
On Sat, Mar 10, 2012 at 5:44 PM, lcaminiti <lorcaminiti@> wrote:
Then I think we can proclame Boost convention to be .[ch]pp for file names, CXX for macros, and cxx for directories (and also cxx for code symbol names other than macros?).
Why cxx for dirs? Then we've got cpp for one path component and cxx for another?
OK, honestly the convention that would make the most sense to me (as long as it doesn't break any exiting code) is cpp/hpp/CPP for everything files, directory, and code symbols (including macros). But I'm happy to just pick a convention and move on with my life ;) I can't make the final call on my own-- Boost developers, what do you think the convention should be here? Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-algorithm-aesthetic-question-about-... Sent from the Boost - Dev mailing list archive at Nabble.com.
lcaminiti wrote:
Olaf van der Spek-3 wrote
On Sat, Mar 10, 2012 at 5:44 PM, lcaminiti <lorcaminiti@> wrote:
Then I think we can proclame Boost convention to be .[ch]pp for file names, CXX for macros, and cxx for directories (and also cxx for code symbol names other than macros?).
Why cxx for dirs? Then we've got cpp for one path component and cxx for another?
OK, honestly the convention that would make the most sense to me (as long as it doesn't break any exiting code) is cpp/hpp/CPP for everything files, directory, and code symbols (including macros). But I'm happy to just pick a convention and move on with my life ;)
Recall that CPP can refer to the C preprocessor, so CXX is better for macros. Once you make that leap, using cxx for the directories makes sense. If hxx and cxx were the file suffixes from the beginning, all would be consistent. However, there's too much water under that bridge, so there remains some disturbance in the force. I think there's enough logic behind CXX/cxx for everything but the suffixes to choose that route. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Recall that CPP can refer to the C preprocessor, so CXX is better for macros. CPP can mean a lot of things. Do we really use it to mean C preprocessor that much? ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2012-03-15 04:12:54 +0000, Gottlob Frege said:
Recall that CPP can refer to the C preprocessor, so CXX is better for macros.
CPP can mean a lot of things. Do we really use it to mean C preprocessor that much?
FWIW, the Boost.Preprocessor library uses just "PP" (BOOST_PP_*) to mean the C preprocessor. I think the connection between "CPP" and "C++" is pretty strong in the context of Boost, stronger than "CXX" and "C++". -- Pyry Jahkola
I was wondering what the status is on implementing the discard() functionality in random engines? Eg for MT these is a constant time algorithm, is there work being done on that? Another thing I found in the sandbox is a Sobol and Fauré quasi-random sequence random engine. Is that planned for inclusion? Those too have constant time discard() algorithms. A fast discard() is something we need for parallel random number generation, it will allow us to have independent random streams via discarding. Finally I've also used an trial PRF engine posted here, and I liked it a lot. What is the status of that random engine? Thanks! Thijs
AMDG On 03/18/2012 11:11 AM, thijs@sitmo.com wrote:
I was wondering what the status is on implementing the discard() functionality in random engines?
linear_congruential_engine has an optimized discard. I think most of the rest are implemented as as simple for loop.
Eg for MT these is a constant time algorithm, is there work being done on that?
Really? Do you have a link?
Another thing I found in the sandbox is a Sobol and Fauré quasi-random sequence random engine. Is that planned for inclusion? Those too have constant time discard() algorithms.
I believe the implementation is solid, but I'd prefer to have them go through the review process before being included.
A fast discard() is something we need for parallel random number generation, it will allow us to have independent random streams via discarding.
Finally I've also used an trial PRF engine posted here, and I liked it a lot. What is the status of that random engine?
In Christ, Steven Watanabe
AMDG
On 03/18/2012 11:11 AM, thijs@sitmo.com wrote:
I was wondering what the status is on implementing the discard() functionality in random engines?
linear_congruential_engine has an optimized discard. I think most of the rest are implemented as as simple for loop.
Good to hear that it's implemented. I went through the code and found it indeed (1.48 linear_congruential.hpp). There is however no mention I could find in the online manuals of 1.49 about "engines" concepts. Is it implemented but not ready as a full implementation of the C++11engine concept? is that reason that it's not publicly documented yet?
Eg for MT these is a constant time algorithm, is there work being done on that?
Really? Do you have a link? I'll get back on this, I've asked someone who has an implementation to help out.
Another thing I found in the sandbox is a Sobol and Fauré quasi-random sequence random engine. Is that planned for inclusion? Those too have constant time discard() algorithms.
I believe the implementation is solid, but I'd prefer to have them go through the review process before being included.
Good to hear! That makes sense. If I can help, then I can compare results with e.g. reference implementations I have, and feedback in general.
A fast discard() is something we need for parallel random number generation, it will allow us to have independent random streams via discarding.
Finally I've also used an trial PRF engine posted here, and I liked it a lot. What is the status of that random engine?
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG On 03/18/2012 01:13 PM, Thijs (M.A.) van den Berg wrote:
On 03/18/2012 11:11 AM, thijs@sitmo.com wrote:
I was wondering what the status is on implementing the discard() functionality in random engines?
linear_congruential_engine has an optimized discard. I think most of the rest are implemented as as simple for loop.
Good to hear that it's implemented. I went through the code and found it indeed (1.48 linear_congruential.hpp). There is however no mention I could find in the online manuals of 1.49 about "engines" concepts. Is it implemented but not ready as a full implementation of the C++11engine concept? is that reason that it's not publicly documented yet?
That's an oversight. Boost.Random should be fully compatible with C++0x <random>. I'll update the Concepts to reflect this. Can you file a ticket a http://svn.boost.org/? In Christ, Steven Watanabe
AMDG
On 03/18/2012 01:13 PM, Thijs (M.A.) van den Berg wrote:
On 03/18/2012 11:11 AM, thijs@sitmo.com wrote:
I was wondering what the status is on implementing the discard() functionality in random engines?
linear_congruential_engine has an optimized discard. I think most of the rest are implemented as as simple for loop.
Good to hear that it's implemented. I went through the code and found it indeed (1.48 linear_congruential.hpp). There is however no mention I could find in the online manuals of 1.49 about "engines" concepts. Is it implemented but not ready as a full implementation of the C++11engine concept? is that reason that it's not publicly documented yet?
That's an oversight. Boost.Random should be fully compatible with C++0x <random>. I'll update the Concepts to reflect this. Can you file a ticket a http://svn.boost.org/?
I will. Thanks for the feedback.
On 3/18/2012 2:46 PM, Steven Watanabe wrote in reply to Thijs (M.A.) van den Berg <thijs@sitmo.com>:
Eg for MT these is a constant time algorithm, is there work being done on that?
Really? Do you have a link?
There is: Hiroshi Haramoto, Makoto Matsumoto, and Pierre L'Ecuyer. 2008. A Fast Jump Ahead Algorithm for Linear Recurrences in a Polynomial Space. In /Proceedings of the 5th international conference on Sequences and Their Applications/ (SETA '08), Solomon W. Golomb, Matthew G. Parker, Alexander Pott, and Arne Winterhof (Eds.). Springer-Verlag, Berlin, Heidelberg, 290-298. DOI=10.1007/978-3-540-85912-3_26 http://dx.doi.org/10.1007/978-3-540-85912-3_26 An accessible online copy is at: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ARTICLES/jump-seta-lfsr.pdf If I understand it correctly, whether or not it is "constant time" is a bit ambiguous. Applying it to an arbitrary MT generator requires O(k^1.6) where k is the size of the state, and k must be moderately large before this asymptote is approached. For a particular generator the k is a constant so it is "constant time" -- i.e., constant in the size of the jumps. So, for example, k for MT19937 is 19937 and so is k^1.6 (about 7.5 million). The timing tests in the paper seem to indicate reasonable performance for common applications (e.g., where generating the jumps is done infrequently relative to the number of calls to the generators themselves). Topher
AMDG On 03/18/2012 02:22 PM, Topher Cooper wrote:
On 3/18/2012 2:46 PM, Steven Watanabe wrote in reply to Thijs (M.A.) van den Berg <thijs@sitmo.com>:
Eg for MT these is a constant time algorithm, is there work being done on that?
Really? Do you have a link?
There is:
Hiroshi Haramoto, Makoto Matsumoto, and Pierre L'Ecuyer. 2008. A Fast Jump Ahead Algorithm for Linear Recurrences in a Polynomial Space. In /Proceedings of the 5th international conference on Sequences and Their Applications/ (SETA '08), Solomon W. Golomb, Matthew G. Parker, Alexander Pott, and Arne Winterhof (Eds.). Springer-Verlag, Berlin, Heidelberg, 290-298. DOI=10.1007/978-3-540-85912-3_26 http://dx.doi.org/10.1007/978-3-540-85912-3_26
An accessible online copy is at:
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ARTICLES/jump-seta-lfsr.pdf
If I understand it correctly, whether or not it is "constant time" is a bit ambiguous. Applying it to an arbitrary MT generator requires O(k^1.6) where k is the size of the state, and k must be moderately large before this asymptote is approached. For a particular generator the k is a constant so it is "constant time" -- i.e., constant in the size of the jumps. So, for example, k for MT19937 is 19937 and so is k^1.6 (about 7.5 million). The timing tests in the paper seem to indicate reasonable performance for common applications (e.g., where generating the jumps is done infrequently relative to the number of calls to the generators themselves).
Can you file a ticket at http://svn.boost.org/ for this so I don't forget it? In Christ, Steven Watanabe
On 3/18/2012 7:13 PM, Steven Watanabe wrote:
On 03/18/2012 02:22 PM, Topher Cooper wrote:
On 3/18/2012 2:46 PM, Steven Watanabe wrote in reply to Thijs (M.A.) van den Berg<thijs@sitmo.com>:
> Eg for MT these is a constant time algorithm, is there work being > done on that? > >
Really? Do you have a link?
There is:
Hiroshi Haramoto, Makoto Matsumoto, and Pierre L'Ecuyer. 2008. A Fast ... Can you file a ticket athttp://svn.boost.org/ for this so I don't forget it?
In Christ, Steven Watanabe So it doesn't get entered twice, I'll leave that to Thijs van den Berg, since it is his request.
Topher
On 3/18/2012 7:13 PM, Steven Watanabe wrote:
On 03/18/2012 02:22 PM, Topher Cooper wrote:
On 3/18/2012 2:46 PM, Steven Watanabe wrote in reply to Thijs (M.A.) van den Berg<thijs@sitmo.com>:
>> Eg for MT these is a constant time algorithm, is there work being >> done on that? >> >> Really? Do you have a link?
There is: Hiroshi Haramoto, Makoto Matsumoto, and Pierre L'Ecuyer. 2008. A Fast ... Can you file a ticket athttp://svn.boost.org/ for this so I don't forget it?
In Christ, Steven Watanabe So it doesn't get entered twice, I'll leave that to Thijs van den Berg, since it is his request.
Topher
Thanks for you help Topher! I've created a ticket and added your references. https://svn.boost.org/trac/boost/ticket/6706
lcaminiti wrote
Hello all,
I have an aesthetic question. Boost.Algorithm puts C++11 algorithms like all_of into a directory boost/algorithm/cxx11. Would the directory name boost/algorithm/cpp11 be preferred?
After poking around Boost.Config and other Boost libraries, it seems that cxx11/CXX11 is the commonly adopted code name for C++11. Therefore, I have no problem with cxx11/CXX11 in macros, code symbols, directories, files, etc when there's a need to name C++11 as Boost.Algorithm, Boost.Config, etc are doing. Naming the specific C++11 standard can be considered a different issue from naming a C++ files .cpp/.hpp. For example add_with_cxx11_lambdas.cpp is a C++ files that implements and addition using C++11 lambdas and I think that's a fine name (maybe even better than add_with_cpp11_lambdas.cpp). I'd consider this issue closed. Regards, --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-algorithm-aesthetic-question-about-... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (10)
-
Gottlob Frege -
lcaminiti -
Marshall Clow -
Olaf van der Spek -
Pyry Jahkola -
Steven Watanabe -
Stewart, Robert -
Thijs (M.A.) van den Berg -
thijs＠sitmo.com
-
Topher Cooper