[boost] Re: [date_time] enabling microsec_clock under C++Builder
"Russell Hind" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Johan Nilsson wrote: > > > > Perhaps, but one should consider that GetSystemTime promises 1ms resolution > > and delivers 10-15ms (and, IIRC, that GetSystemTimeAsFileTime promises > > 250ns resolution). > > > > The Platform SDK states that the tickcount (GetTickCount) is updated > every 10ms on NT3.51 and hight so I guess that GetSystemTime is updated > at this interval also. That's correct for uniprocessor machines. It is normally 15ms on SMP machines (at least on NT 4.0 upwards). As I said earlier, my only experience is with x86 machines (and NT, not Win9x et al). > > FileTimes are measured in 100 nanosecond intervals since 1 January, > 1601, but are you sure that GetSystemTimeAsFileTime will return a value > that is updated at 250ns intervals? I can't find anything in the SDK to > say what the update interval is for the SystemTime, I'm just guessing > that it is updated when the tick count is. Sorry - just a case of bad memory - 100ns is of course correct. I am definitely sure that GetSystemTimeAsFileTime will _not_ return a value that is updated more frequently than the system's tick interval. I just wanted to point out the similarity between: - GSTAFT having a 100ns resolution but not being updated more often than 10-15ms - microsec_clock having a microsec resolution but not being updated more often than 10-15ms // Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
"Russell Hind" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Johan Nilsson wrote: > > > > Yes, but why not have both on all platforms? > > > > It would make using it cross-platform easier, but you aren't actually > getting microsecond information under windows, so if your program relies > on that detail, it won't work correctly under windows anyway, so you > must make your program work with millisecond times and you could then > just use your millisec_clock on both platforms. > > Basically, I both agree and disagree. I agree from the point of view of > using the library cross-platform, but disagree on the principle that > your using something that promises microsecond detail, but in fact is > only returning millisecond. (in my example anyway, if you could make > the microsecond stuff work from QPC then that would be fine) > Perhaps, but one should consider that GetSystemTime promises 1ms resolution and delivers 10-15ms (and, IIRC, that GetSystemTimeAsFileTime promises 250ns resolution). // Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
"Russell Hind" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Johan Nilsson wrote: > >> > >>Can these be used to get an actual date/time though? Or just for high > >>resolution timing? I've only had a brief look at them, so will read a > >>bit more. > >> > > > > > > Yes and yes. But the former (using them to get an actual date/time with a > > _low_ overhead) is ... well ... interesting ;-) > > > > How do you convert the tick count from QueryPerformanceCounter into a > date time then? I can't see how to do this? > In brief: get the value of QPC at the instance the system time changes. The devil is in the details, of course, but it's a good starting point. // Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
"Russell Hind" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Johan Nilsson wrote: > > > > I might be a bit off here (coming in late into the discussion), but I'd > > prefer consistency in my code; using microsec_clock for both Windows and > > Unix code - even if the real 'resolution' is dependent of the system time > > updates on the Win platforms. > > > > That is an option, but if a millisecond clock is introduced, it like to > see it implemented on all platforms, then you could use that on all > platforms rather than microsec_clock which isn't 'really' supported > under windows. At least this way you are dealing with a known resolution. > Yes, but why not have both on all platforms? // Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
"Russell Hind" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Alisdair Meredith wrote: > > Russell Hind wrote: > > > > > >>I agree with that. Would it be better to make it a millisec_clock, or > >>just use the microsec_clock but the resolution is only milliseconds? > > > > > > WinAPI Note: we can get a higher resolution using the > > QueryPerformanceCounter API (and QueryPerformanceFrequency if resolution > > info is required) > > > > Can these be used to get an actual date/time though? Or just for high > resolution timing? I've only had a brief look at them, so will read a > bit more. > Yes and yes. But the former (using them to get an actual date/time with a _low_ overhead) is ... well ... interesting ;-) // Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: [date_time] enabling microsec_clock under C++Builder
"Jeff Garland" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > I think this is a good addition, but we should probably make the > > > addition for all Win32 compilers since I think this is actually > > > part of the Win32 api. > > > > > > > I agree with that. Would it be better to make it a millisec_clock, or > > just use the microsec_clock but the resolution is only milliseconds? > > Hmm, I'm thinking that for consistency it would probably be better to > call it millisec_clock. Could be. I might be a bit off here (coming in late into the discussion), but I'd prefer consistency in my code; using microsec_clock for both Windows and Unix code - even if the real 'resolution' is dependent of the system time updates on the Win platforms. If you plan to timestamp events with low overhead, the easiest and fastest way to get the system time is GetSystemTimeAsFileTime (assuming you can defer the conversion from FILETIME to SYSTEMTIME until later). Just remember that you'll never (?) get more frequent updates of the system time than 10 or 15 (SMP system) milliseconds. Even though it is possible to affect the possible Sleep() resolution to get ~1 millisecond sleeps by using NtSetTimerResolution or multimedia timers, this doesn't seem to affect the system updates (I've never seen it update more often than the standard 10/15 ms even though I've tried). Anyone else got comments on that? I've got no experience on non-Intel or 64-bit Windows though. // Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: dynamic_void_cast
"Terje Slettebø" <[EMAIL PROTECTED]> wrote in message 082701c2a12f$15c74170$60fb5dd5@pc">news:082701c2a12f$15c74170$60fb5dd5@pc... > >From: "Eric Woodruff" <[EMAIL PROTECTED]> > > > "Johan Nilsson" <[EMAIL PROTECTED]> wrote in message > > at76e1$2ro$[EMAIL PROTECTED]">news:at76e1$2ro$[EMAIL PROTECTED]... > > > > Anyhow, in my opinion, dynamic_void_cast is completely unnecessary and > takes > > casts away the intent that it is _supposed_ to be a two step and very ugly > > process--the signifier that you have a not-so-good design on your hands. > > Stop trying to code a new messenger. > > As Bjarne Stroustrup says in D&E, "Don't fight the type system." You can't > win. :) Casting does indeed tend to be fighting the type system. Sure, you > can do it, but you may end up with switch-on-type code, etc., which, as he > said that some had said it, "has the elegance of C, combined with the > efficiency of Smalltalk." :) And even that was too nice, he said. > > I understand you (Johan) want to be able to have generic factories, but then > erasing the type is probably not the way to go, and as has been pointed out > in this thread, void * is type erasure. More or less the only safe thing you > can do with it, is to delete it. You can also cast it back to its original > type, but that requires that you know that type to begin with. It doesn't, > portably, have the possibility to cast to arbitrary type, as you've seen. I just found a thread called "more flexible any" in the ASPN archives, that at a first glance looks like something I could use. However I couldn't compile it under VC.NET. The post was a few months old, don't know what's happened since that. > > As you said it, even COM doesn't use void *, but IUnknown and > QueryInterface. > Well, all COM objects are required to implement IUnknown (which helps :) // Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: dynamic_void_cast
"Eric Woodruff" <[EMAIL PROTECTED]> wrote in message
at7kru$5v7$[EMAIL PROTECTED]">news:at7kru$5v7$[EMAIL PROTECTED]...
>
> "Johan Nilsson" <[EMAIL PROTECTED]> wrote in message
> at76e1$2ro$[EMAIL PROTECTED]">news:at76e1$2ro$[EMAIL PROTECTED]...
> >
> > "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message
> > at542o$2hq$[EMAIL PROTECTED]">news:at542o$2hq$[EMAIL PROTECTED]...
> > >
> > > "Johan Nilsson" <[EMAIL PROTECTED]> wrote in message
> > > at52vi$si6$[EMAIL PROTECTED]">news:at52vi$si6$[EMAIL PROTECTED]...
> > > [snip]
> > >
> > > > I'd like to be able to store references to objects of arbitrary
types
> in
> > a
> > > > homogenous collection, not requiring them to be derived from a
common
> > base
> > > > class. For COM users, that would be something like an "IUnknown in
the
> > > > context of standard C++". I suspect that boost::any might be
something
> > > > similar to what I need, but I just got that idea using void
pointers.
> > > >
> > >
> > > What's the point of that? I mean, with no interface to the types, you
> > can't
> > > do anything with these objects you're storing, not even delete them.
> > >
> >
> > If I can dynamically cast a void pointer to a polymorphic type, I can do
> > whatever I want to do.
> >
> > > You could also do:
> > >
> > > struct IHolder {
> > > virtual ~IHolder () {}
> > > };
> > >
> > > template
> > > class holder : public IHolder{
> > > public:
> > > holder (Object* const object);
> > > ~holder ();
> > > };
> > >
> > > It's always better to try and look for a real (type safe) solution
than
> > > playing around with type casting. It still depends on what you want to
> > _do_
> > > with theses objects behind this common, empty interface. I suspect
> > problems
> > > with your design if you have been led down this path.
> > >
> >
> > I _am_ looking for a type safe solution, I was simply playing around
> trying
> > to find one that would fit my needs.
> >
> > I'm actually experimenting with a kind of 'generic' object factory with
> the
> > following characteristics:
> >
>
> Well then void* is not what you need. Especially in your design, you may
> later decide that need to not only delete these objects in the factory,
but
> do other things with them as well.
>
I thought that was what I said, or, at least what I was trying to say?
> I think you need to reanalyze what your needs are and the important roles
in
> this system. It seems to be that there is more than one class necessary
> here.
I have not suggested otherwise. I simplified for the sake of illustration
(which obviously failed), and the domain-specific part has not even been
mentioned here. Anyway, I think this is definitely going out of scope for
this mailing list, so I suggest leaving the discussion.
>
> Anyhow, in my opinion, dynamic_void_cast is completely unnecessary and
takes
> casts away the intent that it is _supposed_ to be a two step and very ugly
> process--the signifier that you have a not-so-good design on your hands.
I'd rather have the possibility in the language to dynamic_cast all data
types (including built-ins).
> Stop trying to code a new messenger.
?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: dynamic_void_cast
"Eric Woodruff" <[EMAIL PROTECTED]> wrote in message
at542o$2hq$[EMAIL PROTECTED]">news:at542o$2hq$[EMAIL PROTECTED]...
>
> "Johan Nilsson" <[EMAIL PROTECTED]> wrote in message
> at52vi$si6$[EMAIL PROTECTED]">news:at52vi$si6$[EMAIL PROTECTED]...
> [snip]
>
> > I'd like to be able to store references to objects of arbitrary types in
a
> > homogenous collection, not requiring them to be derived from a common
base
> > class. For COM users, that would be something like an "IUnknown in the
> > context of standard C++". I suspect that boost::any might be something
> > similar to what I need, but I just got that idea using void pointers.
> >
>
> What's the point of that? I mean, with no interface to the types, you
can't
> do anything with these objects you're storing, not even delete them.
>
If I can dynamically cast a void pointer to a polymorphic type, I can do
whatever I want to do.
> You could also do:
>
> struct IHolder {
> virtual ~IHolder () {}
> };
>
> template
> class holder : public IHolder{
> public:
> holder (Object* const object);
> ~holder ();
> };
>
> It's always better to try and look for a real (type safe) solution than
> playing around with type casting. It still depends on what you want to
_do_
> with theses objects behind this common, empty interface. I suspect
problems
> with your design if you have been led down this path.
>
I _am_ looking for a type safe solution, I was simply playing around trying
to find one that would fit my needs.
I'm actually experimenting with a kind of 'generic' object factory with the
following characteristics:
1) Objects should be dynamically creatable from a textual description using
named parameters, e.g.:
"InputDevice = Type:MulticastSocket,Interface:0.0.0.0,Port:12345,...", _or_
InputDeviceMulticastSocket0.0.0
.0, _or_ whatever
2) Object creation if deferred until someone expliticly requests a reference
to them - 'lazy creation'
3) Later requests for the same object simply returns a reference to it -
_but_ the type need not be the same as the concrete type. Suppose the
MulticastSocket object implements the interfaces IStream, IAsyncStream,
INamedObject, etc. Clients should be able to do something like (fíctionary):
SharedPtr pStream =
ObjectManager::instance().get("InputDevice");
as well as
SharedPtr pNamedObject =
ObjectManager::instance().get("InputDevice");
(so who on earth would get a named object through an input device? Well,
forget it - the name of the object might be passed as a parameter itself -
it was just an example)
4) Named objects can be used as arguments to other objects.
-
1) is easy enough to implement through some parser + 'extendable' object
factory.
2-4) are harder. The lookup/'reference by name' part + lazy creation are
rather easy stuff. The ability to cast to an arbitraty polymorphic type is
harder. Maybe I could use some kind of 'holder' or modify boost::any, making
it a mixin instead, but then comes the problem of constructor parameters. I
specifically don't want to use a common base, unless I can do it
non-intrusively (if that's an english word).
Note that I only use this stuff during object creation, initialization and
reference resolving phase, and not during the actual program execution. Once
all objects are created and initalized, no further dynamic casting is
required. I've done something similar using COM a while ago, but there I had
the possibility to use IUnknown and QueryInterface.
// Johan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: dynamic_void_cast
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Johan Nilsson" <[EMAIL PROTECTED]> writes: > > > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > > > >> A rather lengthy example with no comments or explanatory text > >> describing what it's supposed to be accomplishing is not very easy to > >> analyze. If you want feedback from the group, it would be polite to > >> describe what you're trying to do. > >> > > > > I certainly wasn't being intentionally rude; apologies to anyone > > offended by my posting. > > Your posting wasn't exactly rude; it just asked for a lot more than it > probably should from your readers. > > > I just wanted to get some feedback on what I tried, and currently consider > > the stuff as a hack. But, as the functionality would be extremely helpful > > for object factories, I thought I might as well post the code and get some > > comments about it. The hack makes no 'fixed' assumptions on binary object > > layout, rather, it relies on the fact that any polymorphic type can be > > queried for an implemented interface (aka 'base class'). It does, however, > > make the assumption that the location of the rtti itself data is fixed for a > > specific c++ implementation across different polymorphic types. > > The quibble I have with all this, which you _still_ haven't satisfied, > is that you never said in simple terms what you're trying to > accomplish. A sentence as simple as, "I'm trying to dynamic cast from > an arbitrary void* to and arbitrary polymorphic object type" would > have sufficed. I came to this explanation after looking at your code > below again, and I'm still not sure that's what you're trying to do. > It just might be my english ... anyway, what you stated above pretty much describes what I was trying to say :). I'd like to be able to store references to objects of arbitrary types in a homogenous collection, not requiring them to be derived from a common base class. For COM users, that would be something like an "IUnknown in the context of standard C++". I suspect that boost::any might be something similar to what I need, but I just got that idea using void pointers. > Incidentally, shared_ptr may allow you the kind of type erasure > you want. Just a thought... > I' afraid I don't really follow you. Wouldn't shared_ptr choke on trying to delete through a void pointer? // Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: OpenVMS file name compatibility
"Iain K.Hanson" <[EMAIL PROTECTED]> wrote in message 000f01c2a039$91207a40$56011cac@ih1comp">news:000f01c2a039$91207a40$56011cac@ih1comp... > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of David Abrahams > > Sent: 06 December 2002 22:08 > > > > > > Do you know of specific problems we have? I would be a bit shocked if > > VMS incompatibilities hadn't crept into the bjam sources, for example. > > > > > The files below are incompatible with the VMS filesystem. The first period > needs to be changed to something else i.e underscore. > > /ikh > > boost/libs/array/array.hpp.html > boost/libs/array/array1.cpp.html > boost/libs/array/array2.cpp.html > boost/libs/array/array3.cpp.html > boost/libs/array/array4.cpp.html > boost/libs/array/array5.cpp.html > boost/libs/array/print.hpp.html > boost/libs/compose/compose.hpp.html > boost/libs/compose/compose1.cpp.html > boost/libs/compose/compose2.cpp.html > boost/libs/compose/compose3.cpp.html > boost/libs/compose/compose4.cpp.html > boost/libs/compose/print.hpp.html > boost/libs/preprocessor/doc/headers/arithmetic/add.hpp.html > boost/libs/preprocessor/doc/headers/arithmetic/dec.hpp.html > boost/libs/preprocessor/doc/headers/arithmetic/div.hpp.html > boost/libs/preprocessor/doc/headers/arithmetic/inc.hpp.html > boost/libs/preprocessor/doc/headers/arithmetic/mod.hpp.html > boost/libs/preprocessor/doc/headers/arithmetic/mul.hpp.html > boost/libs/preprocessor/doc/headers/arithmetic/sub.hpp.html > boost/libs/preprocessor/doc/headers/arithmetic.hpp.html > boost/libs/preprocessor/doc/headers/array/data.hpp.html > boost/libs/preprocessor/doc/headers/array/elem.hpp.html > boost/libs/preprocessor/doc/headers/array/insert.hpp.html > boost/libs/preprocessor/doc/headers/array/pop_back.hpp.html > boost/libs/preprocessor/doc/headers/array/pop_front.hpp.html > boost/libs/preprocessor/doc/headers/array/push_back.hpp.html > boost/libs/preprocessor/doc/headers/array/push_front.hpp.html > boost/libs/preprocessor/doc/headers/array/remove.hpp.html > boost/libs/preprocessor/doc/headers/array/replace.hpp.html > boost/libs/preprocessor/doc/headers/array/reverse.hpp.html > boost/libs/preprocessor/doc/headers/array/size.hpp.html > boost/libs/preprocessor/doc/headers/array.hpp.html > boost/libs/preprocessor/doc/headers/assert_msg.hpp.html > boost/libs/preprocessor/doc/headers/cat.hpp.html > boost/libs/preprocessor/doc/headers/comma.hpp.html > boost/libs/preprocessor/doc/headers/comma_if.hpp.html > boost/libs/preprocessor/doc/headers/comparison/equal.hpp.html > boost/libs/preprocessor/doc/headers/comparison/greater.hpp.html > boost/libs/preprocessor/doc/headers/comparison/greater_equal.hpp.html > boost/libs/preprocessor/doc/headers/comparison/less.hpp.html > boost/libs/preprocessor/doc/headers/comparison/less_equal.hpp.html > boost/libs/preprocessor/doc/headers/comparison/not_equal.hpp.html > boost/libs/preprocessor/doc/headers/comparison.hpp.html > boost/libs/preprocessor/doc/headers/config/limits.hpp.html > boost/libs/preprocessor/doc/headers/control/deduce_d.hpp.html > boost/libs/preprocessor/doc/headers/control/expr_if.hpp.html > boost/libs/preprocessor/doc/headers/control/expr_iif.hpp.html > boost/libs/preprocessor/doc/headers/control/if.hpp.html > boost/libs/preprocessor/doc/headers/control/iif.hpp.html > boost/libs/preprocessor/doc/headers/control/while.hpp.html > boost/libs/preprocessor/doc/headers/control.hpp.html > boost/libs/preprocessor/doc/headers/debug/assert.hpp.html > boost/libs/preprocessor/doc/headers/debug/line.hpp.html > boost/libs/preprocessor/doc/headers/debug.hpp.html > boost/libs/preprocessor/doc/headers/dec.hpp.html > boost/libs/preprocessor/doc/headers/empty.hpp.html > boost/libs/preprocessor/doc/headers/enum.hpp.html > boost/libs/preprocessor/doc/headers/enum_params.hpp.html > boost/libs/preprocessor/doc/headers/enum_params_with_a_default.hpp.html > boost/libs/preprocessor/doc/headers/enum_params_with_defaults.hpp.html > boost/libs/preprocessor/doc/headers/enum_shifted.hpp.html > boost/libs/preprocessor/doc/headers/enum_shifted_params.hpp.html > boost/libs/preprocessor/doc/headers/expand.hpp.html > boost/libs/preprocessor/doc/headers/expr_if.hpp.html > boost/libs/preprocessor/doc/headers/facilities/apply.hpp.html > boost/libs/preprocessor/doc/headers/facilities/empty.hpp.html > boost/libs/preprocessor/doc/headers/facilities/expand.hpp.html > boost/libs/preprocessor/doc/headers/facilities/identity.hpp.html > boost/libs/preprocessor/doc/headers/facilities/intercept.hpp.html > boost/libs/preprocessor/doc/headers/facilities.hpp.html > boost/libs/preprocessor/doc/headers/for.hpp.html > boost/libs/preprocessor/doc/headers/identity.hpp.html > boost/libs/preprocessor/doc/headers/if.hpp.html > boost/libs/preprocessor/doc/headers/inc.hpp.html > boost/libs/preprocessor/doc/headers/iterate.hpp.html > boost/libs/preprocessor/doc/headers/iteration/iterate.hpp.html > boost/libs/preprocessor/doc/headers/iteration/local.hpp.html > boost/libs/preprocessor/doc/headers/iteration/self.hpp.htm
[boost] Re: Re: dynamic_void_cast
[inlined]
"Terje Slettebø" <[EMAIL PROTECTED]> wrote in message
011401c2a057$f404cf30$60fb5dd5@pc">news:011401c2a057$f404cf30$60fb5dd5@pc...
> >From: "Peter Dimov" <[EMAIL PROTECTED]>
>
> > From: "Johan Nilsson" <[EMAIL PROTECTED]>
> > >
> > > "Peter Dimov" <[EMAIL PROTECTED]> wrote in message
> > > 00bb01c2a046$671b1c20$1d00a8c0@pdimov2">news:00bb01c2a046$671b1c20$1d00a8c0@pdimov2...
> > > > From: "Johan Nilsson" <[EMAIL PROTECTED]>
> > > > [...]
> > > > > template
> > > > > T* dynamic_void_cast(void* pv)
> > > > > {
> > > > > struct rtti_obj__
> > > > > {
> > > > > virtual ~rtti_obj__() = 0;
> > > > > };
> > > > >
> > > > > rtti_obj__* pro = static_cast(pv);
> > > > >
> > > > > try
> > > > > {
> > > > > return dynamic_cast(pro);
> > > > > }
> > > >
> > > > This is not required to work. T's vtable pointer is not guaranteed
to
> be
> > > at
> > > > offset 0.
> >
> > Actually I meant *pv's vtable pointer here.
> >
> > > But I thought that it _might_ be required to be at the same offset for
T
> > as
> > > for rtti_obj. For that part, IIRC, a vtable isn't required at all, or?
> >
> > Try it (on several compilers, as some do put the vptr at offset 0.)
> >
> > struct X { int n; };
> > struct Y: public X { virtual ~Y() {} };
> >
> > Y+0: X::n
> > Y+4: vptr
> >
> > rtti_obj__+0: vptr
>
> I've tested it. Test code:
>
> --- Start ---
>
> struct X { int n; };
> struct Y: public X { public: virtual ~Y() {} };
>
> int main()
> {
> Y y;
>
> Y *yptr=dynamic_void_cast(&y);
> }
>
> --- End ---
>
> Here are the results:
>
> MSVC 6 - vptr at 0 - It works
> Intel C++ 7.0 - vptr at 0 - It works
> g++ 2.95.3 - vptr _not_ at zero - boom! :) It gives an OS protection error
> at the point of dynamic_cast
> BCB 6 - vptr _not_ at zero - boom! :) It gives an OS protection error at
the
> point of dynamic_cast
>
I'd appreciate if you could try to (1) use this instead:
Y *yptr=dynamic_void_cast(static_cast(&y));
and (2) add a virtual destructor to X. What are the results?
> Conclusion: Not recommended. :)
>
> Besides, I can't see the point in testing for bad_cast there, since it
uses
> T * (not T) in the dynamic_cast, which I think would never throw bad_cast.
How true, it was just plain ignorance from my side.
> This also means that its signature is different from dynamic_cast, and
that
> it therefore can't be used for casting references (unlike dynamic_cast).
>
That was because I couldn't imagine a 'void&', or did I miss something?
> In any case, this means it is inherently implementation-dependent and
> unsafe.
>
Basically what I suspected, thanks for taking the time.
// Johan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: dynamic_void_cast
"Terje Slettebø" <[EMAIL PROTECTED]> wrote in message
00e001c2a04e$92f9c190$60fb5dd5@pc">news:00e001c2a04e$92f9c190$60fb5dd5@pc...
> >From: "Johan Nilsson" <[EMAIL PROTECTED]>
>
>
> > The hack makes no 'fixed' assumptions on binary object
> > layout, rather, it relies on the fact that any polymorphic type can be
> > queried for an implemented interface (aka 'base class'). It does,
however,
> > make the assumption that the location of the rtti itself data is fixed
for
> a
> > specific c++ implementation across different polymorphic types.
> >
> > Sample usage (demonstrating syntax only):
> > --
> >
> > void foo(void*)
> > {
> > try
> > {
> > IMyBaseClass* pmc = dynamic_void_cast(pv);
> >
> > if (pmc)
> >{
> > pmc-MyFn();
> > }
> > }
> > catch (std::exception&)
> > {}
> > }
> >
> >
> > The hack:
> > --
> > template
> > T* dynamic_void_cast(void* pv)
> > {
> > struct rtti_obj__
> > {
> > virtual ~rtti_obj__() = 0;
> > };
> >
> > rtti_obj__* pro = static_cast(pv);
> >
> > try
> > {
> > return dynamic_cast(pro);
> > }
> > catch (bad_cast&)
> > {
> > throw;
> > }
> > catch (exception& e)
> > {
> > throw bad_cast(e.what());
> > }
> > }
> >
> > --
>
> Why do you catch, and just rethrow exceptions? Why not just let them
> propagate (no try/catch), or turning them into return zero? Also, what
other
> exception, besides bad_cast, can dynamic_cast throw, which necessitates
the
> second catch clause?
This is rather platform specific, but in VC.NET, you can get the exception
__non_rtti_object (which is derived from bad_typeid)thrown as well. I
preferred throwing bad_cast exceptions only.
// Johan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dynamic_void_cast
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
00bb01c2a046$671b1c20$1d00a8c0@pdimov2">news:00bb01c2a046$671b1c20$1d00a8c0@pdimov2...
> From: "Johan Nilsson" <[EMAIL PROTECTED]>
> [...]
> > template
> > T* dynamic_void_cast(void* pv)
> > {
> > struct rtti_obj__
> > {
> > virtual ~rtti_obj__() = 0;
> > };
> >
> > rtti_obj__* pro = static_cast(pv);
> >
> > try
> > {
> > return dynamic_cast(pro);
> > }
>
> This is not required to work. T's vtable pointer is not guaranteed to be
at
> offset 0.
>
But I thought that it _might_ be required to be at the same offset for T as
for rtti_obj. For that part, IIRC, a vtable isn't required at all, or?
// Johan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dynamic_void_cast
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Johan Nilsson" <[EMAIL PROTECTED]> writes:
>
> > [I've tried posting this to c.l.c++.m, but to no success. Don't know if
it's
> > due to some of the assert code looking like html markup ;-) or whatever.
> > Anyway, I thought this might also be a good forum.]
>
> Does this have something to do with C++ library writing? If so,
> please say what. If not, it's not an appropriate forum.
Yes, at least I hope so. See comments below.
[snip]
>
> A rather lengthy example with no comments or explanatory text
> describing what it's supposed to be accomplishing is not very easy to
> analyze. If you want feedback from the group, it would be polite to
> describe what you're trying to do.
>
I certainly wasn't being intentionally rude; apologies to anyone offended by
my posting.
I just wanted to get some feedback on what I tried, and currently consider
the stuff as a hack. But, as the functionality would be extremely helpful
for object factories, I thought I might as well post the code and get some
comments about it. The hack makes no 'fixed' assumptions on binary object
layout, rather, it relies on the fact that any polymorphic type can be
queried for an implemented interface (aka 'base class'). It does, however,
make the assumption that the location of the rtti itself data is fixed for a
specific c++ implementation across different polymorphic types.
Sample usage (demonstrating syntax only):
--
void foo(void*)
{
try
{
IMyBaseClass* pmc = dynamic_void_cast(pv);
if (pmc)
{
pmc-MyFn();
}
}
catch (std::exception&)
{}
}
The hack:
--
template
T* dynamic_void_cast(void* pv)
{
struct rtti_obj__
{
virtual ~rtti_obj__() = 0;
};
rtti_obj__* pro = static_cast(pv);
try
{
return dynamic_cast(pro);
}
catch (bad_cast&)
{
throw;
}
catch (exception& e)
{
throw bad_cast(e.what());
}
}
--
I'll put together a sample showing some more concrete usage, this is more
something of an apologetic sample ;-)
// Johan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] dynamic_void_cast
[I've tried posting this to c.l.c++.m, but to no success. Don't know if it's
due to some of the assert code looking like html markup ;-) or whatever.
Anyway, I thought this might also be a good forum.]
Hi,
this is an experiment I just tried out. I've only tried it with VC7, and it
doesn't work with virtual base classes, but I'd be still interested in
hearing your comments.
Sorry about the rather lengthy example.
// Johan
---
main.cpp
---
#include
#include
#include
using namespace std;
struct Something
{
virtual const type_info& id() { return typeid(*this); }
};
struct AnotherThing
{
virtual const type_info& id() { return typeid(*this); }
};
struct YetAnotherThing : public AnotherThing
{
virtual void useless() {}
};
struct MiThing : public Something, public YetAnotherThing
{
virtual void worthless() {}
};
template
T* dynamic_void_cast(void* pv)
{
struct rtti_obj__
{
virtual ~rtti_obj__() = 0;
};
rtti_obj__* pro = static_cast(pv);
try
{
return dynamic_cast(pro);
}
catch (bad_cast&)
{
throw;
}
catch (exception& e)
{
throw bad_cast(e.what());
}
}
template
void* void_cast(T* pT)
{
return static_cast(pT);
}
int main()
{
//
// Test successful casts
//
Something something;
assert(0 != dynamic_void_cast(void_cast(&something)));
assert(typeid(something) ==
dynamic_void_cast(void_cast(&something))->id());
assert(typeid(something) ==
typeid(*dynamic_void_cast(void_cast(&something;
AnotherThing another;
assert(0 != dynamic_void_cast(void_cast(&another)));
assert(typeid(another) ==
dynamic_void_cast(void_cast(&another))->id());
assert(typeid(another) ==
typeid(*dynamic_void_cast(void_cast(&another;
YetAnotherThing yetAnother;
assert(0 != dynamic_void_cast(void_cast(&yetAnother)));
assert(0 != dynamic_void_cast(void_cast(&yetAnother)));
assert(typeid(yetAnother) ==
dynamic_void_cast(void_cast(&yetAnother))->id());
assert(typeid(yetAnother) ==
typeid(*dynamic_void_cast(void_cast(&yetAnother;
MiThing mi;
assert(0 != dynamic_void_cast(void_cast(&mi)));
assert(0 != dynamic_void_cast(void_cast(&mi)));
assert(0 != dynamic_void_cast(void_cast(&mi)));
assert(0 != dynamic_void_cast(void_cast(&mi)));
assert(typeid(mi) ==
dynamic_void_cast(void_cast(&mi))->id());
assert(typeid(mi) ==
typeid(*dynamic_void_cast(void_cast(&mi;
//
// Test expected failures
//
assert(0 == dynamic_void_cast(&another));
assert(0 == dynamic_void_cast(&something));
//
// Test 'sub-object' pointers differ
//
Something* pSome = dynamic_void_cast(void_cast(&mi));
AnotherThing* pAnother = dynamic_void_cast(void_cast(&mi));
assert(void_cast(pSome) != void_cast(pAnother));
return 0;
}
---
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: OpenVMS file name compatibility
"David Abrahams" <[EMAIL PROTECTED]> skrev i meddelandet
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Johan Nilsson" <[EMAIL PROTECTED]> writes:
>
> > [cross-posted, but it seemed appropriate]
> >
> > Hi,
> >
> > just wanted to bring this one up: I've come across some problems putting
> > boost source to an OpenVMS system: Filenames cannot include more than
one
> > dot ('.') - i.e. names like .cpp.html aren't allowed. The only
> > exception is (naturally) in directory specifications, e.g:
> > DISK$USER:[DIR.SUBDIR.ANOTHER_SUBDIR].
> >
> > I do realize that VMS platforms might not be of highest priority, but it
> > sure would be nice to be compatible. And, one never knows, when(ever)
the
> > IA64 OpenVMS port is completed we might have a revival ;-)
> >
> > [... and I've not even been able to start _building_ the boost libraries
> > yet - I guess I'll be in for a whole lot more of problems then ...]
>
> Johan,
>
> Do you know of specific problems we have? I would be a bit shocked if
> VMS incompatibilities hadn't crept into the bjam sources, for example.
>
Haven't got that far yet. I 've just recently managed to bootstrap bjam, but
haven't had the time to actually use/test it. Boost.thread is one thing I've
been planning to use, but that's probably not going to be realized until
next year. As you say, I would also be a bit surprised if there didn't exist
any VMS incompatibilities - I've been using classic jam for a while, and
even with that one there was a problem with the dependency checking / header
scanning stuff.
I'll get back to the list once I've got something more specific. This is
unfortunately on a pretty low priority right now, and I haven't got VMS at
home ;-). It is, however, in my own interest to put in some work for VMS
compatibility.
// Johan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Static lookup
"Rozental, Gennadiy" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > If anyone interested I have more generic solution, that
> > includes both
[...snip...]
> namespace mapping {
> template
> class fixed_sized;
>
> // constructed by Key1,Value1,Key2,Value2 ... list plus "invalid value"
>
> template
> class dynamic;
>
> // constrcted by "invalid_value"
>
"invalid_value" ... is what / defined how?
> };
>
> mapping::fixed_sized test_mapping1(
> "Key1", 1,
> "Key2", 2,
> "QWE", 3,
> 0
> );
>
> mapping::dyanamic test_mapping2(
> "Key1", 1,
> "Key2", 2,
> "QWE", 3,
> 0
> );
What would the actual signature of the constructor be in this case?
>
> mapping::dynamic test_mapping3( 0 );
> test_mapping3.add( "Key1", 1 );
> test_mapping3.add( "Key2", 2 );
> test_mapping3.add( "QWE" , 3 );
>
> Usage:
> test_mapping1["Key1"]
> test_mapping2["Key2"]
> test_mapping3["QWE"]
>
And reverse lookup? Does it require another template instantiation with the
first two parameters defined in reverse order, or is it included through
operator [] overloading, or ...?
// Johan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] OpenVMS file name compatibility
[cross-posted, but it seemed appropriate]
Hi,
just wanted to bring this one up: I've come across some problems putting
boost source to an OpenVMS system: Filenames cannot include more than one
dot ('.') - i.e. names like .cpp.html aren't allowed. The only
exception is (naturally) in directory specifications, e.g:
DISK$USER:[DIR.SUBDIR.ANOTHER_SUBDIR].
I do realize that VMS platforms might not be of highest priority, but it
sure would be nice to be compatible. And, one never knows, when(ever) the
IA64 OpenVMS port is completed we might have a revival ;-)
[... and I've not even been able to start _building_ the boost libraries
yet - I guess I'll be in for a whole lot more of problems then ...]
Regards // Johan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Static lookup
"Gennadiy Rozental" <[EMAIL PROTECTED]> wrote in message askekp$fm9$[EMAIL PROTECTED]">news:askekp$fm9$[EMAIL PROTECTED]... > "Johan Nilsson" <[EMAIL PROTECTED]> wrote in message > askatu$v5u$[EMAIL PROTECTED]">news:askatu$v5u$[EMAIL PROTECTED]... > > Well, > > [snip] > If anyone interested I have more generic solution, that includes both > fixed/pseudo-dynamic versions with the same interface and policy template > parameter managing search algorithms (if/else based,slist based linear > search,map based, array+lower_bound based). BTW it appears that array in > many cases does outperform map as Matt Austern states. > '... pseudo-dynamic ...' ? What's the syntax for declaring and using the table (or whatever you may call it)? // Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Static lookup
Well,
if anyone's interested, tell me. This version simply implements a linear
search, but for me this has been sufficient as I generally only got so many
items in a table. Also, it only works for a one-to-one mapping (in both
directions).
// Johan
"David B. Held" <[EMAIL PROTECTED]> wrote in message
asg0jo$mf4$[EMAIL PROTECTED]">news:asg0jo$mf4$[EMAIL PROTECTED]...
> "Johan Nilsson" <[EMAIL PROTECTED]> wrote in message
> asf9bt$7g6$[EMAIL PROTECTED]">news:asf9bt$7g6$[EMAIL PROTECTED]...
> > [...]
> > enum Colors
> > {
> > Red = 1,
> > Blue = 2
> > };
> >
> > struct ColorTable
> > : public StaticLookupTable
> > {
> > LOOKUP_TABLE_BEGIN()
> > LOOKUP_ENTRY(Red, "Red")
> > LOOKUP_ENTRY(Blue, "Blue")
> > LOOKUP_TABLE_END()
> > };
> > [...]
>
> This looks like something that could/should go into a smart enum library.
> The ability to map strings to enums seems common enough (and is just as
> important to me as iterating over an enum type).
>
> Dave
>
>
>
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Static lookup
Sorry - the expression 'compile-time' below is (of course) a misnomer as the
table is implemented as a static array declared inside a static function.
What I meant to say is that you declare the contents of the table together
with the table definition, and that its contents are then fixed at run-time.
// Johan
"Johan Nilsson" <[EMAIL PROTECTED]> wrote in message
asf9bt$7g6$[EMAIL PROTECTED]">news:asf9bt$7g6$[EMAIL PROTECTED]...
> Hi,
>
> I've been implementing some kind of compile-time initialized lookup table,
> but it suddenly struck me: are there already similar functionality
available
> in boost? See attached sample code below.
>
> // Johan
>
> ---
> #incude
> #include
> #include
> #include "StaticLookupTable.h"
>
> enum Colors
> {
> Red = 1,
> Blue = 2
> };
>
> struct ColorTable
> : public StaticLookupTable
> {
> LOOKUP_TABLE_BEGIN()
> LOOKUP_ENTRY(Red, "Red")
> LOOKUP_ENTRY(Blue, "Blue")
> LOOKUP_TABLE_END()
> };
>
> int main()
> {
> assert("Red" == ColorTable::Lookup(Red));
> assert(Blue == ColorTable::ReverseLookup("Blue"));
>
> try
> {
> ColorTable::Lookup(static_cast(7));
> assert(!"Lookup of invalid color succeeded");
> }
> catch(std::range_error&)
> {
> }
>
> return 0;
> }
>
>
>
>
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Static lookup
Hi,
I've been implementing some kind of compile-time initialized lookup table,
but it suddenly struck me: are there already similar functionality available
in boost? See attached sample code below.
// Johan
---
#incude
#include
#include
#include "StaticLookupTable.h"
enum Colors
{
Red = 1,
Blue = 2
};
struct ColorTable
: public StaticLookupTable
{
LOOKUP_TABLE_BEGIN()
LOOKUP_ENTRY(Red, "Red")
LOOKUP_ENTRY(Blue, "Blue")
LOOKUP_TABLE_END()
};
int main()
{
assert("Red" == ColorTable::Lookup(Red));
assert(Blue == ColorTable::ReverseLookup("Blue"));
try
{
ColorTable::Lookup(static_cast(7));
assert(!"Lookup of invalid color succeeded");
}
catch(std::range_error&)
{
}
return 0;
}
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Socket Multiplexing
"Michel André" <[EMAIL PROTECTED]> wrote in message 0dde01c29700$f6cd7790$a400a8c0@orbit">news:0dde01c29700$f6cd7790$a400a8c0@orbit... > > I have not used async io, so I am a little out of my depth here. If we > > were to create an interface that could be implemented using select or > > aio what design constraints would that impose? > > > > I am guessing the callbacks would be free threaded. Is that right? > [big snip] > Therefore I think that an async io package will be a new addition to the > socket library or a completely new library. I don't even now if its possible > to implement async aio in a consistent manor on all platforms (or at least > sufficient number) that is of interest to boost, but it could be simulated > via another multiplex mechanism and threads I guess. OTOH, if we're discussing i/o in general - there are several platforms that doesn't directly support multiplexing on other devices than sockets, as NT/VMS (and the actual implementation in these cases are beyond my knowledge). Implementing async i/o in terms of multiplexing should be easier than the opposite way around, if the latter is even possible. > > And yes the callbacks should be free threaded, since if several threads is > picking completions of the completion queue notifications will come on any > of those threads. _If_ callbacks are used. Async i/o and callbacks are not necessarily associated with each other (but maybe the discussion was just in the context of callbacks, I came in pretty late). And even if callbacks are used in the library to emulate async i/o, the user needn't be notified in a free-threaded fashion (e.g. the aio_xxx implementation under linux). Just my $0.02. / Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Socket Multiplexing
>"Darryl Green" <[EMAIL PROTECTED]> skrev i meddelandet >[EMAIL PROTECTED]">news:[EMAIL PROTECTED] ... [snip] > Note man says "regular files" - there are lots of interesting special files that don't always > report ready - I/O devices, pipes etc. Also, I think it would be a bad idea to assume > that select is the be all and end all of how the socket/file/whatever ready to handler > dispatching can be implemented. It ought to be possible to replace a select based > dispatcher with one based on async I/O or some other exotic scheme. Just adding some comments here. Being able to queue _true_ async read/writes on multiple devices (socket, files, serial devices, pipes, ...), and then wait for any of them to complete has been absolutely essential to me - much, much more than non-blocking (which I personally don't like at all), and also more than multiplexing (select). That's probably why I'm not doing linux programming if I can avoid it (no flames please). I started out to implement cross-platform async I/O for NT/linux/VMS, and got a bit on the way before having to drop the multiplatform support (at least currently) due to resource limitations (time, mostly). Anyway, one can always fake async i/o on linux using i/o multiplexing. I also made some attempts on using libaio, but it didn't seem very mature at the time - maybe one will have to wait for kernel aio support. Under VMS as well as under NT, the i/o subsystems are designed as asynchronous, so there are less work there (even though VMS I/O is not as 'polymorhic' as NT's). Regards // Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
