- Boost-users - lists.preview.boost.org

Re: [Boost-users] interested to know your opinion on possible feature
by Ovanes Markarian 11 Jul '06

11 Jul '06

On Tue, July 11, 2006 01:26, Sebastian Redl wrote: > Ovanes Markarian wrote: > >>In my current project is a need to implement an optional type, this type is considered to be >> lazy. >>I am wondering why C++ or Boost do not offer this possibility. >> >> > In what way does Boost.Optional fail to meet your needs? > > Sebastian Redl > > Thanks for your reply. I will take a look at this class in a more detailed manner. I saw it already, but thought it is not what I need. After some inspection I start to realize, that it is indeed what I might need. Thanks again. With Kind Regards, Ovanes Markarian

1 0

erase and iterators
by bringiton bringiton 11 Jul '06

11 Jul '06

is this common practise for using an interator with erase? what i wish to do is interate through each item and delete the item if some condition is true. when i delete, i need to move back a step so that i dont miss an item. for (std::vector<int>::iterator it = vect.begin(); it != vect.end(); it++) { if ((*it) == 5) { // some condition vect.erase(it); it--; // step back } } or would it be best to use a reverse iterater? (or possible?) for (std::vector<int>::reverse_iterator it2 = vect.rbegin(); it2 != vect.rend(); it2++) { if ((*it) == 5) { // i'm not actually sure how to erase with a reverse iterator??? vect.erase(it2); } }

4 4

weak_ptr, shared_ptr and dynamic libraries
by Kyle Girard 10 Jul '06

10 Jul '06

Hello, I was fooling around with the boost::shared_ptr and boost::weak_ptr library and dynamic libraries and I received a segmentation fault which I do not fully understand and I am hoping someone can shed some light on the situation. I am playing around with having objects in a dynamic library which are managed by shared_ptr's return weak_ptrs to the application My problem arises when the weak_ptrs aren't destroyed before the plugin is unloaded. I was hoping that the weak_ptr would become invalid when the shared_ptr it points to is unloaded but instead it causes a segmentation fault. I'm just starting to play around with dynamic libraries and shared_ptrs and stuff so I don't fully understand all the caveats that go with the territory so any information would be appreciated. Here's a small linux example which generates the error: main.cc == Application foo.cc/foo.hh == Dynamic Library make sure to set LD_LIBRARY_PATH to the appropriate directory main.cc ======= #include <iostream> #include <dlfcn.h> #include <boost/weak_ptr.hpp> #include "Foo.hh" using namespace std; int main() { typedef boost::weak_ptr<Foo> (*DoStuff) (void); void *hndl = dlopen("libFoo.so", RTLD_NOW); void *doStuff = dlsym(hndl, "doStuff"); // { //if I comment this in then the error goes away boost::weak_ptr<Foo> wpFoo = ((DoStuff)(doStuff))(); // } //if I comment this in then the error goes away dlclose(hndl); cerr << "Yay Finished" << endl; return 0; } Foo.hh ====== #ifndef FOO_HH #define FOO_HH #include <boost/weak_ptr.hpp> class Foo { }; extern "C" { boost::weak_ptr<Foo> doStuff(); } #endif //FOO_HH Foo.cc ====== #include "Foo.hh" #include <vector> #include <boost/shared_ptr.hpp> std::vector<boost::shared_ptr<Foo> > Foos; extern "C" { boost::weak_ptr<Foo> doStuff() { Foos.push_back(boost::shared_ptr<Foo>(new Foo)); return Foos[0]; } } Makefile ======== CC = g++ LIBS = -ldl .cc.o: $(CC) -ggdb -c $< default: make all OBJS = main.o test: main.o $(CC) -rdynamic -o test main.o $(LIBS) libfoo.so: Foo.o g++ -shared -Wl,-soname,libFoo.so -o libFoo.so Foo.o all: test libfoo.so clean: rm -f *.so *.o test === end of example thanks Kyle

2 1

interested to know your opinion on possible feature
by Ovanes Markarian 10 Jul '06

10 Jul '06

Hello all, I have one issue, which I would like to discuss here. In my current project is a need to implement an optional type, this type is considered to be lazy. I am wondering why C++ or Boost do not offer this possibility. These are just some thoughts which are really not perfect, but an opinion and interest would be highly appreciated: template<class Type, class Allocator /*some other policies like threading etc.*/> class lazy_type { public: //constructors must be considered which //should it be possible to copy this type etc. //destuctor, must be considered how the object should be deallocated in regards of owning and non-owning policies operator bool()const { return ptr_!=NULL; } Type* operator->() { if(!ptr_) { //allocate ptr_ and instantiate it using an allocator or another policy type ... } return ptr_; } private: Type* ptr_; }; This type can be a mix of reference counted ptr (shared_ptr) and allocator on request. All comments and thoughts are HIGHLY appreciated. With Kind Regards, Ovanes Markarian

2 1

Linking errors while using the test library (for a very basic program)
by Josh 10 Jul '06

10 Jul '06

I have a very simple program ******************************************************************** #include <iostream> #include <boost/test/unit_test.hpp> using boost::unit_test::test_suite; void MyTest() { BOOST_CHECK(2==2); } test_suite * init_unit_test_suite( int, char* [] ) { test_suite* test= BOOST_TEST_SUITE( "Simple test" ); test->add(BOOST_TEST_CASE( &MyTest ), 0); return test; } **************************************************************************************** I am trying to compile it using the following commands g++ -c BoostTest.cpp -I~/boost/include/boost-1_33_1/ g++ -o BT BoostTest.o -I/home/josh/boost/include/boost-1_33_1/ /home/josh/boost/lib/libboost_unit_test_framework-gcc-s.a The first step completes without a problem, the linking stage gives the following errors BoostTest.o(.text+0x15b): In function `MyTest()': : undefined reference to `boost::test_tools::tt_detail::test_and_continue_impl(bool, boost::basic_wrap_stringstream<char>&, boost::unit_test::basic_cstring<char const>, unsigned int, bool, boost::unit_test::log_level)' BoostTest.o(.text+0x258): In function `init_unit_test_suite(int, char**)': : undefined reference to `boost::unit_test::test_suite::add(boost::unit_test::test_case*, unsigned long, int)' BoostTest.o(.gnu.linkonce.t._ZN5boost9unit_test16create_test_caseEPFvvESs+0x12): In function `boost::unit_test::create_test_case(void (*)(), std::basic_string<char, std::char_traits<char>, std::allocator<char> >)': : undefined reference to `boost::unit_test::ut_detail::normalize_test_case_name(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)' BoostTest.o(.gnu.linkonce.t._ZN5boost9unit_test18function_test_caseC1EPFvvENS0_13basic_cstringIKcEE+0x1b): In function `boost::unit_test::function_test_case::function_test_case(void (*)(), boost::unit_test::basic_cstring<char const>)': : undefined reference to `boost::unit_test::test_case::test_case(boost::unit_test::basic_cstring<char const>, bool, unsigned long, bool)' BoostTest.o(.gnu.linkonce.r._ZTVN5boost9unit_test18function_test_caseE+0x10): undefined reference to `boost::unit_test::test_case::size() const' BoostTest.o(.gnu.linkonce.t._ZN5boost9unit_test9test_caseD2Ev+0xc): In function `boost::unit_test::test_case::~test_case()': : undefined reference to `vtable for boost::unit_test::test_case' BoostTest.o(.gnu.linkonce.r._ZTIN5boost9unit_test18function_test_caseE+0x8): undefined reference to `typeinfo for boost::unit_test::test_case' ************************************************************* PLEASE HELP! Josh --------------------------------- Want to be your own boss? Learn how on Yahoo! Small Business.

4 6

Re: [Boost-users] std::vector< boost::shared_ptr<int> >::pop_back()
by Andrew Holden 10 Jul '06

10 Jul '06

You would manually call destructors when you do your own memory management (like std::vector). In this case, you would also need to manually call constructors too. Here is a modified version of your test program that doesn't double-destruct the object. class A { public: A() { counter = 0; } ~A() { counter++; std::cout << "~A(): " << counter << std::endl; } int counter; }; int main(int argc, char* argv[]) { A *a; //Allocate memory using C functions, which do not call constructors a = (A*) malloc (sizeof (A)); cout << a << ' ' << a->counter << std::endl; //Manually call the constructor. The (a) tells the compiler which pointer we are initializing new (a) A (); cout << a << ' ' << a->counter << std::endl; //Manually call the destructor a->~A(); cout << a << ' ' << a->counter << std::endl; //Free memory using C functions, which do not call destructors free (a); return 0; } _____ From: bringiton bringiton [mailto:kneeride@gmail.com] Sent: Monday, July 10, 2006 10:28 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] std::vector< boost::shared_ptr<int> >::pop_back() holy! you learn something every day. you can call the destructor of an object (before destruction) this is a trap for me because i dont clean up my variables in destructors. class A { public: A() { counter = 0; } ~A() { counter++; std::cout << "~A(): " << counter << std::endl; } int counter; }; int main(int argc, char* argv[]) { A a; a.~A(); return 0; } NOTE: destructor gets called twice. (so it's probably a good idea to NULL pointers in destructors) On 7/11/06, bringiton bringiton <kneeride(a)gmail.com> wrote: >>just look at the include files: i looked at the header, but got a little confused. i don't see how you can call a destruct of a a memory space that still exists. ie a C version of a vector. shared_ptr<int> list[1024]; int n = 0; // add an item shared_ptr<int> newItem(new int(1)); list[n++] = newItem; // remove the tail item n--; // destructor never called is it possible to call a destructor of an object that exists? what then happens then the object goes out of scope? the destructor will be called twice. (or maybe i am completely missing the point) BTW: not sure if above code compiles (did it in my head) On 7/10/06, Boris Breidenbach < Boris.Breidenbach(a)physik.uni-erlangen.de <mailto:Boris.Breidenbach@physik.uni-erlangen.de> > wrote: On Mon, Jul 10, 2006 at 03:58:19PM +1000, bringiton bringiton wrote: > This question is based on curiosity. How does std::vector::pop_back() call > the destructor of the item getting removed? > > i understood std::vector to be a contigious array of memory, therefore an > item's memory does not go out of scope when being popped. ie the item goes > out of scope when the entire array goes out of scope. just look at the include files: bits/stl_vector.h says: void pop_back() { --this->_M_impl._M_finish; std::_Destroy(this->_M_impl._M_finish); } so the destructor is called in std::_Destroy. Which can be found in bits/stl_construct.h: /** * @if maint * Destroy the object pointed to by a pointer type. * @endif */ template<typename _Tp> inline void _Destroy(_Tp* __pointer) { __pointer->~_Tp(); } It just calls the destructor. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 2

Re: [Boost-users] std::vector< boost::shared_ptr<int> >::pop_back()
by Andrew Holden 10 Jul '06

10 Jul '06

True. I would not expect a guarantee that malloc/free would be suitable for objects, since they came from a language that doesn't have objects. I was merely looking for a way to demonstrate manually calling both the constructor and destructor without calling either twice, and that happened to work on my platform, and I think will probably work on most. Well, that and I didn't know you could use operator new and operator delete like this. We all learn something new every day. _____ From: Michael Nicolella [mailto:boost@mike-n.com] Sent: Monday, July 10, 2006 2:54 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] std::vector< boost::shared_ptr<int> >::pop_back() I would avoid malloc() and prefer the global operator new... I'm not sure if the standard guarantees that memory allocated with malloc is suitable for constructing an object in. My guess is there's no such guarantee, but there is that guarantee for operator new. Or maybe I'm off my rocker.

1 0

[serialization] save_construct_data problem
by Hugh Hoover 10 Jul '06

10 Jul '06

I have a structure I'm trying to serialize that contains an STL vector of pointers to an abstract base type. When I serialize it, the save_construct_data free function is NOT called - the inline default version is always used. On de-serializing, the load_construct_data IS called! but, of course, fails because the data for it isn't there (although it throws archive_exception (archive_exception::unregistered_class) when it fails). I'm using declarations only for all serialization code, with all definitions in .s.cpp files along with explicit instantiations. Not sure if that affects the problem here. Just in case, I've tried all combinations of save_construct_data with (const)? (Base|Derived) (*|&), and none of them are called. I've also tried putting my declarations before and after the serialization.hpp header with the default declaration/definition. I'm using gcc4 currently. Any notion what might be wrong here?

3 5

Missing example in boost::graph doc
by Loïc Joly 10 Jul '06

10 Jul '06

Hello, In boost::graph doc, I can read (http://www.boost.org/libs/graph/doc/file_dependency_example.html) > A compilation system such as make has to be able to answer a number of questions: > > 1. If we need to compile (or recompile) all of the files, what order should that be done it? > 2. What files can be compiled in parallel? > 3. If a file is changed, which files must be recompiled? > 4. Are there any cycles in the dependencies? (which means the user has made a mistake and an error should be emitted) > I'd like to do something related to the point #3, and looked in the doc, but could not find it. Since I'm not at all a graph expert, I'd like to know whether there is a basic graph algorithm that can be used to remove from a graph all nodes who are not marked as modified and whose all dependencies (recursively) are not marked as modified either. -- Loïc

1 0

memory leaks with signal::connect()
by Elisabeth Benoit 10 Jul '06

10 Jul '06

Hello, I'm sending this message a second time (I didn't receive any response and still have this problem) I'm using boost::bind and boost::signal with VC6. VC6 is detecting some memory leak for a certain type of signal.connect(). I've done a little test program to check if the problem was due to some bug or special configuration in my main program, but the memory leaks are still detected in the test situation. Let me explain the structure of my test program. I have a main, and in the main, an object CCloneAppRecipe named clone. The class CCloneAppRecipe contains a member m_PtrTestMem (a shared pointer, but a raw point or an object does the same thing) of the class CTestMem. CTestMem contains 3 instances of the class CTestTab, and the class CTestTab contains a boost signal typedef boost::signal0<void> TypeSignalTest; TypeSignalTest m_SignalTest; In my main, I invoke clone.connectPtrTestMem(). clone.connectPtrTestMem() then invokes CTestMem::ConnectSignalTriplePtrTab(boost::bind(&CloneAppRecipe::test, this)); ConnectSignalTriplePtrTab() then invokes ConnectSignal(TypeSignalTest::slot_type slot) for each of the 3 instances of the class it contains. ConnectSignal then calls m_SignalTest.connect(slot). And I have a memory leak: 2 blocks of 16 bytes. If I connect only one instance of CTestTab, no leak. Two instances, one leak of 16 bytes. Three, two leaks of 16 bytes, and so on. I connect the m_SignalTest with a CCloneAppRecipe's slot. If I connect it to a CTestMem slot, I have no leak. Or if I place 3 instances of CTestTab directly in the CCloneAppRecipe class (so I don't use CTestMem anymore), I have no leak. But that's not what I need to do. I've tested plenty of variations (shared_pointer or object, etc.) Does anybody have a clue. Thanks #include "stdafx.h" #include "CloneAppRecipe.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif int main() { CloneAppRecipe t; // cree un leak t.connectPtrTestMem(); getchar(); return 0; } void CloneAppRecipe::connectPtrTestMem() { //m_ptrTestMem is a boost::shared_ptr m_ptrTestMem->ConnectSignalTriplePtrTab(boost::bind(&CloneAppRecipe::test, this)); } void CloneAppRecipe::test() const { } void CTestMem::ConnectSignalTriplePtrTab(const TypeSignaTest::slot_type& slot) { //m_ptrTestTab are boost::shared_ptr m_ptrTestTab1->ConnectSignal(slot); m_ptrTestTab2->ConnectSignal(slot); m_ptrTestTab3->ConnectSignal(slot); } void CTestTab::ConnectSignal(const TypeSignalTest::slot_type& slot) { m_SignalTest->connect(slot); } CTestTab::~CTestTab() { m_SignalTest->disconnect_all_slots(); }

2 5