- Boost - lists.preview.boost.org

[chrono/date] validated versus valid dates
by Vicente J. Botet Escriba 07 May '13

07 May '13

Hi, Allowing to build dates that are not validated doesn't mean that they are not valid. A validated date is always valid. E.g date d(year(2013), may, day(5)); d is not a validated date but is valid. Having a is_validated() function in addition to is_valid() could have its uses assert( ! d.is_validated() && d.is_valid() ); is_validated() function forces to use a bit to store this information on the date representation, but it improves the performances of the is_valid() function. Moving from a possible unvalidated to a validated one would need date d1; ... date d2(d1.year(), d1.month(), d1.day(), check); Instead of this a validate factory makes this clearer date d1; ... date d2 = validate(d1); date validate(date const& dt) { if (dt.is_validated()) return *this; else if (dt.is_valid()) { date res(dt); res.set_validated_(); // this is private return res; } throw bad_date(); } Best, Vicente

2 3

Am I missing something or is Boost: String dictionary?
by david.hagood＠gmail.com 06 May '13

06 May '13

One of the libraries I work with (libXML2) has a very useful concept called a string dictionary, and I am surprised this doesn't appear to be in either STL or Boost. Am I missing something, or is Boost missing something? The basic idea is: Given you have a string and an instance of a dictionary, you can: 1) check if the string is already in the dictionary. 2) Add the string to the dictionary and return the dictionary entry (if the string is already present, return existing entry). The dictionary entries contain a copy of the string. Entries may be compared for equality/inequality in O(1) time. The lifespan of the strings in the entry is managed by the entry. This really simplifies writing parsers and the like, and is such a useful concept that I'm really surprised not to see it in STL or Boost.

6 6

[GitHelp]github.com/boostorg/sandbox comment confusing
by Larry Evans 06 May '13

06 May '13

At: https://github.com/boostorg/sandbox there's a comment by Beman from 10 yrs ago saying: Removed as obsolete - use Boost.Random instead which makes no sense to me. Also, are any of the sandbox files from svn going to be moved to this github sandbox? TIA. -regards, Larry

3 4

Fwd: GSOC:2013 Multiprecision Proposal Review
by Siddharth Jain 06 May '13

06 May '13

Please have a look at my proposal. The link to my proposal is http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/siddhart… and I have worked a lot on this proposal. Please suggest any changes which could be incorporated to improve this project. Regards Siddharth Jain

1 0

Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
by Niall Douglas 06 May '13

06 May '13

> Le 02/05/13 18:01, Niall Douglas a ?crit : > >> That's orthogonal. Boost.Asio provides the funding blocks. A nicer > >> interface that doesn't require an explicit continuation passing style > >> transformation can be built with Boost.Context or a similar library. > >> But it probably needs a future implementation that integrates with > >> ASIO, which is one of the point of Niall Douglas. > > Spot on. Especially as parts of ASIO are due to enter with TR2. I worry that > > a thread pool designed without ASIO in mind would become an orphan isolate. > What a ThreadPool must provide to satisfy the ASIO requirements? That's a very good question. And for me to answer in specifics I'd need to think deeply about the issue, and study examples, neither of which time currently allows given C++Now is just around the corner. All I can say right now - and I agree this isn't very helpful - is make it compatible with opaque third party event loop dispatchers such as Qt's QCoreApplication and QRunnable. Because Qt's implementation details iare opaque to external code, if you can meet compatibility with that you'll probably be compatible with anything Boost.ASIO can come up with, especially as most of Boost.ASIO is header defined. I appreciate that isn't very helpful. Thread pool design is hard :( Niall

4 5

[config/multiprecision/units/general] Do we have a policy for user-defined-literals?
by John Maddock 06 May '13

06 May '13

Folks, I've been experimenting with the new C++11 feature "user-defined-literals", and they're pretty impressive ;-) So far I've been able to write code such as: auto i = 0x1234567890abcdef1234567890abcdef_cppi; and generate value i as a signed 128-bit integer. It's particulary remarkable because: * It actually works ;-) * The value is generated as a constexpr - all evaluation and initialization of the multiprecision integer is done at compile time. * The actual meta-code is remarkably short and concise once you've figured out how on earth to get started! Note however my code is limited to hexadecimal constants, because it can't do compile time radix conversion - that would require a huge meta-program for each constant :-( This is obviously useful to the multiprecision library, and I'm sure for Units as well, but that leaves a couple of questions: 1) We have no config macro for this new feature (I've only tested with GCC, and suspect Clang is the only other compiler with support at present). What should it be called? Would everyone be happy with BOOST_NO_CXX11_USER_DEFINED_LITERALS ? 2) How should libraries handle these user defined suffixes? The essencial problem is that they have to be in current scope at point of use, you can never explicitly qualify them. So I suggest we use: namespace boost{ namespace mylib{ namespace literals{ mytype operator "" _mysuffix(args...); }}} Then users can import the whole namespace easily into current scope right at point of use: int main() { using namespace boost::mylib::literals; boost::mylib::mytype t = 1234_mysuffix; } 3) How should the suffixes be named? There is an obvious possibility for clashes here - for example the units lib would probably want to use _s for seconds, but no doubt other users might use it for strings and such like. We could insist that all such names added to a boost lib are suitably mangled, so "_bu_s" for boost.units.seconds, but I'm not convinced by that. Seems to make the feature much less useful? Many thanks in advance for your thoughts, John.

6 12

[chrono/date] Performance goals and design summary
by Vicente J. Botet Escriba 05 May '13

05 May '13

Hi, After the discussion on other threads I would like to summarize some of my performances goals while refactoring the H.H chrono/date library, just to see if I was wrong and going on the bad direction: 1. *Be able to build dates without validating them.* 2. *I wanted the library to be as efficient as possible when the user uses constant objects or literals, no need to validate at runtime what has already been validated by the compiler*. 3. *Possibility to reassign a date if the parameters represent a valid date.* 4. *No a single date class is better than the others on all the algorithms*. 5. *No additional meta-data in absolute dates so that you don't pay for the relative dates overhead when using absolute dates.* 6. *The user must be able to get all the date related informations at once.* Do you have other? The way I have managed with these goals is 1. *P*rovide an unchecked date construction interface with a no_check_t parameter and an is_valid() function. 2. *T*he date parts day/month/year need to be validated or constructed with no_check_t. 3. dt.set_if_valid(year, month, day) 4. Define the Date requirements all the dates must satisfy, implement ymd_date, days_date, ... 5. Separate the absolute and the relative Date requirements into two Date concepts AbsoluteDate and RelativeDate. Provide at least a relative_date class based on the ymd representation. 6. Conversion between different concrete date classe. H.H approach respond to these goals in a different way 1. date and its parts provide constructors that are not validated, the validation is provided by factories as operator/. 2. I don't think this can be achieved when the date must be validated. 3. No problem, this could be added to H.H approach (at least for its YMD date). 4. Same approach. H.H proposes two classes chrono::day_point (only unchecked) and YMD date. 5. I'm not sure the date YMD class doesn't include meta data (Howard could you clarify your point here) 6. same approach. I have some questions for followed by my personal answer; * *Do you see some unnecessary goals, in particular, is the goal 2**necessary?* IMO, yes. Not providing an interface that allows compiler optimizations is against the C++ philosophy. The question is as always, what would be the gain? In the best case we could avoid 6 comparisons. * *Does the introduction of no_check to achieve goal 1 and 2 results in a uglier date interface?* IMO, yes, but I don't know how to achieve goal 2 without. * *Should a concrete date class provide just the functionalities it is able to do efficiently?* IMO, yes. This would prevent the user of non efficient services (Note that my current design doesn't follows this) * *Do we need a Date concept that a concrete date must model**?* IMO, yes. SO we need two levels, level one provides the most efficient service, level two provides an homogeneous interface. * *Do we need to make the separation between absolute and relative dates?* IMO, yes. While relative dates are powerful they incur on unwanted overhead when absolute dates are needed. Best, Vicente

4 14

[build] Conditional sources and compiler options
by Andrey Semashev 05 May '13

05 May '13

Hi, I'm trying to add some SIMD support to my library and I'm having problems with setting up my Jamfile properly. Basically, I have a number of source files that only need to be compiled when the compiler is of a specific version or later (say, gcc >= 4.7 or msvc >= 12 or intel >= X.Y on x86 but not for other compilers/architectures and not for older versions of the mentioned compilers). Next, I need to add special compiler options (specific for each compiler) just for these files. Natuarlly, I also have other source files that need not these tricks and should be compiled normally, without any special options. All source files have to be compiled into a single library (static or dynamic). Is there any way to do it in Boost.Build? I've read about alternatives in the docs, but they require duplicating the library target, which I'd like to avoid. I also read about conditional requirements, but as I understand they don't allow to specify version conditions (like <toolset>gcc >= 4.7). Also I didn't find any way to specify special build options for particular files. Thanks in advance.

2 2

[boost.preprocessor.iteration] relative file iteration not supported
by Adrian H 05 May '13

05 May '13

Hello, I have used Boost in the past and do like the use of the preprocessor as a way of making repetitious code. However, I found that in a project that I was working on, I needed the ability to iterate over a file relative to the file I was iterating from, and that file wasn't relative to any of the include directories. I thought about this and it makes sense to why it didn't work, but I can see that it can prove to be inconvenient sometimes when someone wishes to make library header files relative to each other to allow for flexible positioning of the related files in the source tree or not have to add new items to the include directory set. I have written a preprocessor library to fill this need, but was wondering if such a library would be of interest to the Boost community. I deliberately tweaked it to be similar to the Boost Preprocessor Iterator library, and can be acquired at https://sourceforge.net/projects/relativeiterate/, including documentation and an example located in the README.txt file. I would appreciate any feedback you may have on this and would be more than willing to make changes to accommodate what would be needed for it to be included into the Boost set. Thank you for your time. Adrian -- ======================================== Adrian Hawryluk BSc. Computer Science ---------------------------------------- Specialising in: OOD Methodologies in UML OOP Methodologies in C, C++ and more RT Embedded Programming GUI Development ========================================

3 4

[chrono/date] constructor, factories and validation
by Vicente J. Botet Escriba 05 May '13

05 May '13

Hi all, Two approaches to checking date validation have been proposed Howard approach: * date constructors build unchecked dates (provide the same order of parameters that the date factories. * date factories (expression using operator/()) build checked dates. * could be completed with make_date that will build checked dates. Advantages: * avoids the ugly no_check (that could be replaced by no_throw) Drawbacks * The 3 sets of date constructor factories must provide all the same order of parameters. * Creating a new factory will mean creating a new constructor on each concrete date class. * The factories must be friend of the concrete dates. My original approach complemented with make_date factory: * constructors without no_check build checked dates, and with no_check parameter build well unchecked ones. Provides only decreasing lexicographic order of arguments e.g. date(year,month,day), date(year,month,day,no_check_t). * make_date provides the usual combinations as provided by factory using operator/() and no_check. * date factories (expression using operator/()) build checked dates Advantages: * There are less date constructors. * We can add as many factories as we are able to construct with checking or not. Drawbacks * the no_throw/no_check/unchecked parameter is ugly and a source of conflict. Alternative approach (reverse the defaults): * constructors without check build unchecked dates, and with check parameter build well checked ones. Provides only decreasing lexicographic order of arguments e.g. date(year,month,day), date(year,month,day,check_t). * make_date provides the usual combinations as provided by factory using operator/() and check. * a make_checked_date could have also a sens. * date factories (expression using operator/()) build checked dates Best, Vicente

1 0