Re: [boost] Re: Re: tokenizer comments
Hi, > Ah... the problem is that those new additions are not documented, AFAICT ;-) > It makes it a little bit hard to understand the interface, especially since > there are no examples/tests for split functionality. Well, as I said, this stuff is quite new, documentation will follow soon, please be patient :) Currently the example usage can be seen only in tests :( Tests for split are located in $sandbox$/libs/string_algo/iterator_test.cpp I want to finish some parts of implementation beforehand and I have plans to completely rework the documentation to reflect these changes. > > > One of them is the integration with the container_traits idea proposed by > > Jeremy Siek and Thorsten Ottosen. It allows to use C-string the same way > > as any container. > > Ehmm... I see that you're using a local/modified copy of > sandbox/boost/sequence_algo/container_traits.hpp. Do you plan to intergate > those files? It would be very good idea, IMO. > They are already integrated, but there is still a need for a little bit of polishing. I have modified/extended container_traits from /sequence_algo/ to fit them into the lib. However, the contaiter_traits in the string_algo lib are not mean to be used from outside of the lib. At least not for now. I think, that they are essential for string_lib, so I asked Thorsten if I can integrate them. If my lib gets accepted, it will also act as a showcase for container_traits. Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: tokenizer comments
On Sat, Jun 21, 2003 at 09:03:40AM +0400, Vladimir Prus wrote: > Pavol Droba wrote: > > > Hi, > > > > I have no comment about the tokenize library, but if your are interested > > in the stuff like that, you can have a look into the sandbox. > > > > string_algo library already contains this functionality > > ( along with other interesting features ) and it is implemented in more > > generic way. > > Hi Pavol, > > I'm already aware of string_algo and using it a bit. I wasn't aware it has > tokenizer component, though. > It was added only a few days ago along with some other improvements and more stuff is comming in the near future. One of them is the integration with the container_traits idea proposed by Jeremy Siek and Thorsten Ottosen. It allows to use C-string the same way as any container. It's nice to know, that somebody is using the lib:) If you have any suggestion/problems, let me know. Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] tokenizer comments
Hi,
I have no comment about the tokenize library, but if your are interested
in the stuff like that, you can have a look into the sandbox.
string_algo library already contains this functionality
( along with other interesting features ) and it is implemented in more generic way.
Documentation is not updated yet ( please be patient ), but you can have
a look into tests to examples how the framework works.
Check $sanbox$/boost/string_algo/split.hpp ( and related headers )
for algorithms
and $sandbox$/boost/string_algo/classification.hpp for supporing functors.
$sandbox$/libs/string_algo/test/iterator_test.hpp contains some usage examples.
Regards,
Pavol.
PS:
Just a small comment. Library ( and especially split/tokenize part )
is dependant on Boost.iterator_adaptors. Unfortunately it is not yet ported
to the new version. Conclusion is, that you cannot build tests directly
from the sandbox.
If you are looking to use the lib, copy all the headers from string_algo subdir
( and/or cummulative headers string_algo.hpp and string_algo_regex.hpp )
into your boost tree. Everything should work fine then.
On Fri, Jun 20, 2003 at 03:45:28PM +0400, Vladimir Prus wrote:
>
> I have a few comments regarding the tokenizer library.
>
> 1. The documentation says that char_delimiters_separator is default parameter
> to 'tokenizer' template, and at the same time says that
> 'char_delimiters_separator' is deprecated. I think that's confusing and
> default parameter should be changed to 'char-separator'.
>
> 2. The token interator description is very brief. Specifically, it does not
> say what that iterator is usefull for, or when it's preferrable to direct use
> of tokenizer. The only way to construct the iterator is via
> make_token_iterator function which takes two interators as arguments. The
> meaning of those arguments is not documented.
>
> Lastly, the usage example
>
>typedef token_iterator_generator::type Iter;
>Iter beg = make_token_iterator(s.begin(),s.end(),f);
>Iter end = make_token_iterator(s.end(),s.end(),f);
>for(;beg!=end;++beg){
>
> appears to be just longer than tokenizer use:
>
>typedef tokenizer< offset_separator > tok_t;
>tok_t tok(s, f);
>for(tok_t::iterator i = tok.begin(); i != tok.end(): ++i) {
>
> so I *really* wonder what this iterator is for. OTOH, if it could be used
> like:
>
>for(token_iterator< offset_separator > i(s, f), e; i != e; ++i) {
>}
>
> it would be definitely simpler and easier. Is something like this possible?
>
> 3. The 'escaped_list_separator' template could have default argument for the
> first parameter, "Char".
>
> 4. I almost always try to use tokenizer when values are separated by commas.
> Believe me or not, I'm always confused as to which tokenizer function to use.
> This time, I read all docs for char_separator and only then used escaped_list
> separator -- which does the work out of the box. Maybe, a different name,
> like "csv_with_escapes_separator" or "extended_csv_separator" would help?
> It would make immediately clear what this separator is for.
>
> - Volodya
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: another program option feature request
On Mon, Jun 09, 2003 at 09:08:37AM +0400, Vladimir Prus wrote:
> Hi Pavol,
>
> > I have a request regarding config file support in the program option
> > library. Currently when the parser encounters an unknown option in the
> > config file, parsing is stopped with an exception.
> > Together with fixed option definition, this feature disables a possibility
> > to have an arbitrary options in the config file, whose exact format is
> > not know prior to parsing.
> >
> > An example:
> >
> > I'd like to have something like this in the config file
> >
> >
> >
> > [module]
> >
> > file-count = 3
> >
> > file-name1 = 001.aaa
> > file-name2 = 002.aaa
> > file-name3 = 003.aaa
> >
> >
> >
> >
> > where the number of file-name* lines is not know before parsing, and it is
> > up to user to specify as many as she wants, or the format and number of
> > options is dependant on some other option ( i.e. file-count )
> >
> > I think, that it would be nice to be able to force the parser to accept
> > also the options not described in the option_descriptions and have a way
> > to work with them.
>
> In fact, there's a (undocumented) feature which applies to your case:
>
> desc.add_options()
> ("file-name*", )
>
> After this, every option starting with "file-name" will be accepted. Is this
> appropriate for your use case?
>
> - Volodya
Well, it looks fine, but still, there can be other cases which could not be coverd by
a simple wildcard like this.
I think, it would still be benefitial if there would be possibility to parse options
which have
not been described.
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] another program option feature request
Hi, I have a request regarding config file support in the program option library. Currently when the parser encounters an unknown option in the config file, parsing is stopped with an exception. Together with fixed option definition, this feature disables a possibility to have an arbitrary options in the config file, whose exact format is not know prior to parsing. An example: I'd like to have something like this in the config file [module] file-count = 3 file-name1 = 001.aaa file-name2 = 002.aaa file-name3 = 003.aaa where the number of file-name* lines is not know before parsing, and it is up to user to specify as many as she wants, or the format and number of options is dependant on some other option ( i.e. file-count ) I think, that it would be nice to be able to force the parser to accept also the options not described in the option_descriptions and have a way to work with them. Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] program_option library bug report
Hi, I have probably encountered a bug in the library. I'm not able to put a bool option in the config file. Regardles how I specify the option there, parsing always fails with the exception: "config file options should have required parameter" Defintion of the option: ( "debug.log-debug", po::parameter( "yes/no", &m_bDebugLog ), "enable debug logging" ); Config file: [debug] log-debug = yes Any hints? Thanks, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Formal Review: Command Line & Config library
On Wed, May 28, 2003 at 11:28:27AM +0400, Vladimir Prus wrote: > Hi Pavol, > > Pavol Droba wrote: > > > I have been reading the discussiong here about adding the support for > > unicode. > > > > Maybe there is a solution which would allow to have templated versions of > > relevant classes AND static library in one box. > > > > > > If we decide that specialization for char and wchar_t is sufficient, the > > headers can contain generic template based declarations, but the > > implementation will be given only for particular cases ( char and wchar_t > > ) and so it can be included in the static lib. > > Oh.. that's yet another approach. I *really* feel Boost-wide solution is > needed. > I'm not sure. This solution is specific for string-like operations where two types for T are sufficient. > > Similar idea is used in stl for streams, strings and locales. > > I though that's different. I need to check out again, but IIRC, RW STL > shipped with borland's free compiler had all string definitions in headers. > I don't know about RW STL, but STLport and VC STL have locale and stream stuff compiled in the lib. Strings are mostly in headers, but CharTraits are linked. > > With a help from preprocessor, it should be easy to define two variants > > in one place. > > Also that could a possibility, that the .cpp file will be included as > > headers all this can be done using macros. > > Yep. Another viable option. It is up to you to decide ... Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Formal Review: Command Line & Config library
Hi,
I have been reading the discussiong here about adding the support for unicode.
Maybe there is a solution which would allow to have templated versions of
relevant classes AND static library in one box.
If we decide that specialization for char and wchar_t is sufficient, the headers
can contain generic template based declarations, but the implementation will be
given only for particular cases ( char and wchar_t ) and so it can be included in
the static lib.
Similar idea is used in stl for streams, strings and locales.
An Example:
aclass.hpp -
template< typename T >
class AClass
{
...
// Declaration of a member function
bool dosomething( std::basic_string );
...
};
aclass.cpp -
bool AClass::dosomething( string )
{
return false;
}
bool AClass::dosomething( wstring )
{
return true;
}
---
Because definition of the member function in the .cpp are not templated,
they can reside in the static library.
With a help from preprocessor, it should be easy to define two variants
in one place.
Also that could a possibility, that the .cpp file will be included as headers
all this can be done using macros.
Example 2:
aclass.inl ---
TEMPLATE_DEF
bool AClass::dosomething( std::basic_string )
{
return false;
}
aclass.cpp --
#define TEMPLATE_T char
#define TEMPLATE_DEF
#include "aclass.inl"
#undef TEMPLATE_T
#undef TEMPLATE_DEF
#define TEMPLATE_T wchar_t
#define TEMPLATE_DEF
#include "aclass.inl"
#undef TEMPLATE_T
#undef TEMPLATE_DEF
aclass.hpp -
template
class AClass
{
...
};
...
#ifdef LIB_INLINE
#define TEMPLATE_T T
#define TEMPLATE_DEF template< typename T >
#include "aclass.inl"
#undef TEMPLATE_T
#undef TEMPLATE_DEF
-
This way everybody can be satisfied with a reasonable effort.
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Formal Review: Command Line & Config library
On Mon, May 26, 2003 at 02:07:06PM +0400, Vladimir Prus wrote: > Pavol Droba wrote: > > > Ok, I think, I see now, where the point is. > > > > The framework is separated into two layers. > > > > L1: option level ( string and boost::any oriented, defined by > > option_description ) L2: typed-paramter level ( represented by > > po::parameter function ) > > > > L2 should work above the L1 as an optional feature > > Currenlty L1 is quite well defined, but L2 is lacking. > > > > I would like if L2 would be able to convert a string representation > > to given type, run the typed validation and store the value into local > > variable. Conversion and validation should be parametric with reasonable > > defaults. Also, I think that the conversion and validation should be > > separated. Conversion should deal with a format of a parameter, while the > > validation should check semantic properties of its value. > > I completely agree. Basically, this means splitting the current "validator" > in two, as your describe above. Plus some polishing of interaction between > 'convert'/'interprepter' -- for string->type conversion > 'validator' -- for checking the value of desired type > 'notifier' -- which does storing into local variables > This sounds very reasonable. I would suggest that L2 should be interfacing to variables_map, to allow cascading of different input formats formats. I don't know how is this feasible though. Also, typed 'default-value' should be considered as parameter of L2 definition. > > Important is, that L2 should be separated from L1. So L2 conversion and > > validation would be different from L1. Actually, L2 validation and > > conversion should plug into L1 as a custom validator. > > > > I hope this makes some sense. po::parameter ( aka L2 ) is quite close to > > the goal, but there are still some missing parts. > > Yep, that makes complete sense. By default, L1 simply converts strings from > command line to strings inside variables_map. The converts/validators that > come from L2 make it behave in more usefull way. > > Do you think those levels must be explicitly written down in docs? Definitely, logical separation of levels is an important concept of the libary. It has to be documented, otherwise users get confused. Pavol. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Formal Review: Command Line & Config library
On Mon, May 26, 2003 at 10:41:08AM +0400, Vladimir Prus wrote:
> Pavol Droba wrote:
>
> >> The only problem with current 'validator' is that it should validate
> >> *string* and return the value. So, the example given by Tanton:
> >>
> >>_1 >= 1 && _1 <= 9)
> >>
> >> would not really work --- the validator function is given a string. It's
> >> probably possible to use 'notify' callback to do such kind of validation,
> >> though. Or add another validator --- which is given converted value.
> >>
> >
> > I see. However I think this is a little bit clumsy to use. I think it may
> > be better to strip validation from the conversion.
> >
> > What I had in mind is an extension to po::parameter funtion to something
> > like
> >
> > template< typename T >
> > *unspecified* po::parameter(
> > string parameter_name,
> > T& variable,
> > const boost::function1 >
> > so the framework would convert string parameter to a specified type and
> > then run the validator functor on the result to validate it.
>
> I was actually thinking about splitting current "validator" into
> "interpreter", which converts string to value and validator proper. That
> should allow to write
>
>desc.add_options()
> ("compression", parameter("n"), "compression quality").
> validator(1 < _1 && _1 <= 9)
> ;
>
> With this feature in place, adding validator as additional argument to
> 'parameter' can be considered a convenience. (Now, there are 3 ideas for
> additional arguments to 'parameter', so I can't decide right now).
>
> One problem: the above would require implementation tricks. The value
> extracted from string is stored in boost::any. Sure, you can't pass
> boost::any to the lambda function above, so some means to recover the type
> stored in any would be needed. I'm not yet sure this will be all that big
> problem, though.
>
Ok, I think, I see now, where the point is.
The framework is separated into two layers.
L1: option level ( string and boost::any oriented, defined by option_description )
L2: typed-paramter level ( represented by po::parameter function )
L2 should work above the L1 as an optional feature
Currenlty L1 is quite well defined, but L2 is lacking.
I would like if L2 would be able to convert a string representation
to given type, run the typed validation and store the value into local variable.
Conversion and validation should be parametric with reasonable defaults.
Also, I think that the conversion and validation should be separated.
Conversion should deal with a format of a parameter, while the validation should
check semantic properties of its value.
Important is, that L2 should be separated from L1. So L2 conversion and validation
would be different from L1. Actually, L2 validation and conversion should plug into L1
as a custom validator.
I hope this makes some sense. po::parameter ( aka L2 ) is quite close to the goal, but
there
are still some missing parts.
[snip]
> Attached is a complete example which uses regex library to validate option's
> value. The format of value is fictional, but the main idea should be clear.
> And there's example session:
>
> bash-2.05b$ bin/gcc/debug/regex --help
> Usage: regex [options]
> Allowed options:
> --help : produce a help screen
> -v [ --version ] : print the version number
> -m [ --magic ] arg : magic value (in NNN-NNN format)
> bash-2.05b$ bin/gcc/debug/regex -m 123
> invalid value
> bash-2.05b$ bin/gcc/debug/regex -m 123-345
> The magic is "345"
>
> I've also realized there are no examples for custom validator now, so this
> code will most likely be added to the library.
>
Thanks for the example. It should definitely become a part of the documentation.
Regards,
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Formal Review: Command Line & Config library
Hi, While using the library I came to a small problem. program_options::store method does two things in one step. It feeds the variables_map and if parametes<> specification is used, it also fills the given variables. The problem arises when both config file and command line facility is used. If the config file is parsed after command line, it will overwrite the values in the local variables. Given the priority of command line over config file - this is not wanted. Nice chaining feature of variables_map ( aka next function ) has not efect on the local variables. I thinks it would be better if the storing to local variables will be part of variables_map interface, instead of doing it in store method. Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Formal Review: Command Line & Config library
Hi On Fri, May 23, 2003 at 09:15:58AM +0400, Vladimir Prus wrote: [snip] > I'll keep this in mind. In fact, I plan to convert all the documentation > into BoostBook is the library is accepted. The Doxygen is very nice --- in > fact, it helps very much to keep everything documented. But I found it > rather limiting for writing various "overview" pages. Hope new > documentation will be better. Great. > > * Validation > > > >Library allows to supports validation and parsing of option parameters, > >but I thinks it is rather limited. It is possible to define > >user-specific behaviour, but it would be helpful, if some common > >formats would be suported. > > > >For instance: > > * Various integer types ( not just int ) with boundary checking. > > Something like > >paramter( "count", 1, 4, &count ) // 1-Min and 4-Max > >value > > It's funny that the very first prototype version had this facility. In > surely can be added to the current version if there's such need. > > I like the idea proposed by Tanton. po::parameter should have a validation predicate as an argument. A reasonable set of arguments can be provided by library, and the user can always provide a specific ones. > > * Format specification and checking for string. Regex specification > > of something like scanf would be nice. > > This can be useful for example to check if the parameter is a > > filename. > > Could you clarify a bit how scanf-like specification can work? You mean it > can be used to specify syntax? > I mean something like "%02.4f" or something like that... it is just an idea. If there would be a validation predicate as an argument, regex library can be used to define regex predicate which would cover most of the cases. > > * Environment & Others > > > >The library tries to unify the access to program options from command > >line and from ini files. This is very nice feature because it is > >removing the need for doing generaly the same thing twice. It would be > >nice if some other sources of paramers could be incorporated as well. > >Particulary the enviromnmet is often used to exchange arguments. Given > >the fact that it consist of a set of pairs "variable=value" it is very > >similar to the ini file and so it souldn't be hard to implement. > > Thanks for the suggestion! It's quite right. > > >For windows platform the registry comes to play as another source of > >options. > > Yep, that source was considered as alternative from the very start. I've > seen some project start with a command line, then add config files and then > need registry on Windows. Registry is not yet supported because I wanted to > find out if there's support to the idea of uniform access to all > configuration means. I definitely like the idea of the uniform access. It would be only welcome if the library can cover more sources of options. Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Formal Review: Command Line & Config library
Hi, I have tried to use program_options library. I have compiled the library, ran the examples and then incorporated the library into one of my projects. All worked quite fine. I have few remarks. First and in my opinion the most important one is the matter of documentation. I find it very hard to use. Examples are quite good to give a nice overview of the library and that's sufficient for a decent start. But searching for the details is quite difficult. I would prefer a few chapters explaining various components of the library, each followed by a reference. Right now I find the documentation rather hard to use. Actuay it is very close to browsing through header files and in my opinion this is not what the documentation should be about. Besides this issue, I think the library is quite nice and easy to use. There are few goodies I'd like to see: * Arguments As it was already mentioned here, arguments should have the same support as options. Validation and format checking would be appretiated * Validation Library allows to supports validation and parsing of option parameters, but I thinks it is rather limited. It is possible to define user-specific behaviour, but it would be helpful, if some common formats would be suported. For instance: * Various integer types ( not just int ) with boundary checking. Something like paramter( "count", 1, 4, &count ) // 1-Min and 4-Max value * Format specification and checking for string. Regex specification of something like scanf would be nice. This can be useful for example to check if the parameter is a filename. * Maybe some more * Environment & Others The library tries to unify the access to program options from command line and from ini files. This is very nice feature because it is removing the need for doing generaly the same thing twice. It would be nice if some other sources of paramers could be incorporated as well. Particulary the enviromnmet is often used to exchange arguments. Given the fact that it consist of a set of pairs "variable=value" it is very similar to the ini file and so it souldn't be hard to implement. For windows platform the registry comes to play as another source of options. Conclusion: I think that this library should be ACCEPTED to Boost. However I would strongly suggest to put some effort to make the documentation more usable. Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost Library Guidelines
On Wed, Apr 30, 2003 at 10:24:09AM +0100, Ken Hagan wrote: > > William E. Kempf wrote... > >> pragmas. As a "best practice suggestion", it's a great idea... as a > >> requirement, I'd have to voice an opinion against. > > Paul A. Bristow wrote: > > > > I absolutely agree, but I feel it would be useful encourage authors > > to try. > > Playing devil's advocate, but why? > > With the compiler in question, I can write > > #pragma warning(push) > // lower the warning level > // include dodgy headers > #pragma warning(pop) > > and I do exactly this for all my third party headers. I don't know > if other compilers have this push/pop feature, but they ought to. > (In fact, I can't think of a pragma that wouldn't benefit from > being able to push and pop its effects.) > > Also, if I run LINT on my code I get warnings about things that > my compiler never worries about. I have to tell LINT to ignore > the quality of third party headers too. Are we suggesting that > boost authors write "//lint" comments too? Where does it stop? > > I use compiler warnings to point me at risk areas in my code. > Boost has been tested rather more thoroughly than my own code > (sad to say) and doesn't feature highly in my risk assessment, > so I'm going to lower the warning level for those headers anyway. > > Given that, there isn't much point in boost authors writing lots > of "line by line" warning suppression paragmas. > I have noticed a lot of new warnings in the release 1.30. I absuletely agree, that there is no reason to do some kind of "line by line" pragma suppression. But... Most of the new warnings can be easily removed with a static_cast. I don't understand, why any boost lib have to generate such a warnings. Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: how to avoid inclusions?
On Fri, Mar 07, 2003 at 08:09:35PM +0100, Gennaro Prota wrote:
> On Fri, 7 Mar 2003 18:17:56 +0100, Pavol Droba <[EMAIL PROTECTED]>
> wrote:
>
> >I wanted to do something else:
> >
> > template struct trait_class
> > {
> >
> > }
> >
> > template struct trait_class >
> > {
> >
> > }
> >
> >without #include
> >
> >Is this possible?
>
>
> Practically speaking, no. At least not in a portable, conforming way.
> You can (under certain limitations) provide specializations like
>
>
> class A { };
> namespace std { template<> class numeric_limits {}; }
>
>
> but you can't otherwise add declarations to std. There are several
> reasons for this limitation.
>
> AFAIK the committee discussed the possibility to provide fwd versions
> of standard headers other than but decided not to do so.
>
My question is then following:
How do the boost libraries solve this problem?
I see only 2 possibilities, both not very nice.
- Silently include all stl container headers ( or at least meny of them )
- Divide the specialization into several files ( one for each container ) and
ask the user to include the specific one.
Is there some other option I don't know about?
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: how to avoid inclusions?
On Fri, Mar 07, 2003 at 04:54:14PM +, John Fletcher wrote:
>
>
> Pavol Droba wrote:
>
> > I wanted to do something else:
> >
> > template struct trait_class
> >{
> >
> >}
> >
> >template struct trait_class >
> >{
> >
> >}
> >
> > without #include
> >
> > Is this possible? Or is there a way how to achieve the same efect, but without
> > including ?
> >
> > I see, that is probably isn't ..
> >
>
> Pavol
>
> Could you put each specialisation in a separate header file and arrange only to
> include the ones which you
> need, the vector one when you include etc?
>
I see this as the only possibility. It's not very nice though. This way user is
required to include a header
each time he want to use a container. It gets even more confusing, because the trait
class is supposed to
be only an implementation detail. However this way, users either accept the inclusion
of unwanted headers,
or they have to include specific header manualy.
Typical now win solution :(
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] how to avoid inclusions?
On Fri, Mar 07, 2003 at 10:09:40AM -0500, David Abrahams wrote:
> Pavol Droba <[EMAIL PROTECTED]> writes:
>
> > I have tried to make forward declaration of std::vector and alike, but it does not
> > work all the time,
> > and, I think it is even forbiden by some compilers.
>
> It's forbidden by the standard.
>
> > My question is:
> > Is there a correct way how to avoid these unwanted inclusions?
>
> Not if they're standard containers :(
not good :(
>
> > Or more specificaly:
> >How to define a partial specialization for a specific type, without including
> > its full definition?
>
> That's a different question:
>
> template struct whatever;
>
> template struct whatever >
> {
>//...
>
> };
>
> You never have to define the primary template, in fact.
I wanted to do something else:
template struct trait_class
{
}
template struct trait_class >
{
}
without #include
Is this possible? Or is there a way how to achieve the same efect, but without
including ?
I see, that is probably isn't ..
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] how to avoid inclusions?
Hi Bootsters, I have a problem that, I think, is worth of discussion. When developing a library I came to a to a need of a trait class, containing properties of different containers. There is a default behavior and a specialization for different stl containers like vector, basic_string and etc. To make the specialiazation, I have to include all the headers for specific containers even, if they are not used by the user code. ( trait class template does not gets instantiated for the specific container ). I have tried to make forward declaration of std::vector and alike, but it does not work all the time, and, I think it is even forbiden by some compilers. My question is: Is there a correct way how to avoid these unwanted inclusions? Or more specificaly: How to define a partial specialization for a specific type, without including its full definition? Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Formal Review Requst: String Algorithm Library
Hi Boosters, I'd like to ask for scheduling a formal review for the string algorithm library. It is mostly finished ( only some final polishing of the documentation is in progress ). Its implementation can be found in the boost sandbox. ( Is it required to upload it to yahoo groups before the review is scheduled? ) Overview: "The String Algorithm Library provides a generic implementation of various string-related algorithms which are missing in STL. It is an extension to the algorithms library of STL. Algorithms in this library include trimming, case conversion, predicates and find/replace functions. All of them come in different variants so it is easier to choose the best fit for a particular need. " Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] cvs web access down?
Sourceforge web and pserver based access to cvs is offline. On Fri, Jan 17, 2003 at 11:41:23AM -, John Maddock wrote: > Is anyone able to connect to > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost ? > > I've been getting: > > Server Error > The following error occurred: > Could not connect because of networking problems. Contact your system > administrator. (CANT_CONNECT) > > for the last few days now. > > John Maddock > http://ourworld.compuserve.com/homepages/john_maddock/index.htm > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost-sandbox CVS access problem
Hi, I have problem accessing the sandbox cvs. I'm using developer access through ssh. During cvs update, I get following message: cvs server: [23:55:48] waiting for yok's lock in /cvsroot/boost-sandbox/boost-sandbox/boost/numeric It is possible to update other directories separately, but not the whole repository. Any idea how to get rid of the problem? Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] mpl::find_if problem on vc7 (once more)
Hi, I have sent a problem report on the list, recently, regarding mpl::find_if algorithm on vc7 platform. I'm using 1.29 release not current cvs snapshot. I assume, that description was not good enough so I haven't got any response. Problem: mpl::find_if algorithm does not compile with vc7. Simple inclusion of the boost/mpl/find_if.hpp header generates a compiler error. Error occurs also on libs/mpl/test/find_if.cpp Error message is following: find_if.cpp D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(26) : error C2143: syntax error : missing ';' before '<' D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(25) : see reference to class template instantiation 'boost::mpl::aux::iter_fold_if_step_impl<>::result_<,,,>' being compiled D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(29) : see reference to class template instantiation 'boost::mpl::aux::iter_fold_if_step_impl<>' being compiled D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(26) : error C2039: 'type' : is not a member of 'operator``global namespace''' D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(26) : error C2238: unexpected token(s) preceding ';' D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(55) : error C2143: syntax error : missing ';' before '<' D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(62) : see reference to class template instantiation 'boost::mpl::aux::iter_fold_if_forward_step' being compiled D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(55) : error C2039: 'type' : is not a member of 'operator``global namespace''' D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(55) : error C2238: unexpected token(s) preceding ';' D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(57) : error C2653: 'not_last' : is not a class or namespace name D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(58) : error C2065: 'value' : undeclared identifier D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(72) : error C2143: syntax error : missing ';' before '<' D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(79) : see reference to class template instantiation 'boost::mpl::aux::iter_fold_if_backward_step' being compiled D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(72) : error C2039: 'type' : is not a member of 'operator``global namespace''' D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(72) : error C2238: unexpected token(s) preceding ';' D:/Boost\boost\mpl\aux_\preprocessed\msvc70\iter_fold_if_impl.hpp(74) : error C2653: 'not_last' : is not a class or namespace name I have found a simple fix for a problem. In file boost/mpl/find_if.hpp, the order of inclusions have to be changed. Original: -- #ifndef BOOST_MPL_FIND_IF_HPP_INCLUDED #define BOOST_MPL_FIND_IF_HPP_INCLUDED #include "boost/mpl/aux_/iter_fold_if_impl.hpp" #include "boost/mpl/aux_/iter_apply.hpp" #include "boost/mpl/logical/or.hpp" #include "boost/mpl/logical/not.hpp" #include "boost/mpl/begin_end.hpp" #include "boost/mpl/always.hpp" #include "boost/mpl/lambda.hpp" -- Patched: -- #ifndef BOOST_MPL_FIND_IF_HPP_INCLUDED #define BOOST_MPL_FIND_IF_HPP_INCLUDED #include "boost/mpl/aux_/iter_apply.hpp" #include "boost/mpl/aux_/iter_fold_if_impl.hpp" #include "boost/mpl/logical/or.hpp" #include "boost/mpl/logical/not.hpp" #include "boost/mpl/begin_end.hpp" #include "boost/mpl/always.hpp" #include "boost/mpl/lambda.hpp" #include "boost/mpl/bind.hpp" - If the order of first two includes is reversed, the error is resolved. I don't have a deep understandness of mpl implementation so it is possible that this patch breaks something else. It is also possible, that the problem is already fixed in cvs. Please, let me know what is the status of this. Thanks, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] mpl problem on vc7 boost_1_29
Hi, I have found a problem while using finf_if from boost distribution. It is probably already fixed, I just wanted to be sure. In the find_if.hpp file the order of include is probably incorrent. Compiler fails to parse boost/mpl/aux_/iter_fold_if_impl.hpp because apply2 is not defined. It is enough just to include the file. I have tried test program libs/mpl/test/find_it.cpp and it does not compile too. I have put #include "boost/mpl/aux_/iter_apply.hpp" before the other one and everything work fine. I don't know if this is a bug or there is some other error in my environment. Thanks, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: notation question
On Wed, Jan 08, 2003 at 12:06:33PM -0500, David Abrahams wrote:
> Vladimir Prus <[EMAIL PROTECTED]> writes:
>
> > David Abrahams wrote:
> >> Vladimir Prus <[EMAIL PROTECTED]> writes:
> >
> >>>I'd prefer the latter variant, so that non-broken platforms use more natural
> >>>syntax. Another question is whether we could use only the second version.
> >>>Theoretically, if you call the second version on const string, then InputT
> >>>should be deduced as "const string". You can then write a simple wrapper to
> >>>select const_iterator or iterator.
> >>>
> >>>The only problem is, IIRC, borland drops "const" on template arguments
> >>>sometimes, and that's not possible to fix. Also, the "simple wrapper"
> >>>requires partial specialization. So, I'm not sure this approach is
> >>>viable, either.
> >> There are mostly-transparent solutions. Something like:
> >> // find_first sequence const version
> >> template< typename InputT, typename SearchT >
> >> inline iterator_range< typename InputT::const_iterator >
> >> find_first_impl( const InputT& Input, const SearchT& Search, 0 )
> >> {
> >>...
> >> }
> >
> > I'm guessing the last parameter should be "int"?
>
> No, sorry. It should be "..."
>
> >> // find_first sequence non-const version
> >> template< typename InputT, typename SearchT >
> >> inline iterator_range< typename InputT::const_iterator >
> >> find_first_impl( InputT& Input, const SearchT& Search, int )
> >> {
> >>...
> >> }
> >> // find_first sequence
> >> template< typename InputT, typename SearchT >
> >> inline iterator_range< typename InputT::iterator >
> >> find_first( InputT& Input, const SearchT& Search )
> >> {
> >>find_first_impl(Input, Search, 0);
> >> }
> >> Should work on vc6. Can't vouch for Borland, though :(
> >
> > Unfortunately, "first_first" will return the same plain (non-const) iterator
> > in all cases. And we'd need to return const_iterator when string is const.
>
> OK, let me fix that:
>
> // find_first sequence
> template< typename InputT, typename SearchT >
> inline iterator_range<
> typename mpl::if_<
> is_const
> , typename InputT::const_iterator
> , typename InputT::iterator
> >::type
> >
> find_first( InputT& Input, const SearchT& Search )
> {
> find_first_impl(Input, Search, 0);
> }
>
> Looking at the name of the function, it occurs to me that dispatching
> to separate implementations might not be needed.
>
> The only restriction on this one is that it doesn't work when the
> Input parameter is an non-const rvalue.
Is this approach feasible for boost? IIRC, somebody mentioned, that BCC does
not handle correctly const templace paramenters, and so, is_const would
not work
I would rather prefer one not-the-pretiest-but-working solution to one which
works only 90% of time without a possible workaround ...
What is the stretegy in Boost development?
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: notation question
On Wed, Jan 08, 2003 at 05:10:17PM +0300, Vladimir Prus wrote:
> Hi Pavol,
>
> Pavol Droba wrote:
>
> > I have following two variants of the same function:
> >
> > // find_first sequence const version
> > template< typename InputT, typename SearchT >
> > inline iterator_range< typename InputT::const_iterator >
> > find_first( const InputT& Input, const SearchT& Search )
> > {
> > ...
> > }
> >
> > // find_first sequence non-const version
> > template< typename InputT, typename SearchT >
> > inline iterator_range< typename InputT::iterator >
> > find_first( InputT& Input, const SearchT& Search )
> > {
> > ...
> > }
> >
> > They are two variants of the same algorithm. Difference is that
> > one variant works on const input while the other one is mutable.
> > Difference is also in the return value. One version contains a
> > const_iterator, while the other one a mutable iterator.
> >
> > According to C++ standard it is perfectly legal to have these
> > two variants and feature known as "function template ordering"
> > does the job of choosing the right variant according to an input.
>
> Strictly speaking, I believe that's overload resolution which selects
> the right one.
Not really. Imagine, you have a "const string" as an input. When matching
a template, compiler can use both versions. For the first one, it
substitutes "string" for InputT and for second one "const string".
This is exatly the place there VC7 fails. In the documentation they,
they say, that they do not support function template ordering and
show the very similar example.
> > Unfortunately not all compilers can hadle this well. For instance
> > VC7 can't handle it properly.
> >
> > A possible workaround is to rename on of the variants.
> > I have added _mutable suffix to the non-const version.
> >
> > My question is, if it is reasonable to do such a rename for all
> > platforms, or it is better to use a macro and add the suffix only for
> > broken platforms?
>
> I'd prefer the latter variant, so that non-broken platforms use more natural
> syntax. Another question is whether we could use only the second version.
> Theoretically, if you call the second version on const string, then InputT
> should be deduced as "const string". You can then write a simple wrapper to
> select const_iterator or iterator.
>
> The only problem is, IIRC, borland drops "const" on template arguments
> sometimes, and that's not possible to fix. Also, the "simple wrapper" requires
> partial specialization. So, I'm not sure this approach is viable, either.
Currently I'm using the macro approach. But, there is a problem. User code is
not portable. To make it portable, one has to use the macro, and that is even
more clumsier than just a suffix.
Smart wrapper would not help without help of partial specialization, I think.
And this would break VC7 completely. Also I'm not sure how to make a wrapper
which would select the proper return value based on the input.
Adding a suffix has one advantage. It gives a better control over constness. If
user needs just a const_iterator, cons version would work fine even on mutable
input. It mutable iterator is needed, then explicit specification of the algorithm
provides a vital safety check.
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Incorrect extensions for cygwin gcc builds
On Wed, Jan 08, 2003 at 11:52:18AM -, John Maddock wrote: > > I have encoutered a problem when building under win2k with cygwin gcc 3.2. > > > > Boost.Build select an extension for binary files according to OS platform. > > So for the Windows paltform it selects .lib for library files and .obj for > object files. > > > > However cygwin is using unix-like .a for libs. When I have compiled regex > library, > > I got libboost_regex.lib as an output, and cygwin ld did not recognized > it. > > I had to build regex with sSUFLIB=.a > > > > Is this a feature or a bug? > > Note that there is a cygwin bjam download available, it's pretty easy to > build from source as well with a: > > make CC=gcc > > although note that cygwin compiled bjam will *not* work with other windows > compilers :-( > If I compile cygwin version of bjam, would it solve my problem? I thought, that the problem is not in bjam, but in tools settings ... Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] notation question
Hi Boosters,
I'd like to hear your opinion about following issue:
I have following two variants of the same function:
// find_first sequence const version
template< typename InputT, typename SearchT >
inline iterator_range< typename InputT::const_iterator >
find_first( const InputT& Input, const SearchT& Search )
{
...
}
// find_first sequence non-const version
template< typename InputT, typename SearchT >
inline iterator_range< typename InputT::iterator >
find_first( InputT& Input, const SearchT& Search )
{
...
}
They are two variants of the same algorithm. Difference is that
one variant works on const input while the other one is mutable.
Difference is also in the return value. One version contains a
const_iterator, while the other one a mutable iterator.
According to C++ standard it is perfectly legal to have these
two variants and feature known as "function template ordering"
does the job of choosing the right variant according to an input.
Unfortunately not all compilers can hadle this well. For instance
VC7 can't handle it properly.
A possible workaround is to rename on of the variants.
I have added _mutable suffix to the non-const version.
My question is, if it is reasonable to do such a rename for all
platforms, or it is better to use a macro and add the suffix only for
broken platforms?
Thanks for help.
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] string_algo lib
Hi, String Algorithm Library is in the feature complete state available in the sand-box. ( :sandbox:/boost/string_algo, :sandbox:/libs/string_algo ) Short summary of the features can be found in the boost WIKI http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?STLAlgorithmExtensions/StringAlgorithms Library contains full set of tests together with Jamfile. Documentation is still missing :( . I'll try to have it done soon. Check the tests for usage scenario. New features: - Boost.Build compatible tests - full regex support - optimized replace algorithms - improved scalability I'll be gratefull for any comments and suggestions. Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Small thing: yes_type and no_type made public?
If there would be voting if to put these two types in Boost, I would vote for it. They are usuful and it is not a good practice to define them on many different places. On Tue, Jan 07, 2003 at 04:29:55PM +0100, Terje Sletteb? wrote: > The types yes_type and no_type (or equivalent) - that is, two types which > are guaranteed to have different size - is used extensively for Boost type > traits, and also in some other libraries (iterator.hpp, > named_template_params.hpp, multi_array, Phyton and signals). Some places use > the type traits ones (), other > define them themselves. > > In the type traits docs (or any other docs I've found), these aren't > mentioned (and they are defined in the "detail"-directory, suggesting it's > an implementation detail). Yet, other libraries use them, as well. Perhaps > these should be documented, so they may be relied on, and other libraries > may avoid having to define them, themselves? > > By the way, these are defined as char and double, respectively. Are these > required to have different size? I haven't found that guarantee in the C++ > or C standard. Theoretically, you might have an architecture which operated > only on values of one size, so that char and double would have the same > size. > > In that case, maybe something like this could be safer: > > typedef char yes_type[1]; > typedef char no_type[2]; > > > Regards, > > Terje > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Incorrect extensions for cygwin gcc builds
Hi, I have encoutered a problem when building under win2k with cygwin gcc 3.2. Boost.Build select an extension for binary files according to OS platform. So for the Windows paltform it selects .lib for library files and .obj for object files. However cygwin is using unix-like .a for libs. When I have compiled regex library, I got libboost_regex.lib as an output, and cygwin ld did not recognized it. I had to build regex with sSUFLIB=.a Is this a feature or a bug? Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] iterator traits
On Thu, Dec 19, 2002 at 03:32:12PM -0500, David Abrahams wrote: > Pavol Droba <[EMAIL PROTECTED]> writes: > > > On Thu, Dec 19, 2002 at 12:04:03PM -0500, David Abrahams wrote: > >> David Abrahams <[EMAIL PROTECTED]> writes: > >> > >> > Pavol Droba <[EMAIL PROTECTED]> writes: > >> > > >> >> but I'm wondering, why it is not documented, or at least mentioned somewhere? > >> >> There are more of such useful headers in boost/detail directory, which are used > >> >> by various libraries. Whouldn't it make sense to write a simple doc mentioning > >> >> all this utilities, so people don't have to invent a wheel again and > >> >> again? > >> > > >> > Be my guest ;-) > >> > > >> > The hardest part of writing libraries is certainly documenting them. > >> > Speaking for myself, I'm lazy, and only wish to spend the effort to > >> > document libraries I'm going to release to the world. > > > > I know what do you mean, I'm working on string_algo library for boost, > > and (un)fortunately, I'm getting the to stage where I have to write documentation >:( > > For me it is the hardest part of work ... > > > >> > >> Pavol, > >> > >> I just realized the above might sound discouraging... I really *would* > >> encourage you to document the useful utilities so we can make them an > >> official part of boost. That file in particular might be good as part > >> of the compatibility library. > > > > Well, I might try if I find a time for doing it:) > > > > Anyway, what I would like to suggest in the mean time, is to at least make a > > summary of these utilities, so that boost developers have a place where they > > can check, if something they need, does not already exists. > > I don't know the place and the form, I think it would be useful. > > Maybe a Wiki page at > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl > ? > > Why don't you start one? Good point, I'll try. Actually I have another question. Why is iterator_traits class so hidden. There is a boost::iterator class which is supposed to be a replacement for std::iterator. Why isn't iterator_traits also in boost/ directory and part of boost namespace? Regards Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] iterator traits
On Thu, Dec 19, 2002 at 12:04:03PM -0500, David Abrahams wrote: > David Abrahams <[EMAIL PROTECTED]> writes: > > > Pavol Droba <[EMAIL PROTECTED]> writes: > > > >> but I'm wondering, why it is not documented, or at least mentioned somewhere? > >> There are more of such useful headers in boost/detail directory, which are used > >> by various libraries. Whouldn't it make sense to write a simple doc mentioning > >> all this utilities, so people don't have to invent a wheel again and > >> again? > > > > Be my guest ;-) > > > > The hardest part of writing libraries is certainly documenting them. > > Speaking for myself, I'm lazy, and only wish to spend the effort to > > document libraries I'm going to release to the world. I know what do you mean, I'm working on string_algo library for boost, and (un)fortunately, I'm getting the to stage where I have to write documentation :( For me it is the hardest part of work ... > > Pavol, > > I just realized the above might sound discouraging... I really *would* > encourage you to document the useful utilities so we can make them an > official part of boost. That file in particular might be good as part > of the compatibility library. Well, I might try if I find a time for doing it:) Anyway, what I would like to suggest in the mean time, is to at least make a summary of these utilities, so that boost developers have a place where they can check, if something they need, does not already exists. I don't know the place and the form, I think it would be useful. Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] iterator traits
Hi, Recently I had to deal with iterator_traits. This feature is kind of problematic on the compilers without partial specialization. Ususally, when iterator_traits are broken, they are not handling generic pointers as iterators. Most of the STL libraries have workaroud for such a situation, but it is usualy used only internaly. After a lot of thinking, how to solve the problem, I have found the small file iterator.hpp in boost/detail directory. In this file, there is a complete solution for my problem. I was happy to use it, but I'm wondering, why it is not documented, or at least mentioned somewhere? There are more of such useful headers in boost/detail directory, which are used by various libraries. Whouldn't it make sense to write a simple doc mentioning all this utilities, so people don't have to invent a wheel again and again? Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bollean states
On Mon, Nov 25, 2002 at 01:36:51PM -0800, Ihsan Ali Al Darhi wrote: > > It's in the Boost sandbox under the name "tribool". Information about the > > sandbox is here: > > http://www.boost.org/more/mailing_lists.htm#sandbox > > > > > Sorry. But nothing there called 'tribool'. try to look in /boost/tribool.hpp and /libs/utility Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: sub string and string algo.
Hi Alexei On Wed, Nov 27, 2002 at 11:09:47AM -0500, Alexei Novakov wrote: > Pavol, > > To make things clear, I do not want to sound like I am opposing to what you > are doing. Thats ok:) Every opinion is worth considering for me > I really think that these algorithms are usefull and very usable. > Only point I want to emphasise is the necessity to have these algorithms > implemented in string oriented fassion (maybe in parallel with generic > ones). String oriented algorithms would give you the following advantages > and additional functionality: I try to explain what are my intentions to support your points. Maybe you will disagree, and we can discuss it in more detail. > 1) They would make implicit use of char_traits methods, which are ignored > now by default. For now, I haven't encountered a need for any char_trait specific features. Functionality provided there is based on char* types and since algorithms should not have access to internal representation of the string, I consider them irrelevant for string_algo lib. > 2) Possible string optimizations, which would be important for string > intensive programs. This is a good point, however all string algorithms are mostly sequencial in the nature so the iterator based implementation is not worse when compared to some string specific one, at least, I don't know about any improvement I could make to the algorithms I have implemented, that would make them much better. > 3) More convenient signatures for those (majority as you agreed) who whould > use it with strings. There are variants for all algorithms which take a generic sequence as an argumnent. So you can use basic_string as a parameters without any special efford. I know that if would be nice to be able to allow to pass a char* as an argument. There is another boost library being developed, called container_algo lib. Almong other features it should provide a unified access to any sequence stl or non-stl one using free-standing operations like begin/end. It would also encapsulate char* and alike. I have disscused this issue with the Thorsten Ottosen, who is working on the container_algo lib, and we have aggreed that I will make the string_algo library compatible with container_algo. So when both libraries will be ready you will not need string specific overrides, everythign will work fine automaticaly. Anyway, I understand quite well a need to flexibility. I'm trying hard now to make string_algo lib open to extension in all possible ways. So that each algorithm could be specialized of modified to any user type and need If will be easy to make a specialization for basic_string if it would be required. However first I have to win a war with VC7 and alike compilers :) Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: sub string and string algo.
On Mon, Nov 25, 2002 at 11:57:25AM -0500, Alexei Novakov wrote:
>
> "Pavol Droba" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Well, in the current state, the string_algo library provides a generic set
> > of string
> > related algorithm. There are many reasons I choose to support any sequence
> > not just the string.
> >
> Can you list these reasons? I have browsed string algorithm library
> discussion and found only one you've mentioned:
>
> Well I have reasons to put it in the way I did. Rationale was to allow usage
> of the
> functions in fuctional way. I consider it quite natural to write something
> like
> if ( to_lower(trim(s)) == "OK" )
> {
> // do somethign with original s
> }
> There are many cases like this in which you probably don't want modify input
> sequence.
>
Actually, this is notthe right point. The quote you have used was about the
reasonability of non-mutable variants.
> This is exactly why sub_string was introduced. If sub_string is returned
> master string will not be modified and new string will not be allocated.
>
> Are there other reasons?
>
All you are pointing out is that substring can be very well used with trims.
I agree, but this is a very special case.
So what are the reasons to allow any sequence type not just a string?
(i) Allow the usage of any string variant like string, wstring, vector and etc.
This also means to allow any user-defined extension of container to be used
( like you sub_string, const_string ) and also for instance rope container.
With the new container_algo library which is under development, it would be
possible to use even c-string as a parameter.
(ii) Allow to used different containers in one algorithm. For example it is possible
to do something like this:
wstring str1( L"abc" );
string str2( "111abc2abc111" )
replace_all( str2, str1, string( "xxx " ) );
(iii) I haven't seen the need to specialize for string. All algorithms for fine
for any sequence, so why to restrict them, when it is not needed. I don't
see any benefit from this specialization.
> >
> > I understand quite well, that in most cases the lib will be used with
> > variants of a the string,
> > however I don't like to sacrifice functionality in the favor of general
> > pattern when it is
> > not needed.
> >
>
> It is good to have generic algorithms, but there is always danger to become
> too generic. There is a pretty comprehensive set of generic algorithms to
> work with generic containers in the Standard. It would be good to have
> special algorithms for special cases, like string algorithms for string
> manipulation. But here you are trying to provide special algorithms for
> general cases, like string algorithms for generic containers.
>
Well, maybe if you can show me a specific algorithm which cannot work with
any sequence but string, I can consider it. I don't know about any.
When you use algorithm, it does not restrict the underlaying sequence. So
If you use algorithm on the string, if will not take away the string functionality.
> > As you can see, library is not just about trim function for which the
> > usage of substring is very
> > obvious. For most of others in the current implementation the usage of
> > substring is questionable.
> >
> Sure, utility classes should be used only where applicable.
>
> > There are places however where we benefit from each other. For example
> > ther was proposal for
> > functions like substr_until( const string& str, const string& substr )
> > which should give you
> > the string from beginning until the first occurenc of the substr. This
> > looks like perfect
> > contructor for your sub_subtring. Also find algorithms can be used for
> > sub_string construction
> >
> > If I thinking about joining, I have one idea. In the similar way you have
> > substring, if may be possible
> > to define generic sub_sequence class which would adapt to a sequence
> > container. I think this
> > could be quite handy and I assume that with a little bit of refactoring
> > you can make the
> > sub_string class a specialization of this generic sub_sequence. Such a
> > class could be then easily
> > integrated with string_algo.
> >
> For generic case like this I believe that pair of iterators would be pretty
> good representation for generic sub sequesnce... However I need to think
> more about it. Definaltely sub sequence will not have 80% of string
> interface implemented, which will
Re: [boost] Re: Sockets
On Mon, Nov 25, 2002 at 04:09:29PM +, Hugo Duncan wrote: > Pavol, > > On Sun, 24 Nov 2002 10:12:36 +0100, Pavol Droba <[EMAIL PROTECTED]> wrote: > > Is there an interest to support also non-TCP/IP based protocols like > > IRDA/TP or raw sockets? > > I think this should be feasable, though I know nothing of IRDA/TP. > > Is it just a case of using the appropriate sockaddr_?? class > and protocol constants? Or are there any requirements on the > communciation once connection is established? > > Hugo > Well IRDA/TP was just an example. There are few differences in the initialization of the socket and of course the different socketaddr. What I was trying to ask is if it would be feasible to add a specializations for non standard protocols. I think its a good idea to leave the design open. If you need examples about different protocols, try to check out MSDN. Winsockets have support for almost every protocol in win platform including NetBEUI, IPX, IRDA/TP and probably more. It could be maybe interesting to look into design of winsockets. There is something called TDI layer in the windows kernel which works as an interface between high-level sockets and kernel-mode drivers. Its design is pretty flexible to support all socket protocol types Maybe it could be worth to look at it to get some ideas how to design lower layers of socket lib. Just my thoughts :) Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] offset_cast proposal
On Mon, Nov 25, 2002 at 04:52:35PM +0100, Terje Sletteb? wrote:
> >From: "Pavol Droba" <[EMAIL PROTECTED]>
>
> > On Mon, Nov 25, 2002 at 02:47:54PM +0100, Terje Sletteb? wrote:
> >
> > > How did you do it on the ARM? As I understand, it requires
> > > word-alignment
> > > for words (and half-word alignment for half-words, if that is supported
> > > on
> > > the given ARM version).
> > >
> > Well it is probably a conjuntion of luck and the kind of data we were
> > working
> > with. As I have mentioned before, offset_cast was used mostly for network
> > packet analysis. And fortunately almost all network protocol structures
> > have correct aligmnent. So we were casting only to correct offsets :)
> >
> Ah, yes, I was thinking of that, too. That's probably designed deliberately
> that way.
>
> > > > I have mentioned before, that binary analysis could be done also using
> > > > a
> > > > more
> > > > complicated framework. Would it make sense to create one?
> > > >
> > > What does it do?
> >
> > The framework I'm proposing should allow user to specify a structure
> > layout
> > ( like what field starts where and what type if have ). Then there would
> > be a kind of possibly hidden management which would do nescesary copy-in
> > and
> > copy-out operations.
> >
> > I can imagine it should be something like this:
> >
> > void modify_binary_header( void* pData )
> > {
> > binary_struct b;
> > b.add_field( 0, "field1" );
> > b.add_field( 4, "field2" );
> > b.add_field( 5, "field3" );
> >
> > b.map_to_binary( pData, offset );
> >
> > b["field1"]=b["field2"]*2;
> > }
> >
> > Please consider this as very preliminary example, just to show a desired
> > functionality.
> > Construction of tructure can be probably done in some better way using
> > static templates.
> >
> > Idea is that binary_struct would be responsible to some sort of safe
> > copying ( possibly byte-by-byte )
> > of binary data into/out from the internal field representation. It can
> > provide also some
> > other functionality like byte order corretion or handling of sub-byte
> > fields ( something what
> > is not aligned to byte boundary )
> >
> > Well, this is my idea how to resolve such a problem where simple mapping
> > using offset_cast
> > is not sufficient.
> >
> Aha, I understand. It's an interesting proposal. I guess it would still
> require some way of detecting, or specifying, alignment requirements (to
> avoid doing it completely pessimistic, by only reading a byte at a time).
>
>
I think it would have to be some compile time option. I don't know about any way
how to detect it automaticaly.
Anyway, do you think that it's worth to start a discussion about such a library?
It's rather complicated topic to do it right. I have many ideas, but it would take
time to implement them.
Regards,
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] offset_cast proposal
On Mon, Nov 25, 2002 at 02:47:54PM +0100, Terje Sletteb? wrote:
[snip]
> As you say, and as was pointed out at the start of the thread, it may work
> on a specific platform (like x86). Perhaps it could be possible to have code
> that detects the platform, and which could then report an error on
> misalignment, if that is not tolerated on the given platform. It appears
> Boost.Config isn't enough for this, though, as it only detects the OS, not
> the underlying hardware.
>
> How did you do it on the ARM? As I understand, it requires word-alignment
> for words (and half-word alignment for half-words, if that is supported on
> the given ARM version).
>
Well it is probably a conjuntion of luck and the kind of data we were working
with. As I have mentioned before, offset_cast was used mostly for network
packet analysis. And fortunately almost all network protocol structures
have correct aligmnent. So we were casting only to correct offsets :)
> > I have mentioned before, that binary analysis could be done also using a
> > more
> > complicated framework. Would it make sense to create one?
> >
> What does it do?
The framework I'm proposing should allow user to specify a structure layout
( like what field starts where and what type if have ). Then there would
be a kind of possibly hidden management which would do nescesary copy-in and
copy-out operations.
I can imagine it should be something like this:
void modify_binary_header( void* pData )
{
binary_struct b;
b.add_field( 0, "field1" );
b.add_field( 4, "field2" );
b.add_field( 5, "field3" );
b.map_to_binary( pData, offset );
b["field1"]=b["field2"]*2;
}
Please consider this as very preliminary example, just to show a desired functionality.
Construction of tructure can be probably done in some better way using static
templates.
Idea is that binary_struct would be responsible to some sort of safe copying (
possibly byte-by-byte )
of binary data into/out from the internal field representation. It can provide also
some
other functionality like byte order corretion or handling of sub-byte fields (
something what
is not aligned to byte boundary )
Well, this is my idea how to resolve such a problem where simple mapping using
offset_cast
is not sufficient.
Regards,
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] offset_cast proposal
On Sun, Nov 24, 2002 at 11:18:10PM +0100, Terje Sletteb? wrote:
> > On Sun, Nov 24, 2002 at 07:27:42PM +0100, Terje Sletteb? wrote:
> > > >From: "Pavol Droba" <[EMAIL PROTECTED]>
> > > >
> > > > Reinterpret-cast could be avoided like this:
> > > >
> > > > template< typename T >
> > > > inline T* offset_cast( void* p, unsigned int offset=0 )
> > > > {
> > > > return static_cast(
> > > > static_cast< void* >( static_cast p )+offset )
> > > > );
> > > > }
> > >
> > > Yes, but that wouldn't make it any more safe, as it would still depend
> on
> > > the alignment requirements, etc. that you mention.
> >
> > Alignment dependency is quite natural here. I'm talking about analysis of
> binary data.
> > I don't see a way how to map a c-like structure onto binary data if you
> don't know what's
> > the bineary representation of the structure and if if does not match the
> required
> > pattern.
>
> What you say here is one of the aspects, the layout in the struct, and any
> internal padding (for internal alignment). However, that's not all. Even if
> you have the same alignment between the components in the struct, as in the
> buffer, you still have the "external alignment" to consider, that is, if the
> struct, in the buffer, starts at the right alignment. If the struct was
> written to the same buffer, then it will be correct. However, if the buffer
> is read from an external source, like a stream, then that is far from
> guaranteed.
>
> For example, if you have a buffer like this (starting at an aligned
> address):
>
> +0 - One byte
> +1 - Number 1
> +5 - Number 2
> +9 - Number 3
>
> Even if you have a struct with three 32-bit ints, no internal padding, if
> you try to map it to the above buffer (at offset 1), on a platform that
> requires 4-byte alignments for ints, it won't work.
>
I see your point now. I'have used offset_cast mostly on x86 platform where to
misalignment is tolerated. I have used it also on ARM processor and we have to
make some sort of special arrangements to make it work. For network strutures,
however it worked fine, because most of them are internaly aligned.
Anyway now I see that in the current implementation offset_cast is too dangerous
and unpredictable and so it is not usable for general purpose.
I have mentioned before, that binary analysis could be done also using a more
complicated framework. Would it make sense to create one?
Regards,
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] offset_cast proposal
On Sun, Nov 24, 2002 at 07:27:42PM +0100, Terje Sletteb? wrote:
> >From: "Pavol Droba" <[EMAIL PROTECTED]>
> >
> > The prerequisite I haven't mentioned is that if you wan to use a structure
> to
> > map to such a buffer, it has to have 1 byte aligmnent. Most of the
> compilers
> > allow this kind of specification with pragmas.
> >
> > Reinterpret-cast could be avoided like this:
> >
> > template< typename T >
> > inline T* offset_cast( void* p, unsigned int offset=0 )
> > {
> > return static_cast(
> > static_cast< void* >( static_cast p )+offset )
> > );
> > }
>
> Yes, but that wouldn't make it any more safe, as it would still depend on
> the alignment requirements, etc. that you mention.
>
Alignment dependency is quite natural here. I'm talking about analysis of binary data.
I don't see a way how to map a c-like structure onto binary data if you don't know
what's
the bineary representation of the structure and if if does not match the required
pattern.
Well there is one, but it would need far more complicated framework.
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: offset_cast proposal
On Sun, Nov 24, 2002 at 06:30:46PM +0100, Dirk Gerrits wrote:
> Pavol Droba wrote:
>
> > Hi,
> >
> > I have developed a simple cast function which I found very useful.
> > Here it is:
> >
> > template< typename T >
> > inline T offset_cast( void* p, unsigned int offset=0 )
> > {
> > return reinterpret_cast< T >( static_cast( p )+offset );
> > }
> >
> > template< typename T >
> > inline T offset_cast( const void* p, unsigned int offset=0 )
> > {
> > return reinterpret_cast< T >( static_cast( p )+offset );
> > }
>
> Why only unsigned offsets?
That was what I needed, but there is no reason why not to support negative
offset as well.
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] offset_cast proposal
On Sun, Nov 24, 2002 at 04:59:45PM +0100, Terje Sletteb? wrote:
> >From: "Pavol Droba" <[EMAIL PROTECTED]>
>
> > On Sun, Nov 24, 2002 at 01:26:05PM +0100, Terje Sletteb? wrote:
> > > >From: "Pavol Droba" <[EMAIL PROTECTED]>
> > >
> > > > I have developed a simple cast function which I found very useful.
> Here it
> > > is:
> > > >
> > > > template< typename T >
> > > > inline T offset_cast( void* p, unsigned int offset=0 )
> > > > {
> > > > return reinterpret_cast< T >( static_cast(
> p )+offset );
> > > > }
> > > >
> > > > template< typename T >
> > > > inline T offset_cast( const void* p, unsigned int offset=0 )
> > > > {
> > > > return reinterpret_cast< T >( static_cast(
> > > p )+offset );
> > > > }
> > > >
> > > > Its purposes is to simplify a mapping of C-like structure onto binary
> > > data. Here is
> > > > the example: Assume thath you have a network packet in raw format, and
> you
> > > want
> > > > to read IP-header information. You could do following:
> > > >
> > > > ip_header* ip=offset_cast( packet, ip_header_offset );
> > > >
> > > > instead of ugly pointer arithmetic.
> > >
> > > Uhm, I think pointer arithmetic could be preferrable to casts,
> particularly
> > > reinterpret_cast, as pointer arithmetic is at least not
> > > implementation-dependent, unlike the reinterpret_cast.
> >
> > I don't see you point here. I'm not sure why whould be reinterpret_cast
> > implemetation dependent and pointer aritmetic not?
>
> Pointer arithmetic, in itself, isn't implementation-dependent. You said that
> your example was an alternative to pointer arithmetic. However, is it
> possible to do the above with pointer arithmetic, only, and no casts? In
> other words, what is the alternative you compare to? [Addition: I see you
> reply to this below here]
>
> > > Also, I find nothing ugly about pointer arithmetic - in fact, STL is
> based
> > > on it, except that it's abstracted as "iterators". int array[10];
> > > std::for_each(array,array+10,f) is pointer arithmetic. Do you find that
> > > ugly, as well?
> >
> > I'm sorry, you are right, ugly is not a good term here. However the
> purpose
> > of the offset cast is not to avoid pointer arithemtic at all cost.
> > Ist purpose is to simplify mapping of structures over memory buffers.
> >
> > Problem here is to shift a pointer n-bytes forward. You can do it
> > with pointer arithmetic, but still you have to cast the pointer to
> something
> > what have size of 1 otherwise you will not shift it n-bytes but
> n*sizeof(type).
> >
> > So offset_cast handles this for you. It is merely a shorcut, which could
> be
> > very handy if you are working with raw data.
>
> Ok, I understand the purpose of it, now. The purpose is to encapsulate the
> pointer arithmetic and casts, into a component. However, as also Dave
> pointed out, it's implementation-dependent whether it would work or not. It
> depends on things like alignment, and any padding in the class you try to
> extract (such as ip_header, above here). As I understand, it's only safe as
> long as the data was the original type to begin with, rather than a plain
> char buffer.
You are right that I have forgotten to mention prerequisities. I have used
offset_cast for analysis of raw network packets. A packet is just a plain
char buffer and you need to analyze it part by part from general parts like
ethernet header to protocol specific parts like tcp header or icmp message body.
offset_cast worked very well for me.
The prerequisite I haven't mentioned is that if you wan to use a structure to
map to such a buffer, it has to have 1 byte aligmnent. Most of the compilers
allow this kind of specification with pragmas.
Reinterpret-cast could be avoided like this:
template< typename T >
inline T* offset_cast( void* p, unsigned int offset=0 )
{
return static_cast(
static_cast< void* >( static_cast p )+offset )
);
}
This would alse restrict the usage of the template to pointer a return value.
>From my experience, such an analysis of unstructured data is not so uncommon.
offset_cast in the form I have proposed is probably too dangerous for general
use. It is possible to provide the same functionality with copy-in, copy-out
semantics. Although it would need more complex framework.
So my question is if such a framework would be usable enough to be considered
for boots.
Regards,
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] offset_cast proposal
On Sun, Nov 24, 2002 at 01:26:05PM +0100, Terje Sletteb? wrote:
> >From: "Pavol Droba" <[EMAIL PROTECTED]>
>
> > I have developed a simple cast function which I found very useful. Here it
> is:
> >
> > template< typename T >
> > inline T offset_cast( void* p, unsigned int offset=0 )
> > {
> > return reinterpret_cast< T >( static_cast( p )+offset );
> > }
> >
> > template< typename T >
> > inline T offset_cast( const void* p, unsigned int offset=0 )
> > {
> > return reinterpret_cast< T >( static_cast(
> p )+offset );
> > }
> >
> > Its purposes is to simplify a mapping of C-like structure onto binary
> data. Here is
> > the example: Assume thath you have a network packet in raw format, and you
> want
> > to read IP-header information. You could do following:
> >
> > ip_header* ip=offset_cast( packet, ip_header_offset );
> >
> > instead of ugly pointer arithmetic.
>
> Uhm, I think pointer arithmetic could be preferrable to casts, particularly
> reinterpret_cast, as pointer arithmetic is at least not
> implementation-dependent, unlike the reinterpret_cast.
I don't see you point here. I'm not sure why whould be reinterpret_cast
implemetation dependent and pointer aritmetic not?
>
> Also, I find nothing ugly about pointer arithmetic - in fact, STL is based
> on it, except that it's abstracted as "iterators". int array[10];
> std::for_each(array,array+10,f) is pointer arithmetic. Do you find that
> ugly, as well?
I'm sorry, you are right, ugly is not a good term here. However the purpose
of the offset cast is not to avoid pointer arithemtic at all cost.
Ist purpose is to simplify mapping of structures over memory buffers.
Problem here is to shift a pointer n-bytes forward. You can do it
with pointer arithmetic, but still you have to cast the pointer to something
what have size of 1 otherwise you will not shift it n-bytes but n*sizeof(type).
So offset_cast handles this for you. It is merely a shorcut, which could be
very handy if you are working with raw data.
Regards,
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Sockets
Hi, On Sat, Nov 23, 2002 at 04:22:22PM +, Hugo Duncan wrote: > Sockets have come up from time to time on this list, without > concrete results. I am no expert, but based on previous > discussions, I have tried to start describing a design at: > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket > (I don't often write formal designs, so please excuse (or correct) > misuse of terminology etc.) > > I propose working with a group of interested people to develop > this design and put together some code. > > As my socket programming experience is limited to tcp/ip streams, > I would also like to ask people to provide small test cases. > In particular, examples of datagram usage, multicast, > broadcast, and non-ip usage. > > Please feel free to edit the wiki pages with comments, etc. Is there an interest to support also non-TCP/IP based protocols like IRDA/TP or raw sockets? Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Possible boost addition: sub string and const string.
Hi John, I have looked into your code. It's pretty interesting, however as I see the current situation in Boost development, your lib ranges over 3 differnt topics which are handled by 3 different libraries. (i) Unification of the interface for various sequence types, including char* variants is being developed as a part of new container_algo interface by Thorten Ottosen and Jeremy Siek. (ii) I'm working on string_algo library which deal mainly with alorithms and does not impose a specific requirement over string. Now it work almost with any sequence and when container_algo lib will be finished it would work almost with anything. (iii) Substring class. This is the latest addition proposed by Alexei. All these topic have common intersetcion and should be designed and implemented in the way they can work and benefit from each other. However I think it is a good idea to leave them separate, because each of them can be useful even without the rest. Regards, Pavol On Sat, Nov 23, 2002 at 12:46:56PM -, John Maddock wrote: > Alexei, > > Looks like we're all thinking alike, a while ago I put together a sequence > based substring class that could act as a universal wrapper for any string > like object, along with a set of algorithms to act upon it: it's based > loosely on Darin Adler's original string algorithm code. > > classes: > > string_traits: this is the glue that allows the classes and algorithms to > act upon any string like object (std::string, char*, other string classes > etc) > basic_substring: an immutable view of any string like object (or iterator > sequence). > > Algorithms returning a substring: > > rtrim > ltrim > trim > > Algorithms returning a new string: > > make_upper > make_lower > > Inplace transformations: > > inplace_ltrim > inplace_rtrim > inplace_trim > inplace_make_upper > inplace_make_lower > > And then I ran out of time... :-) > > I've put what I have at > http://groups.yahoo.com/group/boost/files/string_algorithm/substring.zip, > it's actually pretty complete with full test cases etc, but I'm not sure > where this would fit in with the proposed new string lib, plus I'm pretty > short of time at present. Still I'm hoping someone can make use of this and > maybe the new string lib can include a synthesis of all these ideas... > > John Maddock > http://ourworld.compuserve.com/homepages/john_maddock/index.htm > > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] offset_cast proposal
Hi,
I have developed a simple cast function which I found very useful. Here it is:
template< typename T >
inline T offset_cast( void* p, unsigned int offset=0 )
{
return reinterpret_cast< T >( static_cast( p )+offset
);
}
template< typename T >
inline T offset_cast( const void* p, unsigned int offset=0 )
{
return reinterpret_cast< T >( static_cast( p
)+offset );
}
Its purposes is to simplify a mapping of C-like structure onto binary data. Here is
the example: Assume thath you have a network packet in raw format, and you want
to read IP-header information. You could do following:
ip_header* ip=offset_cast( packet, ip_header_offset );
instead of ugly pointer arithmetic.
Is there any interest for something like this in Boost?
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: sub string and string algo.
On Fri, Nov 22, 2002 at 02:03:49PM -0500, Alexei Novakov wrote:
>
> "Pavol Droba" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Hi,
> >
> > On Thu, Nov 21, 2002 at 02:48:09PM -0500, Alexei Novakov wrote:
> >
> > [snip]
> >
> > > > Alexei.
> > > >
> > > > Cool, I'd definitely use it
> > > > Seeing as there is a move to submit a library of string helpers at the
> > > > moment it might be worth submitting this at the same time!
> > > >
> > > > Vin
> > > >
> > >
> > > I think that these two libs (sub_string and string_algo) could benefit
> from
> > > each other. How do I share the code so that members could see it and try
> it?
> > >
> > > Alexei.
> > >
> >
> > I'm working on the string_algo library. It has a different orientation in
> some way,
> > but I think there are places in which these two libs can benefit from each
> other.
> >
> > There is the boost sandbox cvs and you can read about it from boost web
> page.
> > If you gain access to is, you can have a look into my string_algo lib.
> >
> > Then we can maybe try to find out where we could join our efforts.
> >
> > Regards,
> >
> > Pavol
> >
>
> Oh yes, I did so some time ago and played with string_algo. It seams to me
> that more convenient and natural return type for kinds of trimmers and
> sub_string extractors would be dedicated sub_string class rather than pair
> of iterators. You are using a little bit different approach - your
> algorithms are sequence oriented rather than string oriented. On one hend
> string is a sequence of chars, but on the other there is a good reason why
> dedicated string class was introduced instead of vector. Consider the
> code:
>
> string str(" ***123 ");
> sub_string ss = trim(str); // ss == "***123", but no allocation is done yet.
> // work with ss as with basic_string.
> // We need to do another trim.
> ss = left_trim(ss, "*"); // ss == "123", still no allocation.
> // Let's create real string now;
> string str1 = ss; // str1 == "123"
>
> sub_string is not really usable without a good set of string oriented
> algorithms, as well as algorithms look pretty bulky without being backed up
> by good utility classes.
>
> What do you think?
Well, in the current state, the string_algo library provides a generic set of string
related algorithm. There are many reasons I choose to support any sequence not just
the string.
I understand quite well, that in most cases the lib will be used with variants of a
the string,
however I don't like to sacrifice functionality in the favor of general pattern when
it is
not needed.
As you can see, library is not just about trim function for which the usage of
substring is very
obvious. For most of others in the current implementation the usage of substring is
questionable.
There are places however where we benefit from each other. For example ther was
proposal for
functions like substr_until( const string& str, const string& substr ) which should
give you
the string from beginning until the first occurenc of the substr. This looks like
perfect
contructor for your sub_subtring. Also find algorithms can be used for sub_string
construction
If I thinking about joining, I have one idea. In the similar way you have substring,
if may be possible
to define generic sub_sequence class which would adapt to a sequence container. I
think this
could be quite handy and I assume that with a little bit of refactoring you can make
the
sub_string class a specialization of this generic sub_sequence. Such a class could be
then easily
integrated with string_algo.
So what do you think aboout this?
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] String algorithm library
Hi, This message is mostly for people who are interested in the string algorithm library. New version is in the sandbox. I have redesigned major part of the library, and I think that now its structure is in quite stable state. I want to start writing the documentation, but first I'd like to be sure, that the library will not change too much. ( I'm not very good documenter, and I hate to do this kind of things twice if I don't have to :) ) So I kindly ask you again, to post any comments, additions and proposals. Summary of changes: (i) General naming conventions have changed to be more compliant with STL naming scheme. It means that: - Non-mutable version of algorithm have suffix _copy. - Variants which take a predicate as a selector ( f.e. trim ) have suffix _if. - Find, replace and erase algorithm can have suffix _first, _last or _nth depending on the find functor thay you ( will be explained later ) Convention is that a semantic specification have precendece over parameters. so there is for example erase_first_copy and trim_left_copy_if. (ii) All trim functions have now _if variant which take a selection predicate as a parameter. There are 3 predefined functors available through contruct functions. Function names ar if_isclassified, if_isspace, if_isfrom. ( Check string_funct.hpp for details ) Standard version without suffix map to isspace predicate which I found most common. (iii) find-replace algorithms have been wholy redesigned. - string_algo::compare_traits and string_algo::search_traits has added. Element comparison predicate is now part of traits instead of being a parameter in algorithms. search_traits is a template defined over iterators and provides compare_function_type ( from compare_traits ) and range_type used as a return value for find functions. - all algorithms ( except for _all versions ) has been generalized. They now accept a find algorith as a parameter. There are 3 functors provided for this: find_firstF, find_lastF and find_nthF. User can write his own find function which is supposed to find range representin a subsequence in the given input sequence. For each algorithm there are wrappers for all default find functors. ( f.e there is replace - generic and replace_first, replace_last, replace_nth ) Algorithms included: (i) Trimming: trim, trim_left, trim_right. All in interator, sequence, mutable and non-mutable variants. There are also _if variants for all. (ii) Case conversion: to_lower, to_lower_copy, to_upper and to_upper_copy. (iii) Predicates: start_with (both iterator and sequence version), end_with (sequence version only), contains (both versions) (iv)Find algorithms: find, find_first, find_last, find_nth in iterator and sequence versions (v) Replace algorithms replace, replace_first, replace_last, replace_nth in iterator and sequence version. sequence version in mutable and non-mutable variant (vi)Erase algorithms Same as replace. Please check sources and test code in the sandbox for more datails and usage scenario. Last but not least, I'd like to ask what is needed for library to be commited for submission rewiev? Thats all folks. Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] sub string and string algo.
Hi, On Thu, Nov 21, 2002 at 02:48:09PM -0500, Alexei Novakov wrote: [snip] > > Alexei. > > > > Cool, I'd definitely use it > > Seeing as there is a move to submit a library of string helpers at the > > moment it might be worth submitting this at the same time! > > > > Vin > > > > I think that these two libs (sub_string and string_algo) could benefit from > each other. How do I share the code so that members could see it and try it? > > Alexei. > I'm working on the string_algo library. It has a different orientation in some way, but I think there are places in which these two libs can benefit from each other. There is the boost sandbox cvs and you can read about it from boost web page. If you gain access to is, you can have a look into my string_algo lib. Then we can maybe try to find out where we could join our efforts. Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
On Wed, Nov 20, 2002 at 04:34:21PM +0100, Gennaro Prota wrote: > On Tue, 19 Nov 2002 19:37:51 +0100, Pavol Droba <[EMAIL PROTECTED]> > wrote: > > > isclassified was suggested by Genny Prota > > My name in the file is a theft though. That's just a classic. My only > contribution was the error of using the type ctype_base::mask for a > template parameter :-) > well for me you are the first one who showed it to me:) I can remove the remark, if you don't like it. But I will definitely put you in the acknowledgements :) Cheers, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] singlton library?
On Wed, Nov 20, 2002 at 01:42:47PM +0200, Yakov Bachmutsky wrote: > Hi, > > I've posted a proposal of a singleton library (among others) maybe a month > ago and as far as I remember it was ignored so I post it again with its name > as the subject, hoping this will help, and some explanations: > > 1. I use singleton to have a singleton instance of a class in my > apps. > The obvious advantage in developement of large apps is that u don't have to > remember the name of the 1 instance u create like g_myObj but only the > class's name and thus always use it like this: > singleton p->method(); > > 2. In addition I use a singleton manager to have all singleton objects > started at app start: > singleton_manager::startup() > > 3. to use that I "register" classes to use the singleton class and manager > class using a macro: > REGISTER_SINGLETON(myclass) > > 4. classes can inherit the singleton class to get more specific behaviour > like two stage construction. > Every such inhariting class must have its own registration macro. > > 5. In addition to all the above I suggest few more little thingies to > support other singleton patterns, mostly in the form of macroes. There's > also an article on this topic: > http://www.beginthread.com/Article/yakov/Singleton Techniques/ I have done singleton stuff in a way many times. Could you please post some code examples. I'd like to have a look. Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
Hi On Mon, Nov 18, 2002 at 07:20:58PM -0500, Beman Dawes wrote: > At 03:25 AM 11/18/2002, Pavol Droba wrote: > > >What I want to do in the future is to change default signature of trim to > > >something like you're proposing. There will be a variant with predicate > and > >a set of standard predicates. This way the locale stuff will be moved out > >to the predicate and will not confuse you any more, I hope :) > > Please post the signatures when you think they are stable. I think I > understand what you are planning, but it would be better to actually see > it. > There is new version of the lib in the sandbox. Now it contains predicate variants of all trim functions. I have also provided few default predicated to use. They are in string_funct.hpp header and can be accessed via following helper functions. if_isclassified( Type, Locale ) if_isspace( Locale ) if_isfrom( Seq ) all of them return instance to specific functor. isclassified was suggested by Genny Prota, isspace is just instantiation if isclassified with std::ctype_base::space as the type. isfrom functor lets you specify a range over set of elements you want to trim-out. I have used the same naming scheme as in standard, so all variants which accept predicate have _if suffix. A have left original variants ( those without suffix ) and they are mapping to isspace functor. Cheers, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
On Mon, Nov 18, 2002 at 07:20:58PM -0500, Beman Dawes wrote: > At 03:25 AM 11/18/2002, Pavol Droba wrote: > > >What I want to do in the future is to change default signature of trim to > > >something like you're proposing. There will be a variant with predicate > and > >a set of standard predicates. This way the locale stuff will be moved out > >to the predicate and will not confuse you any more, I hope :) > > Please post the signatures when you think they are stable. I think I > understand what you are planning, but it would be better to actually see > it. Implementation will be in the sandbox soon, I'll post the note on the list when they will be ready. Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
On Mon, Nov 18, 2002 at 06:52:53PM +0100, Gennaro Prota wrote:
> On Mon, 18 Nov 2002 09:25:38 +0100, Pavol Droba <[EMAIL PROTECTED]>
> wrote:
>
> >You are probably right that some ideas are confusing without explanation.
>
> In fact the reason why I was perplexed is that everybody seems to
> focus on minor issues like the names of the templates, while the
> design should be addressed first IMHO. That's odd because people here
> are not likely to let errors easily pass.
Thanks for comments. I appreciate them very much. This is very first version of the
library and I'm willing to change it to more usable way. Actually I'm already working
on some changes.
> [snip]
> >What I want to do in the future is to change default signature of trim to something
> >like you're proposing. There will be a variant with predicate and a set of standard
> >predicates. This way the locale stuff will be moved out to the predicate and will
> >not confuse you any more, I hope :)
>
> Well, I'm confused by definition :-) Anyhow I think what you are
> proposing is actually an algorithm library. It provides
> *generalizations* of typical string algorithms. As I hinted at, trim()
> can be seen as an algorithm that removes the elements that satisfy a
> given predicate from the beginning of any sequence.
You are right, I want to provide string algorithm
library, not just a bunch of functions to manipulate with strings.
Algorithms can be used anywhere they fit.
> Now, it's a matter
> of how much information you need and how you want to provide it. From
> the perspective of generic programming the choice I find natural is a
> pair of iterators and a predicate. To do the same job with "spaces"
> you need ctype<>, but that's easily solved with an appropriate
> functor:
>
>
> // WARNING: completely untested!!!
> //
> template
> class is_classified_as : public std::unary_function
> {
> std::ctype const & m_ctype;
>
> public:
>
> // ctor from a ctype
> is_classified_as (std::ctype & ct) : m_ctype(ct) {}
>
> // ctor from a locale (for convenience)
> is_classified_as (std::locale const & loc = std::locale())
> : m_ctype(std::use_facet< std::ctype >(loc)) {}
>
> bool operator() (charT c) const { return m_ctype.is(Type, c);}
>
> };
this one I haven't though of. Looks interesting
>
>
> What I would see is a bunch of trim variants accepting a predicate
> and, separately, a bunch of string-specific versions like e.g:
>
>
> template
> StringT trim_left(StringT const & str,
> std::locale const & loc = std::locale())
> {
> typename StringT::const_iterator it
> = std::find_if(
> str.begin(),
> str.end(),
> std::not1 (is_classified_as())
> );
>
>return StringT(it, str.end());
> }
>
>
> Don't stop too much on the details though, because that's just to
> explain the idea.
As for the functor stuff. Internaly the trim functions are implemented
exactly the way you are proposing. There is isspaceF functor which is
called by transformation function.
Anyway I'm currently changing interface to support user defined predicates.
Library will contain a set of default predicates and shortcuts to use them.
Any ideas about what functors to include are welcome.
>
> (BTW if there's interest in a collection of functors like the one
> above for integration with STL algorithms as well I'm willing to
> volunteer)
>
Regards,
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
On Mon, Nov 18, 2002 at 06:14:01PM +0100, Thorsten Ottosen wrote: > > - Original Message - > From: "James Curran/MVP" <[EMAIL PROTECTED]> > > > > > While there is a certain elegance to the names, I'd have to vote > against > > those. It's not immediately obvious from the names trim/trimmed which one > > is inplace and which isn't. > > well, I would say it is. verbs in the imperative donote mutation, adjectives > denote copy. > > > Further, in the matter of > > lower_cased/to_lower_case, if you guess wrong, the other one isn't nearby > in > > an alphabetic listing of functions. > > remove or add "to_" from one of them? > I have already changed names to to_lower and to_lower_copy. This way it conform with STL algorithm nameing-rules. IMO it's not the most beautiful way, but at least it is standard .. Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] String algorithm library
Hi, According to the discussion, I have changed the naming scheme so it is more conformant with the standard. I changed all mutable variants to be plain without any suffix and prefix like "trim(s)" and non-mutable variants have suffix _copy like "trim_copy(s)". I have also expanded the names of trimming functions. Now there is trim_left instead ltrim and etc. Have a look in the sandbox. Regards, Pavol. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
On Sun, Nov 17, 2002 at 05:36:35PM +0100, Gennaro Prota wrote: > > Hi Pavol, I haven't been following this thread so please forgive me if > I'm just pointing out something stupid, or problems that you already > know. I had a quick glance at the library and I'm a little confused at > what is its scope. For instance the "is space" generalization makes in > fact functions like trim() and the like generic algorithms that remove > a given element (or its equivalents) from the beginning and the end of > a sequence. At this point either you make clear that the library isn't > specifically a "string library" or that isspaceF is actually a generic > functor that can test whatever charT you like (and change its name at > least). > You are probably right that some ideas are confusing without explanation. It should all go into documentation, but there no such a thing right now, because of very preliminary version of the lib. Idea of the string lib is to provide a set of string related algorithms, but not necessary working only with basic_string. So you can use most of the algorithms on any compatible sequence. It makes it easy for instance to compine basic_string with vector in one function call. This makes sense for example if you are trying to call som C-style API for which vector is much better variant then basic_string. > > >Trimming: > > > > Iterator trim_begin( Iterator InBegin, Iterator InEnd, const std::locale& >Loc=std::locale() ) > > Seq ltrim( const Seq& Input, const std::locale& Loc=std::locale() ) > > Seq& ltrim_in( Seq& Input, const std::locale& Loc=std::locale() ) > > Seq rtrim( const Seq& Input, const std::locale& Loc=std::locale() ) > > Seq& rtrim_in( Seq& Input, const std::locale& Loc=std::locale() ) > > Seq trim( const Seq& Input, const std::locale& Loc=std::locale() ) > > Seq& trim_in( Seq& Input, const std::locale& Loc=std::locale() ) > > This is in accordance with my confusion :-) What has a locale to do > with a generic sequence? If I imagine a generalized trim function > (say, a function that removes all the odd numbers from the beginning > and the end of a vector) I imagine, type requirements about the > iterators etc. aside, signatures like: > > template > Iterator trim (Iterator start, Iterator end, Elem const &); > > template > Iterator trim (Iterator start, Iterator end, Pred pred); > > > It seems that either the design is seriously flawed or (more likely) > I'm missing something. I have already a plan for changing this. The reason for locale paramter is that most obvious scenario for using trim it to remove spaces. And term "space" is locale specific. Locales are not working above a generic sequence, but with every single element, so if you try vector everything is perfectly correct. What I want to do in the future is to change default signature of trim to something like you're proposing. There will be a variant with predicate and a set of standard predicates. This way the locale stuff will be moved out to the predicate and will not confuse you any more, I hope :) Regard, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] String algorithm library
On Sun, Nov 17, 2002 at 11:20:16AM -0500, Beman Dawes wrote: > At 04:00 AM 11/17/2002, Pavol Droba wrote: > > >> Have you taken a look at Darin Adler's string algorithms? See > >> http://groups.yahoo.com/group/boost/files/string_algorithm/ > >> > >> Do any of these have a place in your library? > > > >except for regex variant which are in some way all part of the regex lib, > >all functions are there. Mostly with more general signature and more > >variants > > Do you have any plans to add regex variants? > > Seems like they provide considerable convenience (although it has been > awhile since I looked at them). It would be a shame if they get lost > because they fall in the seam between strings and regex. > I was thinking about it. The problem I found is that whatever I would write, it would be just a forwarder to regex library variant. So maybe it makes sence to provide regex variants in the string library, but only to unify interface for some functions, but not to add much of additional functionality. However it is not a problem for me to add them if there would be a demand to doing it. Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] String algorithm library
On Sun, Nov 17, 2002 at 02:46:31PM +0100, Thorsten Ottosen wrote:
> - Original Message -
> From: "Pavol Droba" <[EMAIL PROTECTED]>
>
> > > Your example would become
> > >
> > > if ( lower_cased( trimmed( s ) ) = "ok" )
> > >
> >
> > This naming sounds good enough, just I'm not sure if such a difference
> >between
> > two variants would not make the code less readable. Alfter all both of
> >them are doing
> > the same thing.
> Well, 'trim_in' was not too good either. Basically, we are trying to improve
> on _in, right?
>
Eighter _in or some something else to copy variants.
I have one idea, but it is probable even more crazy. What about putting each
variant if different namespace.
Then yoou can use copy::trim for copy variant and transform::trim from in-place
variant. Or you can use using namespace for you favorite version and fuly qualify
the other one. I have though about it just a little, probably it is not the best idea.
BTW: Just ot remark that I'm folling the pattern of two variants also for find-replace
functions not just for trim. If woudl be nice the have these two categories consistent.
> > What I don't get is why are you proposing to change return value from Seq&
> >to void.
> > I think it is easier fo write
> >
> > to_lower(trim(to_upper(s)));
> >
> > then
> >
> > to_upper(s); trim(s); to_lower(s);
>
> Chaining is not always good. How often are one going to do it/need it?
> I would simply write a small foo( String& s ) { to_lower(s); trim(s);
> to_upper(s); }.
> If I do use string manipulation a lot I will probably could reuse foo(); I a
> way chaining
> encourages people to avoid writing small helpers; highly unfortunate IMO.
Small helpers are fine, but I'm not a very big fun of them, because if there are too
many
of them, it makes the code less readable. And stacking more operations of the same type
is not new in STL. Look for streams. Even it is something different, the ideas can be
used
here as well, and I don't mean just trimming, but any other transformation you can
think of.
Regards,
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] String algorithm library
On Sat, Nov 16, 2002 at 04:43:53PM -0500, Beman Dawes wrote: > At 11:58 AM 11/15/2002, Pavol Droba wrote: > >Hi Boosters, > > > >I have developed a set of various string manipulating functions into a > >string_algo lib. > > Pavol, > > Have you taken a look at Darin Adler's string algorithms? See > http://groups.yahoo.com/group/boost/files/string_algorithm/ > > Do any of these have a place in your library? except for regex variant which are in some way all part of the regex lib, all functions are there. Mostly with more general signature and more variants Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] String algorithm library
> Perhaps one could use these names then: > > Seq trimmed(...); > void trim(...); > >Seq trim( const Seq& Input, const std::locale& Loc=std::locale() ) > >Seq& trim_in( Seq& Input, const std::locale& Loc=std::locale() ) > > and > > Seq lower_cased(...); > void to_lower_case(...); > > Seq upper_cased(...); > void to_upper_case(...); > > >Seq tolower( const Seq& Input, const std::locale& Loc=std::locale() ) > >Seq& tolower_in( Seq& Input, const std::locale& Loc=std::locale() ) > > >Seq toupper( const Seq& Input, const std::locale& Loc=std::locale() ) > >Seq& toupper_in( Seq& Input, const std::locale& Loc=std::locale() ) > > Your example would become > > if ( lower_cased( trimmed( s ) ) = "ok" ) > This naming sounds good enough, just I'm not sure if such a difference between two variants would not make the code less readable. Alfter all both of them are doing the same thing. What I don't get is why are you proposing to change return value from Seq& to void. I think it is easier fo write to_lower(trim(to_upper(s))); then to_upper(s); trim(s); to_lower(s); > > > > This sounds interesting. I have seen your library in the sandbox, and I've > > even > > written a mail to Jeremy who I thought is a co-author of the lib. > He is. But he's pretty busy (aren't we all?). Anyway, it was Jeremy's idea > to > use free standing functions s.t. pairs of iterators could be used and he > laid the basic > tagging mechanism. The free-standing functions also made array support > possible (which will make builtin arrays a _lot_ > more useful), so I added that and implemented most of the algorithmic stuff > and a > 1000+ lines of test. We still need concept checks and some assertions, but > it has to way till > the traits are running on more platforms. > > > I'm open to any ideas, but I consider compatibility with compiler like > > VC6/7 > > as an important issue. But I coudl be possible to #ifdef sensitible code > > and > > keep at least the core of the lib to be usable for everyone. > > > > It would be nice If you can provide me with more details about your work. > > As I see it, the free standing begin()/end() stuff would be beneficial to > you, and perhaps > many others. Let's assume that they we're working. Then you would implement > the iterator range version of the algorithms (as you already did) and the > forwarding > in the container versions would use the free-standing begin()/end() and you > would automatically > get support for pair of iterators and arrays too. > > I guess we could just make some defines at present s.t. you could use > begin/end in your code > and on compilers with enough support one would be able to use everything. > > In that case I guess the traits should be moved to a seperate header, to > make it more appropriate > for different libraries to use it. BTW, the array_traits was written a long > time ago by Dietmar Kuehl. Well what I do now is to move the usage of .begin() and .end() outside from the functions, so they can be adapted to your lib when it will be ready. I can you defines as you are proposing for instance. There could be a define which would allow user to choose which version to use. That way it would leave the way open for your impoved version and it would still be possible to use it on a platform where new containter lib is not available. I'll try to think about it, it should not be a big deal. Anyway I would definitely like to support your container lib. I like it and it would add an interesting functionality to the string lib with almost no cost. > Anyway, I think the main problem is this statement: > > template< typename T, size_t > > struct some_traits; > > template< typename T, size_t sz > > struct some_traits< T[sz] >; // bad bad bad on vc6/7 > > Unfortunately I don't know a workaround :-(. I haven't tried to add traits to my lib yet. But as I see from discussion I would prefer to have them as something optional so that the compatibility issues with some compilers would not cause the lib unusable. Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
On Sat, Nov 16, 2002 at 03:46:07PM +, Alisdair Meredith wrote: > Pavol Droba wrote: > > To pick on a function at random... > > >Seq ltrim( const Seq& Input, const std::locale& Loc=std::locale() ) > > Why the default to std::locale? > > In typical use, I expect Seq to be an instantiation of > std::basic_string. Given this is a string library, what motivation is > there to support other containers? If none, then why not default to > locale of the string-type? > Library is about the string operations, but I see no reason to limit them to basic_string. In many occasions these functions can be used with other containers as well. But I can provide specialization for basic_string which will use its default locale. Would this be sufficient for you? Regards Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] String algorithm library
On Fri, Nov 15, 2002 at 01:12:59PM -0500, Rozental, Gennadiy wrote: > > Trimming: > > > >Iterator trim_begin( Iterator InBegin, Iterator InEnd, > > const std::locale& Loc=std::locale() ) > >Seq ltrim( const Seq& Input, const std::locale& Loc=std::locale() ) > >Seq& ltrim_in( Seq& Input, const std::locale& Loc=std::locale() ) > >Seq rtrim( const Seq& Input, const std::locale& Loc=std::locale() ) > >Seq& rtrim_in( Seq& Input, const std::locale& Loc=std::locale() ) > >Seq trim( const Seq& Input, const std::locale& Loc=std::locale() ) > >Seq& trim_in( Seq& Input, const std::locale& Loc=std::locale() ) > > 1. I would prefer explisit names: trim_left, trim_right,... I'm open for discussion about this. You are probably right. More peaole were asking for more readable names. I will probably rename them soon. > 2. Where do you specify what to trim? What If I want to trim "<>" This is good point. Currently you can override isspace function, I think I can provide variants with explicit predicate so everyone can write one he needs. > 3. why do we need not _in functions? > If you want it that bad you could do something like: > Seq& trim_copy( Seq& input, Seq& trim_func( Seq&, const std::locale& ) ); I have tried to explain my reasons in the other mail. Please try to consider them. Generaly speaking I link functional approach of programming and non-modifying transformatios are part of it. Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] String algorithm library
On Fri, Nov 15, 2002 at 06:57:47PM +0100, Thorsten Ottosen wrote: > - Original Message - > From: "Pavol Droba" <[EMAIL PROTECTED]> > > > bool contains( const Seq1& Input, const Seq2& Prefix, BinaryPredicate > Comp ) > > BTW, contains is one of the new proposed algorithms. It would be double work > to provide > it here. Well, it is already there. When a new standard will come up, it is nothing easier then to remove it. But until then, I see no reason why to not allow is in here. Regards Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] String algorithm library
On Fri, Nov 15, 2002 at 06:47:35PM +0100, Thorsten Ottosen wrote:
> >Seq rtrim( const Seq& Input, const std::locale& Loc=std::locale() )
> >Seq& rtrim_in( Seq& Input, const std::locale& Loc=std::locale() )
> >Seq trim( const Seq& Input, const std::locale& Loc=std::locale() )
> >Seq& trim_in( Seq& Input, const std::locale& Loc=std::locale() )
>
> I would find it more naturally to say
>
> string s = ...;
> trim( s );
>
> than to use 'trim_in()'. I think the functions that return a new 'Seq'
> should be the special cases, perhaps
> just with an appended underscore? Or maybe we should rely on that there is
> only one version of trim etc.
> and we would do
>
> string s2 = s;
> trim( s2 )
>
> instead of
>
> string s2 = trim( s );
>
> ? I guess could be considered for the rest of the library and I think It
> would simplify usage too, since it
> destinguishes between queries and commands. The prototype would then just be
>
> void trim( Seq& input, ... );
>
Well I have reasons to put it in the way I did. Rationale was to allow usage of the
functions in fuctional way. I consider it quite natural to write something like
if ( to_lower(trim(s)) == "OK" )
{
// do somethign with original s
}
There are many cases like this in which you probably don't want modify input sequence.
So in the functional approach when you usualy stack multiple transformation in one line
especialy in conditions. When expression gets complicated it could be quite anoying
and
less readable to use variants with suffix of prefix.
While using the functions for in-place transformations is usually done in the separate
line
and if the function has some suffix, it ususaly does not matter because expression is
separated.
The expample above partly explains also the reason why in-place variants return
reference
to the container. This way it is easier to write
to_lower_in( trim_in( do_some_other_transform( s ) ) )
maybe the suffix _in is not the best, and i'm open to any suggestions, but I like you
to
consider my reasons to keep non-modifying variants as default.
> > Predicates:
> >
> >bool start_with(
> > InputIterator Begin, InputIterator End,
> > SubIterator SubBegin, SubIterator SubEnd,
> > BinaryPredicate Comp )
> > bool start_with( const Seq1& Input, const Seq2& Prefix, BinaryPredicate
> Comp )
> > bool end_with( const Seq1& Input, const Seq2& Prefix, BinaryPredicate
> Comp )
> > bool contains( const Seq1& Input, const Seq2& Prefix, BinaryPredicate
> Comp )
>
> I think the names should be 'starts_with' and 'ends_with', right?
>
Thats a good point. I can easily fix this
> BTW, much of the argument passing resembles what will be possible in the new
> container algorithms I'm working on.
> I guess you might just forward 'Seq.begin()' and 'Seq.end()'. In the
> container
> algorithms it will be possible to say
>
> inta[] = ...;
> pair p =
> vectorv = ...;
>
> for_each( array, print() );
> for_each( p, print() );
> for_each( v, print() );
>
> What is relevant here is that the code below does not call .begin()/.end(),
> but overloaded
> freestanding begin() / end() functions. If your code should work with char
> arrays or iterator ranges,
> then you could benefit from the container algo. begin/end functions
> approach. However, there is a big problem, namely that
> the container algorithms don't work on eg. VC6/7.
This sounds interesting. I have seen your library in the sandbox, and I've even
written a mail to Jeremy who I thought is a co-author of the lib.
I'm open to any ideas, but I consider compatibility with compiler like VC6/7
as an important issue. But I coudl be possible to #ifdef sensitible code and
keep at least the core of the lib to be usable for everyone.
It would be nice If you can provide me with more details about your work.
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] String algorithm library
utIterator Begin, InputIterator End,
MatchIterator MatchBegin, MatchIterator MatchEnd,
OutputIterator Output,
BinaryPredicate Comp )
InputSeq erase_first(
const InputSeq& Input,
const MatchSeq& Match,
BinaryPredicate Comp )
InputSeq& erase_first_in(
InputSeq& Input,
const MatchSeq& Match,
BinaryPredicate Comp )
void erase_all(
InputIterator Begin, InputIterator End,
MatchIterator MatchBegin, MatchIterator MatchEnd,
OutputIterator Output,
BinaryPredicate Comp )
InputSeq erase_all(
const InputSeq& Input,
const MatchSeq& Match,
BinaryPredicate Comp )
InputSeq& erase_all_in(
InputSeq& Input,
const MatchSeq& Match,
BinaryPredicate Comp )
Regards,
Pavol Droba
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
