creating a shared_ptr<T> from a weak_ptr<T>
When creating a shared_ptr<T> from a weak_ptr<T>, I want the shared_ptr<T> to use the same count as the shared_ptr the weak_ptr was constructed from. I could create a new shared_ptr, based on the pointer I can get() from the weak_ptr. But in this case, this shared_ptr will keep its own count. Let me fill you in on my use-case. An object creates some big data-structure on request of its clients, taking into account some options specified by the client while making the request. Now I'd like the server-object to keep a weak_ptr to these big data-structure to provide quickly the same result once another client performs an identical request. The server should however not keep a shared_ptr because otherwise all datastructure will stay in memory. And therefor I need to create a shared_ptr from a weak_ptr. thanks, toon
From: "Toon Knapen" <toon.knapen@si-lab.org>
When creating a shared_ptr<T> from a weak_ptr<T>, I want the shared_ptr<T> to use the same count as the shared_ptr the weak_ptr was constructed from.
The CVS shared_ptr has a constructor that takes a weak_ptr and will attach to the original count (or throw an exception if this isn't possible, as the object has already been deallocated.)
Query regarding the use/limitiations of traits in metaprogramming I am trying to use traits pattern to assist in metaprogramming. I have the following problem. A traits class "trait" defers a decision to another traits class "trait1" depending on the result of a third traits class "traita". However, the compiler does not cooperate. The code below excutes but gives unexpected output (also shown). [Note:: The code has been reduced to the minimal to demonstrate the problem. I have a real task at hand not shown here.] template <class T> struct traita { BOOST_STATIC_CONSTANT(int, value=0); }; template <> struct traita<int> { BOOST_STATIC_CONSTANT(int, value=1); }; template <class T, int> struct trait1 {}; template <class T> struct trait { BOOST_STATIC_CONSTANT(int, value=traita<T>::value); typedef trait1<T, value> t1; }; int main(int argc, char* argv[]) { std::cout << typeid(trait<int>::t1).name() << std::endl << trait<int>::value << std::endl ; return 0; } output:: trait1<int,0> 1 It would be nice if the first line of output were "trait1<int, 1>", but it isn't. Any assistance would be greatly appreciated. Craig Hicks
--- hicks <hicks@kgk.co.jp> wrote:
Query regarding the use/limitiations of traits in metaprogramming
I am trying to use traits pattern to assist in metaprogramming. I have the following problem.
A traits class "trait" defers a decision to another traits class "trait1" depending on the result of a third traits class "traita". However, the compiler does not cooperate. The code below excutes but gives unexpected output (also shown).
[Note:: The code has been reduced to the minimal to demonstrate the problem. I have a real task at hand not shown here.]
template <class T> struct traita { BOOST_STATIC_CONSTANT(int, value=0); }; template <> struct traita<int> { BOOST_STATIC_CONSTANT(int, value=1); };
template <class T, int> struct trait1 {};
template <class T> struct trait { BOOST_STATIC_CONSTANT(int, value=traita<T>::value); typedef trait1<T, value> t1; };
int main(int argc, char* argv[]) { std::cout << typeid(trait<int>::t1).name() << std::endl << trait<int>::value << std::endl ; return 0; }
output::
trait1<int,0> 1
It would be nice if the first line of output were "trait1<int, 1>", but it isn't.
Any assistance would be greatly appreciated.
I have some questions for you: 1. Why are you so interested in the value of "typeid.name()"? 2. Are you sure this isn't a compiler problem? What compiler(s) have you tried this on? Noel __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
Hello
I have some questions for you: 1. Why are you so interested in the value of "typeid.name()"?
I'm not particulary interested in typeid::name() as an end result. As I said in the letter, I have real task at hand, and condensed the code so that anybody looking at it would be able to get to the point quickly. I used typeid()::name() here as a means of demonstating the problem. The result which is shown by typeid()::name() corresponds to the result encountered in the real task, namely, the next stage of processing is supposed to take place in traits1<int, 1> but takes place in traits1<int, 0> instead. In other words, the branching mechanism fails silently.
2. Are you sure this isn't a compiler problem? What compiler(s) have you tried this on?
Borland Builder C++ 5. Unfortunately, it's the only one to which I have access now. It could well be a compiler problem. Unless there are some rules which I don't understand. If it is a compiler problem perhaps someone knows of a workaround. I have tried various approaches to no avail. Craig Hicks Noel Yap wrote:
--- hicks <hicks@kgk.co.jp> <mailto:hicks@kgk.co.jp> wrote:
Query regarding the use/limitiations of traits in metaprogramming
I am trying to use traits pattern to assist in metaprogramming. I have the following problem.
A traits class "trait" defers a decision to another traits class "trait1" depending on the result of a third traits class "traita". However, the compiler does not cooperate. The code below excutes but gives unexpected output (also shown).
[Note:: The code has been reduced to the minimal to demonstrate the problem. I have a real task at hand not shown here.]
template <class T> struct traita { BOOST_STATIC_CONSTANT(int, value=0); }; template <> struct traita<int> { BOOST_STATIC_CONSTANT(int, value=1); };
template <class T, int> struct trait1 {};
template <class T> struct trait { BOOST_STATIC_CONSTANT(int, value=traita<T>::value); typedef trait1< ;T, value> t1; };
int main(int argc, char* argv[]) { std::cout << typeid(trait<int>::t1).name() << std::endl << trait<int>::value << std::endl ; return 0; }
output::
trait1<int,0> 1
It would be nice if the first line of output were "trait1<int, 1>", but it isn't.
Any assistance would be greatly appreciated.
I have some questions for you: 1. Why are you so interested in the value of "typeid.name()"? 2. Are you sure this isn't a compiler problem? What compiler(s) have you tried this on?
Noel
__________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[Non-text portions of this message have been removed]
It looks like it's working find with gcc-2.95.3-5. One thing, though, it gave me a compiler error when I didn't #include <typeinfo>. Since you didn't list which header files you're including, I'm not sure if you're including <typeinfo> or not and what the Borland's behaviour would be if you didn't. Noel --- hicks <hicks@kgk.co.jp> wrote:
Hello
I have some questions for you: 1. Why are you so interested in the value of "typeid.name()"?
I'm not particulary interested in typeid::name() as an end result. As I said in the letter, I have real task at hand, and condensed the code so that anybody looking at it would be able to get to the point quickly. I used typeid()::name() here as a means of demonstating the problem. The result which is shown by typeid()::name() corresponds to the result encountered in the real task, namely, the next stage of processing is supposed to take place in traits1<int, 1> but takes place in traits1<int, 0> instead. In other words, the branching mechanism fails silently.
2. Are you sure this isn't a compiler problem? What compiler(s) have you tried this on?
Borland Builder C++ 5. Unfortunately, it's the only one to which I have access now. It could well be a compiler problem. Unless there are some rules which I don't understand. If it is a compiler problem perhaps someone knows of a workaround. I have tried various approaches to no avail.
Craig Hicks
Noel Yap wrote:
--- hicks <hicks@kgk.co.jp> <mailto:hicks@kgk.co.jp> wrote:
Query regarding the use/limitiations of traits in metaprogramming
I am trying to use traits pattern to assist in metaprogramming. I have the following problem.
A traits class "trait" defers a decision to another traits class "trait1" depending on the result of a third traits class "traita". However, the compiler does not cooperate. The code below excutes but gives unexpected output (also shown).
[Note:: The code has been reduced to the minimal to demonstrate the problem. I have a real task at hand not shown here.]
template <class T> struct traita { BOOST_STATIC_CONSTANT(int, value=0); }; template <> struct traita<int> { BOOST_STATIC_CONSTANT(int, value=1); };
template <class T, int> struct trait1 {};
template <class T> struct trait { BOOST_STATIC_CONSTANT(int, value=traita<T>::value); typedef trait1< ;T, value> t1; };
int main(int argc, char* argv[]) { std::cout << typeid(trait<int>::t1).name() << std::endl << trait<int>::value << std::endl ; return 0; }
output::
trait1<int,0> 1
It would be nice if the first line of output were "trait1<int, 1>", but it isn't.
Any assistance would be greatly appreciated.
I have some questions for you: 1. Why are you so interested in the value of "typeid.name()"? 2. Are you sure this isn't a compiler problem? What compiler(s) have you tried this on?
Noel
__________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
Info: <http://www.boost.org> Wiki:
<http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[Non-text portions of this message have been removed]
------------------------ Yahoo! Groups Sponsor
Info: <http://www.boost.org> Wiki:
<http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
__________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
The following works as desired in CBuilder C++ 6.0: As you have discovered, Borland has a hard time with compile-time constants used in template parameters. #include <typeinfo> #include <iostream> #include "boost/config.hpp" template <class T> struct traita { BOOST_STATIC_CONSTANT(int, value=0); }; template <> struct traita<int> { BOOST_STATIC_CONSTANT(int, value=1); }; template <class T, int> struct trait1 {}; template <class T> struct trait { BOOST_STATIC_CONSTANT(int, value=traita<T>::value); typedef trait1<T, (traita<T>::value)> t1; }; int main(int argc, char* argv[]) { std::cout << typeid(trait<int>::t1).name() << std::endl << trait<int>::value << std::endl ; return 0; }
El Tue, 7 May 2002 09:19:31 -0700 (PDT) Noel Yap <yap_noel@yahoo.com> escribió:
It looks like it's working find with gcc-2.95.3-5. One thing, though, it gave me a compiler error when I didn't #include <typeinfo>. Since you didn't list which header files you're including, I'm not sure if you're including <typeinfo> or not and what the Borland's behaviour would be if you didn't.
I tried a different version in gcc 3.0.3 and I think it works find. The modified code is: ________________________________________ int main(int argc, char* argv[]) { std::cout << typeid(trait<int>::t1).name() << std::endl << typeid(trait1<int,1>).name() << std::endl << typeid(trait1<int,0>).name() << std::endl << trait<int>::value << std::endl ; return 0; } ________________________________________ and the output is: ________________________________________ 6trait1IiLi1EE 6trait1IiLi1EE 6trait1IiLi0EE 1 ________________________________________ -- Raúl Huertas Díaz Redes y Comunicaciones Ingeniero de Sistemas TCP Sistemas e Ingenieria Fernández Caro, 7, 3ª planta Tel.: +34 91 367 32 79 (Ext. 535) Fax: +34 91 407 71 39 rhuertas@tcpsi.es http://www.tcpsi.es
participants (6)
-
hicks -
Noel Yap -
Peter Dimov -
Raul Huertas Diaz -
Toon Knapen -
whastingsnj