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
[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] 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: 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 #compiled-function nil ...(147) [gnus-tmp-unread gnus-tmp-replied gnus-tmp-score-char gnus-tmp-indentation gnus-tmp-opening-bracket gnus-tmp-lines gnus-put-text-property format %c%4s: %-23s%c string-match 9 nil To - 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 #compiled-function nil ...(147) [gnus-tmp-unread gnus-tmp-replied gnus-tmp-score-char gnus-tmp-indentation gnus-tmp-opening-bracket gnus-tmp-lines gnus-put-text-property format %c%4s: %-23s%c string-match 9 nil To - 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] 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] 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
[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] 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
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 gridnumber of columns(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
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::showmy_company_gui_traits( 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
[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
[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
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] 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
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
[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: 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
