[boost] Re: Fixed-Point Decimal Formal Review
Hello Mike, I completly agree with your your statement. The IEEE 754 revision committee has added decimal formats (32, 64, and 128 bits) to the proposed new Floating-point standard, along with full DFP arithmetic. May I suggest that the class be changed to implement the proposed IEEE 754 arithmetic? This would be a tremendous contribution, and it could even use the existing representation (perhaps expanded to 128 bits), or it could use the proposed IEEE 754 layouts. The latter offers the possibility of changing the class later to take advantage of the hardware DFP when that becomes available. We used the proposed IEEE754 layouts for our own number class with some minor changes. The proposed format seems to be ideal for hardware but was a little bit to slow for a pure software implementation. For every feature in the specification we asked Is there a performance penalty even if I don't use this feature and removed it if necessary. The resulting class is quite fast (not as fast as a fixed point decimal class). Dirk ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Slight revision to more-I/O
On Tuesday, July 22, 2003, at 8:51 AM, Paul A. Bristow wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daryle Walker Sent: Saturday, July 19, 2003 8:38 AM To: Boost Subject: [boost] Slight revision to more-I/O In the latest post-review version, I fully disabled copying for the array-based stream-buffer class. I also copied the revised version of the library to http://groups.yahoo.com/group/boost/files/more_io_revised.zip The iostate saving and iomanip seem fine, but I am left uncertain on how to use the stream buffer class in practice. More user-oriented documentation, tests and examples would be helpful. (And also there seem to be differing, perhaps competing, perhaps conflicting, offerings in filtering/decorating stream buffers). You've looked at the revised version, right? (A lot of the changes between the original and revised versions were based on previous reviews, so I don't want to answer questions on the first version if it was already fixed in the second. Note that changes that would have involved greatly changing the API weren't/won't-be done.) The State-saving I/O stuff has already gone in; it was reviewed over a year ago. (I don't know why almost everyone is thinking it's being re-reviewed?) The I/O manipulator is part of this review. Which stream-buffer class are you talking about, array-wrappers or the stream-wrapping helpers? The stream-wrapping helpers are just that; you would define your own stream-buffer class then semi-automate the corresponding stream classes with the helper classes. You'll have to manually write the constructors and forwarding functions yourself since they're open-ended. The docs for the stream-wrappings now has a long example that also includes alternate techniques. The array-wrappers are also example of the wrapping technique. Those array-wrappers can be used to help limit the amount of dynamic storage in a program (since it doesn't use any). I checked out some of the filtering/decorating stuff; they have nothing to do with the stuff in this review, in terms of main features. However, the stream adaptations of the filtering stream-buffers use a manual version of the stream-wrapping technique. It looks like there is a case to encapsulate this idiom with actual helper classes (since I'm not the only one using it). Daryle ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] spatial and metric containers
[EMAIL PROTECTED] wrote: SMTL aims to efficiently solve queries like: a) Which books where written by authors whose last name begins with B between 1986 and 1994? b) How many cities with population above 10,000 are located between such and such latitude and such and such longitude? c) Which is the closest gas station to this point? d) Which are the 10 most similar objects to this complex object? I'd be very interested in something like this. A few questions: 1. What underlying data structures are used? Are they interesting in their own right? (in particular, KD trees and R-trees may be useful as building blocks for interesting applications of their own. For example, both can be very useful as accelerators for raytracing) 2. Is there any support for more specialised geometric structures? In particular, BSP trees and Delauney triangulation? If not, are the structures you've already build easily reusable for this? 3. Have you looked into contacting the author of the relational algebra boost proposal (this was discussed a few months ago, the archives would be the good place to look). SMTL would be great for implementing multi-indexed relational tables. Miro ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fixed-Point Decimal Formal Review
Dirk Schreib wrote: I completly agree with your your statement. Always nice to hear :-). We used the proposed IEEE754 layouts for our own number class with some minor changes. The proposed format seems to be ideal for hardware but was a little bit to slow for a pure software implementation. For every feature in the specification we asked Is there a performance penalty even if I don't use this feature and removed it if necessary. The resulting class is quite fast (not as fast as a fixed point decimal class). Any documentation of what you ended up with? Mike Cowlishaw ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Bug of new boost::random
Dear Jens, dear Boosters,
Some of the new distributions in the Boost random library no longer
work with floating point based generators. Could Jens or somebody fix
that? I myself am reluctant to provide a fix.
Here is a test program that fails to compile now:
#include boost/random.hpp
int main()
{
boost::lagged_fibonacci607 rng;
boost::uniform_int int_rng(0,3);
int x = int_rng(rng);
}
Best regards,
Matthias
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Thread locking
Sometimes I have to write code like this:
timed_mutex mtx;
void foo()
{
{
xtime xt = get_it();
timed_mutex::scoped_timed_lock lock1(mtx, xt);
if(lock1)
{
// ...
}
}
{
boost::xtime xt = get_it();
timed_mutex::scoped_timed_lock lock2(mtx, xt);
if(lock2)
{
// ...
}
}
}
I don't like extra scope needed to control locking. IMO, ScopeGuard idiom
can be used to get rid of it. In example below class lock plays the role
of ScopeGuard:
void foo()
{
xtime xt = get_it();
if(lock lock1 = timed_mutex::scoped_timed_lock(mtx, xt))
{
// ...
}
xt = get_it();
if(lock lock2 = timed_mutex::scoped_timed_lock(mtx, xt))
{
// ...
}
}
--
Alexander Nasonov
Remove minus and all between minus and at from my e-mail for timely response
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Status of CVS problems
Here is a quote from the monthly SourceForge newsletter: As you may have noticed, CVS is visibly having growing pains. Due to system load, we have had to move anonymous checkouts to our backup server. This has made the code of our 65,000 projects more accessible. However, since data is synchronized from the primary CVS servers to the backup CVS servers at specific times during the day, it has also caused up to a 24 hour delay in getting the freshest code on the site. I know this temporary solution has frustrated some of you and I want to apologize for that. The good news is, in the very short term, we will have a solution that will solve this issue. We are upgrading our hardware from one aging system to six new speedy boxes; this hardware is a portion of the new CVS infrastructure that we are implementing to improve CVS performance and reliability. The solution will be in place by the time I write you next month. You'll know when we make the change. It will be hard to miss. In the mean time, hang in there. I know it's frustrating, but help is on the way. Hopefully then the CVS access problems will clear in the next 30 days or so. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: In Re Comments From Peter Dimov
Smith, Devin wrote: * Why is the new license better? A: Because it's more thorough CPL is even more thorough. Heck, what about patents? What about re-licensing/forks (e.g. infamous LGPL - GPL degradation)? regards, alexander. -- If Unix were a car, they said, SCO Unix was like a driving motorized wheelbarrow through a mosquito-infested swamp naked with both hands tied behind your back. -- http://www.humorix.org/articles/may03/sco.shtml ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: In Re Comments From Peter Dimov
[2003-07-25] Alexander Terekhov wrote: Smith, Devin wrote: * Why is the new license better? A: Because it's more thorough CPL is even more thorough. Heck, what about patents? What about re-licensing/forks (e.g. infamous LGPL - GPL degradation)? See... http://tinyurl.com/i1uu -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] GUI/GDI template library
I was thinking about designing a GUI/GDI template
library.
The main ideas are:
1. Create a portable template abstraction for standard
GUI/GDI elements and dialog boxes.
2. Design an iterator-like interface.
3. The most important goal is design a natural
connection between STL containers and GUI elements, so
that STL data can be easily presented in the GUI
environment.
For example
template typename IT, typename PhysicalGuiLayer
class ListControl
{
public:
template typename Filter, typename Format
void push_back( IT FirstIt,
IT EndIt,
Filter filter,
Format format )
{
for( IT it = FirstIt; it EndIt; ++it )
{
if( filter(it) )
{
PhysicalGuiLayer::list_add_item(
m_hnd,
format.get_list_item(it)
);
}
}
}
};
Does something similar exist already?
It seems like a challenging project. If anybody is
interested, let me know.
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: is_nan
[EMAIL PROTECTED] writes:
| Sorry for the late reply, I was enjoying some peaceful holidays.
There is no reason for sorrying.
| En réponse à Gabriel Dos Reis [EMAIL PROTECTED]:
|
| Guillaume Melquiond [EMAIL PROTECTED] writes:
|
| | On Fri, 4 Jul 2003, Fernando Cacciola wrote:
| |
| | Gabriel Dos Reis [EMAIL PROTECTED] wrote in message
| | news:[EMAIL PROTECTED]
| | jvd [EMAIL PROTECTED] writes:
| |
| | | Dear boosters,
| | |
| | | seems like this code
| | |
| | | template typename T
| | | bool is_nan( const T v )
| | | {
| | | return std::numeric_limitsT::has_quiet_NaN (v != v);
|
| Do you read the previous line?
Do you have evidence otherwise?
Must we quibble?
| We are speaking about quiet NaNs here. And so I
| was justifying why the interval library computes v != v in order to detect
| quiet NaNs. I never intended to speak about signaling NaNs.
The point of my mail was that it is a mistake to ignore sNaNs.
| | | }
| | |
| | | does not work correctly on some machines.
| |
| | Yes. It is an incorrect (unfortunately popular) implementation.
| |
| | Right. We should say that more often. It is incorrect however popular.
| |
| | Yes, it is incorrect for C++. But it's something we can hope to see one
| | day. For example, in the LIA-1 annex I about C langage bindings, it is
| | written that != is a binding for IEEE-754 ? operator (unordered
| | compare). In the C9X annex F.8.3 about relational operators, it is written
| | that the optimization x != x - false is not allowed since The
| | statement x != x is true if x is a NaN. And so on.
|
| You seem to forget that C99 does not consider Signalling NaNs -- which
| are other missing parts of C99. For those NaNs, the comparaison might
| just trap.
|
| Please, be careful when quoting.
|
| I hope you understand I was careful when quoting: we only were talking about
| quiet NaNs initially. But since you absolutely want to talk about signaling
| NaNs, I suggest you take a look at the revision of the IEEE-754 standard[1].
Don't worry, I have a copy of it. Not just because, something get
deprecated means it gets (1) illegal, (2) out of circulation. In
fact, it is still there.
| Signaling NaNs are on their way to be deprecated (the §N proposal for example),
I know of the proposal -- and of an initial sent to many forums.
| or at least declared stricly optional (the current draft). So I wouldn't expect
| a portable program to use signaling NaNs.
Portable programs don't rely on IEEE-754 semantics. Period. So, you
cannot use porability argument for discrimination. And sNaNs are
still in use. *You* (Guillaume) can choose to not support them, but
that is a different story.
| As for your other mail:
|
| From your above statement, I understand that the interval library
| does not use sNaNs by itself. What about users getting sNaNs with the
| library?
|
| I don't understand what you mean by getting sNaNs with the library.
this:
| If the user gives signaling NaNs in input,
| the interval program will fail exactly as if it was a floating-point
| program: it will generate a floating-point trap.
I guess, the point of my question got lost in rhetorics. Sigh.
Ths point was the isnan() query should *not* trigger a trap.
-- Gaby
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_nan
En réponse à Gabriel Dos Reis [EMAIL PROTECTED]: [snip] | We are speaking about quiet NaNs here. And so I | was justifying why the interval library computes v != v in order to | detect quiet NaNs. I never intended to speak about signaling NaNs. The point of my mail was that it is a mistake to ignore sNaNs. It seems there is a misunderstanding. In the context of the interval library, think about this function as an internal function. If quiet NaNs are available, the library will use them. And this function is here to detect them. It is meant to detect values created by the library itself. The library only creates quiet NaNs, the function only has to detect quiet NaNs. The library does not create signaling NaNs, it is not necessary to have an overly complex function in order to detect them (since this function will never have a signaling NaN as an argument). [snip] | As for your other mail: | | From your above statement, I understand that the interval library | does not use sNaNs by itself. What about users getting sNaNs with the | library? | | I don't understand what you mean by getting sNaNs with the library. this: | If the user gives signaling NaNs in input, | the interval program will fail exactly as if it was a floating-point | program: it will generate a floating-point trap. I guess, the point of my question got lost in rhetorics. Sigh. Ths point was the isnan() query should *not* trigger a trap. The way the library uses it, the isnan function can not trigger a trap unless the user messed with something. Moreover, it is a private function, the user is not supposed to use it. On a more general side, please keep in mind that *signaling* NaNs are meant to trap when used (used can be a simple copy, the standard leaves it implementation-defined). If the user suddenly decides to put a signaling NaN in a floating-point variable, she shouldn't be surprised if the program traps as soon as it uses this variable. I don't understand why the interval library should prevent such a behavior, since it is the expected behavior (the isnan function is an internal function used by the other functions of the library, they are supposed to trap if supplied with a signaling value). Regards, Guillaume ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
This sounds to me like the goals of the Whisper framework. Check out
Whisper 2 on source forge.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of E. Gladyshev
Sent: Friday, July 25, 2003 11:11 AM
To: [EMAIL PROTECTED]
Subject: [boost] GUI/GDI template library
I was thinking about designing a GUI/GDI template
library.
The main ideas are:
1. Create a portable template abstraction for standard
GUI/GDI elements and dialog boxes.
2. Design an iterator-like interface.
3. The most important goal is design a natural
connection between STL containers and GUI elements, so
that STL data can be easily presented in the GUI
environment.
For example
template typename IT, typename PhysicalGuiLayer
class ListControl
{
public:
template typename Filter, typename Format
void push_back( IT FirstIt,
IT EndIt,
Filter filter,
Format format )
{
for( IT it = FirstIt; it EndIt; ++it )
{
if( filter(it) )
{
PhysicalGuiLayer::list_add_item(
m_hnd,
format.get_list_item(it)
);
}
}
}
};
Does something similar exist already?
It seems like a challenging project. If anybody is
interested, let me know.
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/bo ost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI/GDI template library
E. Gladyshev wrote: I was thinking about designing a GUI/GDI template library. The main ideas are: 1. Create a portable template abstraction for standard GUI/GDI elements and dialog boxes. 2. Design an iterator-like interface. 3. The most important goal is design a natural connection between STL containers and GUI elements, so that STL data can be easily presented in the GUI environment. [...] You have my support when time permits. I know Qt like the back of my hand and I keep playing around with their designs to implement flexible widgets. I just don't have enough time for further in-depth development. A template based widget interface would be great for SDI / MDI windows, recursive container widgets, ownership, layout management, policy based input / output (string, wstring, stringstream, filestream, pipestream, ...), etc. It is hard to believe sometimes this is not yet done. ;) Philippe A. Bouchard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
Do you mean that your librry is directed to MS Windows?
Mohammed
- Original Message -
From: E. Gladyshev [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 25, 2003 9:11 PM
Subject: [boost] GUI/GDI template library
I was thinking about designing a GUI/GDI template
library.
The main ideas are:
1. Create a portable template abstraction for standard
GUI/GDI elements and dialog boxes.
2. Design an iterator-like interface.
3. The most important goal is design a natural
connection between STL containers and GUI elements, so
that STL data can be easily presented in the GUI
environment.
For example
template typename IT, typename PhysicalGuiLayer
class ListControl
{
public:
template typename Filter, typename Format
void push_back( IT FirstIt,
IT EndIt,
Filter filter,
Format format )
{
for( IT it = FirstIt; it EndIt; ++it )
{
if( filter(it) )
{
sicalGuiLayer::list_add_item(
m_hnd,
format.get_list_item(it)
);
}
}
}
};
Does something similar exist already?
It seems like a challenging project. If anybody is
interested, let me know.
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
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_nan
[EMAIL PROTECTED] writes: | En réponse à Gabriel Dos Reis [EMAIL PROTECTED]: | | [snip] | | | We are speaking about quiet NaNs here. And so I | | was justifying why the interval library computes v != v in order to | | detect quiet NaNs. I never intended to speak about signaling NaNs. | | The point of my mail was that it is a mistake to ignore sNaNs. | | It seems there is a misunderstanding. Certainly, there is. Given the amount of mails, and apparently no concrete convergence. | In the context of the interval library, think about this function as | an internal function. Please, assume I have some knowledge of interval arithmetic -- or else, I will shut up. | If quiet NaNs are available, the library will use them. And this | function is here to detect them. I understand the purpose of the function. What I'm saying is that it is ill-implemented, or the implementation is not correct. | It is meant to detect values created by the library itself. The | library only creates quiet NaNs, I fully understand how NaNs get created and that usual arithmetic operations don't create sNaNs. The point you seem to miss is that values are not only created by interval arithmetic operations. [...] | Ths point was the isnan() query should *not* trigger a trap. | | The way the library uses it, the isnan function can not trigger a trap unless | the user messed with something. Moreover, it is a private function, | the user is not supposed to use it. The fact that the function is private has nothing to do with it triggering a trap or not. | On a more general side, please keep in mind that *signaling* NaNs are meant to | trap when used (used can be a simple copy, the standard leaves it | implementation-defined). They trap only when operands of arithmetic operations. | If the user suddenly decides to put a signaling NaN in | a floating-point variable, she shouldn't be surprised if the program traps as | soon as it uses this variable. I don't understand why the interval library | should prevent such a behavior, I'm not saying the interval library should prevent that behaviour. I'm syaing the interval arithmetic should not provide a trapping isnan function. That is a different matter. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
The library itself would be portable, the physical
layer (Win32 or else) is specified as a data type with
a bunch of static functions. It is similar to data
type traits in STL. In other words the physical layer
is a data type that is used as a template parameter.
If you need to adopt the GUI/GDI template library to
another system, all you'll need to do is to create a
data type which defines the predefined traits.
Here is a simple example of the Bitmap and ImageList
templates and Win32 traits that demonstrates this
idea. Note: I have not tried to compile this code yet.
template typename Tr = WinGdiTraits
class Bitmap : public GdiObj Tr::BitmapHnd, Tr
{
public:
_bool create( const Resource r )
{
m_hnd = Traits::load_bitmap( r );
if( !m_hnd ) return FALSE;
return TRUE;
}
inline Size size( )
{
return Traits::get_bmpsize( m_hnd );
}
};
template typename Tr=WinGdiTraits
class ImageList : public GdiObj Tr::ImageListHnd, Tr
{
public:
typedef int iterator;
_bool create( const Resource r, const Color
transp_color, int imgnum )
{
BitmapTr bmp;
if( !bmp.create(r) ) return FALSE;
m_hnd = Traits::create_imglist( bmp, transp_color,
bmp.size()/imgnum );
if( !m_hnd ) return FALSE;
return TRUE;
}
inline iterator begin () { return 0; }
inline iterator end () { return size(); }
inline int size () { return
Traits::get_imglist_size( m_hnd ); }
};
// Win32 traits
//=
class WinTypes
{
public:
typedef HWNDWinHnd;
typedef HGDIOBJ GdiHnd;
typedef HBITMAP BitmapHnd;
typedef HIMAGELIST ImageListHnd;
typedef SIZESize;
typedef POINT Point;
typedef RECTRect;
typedef WinRes Resource;
typedef COLORREFColor;
};
//
class WinGdiTraits : public WinTypes
{
public:
typedef GdiHnd Hnd;
static void destroy ( Hnd h ) { ::DeleteObject( h
); }
static void destroy ( BitmapHnd h ) {
::DeleteObject( (Hnd)h ); }
static void destroy ( ImageListHnd h ) {
::ImageList_Destroy( h ); }
//bitmap functions
static BitmapHnd load_bitmap( const Resource r )
{
return ::LoadBitmap( r.m_hinst, r.m_res }
}
static Size get_bmpsize( BitmapHnd h )
{
Size s;
BITMAP bmp;
assert( h );
::GetObject( h, sizeof(BITMAP), bmp);
s.cx = bmp.bmWidth;
s.cy = gmp.bmHeight;
return s;
}
//image list
static ImageListHnd create_imglist( BitmapHnd hb,
const Color transp_color, int image_cx )
{
ImageListHnd h;
Size s;
get_bmpsize( hb, s );
h = ImageList_Create( image_cx, s.cy, ILC_MASK |
ILC_COLOR32, 0, 1);
if( !h ) return NULL;
// Add the bitmap into the image list
ImageList_AddMasked( h, hb, transp_color );
return h;
}
static int get_imglist_size( ImageListHnd h )
{
return ImageList_GetImageCount( h );
}
};
Eugene
--- iad929 [EMAIL PROTECTED] wrote:
Do you mean that your librry is directed to MS
Windows?
Mohammed
- Original Message -
From: E. Gladyshev [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 25, 2003 9:11 PM
Subject: [boost] GUI/GDI template library
I was thinking about designing a GUI/GDI template
library.
The main ideas are:
1. Create a portable template abstraction for
standard
GUI/GDI elements and dialog boxes.
2. Design an iterator-like interface.
3. The most important goal is design a natural
connection between STL containers and GUI
elements, so
that STL data can be easily presented in the GUI
environment.
For example
template typename IT, typename PhysicalGuiLayer
class ListControl
{
public:
template typename Filter, typename Format
void push_back( IT FirstIt,
IT EndIt,
Filter filter,
Format format )
{
for( IT it = FirstIt; it EndIt; ++it )
{
if( filter(it) )
{
sicalGuiLayer::list_add_item(
m_hnd,
format.get_list_item(it)
);
}
}
}
};
Does something similar exist already?
It seems like a challenging project. If anybody is
interested, let me know.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site
design software
http://sitebuilder.yahoo.com
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
Sorry, forgot to put the base class in.
// base for GDI objects, like bitmaps, imagelists,
pens, etc.
//==
template typename T, typename Tr
class GdiObj
{
public:
typedef Tr Traits;
typedef T Hnd;
inline GidObj()
{
m_hnd = NULL;
}
virtual ~GdiObj()
{
destroy();
}
inline destroy()
{
if( !m_hnd ) return;
Traits::destroy( m_hnd );
m_hnd = NULL;
}
inline void set_hnd( Hnd hnd ) { m_hnd = hnd; }
inline Hnd get_hnd() const { return m_hnd; }
inline operator T() const { return m_hnd; }
public:
T m_hnd;
};
template typename Tr = WinGdiTraits
class Bitmap : public GdiObj Tr::BitmapHnd, Tr
{
public:
_bool create( const Tr::Resource r )
{
m_hnd = Traits::load_bitmap( r );
if( !m_hnd ) return FALSE;
return TRUE;
}
inline Size size( )
{
return Traits::get_bmpsize( m_hnd );
}
};
template typename Tr=WinGdiTraits
class ImageList : public GdiObj Tr::ImageListHnd, Tr
{
public:
typedef int iterator;
_bool create( const Tr::Resource r, const Color
transp_color, int imgnum )
{
BitmapTr bmp;
if( !bmp.create(r) ) return FALSE;
m_hnd = Traits::create_imglist( bmp, transp_color,
bmp.size()/imgnum );
if( !m_hnd ) return FALSE;
return TRUE;
}
inline iterator begin () { return 0; }
inline iterator end () { return size(); }
inline int size () { return
Traits::get_imglist_size( m_hnd ); }
};
--- E. Gladyshev [EMAIL PROTECTED] wrote:
The library itself would be portable, the physical
layer (Win32 or else) is specified as a data type
with
a bunch of static functions. It is similar to data
type traits in STL. In other words the physical
layer
is a data type that is used as a template parameter.
If you need to adopt the GUI/GDI template library to
another system, all you'll need to do is to create a
data type which defines the predefined traits.
Here is a simple example of the Bitmap and ImageList
templates and Win32 traits that demonstrates this
idea. Note: I have not tried to compile this code
yet.
template typename Tr = WinGdiTraits
class Bitmap : public GdiObj Tr::BitmapHnd, Tr
{
public:
_bool create( const Resource r )
{
m_hnd = Traits::load_bitmap( r );
if( !m_hnd ) return FALSE;
return TRUE;
}
inline Size size( )
{
return Traits::get_bmpsize( m_hnd );
}
};
template typename Tr=WinGdiTraits
class ImageList : public GdiObj Tr::ImageListHnd,
Tr
{
public:
typedef int iterator;
_bool create( const Resource r, const Color
transp_color, int imgnum )
{
BitmapTr bmp;
if( !bmp.create(r) ) return FALSE;
m_hnd = Traits::create_imglist( bmp, transp_color,
bmp.size()/imgnum );
if( !m_hnd ) return FALSE;
return TRUE;
}
inline iterator begin () { return 0; }
inline iterator end () { return size(); }
inline int size () { return
Traits::get_imglist_size( m_hnd ); }
};
// Win32 traits
//=
class WinTypes
{
public:
typedef HWNDWinHnd;
typedef HGDIOBJ GdiHnd;
typedef HBITMAP BitmapHnd;
typedef HIMAGELIST ImageListHnd;
typedef SIZESize;
typedef POINT Point;
typedef RECTRect;
typedef WinRes Resource;
typedef COLORREFColor;
};
//
class WinGdiTraits : public WinTypes
{
public:
typedef GdiHnd Hnd;
static void destroy ( Hnd h ) { ::DeleteObject( h
); }
static void destroy ( BitmapHnd h ) {
::DeleteObject( (Hnd)h ); }
static void destroy ( ImageListHnd h ) {
::ImageList_Destroy( h ); }
//bitmap functions
static BitmapHnd load_bitmap( const Resource r )
{
return ::LoadBitmap( r.m_hinst, r.m_res }
}
static Size get_bmpsize( BitmapHnd h )
{
Size s;
BITMAP bmp;
assert( h );
::GetObject( h, sizeof(BITMAP), bmp);
s.cx = bmp.bmWidth;
s.cy = gmp.bmHeight;
return s;
}
//image list
static ImageListHnd create_imglist( BitmapHnd hb,
const Color transp_color, int image_cx )
{
ImageListHnd h;
Size s;
get_bmpsize( hb, s );
h = ImageList_Create( image_cx, s.cy, ILC_MASK |
ILC_COLOR32, 0, 1);
if( !h )
RE: [boost] GUI/GDI template library
Whisper2 is more like an application framework, and
it's quite huge and Mac/Win only. My suggestion is to
provide a relatively simple way to connect STL
containers to the standard GUI elements and deploy the
container/iterator paradigm to the GUI/GDI elements
themselves. Something very light and portable.
Eugene
--- Jon Kalb [EMAIL PROTECTED] wrote:
This sounds to me like the goals of the Whisper
framework. Check out
Whisper 2 on source forge.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of E. Gladyshev
Sent: Friday, July 25, 2003 11:11 AM
To: [EMAIL PROTECTED]
Subject: [boost] GUI/GDI template library
I was thinking about designing a GUI/GDI template
library.
The main ideas are:
1. Create a portable template abstraction for
standard
GUI/GDI elements and dialog boxes.
2. Design an iterator-like interface.
3. The most important goal is design a natural
connection between STL containers and GUI
elements, so
that STL data can be easily presented in the GUI
environment.
For example
template typename IT, typename PhysicalGuiLayer
class ListControl
{
public:
template typename Filter, typename Format
void push_back( IT FirstIt,
IT EndIt,
Filter filter,
Format format )
{
for( IT it = FirstIt; it EndIt; ++it )
{
if( filter(it) )
{
PhysicalGuiLayer::list_add_item(
m_hnd,
format.get_list_item(it)
);
}
}
}
};
Does something similar exist already?
It seems like a challenging project. If anybody is
interested, let me know.
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/bo
ost
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
I was thinking about designing a GUI/GDI template library. I suggest that you build it around Boost nit buildingit then Bosstifing it later. Mohammed ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: spatial and metric containers
Miroslav Silovic [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: SMTL aims to efficiently solve queries like: a) Which books where written by authors whose last name begins with B between 1986 and 1994? b) How many cities with population above 10,000 are located between such and such latitude and such and such longitude? c) Which is the closest gas station to this point? d) Which are the 10 most similar objects to this complex object? I'd be very interested in something like this. A few questions: I concur. Eugene ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: spatial and metric containers
[EMAIL PROTECTED] wrote: This post is to ask for potential interest for a new library. We (G. Marpons and me) have developed a prototype library called SMTL (Spatial and Metric Template Library) Could you give an example of what a query like, for example a) Which books where written by authors whose last name begins with B between 1986 and 1994? would look like using this library? (required underlying structs can be assumed to be present) -- Truth, James Curran www.noveltheory.com (personal) www.njtheater.com (professional) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI/GDI template library
E. Gladyshev wrote: I was thinking about designing a GUI/GDI template library. The main ideas are: 1. Create a portable template abstraction for standard GUI/GDI elements and dialog boxes. 2. Design an iterator-like interface. 3. The most important goal is design a natural connection between STL containers and GUI elements, so that STL data can be easily presented in the GUI environment. Microsoft has a Windows Template Library, WTL, for Windows specifically, which is template-based but which they barely support for their VC++ users. There are other cross-platform frameworks which seek to encapsulate GUI/GDI in classes but few of them are template-based as far as I know. I think you have a big job attempting to create a cross-platform C++ GUI/GDI framework considering the different operating systems which Boost supports and therefore the different GUI/GDI elements on those systems. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI/GDI template library
Edward Diener wrote: [...] Microsoft has a Windows Template Library, WTL, for Windows specifically, which is template-based but which they barely support for their VC++ users. There are other cross-platform frameworks which seek to encapsulate GUI/GDI in classes but few of them are template-based as far as I know. I think you have a big job attempting to create a cross-platform C++ GUI/GDI framework considering the different operating systems which Boost supports and therefore the different GUI/GDI elements on those systems. If you want to write a portable GUI from scratch, the only thing you need is the stylish frame, colors, fonts menus. You then need to implement the ability to draw some rectangles portably and the Qt library does that already, you can take a look here (qt.../src/kernel/qpaintdevice_x11.cpp): http://ftp.debian.org/debian/pool/main/q/qt-x11-free/qt-x11-free_3.1.1.orig.tar.gz Everybody knows Windows GDI so there's nothing to hide... -- Philippe A. Bouchard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
Microsoft has a Windows Template Library, WTL, for Windows specifically, which is template-based but which they barely support for their VC++ users. The main point of the proposed library is not a wrapper. WTL is just a Win32 wrapper. The main idea is to simplify the use of STL containers as data sources for UI widgets (in a portable way). See my ListControl sample in a prev. message. Also the proposed library will help to organize the GUI/GDI elements and controlling data structures in a consistent (with the C++ standard) way using the 'iterator' paradigm. It seems to me that in our practicle life, we ended up with two different worlds in our hands. One is the nice and clean C++ template world which works great to program algorithms and data strucures and another one is the dirty GUI world that we have to use to present our nice data structures. Most of the time when we try to bring these two together, the nice structure of C++ template programming doesn't look so nice anymore. It is a big project but at the end, it should bring these two worlds together (at least bit). __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
E. Gladyshev wrote: The library itself would be portable, the physical layer (Win32 or else) is specified as a data type with a bunch of static functions. It is similar to data type traits in STL. In other words the physical layer is a data type that is used as a template parameter. If you need to adopt the GUI/GDI template library to another system, all you'll need to do is to create a data type which defines the predefined traits. Here is a simple example of the Bitmap and ImageList templates and Win32 traits that demonstrates this idea. Note: I have not tried to compile this code yet. See, the problem is the fundamental abstractions in GUI programming are radically different. GUI programming in Unix for example is _dramatically_ different from Windows. One needs to worry about things like server side pixmaps instead of client side pixmaps and some of the modern widget kits (like Gtk+) have a complex OO design. Not to mention the fundamental difference between message-based GUIs (like Win32) verses callback based GUIs (like X) verses signal/slot based libraries (like Qt). It's not impossible, but it's very very difficult. Regards, Anthony Liguori ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: GUI/GDI template library
E. Gladyshev wrote: Microsoft has a Windows Template Library, WTL, for Windows specifically, which is template-based but which they barely support for their VC++ users. The main point of the proposed library is not a wrapper. WTL is just a Win32 wrapper. The main idea is to simplify the use of STL containers as data sources for UI widgets (in a portable way). See my ListControl sample in a prev. message. Also the proposed library will help to organize the GUI/GDI elements and controlling data structures in a consistent (with the C++ standard) way using the 'iterator' paradigm. I understand that. It seems to me that in our practicle life, we ended up with two different worlds in our hands. One is the nice and clean C++ template world which works great to program algorithms and data strucures and another one is the dirty GUI world that we have to use to present our nice data structures. Most of the time when we try to bring these two together, the nice structure of C++ template programming doesn't look so nice anymore. Again I see what you want to do. It is a big project but at the end, it should bring these two worlds together (at least bit). I am not trying to discourage you on working on such a project but the differences in GUI widgets and GDI functionality between operating systems is still very great. As a very simple example, realizing that most examples will be much more complex, items in a listbox may be representable by a std::vector or even a std::map in one operating system but may have much more complex requirements in another OS. Besides the issue of mere representation of the items in the listbox is the way the listbox gets populated with data and the way one reads data from the listbox back into your containers. This also varies from OS to OS. Some OS's use messages to transport data, some use callbacks, some use direct API calls, some use enumerations, some use asynchronous I/O, and there may be other mechanisms for all I know. And this is just a listbox, a very simple widget, and yet you are going to have to write code for this that works for Windows, Linux, Unix flavors, MacIntosh, VMS, OS2, and whatever else OSs Boost supports. Think of more complicated widgets which have been developed like tree views, page controls, list views, track bars, toolbars, edit controls, combo boxes, and many others. On the GDI side there is the drawing of bitmap images, geometrical figures, text, regions, vector images, low-level APIs like OpenGl and DirectX, the list goes on and on. The task is daunting. Add to this the fact that nearly every C++ programmer already works with a framework library depending on his implementation of choice. On Windows alone I know of WTL, ATL, MFC, OWL, VCL, wxWindows, QT, and no doubt others about which I have no knowledde, each tied very closely to a particular C++ compiler, IDE, and implementation. While there may well be C++ programmers looking for a cross-platform GUI/GDI from Boost, most programmers are already very comfortable with the framework which comes with their C++ compiler and with the IDE features and tools that make using their widgets very easy. Some of these frameworks, hooked to dialog editors or window placement tools, allow the programmer to literally draw or place the widget exactly where it should go and specify both the widget's physical representation and data representation, and even the structures by which the data will be passed from and to the widget. The amount of code which must be written often becomes negligible by the programmer after the design time interfaces have been set up. Yes, the data structures are pretty primitive compared to C++ template containers and whatever other good things you might create, but it will be very hard for most C++ programmers to give up their RAD and RAD-like tools for manipulation of a library entirely by code. Finally many C++ programmers, being the creators that they are, have already invented C++ template-based mechanisms to use on top of the GUI/GDI framework of choice which their compiler and implementation provides. They may be very loath to use another more general template-based framework no matter how good it is. I am not trying to argue you against pursuing your goal but simply trying to point out the difficulties that exist and the barriers against many C++ programmers adopting your implementation as opposed to what they have already been using. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
[...] I am not trying to discourage you on working on such a project but the Thanks for your comments. Don't worry, this is why I posted it here, to hear what other people think. [...] works for Windows, Linux, Unix flavors, MacIntosh, VMS, OS2, and whatever else OSs Boost supports. The library itself won't care/know about all the systems. It would be up to the developer to provide a relevant template parameter that defines the required GUI/GDI traits (the traits for couple of the most popular systems could be included in the first distrubution). [...] Think of more complicated widgets which have been developed like tree views, page controls, list views, track bars, toolbars, edit controls, combo boxes, and many others. I don't think that there are too many standard widgets, just about 20. Add to this the fact that nearly every C++ programmer already works with a framework library depending on his implementation of choice. You could have made the same argument before STL was invented. Nearly every C++ programmer already worked with some sort of private containers/algorithms. The amount of code which must be written often becomes negligible by the programmer after the design time interfaces have been set up. It was not exactly my experience. The ammount of code just to manage the GUI states and data transfer between GUI structures and internal application reperesentations is huge. RAD and RAD-like tools for manipulation of a library entirely by code. Yes, it is not intended for RAD developers like VB forms and such. Finally many C++ programmers, being the creators that they are, have already invented C++ template-based mechanisms to use on top of the GUI/GDI ... programmers adopting your implementation as opposed to what they have already been using. Again, the same argument could have been made about building STL. 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] Proposal: BOOST_NO_TEMPLATED_STREAMS config macro and helpers
In adding output streaming support for variant, I've realized the
standard library packaged with gcc 2.9.7 and below does not support the
templated stream classes. I've also realized that Boost.Tuple features a
workaround addressing this same problem, with a comment to add a defect
macro to boost/config.hpp in the future.
Therefore, I think the time to add BOOST_NO_TEMPLATED_STREAMS is now.
I believe the test is as simple as follows, but I'll leave it up to
others who are more knowledgeable of the numerous streaming classes than
I:
#include iosfwd
using namespace std;
template typename E, typename T
void basic_ostream_check( basic_ostreamE,T );
template typename E, typename T
void basic_istream_check( basic_istreamE,T );
// ...and so on...
However, I believe this is only a partial solution. Even with
BOOST_NO_TEMPLATED_STREAMS appropriately defined, much is still left on
library implementors. Indeed, this can be seen in the redundancy of the
workarounds in boost/tuple/tuple_io.hpp.
I propose several helper macros to address this redundancy. I've added
the helper macros in the main CVS under
boost/detail/templated_streams.hpp and demonstrate their use in
boost/variant/detail/variant_io.hpp and in boost/empty.hpp.
I'd greatly appreciate input.
Thanks,
Eric
P.S. For those who do not have time to check my code in CVS, the basic
idea is that the macros can be used as in the following:
BOOST_TEMPLATED_STREAM_TEMPLATE(Elem,Traits)
inline BOOST_TEMPLATED_STREAM(ostream, Elem,Traits) operator(
BOOST_TEMPLATED_STREAM(ostream, Elem,Traits) out
, const my_class rhs
)
{
...
}
Or for class templates:
template
BOOST_TEMPLATED_STREAM_ARGS(Elem,Traits)
BOOST_TEMPLATED_STREAM_COMMA
typename T
inline BOOST_TEMPLATED_STREAM(ostream, Elem,Traits) operator(
BOOST_TEMPLATED_STREAM(ostream, Elem,Traits) out
, const my_class_templateT rhs
)
{
...
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_nan
En réponse à Gabriel Dos Reis [EMAIL PROTECTED]: [snip] | On a more general side, please keep in mind that *signaling* NaNs are meant to | trap when used (used can be a simple copy, the standard leaves it | implementation-defined). They trap only when operands of arithmetic operations. Please. When I wrote that it can be a simple copy and that it is implementation-defined, I meant it. Computer arithmetic is my everyday work; whenever possible, I try to avoid making things up. Here is an excerpt of paragraph 6.2 of IEEE 754 standard: Whether copying a signaling NaN without a change of format signals the invalid operation exception is the implementor's option.. | If the user suddenly decides to put a signaling NaN in | a floating-point variable, she shouldn't be surprised if the program traps as | soon as it uses this variable. I don't understand why the interval library | should prevent such a behavior, I'm not saying the interval library should prevent that behaviour. I'm syaing the interval arithmetic should not provide a trapping isnan function. That is a different matter. What don't you understand in the expression isnan is a private function? This trapping isnan function is *not* provided to the user, it is an internal function. It is only used inside interval arithmetic functions and it will make these functions trap if given a signaling NaN argument. Let's stop this discussion right now, it's going nowhere. I'm not arguing a general purpose isnan function should trap when given a signaling NaN, because it shouldn't. But in the particular case of the *internal* function of the interval library, it is the *expected* behavior. Unless you can give a single example where this behavior is not desirable for the users of the interval library, I won't try any further to justify why the function was written the way it is and not another way (and that was the reason that started this whole thread). Regards, Guillaume ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
