Re: [boost] Re: Re: Re: GUI/GDI template library
--- Bohdan <[EMAIL PROTECTED]> wrote: > "E. Gladyshev" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > Yes it is, but AFAIK it doesn't have cpp files. > std::streams really have cpp files and are part of > standart, > but if i don't mind they are not part of STL. Am i > wrong ? Maybe, I am not sure. > > > I repeat the gui library itself will contain > headers > > only (NO .cpp files). > > ... Here you are telling NO CPP in your library. > > > All the cpp files will be > > platform dependant that should be considered as > > customizations of the pure template library. > > ... And here you are telling that there will be > some (platform dependant). > > Do you mean there will be two libraries/layers ? I suggest for you take a look at some other posts in this thread on the library layers. Let me know if you cann't fine them. 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] RC_1_30_2 tagged for release
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. Thanks, Dave -- 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
--- John Torjo <[EMAIL PROTECTED]> wrote: > Basically, I don't think you should be concerned > about data at such a low > level. > > I think there should be a layer that represents gui > objects (windows, views, > controls, dcs, etc.), and ON TOP OF THIS, have > representations of data, > based on real-life scenarios. > > Like, for a list_control that should show employees, > we would expect it to > show an array of employees. Therefore, have a > list_control_with_data< employee> employees_list; Thanks for taking a look at it. Good point. Actually your suggestion is not different from mine. Your code: list_control_with_data< employee> employees_list My code: edit tst; tst << 1; The confusion is that your interpretation (more traditional) of a modern GUI framework is a bit different from notus. We are not concerned with building low-level controls. The low-level implementation is basically proveded by the platform (Mac, win32, etc.). Notus is just going to be using it. Notus's objective is exaclty to connect the 'real-world' data (STL containers, etc) to the low-level GUI. In fact, the data-GUI connection and data/GUI management policies IS a low-level for notus, below is just a presentation layer. Traditional GUI toolkits are mostly concerned with the presentation level, notus is not! (well to a degree) 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] GUI/GDI template library
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of E. Gladyshev > Sent: Wednesday, August 06, 2003 11:33 AM > To: Boost mailing list > Subject: RE: [boost] GUI/GDI template library > [...] > To the method 1 pros list: > - More user friendly. If the user implements the layer > 1, she can use the library with her custom GUI > platform. OK, so there is a separate implementation of the first layer for each target GUI? That would be better. [...] > Sorry why does adding new target affect code referring > to existing targets? Could you give an example? For an exaggerated example, imagine that we design and implement layer one knowing nothing about any GUI APIs besides Win32. We'll probably have to make a lot of revisions if we then want to make that scheme fit over a *nix GUI API. [...] > to the the Method 2 cons list: > > - The user won't be able to use the library on top of > a custom GUI (like some requested) unless she writes > it from scratch. Yeah, that's probably the biggest con, I just forgot it. It sounds like you are advocating a scheme somewhere between the two extremes I described: layer 1 - an abstraction of common GUI elements that is at a lower level than the 'domain specific sublanguage' of the primary public interface, but is implemented separately for each target GUI API. layer 2 - The top level public interface is implemented in terms of the layer 1, platform independent API. There is only one implementation of the top level public interface. Does this sound better? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neal, Neal D. Becker wrote: | Some time back I mentioned I was interested in iterator adaptors to convert | between vectors of complex and scalar. I have looked at using the iterator | adaptor framework in boost. It appears that it is easy enough to adapt from | a complex sequence to pick off either the real or imaginary part, but going | the other direction is not feasible? | | You would need to adapt from a pair of iterators over scalars to output an | iterator over complex. Thomas Becker is working on a combine iterator that will solve this problem. IIUC he has a working draft. | | Will the "new" iterator adaptor framework help? If you need it badly iterator_facade will help with getting the iterator interface right. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MT3Q0ds/gS3XsBoRAk+gAJ4vWlBSQkW8+pGAwMlHYWJ6y7k2JgCfRSF9 a6MjiFmWyB01bI7tScpMY6Y= =BLfu -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] what happened to allocators in boost?
- Original Message -
From: "E. Gladyshev" <[EMAIL PROTECTED]>
> I am wondering what happened to the allocator idiom in
> boost. Was it left out intentially?
> I can control all memory allocation details in STL
> (orthogonally to data types) but not in boost.
> It seems like a step backward comparing to STL.
> How can I use allocators with shared_ptr? Is there any
> way to write something like this.
> f()
> {
>shared_ptr< int, std::allocator > myptr;
>myptr.allocate();
>*myptr = 123;
> }
shared_ptr myptr(new int(123));
?
The allocator design focused on the benefits one could get from specialized
allocators for containers, e.g., data structures that may allocate large
chunks of memory that are expected to be used together. They don't really
give us much for components like shared_ptr that allocate one thing (and
note that shared_ptr does not allocate the pointer it stores, although it
does allocate a reference count). boost::function supports an allocator
argument, but the C++ committee is considering removing this allocator from
the library TR version of function<> for precisely this reason.
Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: UI++ [was: GUI sublanguage;Re: GUI/GDI templatelibrary]
David B. Held wrote: [...] > Well, honestly, I can't wrap my head around the big vision for how > this thing is proposed to get implemented, so maybe I don't know > what I'm talking about here. But it seems to me that Layer 0 for > existing GUIs could be designed in such a way that you could > offer custom alternatives for the standard widgets that do your > low-level visual tweaking (messing with functionality might be a bit > much). So if you wanted to customize the look of a button, there > would be a Layer 0 wrapper, say, for Win32 buttons that provide > the expected interface to Boost.GUI. But maybe you can inherit > from that wrapper and override some things to do your custom > drawing, and so you still have the required Layer 0 interface that > Boost.GUI needs, but you also get your customization of native > controls. > > It seems to me that Boost.GUI could possibly provide hooks for > such things as owner-drawn controls without cluttering up the > interface too much, which should give you quite a bit of > customization power. Would that be satisfactory? If I had more time working on this I wouldn't mind rewriting the basic widgets because reuseing or wrapping existing ones would limit a lot the design we aim for. Qt's QSpinBox only accepts integer types QListBox can only display simple labels. I don't know about WxWindows but new styles (Windows 200x) would take time for another LGPL group to implement. MFC is limited to Windows. I agree that some deterministic automata is missing also and Direct X / OpenGL support is interesting also. Philippe ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: UI++ [was: GUI sublanguage; Re: GUI/GDI templatelibrary]
Brock Peabody wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David B. Held Sent: Friday, August 08, 2003 1:18 PM To: [EMAIL PROTECTED] Subject: [boost] Re: UI++ [was: GUI sublanguage; Re: GUI/GDI template library] "Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] David B. Held wrote: [...] To bring a bit of sobering reality to the project, I would suggest picking a simple, even trivial target project (like displaying some trivial dialog box). This is exactly what I wanted first: a project based on portable rectangles, windows, stylish frames, menus, fonts & events. Thanks for confirming. [...] I am of the opinion that the library should use native widgets. It sounds to me like you want to create a custom universal widget set, but of course, this is going to be a hot-button issue for this library. I think the majority of people who have chimed in have also voted for or assumed native widgets, but I could be wrong. I strongly support native widgets too. I want the Windows version of my program to look like a windows program and the Mac version to look like a Mac program. This also saves us from having to develop our own widgets. Supporting native widgets would also mean that XP Styles would be automatically supported. However, this means that porting the GUI library to use, say, DirectX would be MUCH tougher. Basically you'd need to create EVERY single GUI control by scratch. If we instead created the controls by scratch in the library just using an abstract draw rectangle, etc, then not only would porting to DirectX would be simple, but it would also be much easier to port to other platforms as well. Also, keep in mind that building our own controls means we'll have instant support for certain controls that may not exist in other platforms, such as the common tabbed user interface, or dockable control bars used in Visual Studio. Rob Geiman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Insufficient significant digits using lexical_cast
I note that the 'precision' number of digits in lexical cast is obtained from
digits10 +1
if(std::numeric_limits::is_specialized)
{
stream.precision(std::numeric_limits::digits10 + 1);
}
If, as I believe correct, the objective is to get all digits that can be
significant, and can be read back in without loss of precision, this isn't
always quite right according to:
"Lecture notes on the status of IEEE 754 standard for binary floating point
arithmetic"
William Kahan
http://http.cs.berkley.edu/~wkahan/ieee754status/ieee754.ps
gives formula for number of decimal digits which are guaranteed to be
correct on output and required for input to achieve maximum possible precision
as a function of the number of significand bits (given by
std::number_limits::digits).
In C++ the full formula is:
int significant_digits10 = int(ceil(1 + float_significand_digits * log10Two));
and using this formula :
std::numeric_limits::digits = 24 significand bits
std::numeric_limits::digits10 = 6
floor(float_significand_digits -1) * log10(2) = 6
ceil(1 + float_significand_digits * log10(2) = 9 all significant bits
(note that the existing code gives 7 here, which is 2 too few)
std::numeric_limits::digits = 53
std::numeric_limits::digits10 = 15
floor(double_significand_digits -1) * log10(2) = 15
ceil(1 + double_significand_digits * log10(2)) = 17
(note that the existing lecial_cast.hpp code gives 16 here, which is 1 too few)
32 significand bits digits10 = 6 significant_digits10 = 9
53 significand bits digits10 = 15 significant_digits10 = 17
64 significand bits digits10 = 18 significant_digits10 = 21
106 significand bitsdigits10 = 31 significant_digits10 = 33
113 significand bitsdigits10 = 33 significant_digits10 = 36
128 significand bitsdigits10 = 38 significant_digits10 = 40
(note that the rest are a few too few)
I have proposed before that numeric limits should have another item called,
perhaps,
significant_digits10 returning these useful values,
but meanwhile I suggest that following the style of boost/limits.h
BOOST_STL_DECLARE_LIMITS_MEMBER(int, digits10, (digits * 301) / 1000);
// log 2 = 0.301029995664...
The integer fraction 301/1000 is needed to avoid suggeating to the compiler that
it should do a floating point calculation (which silently fails!)
so the following formula is used instead:
int const sig_digits10 = 2 + std::numeric_limits::digits * 301/1000; //
log10(2.)
This gives the same result without using the ceil function which might not be
computed at compile time.
So in lexical_cast, substitute for example the above fragment with:
if(std::numeric_limits::is_specialized)
{ // Show all significant decimal digits, 2 or 3 more than digits10.
stream.precision(2 + std::numeric_limits::digits * 301/1000);
} // & similarly for Source
A suggested revision and test attached, for example showing float & double now
have extra decimal digits.
Boost release 30 outputs:
1.414214
1.414213562373095
Revised version outputs:
1.41421354
1.4142135623730951
And it is thus now possible to convert float & double to a string and back again
to give exactly the same as the original float & double (which the current
version sometimes does not - a pit for the unwary).
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
mailto:[EMAIL PROTECTED]
test_lexical_cast.cpp
Description: Binary data
lexical_cast.hpp
Description: Binary data
testLexical_cast.vcproj
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] ABI fixing and prefix/suffix headers (was theboost::signalsample crashes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Maddock wrote: | | One final point - there was a reason that I moved regex to use automatic | library selection and ABI fixing - without it I was getting a tonne of | support requests along the lines of "Your library doesn't work, it just | crashes when I call anything", which almost always turned out to be caused | by ODR violations (either the user had changed an ABI option, or had linked | to the wrong runtime-library-build variant), these basically stopped | overnight once I modified my code to stop those (this was all in pre-boost | days BTW). FWIW I do believe that automatic library selection is a broken concept in praxis. It causes no end of problems when there is more than one library that does it. In the end you end up with the same situation as before the user has to know about the different runtime libraries and how to handle them. Furthermore I do believe that dependencies should be something that the programmer is aware of and that they should be actively managed by the programmer. Automatic library selection hides dependencies sometimes up to the point that dll's aren't shipped to the customer. Said that I can see your point John. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/M5fw0ds/gS3XsBoRArhaAJ9zPYhIARwrE2xTvG/mV8WhJI+w4gCbBlqt Jffv2UEPlUzTAE9ytIHcsbs= =kWRT -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
Perhaps Perseus, who slew the Medusa, the snake-haired monster of "so frightful an aspect that no living thing could behold her without being turned into stone." Perseus avoid being turned to stone by clever use of indirection -- he avoided looking directly at Medusa, instead looking only at her reflection in the mirror of his polished shield. http://www.online-mythology.com/perseus_medusa/ On Thursday, Aug 7, 2003, at 11:52 America/Denver, Brock Peabody wrote: On Behalf Of E. Gladyshev [...] Don't know where to start... Greek and Roman mythology? 'Aquilo' the north wind, the ruler of the winds. 'Notus' the south wind 'Flora' goddess of flowers and spring. 'Arcadia' a district of the Peloponnesus, the home of pastoral simplicity. Hmm of those I like Notus. Other ideas: Atlas Hydra Muse ... Eugene, you brought this whole thread up so I think you should pick the name :) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: time_duration bug in Boost 1.30.0
On Wed, 6 Aug 2003 10:11:20 -0700, Stephan T. Lavavej wrote > [Jeff Garland] > > The downside of this is that when you are printing a time duration: > > std::cout << td.hours() << ':' << td.minutes() << ':' << td.seconds(); > > you have to take remove the sign from the minutes and seconds. > > I have a third suggestion: > > - Implement (1) using abs() in the hours() method > > - Add a total_seconds function to the library so you don't have to write > > it. > >[Stephan T. Lavavej] > How about: > > * Implement (2), making all components negative if the time_duration > is negative * Add a total_seconds() fxn so users don't have to write > it * Allow users to lexical_cast a time_duration so it can > be printed as "-5:34:22" and document this so that users don't try > to roll their own naively. I believe to_simple_string does what you are suggesting so you shouldn't need lexical_cast. > Some unrelated issues that have come to me while working with date_time: > > * The documentation could stand some revision. There's apparently daylight > saving time stuff in the code, but it's not documented at all. Yes, the DST part of the library is under experiment and revision which is why there is a lack of documentation. > * It's also not obvious from the documentation where things like > January and Tuesday live. This applies generally; it's not obvious > what namespace many functions and classes live in. Ok. The answer is there are 3 namespaces: boost::date_time, boost::gregorian, and boost::posix_time. boost::date_time is where 'time system independent' or reuseble components live. boost::gregorian and boost::posix_time are 'instances' of a set of compatible temporal types and related classes built from the components in boost::date_time. Mostly they are comprised of typedefs of templates in boost::date_time and selection of specific implementations (eg: selecting the size integer to use for the time duration). So January ends up living in both date_time and gregorian. You can imagine needing it to build 'MyAlternativeDateSystem' and wanting the enum for the interface. > * I looked at the code and determined that Sunday = 0 (it's an > enumeration), but it'd be nice if this were guaranteed in the > documentation. Ok. > * One example shows: > last_kday_of_month lkm(Monday,Jan); > date d = lkm.get_date(2002);//2002-Jan-28 > > I found that I had to write: > first_kday_of_month(Sunday, Apr).get_date(2002) This was a bug (missing typedef) that has been fixed. If you update your boost/date_time/gregorian/gregorian_types.hpp you will pick it up. > Shouldn't the fact that first_kday_of_month and its ilk are > templated be documented? I was confused why I have to template it > on date in the first place (what else would go there?). Well sure, but virtually everything in the library is a template so that isn't going to help much. If you want to see more about what is under the hood I recommend looking at: http://www.crystalclearsoftware.com/libraries/gdtl/gdtl_ref_guide/index.html or http://www.crystalclearsoftware.com/libraries/gdtl/gdtl_ref_guide/annotated.html HTH, Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] switch-based runtime type selection (for variant)
Brian Simpson wrote:
> The implementation reasoning runs like this: It seems that the problem
with
> building a switch statement to implement type selection is that a switch
> statement can't be built incrementally--it is a syntactic construct. (The
> currently accepted solution builds an else-if-then statement incrementally
> by means of a recursive function template instantiation.) But what if you
> could give a template the number of types among which you want to select
in
> addition to the sequence? Could it then implement a switch-based
selection
> on the first 'n' types in the sequence? The answer turns out to be yes,
up
> to a point. The mechanism, in this case, is partial template
> specialization.
> Let us define a template class:
> template
> class n_ary_rtts_invoker;
> How does it produce a switch statement based on 'n'? Well, if we limit
> ourselves to a specific value of 'n', we can express it. For example,
here
> is a specialization for 'n'==3:
>
> template
> class rtts_invoker
> {
> public:
>template
>static
>BOOST_DEDUCED_TYPENAME Operator::result_type
>invoke(Operator & op, StoragePtr storage, long index)
>{
> switch (index)
> {
> case 0:
> return op(*(static_cast::type
> *>(storage)));
> case 1:
> return op(*(static_cast::type
> *>(storage)));
> case 2:
> return op(*(static_cast::type
> *>(storage)));
> }
>}
> };
>
> Given this specialization of n_ary_rtts_invoker, we can setup runtime type
> selection on the first three types in a sequence. To be more specific, if
> we instantiate a type, "n_ary_rtts_invoker", the template
> machinery should match the above specialization, and the statement,
> "n_ary_rtts_invoker::invoke(my_op, storage, index)", will make
a
> selection among the first three types in 'my_seq' via a switch statement
> (assuming 0<=index<3).
> If we define a similar specialization for values 1 and 2, we can setup
> selection on sequences of size 1-3.
>
> The general case devolves into an else-if-then:
> Let us assume that we have specializations up to a certain number,
> 'max_specialization_count'. Then we know that we can get switch-based
> runtime type selection ("rtts") on any mpl::Sequence whose size is not
> greater than 'max_specialization_count'. To provide rtts for Sequences
> whose size is greater than 'max_specialization_count', we provide a more
> general template definition. Its "invoke" function sets up a switch-based
> selection among the first 'max_specialization_count' types, and then sets
up
> a (recursive) selection among the remaining types.
FWIW, I've used a similar technique in MPL to do recursion unrolling for the
'advance' algorithm:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/boost/mpl/aux_/preprocessed/plain/advance_forward.hpp?rev=1.4
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Re: GUI sublanguage ?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of E. Gladyshev > Sent: Thursday, August 07, 2003 10:51 AM > To: Boost mailing list > Subject: Re: [boost] Re: Re: Re: GUI sublanguage ? [...] > I think the library should be scaleable in respect to > the space management. We can implment a set of > predefined space managemenet strategies/polices, all > the great stuff that we can come up with. However the > user should be able to customize them in any way she > likes. > For instance the row/col management strategy can be > just one of the predefined set. > In general, I think that it is just an issues of clear > definitions of space management basics that can be > utilized by various specilized algorithms. My thoughts exactly. Brock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
The notus project has been setup on sf. http://sourceforge.net/projects/notus It has several public forums including the Design forum. Please feel free to move this discussion there. I'll be posting a detailed proposal of basic design ideas soon which we can hopefully use as a starting point for discussions. IMO, designing a scaleable notus core is a critical issue for the whole idea. We don't want notus to be just an another MFC or Qt with an endless fixed hierarchy of classes. I hope that we can come up with a truly innovative design using the ideas of generic programming. Anyone is welcome to join! 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: UI++ [was: GUI sublanguage; Re: GUI/GDI template library]
> >That reminds me of something I was thinking about your post on >wxWindows. Someone could always write a 'driver' targeting wxWindows if >they want quick access to all of the platforms it supports and don't >mind the LGPL. > >Brock > Not _exactly_ LGPL. To quote from the wxWindows (2.4.0) distribution: " The core distribution of the wxWindows library contains files under two different licences: - Most files are distributed under the GNU Library General Public Licence, version 2, with the special exception that you may create and distribute object code versions built from the source code or modified versions of it (even if these modified versions include code under a different licence), and distribute such binaries under your own terms. - Most core wxWindows manuals are made available under the "wxWindows Free Documentation Licence", which allows you to distribute modified versions of the manuals, such as versions documenting any modifications made by you in your version of the library. However, you may not restrict any third party from reincorporating your changes into the original manuals. " -- Alec Ross ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bind and lambda don't work together?
Victor A. Wagner, Jr. wrote:
> I finally had a chance to go back and look at an attempt to use lambda in
> one of my commercial endeavors. It turns out that I was getting "ambiguous
> _1" with my compiler (VC.net2003) between lambda and bind.
Boost.lambda places _1 in the boost::lambda namespace.
Boost.bind places _1 in the global namespace. This is fine
so long as you avoid using directives and are careful with
using declarations.
As soon as you have a using directive for the boost::lambda
namespace, boost::lambda::_1 will be injected into the
global namespace -- even if the using directive is at block
scope -- and any use of _1 will be ambiguous.
If you have translation units that use both Boost.bind and
Boost.lambda, the safest advice is (i) avoid all using
directives for namespace boost::lambda; (ii) put using
declarations at block scope. For example,
int main()
{
boost::function< int (int, int) > times;
{
using boost::lambda::_1;
using boost::lambda::_2;
times = _1 * _2;
}
boost::function< int (int) > square
( boost::bind( times, _1, _1 ) );
std::cout << times(10,20) << std::endl;
std::cout << square(9) << std::endl;
}
--
Richard Smith
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Matthias Troyer <[EMAIL PROTECTED]> writes: >> >> > Dear Boosters, >> > >> > Since some of the applications and libraries we plan on releasing soon >> > rely on Boost features and bugfixes that are in the CVS but not in >> > Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 >> > release? Since we would prefer to base our released software on a >> > Boost release instead of a CVS snapshot I would be interested in >> > hearing about the plans for a Boost 1.31 release >> >> As far as I know the CVS is in very good health at the moment. > > Uhmm, I really wouldn't say so! If you look at the main trunk report - > http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, > there are lots of regressions comparing to 1.30.0, and IMO we ought to fix > all these before we branch for the release or anything. Regarding http://tinyurl.com/jhtn: does this compiler ever need the typename keyword? If not, perhaps we ought to define BOOST_NO_DEDUCED_TYPENAME for all Borland versions> -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: UI++ [was: GUI sublanguage;Re: GUI/GDI templatelibrary]
"Rob & Lori" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > [...] > > > Sigh, it sounds like pretty much everyone is of this same > > > opinion. Sure it makes a nice C++ interface, but it doesn't > > > allow much extensibility, > > [...] > Yeah, but it depends on what our goals are in the future. If we > just wrap platform API controls and add some extra tweaking > capability (like changing button color as you mentioned) then > that would work for a first version. I guess I'm more worried > about whether we are going to keep it like this or if we'll be > moving to doing a Boost.Widget for layor 0 in the future. > > I'm really excited about the possibilities for this library, and I'd > like to make sure that users can extend the Boost.GUI to suit > their own needs, while keeping such base goals as multi- > platform support in tact. Well, honestly, I can't wrap my head around the big vision for how this thing is proposed to get implemented, so maybe I don't know what I'm talking about here. But it seems to me that Layer 0 for existing GUIs could be designed in such a way that you could offer custom alternatives for the standard widgets that do your low-level visual tweaking (messing with functionality might be a bit much). So if you wanted to customize the look of a button, there would be a Layer 0 wrapper, say, for Win32 buttons that provide the expected interface to Boost.GUI. But maybe you can inherit from that wrapper and override some things to do your custom drawing, and so you still have the required Layer 0 interface that Boost.GUI needs, but you also get your customization of native controls. It seems to me that Boost.GUI could possibly provide hooks for such things as owner-drawn controls without cluttering up the interface too much, which should give you quite a bit of customization power. Would that be satisfactory? Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ublas and gcc (was: Re: [boost] Re: Compiler status for GCC 3.3)
Hi Gabriel, you wrote: > | >>> On the other hand if your native compiler is GCC and your system was > | >>> not configured with that setting, then you may get into trouble -- > | >>> since you'll be mixing translation units with different ABIs. > | >> > | >> Furthermore, that sounds like a workaround. Isn't it still a > | >> compiler bug that it doesn't work without -fabi-version=0? > | > > | >No, it's correctly fixed, but since it's a fix that breaks ABI, the > | >version number was bumbed. By default, GCC 3.3 uses the GCC 3.2 ABI. > | >If you want to > | >activate the new version, you have to explicitally say so. > | >"-fabi-version=0" always selects the last version of the ABI. > | > | So are you are saying we should add "-fabi-version=0"? > > If you do that unconditionally, you may get ABI incompatible > libraries/programs compared to what your system come with. > > The default ABI version for GCC-3.3.x is 1. You might want to set it > to 2 and see what happens (for GCC-3.3.x) -- some bugs are fixed in > -fabi-version=2. > > > This whole thing (-fabi-version) is messy. It is what one gets by > taking users for beta testers ;-) That's not the whole story. When testing with GCC 3.3.1 prerelease I noticed that setting -fabi-version isn't necessary anymore. So I filed a bug report http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11812, which immediately got closed ;-). The subsequent discussion at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11105 leads me to believe that GCC 3.3 was too conservative w.r.t. ABI compatibility. Due to this and the fact that there's been another bug in GCC 3.3 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11198) which manifests when using ublas, I tend to advise against using GCC 3.3 for ublas. Thanks, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Building header files with bjam
I have a need to generate header files which are then subsequently used
in a source file and built.
If i have a file called "xxx.y", which is used as an input to a program
to generate "xxx.hpp", and "xxx.hpp" is included in "xxx.cpp" I should
(I thought) be able to do something like this:
rule Tangle
{
DEPENDS $(<) : $(>) ;
}
actions Tangle
{
tanglemyfile $(<) $(>)
}
Tangle xxx.hpp : xxx.y ;
CPP_SOURCES = xxx.cpp ;
lib mylib : $(CPP_SOURCES).cpp
: $(PROJECT_ROOT) $(BOOST_ROOT)
: debug release
;
But when I try all of this in my jamfile, as much as I touch xxx.y,
xxx.hpp is never being asked to rebuild. basically the "actions" is
never executed.
What's the right way to do this?
Paul.
-
Paul Hamilton
pHamtec P/L - Software Makers
http://www.phamtec.com/
mailto:[EMAIL PROTECTED]
The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer.
-
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
Alisdair Meredith <[EMAIL PROTECTED]> writes:
> There is a problem with the Borland BCB6 compiler specializing std::swap
> for user defined types when using the STLport standard library. This
> may apply to other compilers using the library as well, but only have
> experience with Borland.
>
> An example is the clearest demonstration:
>
> // - Begin example
> #include
>
> class Swappable
> {
> public:
> Swappable() {}
>
> void Swap( Swappable & ) { }
> };
>
> namespace std
> {
> template<>
> void swap( Swappable &lhs, Swappable &rhs )
> {
> lhs.Swap( rhs );
> }
>
> }
>
> int main(int argc, char* argv[])
> {
> Swappable a, b;
> std::swap( a, b );
>
> boost::shared_ptr pA( new Swappable() );
> boost::shared_ptr pB( new Swappable() );
> # if BOOST_WORKAROUND( __BORLANDC__, >= 0x0560 )
> _STL::swap( pA, pB );
> # else
> std::swap( pA, pB );
> # endif
> return 0;
> }
> // - End example
>
> If the workaround is disabled, the compiler cannot find the
> specialization in namespace std as the swap algorithm is implemented in
> namespace _STL and introduced by a namespace alias.
>
> What does this mean for Boost?
> i/ There are no test cases for this in the test suite, or BCB would be
> failing more tests!
> ii/ Anywhere we use std::swap, we need a borland hack as above (although
> better tuned to STLport version as well)
Err, I don't get it. It seems to me that you only need the hack if
you're going to *specialize* swap. *Using* std::swap should work just
fine.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
> Now that the interest for this kind of library has been shown (or not, > whatever) could the interested parties please coordinate > their efforts using other means than boost mailing list? > IIUC > this list is for issues with existing code (problems, usage > patterns etc) and for submissions that have some code. I do not think that is true. > I am > already having problems keeping up with the list as is... Set up some kind of filter that dispose of all messages with nonimportant for you topics. Or read it thread based. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: what happened to allocators in boost?
- Original Message - From: "Douglas Gregor" <[EMAIL PROTECTED]> Newsgroups: gmane.comp.lib.boost.devel Sent: Tuesday, August 05, 2003 8:32 PM Subject: Re: what happened to allocators in boost? > The allocator design focused on the benefits one could get from specialized > allocators for containers, e.g., data structures that may allocate large > chunks of memory that are expected to be used together. They don't really > give us much for components like shared_ptr that allocate one thing (and > note that shared_ptr does not allocate the pointer it stores, although it > does allocate a reference count). boost::function supports an allocator > argument, but the C++ committee is considering removing this allocator from > the library TR version of function<> for precisely this reason. > > Doug > Hi there. I believe that components such as shared_ptr could still benifit from allocators that are shared at the class level; for example, a singleton pool allocator could be used by all instances of the shared_ptr template. Loki uses exactly this, and it gains a performance increase of ~100% compared to using the standard ::operator new and ::operator delete under MSVC++.NET 2003, when constructing and destructing lots of shared_ptr objects (or to be more accurate, shared_count objects), i.e.: std::vector > myDoubleVector(1); I personally think that the benifits are still there, and with things such as template typedefs and template aliases being introduced by the standards commitee, using templates with a lot of arguments may be less painful. Jesse Towner ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: filesystem feature request
From: "David Abrahams" <[EMAIL PROTECTED]> > I need the ability to do interprocess synchronization through file > locking, c.f. Java.File.createNewFile and Java.File.deleteOnExit: ... > On Posix, the first one would be done with > open(..., O_CREAT | O_EXCL) > > and the second, I suppose, would be done with a terminate handler. > The second feature (delete-on-exit) is supported by OS: - on Win32 using FILE_FLAG_DELETE_ON_CLOSE flag in CreateFile() - on Unix using unlink() standard system call /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: [regex] Escaping a search string?
John Maddock wrote:
>> 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 ?
>
> Yes, I was afraid you would bring that up :-)
Since I support the same localizations using your regex++ library in my
components, I have to.
>
>> 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.
>
> No it's not - the internal data simply isn't structured in a way that
> allows that kind of query - however as you yourself said already -
> the end user
> *knows* what the special characters are (if they have been changed).
This is true. I was really suggesting it to forestall the objection that the
changes are normally in a file set up manually, such as a resource DLL, so
it is difficult to read the file back in and load the substitutions etc.
etc. to figure out what changes were made. Of course one needs to know what
the localization changes are to present valid regular expressions so the
objection is a weak one.
>
> The worst case scenario: the user has substituted a traits class that
> uses different characters for the \ x { and } regular characters, so
> that escape sequences like: \x{32} don't work anymore.
You forgot that the digit characters themselves can be changed also.
I think, given the difficulty, but not the impossibility, for an end-user to
do it, you might consider a function in reg_expression which returns an
escaped string, like your example escape_regex function, for any regex
string passed to it, taking into account all the currently set flag
possibilities and possible localization changes.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: UI++ [was: GUI sublanguage;Re: Re: Re: Re: GUI/GDI template library]
- Original Message - From: "Beman Dawes" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]>; "'Boost mailing list'" <[EMAIL PROTECTED]> Sent: Saturday, August 09, 2003 8:31 AM Subject: RE: [boost] Re: UI++ [was: GUI sublanguage; Re: Re: Re: Re: GUI/GDI template library] > At 09:27 AM 8/8/2003, Brock Peabody wrote: > > >... I took the library from work code ... > > Brock, > > Do you have formal permission from the library's owner to do that? > Presumably the code is owned or licensed by your employer. I don't intend for the library to be part of boost, just an example people could play with. We're going to start from scratch for Notus. I'm a manager and I wrote all the code I posted. My boss, who is a VP, thinks it's great. I don't know who else I would need to ask. What do you think? Brock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [regex] Escaping a search string?
> 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? Second that request. I just had a need for this, though I wound up ignoring the problem rather than fixing it... George Heintzelman [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [regex] Escaping a search string?
> 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 ?
Yes, I was afraid you would bring that up :-)
> 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.
No it's not - the internal data simply isn't structured in a way that allows
that kind of query - however as you yourself said already - the end user
*knows* what the special characters are (if they have been changed).
The worst case scenario: the user has substituted a traits class that uses
different characters for the \ x { and } regular characters, so that escape
sequences like: \x{32} don't work anymore.
John
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Re: Re: [boost] GUI/GDI template library
--- Brock Peabody <[EMAIL PROTECTED]> wrote: > That might be a better way to go. I just don't know > enough about GUI > systems other than MFC to be able to envision what a > scheme like that > would look like or if it would succeed. You might > save a lot of work > coming up with a single low-level representation > scheme, but it might > become too complex. It's probably worth a try. In > the worst case, I > feel confident that we can make my brute-force > approach work. > I don't know much about other GUI systems but win32 and MFC. I think we can try to define the low-level layer using win32 and/or MFC as the starting point. If we cover these two, it'll be a good start and prove of concept. 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] filesystem/exception.hpp
At 05:23 PM 8/1/2003, David Abrahams wrote: > >Why aren't there constructors accepting an error_code in >boost::fs::exception? > >I have some code which needs to throw an exception if >!is_directory(some_path). I'd like to throw a not_a_directory >filesystem exception (or one derived therefrom). > >Howto? Seems like there should be additional constructors: filesystem_error( const std::string & who, const path & path1, error_code err_code ); filesystem_error( const std::string & who, const path & path1, const path & path2, error_code err_code ); There are several issues: * Instead of mapping a system error code into a generic error code, the reverse will need to be done. This allows the error message mechanism to work as if the system had reported the error. * Having constructors which are distinguished only by one argument being of type error_code or type int (for system specific error codes) may confuse users. I don't see any way around that. * If I was starting from scratch, I'd probably fold four constructors into two by redoing the arguments for both the generic error code and system specific error code like this: filesystem_error( int err_code, const std::string & who, const path & path1, const path & path2 = "" ); Hum... The current argument ordering wouldn't be broken by adding the new ordering. That would allow a period of transition without breaking any existing code. Comments? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bind/lambda - unsupported use case?
Aleksey Gurtovoy wrote:
> Consider the following snippet:
>
> void show_warning( message_dialog const&, user_message );
> void post_command( boost::function );
>
> int main()
> {
> boost::function f(
> bind( &post_command
> , ( bind( &show_warning, message_dialog(), _1 ) )
> // what goes here?
"protect", in boost/bind/protect.hpp. Lambda has both "protect" and
"unlambda", either will work (I think).
> )
> );
> }
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Matthias Troyer <[EMAIL PROTECTED]> writes: >> >> > Dear Boosters, >> > >> > Since some of the applications and libraries we plan on releasing soon >> > rely on Boost features and bugfixes that are in the CVS but not in >> > Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 >> > release? Since we would prefer to base our released software on a >> > Boost release instead of a CVS snapshot I would be interested in >> > hearing about the plans for a Boost 1.31 release >> >> As far as I know the CVS is in very good health at the moment. > > Uhmm, I really wouldn't say so! If you look at the main trunk report - > http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, > there are lots of regressions comparing to 1.30.0, and IMO we ought to fix > all these before we branch for the release or anything. I can't really tell what these represent. All of the new iterator library tests which weren't in 1.30.0 are showing up as regressions if they're failing. Many are simply not going to get better; they're due to compiler bugs which can't be worked around. As for the others, the failures you're reporting with intel-7.1 are very strange; my 7.1 compiler doesn't have these problems AFAIK. What does the "meta-" prefix mean? Do you have some special configuration of each of these compilers? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] SRPM 1.30.1 available
I have modified the 1.30.0 SRPM for 1.30.1. Pretty simple, except you need a patch to fix the version number or the RPM build will fail. Should I upload the SRPM somewhere? pgp0.pgp Description: signature
[boost] Re: UI++ [was: GUI sublanguage;Re: Re: Re: Re: GUI/GDI template library]
"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote: > Yeah I like Notus (kinda looks like Lotus). Exactly. Have you considered your reply when IBM's lawyers contact you over a possible trademark infringement? I immediately associated the name with Lotus Notes - I am sure they will to if Notus turns out it be successful. .-) Bo Persson [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [regex] Escaping a search string?
Daniel Frey wrote: > Edward Diener wrote: >> You can turn on the literal flag type. All characters in your regular >> expression are treated as literals. > > That doesn't help. Maybe an example clarifies what I need: > > std::string s = "1.30.0"; > boost::regex r( "^(.*)\s+(?:[Vv](?:ersion)?\s+" + s + ")\s*$" ); > > I need a way to convert 's' to '1\.30\.0', not to escape the whole > regex. No such function exist in the regex++ library but it should be easy enough to build one for yourself. In the regex++ doc, under the syntax topic there is a list of all the characters that aren't literals. Put them in a static string and write a transformation function which checks each character in your source string and if it matches one in the static string, added a backslash in front of it before putting it in a result string. BTW, in your example above, you of course need two backslashes for every backslash that occurs in your string literal. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
