[boost] program_options defect
I just found that program_options (from yahoo files) has a serious defect. The value of an option cannot start with the character '-', or it will be interpreted as an option. Obviously, this makes it difficult to enter a negative number as the option value. pgp0.pgp Description: signature
RE: [boost] Re: How Do We Install the Boost FileSystem?
You can use the parts independently There is no install required You have the complete code, you include the appropriate header! Yes, for the 'header-only' libraries, filesystem library is not one of them. Boost isn't like most 3rd party libraries in the sense of a dll (or similar) which you download or build and then have to ship and an API to use it. You have the complete code so you can use it as if it was your own! In this case, one would need to either statically link to filesystem lib (if(!) static library is one of the targets of the jamfile) or to link to DLLs (which are for sure produced by jamfile). I would personally always go with DLLs (if we are talking about Windows platform), and building filesystem to DLLs with provided jamfiles is really easy... Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the release criteria will be 100% accounting for all failures on those platform/compiler pairs. I assume that Linux/GCC will be one of those platform/compiler pairs. I need input from Linux/GCC experts as to which version of GCC should be used for the release criteria. I see GCC 3.3.1 has just been released, and so will be switching the Windows/GCC tests to use that version. Unless anyone objects, it will be one of the Windows release criteria compilers. I added gcc-3.3.1 to the Linux tests for CVS HEAD. Test failures have been down to 1% for gcc versions 3.2.3 and 3.3 a few weeks ago. I think 3.2.3 and 3.3.1 would be good candidates for being release criteria. 6 tests fail for 3.2.3 and 6 tests fail for 3.3.1 From the list I recently posted 1 failure has been fixed and 1 failure is due to a compiler error and not considered harmful. That leaves function::sum_avg_portable math::octonion_test math::quaternion_test test::errors_handling_test to be fixed or to be explained. Note, all these tests fail for both CVS HEAD and RC_1_30_0. Regards, m PS: The one additional error gcc 3.2.3 produces over 3.3.1 is in crc_test, btw. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: swappable user defined types and STLport libraries
Beman Dawes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] At 07:49 PM 8/5/2003, Pavel Vozenilek wrote: Edward Diener [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Beman Dawes wrote: At 09:58 PM 8/4/2003, Alisdair Meredith wrote: There is a problem with the Borland BCB6 compiler... What is the status of the Borland compiler as far as fixes and updates go? Have they announced any plans? Although they have not announced anything further about more BCB6 service packs, it is easy to guess that there will not be any more. All indications are that Borland is working on a BCB7 release but, in true Borland fashion, there is no date given when it will be released until it happens. ... Something is happening right now - announcement and beta invitation is on http://bdn.borland.com/article/0,1410,30279,00.html. OK, sounds good. Thanks for the heads up. 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. Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Infinite number of parameters?
Douglas Gregor wrote:
[...]
You can always write a forwarding 'foo' that checks the argument
types, but
I understand the reason you'd like this feature. My only question is
whether it is worth the additional machinery that it would take,
e.g., would this help a large amount of code? Perhaps you have a
particular real world use in mind? I can't think of one, and
there's a bit of code in the paper that uses the template varargs
stuff but didn't need it.
I think some people where interested to use a list of char also, a
compile-time string:
template ... char A
void foo()
{
}
foo'f', 'a', 's', 't', ' ', 's' , 't' , 'r' , 'i' , 'n', 'g'();
[...]
Philippe
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: UI++ [was: GUI sublanguage;Re: Re: Re: Re: GUI/GDI template library]
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philippe A. Bouchard Sent: Friday, August 08, 2003 7:54 AM To: [EMAIL PROTECTED] Subject: [boost] Re: Re: UI++ [was: GUI sublanguage; Re: Re: Re: Re: GUI/GDI template library] Brock Peabody wrote: [...] No and no. It actually only works on MSVC 6 because that is what we use at work - until next week. I can't wait! I took the library from work code and put it out there just so people could toy with the syntax a little. In theory, would it be possible to easily port it to another compiler? I have Visual Studio 7 but not everybody has it. Yes, In fact at we (as in me) are switching everything at work to VC 7.1 next week. Maybe this weekend I can get the example done. The only reason it won't work now is because of missing typenames. The interface example is in boost_gui_test/dialog.cpp. In the example code I support combinations of row(), column(), group(), static text, and edit(), and date_time(). Maybe we could start be taking a portable paint device; rectangles, fonts, frames events and we could mix your code to it portably. I really think we'll want to start from scratch as far as my code is concerned. We might want to reuse some of it, but probably not much except for ideas. I'm excited to see what sort of interface we can come up with. We could then implement groups, line edits, ..., Excel ;) Hehe. Actually, I think we should start out at 'line edit', button, etc... Painting is something we can include in a later iteration of our design, but it's too low level. 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. Regards, Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: ANN: C++ XML Objects
Paul Hamilton [EMAIL PROTECTED] writes: I have just uploaded a new project called cppxmlobj which is a system for persisting C++ objects to and from XML files. It uses Boost, Patterns, STL etc extensively (even the build system), and I thought that the list might be interested. An incarnation of it has been used in a number of commercial projects (by myself), but this is a complete rewrite using all the Boost stuff. Here is the link: http://sourceforge.net/projects/cppxmlobj/ I am still working on a literate programming system using this, but it will be ready to release in an early state soon. It's important that I complete the tangle tool so that it can create any sort of file for programming. It's almost done. There aren't any docs done except the doxygen stuff, but that will happen over time. Well, it's interesting but pretty hard to evaluate. As a recent Boost review of a persistence system shows, there are many dimensions to this problem domain. It's hard to get a grip on which of those you've chosen to address without some docs and/or examples. The most I can tell is that it seems to be intrusive on the design of classes you are persisting. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Insufficient significant digits using lexical_cast
[Paul claims that lexical_cast prints (floating-point) numbers with too few precision digits. Currently, limits::digits10 + 1 is used. Paul wants to change it to int significant_digits10 = int(ceil(1 + limits::digits * log10Two)); where limits is the numeric-limits traits class and log10Two is the base-10 logarithm of 2.] You used an article on IEEE 754 arithmetic. Shouldn't you check if the number type is compliant with that format? Or can this work for any suitable type? You also have to check if limits::digits is 2! Looking at the numbers you had, couldn't you just change limits::digits10 + 1 to limits::digits10 + 3? It could be argued that there's just a bug in the definitions of limits::digits10 (it's too low). On Saturday, August 9, 2003, at 5:48 PM, Paul A. Bristow wrote: [CHOP OFF really long article, with long attachments] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] interval input operator has problem with spaces
En réponse à Jason McCarty [EMAIL PROTECTED]:
[gah, I originally sent this to the wrong address]
I found a slight annoyance with operator (istream, intervalwhatever):
It can't cope with whitespace before its sentinel characters '[' and
',', causing some input operations to fail unnecessarily.
I would recommend the following alternative implementation, modeled
after a function in Stroustrup's TCPL.
templateclass T, class Policies inline
std::istream operator(std::istream is, intervalT, Policies r)
{
T l, u;
char c = 0;
is c;
if (c == '[') {
is l c;
if (c == ',')
is u c;
if (c != ']')
is.setstate(is.failbit);
} else {
is.putback(c);
is l;
u = l;
}
if (is)
r.assign(l, u);
return is;
}
This implementation also allows reading a scalar of type T, and
creating a point interval with that value.
Thoughts?
Since you are new to this mailing-list, you don't know all the discussions there
was about input/output and the library (mean/width, relative error, limited
number of digits, point representation, etc). To sumarize: interval/io.hpp is
a bit on the braindead side. It should never have been a real header. It was
rather designed as a quick and dirty hack to debug programs. It was up to the
user to provide well-built implementation for and in their final programs
(it's the reason why io.hpp is not automatically included by interval.hpp so
that there is no multiple definition). In the next release, this header will
probably be moved to the example section so that there is no more misunderstanding.
In conclusion, don't include interval/io.hpp but directly define your own
operators. And thanks for your function, I will use it when I create the example
file.
Regards,
Guillaume
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: switch-based runtime type selection (for variant)
Aleksey Gurtovoy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... 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 Thanks for the info. It alerted me to a shortcoming in my implementation (I don't account for an instantiation with a negative number). _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
Fernando Cacciola [EMAIL PROTECTED] writes: I'm trying to say that I think it's the wrong patch. The right patch would put the swap specialization into _STL::. It actually sufixes I assume you mean suffices. to put any 'std' extension in a nested namespace (say, stdx); then injecting the names in 'std'. That's unfortunately illegal. You're not allowed to add names to std, and anyway I don't see how it could help if you want to specialize something in std. Am I missing something? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::filesystem : compile trouble on Sun Solaris
Toon Knapen [EMAIL PROTECTED] writes: Using the sunpro toolset I get a strange error when compiling the boost::filesystem library (and thus all regression testing fails). Below you can find the error diagnostics. It comes down to an ambiguous overload of boost::operator==... but the two operator=='s (reported in the error message) are identical ! So why is this ambiguous ? I've been trying to find out where the operator== for directory_iterator is implemented. Seems that it comes from the iterator_facade. Also the header containing the iterator_facade declaration mentions support for operator== but still I do not grasp where the operator== is implemented. Maybe one of you can give me a hint where to look. Thanks in advance, My best guess is that SunPro is somehow getting confused by the forward declarations of those operators. You might try commenting that out and seeing if things get better. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: Hi, There are still problems with Optional, related to some compilers not finding std swap(). I wrote the original code following compressed_pair.hpp, which is via unqualified call (to activate ADL), plus a using declaration at function scope for GCC. Recently, Jens Maurer patched it adding an alternative using declaration at namespace scope (optional_detail) for GCC, but this seems not to work as the regressions show. I don't have access to any of the failing compilers Which compilers are failing and where are the regression report pages? Sorry for the delay, I was leaving the office when you posted this Most problems related to swap ocurr with GCC3.3 and VC==6.0 It appears that this problem ocurrs both with 1.30.0 and the current rc 1.30.2 On Linux_1_30_0: gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test gcc-3.3 gcc3.3.1: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test gcc-3.3.1 On Linux: All tests passed. (how come? On Libux-rc-1_30_0: gcc3.4: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.4-cvs gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.3 gcc3.3.1: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.3.1 On Win32_1_30_1: gcc: http://boost.sourceforge.net/regression-logs/cs-win32-1_30_1-links.html#optional_test-gcc On Win32: Comeau 4302: http://boost.sourceforge.net/regression-logs/cs-win32-links.html#optional_test-como-win32 VC60 : http://boost.sourceforge.net/regression-logs/cs-win32-links.html#optional_test-msvc On Win32 metacomm: Comeau 4302: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-com o-4.3.2b-vc7 Intel 7.0: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-int el-7.1 Intel 7.0 STLPort: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-int el-7.1-stlport VC 6.0: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-msvc VC 6.0 STLPort : http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-msvc-stl port The following are errors in other dependent libraries (type_traits and mpl) On MAC OS: GNU-GCC: http://boost.sourceforge.net/regression-logs/cs-Darwin-links.html#optional_test_fail5a-darwin On HP-UX: aCC53800: http://boost.sourceforge.net/regression-logs/cs-HP-UX-links.html#optional_test-acc aCC33380: http://boost.sourceforge.net/regression-logs/cs-hpux-links.html#optional_test-acc This is a compiler crash. On Solaris: http://boost.sourceforge.net/regression-logs/cs-solaris-links.html#optional_test-sunpro Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Build V2, Milestone 6 released
I finally had some time to try this out ... the .zip flavor: and came away confused = Installation...step 2. Place the Boost.Jam binary, called bjam or bjam.exe, somewhere in your PATH. Verify that correct bjam is being executed by running bjam --version. You should get Boost.Build V2 (Milestone N) not what I get. bjam starts running and complains about syntax errors... even when I get it building boost (V1 by default) it never gives me a version. Installation---step 3 Configure toolsets to use. Open new/user-config.jam file and follow instructions there to specify what compiles/libraries you have and where they are located. I'm not sure what instructions are being referred to here..but I un commented the line saying: using msvc; Installation...step 4 You should now be able to go to examples-v2/hello, and run bjam there. A simple application will be built. You can also play with other projects in examples-v2 C:\Projects\boost\boost-build\examples-v2\hellobjam C:/Projects/boost/boost-build/tools\boostbook.jam:86: in boostbook.init *** argument error * rule path.make ( native ) * called with: ( ) * missing argument native C:/Projects/boost/boost-build/new\path.jam:42:see definition of rule 'path.make' being called C:/Projects/boost/boost-build/new\toolset.jam:22: in using C:\Projects\boost\boost-build\examples-v2\../new\user-config.jam:58: in modules.load C:/Projects/boost/boost-build\build-system.jam:55: in load C:\Projects\boost\boost-build\examples-v2\..\kernel\modules.jam:296: in import C:\Projects\boost\boost-build\examples-v2\..\kernel\bootstrap.jam:122: in boost-build C:\Projects\boost\boost-build\examples-v2\boost-build.jam:2: in module scope I'm clueless build boost: C:\Projects\boostbjam --version --v2 -sTOOLS=vc7.1 C:\Projects\boost\tools\build\kernel\modules.jam:203: in normalize-raw-paths rule NORMALIZE_PATH unknown in module modules. C:\Projects\boost\tools\build\kernel\modules.jam:252: in import C:\Projects\boost\tools\build\kernel\bootstrap.jam:50: in boost-build C:\Projects\boost\boost-build.jam:12: in module scope Was I supposed to copy more of the files someplace?? At Tuesday 2003-07-22 03:06, you wrote: I'm pleased to announce that the next milestone release of Boost.Build V2 is available at http://prdownloads.sourceforge.net/boost/boost-build-2.0-m6.tar.bz2 http://prdownloads.sourceforge.net/boost/boost-build-2.0-m6.zip See also http://boost.sourceforge.net/boost-build2/ for online docs (a copy is included in distribution). Changes in this release are: - Segfault on use of RMOLD builtin fixed. - The gcc toolset handles threadingmulti now. - A bug which blocked update of certain targets was fixed. - BoostBook support was improved. - Boost.Build bootstrapping was improved. - A bug which caused wrong suffix to be used when linking to prebuilt targets was fixed. - A bug which prevented free features, like define from being specified in user-defined build variants was fixed. - Detection of loops in main target references was added. - Bug with : symbol in properties was fixed. - Bug which caused inline targets to be confused with top-level ones of the same name was fixed. Since some bugs are important, all users are advised to upgrade. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: There oughta be a law ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Release of 1.30.2 imminent
Peter Dimov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola wrote: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Which compilers are failing and where are the regression report pages? Sorry for the delay, I was leaving the office when you posted this Most problems related to swap ocurr with GCC3.3 and VC==6.0 It appears that this problem ocurrs both with 1.30.0 and the current rc 1.30.2 What's so surprising here? Everything fails exactly as it should. 1.30 has #ifndef __GNUC__ using std::swap; #endif and hence should fail on every non-broken GCC. HEAD has #ifndef BOOST_NO_STDC_NAMESPACE using std::swap; #endif instead and hence should fail on every BOOST_NO_STDC_NAMESPACE compiler that isn't a broken GCC. There's something I don't understand. 1.30.0, as you said, doesn't has the using declaration at function scope, BUT is has it at namespace scope. See revision 1.9 or prior. The idea was that borken GCC don't like it at function scope but do at namespace scope. Recently, Jens Maurer changed the guard at function scope from: #ifndef __GNUC__ to #ifndef BOOST_NO_STDC_NAMESPACE and honestly, I didn't looked much at it as I should. BOOST_NO_STDC_NAMESPACE is documented to relate to C names, but swap is a C++ name so I don't think such macro should be used here. I don't understand the problem with the original code (as of revision 1.19), and I don't understand why 1.30.0 fails. I do understand why HEAD fails, by my 'fix' would be to revert Jens fix, but if I were right, 1.30.0 wouldn't fail as it does. Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Some FC++ comments
On Wed, Aug 13, 2003 at 11:27:08PM -0400, Brian McNamara wrote: I've been working on a draft of the documentation for the boostified version of FC++, and it's finally reached a good enough state to be potentially useful to you-all. Check out http://www.cc.gatech.edu/~yannis/fc++/boostpaper.pdf (I'll make it available in a more convenient format when I figure out how to work latex2html.) Got it working: http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ is the HTML version. -- -Brian McNamara ([EMAIL PROTECTED]) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: ANN: C++ XML Objects
Dave Abrahams writes: Well, it's interesting but pretty hard to evaluate. As a recent Boost review of a persistence system shows, there are many dimensions to this problem domain. It's hard to get a grip on which of those you've chosen to address without some docs and/or examples. The most I can tell is that it seems to be intrusive on the design of classes you are persisting. Good points Dave. it's not really meant to be evaluated with the idea that it will be incorporated into Boost, since it's extremely intrusive and not really conducive to adding to projects. The announcement was really just a heads up for the list that this thing exists, and it might be useful for some projects where you read and write data from XML files. I have written this as part of another project, and thought that I would go free with it straight away, because I looked around myself for XML persistence and couldn't really find anything of use to me (they all involved some type of preprocessing which I hate. at least this thing you can just bolt on to any class from the outside). This scheme also uses pure patterns like Visitor, Abstract factory, Composite to do it's stuff. There are two small parts of this called cppreflect and cpppersist which would probably make nice additions to Boost, since they are very small, simple and general, but I'm really busy at the moment getting some other stuff going and don't really have time to push this. I'd really rather get a project written using this stuff as a kind of body of work using it rather than try to push it on the group at such an early stage. Thank's for looking at it though! 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: Boost 1.31 release?
Aleksey Gurtovoy [EMAIL PROTECTED] writes: Aleksey Gurtovoy wrote: David Abrahams wrote: Misha and Aleksey -- I think we really need to distinguish those failures from real regressions in the chart somehow or we'll never be able to tell where we stand. Here - http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html Yellow cells indicate failures on the newly added tests/compilers. The updated report tools are not in the CVS yet, we will check them in after the first round of feedback. The new reports are now checked into the main trunk and RC_1_30_0 branch. Now *thats* really informative! Thanks again for all your efforts! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Beman Dawes wrote: At 06:03 AM 8/14/2003, Walter Landry wrote: It would be trivial to add an additional path constructor that takes a checking function or function object. But that would kill ease-of-use. It is one thing to require an additional constructor argument in the fairly limited use native case, but the portability checking is applied to each and every path object constructed, including the many path temporaries created by the automatic conversions from char * and string. You could have the checking functor as a pointer to a boost::function which is a default argument initialized to 0. That wouldn't kill ease of use or change anything for the users who are very happy with the current posix default. (That kill ease-of-use point might be hard to understand if you haven't actually written code using the library. The automatic conversions really do allow script-like programming ease, and are reasonably safe given the conversion result is class path.) Also, the portability checking policy often needs to propagate to called functions such as third party liberties. Adding overloads of functions to take an additional argument is also too messy, and doesn't provide for automatic pass-through to lower level functions. I think this is an excuse for a certain amount of additional rewriting of the library. How you propagate the functor pointer is your own business but we all have been faced with problems like this when adding a new feature to an implementation. Internally, do what you need to do but for the end-user I think you need to consider what is best and most flexible for him. In most (but not all) programs it really would be convenient if portability checking policy was a global. But of course we all know that global variables are consider harmful. There are also several valid use cases where a program needs to switch back and forth between portability policies. Yes, not all portability policies need to theoretically be the same. There are cases when an OS accepts a file name in one instance, such as iteratoring through wildcard names, whereas another instance it does not accept the same notation, such as determining whether or not a specific file exists. So I think you need to allow portability policies on an instance by instance basis. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Peter Dimov [EMAIL PROTECTED] writes: Fernando Cacciola wrote: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Which compilers are failing and where are the regression report pages? Sorry for the delay, I was leaving the office when you posted this Most problems related to swap ocurr with GCC3.3 and VC==6.0 It appears that this problem ocurrs both with 1.30.0 and the current rc 1.30.2 What's so surprising here? Everything fails exactly as it should. 1.30 has #ifndef __GNUC__ using std::swap; #endif and hence should fail on every non-broken GCC. HEAD has #ifndef BOOST_NO_STDC_NAMESPACE using std::swap; #endif instead and hence should fail on every BOOST_NO_STDC_NAMESPACE compiler that isn't a broken GCC. Are you suggesting these should all be replaced with simply: using std::swap; ?? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::filesystem file restrictions
Beman Dawes wrote: The current approach is clearly too restrictive and isn't satisfactory. Beyond the problems you mention, there really isn't a single standard for portability. Even 8.3 names aren't portable to systems which don't allow periods in names. A whole family of checkers is needed, giving various degrees of portability. Some should be supplied with the library, but users also need to be able to provide their own. OTOH, a function that has to be explicitly called isn't going to be effective. Manual checking is too laborious in code that does a lot of path manipulation. A one time I took several pages of code and tried to add explicit checks. The code turned into a mess. Manual checking is also likely to be ignored by the very programmers who need it the most; those who have firm but erroneous ideas about what is or isn't portable. I am not sure that it should be the responsibility of the path class to enforce some notion of portability. Wouldn't it be more appropriate to defer the portability check, if any, to the point where the path is actually used in a filesystem operation? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast
Aleksandr Golovanov wrote: Hello, I'm pretty new here, but I've extensively used boost library for about a year. Yesterday, I ran into a small problem, lexical_cast accepts copy instead of (const)? reference to a source. I have a class which I would prefer to be noncopyable and castable with laxical_cast at the same time. I've been forced to reject noncopyable concept because of that strange feature of the lexical_cast. Is there any particular reason of such feature? And if not, is it possible to fix it in new release? Wrap the object in boost::cref(). -- Ross Smith .. Pharos Systems, Auckland, New Zealand Remember when we told you there was no future? Well, this is it. -- Blank Reg ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost.Filesystem: naming, canonical path
David Abrahams [EMAIL PROTECTED] writes: Once syntactic markers and/or rules are introduced, whether to eliminate ambiguities or to improve readability and writablity, the question is then what are the advantages of a new and unfamiliar set of markers and/or rules? You're already making paths unfamiliar by genericizing them. It would be unfair to VMS and whatever other OSes will be supported to say otherwise just because you are only changing slash direction on windows paths. The advantages are: 1. You can use familiar terminology - there should be no need to throw out the term absolute just to meet the expectations of Unix programmers who expect all paths beginning with '/' to be absolute. 2. The rules for understanding generic path syntax are greatly simplified and can be understood without platform-specific knowledge. 3. Portable/generic paths can actually be portable/generic, as advertised. You won't have the problem we have now: no complete path that works on a Windows machine can also work on a Unix machine (disregarding paths to remote machines, of course). Not to keep harping on this, but I just realized I forgot to mention another naming problem with complete: many shells support a familiar notion of path completion which is what I expected of the complete() function in operations.hpp when I first saw it. I think having an up-front definition of complete is helpful, but it doesn't eliminate the cognitive dissonance. The docs should cross-link all special uses of the term complete to the definition, since it is such a common word that many people won't guess it has a well-defined technical meaning. That would help too. BTW, I also have trouble with the phrase uniquely identify a file or directory. Does that mean there is only one complete path that identifies a file? If so, what about links? If not, what does uniquely mean? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] (newbie)Finding the root of tree
Thanks, stupid me ! I guess it has been too hot around here these days. At 13:12 14/08/2003 -0400, you wrote: From: Jonathan de Halleux [EMAIL PROTECTED] I have a tree built with the BGL. I want to find the root of the tree. Has anybody an idea on the algorithm I should be using ? thks Assuming your graph is bidirectional and has a single root, then you should just be able to pick any node, pick any parent thereof, repeat until you deadend. that is the root. ? Joel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost --- Jonathan de Halleux, Research Assistant Center for Systems Engineering and Applied Mechanics (CESAME) Universite catholique de Louvain Batiment Euler , Av. Georges Lemaitre, 4 Tel : +32-10-47 2595 B-1348 Louvain-la-Neuve Belgium E-mail : [EMAIL PROTECTED] --- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
David Abrahams wrote: Here - http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html Yellow cells indicate failures on the newly added tests/compilers. The updated report tools are not in the CVS yet, we will check them in after the first round of feedback. Very nice! Thank you! I am looking for a library which has both red and yellow for the same compiler so that I can verify that it shows up red in the top-level summary. It does. See, for instance, regex on cwpro8. I have looked at the iterator library failure with meta-intel-7.1-stlport. It appears to me that either BOOST_NO_STD_ITERATOR_TRAITS or BOOST_MSVC_STD_ITERATOR is misconfigured for this library. This configuration probably needs to change depending on whether you are using STLPort iostreams and which Dinkum library underlies your STLPort. Thanks for the info, we will look into it. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Fernando Cacciola [EMAIL PROTECTED] writes: I don't understand the problem with the original code (as of revision 1.19), and I don't understand why 1.30.0 fails. RC_1_30_0 is working for me with gcc-3.2 on Win32. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] lexical_cast
Hello, I'm pretty new here, but I've extensively used boost library for about a year. Yesterday, I ran into a small problem, lexical_cast accepts copy instead of (const)? reference to a source. I have a class which I would prefer to be noncopyable and castable with laxical_cast at the same time. I've been forced to reject noncopyable concept because of that strange feature of the lexical_cast. Is there any particular reason of such feature? And if not, is it possible to fix it in new release? Thanks, Aleksandr Golovanov MetaCommunications, Inc. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in iostream-like pipe?
Alexander Nasonov [EMAIL PROTECTED] writes: Philippe A. Bouchard wrote: There is another pipestream project you can take a look at: http://pstreams.sourceforge.net/ May be I missed something but this library is about reading from stdin and writing to stdout of other process. It's not about inter-thread pipes. hm, yes, there appear to be two discussion threads tangled up here, I too got this discussion confused with Jeremy Siek's thread process control, fork/pipe, etc. an inter-thread pipe might also be referred to as a synchronization channel, if you want to avoid confusion about names (pipes being a particular OS object). -graydon ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::filesystem file restrictions
Greetings,
I've started using boost::filesystem recently, and I'm mostly very
happy. One thing bothers me, though. Why does it implement any
restrictions, by default, on what kind of files it allows? From the
documentation:
The following are not valid name char's: x01-x1F, , , :, , /, \,
|, *, ?. Although these characters are supported by some operating
systems, they are disallowed by so many operating systems that they
are banned altogether.
I also noticed that you can't open a directory named . or ..,
though I think ./ and ../ both work. Files starting or ending
with spaces also don't work.
I understand that I can (painfully) work around it by using a
different context, but I don't understand why boost::filesystem wants
to restrict me to a set of filenames that are portable. Isn't that a
bit too much handholding? I don't mind having an is_portable()
command or something similar, but it is incredibly annoying to have to
abide by someone else's filename restrictions.
I found a bug report at
https://sourceforge.net/tracker/?func=detailatid=107586aid=776146group_id=7586
and a discussion about this (though it focused more on ? and *) at
http://lists.boost.org/MailArchives/boost/msg46073.php
In particular, Beman Dawes said:
What is very explicitly not a supported use case is for providing
simply a new but still non-portable interface to non-portable
operating system API's. If that is the need, just call the
non-portable operating system API's directly.
If we were to take that to the extreme, then boost::filesystem should
only accept 8.3 filenames. What Beman seems to be missing is that he
has made an extremely nice interface to filesystems. It is much
simpler and easier to use within C++ than the non-portable API's. But
it is unneccesarily difficult to look at whatever files the user may
have created. This makes the library much less useful than it might
otherwise be.
It is a trivial change to fix this (just take out the check), and I've
done this in my own copy. I'm attaching a patch with this email.
Thanks,
Walter Landry
[EMAIL PROTECTED]
--- /home/boo/arx/arx/src/boost/{arch}/++pristine-trees/unlocked/boost/boost--ar
x/boost--arx--1.0/[EMAIL PROTECTED]/boost--arx--1.0--patch-6/./libs/filesyst
em/src/path_posix_windows.cpp 2003-07-18 13:22:15.0 -0400
+++ /home/boo/arx/arx/src/boost/./libs/filesystem/src/path_posix_windows.cpp
2003-07-31 10:37:51.0 -0400
@@ -128,17 +128,6 @@
{
// error checking functions /
/
-
-bool generic_name( const std::string name )
-{
- return name.size() != 0
- name.find_first_of( invalid_generic ) == std::string::npos
- name != .
- name != ..
- *name.begin() != ' '
- *(name.end()-1) != ' ';
-}
-
bool posix_name( const std::string name )
{
return name.find_first_not_of( valid_posix ) == std::string::npos
@@ -308,13 +297,6 @@
# endif
);
- if ( context == generic !generic_name( name ) )
- {
-boost::throw_exception( filesystem_error(
- boost::filesystem::path,
- invalid name \ + name + \ in path: \ + src + \ ) );
- }
-
m_path += name;
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MetaComm Regression results for gcc/icc on linux
Hi, I am trying to find regression test results for gcc-3.3 on linux and Intel 7.1 on Linux. Are the meta-intel-7.1 results at http://www.meta-comm.com/engineering for windows or linux? Does anyone have regression results for gcc/intel on linux? By the way, these results are really useful, thanks for all the effort. Regards, -Tom Wenisch Computer Architecture Lab Carnegie Mellon University ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: trouble with static linking and intel-linux
Samuel Krempp [EMAIL PROTECTED] writes:
As said in the Re: Release of 1.30.2 imminent thread,
recent regressions for intel-linux-7.1 on ios_state and format
(eg
http://boost.sourceforge.net/regression-logs/cs-Linux-links.html#format_test1-intel-7.1)
report weird linking erros (due to pthread symbols not found).
In fact, ios_state and format are the only boost libs with static-linked
tests, and I suspect this triggers a problem with the intel-linux
toolset.
I can solve the errors by adding threadsmulti as a build
requirement, but I'd prefer not.
If I change format's test Jamfile to use dynamic linking, intel-linux
links (and runs) ok.
but then metrowerks would fail because it supports locale only with
static-linking.
I see 2 ways out, but dont know how to actually implement them, so
either :
1. someone understands the situation with intel-linux and fixes this
toolset
2. soemeone tells me how to have a build requirement for a specific
compiler in a Jamfile, so as to use static-linking only for metrowerks.
solution 2 is enough to work around the intel-linux problem for now, but
it would be good to fix the intel-linux toolset static-linking problem.
Oh, and would it be important to fix that before releasing 1.30.2, or
can it just wait ?
I think we should fix it.
The fix is pretty easy; just add
intel-linux*runtime-linkstatic
to the requirements. Alternatively, you could use something like:
local rtlink = runtime-linkstatic
if $(NT)
{
rtlink = runtime-linkdynamic
}
and then add $(rtlink) to the target requirements. This is a bit more
reliable because we have a proliferation of very specific toolset
names at this point (i.e. it might not match metrowerks or
intel-linux).
Please let me know if it works out,
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Release of 1.30.2 imminent
-Original Message- From: Fernando Cacciola [mailto:[EMAIL PROTECTED] Note: although this library is new, google shows (to my satisfaction) that there are already a couple of users of Optional out there. Simple and effective. It is in a production system here. Many thanks, Matt. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] boost::filesystem file restrictions
-Original Message- From: Beman Dawes [mailto:[EMAIL PROTECTED] Sent: 14 August 2003 04:56 To: Boost mailing list; [EMAIL PROTECTED] Subject: Re: [boost] boost::filesystem file restrictions At 06:03 AM 8/14/2003, Walter Landry wrote: I've started using boost::filesystem recently, and I'm mostly very happy. Wow! A very happy user. Or at least mostly very happy. That's good news:-) Seriously, it is a powerful motivator to get that kind of feedback. Well, here's another happy user :-) -- snip -- I'm curious to hear what others would think of the above scheme. Oddly enough I had a similar thought halfway through reading your mail - by the time I got to your proposal all I could think was yes. As for the stack/heap question... I don't believe there is a way to portably and reliably tell how memory was allocated (please correct me if I'm wrong - code would be most welcome!). Michael ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ANN: C++ XML Objects (docs)
For those who were interested but wanted to see what it is all about first, I have updated the site so that it has some documentation on how to actually use the project from within your own code. http://cppxmlobj.sourceforge.net/use.html 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
Re: [boost] Re: Release of 1.30.2 imminent
David Abrahams wrote: Martin Wille writes: David Abrahams wrote: NOTICE: If I don't hear of any new problems with the RC_1_30_0 branch I'm going to release 1.30.2 tomorrow (Wed) evening or Thursday morning. Not new: there are still some regressions for Linux: crc_test regresses for gcc3.1 and gcc3.2.3 config_test regresses for intel 7.1 (clock_gettime function isn't found) format tests (all of them) regress for intel 7.1 ios_state_test regresses for intel 7.1 The format tests and ios_state_test fail due to a linker error. Apparently, the tests need to be linked against pthreads. Since Daryle and Samuel haven't been responsive about these, I guess I have to ask you if you'd like the opportunity to try to fix them before we ship... Are you interested? The config_test regression was caused by not having linked against librt. I added these lines to intel-linux.jam on the RC_1_30_0 branch: # required libraries flags intel-linux FINDLIBS : rt ; The HEAD version of intel-linux.jam already contains those lines. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] time_duration bug in Boost 1.30.0
On Mon, 4 Aug 2003 20:17:03 -0700, Stephan T. Lavavej wrote time_duration behaves highly nonintuitively. A time_duration should be convertible to seconds by calculating td.hours() * 3600 + td.minutes() * 60 + td.seconds(), right? Wrong! Hmm, I agree that this is not nice... ...example omitted... In short, the .minutes() and .seconds() of a negative time_duration should be negative, but are not. Since the negative sign is attached to the hours only, the complicated above seconds_from_time_duration() function must be used in order to avoid incorrectly converting time_durations to seconds. I believe that there are two solutions to this bug: 1. Make all of time_duration's quantities unsigned and store whether the time_duration is negative in a boolean. This cleanly separates storing the direction of the time_duration from the magnitude. However, this is undesirable because converting a time_duration to seconds would still require (td.is_negative() ? -1 : 1) * (td.hours() * 3600 + td.minutes() * 60 + td.seconds()). If the user forget the parentheses around the second expression, then again the result would be correct except when the negative time_duration has nonzero seconds or minutes. Plus it makes the memory footprint of time duration bigger which is not desirable. Of course this same solution could be implemented by only returning the abs in the hours() so that it is consistent with the other methods and provides only the magnitude. 2. If a negative time_duration is produced, all of its fields should be negative or zero. This has the advantage of allowing easy conversion to seconds: td.hours() * 3600 + td.minutes() * 60 + td.seconds(), which is what a user will naturally want to write. Users may construct time_durations with differently signed fields, but these will have well-defined meanings (just as 1 hour 1 minute 61 seconds is equal to 1 hour 2 minutes 1 second, 1 hour 0 minutes -1 seconds is equal to 0 hours 59 minutes 59 seconds). I believe that (2) is the correct solution and has no downsides. 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. Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] (newbie)Finding the root of tree
From: Jonathan de Halleux [EMAIL PROTECTED] I have a tree built with the BGL. I want to find the root of the tree. Has anybody an idea on the algorithm I should be using ? thks Assuming your graph is bidirectional and has a single root, then you should just be able to pick any node, pick any parent thereof, repeat until you deadend. that is the root. ? Joel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
Bohdan wrote: E. Gladyshev [EMAIL PROTECTED] wrote in message Do you mean link of incompatible library problems ? If so ... as mentioned this is problem of boost build system and it will be finally solved. Look at boost::regex, it doesn't have such problems for compilers supporting #pragma comment. It means that correct library is linked automatically. Does regex address the issue of alignment and calling convention etc and other options (in BCB, treat enums as ints is a good one to screw up libraries) by wrapping the headers in push/pop option statements? Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Files of types *.ipp are unfriendly, especiallytoMSVC ?
Paul A. Bristow wrote: Since I couldn't find how to make the editor work with .ipp files from the MS documentation, but it ws kindly provided by a diligent Booster, can you suggest where this info shold be stored? FYI, a while back I got a power toy called vstweak that allows you to tweak stuff like this: http://www.gotdotnet.com/team/ide/ Regards, Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Mixing g++/aCC on HP-UX (was: Compiler support)
... Well, if things were that simple, we would have used GCC 2.x/3.x on HP-UX as well. Unfortunately, we have to link against 3rd party C++ libraries (Tuxedo (CORBA), actually) that have been compiled with aCC (*gasp* even with the old roguewave STL - they don't even have the std namespace). Since CORBA provides IIOP interoperability, I would suggest to use some different implementation in apps, where you would like to use boost+gcc instead of Tuxedo. Any problem with using free impls like: MICO (http://www.mico.org), omniORB (http://www.omniorb-support.com), TAO (http://www.theaceorb.com)? We will (currently starting to write a C++ framework) also use OmniORB4, but our main target is BEA Tuxedo (=8). We _have_ to use Tuxedo, because of its abilities. We do high troughput OLTP applications (banking, telecoms, stuff like that). OmniORB4 or TAO would be for low-cost, smaller systems. I've been able to get forward some by simply commenting in the two template classes that aCC didn't want to compile (I'm just focussing on date_time and unit_test at the moment, I would already be pleased if I was able to use that from BOOST) in operators.hpp, but then aCC crashes (*g*) with Too many nested classes! and a SIGSEGV (can't allocate more stack, really) Here's the line that breaks aCC: boost::tokenizerboost::char_delimiters_separatorchar tok(s); I reproduced that in a very simple C++ file, just by calling the constructor. And yes, it's just the tokenizer constructor (I also tried replacing char_delim... by std::string, same thing). I'm afraid it's hopeless, there's no way I could make a workaround in tokenizer. Stack size is set to 8MB. I'll have the admins set it up for me and give it another try, but I can't really imagine that 8MB of memory wouldn't be enough for aCC to parse the tokenizer template. This gets a little off-topic, but has anybody had any success linking together objects that have been compiled with g++ and aCC on HP-UX ? I'm afaraid name mangling is different... Yes, I made some tests, and they all failed. I took two different C++ files, one compiled with g++, one with aCC. g++ as a linker (= GNU ld) can't see the symbols from the aCC .o and vice-versa. Even with the HP ld linker, same thing. So I guess there's no way to mix them (I didn't really believe it could work ;)). Would be so nice if g++ could use the native platform's (or rather: the native compiler's) name mangling ;) Anyway, thanks Karel. But I'm afraid I'll have to drop BOOST :( This is definately off-topic (shoot me if you want ;)) but does anyone know some other OpenSourced (not GPL - LGPL, BSD-like, MIT, etc...) library that has date/time stuff and that might compile on some Unices ? Thanks for your help. -- -o) Pascal Bleser ATOS Origin/Aachen(DE) /\\ System Architect [EMAIL PROTECTED] _\_v Project Leader WLP Online Framework The more things change, the more they stay insane. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
On Wednesday 06 August 2003 02:38 pm, Thomas Witt wrote:
gpgkeys: WARNING: this is an *experimental* HKP interface!
gpgkeys: key D1DB3F812DD7B01A not found on keyserver
Rozental, Gennadiy wrote:
| What is the problem adapting pair of iterators to scalar vectors to
produce
| an iterator with complex value type?
The problem is you can hardly adapt a pair. So using iterator_adaptor
(the new class template) does not provide any benefit.
| I am sure both old and new iterator adaptor easily allows it.
As I said before iterator_facade (new) would be the right tool AFAICS.
Thomas
This seems to work, but it's klugey. I guess it is an existance proof that
it's possible to do with old iterator adaptors?
1) Since only 1 object can be passed to the iterator adaptor constructor, I
had to pass a pair.
2) Distance uses only one of the base iterators.
3) iterator_category uses only 1 of the iterators.
Can anyone suggest ways to improve this?
The first 2 policies pick off real or imag parts of complex. They are no
problem.
The last 1 combines real and imag into complex. That's where the problems
lie.
#includeboost/iterator_adaptors.hpp
#include complex
#include utility // pair
// #includealgorithm
namespace boost {
namespace detail{
templatetypename BaseIterator
class complex_real_iterator_policy : public default_iterator_policies {
public:
// Constructors
complex_real_iterator_policy (BaseIterator const _base) :
base (_base) {}
template class IteratorAdaptor
typename IteratorAdaptor::reference dereference (IteratorAdaptor x)
const {
return real (*x.base());
}
private:
const BaseIterator base;
};
templatetypename BaseIterator
class complex_imag_iterator_policy : public default_iterator_policies {
public:
// Constructors
complex_imag_iterator_policy (BaseIterator const _base) :
base (_base) {}
template class IteratorAdaptor
typename IteratorAdaptor::reference dereference (IteratorAdaptor x)
const {
return imag (*x.base());
}
private:
const BaseIterator base;
};
templatetypename BaseIterator1, typename BaseIterator2
class real_imag_complex_iterator_policy : public default_iterator_policies
{
public:
typedef typename std::pairBaseIterator1, BaseIterator2 base_type;
// Constructors
real_imag_complex_iterator_policy (base_type const _base) :
base (_base) {}
template class IteratorAdaptor
typename IteratorAdaptor::reference dereference (IteratorAdaptor x)
const {
return typename IteratorAdaptor::value_type (*x.base().first,
*x.base().second);
}
template class IteratorAdaptor
void increment(IteratorAdaptor x)
{ ++x.base().first; ++x.base().second; }
template class IteratorAdaptor
void decrement(IteratorAdaptor x)
{ --x.base().first; --x.base().second; }
template class IteratorAdaptor1, class IteratorAdaptor2
typename IteratorAdaptor1::difference_type
distance(const IteratorAdaptor1 x, const IteratorAdaptor2 y) const
{ return y.base().first - x.base().first; }
private:
const base_type base;
};
} // namespace detail
templatetypename BaseIterator
struct complex_real_iterator_generator {
typedef typename boost::detail::iterator_traitsBaseIterator::value_type
complex_value_type;
typedef typename complex_value_type::value_type scalar_value_type;
typedef
boost::iterator_adaptorBaseIterator,detail::complex_real_iterator_policyBaseIterator,
reference_isscalar_value_type type;
};
templatetypename BaseIterator
typename complex_real_iterator_generatorBaseIterator::type
make_complex_real_iterator(BaseIterator const begin) {
typedef typename complex_real_iterator_generatorBaseIterator::type
ret_type;
return ret_type (begin, detail::complex_real_iterator_policyBaseIterator
(begin));
}
templatetypename BaseIterator
struct complex_imag_iterator_generator {
typedef typename boost::detail::iterator_traitsBaseIterator::value_type
complex_value_type;
typedef typename complex_value_type::value_type scalar_value_type;
typedef
boost::iterator_adaptorBaseIterator,detail::complex_imag_iterator_policyBaseIterator,
reference_isscalar_value_type type;
};
templatetypename BaseIterator
typename complex_imag_iterator_generatorBaseIterator::type
make_complex_imag_iterator(BaseIterator const begin) {
typedef typename complex_imag_iterator_generatorBaseIterator::type
ret_type;
return ret_type (begin, detail::complex_imag_iterator_policyBaseIterator
(begin));
}
templatetypename BaseIterator1, typename BaseIterator2
struct real_imag_complex_iterator_generator {
typedef typename boost::detail::iterator_traitsBaseIterator1::value_type
scalar_value_type;
typedef typename
[boost] Re: the boost::signal sample crashes
This is just what I would like to see in boost. I have created a duplicate set of headers for boost (same names, same structure but in boost_wrappers which do this and include the original header between the push and pop). We had a discussion about this a while back and I am all for it, but people seemed against it. I'll try and find a link to the discussion. Thanks Russell John Maddock wrote: Does regex address the issue of alignment and calling convention etc and other options (in BCB, treat enums as ints is a good one to screw up libraries) by wrapping the headers in push/pop option statements? Yes: #ifdef __BORLANDC__ # pragma option push -a8 -b -Vx -Ve -pc -w-8027 #endif // code here #ifdef __BORLANDC__ # pragma option pop #endif We should standardize this boost-wide really in some kind of prefix/suffix header. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Gcc problem in variant library
At 06:28 AM 8/7/2003, Hartmut Kaiser wrote: Hi all, I've tried to use the variant library to implement some new functionality inside the Boost.Spirit library. I must say, I'm impressed. Very well done! I've stumbled over a problem though: gcc (Cygwin: gcc (GCC) 3.2 20020927 (prerelease)) reports: In file included from D:/cvs/boost/boost/variant/variant.hpp:25, from D:/cvs/boost/boost/variant.hpp:22, from D:/cvs/spirit/boost/spirit/core/non_terminal/impl/grammar.ipp:29, from D:/cvs/spirit/boost/spirit/core/non_terminal/grammar.hpp:23, from D:/cvs/spirit/boost/spirit/core.hpp:49, from grammar_tests.cpp:18: D:/cvs/boost/boost/variant/detail/forced_return.hpp:57: default argument specified in explicit specialization Is it my fault? Other compilers (VC7.1) work well. Hartmut, The variant library developers were checking in changes almost daily until a week or two ago, so you might want to make sure you have the latest from CVS. They haven't been active since then, however, so may be on vacation or otherwise busy. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Torjo Sent: Tuesday, August 05, 2003 11:58 AM To: Boost mailing list Subject: Re: [boost] Re: Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library [...] I did fix the include file problem. The file was on my box :) What do you mean? I got boost_gui.zip from yahoo section yesterday. I meant that I fixed the problem after I got your email and then updated it in the yahoo files section. There was a /source/c++/bplib/WindowsUtils.h on my development box, but not in the package, so while it compiled for me it was doomed to fail on any other machine. [...] Thanks a lot for checking this out! Anytime! The ideas you present are really cool! Thank you very much! Eventually, please send me the files by mail - [EMAIL PROTECTED] You got it! Please let me know if it works. I will try to find time today to add some more elements to the sample like grid, typed_list_box, etc... Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::array
Robert Ramey wrote:
const int array[] = {1, 2, 3, 4};
boost::container_facadeint cfa(array, sizeof(array)/sizeof(int));
I guess my problem is I still don't understand what is wrong with
const boost::array int, 4 = { 1, 2, 3, 4 };
in this case.
If you are referring to having to dictate the size of the array in
advance, rather than deduce it, that is a known deficiency and I would
welcome any solutions for this!
[I have proposed array to the ISO committee and this is one of the
issues that I suspect may hold back its adoption]
As for making the copy above:
Would a constructor template perform the deduction correctly?
template typename T, unsigned int N
container_facade( const T[N] source )
{
std::copy( source, source + N, m_data );
}
We are still stuck with the case that N does not match the fixed size of
the array template, but we are closer for my case (a) where the array
size is fixed at run-time rather than compile time.
By using a function template as a factory, we could even deduce the
correct array size, at the expense of another copy.
template typename T, unsigned int N
boost::arrayT, N make_array( const T[N] source )
{
boost::arrayT, N result;
std::copy( source, source + N, result.begin() );
return result;
}
I can't help feel you are trying to use array for something it is not.
As I see it, boost::array is a replacement for 'traditional' arrays, not
a wrapper for them, in the same way that std::vector is a replacement
for dynamic arrays.
--
AlisdairM
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.30.1 released
On Thu, 07 Aug 2003 17:38:22 +0200, Daniel Frey wrote: David Abrahams wrote: No, it means managing the next release. Um, no, I don't feel like I can handle that. Sorry. I'm sure it's a lot of work and a big Thank You! to you for doing this job, but I think it requires knowledge which I don't have. And more time than I have, but this seems to be everybody's problem... :) Just to clarify: I don't meant to reject volunteering to the release process in general. It's just that I am sure that I would make a mess of 1.30.2 due to the tight shedule. Also, I need to learn more about some parts of boost that I don't feel comfortable with (yet). Anyway, if you really think I should/could manage a release, I suggest that I get more time and try my hands on 1.31.1 or something similar. Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Mutable typedefs - changing the type associated withan identifier
2) Is there a way to enhance the mutable typedef trick to avoid the
large number of template instantiations?
I have worked on a solution that would require less template instantiations
but would still rely on the __LINE__ trick to avoid violations to the ODR.
The example provided (as an attachment) works on gcc 3.3 but fails to
compile with intel's compiler(7.1).
It makes the following possible :
DECLARE_VECTOR( MyVector );
SET_VECTOR_ELEMENT( MyVector, 0, int );
SET_VECTOR_ELEMENT( MyVector, 1, float );
PUSH_BACK_IN_VECTOR( MyVector, double );
PUSH_BACK_IN_VECTOR( MyVector, long );
If this kind of solution works for you we could improve it, this is
certainly not production code.
Hope this helps,
Marc-Antoine
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Thomas Wenisch
Sent: 5 aout, 2003 15:06
To: [EMAIL PROTECTED]
Subject: [boost] Mutable typedefs - changing the type associated with
an identifier
Hello all,
Recently, I had the following problem in some library code I maintain.
I provide users with a macro which generates fairly complex typedefs:
#define MAKE_TYPEDEF(Ident, etc) typedef complicated Identifier;
Users use the macro to define a bunch of different types, all with
identifiers of the user's choosing. Elsewhere, I need an mpl::list of the
types generated by the macro. Right now, users have to supply me with
this mpl::list. This opens the possibility for the list to get out of
sync with the MAKE_TYPEDEF()s if the user forgets to update the list when
adding a new MAKE_TYPEDEF() invocation.
I wanted to eliminate this possible source of bugs, by somehow
automatically generaring the mpl::list as a side effect of using the
MAKE_TYPEDEF macro. I want each macro invocation of MAKE_TYPEDEF to
mpl::push_front the type it declares onto the front of a typelist.
#define MAKE_TYPEDEF() ...\
typedef mpl::push_front previous_list, Ident::type new_list;
The problem is the naming of the identifiers previous_list and
new_list. Because of ODR, each invocation of MAKE_TYPEDEF needs to give a
unique identifier to new_list, and yet somehow figure out what name was
used for previous_list. The easy solution is to have the user provide
unique names and chain the list of MAKE_TYPEDEFs together. But, this is
just as error prone as having the user simply provide the mpl::list
directly.
I wanted a solution which is completely transparent to the user. Thus, I
cooked up the following, which I am calling mutable typedef.
The solution abuses the __LINE__ macro to generate unique identifier
names. A template specialization is created to mark the line number
used in the identifier. Then, when I wish to determine the name of
the identifier, a second template tests each line number going
upward from the current line until it finds the line number marked by the
specialization. Using this trick, I can create the effect of a
typedef which can be redefined, without violating ODR. Each use of the
typedef finds the nearest preceeding definition.
The code demostrating the trick appears below. The same trick can be used
to redefine integral constants as well, but I omit that code for brevity.
The main disadvantages of the approach are that it is not extremely robust
(doesn't work if line numbers change, i.e. when including files; or if
multiple mutable typedefs appear on one line), and that it requires a
large number of template instantiations if the nearest definition of the
mutable typedef is far away.
My questions for the Boost community are:
1) Is there an easier way to accomplish what is outlined in my use case
above, using preprocessor tricks or something similar?
2) Is there a way to enhance the mutable typedef trick to avoid the
large number of template instantiations?
3) Are there others interested in using this or seeing it submitted to
Boost?
Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University
=== Example code begines here. Tested with gcc 3.3 ===
#include iostream
#include boost/preprocessor/cat.hpp
//Create the base templates for a line marker for Identifier and declare
//the struct used to search for the nearest previous occurence of the
//marker
#define DECLARE_LAST_LINE_MARKER(Identifier) \
template int N\
struct BOOST_PP_CAT(last_line_marker_,Identifier) \
: public BOOST_PP_CAT(last_line_marker_,Identifier)N-1 {}; \
template int StartAtLine \
struct BOOST_PP_CAT(find_last_line_,Identifier) \
: public BOOST_PP_CAT(last_line_marker_,Identifier) StartAtLine {}
/**/
//Mark the current line
#define LAST_LINE_MARKER(Identifier) \
template struct BOOST_PP_CAT(last_line_marker_,Identifier)__LINE__ \
{ static const int value = __LINE__; }
/**/
//Find
[boost] bind/lambda - unsupported use case?
Consider the following snippet:
void show_warning( message_dialog const, user_message );
void post_command( boost::functionvoid() );
int main()
{
boost::functionvoid( user_message ) f(
bind( post_command
, ( bind( show_warning, message_dialog(), _1 ) )
// what goes here?
)
);
}
Could we make it work, somehow? Offers of a hand-written function
performing the composition are not accepted :).
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: automating registering of events (was: Re: GUI/GDItemplatelibrary)
AFAIK, some gui toolkits use not event, but callback system. IMHO it is more evective. Definitely it should be discussed carefully. Aren't we talking about the same thing? ;) In response to an event, you call an event callback. That's what my example does - it's obfuscated indeed, but that's because I had to tweak it to work with VC6. Best, John ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: File missing from Boost 1.30.1 release?
- Original Message - From: David Abrahams [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 10:06 PM Subject: [boost] Re: File missing from Boost 1.30.1 release? David Abrahams [EMAIL PROTECTED] writes: Zak Kipling [EMAIL PROTECTED] writes: I've just tried to build Boost 1.30.1, and it failed with the error: /home/zak/current/unpacked/boost/src/boost-1.30.1/boost/pending/integer_rang e.hpp:15:39: boost/counting_iterator.hpp: No such file or directory This file doesn't appear to be there at all... it's in CVS, but only on the MAIN branch. That's very strange; somehow the tag must've been dropped. permutation_iterator.hpp is missing too. Ouch. Maybe we need to release a 1.30.2? Definitely. Here's a complete list of files that were removed from RC_1_30_0 between 1.30.0 and 1.30.1. This can't be intentional: [...] OK, I believe bugfix releases are necessary, but we're 60+ developers, so some kind of planning is neccessary, too. Personally I can't cope with a time frame of a week or two. Appreciating-the-release-manager's-efforts-ly y'rs, Joerg P.S.: Daniel, it's seems you're going to have challenging times ;-) ___ 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of E. Gladyshev Sent: Friday, August 08, 2003 12:22 AM To: Boost mailing list Subject: Re: [boost] Re: UI++ [was: GUI sublanguage;Re: Re: Re: Re: GUI/GDI template library] --- Philippe A. Bouchard [EMAIL PROTECTED] wrote: Could you prepare a little schedule, I would like to know more about the timelines given to hypothesises abstractions, Hello worlds multi-platform issues. We are talking about hard labours here time management is a big issue. I am pretty much convinced I know what I am saying but it would be something else coding it in details. I am in but I can't affort every day development...! I can't afford it either. As for the timelines. Given the work-at-spare-time nature of this project, I would not spend any time trying to come up with a timeline. I think that our first objective is to get on the same page in terms of major design decisions (I am working on a proposal that hopefully we can use as the starting point for a detailed technical discussion). After the design is approved, we can subdivide the whole project and assign responsibilites. Then it is up to each developer to come up with a reasonable personal timeline (based on his/her personal schedule) for a part that she/he is going to be working on. What do you think? I think we should come up with a plan that takes us from start to finish (submission for review), but I don't think we should attach any dates to it. Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: UI++ [was: GUI sublanguage; Re: GUI/GDI template library]
Beman Dawes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] At 06:42 PM 8/10/2003, brock wrote: [...] Should I get this permission formalized? Yes, to protect both yourself and Boost. [...] Can we say: SCO vs. IBM? ; Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Aleksey Gurtovoy [EMAIL PROTECTED] writes: David Abrahams wrote: Thanks for all the testing; the release looks pretty darned great! Just to make sure it's understood - although expected, all the green failures are still failures. Not that we can do much about them, of course. From a user POV, a darned great release would be the one for which http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/user_summary_page.html would reveal a clear green field, without any details links to check. Yep. http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_result_page.html Only one red box (intel-7.1-stlport lexical_cast)! ... which means a regression from 1.30.0 ;). Yes, I know. To be fair, quite a few failures have been fixed (dark green cells) Yes. http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_summary_page.html Still, it would be nice if we didn't release until _all_ regressions are fixed. I agree, but nobody seemed to be paying attention to that problem. I wonder what our maintenance wizard is up to...? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ 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?
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...
John.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem broken links
At 06:04 PM 8/5/2003, David Abrahams wrote: Many of the internal references seem to be broken. For example, path.htm#Representation_example doesn't seem to go anywhere. Ugh. Fixed. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] filesystem feature request
I need the ability to do interprocess synchronization through file locking, c.f. Java.File.createNewFile and Java.File.deleteOnExit: --- createNewFile public boolean createNewFile() throws IOException Atomically creates a new, empty file named by this abstract pathname if and only if a file with this name does not yet exist. The check for the existence of the file and the creation of the file if it does not exist are a single operation that is atomic with respect to all other filesystem activities that might affect the file. This method, in combination with the deleteOnExit() method, can therefore serve as the basis for a simple but reliable cooperative file-locking protocol. Returns: true if the named file does not exist and was successfully created; false if the named file already exists Throws: IOException - If an I/O error occurred SecurityException - If a security manager exists and its SecurityManager.checkWrite(java.io.FileDescriptor) method denies write access to the file deleteOnExit public void deleteOnExit() Requests that the file or directory denoted by this abstract pathname be deleted when the virtual machine terminates. Deletion will be attempted only for normal termination of the virtual machine, as defined by the Java Language Specification (12.9). Once deletion has been requested, it is not possible to cancel the request. This method should therefore be used with care. Throws: SecurityException - If a security manager exists and its SecurityManager.checkDelete(java.lang.String) method denies delete access to the file --- 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] config, workaround of bug in variant's compiler bugworkaround on gcc
I think problem is with BOOST_EXPLICIT_TEMPLATE_TYPE(void) Simply removing that workaround macro from forced_return works for me as a dirty workaround. The question is, why BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS on gcc 3.2.x? config/compiler/gcc.hpp comments about some unspecified bug, while documentation says only about VC6. The same bug in both compilers? Strange. Kind of - the extended test case is in libs/config/test/boost_no_exp_func_tem_arg.cxx Diving more in config, little of compiler specific code pollutes config/suffix.hpp, shouldnt it go to compiler specific config instead? Everything in suffix.hpp is generic macro workarounds - it's not dependent upon specific compilers just whether the appropriate macro is defined. I think you are going to have to use a dirty workaround here: check for gcc before using BOOST_EXPLICIT_TEMPLATE_TYPE(void) in this particular case. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: UI++ [was: GUI sublanguage;Re: GUI/GDI templatelibrary]
If you haven't seen Fresco (successor to InterViews) before, I think it has a lot of interesting ideas. http://www.fresco.org/ I've heard a couple competing ideas; either wraping native widgets or writing the widgets from scratch (both is a possibility too, of course). Either way I think it would be worthwhile to conside reusing existing low-level cross-platform libraries. For the former, wxWindows has been mentioned; for the latter, there's SDL, OpenGL, and many others (I wouldn't suggest DirectX; SDL wraps it very nicely, and DirectX is obviously not cross-platform). Many more ideas could be explored and prototypes built by reusing these existing libraries, rather than (IMHO) wasting cycles reinventing the wheel implementing low-level compatibility libraries. Once there's consensus on a design, the question of 'level 0' libraries could be revisited. I think, in any case, Novus should be flexible enough to allow end-users to choose which rendering library they want to link with. I certainly don't want to be stuck with MFC or DirectX! Thanks, --craig ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Patch to emacs cc-mode for template syntax andindentation
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? Also, [EMAIL PROTECTED] pgp0.pgp Description: signature
RE: [boost] Iterator adaptor question
|| What is the problem adapting pair of iterators to scalar vectors to |produce || an iterator with complex value type? | |The problem is you can hardly adapt a pair. So using iterator_adaptor |(the new class template) does not provide any benefit. | | | Why is that? The whole point in adapting is that you modify some but not all behavior/interface of a thing. There is nothing a pair provides that can be reused so adoption is pointless. There is all that we need so we could create valid iterator. As for how much we will need to overwrite - it still less then writing iterator from scratch. That's why the new version provides iterator_facade and iterator_adaptor. iterator_facade helps with implementing iterators, iterator_adaptor is for adapting iterator like types. | I did not look in depth on new version but I remember that old one | allowed to adapt any source. You needed to do this as the iterator interface implementation was not separated from the actual iterator_adaption. I do not argue which version better fit for the task. I just saying that it could be easily done with old version either. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: UI++ [was: GUI sublanguage;Re: GUI/GDI template library]
-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. An interesting question is whether the library could support a native widget set as an abstract third-party platform. Then people who want that exact portable look and feel can get it by specifying the custom widget platform. That's a great point. If our library is well designed it should support this type of customization naturally. We can have our cake and eat it too :) 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 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 05:12 AM 8/11/2003, Alisdair Meredith wrote: Aleksey Gurtovoy wrote: While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. OTOH, it might not always be achievable. For boost 1.31 we are having an interface breaking change to the iterator_adaptors, and not all compilers pass all tests with the new adaptors yet. While this may not be a problem for the iterators library (it is effectively new) it may have a knock-on effect on any other boost libraries implemented on top of it. The principle is a good one, but I be prepared to make a few allowances in the practice. I think a reasonable goal is that any regressions should be understood and discussed, rather than silent. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI sublanguage ?
[EMAIL PROTECTED] wrote: [...] 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). At some degree it becomes political issues. I doubt Boost would want to take the same risky path I took (Corel). Philippe ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any interest in iostream-like pipe?
Alexander Nasonov wrote: [snip] The library doesn't use OS pipes. Pipe support is implemented by hand with a help of Boost.Threads. Synchronization occurs only in underflow, overflow, sync, open and close functions which means fast I/O. The library also has two capacity models: limited and unlimited. In the former case, if writer goes ahead of a reader it stops and waits; in the latter case, the writer always allocates new block of memory when overflow occurs. The following post: http://aspn.activestate.com/ASPN/Mail/Message/boost/1593756 indicates there's some interest in thread-safe access to ostreams at least. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] what happened to allocators in boost?
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::allocatorint myptr;
myptr.allocate();
*myptr = 123;
}
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: Boost 1.31 release?
At 04:11 PM 8/10/2003, Martin Wille wrote: I added gcc-3.3.1 to the Linux tests for CVS HEAD. Test failures have been down to 1% for gcc versions 3.2.3 and 3.3 a few weeks ago. I think 3.2.3 and 3.3.1 would be good candidates for being release criteria. OK, let's use 3.2.3 and 3.3.1 as the Linux release criteria. Since someone has to research every failure, and this is our first release using formal criteria, we don't want to go overboard. 6 tests fail for 3.2.3 and 6 tests fail for 3.3.1 From the list I recently posted 1 failure has been fixed and 1 failure is due to a compiler error and not considered harmful. That leaves function::sum_avg_portable math::octonion_test math::quaternion_test test::errors_handling_test to be fixed or to be explained. Note, all these tests fail for both CVS HEAD and RC_1_30_0. I've just installed 3.3.1 on Windows, and am getting those same four failure plus failures from: date_time/testmicrosec_time_clock (runtime failure) iterator/interoperable_fail (compile_fail test isn't failing) That seems like a reasonable number to fix or otherwise account for. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI sublanguage ?
Philippe A. Bouchard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bohdan wrote: [...] There are a lot of good reasons why we would not always want to have total control. Not always means sometimes not ? According to this logic your gui language is layer built on top of interface proposed by me ... just for convenience. Right ? I looks like a competition between the two of you... No. My apologises, if my posting were too offensive for somebody. Unfortunately my english is far from being perfect. Everything i want is to clarify the idea of incoming modern gui library and particularly 'gui sublanguage'. I'm very interested in this library and this is the only source of emotions. No wars, only questions, doubts and ideas. I want my applications to be as simple as possible, and to all look the same. Generally GUI applications are semantically complicated. Forget about universal cure from this. Everithing you can do is to symplify development in some cases. It doesn't make sense to start positionning every widget manually like this. What if you find you're interface ugly (p = 0.90) the first time and you have found a better idea? You are going to retype the position of every widgets in the whole application?!? No. Look at Borland VCL lib. It handles autosizing/alignment without significant problems. Anyway, i agree there a lot of interesting ideas for improvements in this field. If you are planning to do this, I suggest to use another GUI application which will generate the spaghetti part of you're code. Another GUI application may require much more complicated behavior than gui-sublanguage can propose. regards, bohdan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of E. Gladyshev Sent: Wednesday, August 06, 2003 5:21 PM To: Boost mailing list Subject: Re: [boost] Re: GUI/GDI template library --- Bohdan [EMAIL PROTECTED] wrote: 2. Finally your lib may become non-template ( i mean cpp files) ... If it becomes not-template, I'll stop working on it :). cpp files are allowed for the layer 1 code and compilation-time optimization wrappers only, that's it! Both has little to do with the library itself. It may not be necessary to templatize some of the lower levels of the implementation. The interface will almost certainly be all templates. What about simple boost::gui ? I would like to have an unique name without the boost prefix. I think the boost namespace is a requirement for any boost library. Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: automating registering of events (was: Re: GUI/GDItemplatelibrary)
John Torjo [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
AFAIK, some gui toolkits use not event, but callback system.
IMHO it is more evective. Definitely it should be discussed
carefully.
Aren't we talking about the same thing? ;)
Not exactly.
- Callbacks --
button b;
b.on_click_callback = do_button_down; // or:b.on_click_callback.connect(
my_func );
-- Events
class MyButton : public button
{
private:
void dispatch_event( Event event )
{
switch( event.ID )
{
case EVENT_BUTTON_DOWN:
do_button_down( ... ); break;
...
defautl:
default_handler( ... );
}
}
};
---
Sure you can wrap event-interface to work with callbacks and vice-versa
or even user mixed approach.
Have nothing against your ideas :) just want to note that there are
can be 'native' gui libs that are not using event-objects at all and
that event mapping/dispatch probelm is platform specific.
The question is which interface (callback or events) is more comfortable
for user and which one is more effective. IMHO, mapping proposed by
you should be deeply inside library and user interface should work with
callbacks only.
In response to an event, you call an event callback.
That's what my example does - it's obfuscated indeed, but that's
because I had to tweak it to work with VC6.
regards,
bohdan
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast segfault
Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: Test case (note that WinXP doesn't complain when programs segfault, hence the Begin/End business): See http://www.boost.org/more/error_handling.html for a way to work around that. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost.Filesystem: naming, canonical path
At 01:07 AM 8/10/2003, David B. Held wrote: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] As a user of the filesystem library, I am having the experience that obvious things are hard to find, and the docs are much harder to understand than they ought to be. [...] Just out of curiosity, is the filesystem library being used to create a new build or regression test system, like it was originally designed to do? Both the boost-root/tools/inspect and regression code use the filesystem library, as does the bcp code. The build system is built on the jam code, which is C rather than C++, and wasn't one of the envisioned uses of the filesystem library. My sense is that the filesystem library is fairly widely used. I base that on page views on the web site, bug reports, enhancement requests, and comments I've gotten from users. OTOH, the filesystem library isn't used by any other Boost libraries. That is pretty much is as I would expect, partially because the library is aimed more at end-use than as a building block for other libraries, and partially because it is a fairly new library. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Infinite number of parameters?
Brock Peabody wrote:
That's a cool idea. It's a lot prettier than using the preprocessor.
Thanks, Brock.
Does anyone know whether or not a language solution is being
considered
for this or variable class template arguments?
It would be valueable for expressions only, not declarator lists. But in
general those infinite parameters function instanciations happens mostly for
function overloading.
[...]
int main()
{
foo((infinite::begin, true, (char *) adasd, 12367, 127.2));
}
The previous syntax or the following by using a px() helper which would
generate another type:
template typename T
struct p_t
{
T const t;
...
};
template typename T
p_tT px(T const p)
{
return p_tT(p);
}
template ...
infinite V, infiniteT, U operator , (infiniteT, U const u,
p_tV const p)
{
return infinite V, infiniteT, U (u, p.t);
}
...
int main()
{
foo((px(true), px((char *) adasd), px(12367), px(127.2)));
}
My 0,03$
Philippe
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
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) Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: UI++ [was: GUI sublanguage;Re: Re: Re: Re: GUI/GDI template library]
E. Gladyshev wrote: [...] assign responsibilites. Then it is up to each developer to come up with a reasonable personal timeline (based on his/her personal schedule) for a part that she/he is going to be working on. What do you think? Ok, but the main decisions should be classified archived so that it is faster to catch up. Feel free to e-mail me directly. Some people are complaining that we are taking too much of the boost's traffic. Are we Boost approved? I have submitted a request for Notus to sf today. It takes up to 2 business days to get approved. Talk to you on Sunday! Philippe ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
En réponse à David Abrahams [EMAIL PROTECTED]: Martin Wille [EMAIL PROTECTED] writes: David Abrahams wrote: In that case, can I release 1.30.2? I don't like having the 1.30.1 debacle hanging over my head. There are new regressions on Linux (RC_1_30_0 branch): http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html crc has regressions for gcc-3.1 and gcc-3.2.3 config, format and io have regressions for intel 7.1 According to your chart, the following libraries are all regressing: [...] numeric/interval [...] Nothing has been commited to the RC_1_30_0 branch for the interval library, so there should be no regression. In fact, the regression you speak about happens with gcc-3.4-cvs. Martin was careful not to mention these failures in his mail. Are these real regressions or just newly-tested compilers? Can the library authors/maintainers address these problems? Where is our maintenance wizard? Mainly newly-tested compilers (gcc-3.3.1 and gcc-3.4). You just have to focus on gcc-3.1, gcc-3.2.3 and intel-7.1 columns. Regards, Guillaume ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Fun PP lib example
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
There is another variation of the idiom, sometimes called hidden
state, which doesn't have the shortcoming in the first place:
class foo
{
public:
foo();
foo(int);
int f() const;
void g(double*);
private:
struct state;
scoped_ptrstate m_state;
};
Missing ~foo, possible undefined behavior. :-)
Not here :). I intentionally didn't qualify 'scoped_ptr'; ours works just
fine :).
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] UI++ [was: GUI sublanguage;Re: Re: Re: Re: GUI/GDI template library]
--- Philippe A. Bouchard [EMAIL PROTECTED] wrote: Here are some of my postings on the name and project issues. Brock and I liked the Notus (god of the south wind) name. BTW Brock said that he is in! 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 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. 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] [BGL] bug in incremental_components examples / documentation
Hi all I've found bug in incremental_components examples and documentation. Type _Rank_ is expected to be size_type, but container _rank_ is created from vertex_descriptor. Examples work because adjacency_list VertexList container type is vector. // ... typedef adjacency_list vecS, vecS, undirectedS Graph; typedef Graph::vertex_descriptor Vertex; // ... // create the disjoint-sets structure, which requires // rank and parent vertex properties std::vectorVertex rank(num_vertices(G)); //^^ std::vectorVertex parent(num_vertices(G)); typedef std::vectorGraph::size_type::iterator Rank; // typedef std::vectorVertex::iterator Parent; disjoint_setsRank, Parent ds(rank.begin(), parent.begin()); //... Regards, Janusz ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- Brock Peabody [EMAIL PROTECTED] wrote: 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. I agree. 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? It is exactly my preference... if, like you said before in your prev post, it is feasible to come with a nice layer one spec at all. I think it could be worth to try. 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: swappable user defined types and STLport libraries
David Abrahams wrote: I'm trying to say that I think it's the wrong patch. The right patch would put the swap specialization into _STL::. I'm weighing up the 'correct' solution with the 'practical' solution. Correct would be, as you say, fix all the code everywhere else specializing std::swap, including code in other vendor supplied headers. (This may cause friction with 3rd party vendors, but that is their problem not Boost's) Likewise, we are in perfect control of our own source to 'do the right thing' ourselves. The practical approach says that the error the compiler reports always points to the place using std::swap, and not the place defining the specialization. This means the errors always point to boost headers, no matter how unjust. It also makes tracking the header causing the problem a nasty case of recursively checking every header and those it includes to locate the source of the problem. Various search tools can simplify the task, but there is still an element of needle-in-a-haystack. Finally there is the problem of explaining all this to users the first time they hit the problem, as 'the bug is in boost code. See, the compiler says so!' I guess as the problem is not reported regularly to the user list it is still quite rarely encountered, but at the least we should put up an entry on the Wiki to point people to (and as chief trouble maker I guess that is my job!) I tried searching the Boost source for places where Boost itself provided swap implementations, and discovered that these are always placed in namespace boost and not std. As this pattern is adopted everywhere I am assuming I have missed some discussion/guideline outlining this as best practice. Is there a reference/link I could read up before putting an entry in the Wiki? -- AlisdairM Team Thai Kingdom ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Re: Re: [boost] GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bronek Kozicki Sent: Tuesday, August 05, 2003 2:06 AM To: Boost mailing list Subject: Re: Re: Re: [boost] GUI/GDI template library E. Gladyshev [EMAIL PROTECTED] wrote: 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. Please, do NOT use MFC. Just native Win32 API as a starting point. MFC is 1) not available on mingw 2) big and full of traps. If we can do Win32 I guess there isn't any point in doing MFC. I will not miss it much :) Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
Beman Dawes wrote: At 12:53 PM 8/6/2003, Russell Hind wrote: Perhaps coordinate with John Maddock? He is really our config header expert. So John, would you be interested in trying to get this sorted out for the next release? As I have said, I currenly only use BCB, and so can't offer much help for other compilers. Would it be best to have something like a boost/config/preinclude.hpp file which includes a compiler specific pre-include and then a boost/config/postinclude.hpp for afters? I've created ones for BCB which I use here, that simply do #praga nopushoptwarn #pragma option push -a8 -b -Vx -Ve -pc -w-8027 for pre and #pragma nopushoptwarn #pragma option pop for post (probably don't need the nopushoptwarn in postinclude though). These options are from regex. I may be a better idea not to include disabling warnings in the default boost options? And also, It might be worth adding -Vg- to disable codeguard for boost, unless the new build system will build CodeGuard libraries as well as non-cg enabled libraries. These options also should be the same as the default jam options for the compiler also. What do you think? Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.30.1 released
At 04:43 PM 8/7/2003, Daniel Frey wrote: On Thu, 07 Aug 2003 17:38:22 +0200, Daniel Frey wrote: David Abrahams wrote: No, it means managing the next release. Um, no, I don't feel like I can handle that. Sorry. I'm sure it's a lot of work and a big Thank You! to you for doing this job, but I think it requires knowledge which I don't have. And more time than I have, but this seems to be everybody's problem... :) Just to clarify: I don't meant to reject volunteering to the release process in general. It's just that I am sure that I would make a mess of 1.30.2 due to the tight shedule. Also, I need to learn more about some parts of boost that I don't feel comfortable with (yet). Anyway, if you really think I should/could manage a release, I suggest that I get more time and try my hands on 1.31.1 or something similar. As far as 1.31.0 goes, I don't mind managing most of it. But what would be a great help is if you (and anyone else interested) would volunteer to work on patches/bugs/issues management. There are really two aspects of this: (1) Making sure that patches, bugs, and issues get dealt with. (I can provide more details on what this involves.) (2) Figure out a better way to track patches, bugs, and issues. Somehow we aren't making use of available tools; we need to fix that. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
On Friday, August 8, 2003, at 12:21 PM, 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. The only major thing I know needs to be done is to complete the documentation for the new iterator adaptors. I'd like to get that over with soon, so it isn't hanging over our heads much longer. As far as I can see Jens Maurer has updated boost.random to his standards proposal, but not yet the documentation. I believe it would be important to have the random documentation be consistent with the sources, especially since the interface has changed significantly. Matthias ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [MPL] Metafunction classes
Aleksey Gurtovoy [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[...]
typedef typename apply
typename lambdaPolicy::type
, T
::type p;
things should work independently of whenever 'Policy' is in form of
'my_policy_' or 'my_policy' - given that the latter is a metafunction
class, of course.
Never mind. It all works as advertised. I thought a class only had to
have a nested apply struct to be metafunction class, but it also
needs a typedef .. type; in the *apply*. I think I tried putting in the
type,
but I put it outside of the apply, which was causing my problems. It
seems odd that I have to say:
struct Policy
{
template typename P
struct apply
{
typedef apply type;
// ...
};
};
I guess that is to be consistent with metafunctions, but for some
reason I thought that lambda or mpl added the type for you. Anyway,
all is well now. Thanks for the help (Dave too).
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- Brock Peabody [EMAIL PROTECTED] wrote: I think now we need to decide which *nix GUI API to use and get started on a proof of concept. I am currently working with win32 only. I can take care of this one. I think it'll be nice to have support for X as well. Maybe we should decide which elements of the layer 1 API to implement first. What do you think about: window, button, edit, and static_text? We can get a simple sub-language running on top of those few controls quickly enough. I think it'll be nice to include a container like control like list/tree control to demonstrate how they could be linked to STL iterators. I was thinking about starting to work on on the layer 2 design first. The idea is to design the layer 2 the way we'd like it to be first. It'll provide a set of natural requirements for layer 1. Using these requirement, we'll try to design the layer 1 traits/polices. Then we review it and decide whether it could be implemented on win32/X platform. If it doesn't work, we'll revisit the layer 2 design again and correct the layer 1 requirements. I'd suggest a recursive design procedure. :) I think we'll have to establish some basic design/implemntation polices/idioms. 1. For instance how we handle memory allocations, are we going to use std::allocator idiom or just new/delete. 2. Is the library thread-safe or not. 3. Event handling polices (send/post, etc.). 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 sublanguage ?
At 3:28 PM -0500 8/6/03, Brock Peabody wrote:
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)));
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.
--
-- Marshall
Marshall Clow Idio Software mailto:[EMAIL PROTECTED]
Hey! Who messed with my anti-paranoia shot?
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New Filesystem Lib function to set last write time
At 03:35 PM 8/6/2003, Beman Dawes wrote: I've having trouble with the Borland compiler. It is getting an error in its own utime.h header: Error E2303 D:\Program Files\Borland\CBuilder6\Include\utime.h 42: Type name expected If anyone can figure out a workaround, please let me know. Never mind; I've worked around it. In one header Borland puts time_t in std::, and then in another headers assumes it is in the global namespace. --Beman ___ 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: Aleksey Gurtovoy [EMAIL PROTECTED] writes: I worry a little about requiring library authors not to regress on compiler combinations they don't test with. Well, the regressions are run daily, so testing happens. Another question is whether library authors care about how their libraries perform on all the compilers the regressions are being run on. Obviously, some compilers/configurations are included in the regression testing because the ones who manage the latter are the ones who are most interested in those. Then, again, obviously, some compilers/ configurations are included in the regressions because they are very widely used. For every release, the interested parties include library authors, regression runners, the release manager, the maintenance wizard, and of course active users who are subscribed to either of the lists. Given the above setup, the implied interests of the participating groups, and their explicit and implicit responsibilities and gratitude towards each other, I think striving for no regressions goal I stated above would be both a reasonable and fair strategy which can be made to work. Some people are posting regressions for pre-release compilers. Should a library author should be expected to keep his library healthy on some weird/broken compiler just because it happened to work there by chance at one point? You skipped the part of my original posting which explicitly said: While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. Still, lots of weird/broken compilers are non-beta. IMO all the Borland tools fall into that category. Lots of people consider supporting older versions of released compilers to be unneccessary. I don't always agree, but for example I recently dropped CWPro7 support from Boost.Python, IMO with justification. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Iterator adaptor question
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. Will the new iterator adaptor framework help? pgp0.pgp Description: signature
RE: [boost] [date_time] improvements
John -
Sorry to be slow on this reply...
John Torjo wrote:
[1]
unary operator-(time_iterator).
Example: -hours(24) instead of hours(-24).
(seems more straightforward)
I see your point, but then don't you have to add all the other
operators for consistency? Not sure that makes sense to do with
the iterator.
I'm sorry I messed up. I wanted it for time_duration :)
But anyway, unary operator- I think could make some parts of code a little
more readable. For instance, I had some code where I would use time_iterator
to go from, lets say, today, to 3 months before.
I think unary operator- is very easy to implement for time_duration (and
perhaps date_duration).
Ah, that makes sense -- on the todo list...
[2]
Does a *FOUR* functions justify having a jam file?
(greg_month::as_short_string(), greg_month::as_long_string(),
greg_weekday::as_short_string(), greg_weekday::as_long_string())
... detail omitted...
I thought a smart compiler could definitely overcome that.
Something like, a static inline function:
// Warning: untested code
static const char* as_short_string( int idx) {
static const char * months[] ={ ... };
return months[ idx];
}
Yep, true.
localized strings ever gets into the library there will be many more
strings (take a look at libs/date_time/test/gregorian/test_facet.cpp).
Finally, there may be other functions that eventually will be in the
library and not inlined.
Sure thing. But you haven't convinced me ;)
Basically, the above could become:
static const char * default_as_short_string( int idx) {
...
}
And as for locales, the user can choose the right locale for him, you can
still have some static functions, like:
static const char*[] de_short_month_names() {
static const char* const
names[]={Jan,Feb,Mar,Apr,Mai,Jun,Jul,Aug,Sep,Okt,Nov,
Dez, NAM};
return names;
}
So, if the user wants a de locale, you could - behind the scenes -, select
de_short_month_names(), de_long_month_names(), etc.
- they could exist in a distinct header, and they would be #included only if
the user needs them (wants localized information).
Ok, sure. I can't really see anything wrong with your argument. That said,
I still don't want to change this lightly. While this would make life
easier for users, they are already used to the library. If I get rid of it
and then want/need it back it won't be nice. So I'll put this on my
to be considered list, ok?
As I understood by looking at the docs, fraction actually means
nano-seconds.
Not necessarily. It depends on the resolution the time duration template
is
instantiated with. For example, there is a second option that many people
use
In that case, I'm confused ;-)
There should be more info in the docs, I think.
Yep, that's for sure.
which only provides microsecond duration resolution, but only requires a
single 64 bit integer to represent a time value. The bottom line is that
fractional seconds is a count of the number of fractional seconds at the
given resolution.
Maybe still, for simplicity you could have a time_duration::nanoseconds()
function.
I agree this would be nice. Of course, I think this will need to fail
compilation if the resolution doesn't support nanoseconds.
Also, now that I come to think of it :), the following functions would come
in handy:
time_duration::total_hours() - the number of hours (ignoring mins, secs,
etc.)
Don't see how this would be different from the current method.
time_duration::total_mins() - the total number of minutes (hours*60 +
minutes() )
time_duration::total_secs() - you get the idea.
(of course they can be computed, but it's more error prone)
Yep, these would be handy -- on the list...
Jeff
___
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 10:33 PM To: Boost mailing list Subject: Re: [boost] GUI/GDI template library [...] 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
[boost] Re: UI++
I am currently porting something called XMLUI to use boost/bjam etc. The general background of XMLUI is based on the work we did at mBED for a flash-like animation system (although it predated flash). This project is the culmination of a number of years of design of widget-less UI systems that I have been undertaking. What XMLUI is now: - XML based description language for UI's (windows, panes, buttons etc). - Rendering engine for the above (only on windows at the moment, and not GPL or using boost). - Dynamic loading system (just DLL's on windows). - Tools for developing XMLUI are written in XMLUI. - written using C++ (VC at the moment). - heavy use of patterns and STL. I presented a white-paper on XMLUI at an XML conference last year (which I can send to people who want it. It's only a 170K PDF), and the project has been used commercially to build a number of systems. So where am I at? A complete UI system may involve a complex class hierarchy of maybe 200 to 300 objects. Each of these objects needs to interact in the following ways: - settable and gettable members directly in the UI (so that a slider can modify a text field for example). - observer pattern in heavy use so that a button can dim based on the value of another object's field (for state maintaining), and so that a slider can update a text field. - each object persists to and from XML files (and complete hierarchies of objects need to do this). So to support this, from the start you need: - A tangle tool which can read a large object schema and build C++ classes for: - the visitor patterns so that members can be set/get. - the observer pattern. - the prototype pattern (for object inheritance and persistance). - the composite pattern so that one object can contain lists (vectors) of other objects and references to other objects. - A schema which describes the following types of objects: - panes which represent the different types of UI elements. - commands which encapsulate the actions for the buttons etc (and for the undo system). - enablers and pipes for moving data around between objects. - some type of expression language. - generators for filling panes with data. What I have done using boost: - A general persistence scheme called cpppersist which is general, but I have written an XML persister. - A general reflection scheme called cppreflect which allows members of objects to be set/get via strings (and found etc). - A base object for all XML persisted/reflectable objects called xmlobj which combines the above two things. These are almost ready to go up (on sourceforge probably), I just need to write a few more unit tests. What I am working on right now: - a tangle/weave literate programming system using xmlobj's called cppliterate which I can use to build all of the classes, create the Jamfiles etc. I am a couple of weeks of work away from finishing this off. I need to integrate tangle into boost's build system, and I need to build a weave tool (it really isn't needed since I get around it now by having tangle build doxygen friendly source files, and then run doxygen on them. But a REAL weave will be necessary for user documentation etc). Naturally weave and tangle will be built using weave and tangle :-) So it's an interesting if not recursive exercise to build (like, how much of tangle do you need to have written before it can start tangling itself?). When I've finished cppliterate I'll let you guys know, but of course this still isn't anything to do with UI's, but it would be useful for others who need to do large scale cpp development. This will be released the same as boost is (using the same build system), so it might be cool to put it into boost at some point once it's proven useful. Once this is done, you could use it to build a description system for a widget library, which is a necessary thing. You could probably write an object-widget mapper in tangle to generate the WxWindows/QT/MFC stubs directly which would save time. Then it's a case of taking my existing schemas that I have for XMLUI, creating all the objects and then porting all of the code currently running on windows to this new system. This is probably a good 6 months away, but it will happen this year, and it will be free (probably GPL). It will probably only be windows/Mac OS X available, but a port to X would be simple. 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.
Re: [boost] Re: Release of 1.30.2 imminent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Maddock wrote: |Just out of curiosity. What the heck is librt? | | | It contains the POSIX realtime feature set (used by boost.threads, and hence | tested by boost.config for timeouts and thread priorities and the like). Ahhh.. Thanks! 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/O2ny0ds/gS3XsBoRAgmqAJ48W8mgnaD0xDKjiE8SwfyjOmGI1gCfdYlW Bj4/UnUt8H5aVe6xWC5xI+k= =+0Iq -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: ublas and gcc (was: Re: [boost] Re: Compiler status for GCC 3.3)
At 07:02 PM 8/10/2003, Gabriel Dos Reis wrote: More seriously, did you have a chance to test GCC-3.3.1? I just tested 3.3.1 on Windows, and the 7 ublas tests which had been failing on 3.3 are now passing. The variant libraries variant_test4 is also now passing. The current plan is to use 3.3.1 as one of our release criteria compilers for Boost 1.31.0, so we will try to account for each remaining GCC 3.3.1 failure. There are only a handful of GCC failures left. Perhaps we can submit bug reports on any that turn out to be GCC problems, and GCC can join the 100% pass club with 3.3.2. (I still haven't gotten over Microsoft being the first compiler to pass 100%. The world takes some strange twists sometimes.) --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] SourceForge Tasks enabled for 1.31.0
SourceForge has a Tasks list feature which is now enabled for Boost. See the Tasks entry on the top toolbar at http://sourceforge.net/projects/boost/ If you click Tasks, that should take you to a page listing sub-projects. There is currently only one sub-project, titled 1.31.0 Release Preparation. If you click on that sub-project, you should be able to see (at least) two tasks, and be able to browse their details. The plan is to use this feature to actively manage the preparation for release 1.31.0. IIUC, anyone should be able to view the list, but only Boost developers can add to it or modify it. I've tried to set all developers permissions to be able to add/modify tasks, but if someone has been missed please let one of the moderators know. There are also several Boosters who actively help with bug reports, patches, and the like who may need to be added so they can help with tasks management. Again, please let a moderator know. Boost developers should add tasks for themselves if they want other Boosters, including the release manager, to know that a task needs to be complete before the release. But only release managers or moderators should add tasks that others have to complete. A task list isn't wish list of things you would like to see someone else do; rather it is a list of specific tasks that a release manager, Boost moderator, or a library's developers view as a precondition for release. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- Brock Peabody [EMAIL PROTECTED] wrote: 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 MusE is a Linux music editor. ... Eugene, you brought this whole thread up so I think you should pick the name :) I like Notus too (it is better when a namespace is short). I checked sourceforge, it is available. If there are not strong objections, let's use it as a codename for now. Hopefully the south wind will be good for the landscape of GUI development. :) I am going setup a sf project. Are there any guidelines on how to setup/structure sf projects that are intended to be submitted to boost? 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: ublas and gcc (was: Re: [boost] Re: Compiler status for GCC 3.3)
[EMAIL PROTECTED] (Joerg Walter) writes: [...] | 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. GCC-3.3 is GCC-3.3.0 in disguise and I tend to refrain myself from using .0 releases outside of experimental works :-). More seriously, did you have a chance to test GCC-3.3.1? -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: RC_1_30_2 tagged for release
Martin Wille wrote: David Abrahams wrote: Martin Wille writes: The fix made to the gcc toolset regarding the use of the GXX variable should be backported to 1_30_2. Please be more specific, i.e. post a patchset. If I had a patchset then I would have applied it :) (I sent a bug report some time ago to the JamBoost list. Rene fixed the issue immediately) I was talking about the difference between 1.70 and 1.69 of gcc-tools.jam. I don't know wether other changes to that file should also be applied to 1_30_2. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Release date? (was the boost::signal sample crashes)
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. OK, I've got this working pretty well with regex - but as it entails changes to boost.config I'm not sure if I should make the changes now or wait until after the next release - Beman I guess we have a couple of weeks still to run yes? [ Footnote - on second thoughts it just means moving code that's in boost.regex now into the central config system it's not new code - so maybe I should go ahead ] John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
