- Boost - lists.boost.org

operators.hpp bugs
by Søren Lassen 17 May '05

17 May '05

I have found a couple of "undocumented features" in operators.hpp: 1) The return values from a lot of the binary operators should be declared const, so that it is not possible to assign to the temporary object that results from the operation. An example: if(!(a/b=c/d))... This statement is obviously a typo. The assignment operator= should have been a comparison operator==. With the current definition of operator/ in operators.hpp, the compiler will not recognize this as an error. Instead, the following will happen: first, the values of a/b and b/c are calculated and placed in temporary objects. Then, the result of a/b is overwritten by the result of c/d. Finally, operator! converts that to a boolean and the if statement acts on it (in other words, the statement is probably interpreted as "if(!c)..."). If, on the other hand, the return value from operator/ is declared constant, the compiler will catch the error, and probably say something like "lvalue required". Much better. 2) I think the "Named Return Value Optimization" code is a misunderstanding. The way I read the excerpts from the C++ standard quoted in the documentation (see http://www.boost.org/libs/utility/operators.htm#symmetry) is as follows: The standard places some limits on when NAMED objects may be optimized away. From this follows implicitly that UNNAMED objects may always be optimized away. Or, to quote from Scott Meyers' "More Effective C++", page 109-110: "However, the fact remains that unnamed objects have historically been easier to eliminate than named objects, so when faced with a choice between a named object and a temporary object, you may be better off using the temporary. It should never cost you more than its named collegue, and, especially with older compilers, it may cost you less". In other words: some compilers may not have Named Return Value Optimization, but most of them have (Unnamed) Return Value Optimization, which means that temporary, unnamed objects are optimized away where possible. So, I think, a better way of writing e.g. operator+ is the good old-fashioned: template <class T> inline const T operator+(const T& lhs,const T& rhs) {return T(lhs) += rhs;}; 3) When using compilers that do not support operators in namespaces (#ifdef BOOST_NO_OPERATORS_IN_NAMESPACE), the operator templates are first placed in the global namespace, and then copied to the boost namespace. The consequence of this is that it is not possible to access the templates with a "using namespace boost;" declaration - trying to do so creates an ambiguity between the stuff in boost and the stuff in the global namespace. Also, of course, the global namespace is "polluted" with quite a lot of extra names. The solution to this problem is to declare all the templates inside a "pseudo-namespace" struct in the global namespace - this also makes it easier to import the templates into boost, as even the Borland compiler now recognizes a "using" declaration. I have uploaded a new version of "operators.hpp" with fixes for above-mentioned problems to the sandbox vault. It has been tested with "rational.hpp" on the Borland 5.5 compiler and the Microsoft version 13.10.3077 compiler (the one that comes with the free Visual Toolkit 2003, and also (I think) with Visual C++ 7.1). I hope that some of you have time to test my new version with other programs and compilers. --- Søren

5 20

char[] support in Boost.Range
by Pavol Droba 17 May '05

17 May '05

Hi Boosters, There was a discussion about char[] support in the Boost.Range library. The issue seems important and I'd like to express my ideas about a possible solution. First lets sumarize problems and goals. The problems: char[] and possibly any other type that can be used as a c-string (this includes wchar_t, but also int, long and etc when used as a unicode code-point) might represent two different things: 1.) c-string literal 2.) arbitrary c-array Both views differ in lenght calculation, which is totaly incompatible and what's worse, it can lead to casual access violation when used improperly. An example: char str[] = "Hello"; // typeof(str) is char[6], str=={'h','e','l',l','o',0} In the c-string view, str have 5 letters and ends at the 'o'. So the range should be <'H','o') In c-array view str is 6 elements long and ends with '\0' The range is <'H','\0') From the user perspective, both views are equaly important, however according to the usage scenarion, one might be preferable over the other one. Important aspect to keep in mind is this strict relativnes. For example for string algorithms c-string literal is obvious default, while for a data processing library the second choice is better. Current implementation is not ideal. First of all, there is a difference between char,wchar_t[] and the rest of the types. This brings some confusion. Secondly, it is not possible to use char[] as an ordinary array. The goals: From the problem analysis above, following goals can be implied 1. we need to support both views equaly 2. a user must be always able to explicitly specify what type of view he requires 3. it should be possible for a library writer to select default view for his library. However point (2) must hold, so the user must be able to override this default. 4. Support must be present in the Boost.Range library. It is not feasible to ask library writer to provide specific workarounds/hacks. It would simply break the idea of Boost.Range library as a unified interface to range-like data structures. The solution: I propose to have two free-standing functions as_string() and as_array() (naming is not important now). Both should have the same generic signature: template<typename RangeT> boost::sub_range<RangeT> as_string(RangeT& aRange); template<typename RangeT> boost::sub_range<RangeT> as_array(RangeT& aRange); By default, the functions only copy the input range to the target. However for the types like char[], the result will differ. For as_string() will create a sub_range delimiting string literal (using char_type<char>::length for instance), while as_array() will use compile-time boundaries. In addition we might consider to open this interface for user-defined type, even if I'm not sure how it can be used. Please note, that once any of these manipulators is applied to a range following application will have no effect. Lets see how this faicility can be used: A library writer can set the default by writting algorithm like this: template<typename RangeT> ... AnAlgorithm(const RangeT& aRange) { boost::sub_range<RangeT> StrRange=as_string(aRange); // Do something with StrRange } If a user calls AnAlgorithm directly: char str[]="hello"; AnAlgorithm(str); str will be converted to a range, delimiting a string_literal. However he can alse use as_array(): char str[]={'h', 'e', 'l', 'l', 'o'}; AnAlgorithm(as_array(str)); This time no conversion will take place, since as_array() returns sub_range. Note, that for the AnAlgorithm it does not matter what default is used in the Range library. Open questions: - I have intentionaly not included a proposal for the default view that the Range library should provide. Goal of this solution is to provide a way, that is not dependant on this. I'd like to leave it for the discussion. Right now it seems, that most of the people that entered discussion prefer c-array view. I would prefer c-string view, but I'm probably biased by the fact that I'm the author of StringAlgo library. - There is a space for possible extentions to the basic proposal. For instance, as_string() migh have the second parameter that will identify a terminator. - String literal lenght can be calculated in two ways. Either by using strlenght() (or alike), or using compile-time size (N) decreased by 1 (N-1). Later approach is faster and allows to specify literals like this: char str[]="hello\0bye"; But it is different from char* handling and therefor it might be confusing. Best Regards, Pavol

6 15

[preprocessor] What syntax to present to the user
by Loïc Joly 17 May '05

17 May '05

Hello everybody, I'm trying to use the boost preprocessor library to allow the user to define "rich" enums, for instance enums that cannot be converted to int, whose values can be displayed in human readable form on a stream... I think I have to use macro to ease the writing of such enums, and I decided it was a good occasion to learn boost::preprocessor. My first impression : Wow ! You guys really use magic when programming ! Now, I have to decide what will be the interfaces for such rich enums. My (unreachable) goal would be something like that : RichEnum Type{Val1, Val2, Val3}; A little bit more reasonnable (but still unacheivable, I believe) goal would be : RICH_ENUM(Type, Val1, Val2, Val3); I think I can come up with several possible writing : 1/ RICH_ENUM(Type, (Val1)(Val2)(Val3)); 2/ RICH_ENUM(Type, 3, (Val1,Val2,Val3)); 3/ #define NAME Type #define VALUES (Val1)(Val2)(Val3) #include "RichEnum.h" #undef NAME #undef VALUES 4/ same as 3/, but with tuple syntax for VALUES With 1/ and 2/, all the class declaration is on the same line, which could decrease debugability. With 3/ and 4/, I can write it one several lines. And now, the questions : Which writing do you think would be best ? Why ? Are there other possibilities I overlooked ? Is is possible to have a syntax like 1/ and 2/ with good debugability ? Regards, -- Loïc

2 3

Re: [boost] Re: char[] support in Boost.Range
by brangdon＠cix.compulink.co.uk 17 May '05

17 May '05

In-Reply-To: <20050516205339.GW11789(a)lenin.felcer.sk> droba(a)topmail.sk (Pavol Droba) wrote (abridged): > In addition I would suggest to remove direct support for pointer types > like char* from the range library and provide it only via as_string() > construct to definitely remove any kind of confusion. Sounds like a good idea. Are we going to generalise it to allow any (compile-time constant) terminator? If so, is as_string() the best name? -- Dave Harris, Nottingham, UK.

3 2

Re: [boost] Re: Re: char[] support in Boost.Range
by dan marsden 17 May '05

17 May '05

> > what's wrong with using boost::array<char,N> for all > this? > > -Thorsten > If boost::array<char,N> is not going to behave the same at char[N] in this respect surely that is counter intuitive? Wasn't there a fixed string type under consideration that could be applied the opposite way? ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

2 1

[wave] cw-8.3 segfault..
by Rene Rivera 17 May '05

17 May '05

Hartmut, Don't know is this will help at all.. But this is the stack trace for the crash for testwave built with CW-8.3: ========== > testwave.exe!boost::spirit::multi_pass_policies::buf_id_check::check() const(buf_id_check * this=0xcccccccc) Line 195 + 0xb C++ testwave.exe! ?? ?? :: ?? ::operator*(multi_pass * this=0x0012eb0c) Line 1005 C++ testwave.exe!?get@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_po(iteration_policy * this=0x0012eb40, scanner & scan={...}) Line 50 + 0xb C++ testwave.exe! ?? ?? :: ?? ::operator*(scanner * this=0xcccccccc) Line 251 + 0xb C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(char_parser * this=0xcccccccc, scanner & scan={...}) Line 50 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(kleene_star * this=0xcccccccc, scanner & scan={...}) Line 58 + 0x19 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(sequence * this=0xcccccccc, scanner & scan={...}) Line 54 + 0x16 C++ testwave.exe! ?? ?? :: ?? ::do_parse_virtual(concrete_parser * this=0x0012ed30, scanner & scan={...}) Line 233 + 0x11 C++ testwave.exe!?parse_main@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_m(rule_base * this=0x00138078, scanner & scan={...}) Line 189 + 0x19 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(rule_base * this=0xcccccccc, scanner & scan={...}) Line 172 + 0x48 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(optional * this=0xcccccccc, scanner & scan={...}) Line 54 + 0x16 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(sequence * this=0xcccccccc, scanner & scan={...}) Line 54 + 0x16 C++ testwave.exe!?do_parse_virtual@?$concrete_parser@U?$sequence@U?$sequence@U?$alternative@U?$alternative@U?$chlit@W4token_id@wave@boost@@@spirit@boost@@U?$pattern_and@W4token_category@wave@boost@@@util@wave@3@@spirit@boost@@U?$pattern_and@H@util@wave@3@@spirit@boost@@U?(concrete_parser * this=0x0012eebc, scanner & scan={...}) Line 233 + 0x11 C++ testwave.exe!?parse_main@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_m(rule_base * this=0x00138070, scanner & scan={...}) Line 189 + 0x19 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(rule_base * this=0xcccccccc, scanner & scan={...}) Line 172 + 0x48 C++ testwave.exe!?do_@?$@V?$tree_match@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@V?$node_val_data_factory@Unil_t@spirit@boost@@@spirit@4@Unil_t@(tree_match & result={...}, definition & def={...}, scanner & scan={...}) Line 262 + 0x16 C++ testwave.exe!?grammar_parser_parse@?$@$0A@Upredefined_macros_grammar@grammars@wave@boost@@U?$parser_context@Unil_t@spirit@boost@@@spirit@4@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave(grammar * self=0x0012f058, scanner & scan={...}) Line 281 + 0xf C++ testwave.exe!?parse_main@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_m(grammar * this=0x0012efec, scanner & scan={...}) Line 55 + 0x1f C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(grammar * this=0xcccccccc, scanner & scan={...}) Line 63 + 0x48 C++ testwave.exe!?pt_parse@?$@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@Upredefined_macros_grammar@grammars@34@@spirit@4@YA?AU?$tree_parse_info@(lex_iterator & first_={...}, lex_iterator & last={...}, parser & parser={...}) Line 229 C++ testwave.exe!boost::wave::grammars::predefined_macros_grammar_gen<class boost::wave::cpplexer::lex_iterator<class boost::wave::cpplexer::lex_token<struct boost::wave::util::file_position<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > > >::parse_predefined_macro( ?? )(lex_iterator & first={...}, lex_iterator & last={...}) Line 153 + 0x13 C++ testwave.exe!?add_macro_definition@?$@V?$context@V?$__wrap_iterator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PB$$CBD@std@@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@(context & ctx=, basic_string & macrostring=, bool is_predefined=, language_support language=) Line 154 + 0x4a C++ ========== All those this=0xcccccccc, is CodeWarrior's way of saying one has a refenrence to a deleted object. As that's the value it clears memory to when it deletes. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

3 7

[1.33] Program_options and Borland
by John Maddock 17 May '05

17 May '05

The following patches get Boost.Program Options compiling with Borland C++ 5.6.4 (it's enough to fix the regex grep test program which was what I wanted). Is it OK to apply these? I can't see how they would cause problems with other compilers: in fact I'm not at all clear how "cmdline" was ever found without the qualifier on other compilers. I haven't looked at the runtime test failures with this compiler yet (has anyone?), Regards, John. RCS file: /cvsroot/boost/boost/boost/program_options/detail/parsers.hpp,v retrieving revision 1.7 diff -r1.7 parsers.hpp 31c31 < : cmdline(to_internal(args)) --- > : detail::cmdline(to_internal(args)) 38c38 < : cmdline( --- > : detail::cmdline( 49c49 < cmdline::set_options_description(desc); --- > detail::cmdline::set_options_description(desc); 59c59 < cmdline::set_positional_options(desc); --- > detail::cmdline::set_positional_options(desc); 67c67 < cmdline::style(style); --- > detail::cmdline::style(style); 75c75 < cmdline::set_additional_parser(ext); --- > detail::cmdline::set_additional_parser(ext); 84c84 < result.options = cmdline::run(); --- > result.options = detail::cmdline::run();

2 2

boost::program_options INI file parsing
by Preston A. Elder 17 May '05

17 May '05

The INI file parser module of program_options needs to be changed. For some reason, the comment delimiter has been changed from ';' to '#'. The bigger problem is this has been taken beyond the first character of the line and there is no escaping ability! The more common INI file comment behavior is: '#' is a comment ONLY if it is the first character of the line ';' is a comment from that point of the line on, unless preceeded by a '\' (or more accurately, an odd number of '\' characters, since you could theoretically do \\\;, to translate to \; when made a string). I have written my own INI parser for my own purposes, but it is not associated with program_options, which makes its usefulness in that context limited (without a lot of extra coding, etc). You can view the source here: http://www.neuromancy.net/viewcvs/Mantra-I/src/file/inifile.cpp?root=mantra… My own implementation does differ from the standard INI file parsing convention in allowing line continuation, ie. Allowing: my_option = some text \ some more text And it is interpreted as 'some text some more text'. One big selling point of my implementation is that it uses boost::spirit (the lexical parser) to do the parsing - so the logic for parsing is encoded in the lexical parsing language, not in code. Theoretically, this means you should be able to use my implementation directly, and adapt the code from IniFile::Load() that uses it for program_options relatively easily, and not have to worry about the parsing logic itself. Otherwise (if you don't want to use a lexical-parser based implementation, or my version specifically), could we please stick to the standards, and allow '#' as a comment ONLY from the beginning of the line, and then ';' from any point in the line (as '#' is treated in the current version) (with the 'escaping' rules). Thanks, -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

6 7

[ptr_container] and bcc32
by Russell Hind 17 May '05

17 May '05

I'm trying the regression tests on bcc32 5.6.4. The first error (and often occuring one with bcc32) is in detail/static_move_ptr.hpp line 70 should be changed from static_move_ptr( const move_ptrs::move_source<static_move_ptr>& src ) to static_move_ptr( const move_ptrs::move_source<static_move_ptr<T, Deleter> >& src ) The next is in detail/reversible_ptr_container.hpp line 117 where typedef null_clone_allocator<allow_null> null_cloner_type; needs to be typedef null_clone_allocator<reversible_ptr_container::allow_null> null_cloner_type; The next is in ptr_vector.hpp line 43: BOOST_PTR_CONTAINER_DEFINE_NON_INHERITED_MEMBERS( ptr_vector, needs to be BOOST_PTR_CONTAINER_DEFINE_NON_INHERITED_MEMBERS( ptr_vector<T,CloneAllocator,Allocator>, And the same in ptr_deque. I guess this is the same for the other ptr_XXXX.hpp files (list,set,map etc). The next error I'm not so sure on is in tutl.cpp line 233: tut1.cpp: Error E2227 tut1.cpp 233: Extra parameter in call to boost::ptr_deque<animal,boost::heap_clone_allocator,_STL::allocator<void *> >::release() in function farm::sell_animal(boost::void_ptr_iterator<_STL::_Deque_iterator<void *,_STL::_Nonconst_traits<void *> >,animal>) Error E2034 tut1.cpp 233: Cannot convert '_STL::auto_ptr<boost::ptr_deque<animal,boost::heap_clone_allocator,_STL::allocator<void *> > >' to 'boost::ptr_container_detail::static_move_ptr<animal,boost::ptr_container_detail::clone_deleter<boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<animal,_STL::deque<void *,_STL::allocator<void *> > >,boost::heap_clone_allocator>::null_clone_allocator<0> > >' in function farm::sell_animal(boost::void_ptr_iterator<_STL::_Deque_iterator<void *,_STL::_Nonconst_traits<void *> >,animal>) Cheers Russell

2 13

RE: [boost] Re: Math constants - updated.
by Simon Li 17 May '05

17 May '05

> > On the other hand, the boost libraries have never, as far as I can > > tell, compromised on interfaces to accommodate programmers > who don't > > like templates or modern C++ idioms. [...] > > Why should the constants library be any different? Why should boost > > give physicists special consideration that most C++ > programmers do not > > get? > > There is nothing extraordinary about it. A library is > designed for clients, and it's sound to listen to what they > desire. If they don't like the product, they'll use > something else. That may or may not matter to you. > True, but a library should also be consistent within itself. The impression I get from Boost is that, as pointed out above, it tries to apply strong principals in the design of its interfaces. It also seems to have no qualms (and arguably makes a point) about using relatively recent c++ features (eg. template specialisations) rather than getting bogged down with established practice. IMHO if a user wanted a library using long established programming practice, they definitely wouldn't be using Boost. However, if for some reason someone really did want the constants library, they'd be free to rewrite it (and even release it) in a format they required... it's not as if the values of constants are likely to change :-) Simon This e-mail message (including its attachments) is private, is intended for the recipient named in it and may contain material which is confidential and privileged. No-one other than the named recipient may read, copy, rely on, redirect, save or alter the message or any part of it or any attachment to it in any way. VMS does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not represent those of VMS unless otherwise specifically stated. While reasonable effort has been made to ensure this message is free of viruses, opening and using this message is at the risk of the recipient.

1 0