[boost] Re: Filesystem: create_directories
David Abrahams wrote: The documentation for create_directories makes no sense. It says only: void create_directories( const path ph ); Precondition: ph.empty() || forall p: p == ph || is_parent(p, ph): is_directory(p) || !exists( p ) Postcondition: exists(ph) is_directory(ph) It looks as though this is the same as create_directory, but has a weird precondition. Sure. It has the (almost) the same postcondition, but has waeker precondition: the parent directories are not required to exist. I swear I was *completely* baffled by its purpose until I looked at the header file. I'd say that pre/post conditions are just correct. Maybe more docs can be added. The comment in the header file describes it pretty well, though. Ehm... only postcondition there is not correct: is_empty(ph) is not guaranteed. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sudden VC6 ICEs in BGL code
David Abrahams wrote: David Abrahams [EMAIL PROTECTED] writes: Jeremy Siek [EMAIL PROTECTED] writes: I seem to remember the named parameters mechanism being fragile under VC6. After a painstaking binary search in recent CVS states for the ICE, I narrowed it down to: snip Worked around now in CVS. Had no idea my innocent change will break anything. Why doesn't vc6 like declarations of static methods inside class? - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: Re: Filesystem: create_directories
Reid Sweatman wrote: Another option might be: create_directory_and_parents That name is longer than create_directories although it better describes the function. I like create_directory_path That one's good, and captures the essential distinction well. Other possibles: create_full_directory, or create_rooted_directory. Dunno. On whole, I might prefer your choice. Although it again lengthens the name, create_directory_and_path captures another minor piece of the distinction. You could also play with the distinction (none save semantic in most file systems) between pathname and filename; a filename is usually just the thing at the leaf-terminal end of the path (and needn't be a file, save as a directory is often actually implemented as such), while the pathname is the full Monty. FWIW, I don't like - create_full_directory, because I don't understand what it means for directory to be full. Full of files is one interpretation which is not correct. - create_rooted_directory, because I don't know what's rooted directory. - create_directory_and_path, because how if one can create directory, one can name that directory, and the path should already exist. So, to summarize, I've no problem with the current name that I've introduced. Of other suggestions create_directory_and_parents looks best to me. ensure_directory_exists does not imply any operational semantic (i.e. the name does not say that the directory will be created. One might expect exception to be thrown if dir does not exist). demand_directory is good. One problem is that demand still does not communicate to me that something will be created. - Volodya In the original scheme, I would think the problem with create_directories is that it would seem to imply (to me, at any rate) the creation of multiple directories at the same depth in the file system. Anyway, them's my kibitz's. Reid Sweatman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
E. Gladyshev wrote: Have you built the signals library multi-threaded or single threaded and Whatever the default build is. Single threaded. The application is set to use multi-thread run-time libraries and MFC.DLL. Not seen this specific one, the most common problem I saw was a hang so it may well not be your problem, but worth looking into. It may well be the problem. I didn't see crashes, just hangs. You have objects created inside the signals lib (non-multi-threaded) so it doesn't create/initialise the lock member variables. There is then header code which is compiled directly in your application (multi-threaded even though you only use 1 thread) and so it tries to access these non-existent locks in the objects created in single threaded signals lib. If you are going to use a multi-threaded application/run-time, you must build/link the multi-threaded version of the boost libs also. Because of the crash, you may still have another problem, but I would solve this one first, then look for the next. I saw the hangs under Borland C++ Builder, the bug may present itself in a different way under VC++. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: tokenizer comments
Beman Dawes wrote: Care to suggest a docs patch? Guess I asked for that g I should have time to write something up this weekend, assuming John is happy. -- AlisdairM Team Thai Kingdom ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: Re: Filesystem: create_directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir, Vladimir Prus wrote: | Reid Sweatman wrote: | | So, to summarize, I've no problem with the current name that I've | introduced. :-). Seriously having two functions that differ only by number is a no-go to me. | Of other suggestions create_directory_and_parents looks best | to me. ensure_directory_exists does not imply any operational semantic | (i.e. the name does not say that the directory will be created. That's exactly the point. The operational semantics are that the directory is only created if it not already exists. The long name is do_what_it_takes_but_make_sure_this_directory_exists(path p); | One might | expect exception to be thrown if dir does not exist). This is a bit of a stretch AFAICS but if ensure is to much like assert, I am perfectly fine with demand. | demand_directory is | good. One problem is that demand still does not communicate to me that | something will be created. And that's good because creation does not necessarily happen. Not until you require that create_directories creates at least one directory. I don't see this in the documentation and I don't think this would be the most usable semantics. 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/LiGi0ds/gS3XsBoRAvypAJ9tqAhHcHL4IjyE7pdjF1JKD8iJpACfVC2y 2mcc8YE/zl1umrg/WJjo7Es= =O4XE -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: circular_buffer update
Hi Pavel,
I agree with most of your comments.
2. in function cb_iterator::operator -(), shouldn't it be std::less instead
of less? (actually I do not see why isn't enough here).
I call less() just because efficiency reasons. If I called operator it would
result in unnecessary calls to create_internal_iterator().
5. Similarly in circular_buffer::allocate(). (I wonder where
std::length_error
does come from?)
The STL delivered with MSVC7 does it like this. In your opinion what should it
throw?
Once again unused space overhead. What about this adaptor?
template class T class Adaptor {
public:
typedef typename circular_bufferT::iterator iterator;
typedef typename circular_bufferT::size_type size_type;
private:
size_type m_final_capacity;
circular_bufferT m_buff;
public:
Adaptor(size_type capacity) : m_final_capacity(capacity), m_buff(1) {}
iterator begin() { return m_buff.begin(); }
iterator end() { return m_buff.end(); }
size_type size() const { return m_buff.size(); }
size_type capacity() const { return m_final_capacity; }
T operator [] (size_type index) { return m_buff[index]; }
void push_back(const T item) {
check_capacity();
m_buff.push_back(item);
}
iterator insert(iterator pos, const T item) {
check_capacity();
return m_buff.insert(pos, item);
}
private:
void check_capacity() {
if (m_buff.full() m_buff.size() m_final_capacity) {
size_type new_capacity = m_buff.size() * 2;
if (new_capacity m_final_capacity)
new_capacity = m_final_capacity;
m_buff.set_capacity(new_capacity);
}
}
};
Jan
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Misha Bergal [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] writes: I am slightly concerned about the number of unexpected failures with intel7.1-stlport. Is there a configuration problem? Yes, there is. The main trunks intel-win32-tools.jam,1.28 enables wchar_t for our configuration but RC_1_30_0 intel-win32-tools.jam,1.23 doesn't. Our STL installation is compiled with wchar_t support. I will setup another copy compiled without it. Done. The results for intel7.1-stlport are definetely better now, there is just one regression in lexical_cast_test - I will take a look at it. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
David Abrahams [EMAIL PROTECTED] writes: Could you possibly do another regression run? There have been quite a few little changes since the last one. Sure, actually we are running the regressions on RC_1_30_0 continuously, with the interruptions for configuration changes and power outages (they happen here). We get sources from main SF CVS, one run takes about 6 hours (we do clean rebuilds) - so the results on the web site should be really up-to-date. Please ignore the results for Comeau if there are still there - it has been enabled by mistake. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Filesystem: create_directories
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams Sent: Sunday, August 03, 2003 8:09 AM To: [EMAIL PROTECTED] Subject: [boost] Re: Filesystem: create_directories Dave Gomboc [EMAIL PROTECTED] writes: Ah, naming again. My favourite. :-) I like create_path_and_directory. I prefer this order of the two terms because logically the path exists before the directory itself does. create_full_path(path, 'd') create_full_path(path, 'f') That distinction is part of what I was trying to work around with my off-the-wall suggestions. However, there's a fundamental distinction between a path and a directory: a path describes the location of a directory, while a directory is an object. I know this confusion is built into just about every OS out there, but I think a naming scheme that made this distinction obvious would be a good thing. What, you're waiting for suggestions? I've already shot my wad on that one, with the full and rooted notions. They don't really capture it, though. Problem here is that you want the directory to exist, but you're describing the two functions in terms of objects, on the one hand, and paths on the other. There must be some keywords that would capture this. I'm going to respond to a message a little further down the thread, though, with a different distinction, and it'll have to capture both g. Reid Sweatman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
It might not be too hard to make the GUI objects 'serialize' themselves into a native resource file but this would be useless without something to convert a resource file back into C++ code. Something like this could be written on top of a pure C++ solution with the help of a serialization library. Indeed, that would be cool! I suppose you're talking about something that will write ALL GUI objects from a OS-independent resource file to a native resource file. Best, John ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI/GDI template library
2. is there potential to identify a generic state machine that can be part of your gui templates/library without getting tangled in the application specific machines. i One more on the state machines. Even the standard button control is a state machine (when you press it, it goes to the push-down state). But again it'll be the next layer. In the propsed library it will generate the mouse down event and do nothing. I'm not sure if it makes too much sense what I'm about to say, but I'll say it anyway :) I don't think we should include the generic state machine in one of the first layers of the design. I think the generic state machine should sit on top of the design (be based on the other layers), and based on the possible states of each possible type of GUI (edit box, push button, etc), just create a control that can respond to them in an easy and straightforward way. Best, John ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
1. i'm 99% sure that plain resource language or even XML is much cleaner than c++ bindings- templates-operators mess. Templates aren't always beautiful, but this library is targeted towards C++ programmers who should be familiar with them. We've had the STL for over 5 years now. I don't know how to read plain resource language or XML, but I know how to read C++. That said one of the primary goals of the library should be to make easy to write and read user code. I think the code generated using my library is pretty easy to read so far: gui_applicationemployee gui = row(Name: , edit(employee::name)); Forgive me for not agreeing with you here ;-) Just think how hard it is - even for a programmer -, when dealing with lets say 50-100 types of windows, each window having more than 20-30 controls, to have an OVERVIEW. Not talking about maintaining that code. Not talking about internationalization. So IMHO resource files are THE option. Best, John ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: smart_assert - update; SMART_ENFORCE works
Hi Michael, 1) How is this going? Unfortunately, I've been EXTREMELY busy these days :( It's almost done - I've worked on making a small footprint of SMART_ASSERT (when using SMART_ASSERT, the generated code should be as small as possible) Note: try the latest version - www.torjo.com/smart_assert.zip I want to write the full documentation, and then post it to boost sandbox as well. 2) I notice that when the Debug button in the Win32 assertion dialog is pressed, it breaks into the debugger deep inside smart_assert code. Any chance of moving the debug-break out into the SMART_ASSERT macro? I suppose this would be done by making the handler return values that specify standard actions (do nothing, break into debugger, abort, etc.). Hmm. I think it can be done. I'll try these days - hopefully should do it until Fri. 3) I've always wanted an assertion that would evaluate the condition and fire when the enclosing block exits instead of immediately (i.e., a postcondition). I realize this would have to work in an entirely different way from a standard assertion, in that it would require the condition to be a boost::bind type function or boost::lambda type expression that could be evaluated later. Something like a ScopeGuard that evaluates to an assertion, in fact. Do you have any interest in pursuing this? I'd be glad to help, if I can. I'm not quite sure of the usefullness of this. Please go into more details. Best, John ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Fun PP lib example
Here's an example I just cooked up of using the PP lib to solve a classic C++ OO problem: repeated boilerplate in the definition of Pimpl classes. Paul, if you want to put it (or something like it) in the PP lib docs, you're welcome to. Hi Dave, Pretty cool! Small note: instead of 'interface', maybe you could use some other word, like interf or something, since VC6 has its own (stupid) extension, and highlights the 'interface' as a keyword (not sure if VC7 does the same). Anyway, users of VC could get a little confused :) Best, John ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [date_time] improvements
Hi Jeff,
Told you I'd come back for more ;)
Here are some more improvements I would consider useful:
[1]
unary operator-(time_iterator).
Example: -hours(24) instead of hours(-24).
(seems more straightforward)
note: hours(24) can be also written as:
hours(0) - hours(24) but look ugly
[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())
They could definitely be made static or something.
(or the user could be given a choice - using the date_time from a
.jam-generated
dynamic link library, or directly)
[3]
I've been recently involved in a project that used to use raw time_t's.
A conversion to/from time_t would come in very handy.
(at least one way would be enough).
I've created such a function:
#include boost/date_time/posix_time/posix_time.hpp
// converts raw time to cool ptime structure
inline boost::posix_time::ptime rawtime_to_ptime( time_t raw) {
using namespace boost::posix_time;
using namespace boost::gregorian;
tm details = *localtime( raw);
date day( details.tm_year + 1900, details.tm_mon + Jan,
details.tm_mday);
time_duration offset( details.tm_hour, details.tm_min, details.tm_sec,
0);
return ptime( day, offset);
}
pretty simple and straightforward, I think.
[4]
time_duration::fractional_seconds() seems pretty confusing.
As I understood by looking at the docs, fraction actually means
nano-seconds.
Why not use time_duration::nano_secons() instead?
(at first, I did not know what fractional_seconds meant)
[5]
In file gregorian_calenar.hpp, you
#include gregorian_calendar.ipp
I think to make it more portable, it should be:
#include boost/date_time/gregorian/gregorian_calendar.ipp
[6]
documentation - does not say if greg_day starts from one or zero
(from experiments, I realized it starts from one)
Maybe this is not so important, but was confusing for me at first.
[7]
I think a wrapper like I've attached would be pretty useful for dealing
with time values - mainly for testing/debugging.
(as a matter of fact, this simple wrapper helped me a lot catch a few bugs
from code written by others. all I had to do was replace time_t with
time_t_wrapper)
Short description:
- this allows writing times (to streams) in a user-friendly manner:
besides the time_t value, a *word* that shows what the time_t value means.
- also, reading these values from streams can be done using the ''
operator.
The cool thing is that both time_t and time_t_wrapper values can be read
from a stream.
time_t_wrapper can be used in two modes:
- debug mode
- release mode (time_t_wrapper can be as efficient as time_t in release
mode)
In debug mode, each value contains a user-friendly string corresponding to
the time_t value.
As a side-note, this could be made much more general, to work for other
HANDLE-like types (for instance, HWND in Win32 or so).
What do you think?
Best,
John
--
John Torjo
-- Practical C++ column writer for builder.com.com
Freelancer, C++ consultant
mailto:[EMAIL PROTECTED]
time_t_wrapper.h
Description: Binary data
time_t_wrapper.cpp
Description: Binary data
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Filesystem: create_directories
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams Sent: Sunday, August 03, 2003 7:15 PM To: [EMAIL PROTECTED] Subject: [boost] Re: Filesystem: create_directories Thomas Witt [EMAIL PROTECTED] writes: I'de like to get away from create. As I understand it, what we really want is to make sure a directory path actually exists without necessarily creating any directories. To me calling a create function for something that already exists should be an error. I can't see a reasonable way to have these semantics with create_directories. What about something like this: ensure_path_exists(path); I have a word I use in scenarios like this: demand. demand_directory(path) Demand is not a perfect fit, but if you treat it like a term of art, it works. And this is the message I referred to in my slightly prior post. The distinction here you've already pinned down. You're right in your final comment, I think; any word I can think of is just a synonym for demand, like request, or return. This is a place where traditional CS has let us down; it's a distinction that's been there since there were decent file systems, but no one ever coined a word to cover the situation, which is really common. Gee, I'd have thought Knuth would have invented one, if no one else g. This feels almost (but not quite) like the distinction between logical or and xor. Of course, there, Boole supplied terminology. Hmmmn. It feels *exactly* like a singleton class, in that if there's not one, you create it, and if there is, you just return it. In fact (to go OT a bit), since directories are unique (ignoring aliases), you could implement this functionality via singleton. Most of the terminology associated with singletons doesn't much work here, though. How about turning it into a functor? I guess that's sort of a cheat, inasmuch as it just dodges the naming issue altogether, and requires the semantics to be documented somewhere other than in the name. I don't know as I'd fight too hard for a solution like that. Anyway, was pondering, it bubbled to the top. To clarify what was something of (two) rambles, I think the issues that need encapsulation in names are: 1) Distinction between path and directory 2) Asking for an object that may or may not exist; ditto its precursors 3) Default behavior in different cases of (2) I suppose (3) could be captured via any of several mechanisms; simplest seems to be overloaded unary and binary versions. Reid Sweatman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Re: Filesystem: create_directories
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Vladimir Prus Sent: Monday, August 04, 2003 12:51 AM To: [EMAIL PROTECTED] Subject: [boost] RE: Re: Filesystem: create_directories Reid Sweatman wrote: snipped FWIW, I don't like - create_full_directory, because I don't understand what it means for directory to be full. Full of files is one interpretation which is not correct. - create_rooted_directory, because I don't know what's rooted directory. - create_directory_and_path, because how if one can create directory, one can name that directory, and the path should already exist. Well, I knew they were imperfect attempts. The semantic difficulty you have with them is due to something I mentioned in a just-posted message (this thread is fragmenting in my reader for some reason) you'll see shortly, namely that a directory and a path are different things, and yet are often used interchangeably. I think in a library as fundamental as this the semantics implied by the names should be as tight as possible. So, to summarize, I've no problem with the current name that I've introduced. Of other suggestions create_directory_and_parents looks best to me. ensure_directory_exists does not imply any operational semantic (i.e. the name does not say that the directory will be created. One might expect exception to be thrown if dir does not exist). demand_directory is good. One problem is that demand still does not communicate to me that something will be created. Ditto. Reid Sweatman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: Re: Filesystem: create_directories
Thomas Witt wrote: Vladimir Prus wrote: | Reid Sweatman wrote: | | So, to summarize, I've no problem with the current name that I've | introduced. :-). Seriously having two functions that differ only by number is a no-go to me. | Of other suggestions create_directory_and_parents looks best | to me. ensure_directory_exists does not imply any operational semantic | (i.e. the name does not say that the directory will be created. That's exactly the point. The operational semantics are that the directory is only created if it not already exists. The long name is do_what_it_takes_but_make_sure_this_directory_exists(path p); May I bicycleshedingly suggest make_directory_hierarchy() or make_hierarchy() ? On X-Windows systems there is a small program called mkdirhier. So, the names I suggested resemble it a bit. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Fun PP lib example
Aleksey Gurtovoy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola wrote: Aleksey Gurtovoy [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] David Abrahams wrote: Here's an example I just cooked up of using the PP lib to solve a classic C++ OO problem: repeated boilerplate in the definition of Pimpl classes. There is another variation of the idiom, sometimes called hidden state, which doesn't have the shortcoming in the first place: A shortcoming of the hidden state idiom compared to the classic delegation idiom is that only the state is encapsulated, not the behaviour. I am not sure what do you mean by encapsulated. Hidden in a source file as opposite to the header? Sort of. Hidden in any other file different from the file containing the declaration of the public interface. IOWs, if you need to hide the operations, not just the state, you still need to mirror the interface class member functions into the impl class. How so? With the hidden state, what would be private member functions becomes free functions at the file scope. Ah... you didn't show this in your example... what you're right AFAICT. Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Misha Bergal [EMAIL PROTECTED] writes: Misha Bergal [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] writes: I am slightly concerned about the number of unexpected failures with intel7.1-stlport. Is there a configuration problem? Yes, there is. The main trunks intel-win32-tools.jam,1.28 enables wchar_t for our configuration but RC_1_30_0 intel-win32-tools.jam,1.23 doesn't. Our STL installation is compiled with wchar_t support. I will setup another copy compiled without it. Done. The results for intel7.1-stlport are definetely better now, there is just one regression in lexical_cast_test - I will take a look at it. It looks like you need to build your vc6 stlport debug library also; that would account for the failure in the testing library tests. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fun PP lib example
John Torjo [EMAIL PROTECTED] writes: Here's an example I just cooked up of using the PP lib to solve a classic C++ OO problem: repeated boilerplate in the definition of Pimpl classes. Paul, if you want to put it (or something like it) in the PP lib docs, you're welcome to. Hi Dave, Pretty cool! Small note: instead of 'interface', maybe you could use some other word, like interf or something, since VC6 has its own (stupid) extension, and highlights the 'interface' as a keyword (not sure if VC7 does the same). Anyway, users of VC could get a little confused :) I have little sympathy ;-S -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sudden VC6 ICEs in BGL code
Vladimir Prus [EMAIL PROTECTED] writes: David Abrahams wrote: David Abrahams [EMAIL PROTECTED] writes: Jeremy Siek [EMAIL PROTECTED] writes: I seem to remember the named parameters mechanism being fragile under VC6. After a painstaking binary search in recent CVS states for the ICE, I narrowed it down to: snip Worked around now in CVS. Had no idea my innocent change will break anything. Why doesn't vc6 like declarations of static methods inside class? Who knows why? I just flail around a bit until I can find a fix ;- -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Compiler support
Sorry if this is a recurrent question...
Has anybody been able to compile BOOST (date_time and test) with aCC (HP ANSI C++ B3910B A.03.35) on
HP-UX ?
I tried using configure and with the new STL shipped with the compiler (-AA flag): the configure
seems pretty good (no Failed), but the compilation of date_time fails:
Error 174: /sw/local/pab/boost_1_30_0/boost/operators.hpp, line 368 # Function redefinition;
previously defined as bool boost::operator
=(const #1 ,const #2 ) at [/sw/local/pab/boost_1_30_0/boost/operators.hpp, line 125].
friend bool operator=(const T x, const U y)
^^
Error 445: /sw/local/pab/boost_1_30_0/boost/operators.hpp, line 368 # Cannot recover from earlier
errors.
friend bool operator=(const T x, const U y)
^^
The offending code snippets are the following (in boost/operators.hpp):
template class T, class U, class B = ::boost::detail::empty_base
struct less_than_comparable2 : B
{
friend bool operator=(const T x, const U y) { return !(x y); }
friend bool operator=(const T x, const U y) { return !(x y); }
friend bool operator(const U x, const T y) { return y x; }
friend bool operator(const U x, const T y) { return y x; }
friend bool operator=(const U x, const T y) { return !(y x); }
friend bool operator=(const U x, const T y) { return !(y x); }
};
[...]
template class T, class U, class B = ::boost::detail::empty_base
struct partially_ordered2 : B
{
friend bool operator=(const T x, const U y)
{ return (x y) || (x == y); }
friend bool operator=(const T x, const U y)
{ return (x y) || (x == y); }
friend bool operator(const U x, const T y)
{ return y x; }
friend bool operator(const U x, const T y)
{ return y x; }
friend bool operator=(const U x, const T y)
{ return (y x) || (y == x); }
friend bool operator=(const U x, const T y)
{ return (y x) || (y == x); }
};
aCC tells me that it's the same function... yuck...
Agreed, it's a sick compiler, but nevertheless...
I will try once more using STLport, but it's not about the STL IMHO.
Thanks for any 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] [date_time] improvements
On Mon, 4 Aug 2003 12:50:36 +0300, John Torjo wrote
Told you I'd come back for more ;)
Here are some more improvements I would consider useful:
[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.
[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())
They could definitely be made static or something.
(or the user could be given a choice - using the date_time from a
.jam-generated
dynamic link library, or directly)
Yes, to avoid multiple definitions of the said strings without having
to recreate them every time a date is formatted. Also, if a set of
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.
BTW, my original intent was to make much more of the library 'inline
swappable'. That is, by flipping a compile switch large chunks of the
library could either be inline or in the library -- whichever was
better for the user's performance / space tradeoff. I've let this
slide for now as the way I did it was a pain for users and there are
more important issues at the moment...
[3]
I've been recently involved in a project that used to use raw time_t's.
A conversion to/from time_t would come in very handy.
(at least one way would be enough).
I've created such a function:
#include boost/date_time/posix_time/posix_time.hpp
// converts raw time to cool ptime structure
inline boost::posix_time::ptime rawtime_to_ptime( time_t raw) {
using namespace boost::posix_time;
using namespace boost::gregorian;
tm details = *localtime( raw);
date day( details.tm_year + 1900, details.tm_mon + Jan,
details.tm_mday);
time_duration offset( details.tm_hour, details.tm_min,
details.tm_sec, 0);return ptime( day, offset); }
pretty simple and straightforward, I think.
I agree, this is on the todo list to add to the library. See
below for why it isn't already. I think I would write it like
this, however:
//Warning -- off the top of my head untested code (but should work)!
//in boost::posix_time namespace
posix_time from_time_t(time_t t) {
using namespace boost::gregorian;
return ptime(date(1970,1,1), seconds(t));
}
[4]
time_duration::fractional_seconds() seems pretty confusing.
Sorry about that...
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
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.
[5]
In file gregorian_calenar.hpp, you
#include gregorian_calendar.ipp
I think to make it more portable, it should be:
#include boost/date_time/gregorian/gregorian_calendar.ipp
Yep, that should be fixed.
[6]
documentation - does not say if greg_day starts from one or zero
(from experiments, I realized it starts from one)
Maybe this is not so important, but was confusing for me at first.
Well, I think greg_day might be a bit under-documented in general. I've
added your comment to the todo list.
[7]
I think a wrapper like I've attached would be pretty useful for dealing
with time values - mainly for testing/debugging.
(as a matter of fact, this simple wrapper helped me a lot catch a
few bugs from code written by others. all I had to do was replace
time_t with time_t_wrapper)
Short description:
- this allows writing times (to streams) in a user-friendly manner:
besides the time_t value, a *word* that shows what the time_t
value means. - also, reading these values from streams can be done
using the '' operator. The cool thing is that both time_t and
time_t_wrapper values can be read from a stream.
time_t_wrapper can be used in two modes:
- debug mode
- release mode (time_t_wrapper can be as efficient as time_t in release
mode)
In debug mode, each value contains a user-friendly string
corresponding to the time_t value.
The reason that I didn't put any time_t related interfaces into
the library is that I wanted to encourage people away from using
'under-abstracted clock-hardware-limited' time representations
in code. I suspect you may have spent many hours, as I have,
debugging errors related to the use of time_t. I mean, time_t
is 1/1/1970 0:0:0, right? Oops, minor point, I mean
UTC 1/1/1970 0:0:0. Was that time_t really a time
[boost] Re: Filesystem: create_directories
Vladimir Prus [EMAIL PROTECTED] writes: One problem is that demand still does not communicate to me that something will be created. That's why I'm saying you have to treat it as a term of art. It becomes like a naming convention (on demand, create XXX). -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem: create_directories
Darren Cook [EMAIL PROTECTED] writes: May I bicycleshedingly suggest make_directory_hierarchy() I've been following this discussion, and that is the best suggestion so far. I think the word make or create is critical, to show that something might be created. As someone else said, demand suggests an exception or error code migth be returned if the directory does not exist. I also like: make_directories_as_neccessary() on_demand is shorter than as_neccessary Also, more specific. Who's to say when it's 'neccessary'? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Boost-bugs] [ boost-Bugs-782831 ] CVS locks inboost-sandbox.
Bugs item #782831, was opened at 2003-08-04 18:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=107586aid=782831group_id=7586 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stas Fomin (sfomin) Assigned to: Nobody/Anonymous (nobody) Summary: CVS locks in boost-sandbox. Initial Comment: Please, remove locks in boos-sandbox. - ... cvs server: [06:56:04] waiting for yok's lock in /cvsroot/boost-sandbox/boost-sandbox/boost/policy_p tr/policy cvs server: [06:56:34] waiting for yok's lock in /cvsroot/boost-sandbox/boost-sandbox/boost/policy_p tr/policy cvs server: [06:57:04] waiting for yok's lock in /cvsroot/boost-sandbox/boost-sandbox/boost/policy_p tr/policy ... - while checkout. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=107586aid=782831group_id=7586 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Boost-bugs mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/boost-bugs ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Compiler support
Pascal Bleser [EMAIL PROTECTED] writes: aCC tells me that it's the same function... yuck... Agreed, it's a sick compiler You've hit the nail on the head. , but nevertheless... I will try once more using STLport, but it's not about the STL IMHO. My advice? Don't waste your time. Use GCC or some non-sick compiler for your platform, or, sadly, give up on Boost until HP gets their act together. Sorry, -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem: create_directories
FWIW, I use the word obtain in such contexts. A naming pattern of mine is therefore: create_something just to create something get_something to get something obtain_something to get something anyway (i.e. creating it if it doesn't exist) Sted David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Vladimir Prus [EMAIL PROTECTED] writes: One problem is that demand still does not communicate to me that something will be created. That's why I'm saying you have to treat it as a term of art. It becomes like a naming convention (on demand, create XXX). -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Torjo Sent: Monday, August 04, 2003 2:34 AM To: Boost mailing list Subject: Re: [boost] Re: Re: GUI/GDI template library [...] Forgive me for not agreeing with you here ;-) OK, but just this one time :) Just think how hard it is - even for a programmer -, when dealing with lets say 50-100 types of windows, each window having more than 20-30 controls, to have an OVERVIEW. Not talking about maintaining that code. Not talking about internationalization. So IMHO resource files are THE option. Resource files might be the right solution to some problems, but I think there are a lot of GUI applications that could be written more simply with pure C++ code. A C++ GUI library and a resource system could be complementary. Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem: create_directories
David Abrahams wrote: Darren Cook [EMAIL PROTECTED] writes: I also like: make_directories_as_neccessary() on_demand is shorter than as_neccessary Also, more specific. Who's to say when it's 'neccessary'? To me, on_demand suggest that the creation of the directories will be delayed until an attempt is made to use them. -- Rainer Deyke - [EMAIL PROTECTED] - http://eldwood.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [date_time] improvements
Hi Jeff,
Told you I'd come back for more ;)
Here are some more improvements I would consider useful:
[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).
[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())
They could definitely be made static or something.
(or the user could be given a choice - using the date_time from a
.jam-generated
dynamic link library, or directly)
Yes, to avoid multiple definitions of the said strings without having
to recreate them every time a date is formatted. Also, if a set of
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];
}
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).
BTW, my original intent was to make much more of the library 'inline
swappable'. That is, by flipping a compile switch large chunks of the
library could either be inline or in the library -- whichever was
better for the user's performance / space tradeoff. I've let this
slide for now as the way I did it was a pain for users and there are
more important issues at the moment...
Ok.
[3]
I've been recently involved in a project that used to use raw time_t's.
A conversion to/from time_t would come in very handy.
(at least one way would be enough).
I've created such a function:
#include boost/date_time/posix_time/posix_time.hpp
// converts raw time to cool ptime structure
inline boost::posix_time::ptime rawtime_to_ptime( time_t raw) {
using namespace boost::posix_time;
using namespace boost::gregorian;
tm details = *localtime( raw);
date day( details.tm_year + 1900, details.tm_mon + Jan,
details.tm_mday);
time_duration offset( details.tm_hour, details.tm_min,
details.tm_sec, 0);return ptime( day, offset); }
pretty simple and straightforward, I think.
I agree, this is on the todo list to add to the library. See
below for why it isn't already. I think I would write it like
this, however:
file://Warning -- off the top of my head untested code (but should work)!
file://in boost::posix_time namespace
posix_time from_time_t(time_t t) {
using namespace boost::gregorian;
return ptime(date(1970,1,1), seconds(t));
}
Yes, I think your is much simpler ;)
It never crossed my mind - cool indeed!
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.
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.
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.)
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
[boost] Re: Re: Re: Re: Re: GUI/GDI template library
Terje Slettebø wrote: From: Philippe A. Bouchard [EMAIL PROTECTED] WxWindows don't have any intermediate compiler but the end user syntax is not attractive for the signal / slot mechanism (macros). It's also possible to do the signal/slot without macros on wxWindows. See here (http://www.wxwindows.org/hworld2.txt) for an example. It's all done in standard C++, without any macros. I think they made it that way to make the signal / slot mechanism interact with external languages. But it won't be possible to use multiple inheritance in the widget's hierarchy this is not really C++. Maybe a convertion operatior could help ((void (Object::*)()) - (some standard typeid(...).name()) or anything else). [...] My 0,02$ CAN ($0.01 USD) Philippe ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
--- Russell Hind [EMAIL PROTECTED] wrote:
E. Gladyshev wrote:
You have
objects created inside the signals lib
(non-multi-threaded) so it
doesn't create/initialise the lock member variables.
There is then
header code which is compiled directly in your
application
Thanks for taking a look at the problem. IMO,
distributing objects between inlines and DLL functions
is not a very good idea. The classic example is:
//intended to be used as DLL.
class A
{
public:
char* m_data;
//compiled into application
inline ~A()
{
if(m_data) delete[] m_data;
}
//calls DLL
void init();
};
void A::init()
{
m_data = new char[10];
}
IMHO, boost needs to get rid of any possibility of
this to happen. Why does boost::signal() need a
DLL/LIB in the first place? Would not be just the .h
file enough?
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: Re: [boost] GUI/GDI template library
--- Brock Peabody [EMAIL PROTECTED]
wrote:
http://groups.yahoo.com/group/boost/files/
The name is boost_gui.zip. There is a ton of code,
but the interface
I think, your library has a lot of good stuff. However
it does need a major redesign to cleanly remove all
direct references to the physhical layer (MFC) in the
template code. For example I am a bit worried about
defintions like this one:
namespace controls {
struct static_control :
controls::callback_cwndCStatic {
enum { default_style = WS_CHILD | WS_VISIBLE |
SS_CENTERIMAGE };
void create(CWnd parent,
const std::string text = ,
unsigned int style = default_style,
const CRect = CRect(0,0,0,0));
void create(CWnd parent, unsigned int style);
};
}
It seems to me that it might not be very easy to clean
it up from all MFC references w/o a sustantial
architectural redesign.
As far as I remember you suggested to overwrite it
from scratch too. If we are to do it anyway, I think
we need to redesign it from scratch as well using your
library as a knowledge/experience base.
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: the boost::signal sample crashes
E. Gladyshev wrote: Thanks for taking a look at the problem. IMO, distributing objects between inlines and DLL functions is not a very good idea. The classic example is: It can cause problems but if you are aware of it, then you can work around it quite easily. Part of the reason in speed. Some code can be inlined to optimise things for release builds. This is a good thing IMHO. Also, some libraries are wholly or partly template based so they can't go completely in a .lib yet. I'm sure there are other reasons that other people could fill you in on. IMHO, boost needs to get rid of any possibility of this to happen. Why does boost::signal() need a DLL/LIB in the first place? Would not be just the .h file enough? It could be put in a .h, but there is a lot of code in the library and it makes sense to have it built as a .lib. Perhaps another solution would be for all the inlined code in the header to be moved into the .lib at a loss of performance. I would just prefer a solution mentioned above where the libs built by boost have different name endings for debug/release multi/single threaded. But this isn't the whole problem. The other problem is compiler options and such for the structures in the header files. For example, data alignment. boost builds with alignment of 8 for Borland by default. If your app uses another alignment option (we used to use 4 for historic reasons) then when you accessed objects returned from the dll, you would access the wrong offsets for the members because the boost headers don't force options such as this around there structures. I have created a duplicate set of headers for the parts of boost that I use that force compiler options using a #pragma push, then include the boost header, then pop those compiler options. I only ever include my wrappers so that I don't get caught by this and am free to use whatever compiler options I wish for the rest of the project. Russell ___ 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
Hi,
I tried compiling the boost_gui code, but got compile-time errors.
Do I need a Service pack?
Example:
desired_size_operations.cpp
d:\john\programming\boost\boost_gui\boost_gui\floatroutines.h(8) : error
C2065: 'pow' : undeclared identifier
d:\john\programming\boost\boost_gui\boost_gui\floatroutines.inl(10) : error
C2065: 'floor' : undeclared identifier
d:\john\programming\boost\boost_gui\boost_gui\floatroutines.inl(16) : error
C2065: 'fabs' : undeclared identifier
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : error C2893: Failed to specialize function template 'struct
layout::desired_size __cdecl `anonymous-namespace'::operate_on_sizes(const
struct layout::desired_size ,cons
t struct layout::desired_size ,const Fun )'
With the following template arguments:
'struct `anonymous-namespace'::max_'
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : error C2146: syntax error : missing ';' before identifier
'operate_on_sizes'
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : error C2143: syntax error : missing ')' before 'const'
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : error C2780: 'struct layout::desired_size __cdecl
`anonymous-namespace'::operate_on_sizes(const struct layout::desired_size
,const struct layout::desired_size ,const F
un )' : expects 3 arguments - 0 provided
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : see declaration of 'operate_on_sizes'
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : error C2059: syntax error : ')'
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : error C2893: Failed to specialize function template 'struct
layout::desired_size __cdecl `anonymous-namespace'::operate_on_sizes(const
struct layout::desired_size ,cons
t struct layout::desired_size ,const Fun )'
With the following template arguments:
'struct bplib::pluses'
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : error C2146: syntax error : missing ';' before identifier
'operate_on_sizes'
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : error C2143: syntax error : missing ')' before 'const'
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : error C2780: 'struct layout::desired_size __cdecl
`anonymous-namespace'::operate_on_sizes(const struct layout::desired_size
,const struct layout::desired_size ,const F
un )' : expects 3 arguments - 0 provided
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : see declaration of 'operate_on_sizes'
D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cpp(29
) : error C2059: syntax error : ')'
Error executing cl.exe.
desired_size_operations.obj - 13 error(s), 0 warning(s)
Just one thing:
Drawing.cpp:
you have #include /source/c++/bplib/WindowsUtils.h
which is not present.
Best,
John
- Original Message -
From: Philippe A. Bouchard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, August 03, 2003 9:33 PM
Subject: [boost] Re: Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library
brock wrote:
[...]
What do you mean by official macros? The only macros in my code
are in
the implementation, you shouldn't see any in user code.
Sorry I guess I have misinterpreted BEGIN_MESSAGE_MAP() in
boost_gui_test.cpp.
Oh, that is auto generated MSVC 6 stuff.
[...]
If you're talking about message notifications, I use something like:
struct window {
void set_on_change(boost::funtion0void);
void set_on_character_typed(boost::function1void,char);
};
Is it possible to associate widget instances with functions?
Like with boost::bind?
button b;
edit e;
button.set_on_pushed(boost::bind(edit::disable_window, e));
(This is not how my library class names looks now, but how they will when
rewritten)
Brock
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: the boost::signal sample crashes
--- Russell Hind [EMAIL PROTECTED] wrote: E. Gladyshev wrote: It can cause problems but if you are aware of it, then you can work around it quite easily. IMO, I should be able to just use the library w/o this kind of workarounds. It is hard to debug these .lib/.h conflict issues. IMHO, boost needs to get rid of any possibility of this to happen. Why does boost::signal() need a DLL/LIB in the first place? Would not be just the .h file enough? It could be put in a .h, but there is a lot of code in the library and it makes sense to have it built as a .lib. I think that it doesn't make sense if we have all these problems that you are talking about below. If the user wants to speed the compile-time up, he/she can always create a simple wrapper around the standard signal.h. Perhaps another solution would be for all the inlined code in the header to be moved into the .lib at a loss of performance. I would never do it. I would just prefer a solution mentioned above where the libs built by boost have different name endings for debug/release multi/single threaded. But this isn't the whole problem. The other problem is compiler options and such for the structures in the header files. For example, data alignment. boost builds with alignment of 8 for Borland by default. If your app uses another alignment option (we used to use 4 for historic reasons) then when you accessed objects returned from the dll, you would access the wrong offsets for the members because the boost headers don't force options such as this around there structures. I have created a duplicate set of headers for the parts of boost that I use that force compiler options using a #pragma push, then include the boost header, then pop those compiler options. I only ever include my wrappers so that I don't get caught by this and am free to use whatever compiler options I wish for the rest of the project. Forgive me but it seems insane to me that we make boost users to go through all this hell with .lib files. I am really worried about the road the boost comunity has choosen just to reduce the compile time. Please let the user to reduce the compile time (making his custom wrappers) any way he/she likes it. I want to be able to just include a .h file w/o having to verify that my program won't break from time to time because of some .lib/.h conflicts enforced on me by boost developers. On the side note: this boost road already lead to the fact that the boost::thread library is not up-to-date anymore. Win32 supports two threading models that can be used in one application at the same time. boost::thread doesn't allow it. I think if we continue down this road, boost will be in a big trouble becoming a true industry standard (at least for some of its components). IMHO boost::signals should be in a .h file completely. I can always reduce the compile time myself if I need to. 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: Re: Filesystem: create_directories
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Martin Wille Sent: Monday, August 04, 2003 5:10 AM To: Boost mailing list Subject: Re: [boost] RE: Re: Filesystem: create_directories May I bicycleshedingly suggest make_directory_hierarchy() or make_hierarchy() ? On X-Windows systems there is a small program called mkdirhier. So, the names I suggested resemble it a bit. Save that anyone not truly a hierophant of the C++ temple would have trouble spelling it g. Not bad, but it's semantically similar to make_directories, in that it suggests that it might be creating multiple directories at the same level. Further, it seems to imply that it's always creating an entire tree of directories, and not necessarily just a single path of descent. Unless that's just a connotation I've managed to attach to the word. Bicycleshedingly? M'thinks t'will require ponderance. Anon. Reid Sweatman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: smart_assert - update; SMART_ENFORCE works
John Torjo wrote:
Hi Michael,
1) How is this going?
Unfortunately, I've been EXTREMELY busy these days :(
It's almost done - I've worked on making a small footprint of
SMART_ASSERT (when using SMART_ASSERT, the generated code should be
as small as possible)
Note: try the latest version - www.torjo.com/smart_assert.zip
I want to write the full documentation, and then post it to boost
sandbox as well.
2) I notice that when the Debug button in the Win32 assertion
dialog is pressed, it breaks into the debugger deep inside
smart_assert code. Any chance of moving the debug-break out into the
SMART_ASSERT macro? I
suppose
this would be done by making the handler return values that specify
standard actions (do nothing, break into debugger, abort, etc.).
Hmm. I think it can be done. I'll try these days - hopefully should
do it until Fri.
3) I've always wanted an assertion that would evaluate the condition
and fire when the enclosing block exits instead of immediately
(i.e., a postcondition). I realize this would have to work in an
entirely different way from a standard assertion, in that it would
require the condition to
be
a boost::bind type function or boost::lambda type expression that
could be evaluated later. Something like a ScopeGuard that evaluates
to an assertion, in fact. Do you have any interest in pursuing this?
I'd be glad to help,
if
I can.
I'm not quite sure of the usefullness of this.
Please go into more details.
A postcondition such as I'm suggesting would perform an assertion when a
function (or the enclosing block) exits instead of on the line where the
assertion was defined. Obviously, if a function only has one exit path, it
would be simple just to put assertions at the end of the function, but if a
function has multiple exit points, this would be inadequate.
An example of what I mean is something like this (where SMART_ASSERT_POST is
the new postcondition assertion that I'm suggesting):
class SomeClass(void)
{
public:
void SomeFunction(void)
{
//Precondition: check class invariants on function entry
SMART_ASSERT(CheckClassInvariants());
//Postcondition: check class invariants on function exit
SMART_ASSERT_POST(CheckClassInvariants());
//Function body here
}
private:
bool CheckClassInvariants(void)
{
//Return true if class invariants are met
}
};
Another example would be something like this:
int SomeFunction(int arg)
{
//Precondition: check argument on function entry
SMART_ASSERT(arg 0 arg 10);
int result = 0;
//Postcondition: check result on function exit
SMART_ASSERT_POST(ref(result) = 0);
//Function body here
return result;
}
As far as how it would be implementated, as I suggested before, I assume the
post condition would create an object whose destructor asserts the condition
when the block the it is defined in exits.
Mike
Best,
John
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost and DLL's
I was wondering, has the boost comunitiy had a discussion about exporting/importing C++ classes from a DLL? 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: Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library
John, What compiler are you using? The example only works on VC 6. I added that limitation to the description. I'll have a version ready for VC 7.1 soon. I did fix the include file problem. The file was on my box :) The main code of interest is just the snippet in boost_test_gui/dialog.cpp. The implementation itself is going to get a serious overhaul, but I wanted to see what everyone thought of the direction I was heading with the interface. Thanks a lot for checking this out! Brock -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Torjo Sent: Monday, August 04, 2003 11:36 AM To: Boost mailing list Subject: Re: [boost] Re: Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library Hi, I tried compiling the boost_gui code, but got compile-time errors. Do I need a Service pack? Example: desired_size_operations.cpp d:\john\programming\boost\boost_gui\boost_gui\floatroutines.h(8) : error C2065: 'pow' : undeclared identifier d:\john\programming\boost\boost_gui\boost_gui\floatroutines.inl(10) : error C2065: 'floor' : undeclared identifier d:\john\programming\boost\boost_gui\boost_gui\floatroutines.inl(16) : error C2065: 'fabs' : undeclared identifier D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : error C2893: Failed to specialize function template 'struct layout::desired_size __cdecl `anonymous-namespace'::operate_on_sizes(const struct layout::desired_size ,cons t struct layout::desired_size ,const Fun )' With the following template arguments: 'struct `anonymous-namespace'::max_' D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : error C2146: syntax error : missing ';' before identifier 'operate_on_sizes' D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : error C2143: syntax error : missing ')' before 'const' D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : error C2780: 'struct layout::desired_size __cdecl `anonymous-namespace'::operate_on_sizes(const struct layout::desired_size ,const struct layout::desired_size ,const F un )' : expects 3 arguments - 0 provided D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : see declaration of 'operate_on_sizes' D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : error C2059: syntax error : ')' D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : error C2893: Failed to specialize function template 'struct layout::desired_size __cdecl `anonymous-namespace'::operate_on_sizes(const struct layout::desired_size ,cons t struct layout::desired_size ,const Fun )' With the following template arguments: 'struct bplib::pluses' D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : error C2146: syntax error : missing ';' before identifier 'operate_on_sizes' D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : error C2143: syntax error : missing ')' before 'const' D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : error C2780: 'struct layout::desired_size __cdecl `anonymous-namespace'::operate_on_sizes(const struct layout::desired_size ,const struct layout::desired_size ,const F un )' : expects 3 arguments - 0 provided D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : see declaration of 'operate_on_sizes' D:\john\programming\boost\boost_gui\boost_gui\desired_size_operations.cp p( 29 ) : error C2059: syntax error : ')' Error executing cl.exe. desired_size_operations.obj - 13 error(s), 0 warning(s) Just one thing: Drawing.cpp: you have #include /source/c++/bplib/WindowsUtils.h which is not present. Best, John [...] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Re: [boost] GUI/GDI template library
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of E. Gladyshev
Sent: Monday, August 04, 2003 11:29 AM
To: Boost mailing list
Subject: RE: Re: [boost] GUI/GDI template library
--- Brock Peabody [EMAIL PROTECTED]
wrote:
http://groups.yahoo.com/group/boost/files/
The name is boost_gui.zip. There is a ton of code,
but the interface
I think, your library has a lot of good stuff. However
it does need a major redesign to cleanly remove all
direct references to the physhical layer (MFC) in the
template code. For example I am a bit worried about
defintions like this one:
namespace controls {
struct static_control :
controls::callback_cwndCStatic {
enum { default_style = WS_CHILD | WS_VISIBLE |
SS_CENTERIMAGE };
void create(CWnd parent,
const std::string text = ,
unsigned int style =
default_style,
const CRect = CRect(0,0,0,0));
void create(CWnd parent, unsigned int style);
};
}
It seems to me that it might not be very easy to clean
it up from all MFC references w/o a sustantial
architectural redesign.
The implementation definitely needs to be redesigned from the ground up.
The nice things is that even with my poor implementation, at the highest
level (dialog.h and dialog.cpp) all of the MFC references are already
hidden.
As far as I remember you suggested to overwrite it
from scratch too. If we are to do it anyway, I think
we need to redesign it from scratch as well using your
library as a knowledge/experience base.
That sounds right to me. The sample boost_gui code was just a proof on
concept, it will be much prettier if we start from scratch.
The biggest thing I am lacking is any experience doing GUI development
outside of MFC. If we can keep our interface simple it might be easiest
to just make the library an interface specification which is implemented
totally independently for each target platform. Does that seem
reasonable?
Brock
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Re: Re: [boost] GUI/GDI template library
--- Brock Peabody [EMAIL PROTECTED] wrote: If we can keep our interface simple it might be easiest to just make the library an interface specification which is implemented totally independently for each target platform. Does that seem reasonable? I agree. I think we can have 2 layers. One layer is a low-level single interface specification that will be implemented independently for each target platform. This low-level interface can be designed in terms of pImpl or ImplTraits idioms (the design would have to be different depending on the idiom we choose). I favor the ImplTraits idiom. The higher layer it the actual gui::boost library that would be implement as a modern C++ library and reside in .h files completely. The boost::gui would always call the specified low-level interface to do the low-level stuff (like create_window, draw_text, etc.). Is it what you mean? 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: Re: Re: [boost] GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of E. Gladyshev Sent: Monday, August 04, 2003 1:03 PM To: Boost mailing list Subject: RE: Re: Re: [boost] GUI/GDI template library --- Brock Peabody [EMAIL PROTECTED] wrote: If we can keep our interface simple it might be easiest to just make the library an interface specification which is implemented totally independently for each target platform. Does that seem reasonable? I agree. I think we can have 2 layers. One layer is a low-level single interface specification that will be implemented independently for each target platform. This low-level interface can be designed in terms of pImpl or ImplTraits idioms (the design would have to be different depending on the idiom we choose). I favor the ImplTraits idiom. The higher layer it the actual gui::boost library that would be implement as a modern C++ library and reside in .h files completely. The boost::gui would always call the specified low-level interface to do the low-level stuff (like create_window, draw_text, etc.). Is it what you mean? I think :) What I am trying to say is that the library would be completely reimplemented for each platform, except for those parts of the library which are implemented entirely in terms of the library's public interface. This saves us from having to find a representational scheme that will fit on top of an unknown number of platforms which might not have anything in common. Is that what you thought I meant? Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Re: Re: [boost] GUI/GDI template library
--- Brock Peabody [EMAIL PROTECTED] wrote: This saves us from having to find a representational scheme that will fit on top of an unknown number of platforms which might not have anything in common. I think this is where we disagree. I prefer to find a single low-level represntation scheme that could be implemented on top of an unknown number of platforms. The representation could be even expressed in terms of a C API, it doesn't matter. The modern C++ layer will use the single representation, and not worry about a specific platform at all. The C++ layer will reside in .h files completely. If we do something like this, then our library will support Rainer Deyke's requirements (see his post in this thread). 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] Boost 1.30.1 released
Version 1.30.1 is a bugfix-only update. See http://www.boost.org for details of what has been fixed. Version 1.31.0, due out shortly, will contain some changes to library interfaces (notably the iterator adaptors library) which may break client code. Version 1.30.1 was released in order to deliver non-interface-breaking improvements to existing users of Boost 1.30.0. Note for Boost.Python users: this release is not compatible with Python 2.3. For information on how to obtain a Python 2.3-compatible version of Boost.Python, please see http://www.boost.org/libs/python. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ 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 E. Gladyshev Sent: Monday, August 04, 2003 2:33 PM To: Boost mailing list Subject: RE: Re: Re: [boost] GUI/GDI template library --- Brock Peabody [EMAIL PROTECTED] wrote: This saves us from having to find a representational scheme that will fit on top of an unknown number of platforms which might not have anything in common. I think this is where we disagree. I prefer to find a single low-level represntation scheme that could be implemented on top of an unknown number of platforms. The representation could be even expressed in terms of a C API, it doesn't matter. The modern C++ layer will use the single representation, and not worry about a specific platform at all. The C++ layer will reside in .h files completely. That might be a better way to go. I just don't know enough about GUI systems other than MFC to be able to envision what a scheme like that would look like or if it would succeed. You might save a lot of work coming up with a single low-level representation scheme, but it might become too complex. It's probably worth a try. In the worst case, I feel confident that we can make my brute-force approach work. If we do something like this, then our library will support Rainer Deyke's requirements (see his post in this thread). I'll see if I can find it. Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposed smart_handle library
John Madsen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] - A policy based design to whereas the policy extends the classes interface. - Stronger typing (the types are different based on typename, not on traits). The traits approach seems fundamentally flawed as two separate types could share the same traits. I think that the traits system makes the typing stronger. It guarantees distinct types even in the face of handles that are otherwise indistinguishable. I looked at your design, but I think I can handle what you're trying to do through traits class inheritance. I don't see any use to extending the interface through a policy class. Let me know if I've missed something. I might not have followed the discussion to deeply, but it does look to me like John is entirely right. Traits can fundamentally do one customization per type. That's not going to be enough if you have the same type representing multiple handles, as is the case with many C APIs. For example, sockets and file descriptors might be both integers. Or, a variety of handles can come in the disguise of a void*. In Windows, if you #define STRICT, they use a trick to give different flavors of HANDLEs different C++ types (nothing fancy, it's all casts). Still, they forgot to do that for a couple of handle types (which were that? HBITMAP? HINTERNET? I can only say HGEEITSBEENALONGTIME). So then after a team I was working with built a very nice and sweet smart handle class using traits, we simply couldn't use it because of this particular issue. With a trait, you can only establish one way of dealing with int and one way of dealing with void*. With a policy, you can define at the exact granularity that you want how exactly your handle maps to a type and how it is manipulated - and that policy will be part of the object type. I'm not sure that the inheritance-based approach is superior or not, it sure would be worth some discussion. For more reference on traits, here are two articles that might be of relevance: http://www.moderncppdesign.com/publications/traits.html http://www.moderncppdesign.com/publications/traits_on_steroids.html Andrei ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.30.1 released
Shouldn't the documentation for function and signals be added when your're making an official release also? What's the status regarding the new doc-system btw? (too lazy/tired to dig through the archives right now ;-) // Fredrik David Abrahams wrote: Version 1.30.1 is a bugfix-only update. See http://www.boost.org for details of what has been fixed. Version 1.31.0, due out shortly, will contain some changes to library interfaces (notably the iterator adaptors library) which may break client code. Version 1.30.1 was released in order to deliver non-interface-breaking improvements to existing users of Boost 1.30.0. Note for Boost.Python users: this release is not compatible with Python 2.3. For information on how to obtain a Python 2.3-compatible version of Boost.Python, please see http://www.boost.org/libs/python. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ReadableIteratorConcept and Borland BCB6
The concept checker ReadableIteratorConcept is causing several failures for the new iterator adaptors under BCB6. I have two possible patches, either of which solve the problem. # if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) typedef BOOST_DEDUCED_TYPENAME boost::detail::iterator_traitsIterator::value_type value_type; typedef BOOST_DEDUCED_TYPENAME boost::detail::iterator_traitsIterator::reference reference; typedef BOOST_DEDUCED_TYPENAME boost::access_categoryIterator::type access_category; # else typedef BOOST_DEDUCED_TYPENAME ::boost::detail::iterator_traitsIterator::value_type value_type; typedef BOOST_DEDUCED_TYPENAME ::boost::detail::iterator_traitsIterator::reference reference; typedef BOOST_DEDUCED_TYPENAME ::boost::access_categoryIterator::type access_category; # endif In this case, simply removing the global qualifier 'fixes' the parser. Alternatively: # if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) typedef ::boost::detail::iterator_traitsIterator traits_type; typedef traits_type::value_type value_type; typedef traits_type::reference reference; typedef traits_type::type access_category; # else typedef BOOST_DEDUCED_TYPENAME ::boost::detail::iterator_traitsIterator::value_type value_type; typedef BOOST_DEDUCED_TYPENAME ::boost::detail::iterator_traitsIterator::reference reference; typedef BOOST_DEDUCED_TYPENAME ::boost::access_categoryIterator::type access_category; # endif By introducing an intermediate typedef, the global-namespace qualifier is preserved. I am not clear why there are no dependent typenames in this second version, or if that is another BCB bug. Likewise, I'm not clear which form of patch is to be preferred, so present both g [I suspect the same patch will be required for the Kylix compiler, 0x570, as well, but don't have that available for testing] -- AlisdairM Team Thai Kingdom ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost and DLL's
E. Gladyshev wrote: I was wondering, has the boost comunitiy had a discussion about exporting/importing C++ classes from a DLL? Exporting/importing C++ classes is completely implementation dependent, due mainly to name mangling, and requires a DLL for a particular platform/compiler/release to be built. I know regex++ does this for it's C++ classes, and I imagine all other implementors who export/import C++ classes in their libraries also enable their code to be built for the particular implementations they support using make files or bjam. What discussion about exporting/importing from a shared library do you want to have ? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem: create_directories
On Mon, 04 Aug 2003 10:51:07 +0400 Vladimir Prus [EMAIL PROTECTED] wrote: [snip] Another option might be: create_directory_and_parents That name is longer than create_directories although it better describes the function. So, to summarize, I've no problem with the current name that I've introduced. Of other suggestions create_directory_and_parents looks best to me. ensure_directory_exists does not imply any operational semantic(i.e. the name does not say that the directory will be created. One might expect exception to be thrown if dir does not exist). demand_directory is good. One problem is that demand still does not communicate to me that something will be created. I suggested create_directory_and_parents because the current create_directories has exactly the semantics of calling create_directory incrementally on each parent directory path, then on the directory path itself. It could be called create_parents_and_directory, but it is useful to emphasize the relationship with create_directory since both functions have the same post-condition and many existing libraries provide this functionality based on a parameter to a single create_directory function. On a separate note, the current create_directories documentation uses a non-existent function is_parent in the precondition specification. Perhaps this function should be defined in convenience.hpp also. A name that explicitly conveys the order of the arguments is: is_parent_and_child Grammatically, are_parent_and_child is correct, but it would be inconsistent with the type_traits library and does not sound better. -- Jeremy B. Maitin-Shepard [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: plans for a bugfix release ?
David Abrahams wrote: It looks like you need to build your vc6 stlport debug library also; that would account for the failure in the testing library tests. Done. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Patch to emacs cc-mode for template syntax and indentation
If anyone's interested, the enclosed patch against the current CC-mode
CVS makes Emacs CC-mode very well-behaved w.r.t. identifying template
syntax. Along with various hacks in my .emacs file to customize how
it's indented, I'm able to do this automatically:
template
class T
, class U
, class R
, class U
, template
class F
, class H
, class G
::type
, class U
= std::auto_ptr
std::vectorint,
allocator
int
,
, groot
struct foo
{
typedef typename foo
bar
::template baz
mumble, bag, floot
::type boo;
};
The preceding commas are my preference, but it also handles trailing
commas nicely. If anyone's interested in culling the relevant hacks
from my .emacs file, you can find it at
http://www.boost-consulting.com/.emacs
Enjoy,
--- cc-engine.el.~5.428.~ 2003-07-31 16:13:21.0 -0400
+++ cc-engine.el 2003-08-04 22:26:47.0 -0400
@@ -5934,7 +5934,15 @@
(or (memq (char-after) '(?, ?=))
(and (c-major-mode-is 'c++-mode)
(zerop (c-backward-token-2 1 nil lim))
- (eq (char-after) ?)
+ (or
+ (eq (char-after) ?)
+ ;; handle template template arguments
+ (and (condition-case nil
+ (backward-up-list)
+ (error nil))
+ (eq (char-after) ?)
+ ))
+
(goto-char indent-point)
(setq placeholder
(c-beginning-of-member-init-list lim))
@@ -5984,8 +5992,11 @@
(eq (char-after placeholder) ?))
;; we can probably indent it just like an arglist-cont
(goto-char placeholder)
- (c-beginning-of-statement-1 lim t)
- (c-add-syntax 'template-args-cont (c-point 'boi)))
+ (while (save-excursion
+ (and (zerop (c-backward-token-2 1 t lim))
+(looking-at [a-zA-Z_]\\|::)))
+(c-backward-token-2 1 t lim))
+ (c-add-syntax 'template-args-cont (point)))
;; CASE 5D.4: perhaps a multiple inheritance line?
((and (c-major-mode-is 'c++-mode)
(save-excursion
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Infinite number of parameters?
Hello,
Often some function and functors requires to be overloaded N times to
handle undefinite number of arguments, depending on some default setting.
Maybe the following could be used; it overloads operator , () and gradually
creates a typelist. This typelist is used to replace the undefinite number
of arguments:
#include iostream
using namespace std;
namespace infinite
{
template typename T = void, typename U = void
struct typelist : U
{
typedef T type;
T value;
typelist(T const a, U const b) : value(a), U(b) {}
};
template
struct typelistvoid, void
{
typedef void type;
};
template typename T
struct typelistT, void
{
typedef T type;
T value;
typelist(T const a) : value(a) {}
};
typelist const begin = typelist();
}
template typename V
infinite::typelistV, void operator , (infinite::typelist const , V
const v)
{
return infinite::typelistV, void(v);
}
template typename T, typename U, typename V
infinite::typelist V, infinite::typelistT, U operator ,
(infinite::typelistT, U const t, V const v)
{
return infinite::typelist V, infinite::typelistT, U (v,
infinite::typelistT, U(t));
}
// Usage example:
template typename T, typename U
void foo(infinite::typelistT, U const i)
{
cout __PRETTY_FUNCTION__ endl;
}
int main()
{
foo((infinite::begin, true, (char *) adasd, 12367, 127.2));
}
My 0,02$
Philippe
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Wrong version.hpp in Boost 1.30.1 download
Alisdair Meredith [EMAIL PROTECTED] writes: version.hpp still claims to be version 1.30.0 Oh well. I guess there are some details missing from the release manager's responsibilities on the release procedure page. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
E. Gladyshev wrote: IMO, I should be able to just use the library w/o this kind of workarounds. It is hard to debug these .lib/.h conflict issues. Why build the .lib at all? Why not just add the signals source file to your project? I did this for a while with thread and signals. I've since now got my own build system working with name .libs and generated headers to make sure project options are the same for the .lib and where I include the headers. I've made it easier by only using the multi-threaded libraries in boost and therefore never create the single threaded libraries. Also, boost releases don't come out that often that it is a PITA to keep up to date, although I am just about to go through it with 1.30.1 Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
