[boost] Re: [regex] Escaping a search string?
John Maddock wrote:
>> Given that I have a string 's' from somewhere, I'd like to create a
>> regular expression where some part must match that string. The
>> problem
>> is, the 's' could contain characters that have a special meaning in
>> regular expressions. Is there some support function that can provide
>> an escaped version of 's'? Something that transforms "my.*string"
>> into "my\.\*string"? If there isn't, would it be possible/easy to
>> provide one?
>
> Good question, no there isn't, but how about:
>
> std::string escape_regex(const std::string& s)
> {
> static const std::regex e("[\\[\\]$\\^|.+*?(){}]");
> return regex_merge(s, e, "$&");
> }
>
> Just off the top of my head and untried
>
> I'll try and think up something more general that works with all the
> flag settings though...
Front end localization could change this also, I believe. For instance if a
dll or message catalog substitutes '!' for '$' wouldn't I need to escape '!'
instead of '$' in order to use '!' as a literal in an expression ?
In this regard it would be helpful if the end-user could obtain back at
run-time the substitutions that are made due to localization. I didn't see
this as a function of the regex_traits class reference but maybe it is
there.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem: basename
Beman Dawes <[EMAIL PROTECTED]> writes: > At 11:32 AM 8/6/2003, David Abrahams wrote: > > > >I think this is a badly-chosen name. Both POSIX and Python have a > >basename function which does roughly what our leaf() function does. > > > > ... > > > >I don't think we should use creative naming in cases like this one. > > The naming scheme based the root/branch/leaf tree metaphor was > carefully worked out and reviewed over a long period of time. My argument here is only against basename. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
John Maddock wrote: I'm wondering how complicated to make this - one option would be to do something a little like the config system does and have: #ifdef BOOST_ABI_INCLUDE #include BOOST_ABI_PREFIX #endif // code... #ifdef BOOST_ABI_INCLUDE #include BOOST_ABI_SUFFIX #endif Some of those warnings can get pretty pesky at times Yes, and it is nice to get rid of them, but they may end up being library specific. e.g. date_time causes tag used before definition but does that mean its worth disabling that for all boost headers in BCB? Does adding codeguard info break the ABI? I didn't think it did so (there are no codeguard protected std libraries for example), and I mix and match codeguard and non-codeguard code all the time without any apparent issues... Not sure, I just put it in to play safe. If you've had no issues with it, then I guess not. Providing they share the same RTL (which they should) or memory is allocated and deleted by the same RTL, then it shouldn't affect CodeGuard. I'm slightly tied up this week, but I'll try and add something to regex and see how it looks. I'm not sure how to proceed with this so if there is anything I can do in the meantime, let me know. Feel free to e-mail me off the list. Thanks Russell ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Proposed smart_handle library
--- Andrei Alexandrescu <[EMAIL PROTECTED]> wrote: > This approach is definitely sound, except that you > need to write quite some > scaffolding (ctors etc. etc.) for each handle > wrapped. With a policy you can > put the scaffolding in one place and then write only > the stuff that varies. > In the particular case of handles, maybe there's not > a ton to wrap there, > but if you want to be generic as the original poster > suggested, you do need > to use parameterized types. > > Ah, one more point that was discussed... there was > much around operator-> > and operator* which don't make sense for certain > resources. With Loki's > SmartPtr, you can disable these two functions. > Granted, the error message > would be different, such as "get_reference not > found" as opposed to > "operator* not found". Would this be a major issue? > There is a discussion going on about a GUI/GDI template library. I think a smart handle library would be useful there. IMHO the policy/traits based approach is the way to go, actually not just for the smart_handle library, but for any boost library that needs to access platform specific features. Just my $.02. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI sublanguage ?
> Adobe has a tool called ADM - Adobe Dialog Manager, which is used in many > of their > programs. You can see the docs for ADM in (for example) the Acrobat SDK, > since > you can use ADM when writing plugins for Acrobat. > > In ADM, you define your dialogs in a text-based format, giving control > types, sizes, > and text, and ADM lays out the dialogs, and passes information back to > you based on > what the user does. > > The big advantage here is that all the layout "smarts" are in one place, > and they match > the IU guidelines of the platform that the program is running on. > > The disadvantage is that if you want to do something that is not > supported by ADM, > you have to call the platform APIs, and your portability is shot. After having followed this thread I wander if we are trying to reinvent the wheel. By googling a bit one can find plenty of "Gui Toolkits" and here I saw little of them. Not a word on Qt, for example. I never used it for an important project but they give a (good ?) solution for example to the layout issues discussed so far. If I should criticize them (as a lazy user who is in troble finding his way among all those features) if the fact that there are huge classes that probably need further decomposition of resposibilities. Anyway Qt make life simple for simple apps and provides something that scales quite well for larger projects (I haven't used it but I can use KDE as witness). So I would like to have a clearer idea of the difference between the goal of this thread and existing solutions (i.e. Qt). regards ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: swappable user defined types and STLport libraries
At 01:01 PM 8/6/2003, Fernando Cacciola wrote: >> I'd like to be sure that some Booster signs up for this beta and starts >> running the Boost regression tests against it. And then follows up with >> bug >> reports to Borland as needed. Any bugs fixed in the compiler before it >> ships are bugs Boosters don't have to cope with later. >> >> Any volunteers:-? >> >I signed for it already. Good! The more the merrier. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: swappable user defined types and STLport libraries
At 12:55 PM 8/6/2003, Russell Hind wrote: >Beman Dawes wrote: >> >> I'd like to be sure that some Booster signs up for this beta and starts >> running the Boost regression tests against it. And then follows up with >> bug reports to Borland as needed. Any bugs fixed in the compiler before >> it ships are bugs Boosters don't have to cope with later. >> >> Any volunteers:-? >> > >I've signed up, but don't know when we will here if we've been accepted >or not. If I am, I'd be happy to take on the regression test role for >BCB (and submit bugs etc) Good. If for some reason they don't accept you, let me know privately and I'll email their rep on the C++ committee (who has been supportive of Boost in the past.) In the meantime, you might want to try running the regression tests using any compiler you have at hand. While we are doing much better with docs, etc., running the tests still take a bit of getting used to. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
I'll be working on setting up the Notus (code name) project on sf tomorrow. I think that I've got some solid ideas on the basic design (I have been thinking on the design for a while before I posted the idea to the boost list and this discussion helped me immensely). I'll present it on the project's site and we can discuss it there. I won't be able to pull it off by myself in a reasonable ammount of time. Hope you guys will join. Brock, Philippe, everyone interested, are we up to this challenge? Anyway, now is your last chance to change the project code name or convince me that the whole idea is just plain stupid. ;) Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: swappable user defined types and STLport libraries
Alisdair Meredith wrote: > > I am still not clear on the 'best' solution though. > Clearly the quickest fix is to simply put the swap specialization in > the correct namespace. > > However, boost code does not seem to specialize std::swap at all, but > rather provide its own swaps in namespace boost. Is this the > preferred approach? [using my own namespaces, obviously!] http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#226 Summary: at present, the "best practice" is swap() overload in the class namespace and using std::swap; swap(x, y); at point of use. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: UI++ [was: GUI sublanguage; Re: Re: Re: Re: GUI/GDI template library]
In article <[EMAIL PROTECTED]>, Brock Peabody wrote: >> >> I suggest taking maybe some classes of WxWindows or Qt for basic > portable >> [x1, y1, x2, y2] paint devices. This would be a beginning. > > I'm sure we could learn something at least. Note: Qt is GPL, WxWindows is (modified) LGPL. Obviously, there are potential licensing issues with creating a new implementation modeled after GPL/LGPL code. Studying the interfaces and documentation is probably fair game, but copying from the source has license implications for your library. On the other hand, if you create a derivative work that links to low level classes of one of these existing libraries, you could release an initial prototype under the matching library license, then later replace the low level classes with your own and change the license to a boost compatible one. Steve ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
Beman Dawes wrote: I don't think people were against the idea of solving the problem, but rather there is a need for a unified prefix/suffix header solution such as John is suggesting. Developers need a "canned" solution; they can't be asked to code #ifdefs and pragmas for compilers they know nothing about. I thought people were against it for reasons of setting up test cases and such, not because of the implementation. At the time, I assumed it would be a pre-header and post-header for each compiler supported under boost. In that case, it would be good thing to get in for the 1.31.0 release if possible. I can supply the options for Borland but not other compilers. Thanks Russell ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Files of types *.ipp are unfriendly, especially to MSVC ?
Many thanks for this - works for me too.
HKLM\SOFTWARE\Microsoft\VisualStudio\7.1\Languages\File Extensions.ipp"
{B2F072B0-ABC1-11D0-9D62-00C04FD9DFD9}
makes it edit like .cpp
But I still doubt if files should be called .ipp.
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Randy Bowen
| Sent: Friday, August 08, 2003 6:05 PM
| To: Boost mailing list
| Subject: RE: [boost] Files of types *.ipp are unfriendly, especially to
| MSVC ?
|
|
| On the specific issue of MSVC integration: Assuming you're using MSVC
| 7.[01], the mapping of file extensions to editors is declared in the
| registry. Specifically, the entries under
| "HKLM\SOFTWARE\Microsoft\VisualStudio\7.1\Languages\File Extensions" are
| extension keys whose default value is the CSLID of the editor. So
| simply creating a new entry for ".ipp" and copying the CLSID listed for
| ".cpp" will give you your C++-specific editing features in MSVC. (We do
| this as part of our standard installation here, since ".tpl" is an
| standard extension for template implementation files internally.)
|
| Whether use of ".ipp" as a standard extension is a good idea is, of
| course, a different discussion.
|
| Randy Bowen
| Stamps.com
|
|
|
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: time_duration bug in Boost 1.30.0
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes | Sent: Friday, August 08, 2003 1:31 PM | To: Boost mailing list; [EMAIL PROTECTED] | Subject: Re: [boost] Re: Re: time_duration bug in Boost 1.30.0 | | | At 05:27 PM 8/7/2003, Bo Persson wrote: | > | >"Paul A. Bristow" <[EMAIL PROTECTED]> wrote: | > | >> | >> (And other MS specific unhelpful warnings which could be dealt with | >by | >> | >> #ifdef _MSC_VER or BOOST_? | >> #pragma warning (disable : 4800) // inefficient bool conversion? | >> #endif | >> | >> As a general point, is there any reason why 'known to be unhelpful' | >> warnings like this cannot be disabled in Boost code? | >> | > | >A problem here is that the "inefficient bool conversion" often | >actually *is* an inefficient implicit conversion to bool. IME, most of | >these warnings can be removed by actually producing a bool value. | >Adding == 0 or != 0 is often all it takes. | | FWIW, I've done that for years in my own code, and have come to believe | that it results in better code. It makes the intent clear to someone | reading the code. With an implicit conversion, a reader is unsure whether | or not the conversion was intended. | | To answer Paul's question, some of the toolsets do disable "known to be | unhelpful" warnings. But I agree with Bo that this warning shouldn't be one | of them. | | --Beman Agree with everything the previous speakers have said. Can we document our preference for Boost code to compile warning free in strict mode (MSVC, correct for loop scope, no language extensions and warnings level 4)? I sense that accepting the MS defaults(incorrect for loop scope, language extensions and warnings level 3) is not setting the bar as high as we reasonably could. Of course, it won't always be possible, but from much Boost code, I believe that with a very small additional effort by authors, much code could meet this standard. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Files of types *.ipp are unfriendly, especially to MSVC ?
Spirit and date_time use some files of type *.ipp (they are included 'internally'). I had the misfortune to be reading one using MSVC which does not recognize this as a C++ type and so they are not shown in color, nor laid out etc. Although these are 'private' detail files, I wonder if *.ipp should be deprecated for Boost code? I also found that one date_time file gregorian_calender.ipp includes 0D 0D 0A sequences which double spaces it and, more confusingly, confuses the MSVC IDE editor so that warnings appear on the wrong line :-( (Perhaps Jeff Garland would like to fix this in gregorian_calender.ipp sometime?) I understood that a check program had been devised for this 'mis-feature'. Was this missed because it is not a C++ type 'known' to the checker program? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release Manager's Checklist added
Daniel Frey wrote: > The trackers are IMHO a problem because they require a lot of work. The > current state shows that it is not maintained well, e.g. there are open > bugs which are long closed in CVS, see #451535. Sure we could do better > in theory, but is it worth it? Why not use regression tests to track > bugs? AFAICS people pay a lot of attention to the regression tests and > the whole systems work pretty well. > Also, I hope that it could make the release manager's work easier to > have fewer sources to track :) > OK, what do others think? Am I the only one who feels uncomfortable with > the SF-trackers? The tracker is worse than useless if it is not actively supported. Boost users who do not subscribe to the lists will submit bugs through them, and wonder why they don't get the feedback they expect. If bugs are never marked closed, as you say, it looks bad on the project. OTOH, regression tests are only good for the conditions they test for. If we expand the tests to cover every potential bug, I suspect we will not have enough computers to run them on. Bug trackers let you record and deal with bugs that are not part of the main-line regression suite. As you can see, I am neither for-nor-agianst the bug tracker. But I do think we need to either adopt it, or disable it somehow. It should not be left as some half-way house. -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI sublanguage ?
Because for a pretty large number of applications you can really
simplify your code a lot by relying on the GUI system to 'do the right
thing':
using boost::gui;
void my_action() {...}
void progress_action(int tick) {...}
gui::show( "sample boost application",
column ( button ("click it", &my_action),
progress (100, &progress_action)));
There are a lot of good reasons why we would not always want to have
total control. I want my applications to be as simple as possible, and
to all look the same. If the GUI library picks the 'best' settings for
the platform automatically, the individual programmer doesn't have to
think about it. Everything just works like it should. To take a few
things from your snippet that are suspect to me:
> w.width( 400 );
> w.height( 200 )
Where do 400 and 200 come from? This seems arbitrary to me. The GUI
system should be able to tell how to size itself.
> b.align( alignment::vcenter | alignment::hcenter );
A real world application needs much more sophisticated positioning
mechanisms than this. The tiny snippet above (in my code) hides some
pretty good positioning logic.
> pb.min( 0 );
> pb.max( 100 );
> pb.step( 5 );
> pb.smooth( true );
Again, these values should be picked automatically.
Now, it might be cool to be able to change my above code to:
gui::show( "sample boost application",
...
Where you can have specified such things as whether or not your progress
bars are smooth and what the step size is. Maybe you could even do it
at run-time.
get_my_company_gui_traits().show("sample boost application",
...
My motivation for the design of this again:
- GUI code is difficult, tedious, and error prone even for simple tasks,
I want to make it simple (for simple tasks)
- control positioning is especially difficult
- Consistency in GUI applications is difficult. Give ten programmers a
lower level GUI API and they'll turn out ten applications each with a
different look and feel. I don't want to have to remember that step
size for our company is always '5', for instance.
If we head in the direction we've been talking we would also provide a
cross platform lower level API where you could get more control and do
things like what you describe below. I hope that most programmers would
find it unnecessary though.
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Bohdan
> Sent: Wednesday, August 06, 2003 2:31 PM
> To: [EMAIL PROTECTED]
> Subject: [boost] GUI sublanguage ?
>
> Recently there was idea about "spirit-like" dialog sublanguage
> implemented in c++. I still can't get why someone may need
> it ?
> Spirit is forced to use such language to build QUOTED code, which
> works only when parsing occur. In case of GUI lib
> sutiation is different :
> We are not building code, but tree of gui objects placed in
> 2d (+z order). Sure boost::gui should deal with actions,
> but generally they are much more compicated than spirit ones
> and can't be easyly implemented by binders/bll/phoenix.
> Besides, average gui control has a lot of properties which
> may change in runtime. Would be convenient and
> effective to fill/change such properties using spirit like
> language ?
>
> Why invent new shape for wheel ? :
>
> void my_action( component & sender )
> {
> show_dialog( "sender is " + sender.title() );
> }
>
> main()
> {
> window w;
> w.title("sample boost application");
> w.width( 400 );
> w.height( 200 )
>
> button b;
> b.title("click it!");
> b.on_click.connect( &my_action );
> w.insert( b );
> b.align( alignment::vcenter | alignment::hcenter );
>
> progress_bar pb;
> pb.align( alignment::bottom );
> pb.min( 0 );
> pb.max( 100 );
> pb.step( 5 );
> pb.smooth( true );
> w.insert( pb );
>
> w.show(); //or w.show_modal();
>
> window::main_loop();
> }
>
> regards,
> bohdan
>
>
>
> ___
> 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: GUI sublanguage ?
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Joel de Guzman
> Sent: Wednesday, August 06, 2003 5:51 PM
> To: Boost mailing list
> Subject: Re: [boost] Re: GUI sublanguage ?
>
> Brock Peabody <[EMAIL PROTECTED]> wrote:
>
> >> Have you invented universal algorithm for window size/position ?
> >
> > It works surprisingly well. I know I described it in detail in an
> > earlier post, I can sum it up again if you like. It works well
> > especially if you need complete resizability.
>
> Please do. I've lost track of the thread and I want to catch up.
When we first started doing GUIs, we put things exactly where we wanted
them :) We would either disallow or ignore resizing. This is the type
of sizing logic that is promoted by RAD tools. Eventually you find that
you can't ignore the issue.
Our first attempt at a sizing 'algorithm' was that everything in a
window was sized proportionally as the window grew and expanded. This
led to cartoonish screens at large sizes.
The reason is that some controls benefit from increased size and others
don't. More specifically, each type of control usually has a minimum
and maximum desired size for each dimension (sometimes the maximum is
unlimited). Examples:
static text - fixed size horizontally and vertically
line edit - fixed size vertically. Minimum of one character
horizontally and unlimited size horizontally.
masked edit - both horizontal and vertical sizes can be fixed based on
the mask.
The earliest version of this library was concerned strictly with laying
out controls.
Each layout composition function returns an object that can be
positioned in a rectangle, and can tell you what its desired size is for
each dimension. If you pass a plain window to one it will 'wrap' it for
you. The objects returned by the composition functions can in turn be
passed to other composition functions (or themselves recursively).
row(x, x1, ... xn) - positions its components one after another
horizontally. Space is allocated first for 'minimum sizes'. Left over
space is split evenly among components with no maximum, or with maximums
that are greater than their minimums.
column(y, y1, ... yn) - same as row but vertically
grid(c0, c1, ... cn) - sometimes it is important for
the elements in subsequent rows to 'line up'. You can use the grid
function impose more strict sizing than is possible with combinations of
rows and columns.
I realize that this scheme won't solve all the world's problems, but it
comes close :) You can imagine that one could come up with more
composition functions, I just haven't needed any yet.
This positioning library began evolving into a complete GUI library when
I realized that I could allow the inline definition of static text
controls, and get rid of them completely:
row ("label: ", some_control);
After that I wanted to get rid of more controls and define them all
inline.
I hope I explained that well. My communication skills could be improved
:)
Brock
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: question regarding boost array
Robert Ramey wrote: > Currently boost array contains a copy of the array that initialized it. > Is there any reason that boost array can't be enhanced to contain a reference > to the original C array? I think this would make it more useful > to me as well as others. I don't see the problem. boost::array is not a wrapper around an existing array, it IS an array. In the same way, std::vector does not take ownership of any existing memory you may want to initialise it with. I am not sure what you are trying to achieve, why do scoped_array or shared_array not serve in this case? -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MSVC7.1 bug not yet fixed
Dave, I've just downloaded 1.30.1 and the bug I reported a while ago http://aspn.activestate.com/ASPN/Mail/Message/boost/1622190 (Missing BOOST_HAS_THREADS on MSVC with /Za and /MT) is still there. I don't know config at all but if nobody else has time I'll try to submit a patch (I believe it'd be less than half an hour for someone knowing config). Just let me know. Thanks & Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Release Manager's Checklist added
I've added a detailed Release Manager's Checklist (boost-root/more/release_mgr_checklist.html). It will take up to 24 hours for this to be reflected on SourceForge's public CVS (although it is available right away for those with write access). There are five items on the checklist that take up the bulk of the release manager's time (see abbreviated descriptions below). The release manager is near exhaustion by the time these are complete. I think we need to figure out a way to delegate this management effort to more people. (There are already quite a number of people helping with bits and pieces of the overall process, but we need to formalize that a bit more, IMO, so the release manager doesn't get lost in the details.) --Beman * Monitor inspection report to verify problems are being dealt with. * Monitor regression tests to verify that errors are dealt with. * Monitor mailing lists to verify that patches are being dealt with. * Monitor mailing lists and bug tracker to verify that bug reports are being dealt with. * Monitor CVS commits to verify content gets committed as planned. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_2 tagged for release
David Abrahams wrote: It appears that the tagging step for Version_1_30_1 got messed up somehow. Please have a look at RC_1_30_2, which is our release candidate for Version 1_30_2, and let me know if there are any problems. I'm not able to run the Linux regression tests on that branch. process_jam_log fails due to an out_of_range being thrown from basic_string::substr. Probably, some files are still missing for the tests to work properly. The same is true for the 1.30.1 release. I'll try to investigate that tomorrow. Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Patch to emacs cc-mode for template syntax andindentation
"Neal D. Becker" <[EMAIL PROTECTED]> writes:
> On Monday 04 August 2003 10:43 pm, David Abrahams wrote:
>> If anyone's interested, the enclosed patch against the current CC-mode
>
> Did you send this to cc-mode maintainer?
Yes, via C-c C-b:
C-c C-b runs the command c-submit-bug-report
which is an interactive compiled Lisp function in `cc-mode'.
It is bound to C-c C-b.
(c-submit-bug-report)
Submit via mail a bug report on CC Mode.
I know it's probably not the best channel, but I know he's listening
there.
Also, [EMAIL PROTECTED]
Why should I care about xemacs? It can't even byte-compile the
recent GNUs stuff.
Compiling file c:\src\gnus\xlisp\deuglify.el at Tue Aug 05 10:02:04 2003
While compiling toplevel forms:
!! error (("As of 20.3, `concat' no longer works with compiled-function objects"
# "
gnus-summary-extract-address-component Newsgroups "=> " 23 0 " " "
" gnus-tmp-header gnus-tmp-from header gnus-newsgroup-charset gnus-summary-buffer
gnus-newsgroup-ignored-charsets mail-parse-ignored-charsets mail-parse-charset
gnus-ignored-from-addresses newsgroups to extra-headers
gnus-decode-encoded-word-function val gnus-tmp-closing-bracket gnus-mouse-face-prop
gnus-mouse-face gnus-tmp-subject-or-nil] 11>))
!! error (("As of 20.3, `concat' no longer works with compiled-function objects"
# "
gnus-summary-extract-address-component Newsgroups "=> " 23 0 " " "
" gnus-tmp-header gnus-tmp-from header gnus-newsgroup-charset gnus-summary-buffer
gnus-newsgroup-ignored-charsets mail-parse-ignored-charsets mail-parse-charset
gnus-ignored-from-addresses newsgroups to extra-headers
gnus-decode-encoded-word-function val gnus-tmp-closing-bracket gnus-mouse-face-prop
gnus-mouse-face gnus-tmp-subject-or-nil] 11>))
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Gregory Colvin > Sent: Wednesday, August 06, 2003 4:48 PM > To: Boost mailing list > Subject: Re: [boost] GUI/GDI template library > > Why the S? > > On Wednesday, Aug 6, 2003, at 16:37 America/Denver, E. Gladyshev wrote: > > > > > --- Brock Peabody <[EMAIL PROTECTED]> > > wrote: > > > >> That sounds good. What if we called the lower layer > >> boost::gui and the > >> upper layer boost::sgtl? It stands for 'standard'. Maybe that's a little pretentious for us at this early stage :) gtl would probably be better. I suspect that if we get to a review some people may request something more verbose. Brock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: time_duration bug in Boost 1.30.0
"Paul A. Bristow" <[EMAIL PROTECTED]> wrote: > > (And other MS specific unhelpful warnings which could be dealt with by > > #ifdef _MSC_VER or BOOST_? > #pragma warning (disable : 4800) // inefficient bool conversion? > #endif > > As a general point, is there any reason why 'known to be unhelpful' warnings > like this cannot be disabled in Boost code? > A problem here is that the "inefficient bool conversion" often actually *is* an inefficient implicit conversion to bool. IME, most of these warnings can be removed by actually producing a bool value. Adding == 0 or != 0 is often all it takes. Bo Persson [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: smart_assert - update; SMART_ENFORCE works
Hi Michael,
Sorry for the late reply...
>
> A postcondition such as I'm suggesting would perform an assertion when a
> function (or the enclosing block) exits instead of on the line where the
> assertion was defined. Obviously, if a function only has one exit path, it
> would be simple just to put assertions at the end of the function, but if
a
> function has multiple exit points, this would be inadequate.
>
> An example of what I mean is something like this (where SMART_ASSERT_POST
is
> the new postcondition assertion that I'm suggesting):
I'm not sure we need this.
It's much simpler to have something like:
struct on_exit {
template< class function>
on_exit( function f) { ... }
~on_exit() { call function }
private:
...
};
and in code:
// something similar to
on_exit exit( mem_fun( &SomeClass::CheckClassInvariants) );
>
> class SomeClass(void)
> {
> public:
>
> void SomeFunction(void)
> {
> file://Precondition: check class invariants on function entry
> SMART_ASSERT(CheckClassInvariants());
>
> file://Postcondition: check class invariants on function exit
> SMART_ASSERT_POST(CheckClassInvariants());
>
> file://Function body here
> }
>
> private:
>
> bool CheckClassInvariants(void)
> {
> file://Return true if class invariants are met
> }
> };
>
> Another example would be something like this:
>
> int SomeFunction(int arg)
> {
> file://Precondition: check argument on function entry
> SMART_ASSERT(arg >0 && arg < 10);
>
> int result = 0;
>
> file://Postcondition: check result on function exit
> SMART_ASSERT_POST(ref(result) >= 0);
>
Using ..._POST could just complicate things.
Users should know to use, for each tested argument ref(...),
so you can come up with something like outlined above.
I'll think about it (something using lambda expressions).
Best,
John
> file://Function body here
>
> return result;
> }
>
> As far as how it would be implementated, as I suggested before, I assume
the
> post condition would create an object whose destructor asserts the
condition
> when the block the it is defined in exits.
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
