[boost] Re: boost/detail/iterator.hpp update
- Original Message - From: David Abrahams [EMAIL PROTECTED] Newsgroups: gmane.comp.lib.boost.devel Sent: Thursday, August 28, 2003 9:05 PM Subject: Re: boost/detail/iterator.hpp update ... Anyone got a brilliant way to cause vc7 to print the error message? #pragma message ( some text ) shown during compilation, is good enough? /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable and memcpy_moveable type traits
Edward Diener [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Extremely dangerous and error prone. I can't even imagine a non-POD type
where flagging it for memcpy_copyable and memcpy_moveable can be right.
Can
you give an example ?
It is error prone but many other constructs are too.
Example of moveable object:
struct string_buffer {
unsigned size;
char* data; // allocated buffer
};
The user could then write:
template memcpy_moveablestring_buffer {
static bool moveable = true; // or defining some type or so
}
and container can detect moveability and use memcpy(). If type is not
flagged, memcpy() won't be used.
Usually strings, smart pointers, vectors, pimpls are memcpy moveable. Pimpl
with back pointer isn't.
(The memcpy_copyable is probably not that good idea and not much useful.)
/Pavel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: memcpy_copyable and memcpy_moveable type traits
John Maddock [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] He needs to take a look at the has_trivial_* traits: has_trivial_assign is roughly equivalent to memcpy_copyable I guess there is no equivalent to memcpy_moveable: but it looks rather dangerous, It looks dangerous but the memcpy_moveable is intended for containers designed to deal with this danger. (The problem can be a bit alleviated (in debug mode) by overwriting old storage by 0xCC bit pattern, making invalid use easier to spot.) Combination of is_POD and has_trivial_* covers many cases for memcpy_moveable but not all of them, IMO. Also the has_trivial_* are not yet supported by compilers. My intention was to give user chance to flag moveable types manually. Those causing performance bottleneck could be examined and flagged without need to change container/algorithm/architecture. Performance optimization is often targeted after system gets built and being able to improve it without major design changes looks useful. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable and memcpy_moveable type traits
Edward Diener [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] ... But even for a POD type such as this, copying would lead to errors if the char * data were dynamically allocated since a double delete would probably be done. Containers aware of memcpy_moveable can detect this flag and avoid double delete problems. Other code would use constructors/destructors as usual. Intention is to give user chance to flag performance sensitive types. Commonly used containers/algorithms (typically vector) would be able to take advantage of this. This soulution would work with current compilers and could be useful for performance optimisation phase of a project. Code using memcpy_moveable can play some tricks to help troubleshooting (like filling old storage with debug bit pattern). memcpy_moveable cannot be deduced by compiler automatically, IMO - that's real disadvantage. Also memcpy_moveable is intended for situations where large arrays of objects are moved, like vector reallocations. It is something different and likely orthogonal to Mojo or standard move proposals. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable and memcpy_moveable type traits
Edward Diener [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] ... But even for a POD type such as this, copying would lead to errors if the char * data were dynamically allocated since a double delete would probably be done. Containers aware of memcpy_moveable can detect this flag and avoid double delete problems. Other code would use constructors/destructors as usual. Intention is to give user chance to flag performance sensitive types. Commonly used containers/algorithms (typically vector) would be able to take advantage of this. This soulution would work with current compilers and could be useful for performance optimisation phase of a project. Code using memcpy_moveable can play some tricks to help troubleshooting (like filling old storage with debug bit pattern). memcpy_moveable cannot be deduced by compiler automatically, IMO - that's real disadvantage. Also memcpy_moveable is intended for situations where large arrays of objects are moved, like vector reallocations. It is something different and likely orthogonal to Mojo or standard move proposals. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable and memcpy_moveable type traits
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Pavel Vozenilek [EMAIL PROTECTED] writes: Type traits library may be extended with: - memcpy_copyable and - memcpy_moveable see boost::is_POD. memcpy_moveable may be useful for non-POD types, like some pimpls. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable and memcpy_moveable type traits
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] ... I don't believe you can use memcpy to move any non-POD types portably, i.e. without special knowledge of the compiler. Thats my point - you may flag some types as safely moveable and then use this knowledge in algorithms. User has the responsibility to do the decision. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: filesystem feature request
From: David Abrahams [EMAIL PROTECTED] I need the ability to do interprocess synchronization through file locking, c.f. Java.File.createNewFile and Java.File.deleteOnExit: ... On Posix, the first one would be done with open(..., O_CREAT | O_EXCL) and the second, I suppose, would be done with a terminate handler. The second feature (delete-on-exit) is supported by OS: - on Win32 using FILE_FLAG_DELETE_ON_CLOSE flag in CreateFile() - on Unix using unlink() standard system call /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: GUI/GDI template library
Terje Slettebø [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Make no mistake - this is a lot of work, too. However, it may be much less work than creating one from scratch. What do we want - vaporware of a Boost GUI library coming real soon now, perhaps not appearing for many years, if ever, due to the amount of work, or adapting an existing solution and being able to use it here and now, with a boostified version to come? Every project needs to start and can be labeled 'vaporware' at this moment. My goal was to include existing libraries in the discussion, and that has been met. Exhaustive list of toolkits is on: http://www.free-soft.org/guitool/ Here is interesting review of five GUI toolkits, including wxWindows: http://freshmeat.net/articles/view/928/ /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer update
Hello Jano,
Jan Gaspar [EMAIL PROTECTED] wrote
The updated circular_buffer implementation can be found
at the common place
http://groups.yahoo.com/group/boost/files/circular_buffer.zip
I looked briefly over the code:
1. IMO the macro based exception handling isn't needed, it is better
to use RAII, like:
void set_capacity(size_type new_capacity) {
if (new_capacity == capacity()) return;
pointer buff = allocate(new_capacity);
size_type new_size = new_capacity size() ? new_capacity : size();
BOOST_CB_TRY
std::uninitialized_copy(end() - new_size, end(), buff);
BOOST_CB_UNWIND(deallocate(buff, new_capacity))
destroy();
m_size = new_size;
m_buff = m_first = buff;
m_end = m_buff + new_capacity;
m_last = full() ? m_buff : m_buff + size();
}
can be replaced by:
void set_capacity(size_type new_capacity) {
if (new_capacity == capacity()) return;
pointer buff = allocate(new_capacity);
struct deleter_t {
pointer data;
size_type capacity;
deleter_t(pointer p, size_type s) : data(p), capacity(s) {}
~deleter_t() { deallocate(data, capacity); }
};
deleter_t guard(buff, new_capacity);
size_type new_size = new_capacity size() ? new_capacity : size();
std::uninitialized_copy(end() - new_size, end(), buff);
destroy();
m_size = new_size;
m_buff = m_first = buff;
m_end = m_buff + new_capacity;
m_last = full() ? m_buff : m_buff + size();
guard.data = 0;
}
RAII may replace all the macros in the code. Source code size, runtime speed
and executable size should not get worse.
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).
3. cb_iterator::operator +():
instead of
cb_iterator operator + (difference_type n) const {
cb_iterator tmp = *this;
return tmp += n;
}
you may use
cb_iterator operator + (difference_type n) const {
return cb_iterator (*this) += n;
}
which looks the same but may use unnamed return value optimisation (URVO).
The original code would require compiler to support named RVO to optimize
copy away.
Some other code may or may not be changed in this way, I didn't look futher
for this.
4. circular_buffer::check_position(): raw throw is used, it may be
conditionally
disabled if BOOST_NO_EXCEPTION or function from
boost/throw_exception.hpp may be used.
5. Similarly in circular_buffer::allocate(). (I wonder where
std::length_error
does come from?)
Regarding unused space overhead
I share the Nigel's opinion. The circular_buffer was designed with fixed
allocated memory. It will just complicate things. For example statements
regarding iterator invalidation won't be true any more. On contrary it
is quite easy to adapt std::list, std::slist or std::deque to achieve
this goal. You can just push_back() elements at the end of e.g.
std:list. In case the size of the container exceeds the desired capacity
you just remove the element from the front.
Maybe in this case circular_buffer can reuse vector to keep internal
data
(the source code would be smaller + potential for smaller executable).
The circular_buffer could keep start+end pointers and delegate quite a lot
of functionality to std::vector.
(Since there are not many Mojo enabled vectors, using Mojo likely means
own buffer handling to be of any effect.)
/Pavel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer and unused space overhead
In relation to the previous discussion I thought an alternative container may be a circular_deque that could have the kind of flexibility with resizing that also sounds desirable. Does a circular_deque sound like the right solution to your particular application, rather than a vector-like resizing contiguous circular buffer? I think these solutions are (mostly) equivalent. From practical point of view, adding auto-resize to circular_buffer is easier than creating new container. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer and unused space overhead
Nigel Stewart [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Wouldn't it be better to use smaller internal memory block initially and resize it only when demand goes up? That's a good point, but it certainly complicates both the interface and the semantics of the container. Could this style of circular buffer be an adaptor, or perhaps a policy adaptor? IMO the resize/shrink cannot be added via adaptor (unless it is very complex one). It may be possible to design circular_buffer as adaptor over [vector | deque | list | slist | shrinkable vector | ...]. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer and unused space overhead
Nigel Stewart [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] IMO the resize/shrink cannot be added via adaptor (unless it is very complex one). An adaptor that wraps push() and insert() would be considerd too heavy-weight? I think it is pretty heavyweight, but maybe there's some misunderstanding. The point of NOT adapting a circular_buffer over vector, deque or list is to preserve the fixed time push and pop. It is also useful to automatically overwrite items at the opposite end of the container, to obscure that with resizing semantics seems is undesirable. (In other words, a resizing circular buffer is not consistant with the conventional understanding of what a circular buffer is - correct me if I'm wrong.) My feeling is that with optional auto-resize feature circular_buffer may hit the sweet spot of being good enough for 80% apps. The auto-resize would kick in only when user explicitly asked for it. The fixed push/pop times and optimal memory use would be guarantied if things are going in normal, expected way. When buffer needs to get resized it is likely result of exceptional situation somewhere else and the resize overhead may be insignificant at this point. Primitive type elements may be detected and memcpy() solution used to decrease resize overhead here. In relation to the previous discussion I thought an alternative container may be a circular_deque that could have the kind of flexibility with resizing that also sounds desirable. I was thinking about circular_bitbuffer, space efficient bool container. Boolean values are quite common output of sensors. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposal: BOOST_NO_TEMPLATED_STREAMS config macroandhelpers
Gennaro Prota [EMAIL PROTECTED] wrote ... I had this problem with dynamic_bitset and, after discussing it with Phil Edwards (who is one of the maintainers of libstdc++), I came up with the macro that is currently in http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost-sandbox/boost-sandbox/b oost/dynamic_bitset.hpp?rev=1.28content-type=text/vnd.viewcvs-markup Just note: the macros (BOOST_OLD_IOSTREAMS and BOOST_BITSET_CHAR) should get undefined at the end of the header. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] circular_buffer: minor feature request
Would it be possible to add helper function 'flatten()' into circular_buffer? After invocation, user would be sure of: buff[0] buff[1] ... buff[n] In other words, user will be able to treat circular_buffer content as continuous array of values in this moment. It is not earth shaking feature, it violates 'minimal interface' ideal but can be handy: - when legacy C function requires continuous array (like Win32 API) - when buffer is being saved to file or written to socket - special purpose adaptor could present result as (nonresizable) vector Alternatives are simple but much more CPU/memory expensive. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Formal Review Request: circular_buffer [long]
Hello Jano,
Jan Gaspar [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
3. This fragment fails:
struct Test {}
circular_bufferTest a(2);
a.push_back(Test());
a.push_back(a[0]);
I don't understand this. IMHO there will be 2 copies of Test(). Nothing
should be
destroyed in the second push_back(). I think, everything is OK.
It works OK - I did mistake. The circular_buffer can safely pushXXX its
own values.
3. cb_iterator: is the m_end value needed?
Should or shouldn't impact performance? What about setting m_it to 0 ?
Zero is even better.
/Pavel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: current_function.hpp extension
Peter Dimov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] ... There is currently no BOOST_HAS_CURRENT_FUNCTION since the idealistic goal has been to cover all widely used compilers one day, ... On the other hand, perhaps you have a use case that clearly demonstrates the need for BOOST_HAS_CURRENT_FUNCTION? SMART_ASSERT library implements BOOST_HAS_CURRENT_FUNCTION equivalent (it would be ugly to print out the default text). If not covered yet: MSVC 7 can be added (http://aspn.activestate.com/ASPN/Mail/Message/1647745) as well as HP aCC (http://aspn.activestate.com/ASPN/Mail/Message/1647818). /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [thread] bugfix + possible deadlock
Boost 1.30, Windows. libs/thread/src/once.cpp, function call_once(), CreateMutex() should be replaced with CreateMutexA() in one place. Looking into the code, I have question: if the 'called once' function throws, it leaves (under Win32) opened mutex and this can deadlock the app (if there are more functions to be 'called once'). The mutex can be closed even in this case and function flagged as executed. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_STATIC_ASSERT - a little better
John Torjo [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi all, I was just thinking (actually, I needed this, while doing some coding), that STATIC_ASSERT could get a little of the SMART_ASSERT flavour. What am I talking about? In case a STATIC_ASSERT fails, how about dumping some data that was involved in the expression? SMART_ASSERT is very useful to provide context information for hard to reproduce errors. STATIC_ASSERT error can be reproduced reliably during every compilation. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_STATIC_WARNING ?
Robert Ramey [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
H - I never imagined that something like this would be so problematic.
For now with my VC 7.0 compiler I can use the following and it gives
me almost exactly what I need. The warning message points exactly
to the place in my code where I have invoked it - just like
BOOST_STATIC_ASSERT.
I would hope something like this could be boostified so that I could use
it outside
of a function.
templatebool
struct warning
{
typedef int type;
};
template
struct warningtrue
{
typedef char type;
};
#define BOOST_STATIC_WARNING(B) \
{ \
char x = (warningB::type)0x; \
}
Played with, it works on Intel C++ 7 and MSVC 6 (two warnings issued).
It doesn't work for BC++B and needs change, e.g.:
#ifdef __BORLANDC__
templatebool
struct warning { typedef int type };
template
struct warningtrue { typedef int type; };
#define BOOST_STATIC_WARNING(B) \
{ \
warningB::type compile_time_warning_issued = 0; \
compile_time_warning_issued = compile_time_warning_issued; \
}
#endif
(It produces warning temporary used to initialize
'compile_time_warning_issued'.)
It would not work if
#pragma warn -8028
is defined.
I thought about preprocessor based solution (for compilers supporting
#pragma message):
file test.cpp:
#include boost/preprocessor.hpp
#define BOOST_STATIC_WARNING(x) \
BOOST_PP_STRINGIZE( BOOST_PP_CAT( BOOST_PP_CAT(warning,
BOOST_PP_BOOL(x) ), .hpp ) )
int main()
{
#define BOOST_STATIC_WARNING_TEXT detailed warning description
#include BOOST_STATIC_WARNING(0)
}
file warning0.hpp:
#ifndef BOOST_STATIC_WARNING_TEXT
#error You must define BOOST_STATIC_WARNING_TEXT each time before using
BOOST_STATIC_WARNING
#endif
#ifdef _MSC_VER
# pragma message (COMPILE TIME WARNING: BOOST_STATIC_WARNING_TEXT)
#endif
#undef BOOST_STATIC_WARNING_TEXT
file warning1.hpp:
#ifndef BOOST_STATIC_WARNING_TEXT
#error You must define BOOST_STATIC_WARNING_TEXT each time before using
BOOST_STATIC_WARNING
#endif
#undef BOOST_STATIC_WARNING_TEXT
Output (Intel C++ 7.0 plugged in MSVC 6 IDE, MSVC 6 as well):
Configuration: test - Win32 Debug
Compiling...
test.cpp
COMPILE TIME WARNING: detailed warning description
Linking...
link: executing 'C:\PROGRA~1\Microsoft Visual Studio\VC98\Bin\link.exe'
test.exe - 0 error(s), 1 warning(s)
It cannot be used to generate warnings for template instantiations etc.
/Pavel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in a member function pointer - functionpointerconverter? (a la boost::function)
Terje Slettebø [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[snip]
int main()
{
function_ptrint (A*, int), A::a_member fn;
// The rest the same
A a;
int r=fn(a, 3); // sets r to 9
}
Is it similar (in principle) to
http://www.code-genie.com/cpp/articles/events/events.html (long text)?
/Pavel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Better Intel-Win32 support
John Maddock [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] That will certainly work, but you shouldn't have to do that since the compiler itself defines _WCHAR_T_DEFINED. Since I made the fix earlier this afternoon I am able to compile some non-boost code correctly which had previously be failing. Just let me jump in here: you absolutely can not use _WCHAR_T_DEFINED to detect native wchar_t support: the windows headers will define this when wchar_t has been defined as a typedef (and wchar_t is not a native type). There appears to be no way to actually tell whether wchar_t is a native type or not with Intel. Is is possible to post tiny example which fails? /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [lexical_cast] performance related feature
lexical_cast constructs and destroys std::stringstream
(including dynamic memory allocation/free.)
each time a conversion is done.
Maybe specialised version of lexical_cast can be developed
which takes external, existing stringstream instance as
template parameter and reuses it.
Very rough idea:
templatetypename Target, std::stringstream ss, typename Source
Target lex_cast(Source s)
{
// clear ss
ss s;
Target t;
ss t;
return t;
}
extern std::stringstream ss;
std::stringstream ss;
...
int a = 99;
std::string s = lex_caststd::string, ss(a);
/Pavel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Better Intel-Win32 support
Beman Dawes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'll try to trace where BOOST_NO_INTRINSIC_WCHAR_T is being set. I'm not so worried about ADL, at least with VC++ 7.1. You may look on test table http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864. (Warning : when playing with options I managed to break something in compiler configuration and as result compiler decided to define macro indicating wchar_t support _always_.) /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Configuration for Intel compiler
Guillaume Melquiond [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I found a bug in the interval library. but when I corrected it, I stumbled over another problem: this bug was ironically what allowed the library to be correctly compiled with my version of the compiler (Intel compiler 7.1 for Linux). When I remove it, the library no longer works... The default configuration defines BOOST_NO_STDC_NAMESPACE for this compiler. So the library expects to find standard C math functions (the ones in cmath) in the global namespace. Unfortunately, they are where they are supposed to be: in the std namespace. So here is my question: is this macro really necessary for this compiler? Intel C++ compiler can be embedded in VC++6 IDE and in this configuration cmath puts functions in global namespace. It may be different for Intel C++ embedded into VC++7 IDE and yet different for standalone compiler. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: quantity.hpp uploaded into files section
Terje Slettebø [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] If one were to implement currency conversion, how might that be done, in general? Does one need to store the conversion rates between any two currencies (giving an N^2 size table), or might it be possible to convert any currency to some universal currency, and from that again to any other, and still getting the right values (giving a 2N table)? Currency conversion as drop-in library is IMHO not possible - currencies differ from strict units like weight and future applications may require functionality beyond current requirements. Speaking about quantity.hpp uploaded to Yahoo: it is general purpose and lightweight utility to help with conversions. It doesn't know angles or currencies or SI. I prefere to use example of convering between screen pixel and image point - something application specific what cannot be known and implemented in advance by library writer. Conversion between well known physical units is covered by SIunits (and other libraries) and quantity.hpp doesn't try to compete with these. Another examples: - You may need to know date when one currency value was converted into another (to find exchange ratio): quantity.hpp may help here to keep details separated from application code. - Conversion between angle and geometric point (contrived application specific example). - 'Dynamic' conversions: currency is converted into another using available realtime exchange rate. - 'Lossy' and 'one way' conversions: rounding up to nearest $ and (intentionally) with no conversion back. I am interested if such a utility will be found useful. It is very simple code (just few constructors + cast operators + naming convention) but the name quantity probably gives expectations of very specific functionality. I may change the name (Safer Value Conversions would be better but is wordy). /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
Trevor Taylor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] So it sounds to me like the :blat is *not* part of the extension. It sounds like the NT file name is made up of three parts: name, extension and stream. In which case I think it is fine to have functions extension() and change_extension() - they just should not report or modify the stream part. To implement them I guess I'd need to know whether the file name was an NTFS filename, and then how to reliably locate the extension part? Functin DeviceIoControl() with parameter IOCTL_DISK_GET_PARTITION_INFO can do it. It is available on NT/W2K. Does it make sense to take into account NTFS drives for Win95/98 (from www.systeminternals.com) or Linux NTFS drivers? /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: better assertion technique
John Torjo [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] assert( (i j) || (i == 0) || (j == 1) ); would change into SMART_ASSERT( (v_(i) v_(j)) || (i == 0) || (j == 1) ); The output of the above (in case the assertion fails) can look like: Assertion failed: '(v_(i) v_(j)) || (i 0) || (v_(k) == -1)' i= '3' j= '2' k= '1' This feature looks handy. Short macro like v_ is IMHO acceptable, it won't clash with definition like: int v_; I wounder if it could be somehow merged with http://www.cuj.com/experts/2104/alexandr.htm?topic=experts ? /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
Jason House [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] :blat ??? 1. I have no clue what that would mean 2. Is there any handling of :blat in any way shape or form in the file system stuff? I don't remember seeing any description of that case... It means alternate stream of NTFS file. One file can contain any number of such streams. Default one - unnamed - is what you usually use. To use alternate stream, just append :something to the filename parameter of an API call. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Quantity library: any interest?
I wrote Quantity library some time ago and wonder whether it may get added
into Conversion library. If anyone gets interested I will Boostify and
submit it.
Quantity library is used to get safe conversions between different physical
units (like between Celsius and Farhernheit degrees). Instead of bare number
you have specific type and conversion rules are applied automatically.
Example:
typedef struct { float value; } speed_km_per_hour_t;
typedef Quantity
float, // numeric type to represent speed in meter/sec
speed_km_per_hour// alternative representation
speed_meters_per_sec_t;
// conversion rule: define them when it makes sense
void convert_quantity(const speed_meters_per_sec_t from,
speed_km_per_hour_t to)
{
to.value = from.value * 3.6;
}
int main()
{
speed_meters_per_sec_t m_p_s(10);
speed_km_per_hour_tkm_p_h;
km_p_h = m_p_s;// OK
// m_p_s = km_p_h; ERROR - this conversion is not defined
km_p_h = static_castspeed_km_per_hour_t(m_p_s); // OK
}
You can manipulate Quantity value like any other value (add, multiply,
compare), you may add e.g. 1 inch to value of 2.1 meters. This library
helps to avoid really hard to track down conversion errors.
Some conversions may not be needed: e.g. $1.5 money may be converted to
string one dollar, fifty cents but not vice versa. Unimplemented and used
conversions result in (relatively) readable linker error.
Ability e.g. to divide length quantity by time quantity and get speed
quantity may be added into the library.
The library is simple and uses Boost.Preprocessor to emulate variable number
of template parameters.
-
Shortened snippet of implementation:
templatetypename MainType, typename OtherType1
class Quantity
{
public:
Quantity() {}
Quantity(const Quantity other) : value(other.value) {}
Quantity(const MainType val) : value(val) {}
Quantity(const OtherType1 val) { convert_quantity(val, *this); }
~Quantity() {}
Quantity operator=(const Quantity other) { value = other.value; return
*this; }
Quantity operator=(const MainType other) { value = other; return
this*; }
Quantity operator=(const OtherType1 other) { convert_quantity(other,
*this); return *this; }
operator MainType() { return value; }
operator OtherType1() { OtherType1 result; convert_quantity(*this,
result); return result; }
// operators like ==, /, * etc. not shown here
MainType value;
};
-
Name and inspiration was taken from Martin Fowler's article
http://www.martinfowler.com/ap2/quantity.html.
/Pavel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] two problems with BCB 6 and 1.30b
- Original Message -
From: Fernando Cacciola [EMAIL PROTECTED]
Following snippet of code fails:
-
#include boost/optional.hpp
#include utility
void foo(const boost::optionalstd::pairunsigned, unsigned aux =
boost::optionalstd::pairunsigned, unsigned ())
{}
int main() {}
-
[snip]
Hmm..
I can't reproduce the problem here with the 1.30.0 release,
BCB6, update 4, from within the IDE.
Which command line options are you using?
The BCB flags are:
CFLAG1
= -Od -H=$(BCB)\lib\vcl60.csm -Hc -Vx -Ve -X- -r- -a8 -b- -k -y -v -vi- -tWC
\
-tWM- -c
IDLCFLAGS = -IC:\Temp\optional_test -I$(BCB)\include -I$(BCB)\include\vcl \
-IC:\Work\Editor\3pp\boost_1_30_0 -src_suffix cpp -D_DEBUG -boa
PFLAGS = -$YD -$W -$O- -$A8 -v -JPHNE -M
RFLAGS =
AFLAGS = /mx /w2 /zd
LFLAGS = -D -ap -Tpe -x -Gn -v
It is normal console IDE project in BCB Enterprise, using default options.
It fails with 1.30 as well here.
I may send you the whole project if you want.
/Pavel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Alisdair Meredith [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Russell Hind wrote: WinAPI Note: we can get a higher resolution using the QueryPerformanceCounter API (and QueryPerformanceFrequency if resolution info is required) It is (was) not completely reliable: see Q274323 bug in MS Knowledgebase: Symptoms: The result that is returned by the QueryPerformanceCounter function may unexpectedly leap forward from time to time. This leap may represent several seconds. The MSDN article specifies what HW can cause the problem and how to work it around. /Pavel PS: my experience with this API is positive, I got resolution cca ~1 microsecond and the call overhead was tiny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [optional] two problems with BCB 6 and 1.30b
I use Borland C++ Builder 6, update 4, STLPort 4.5.1 (provided by Borland)
and Boost is 1.30.0beta1.
Following snippet of code fails:
-
#include boost/optional.hpp
#include utility
void foo(const boost::optionalstd::pairunsigned, unsigned aux =
boost::optionalstd::pairunsigned, unsigned ())
{}
int main() {}
-
with error message:
[C++ Error] Unit1.cpp(12): E2188 Expression syntax
[C++ Error] Unit1.cpp(12): E2299 Cannot generate template specialization
from '_STLD::pair_T1,_T2'
[C++ Error] Unit1.cpp(12): E2299 Cannot generate template specialization
from 'boost::optionalT'
[C++ Error] Unit1.cpp(13): E2257 , expected
[C++ Error] Unit1.cpp(33): E2151 Type mismatch in default value for
parameter 'aux'
[C++ Error] Unit1.cpp(12): E2293 ) expected
The same code compiles OK with Intel C++ 7.0.
If I use typedef it works OK with both BC++B and Intel C++:
-
#include boost/optional.hpp
#include utility
typedef boost::optionalstd::pairunsigned, unsigned AType;
void foo(AType aux = AType())
{}
int main() {}
-
Borland also fails with this construct:
-
#include boost/optional.hpp
int main()
{
boost::optionalint aux(0);
if (aux *aux == 0) {
aux.reset(1);
}
}
-
with this error message:
[C++ Error] Unit1.cpp(24): E2094 'operator' not implemented in type
'boost::optionalint' for arguments of type 'bool'
Intel C++ 7.0 compiles and executes this snippet OK.
This works in BC++B:
-
#include boost/optional.hpp
int main()
{
boost::optionalint aux(0);
if ((!!aux) *aux == 0) {
aux.reset(1);
}
}
-
These problems may be caused by bugs in BC++B compiler. Sorry if this
problem was already spotted.
/Pavel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr w/ lock mechanism
David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Peter Dimov [EMAIL PROTECTED] writes: From: David Abrahams [EMAIL PROTECTED] Philippe A. Bouchard [EMAIL PROTECTED] writes: Lock mechanism was added to shifted_ptr: http://groups.yahoo.com/group/boost/files/shifted_ptr.zip Benchmarks are also updated. Still shifted_ptr is using less memory and twice faster for reconstruction time. [snip] One easy way to estimate the impact of an optimized allocator is to #define BOOST_SP_USE_STD_ALLOCATOR, to make shared_ptr use std::allocator. On SGI derived STLs, std::allocator is usually faster than plain new. Yeah; I'm pretty sure that my specialized allocator was faster still, since it just allocated fixed-sized blocks and linked them back into a free-list. It was pretty trivial to implement on top of a std::deque of POD unions. Latest C++ compilers come with fairly good allocator for small object . I played with Loki's SmallObjAllocator and even heavily sped up version didn't match the native allocators used in BCB or Intel C++ (being still 30% slower and no MT safety). I guess small object optimisation was already provided, maybe mixed together with tricks as assembler optimisation or cache wizardry. OTOH GCC 2.95.* was significantly slower than Loki. $0.02 /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: undo library
Ihsan Ali Al Darhi [EMAIL PROTECTED] wrote in message 01d001c2c2ba$6af14ea0$73c721d4@h8p7o2">news:01d001c2c2ba$6af14ea0$73c721d4@h8p7o2... Can I use this library to implement multiple undo/redo in GUI applications under Windows? For example in a word processor. Undo/redo is generic mechanism that can be used for whatever purpose. Undo/redo in wordprocessors/graphics editors is the most common case. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_abstract_baseT ?
Robert Ramey [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Is there such a thing as is_abstract_baseT similar to is_polymorphicT ? Is such a thing possible? I could use it but have been unable to figrure out how to do it. Rani Sharoni wrote is_abstract_classT type trait (see on http://groups.google.com/groups?q=is_abstract_classhl=enlr=ie=UTF-8oe=UT F-8selm=df893da6.0207110613.75b2fe90%40posting.google.comrnum=1). It compiles on Comeau, Intel C++ 7.0 and VC++ 7.1beta. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: undo library
Andrei Alexandrescu [EMAIL PROTECTED] wrote in message b0pu01$bqd$[EMAIL PROTECTED]">news:b0pu01$bqd$[EMAIL PROTECTED]... Al Stevens has an article in a past DDJ about a generic undo/redo library, can anyone dig it out? I recall it was interesting. Can be purchased here: https://www.sdmediagroup.com/secure/?sid=954 and followup here: https://www.sdmediagroup.com/secure/?sid=914 /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] is_abstract_class type trait
Rani Sharoni posted one possible implementation on http://tinyurl.com/459q (c.l.c++.m, 2002-07-11, topic 'is_abstract_class implementation!'). The implementation depends on border-case C++ feature (more in Rani's text). I compiled it sucessfully with Comeau online compiler. It may be considered as addition to type_traits library, after the standard settles on it. is_abstract_classT may be useful e.g. to enforce don't derive from non-abstract classes constraint. /Pavel _ MSN 8: advanced junk mail protection and 2 months FREE*. http://join.msn.com/?page=features/junkmail ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: statistics
Beman Dawes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [snip] If I understand you correctly, those are counts of the number of files. Yes. The visible tendency is to provide all formats: zip/gz/bzip2. Previous releases typically come with only zip/gz and this skews statistic a bit. Bzip2 is catching on lately. It would also be interesting to look at the download counts for projects which make several formats available. SourceForge, for what I know, doesn't provide statistics breakdown on single files. In other words, what formats do users prefer to download when several are available? Question for SourceForge staff, if exact number is needed. I personally always pick the smallest file available. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] statistics
Beman Dawes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 03:05 PM 11/29/2002, Pavel Vozenilek wrote: Bandwith and time of those with dialup can be saved by compressing Boost release by BZIP2 compressor (http://sources.redhat.com/bzip2/). [snip] Regardless, thanks for bringing it up. I've been wondering if bzip2 was becoming a commonplace format. Statistics for first 15 projects from SourceForge, keyword C++: Compressed downloadable files: - ZIP files: 250 - GZ files: 212 - BZIP2 files: 50 No other general purpose compressors were used (there were few Mac specific files and some RPM). 4 out of 15 projects provided BZIP2 compressed files. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost release compressed by bzip2
Bandwith and time of those with dialup can be saved by compressing Boost release by BZIP2 compressor (http://sources.redhat.com/bzip2/). For example boost_1_29_0.tar.gz has size 5 272 kB, tared and compressed by bzip2 size is 4 282 kB (down to 81%). Boost size will grow (Spirit lib has over 600kB) and bzip2 can reduce the growth a bit. Bzip2 is available on many platforms, free to use, stable and quite used. /Pavel _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
