You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(4) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
2005 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(15) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(2) |
Dec
(15) |
2006 |
Jan
(44) |
Feb
(71) |
Mar
(67) |
Apr
(21) |
May
(35) |
Jun
(7) |
Jul
(19) |
Aug
(7) |
Sep
(14) |
Oct
(48) |
Nov
(14) |
Dec
(3) |
2007 |
Jan
(4) |
Feb
(11) |
Mar
(12) |
Apr
(2) |
May
(10) |
Jun
(9) |
Jul
(10) |
Aug
(3) |
Sep
(1) |
Oct
(4) |
Nov
(6) |
Dec
|
2008 |
Jan
(7) |
Feb
(1) |
Mar
(5) |
Apr
(8) |
May
(6) |
Jun
|
Jul
(2) |
Aug
(29) |
Sep
(1) |
Oct
(3) |
Nov
(6) |
Dec
(113) |
2009 |
Jan
(7) |
Feb
(14) |
Mar
(38) |
Apr
(8) |
May
(2) |
Jun
(4) |
Jul
(1) |
Aug
(4) |
Sep
(11) |
Oct
(4) |
Nov
(15) |
Dec
(5) |
2010 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
(9) |
May
(5) |
Jun
|
Jul
(7) |
Aug
(1) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
|
2011 |
Jan
|
Feb
|
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(25) |
Oct
(10) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(2) |
Dec
(8) |
2013 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2011-10-10 09:30:35
|
Bugs item #1202020, was opened at 2005-05-14 19:59 Message generated for change (Comment added) made by denlty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=1202020&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 3 Private: No Submitted By: Martin F. Krafft (madduck) Assigned to: Peter Kuemmel (syntheticpp) Summary: Unix Makefile for Loki Initial Comment: Please find the attached Makefile, which you could include with the distribution. It basically creates a static library libloki.a using libtool and allows for the installation of libloki and the headers. Just drop it into ./Reference and Unix users can install Loki with ease. I use this Makefile to install files into Debian's libloki-dev package. ---------------------------------------------------------------------- Comment By: QtDLSF (denlty) Date: 2011-10-10 12:30 Message: I downloaded last loki sources from svn at 10 oct 2011. At "test\SafeFormat\Makefile" reference to "ThreadPool.cpp" is absent. I suggest correction: at line 4 SRC := main.cpp ThreadPool.cpp ---------------------------------------------------------------------- Comment By: Peter Kuemmel (syntheticpp) Date: 2005-10-05 12:17 Message: Logged In: YES user_id=1159765 Makefile-debian added: # libloki Makefile # # written for Debian GNU/Linux by # martin f. krafft <ma...@de...> # but may be used by others. # # (c) 2005 martin f. krafft <ma...@de...> # Released under the terms of the Artistic Licence: # http://www.opensource.org/licenses/artistic-license.php # LOKI_VERSION=$(shell dpkg-parsechangelog | sed -ne 's,^Version: \(.*\)-[[:digit:]]*,\1,p') prefix ?= /usr/local libdir ?= $(prefix)/lib includedir ?= $(prefix)/include CPPFLAGS = CXXFLAGS = -I./include -O2 -g -Wall -W -pedantic -ansi -Werror -c LDFLAGS = -static -rpath $(libdir) LIBTOOL = libtool COMPILE = $(LIBTOOL) --mode=compile --tag=CXX $(CXX) $(CPPFLAGS) $(CXXFLAGS) LINK = $(LIBTOOL) --mode=link --tag=BINCXX $(LD) $(LDFLAGS) INSTALL = $(LIBTOOL) --mode=install install -m644 FINISH = $(LIBTOOL) --mode=finish CLEAN = $(LIBTOOL) --mode=clean $(RM) SOURCES = src/SmallObj.cpp src/Singleton.cpp libloki.la: $(patsubst %.cpp,%.lo,$(SOURCES)) $(LINK) -o $@ $^ libloki.pc: libloki.pc.in sed -e "s,@prefix@,$(prefix)," \ -e "s,@libdir@,$(libdir)," \ -e "s,@includedir@,$(includedir)," \ $< > $@ .PHONY: all all: libloki.la .PHONY: install install: DESTlibdir = $(DESTDIR)$(libdir) install: DESTincludedir = $(DESTDIR)$(includedir) install: libloki.la libloki.pc ifndef DESTDIR @echo E: DESTDIR not specified. >&2 @false else mkdir -p $(DESTlibdir) $(INSTALL) libloki.la $(DESTlibdir) 2>/dev/null mkdir -p $(DESTlibdir)/pkgconfig $(INSTALL) libloki.pc $(DESTlibdir)/pkgconfig 2>/dev/null mkdir -p $(DESTincludedir) $(INSTALL) $(wildcard *.h) $(DESTincludedir) endif %.lo: %.cpp $(COMPILE) -o $@ $< .PHONY: clean clean: $(CLEAN) $(wildcard *.o *.lo) $(CLEAN) $(wildcard *.a *.la) ---------------------------------------------------------------------- Comment By: Peter Kuemmel (syntheticpp) Date: 2005-09-25 02:42 Message: Logged In: YES user_id=1159765 mostly done, only install option is missing. ---------------------------------------------------------------------- Comment By: Peter Kuemmel (syntheticpp) Date: 2005-07-27 22:49 Message: Logged In: YES user_id=1159765 soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=1202020&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-10-07 07:41:38
|
Bugs item #2887024, was opened at 2009-10-27 03:00 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2887024&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Albert xu (albertclass) >Assigned to: Richard Sposato (rich_sposato) Summary: class ClassLevelLockable in Threads break at Thread.h 574 Initial Comment: Inside the ClassLevelLockable Class, the Initializer member has a bug during initialization. struct Initializer { /// This function provides a Scott-Meyers type of Singleton as the initializer /// for the shared mutex. static Initializer & GetIt( void ) { static Initializer initializer_; return initializer_; } inline bool IsInit( void ) { return init_; } inline MutexPolicy & GetMutex( void ) { return mtx_; } private: bool init_; MutexPolicy mtx_; Initializer() : init_(false), mtx_() { init_ = true; } ~Initializer() { assert(init_); } Initializer( const Initializer & ); Initializer & operator = ( const Initializer & ); }; After the Initialzer constructor, the code breaks on the assert( initialzer.IsInit() ); This bug happens when two threads call the constructor of ClassLevelLockable::Lock() at the same time. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-10-07 00:41 Message: Sorry, but I don't think this problem can be fixed by a change to Loki. Loki can control multiple thread access to a mutex that already exists, but can't control multiple threads trying to construct or destruct a mutex concurrently. That's a problem which must be solved at a higher level within the program. The program needs to explicitly call functions which cause the initialization before other threads can access the object. (Perhaps a thread can call Host::Initializer::GetIt() to force initialization before other threads call Lock.) If you know of a way Loki can protect a mutex from this problem, please let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2887024&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-10-07 07:24:04
|
Bugs item #2892661, was opened at 2009-11-05 07:02 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2892661&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 6 Private: No Submitted By: Aleksandr Vinokurov (xvyg) >Assigned to: Richard Sposato (rich_sposato) Summary: Access violation when using atomic_mutex_ under Windows Initial Comment: Hello guys, I've tried to use SmartPtr with ClassLevelLockable and default mutex policy. First I've added this: --------------------- #else template <class Host, class MutexPolicy> CRITICAL_SECTION ClassLevelLockable<Host, MutexPolicy>::atomic_mutex_; --------------------- in --------------------- #ifdef LOKI_PTHREAD_H template <class Host, class MutexPolicy> pthread_mutex_t ClassLevelLockable<Host, MutexPolicy>::atomic_mutex_ = PTHREAD_MUTEX_INITIALIZER; #endif --------------------- Because of link failure under MSVS 2003. Then it started and crashed calling AtomicIncrement() on atomic_mutex_ without initializing it first. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-10-07 00:24 Message: According to my tests, this was fixed in revision 985 when I also fixed bug 1776032. ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2010-05-11 16:22 Message: Thanks for reporting this Aleksandr. I think this bug is related to #2998899 - which is also about using atomic_mutex_ on Windows. Rich ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2892661&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-10-07 07:23:28
|
Bugs item #2998899, was opened at 2010-05-09 04:32 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2998899&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 6 Private: No Submitted By: Slav Grig (slavgrig) >Assigned to: Richard Sposato (rich_sposato) Summary: global atomic_mutex_ isn't initialized Initial Comment: There are definitions LOKI_THREADS_ATOMIC_FUNCTIONS In the file "threads.h". In case of compiling for windows there is a definition of the static variable static CRITICAL_SECTION atomic_mutex_; \ This variable should be initialized before any using by ::InitializeCriticalSection() method in the Win32 API. But there is no such code. Additionally it should be freed after using by ::DeleteCriticalSection(). The bug is only applied to compilations for windows platform. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-10-07 00:23 Message: According to my tests, this was fixed in revision 985 when I also fixed bug 1776032. ---------------------------------------------------------------------- Comment By: Slav Grig (slavgrig) Date: 2010-05-12 00:41 Message: Yes, it seems to be the same bug. ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2010-05-11 16:22 Message: Thanks for reporting the bug. I think it is related to #2892661 - which is also about using atomic_mutex_ on Windows. Rich ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2998899&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-10-04 23:46:54
|
Bugs item #2694067, was opened at 2009-03-19 03:30 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2694067&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jean-François Bastien (jfbastien) >Assigned to: Richard Sposato (rich_sposato) Summary: SafeFormat atomicity of writes to streams Initial Comment: As reported in http://accu.org/index.php/journals/1539 Allow atomic writing to streams/files so that multiple threads' outputs aren't interweaved.. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-10-04 16:46 Message: Fixed in revision 1138. Added temp strings to functions so output can be formatted atomically before it is written to cout or stdout. Added tests for this bug to test/SafeFormat project. Tests are in revision 1139. ---------------------------------------------------------------------- Comment By: Jean-François Bastien (jfbastien) Date: 2009-03-19 10:26 Message: For FILE* and ostream FastFormat seems to simply concatenate the strings together and then write them to the sink. fprintf and ostream.write are atomic on each call (TO BE VALIDATED), it's just if you make more than one call that they're not. I haven't looked at the SafeFormat implementation, does it use proxies on each call to operator() and write only when the last operator() is called? We can't guarantee atomicity nor reduce the number of memory allocations if it simply chain writes. Andrei says: This means there's opportunity to improve on that. With the atomic primitives you don't need to concatenate, so there's no need to allocate extra memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2694067&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-10-04 20:49:20
|
Bugs item #2694073, was opened at 2009-03-19 03:31 Message generated for change (Settings changed) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2694073&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jean-François Bastien (jfbastien) >Assigned to: Richard Sposato (rich_sposato) Summary: SafeFormat reduce memory allocations when formatting Initial Comment: As reported in http://accu.org/index.php/journals/1539 The number of memory allocations when formatting could be reduced. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-10-04 13:49 Message: Fixed in revision 1137. Added calls to string::reserve so string::append won't resize as often. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2694073&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-10-04 00:55:10
|
Bugs item #2792371, was opened at 2009-05-15 09:42 Message generated for change (Settings changed) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2792371&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Etienne PIERRE (etiennepierre) Assigned to: Richard Sposato (rich_sposato) Summary: Bug in SafeFormat when providing extra arguments Initial Comment: This bug is related to number 2694060, when you provided extra arguments, there may be a security problem, there are 3 cases when you give an argument : - it can be a float, in which case we go in the assert(*fmt == '%') (line 351 in version 0.1.7) - it can be an integer in which case it will read passed the % character - it can be a string in which case we are saved by the test if (fmt != 's') (line 206 in version 0.1.7) I've attached a patch that for each of these function test whether *format_ is \0, in which case it sets result_ to -1 and returns. Thanks for all the work on this really fun library. ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2011-10-03 17:52 Message: Fixed in revision 1135. Added check for end of format string. SafeFormat now throws exception if end of format encountered. Added test for this bug in revision 1136. Thank you, Etienne! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2792371&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-10-04 00:53:16
|
Bugs item #2694060, was opened at 2009-03-19 03:27 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2694060&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jean-François Bastien (jfbastien) >Assigned to: Richard Sposato (rich_sposato) Summary: SafeFormat too many arguments, extras get appended Initial Comment: As reported in http://accu.org/index.php/journals/1539 Arguments that aren't referenced in the format string (too many arguments) are appended. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-10-03 17:53 Message: Fixed in revision 1135. Added check for end of format string. SafeFormat now throws exception if end of format encountered. Added test for this bug in revision 1136. Thank you, Etienne! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2694060&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-10-04 00:52:21
|
Bugs item #2792371, was opened at 2009-05-15 09:42 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2792371&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Etienne PIERRE (etiennepierre) >Assigned to: Richard Sposato (rich_sposato) Summary: Bug in SafeFormat when providing extra arguments Initial Comment: This bug is related to number 2694060, when you provided extra arguments, there may be a security problem, there are 3 cases when you give an argument : - it can be a float, in which case we go in the assert(*fmt == '%') (line 351 in version 0.1.7) - it can be an integer in which case it will read passed the % character - it can be a string in which case we are saved by the test if (fmt != 's') (line 206 in version 0.1.7) I've attached a patch that for each of these function test whether *format_ is \0, in which case it sets result_ to -1 and returns. Thanks for all the work on this really fun library. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-10-03 17:52 Message: Fixed in revision 1135. Added check for end of format string. SafeFormat now throws exception if end of format encountered. Added test for this bug in revision 1136. Thank you, Etienne! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2792371&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-30 23:39:16
|
Feature Requests item #1447423, was opened at 2006-03-10 10:24 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=1447423&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Eric Beyeler (ebeyeler) >Assigned to: Richard Sposato (rich_sposato) Summary: SmartPtr conversion constructor Initial Comment: The templatized constructor template < typename T1, template <class> class OP1, class CP1, template <class> class KP1, template <class> class SP1 > SmartPtr(SmartPtr<T1, OP1, CP1, KP1, SP1>& rhs) : SP(rhs), OP(rhs), KP(rhs), CP(rhs) { GetImplRef(*this) = OP::Clone(GetImplRef (rhs)); } does not compile, at least when T and T1 are not in the same heirarchy, e.g. multiple inheritance of interfaces. Do something similar to boost::shared_ptr... template<class Y> shared_ptr(shared_ptr<Y> const & r): px(r.px), pn (r.pn) // never throws { } template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::static_cast_tag): px(static_cast<element_type *>(r.px)), pn(r.pn) { } template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::const_cast_tag): px(const_cast<element_type *> (r.px)), pn(r.pn) { } template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::dynamic_cast_tag): px (dynamic_cast<element_type *>(r.px)), pn(r.pn) { if(px == 0) // need to allocate new counter -- the cast failed { pn = detail::shared_count(); } } template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::polymorphic_cast_tag): px (dynamic_cast<element_type *>(r.px)), pn(r.pn) { if(px == 0) { boost::throw_exception(std::bad_cast()); } } ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-09-30 16:39 Message: This feature was implemented when the DynamicCastFrom functions were added to SmartPtr and StrongPtr. ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2006-03-13 21:30 Message: Logged In: YES user_id=749922 If I understand your request correctly, then you are asking if we can add a templated constructor to SmartPtr which does a dynamic cast on the plain pointer. And that the constructor is needed for pointers to different base types in an inheritance heierarchy. for example: class A { ... }; class B { ... }; class C: public A, public B { ... }; typedef Loki::SmartPtr< A > A_Ptr; typedef Loki::SmartPtr< B > B_Ptr; typedef Loki::SmartPtr< C > C_Ptr; C_Ptr c1( new C ); // should be okay using existing templated constructor. B_Ptr b1( c1 ); // Not possible in current SmartPtr class, but should be // allowed with another templated constructor which does // dynamic cast on plain pointer within b1. A_Ptr a1( b1 ); Is this what you had in mind? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=1447423&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-30 23:17:33
|
Bugs item #3388381, was opened at 2011-08-08 07:13 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3388381&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Felipe (felipemt) >Assigned to: Richard Sposato (rich_sposato) Summary: Loki::AssocVector constructor accepts duplicated keys Initial Comment: Hi !! Loki::AssocVector constructor accepts duplicate keys in realease loki 0.1.7. The following code prints 2 instead of 1. std::pair<int,char> p[] = { std::make_pair(1,'a'), std::make_pair(1,'b') }; Loki::AssocVector<int, char> w(p, p+2); std::cout << "SIZE = " << w.size() << std::endl; Thanks ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-09-30 16:17 Message: Fixed in revision 1127. Fixed by replacing existing ctor body with code that creates temporary map and then inserts elements into AssocVector. Added test project for AssocVector in revisions 1125 and 1126. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3388381&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-30 20:00:18
|
Bugs item #3415388, was opened at 2011-09-29 08:11 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3415388&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Michael Andres (mlandres) >Assigned to: Richard Sposato (rich_sposato) Summary: [doc] Missing doc for Loki::{Object,Class}LevelLockable Initial Comment: Source: loki-0.1.7.tar.bz2 Doxyfile has 'PREDEFINED = _WINDOWS_H'. Most probably a typo and should read 'LOKI_WINDOWS_H'. Without this the class documentation for ObjectLevelLockable and ClassLevelLockable does't appear in the html doc. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-09-30 13:00 Message: Fixed in revision 1124. Changed predefined as recommended. Thank You! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3415388&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-29 15:11:10
|
Bugs item #3415388, was opened at 2011-09-29 17:11 Message generated for change (Tracker Item Submitted) made by mlandres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3415388&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Andres (mlandres) Assigned to: Nobody/Anonymous (nobody) Summary: [doc] Missing doc for Loki::{Object,Class}LevelLockable Initial Comment: Source: loki-0.1.7.tar.bz2 Doxyfile has 'PREDEFINED = _WINDOWS_H'. Most probably a typo and should read 'LOKI_WINDOWS_H'. Without this the class documentation for ObjectLevelLockable and ClassLevelLockable does't appear in the html doc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3415388&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-23 00:49:17
|
Feature Requests item #3027570, was opened at 2010-07-09 13:54 Message generated for change (Settings changed) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=3027570&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Priority: 5 Private: No Submitted By: Sergio Pascual (sergiopasra) >Assigned to: Richard Sposato (rich_sposato) Summary: Include a text copy of the license Initial Comment: The source code should include a text copy of the license under loki-lib is released ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2011-09-22 17:48 Message: Added text of MIT License to header files and source code files of Loki. Revisions 1115 and 1116. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=3027570&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-23 00:48:24
|
Feature Requests item #3027570, was opened at 2010-07-09 13:54 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=3027570&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Sergio Pascual (sergiopasra) Assigned to: Nobody/Anonymous (nobody) Summary: Include a text copy of the license Initial Comment: The source code should include a text copy of the license under loki-lib is released ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-09-22 17:48 Message: Added text of MIT License to header files and source code files of Loki. Revisions 1115 and 1116. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=3027570&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-22 10:15:42
|
Feature Requests item #3406727, was opened at 2011-09-09 10:42 Message generated for change (Comment added) made by zhnmju123 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=3406727&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: ZenJu (zhnmju123) Assigned to: Nobody/Anonymous (nobody) Summary: Improvement for ScopeGuard Initial Comment: Hi, short version: I ask for a LOKI_ON_BLOCK_EXIT that does not emit a compiler warning about an unused variable on GCC and MSVC. long version: one use of ScopeGuard is as a convenient RAII "cleanup" mechanism, that is without calling "Dismiss()" later. The problem then is that GCC and MSVC emit compiler warnings about an unused variable. This happens both when using a dummy variable without dismissing it and more critically when using "LOKI_ON_BLOCK_EXIT", which is specifically designed for that purpose. As seen here, others have been looking for an answer, but with little success: http://stackoverflow.com/questions/219770/dealing-with-c-initialized-but-not-referenced-warning-for-destruction-of-scop For GCC, there is a nice and simple solution which could be implemented by the Loki library: replace: typedef const ScopeGuardImplBase& ScopeGuard; by __attribute__((unused)) typedef const ScopeGuardImplBase& ScopeGuard; Unfortunately there is no MSVC equivalent. Now with C++11, there might be light at the end of the tunnel: One way to silence the warning about unused variable in both GCC and MSVC is to get rid of the const-reference: typedef const ScopeGuardImplBase& ScopeGuard; -> typedef ScopeGuardImplBase ScopeGuard; It's clear that this creates problems for the general ScopeGuard case where the type is dependent from the number and types of arguments passed. But for LOKI_ON_BLOCK_EXIT, this shouldn't matter. What's still missing is a way to "pass the value without copying". Here C++11 r-value-refences are the fitting solution. You see, there are a few open questions, but my hope is that they can be figured out eventually. Best regards, ZenJu ---------------------------------------------------------------------- >Comment By: ZenJu (zhnmju123) Date: 2011-09-22 10:15 Message: Hi, here is an actually working proposal for C++11: It's some more steroids for LOKI_ON_BLOCK_EXIT: #define LOKI_ON_BLOCK_EXIT2(X) ::Loki::ScopeGuard LOKI_ANONYMOUS_VARIABLE(scopeGuard) = ::Loki::MakeGuard([&](){X;}); (void)LOKI_ANONYMOUS_VARIABLE(scopeGuard); Resulting Syntax: LOKI_ON_BLOCK_EXIT2(::CloseHandle(hDir)); Multiple statements are possible also: LOKI_ON_BLOCK_EXIT2(::CloseHandle(hDir); ::CloseHandle(hDir)); And most importantly: no warning about unused variable anymore, both GCC and MSVC10! Personally, I like the syntax a lot more than BOOST_SCOPE_EXIT (not to mention the bunch of header dependencies), so I would love to see something like this in Loki! Regards, ZenJu ---------------------------------------------------------------------- Comment By: ZenJu (zhnmju123) Date: 2011-09-09 10:46 Message: > typedef const ScopeGuardImplBase& ScopeGuard; -> typedef ScopeGuardImplBase ScopeGuard; The example is wrong, but the main idea is to get rid of the reference and move to a value type. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=3406727&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-21 23:10:49
|
Bugs item #3224591, was opened at 2011-03-18 19:56 Message generated for change (Settings changed) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3224591&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: https://www.google.com/accounts () >Assigned to: Richard Sposato (rich_sposato) Summary: SmartPtr: DeepCopy and ArrayStorage are not compatible Initial Comment: DeepCopy ownership policy and ArrayStorage storage policy are not compatible, because only the first element in array gets copied by Clone() function of the pointee. #include <Loki/SmartPtr.h> struct Foo { Foo* Clone() const { return new Foo(*this); } }; int main() { typedef Loki::SmartPtr<Foo, Loki::DeepCopy, Loki::DisallowConversion, Loki::AssertCheck, Loki::ArrayStorage> Ptr; Ptr ptr(new Foo[23]); Ptr ptrCopy(ptr); // only first element is copied } I think there should be a partial specialization disallowing this combination of policies. ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2011-09-21 16:07 Message: There are multiple problems with attempting to fix this problem. One is that C++ does not allow partial specializations of functions inside template classes. Section 1.4 of Modern C++ Design says "Specialization of member functions does not scale. You can specialize any member function of a template with one template parameter, but you cannot specialize individual member functions for templates with multiple template parameters." The second problem has to do with making any array of objects where each element in the new array is a copy of its counterpart in the source array. If we use the array new operator, (e.g. - new T[ itemCount ]; ), that will just call the default constructor of type T - not the copy constructor for each element in the source array. I can add a comment to DeepCopy and ArrayStorage policies classes saying that each should not be used with the other. That's probably the best we can do here. Cheers, Rich ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3224591&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-21 23:07:17
|
Bugs item #3224591, was opened at 2011-03-18 19:56 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3224591&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: SmartPtr: DeepCopy and ArrayStorage are not compatible Initial Comment: DeepCopy ownership policy and ArrayStorage storage policy are not compatible, because only the first element in array gets copied by Clone() function of the pointee. #include <Loki/SmartPtr.h> struct Foo { Foo* Clone() const { return new Foo(*this); } }; int main() { typedef Loki::SmartPtr<Foo, Loki::DeepCopy, Loki::DisallowConversion, Loki::AssertCheck, Loki::ArrayStorage> Ptr; Ptr ptr(new Foo[23]); Ptr ptrCopy(ptr); // only first element is copied } I think there should be a partial specialization disallowing this combination of policies. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-09-21 16:07 Message: There are multiple problems with attempting to fix this problem. One is that C++ does not allow partial specializations of functions inside template classes. Section 1.4 of Modern C++ Design says "Specialization of member functions does not scale. You can specialize any member function of a template with one template parameter, but you cannot specialize individual member functions for templates with multiple template parameters." The second problem has to do with making any array of objects where each element in the new array is a copy of its counterpart in the source array. If we use the array new operator, (e.g. - new T[ itemCount ]; ), that will just call the default constructor of type T - not the copy constructor for each element in the source array. I can add a comment to DeepCopy and ArrayStorage policies classes saying that each should not be used with the other. That's probably the best we can do here. Cheers, Rich ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3224591&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-20 22:38:00
|
Feature Requests item #1465840, was opened at 2006-04-06 09:59 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=1465840&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Richard Sposato (rich_sposato) Assigned to: Richard Sposato (rich_sposato) Summary: operator [] for SmartPtr and StrongPtr Initial Comment: SmartPtr and StrongPtr could use an array operator for pointers to arrays of objects. It's great they have policies for deleting arrays of objects, so ideally there should be some way to insure that the array operator is only available when SmartPtr has a policy to delete []. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-09-20 15:38 Message: Added operator[] and range-checking to SmartPtr in revision 1109. Added tests to check operator[] in revision 1110. ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2011-09-20 10:55 Message: Added operator[] and range checking for StrongPtr in revisions 1104 and 1105. Added tests for operator[] in StrongPtr in revision 1106. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=1465840&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-20 17:55:04
|
Feature Requests item #1465840, was opened at 2006-04-06 09:59 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=1465840&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Richard Sposato (rich_sposato) Assigned to: Richard Sposato (rich_sposato) Summary: operator [] for SmartPtr and StrongPtr Initial Comment: SmartPtr and StrongPtr could use an array operator for pointers to arrays of objects. It's great they have policies for deleting arrays of objects, so ideally there should be some way to insure that the array operator is only available when SmartPtr has a policy to delete []. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-09-20 10:55 Message: Added operator[] and range checking for StrongPtr in revisions 1104 and 1105. Added tests for operator[] in StrongPtr in revision 1106. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=1465840&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-17 02:23:15
|
Bugs item #3224572, was opened at 2011-03-18 19:48 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3224572&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Richard Sposato (rich_sposato) Summary: SmartPtr: destructive copy from an rvalue is not working Initial Comment: SmartPtr with DestructiveCopy ownership policy can't perform copy construction from an rvalue. #include <Loki/SmartPtr.h> typedef Loki::SmartPtr<int, Loki::DestructiveCopy> Ptr; Ptr makePtr() { return Ptr(new int); } int main() { Ptr ptr = makePtr(); // error! } Constructor taking RefToValue seems to be never called because template constructor with const argument is favoured. Also there is no conversion between RevToValue holding reference to SmartPtr with different pointee types. It seems that the desired behaviour could be achieved by Colvin-Gibbons trick used in std::auto_ptr. However, it's more difficult to implement it in this SmartPtr. I've tried to write my own more lightweight policy-based SmartPtr and came up to some code which I attach here. It's not finished yet, but DestructiveCopy seems to be working. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-09-16 19:23 Message: Fixed bug by adding const overload of Clone function in DestructiveCopy policy class. Fixed in revision 1101. Test for fix is available in revision 1102. ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2011-09-12 17:32 Message: This is a duplicate of bug 2080889. Closing this bug report so only one report exists for this problem. ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2011-09-08 16:40 Message: Added tests for DestructiveCopy policy. One test is commented out until this bug gets fixed. I did confirm compiler calls wrong constructor when SmartPtr is returned by value - thus leading to bug described here. revision 1097. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3224572&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-17 02:21:26
|
Bugs item #2080889, was opened at 2008-08-28 11:12 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2080889&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Richard Sposato (rich_sposato) Summary: Code calls wrong Loki::SmartPtr constructor. Initial Comment: cri...@ya... The Colvin-Gibbons trick (also mentioned in Modern C++ Design) does not work for Loki::SmartPtr when configured as auto_ptr (using DestructiveCopy). Test environment: - Loki: ferrisloki-3.0.2-50022.1: http://download.opensuse.org/repositories/home:/monkeyiq/openSUSE_10.3/ - Compiler: gcc 4.3.1 and 4.2.1 - OS: OpenSUSE 11 and 10.3 Error message (from KDevelop output): g++ -DHAVE_CONFIG_H -I. -I/home/canita/work/loki_smart_auto_ptr/src -I.. -I/usr/local/include/FerrisLoki -O0 -g3 -MT loki_smart_auto_ptr.o -MD -MP -MF .deps/loki_smart_auto_ptr.Tpo -c -o loki_smart_auto_ptr.o /home/canita/work/loki_smart_auto_ptr/src/loki_smart_auto_ptr.cpp /usr/local/include/FerrisLoki/loki/SmartPtr.h: In static member function 'static P Loki::DestructiveCopy<P>::Clone(P1&) [with P1 = Base* const, P = Base*]': /usr/local/include/FerrisLoki/loki/SmartPtr.h:1181: instantiated from 'Loki::SmartPtr<T, OwnershipPolicy, ConversionPolicy, CheckingPolicy, StoragePolicy, ConstnessPolicy>::SmartPtr(const Loki::SmartPtr<T1, OP1, CP1, KP1, SP1, CNP1>&) [with T1 = Base, OP1 = Loki::DestructiveCopy, CP1 = Loki::DisallowConversion, KP1 = Loki::AssertCheck, SP1 = Loki::DefaultSPStorage, CNP1 = Loki::DontPropagateConst, T = Base, OwnershipPolicy = Loki::DestructiveCopy, ConversionPolicy = Loki::DisallowConversion, CheckingPolicy = Loki::AssertCheck, StoragePolicy = Loki::DefaultSPStorage, ConstnessPolicy = Loki::DontPropagateConst]' /home/canita/work/loki_smart_auto_ptr/src/loki_smart_auto_ptr.cpp:47: instantiated from 'void DoTest() [with TPtrBase = Loki::SmartPtr<Base, Loki::DestructiveCopy, Loki::DisallowConversion, Loki::AssertCheck, Loki::DefaultSPStorage, Loki::DontPropagateConst>, TPtrDerived = Loki::SmartPtr<Derived, Loki::DestructiveCopy, Loki::DisallowConversion, Loki::AssertCheck, Loki::DefaultSPStorage, Loki::DontPropagateConst>]' /home/canita/work/loki_smart_auto_ptr/src/loki_smart_auto_ptr.cpp:66: instantiated from here /usr/local/include/FerrisLoki/loki/SmartPtr.h:713: error: assignment of read-only reference 'val' /usr/local/include/FerrisLoki/loki/SmartPtr.h: In static member function 'static P Loki::DestructiveCopy<P>::Clone(P1&) [with P1 = Derived* const, P = Base*]': /usr/local/include/FerrisLoki/loki/SmartPtr.h:1181: instantiated from 'Loki::SmartPtr<T, OwnershipPolicy, ConversionPolicy, CheckingPolicy, StoragePolicy, ConstnessPolicy>::SmartPtr(const Loki::SmartPtr<T1, OP1, CP1, KP1, SP1, CNP1>&) [with T1 = Derived, OP1 = Loki::DestructiveCopy, CP1 = Loki::DisallowConversion, KP1 = Loki::AssertCheck, SP1 = Loki::DefaultSPStorage, CNP1 = Loki::DontPropagateConst, T = Base, OwnershipPolicy = Loki::DestructiveCopy, ConversionPolicy = Loki::DisallowConversion, CheckingPolicy = Loki::AssertCheck, StoragePolicy = Loki::DefaultSPStorage, ConstnessPolicy = Loki::DontPropagateConst]' /home/canita/work/loki_smart_auto_ptr/src/loki_smart_auto_ptr.cpp:51: instantiated from 'void DoTest() [with TPtrBase = Loki::SmartPtr<Base, Loki::DestructiveCopy, Loki::DisallowConversion, Loki::AssertCheck, Loki::DefaultSPStorage, Loki::DontPropagateConst>, TPtrDerived = Loki::SmartPtr<Derived, Loki::DestructiveCopy, Loki::DisallowConversion, Loki::AssertCheck, Loki::DefaultSPStorage, Loki::DontPropagateConst>]' /home/canita/work/loki_smart_auto_ptr/src/loki_smart_auto_ptr.cpp:66: instantiated from here /usr/local/include/FerrisLoki/loki/SmartPtr.h:713: error: assignment of read-only reference 'val' /usr/local/include/FerrisLoki/loki/SmartPtr.h: In static member function 'static P Loki::DestructiveCopy<P>::Clone(P1&) [with P1 = Derived* const, P = Derived*]': /usr/local/include/FerrisLoki/loki/SmartPtr.h:1181: instantiated from 'Loki::SmartPtr<T, OwnershipPolicy, ConversionPolicy, CheckingPolicy, StoragePolicy, ConstnessPolicy>::SmartPtr(const Loki::SmartPtr<T1, OP1, CP1, KP1, SP1, CNP1>&) [with T1 = Derived, OP1 = Loki::DestructiveCopy, CP1 = Loki::DisallowConversion, KP1 = Loki::AssertCheck, SP1 = Loki::DefaultSPStorage, CNP1 = Loki::DontPropagateConst, T = Derived, OwnershipPolicy = Loki::DestructiveCopy, ConversionPolicy = Loki::DisallowConversion, CheckingPolicy = Loki::AssertCheck, StoragePolicy = Loki::DefaultSPStorage, ConstnessPolicy = Loki::DontPropagateConst]' gmake[2]: Nothing to be done for `all-am'. /home/canita/work/loki_smart_auto_ptr/src/loki_smart_auto_ptr.cpp:40: instantiated from 'TPtrDerived CreateDerived() [with TPtrDerived = Loki::SmartPtr<Derived, Loki::DestructiveCopy, Loki::DisallowConversion, Loki::AssertCheck, Loki::DefaultSPStorage, Loki::DontPropagateConst>]' /home/canita/work/loki_smart_auto_ptr/src/loki_smart_auto_ptr.cpp:51: instantiated from 'void DoTest() [with TPtrBase = Loki::SmartPtr<Base, Loki::DestructiveCopy, Loki::DisallowConversion, Loki::AssertCheck, Loki::DefaultSPStorage, Loki::DontPropagateConst>, TPtrDerived = Loki::SmartPtr<Derived, Loki::DestructiveCopy, Loki::DisallowConversion, Loki::AssertCheck, Loki::DefaultSPStorage, Loki::DontPropagateConst>]' /home/canita/work/loki_smart_auto_ptr/src/loki_smart_auto_ptr.cpp:66: instantiated from here /usr/local/include/FerrisLoki/loki/SmartPtr.h:713: error: assignment of read-only reference 'val' gmake[2]: *** [loki_smart_auto_ptr.o] Error 1 gmake[2]: Target `all' not remade because of errors. gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2 *** Exited with status: 2 *** The technique and test is described in "Fixing auto_ptr": http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf 1. Direct-initialization, same type 2. Copy-initialization, same type 3. Direct-initialization, base-from-derived 4. Copy-initialization, base-from-derived Test program does not compile for any case. Note: - In a policy-based smart pointer I made, to avoid const issues I used partial specialization for DestructiveCopy; In primary template (copy)(conversion)constructors and assignment operators are const and not const in partial specialization. This way 3 and 4 does not compile, but 1 and 2 compile and run as expected. But assignment does not work. Ex: TPtrBase pbase = CreateBase() // OK but TPtrBase pbase; pbase = CreateBase() // does not compile If I made operator ByRef (RefToValue in Loki) member template, entire test compile but enters infinite loop in ByRef at runtime. - Case 4 does not compile with gcc 4.3.1/4.2.1 also for std::auto_ptr. I've opened a bug but it seems it won't be fixed. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37255 Visual C++ 8 compile test for std::auto_ptr (need to test with 9); Loki not tested on Windows/Visual C++ (I didn't have time). Thanks, Cristian Test program: // loki_smart_auto_ptr.cpp Test program for Loki::SmartPtr configured as auto_ptr using Colvin-Gibbons trick #ifdef HAVE_CONFIG_H #include <config.h> #endif #include <loki/SmartPtr.h> #include <memory> #include <iostream> #include <cstdlib> using namespace Loki; using namespace std; class Base { public: virtual ~Base() {} virtual void Hello() { cout << "Base Hello, world!" << endl; } }; class Derived: public Base { public: virtual void Hello() { cout << "Derived Hello, world!" << endl; } }; typedef auto_ptr<Base> AutoPtrBase; typedef auto_ptr<Derived> AutoPtrDerived; typedef SmartPtr<Base, DestructiveCopy> SmartAutoPtrBase; typedef SmartPtr<Derived, DestructiveCopy> SmartAutoPtrDerived; template <class TPtrBase> TPtrBase CreateBase() { return TPtrBase(new Base); } template <class TPtrDerived> TPtrDerived CreateDerived() { return TPtrDerived(new Derived); } template <class TPtrBase> void UseBase(TPtrBase ptr) { ptr->Hello(); } template <class TPtrBase, class TPtrDerived> void DoTest() { TPtrBase spb1(CreateBase<TPtrBase>()); UseBase<TPtrBase>(CreateBase<TPtrBase>()); TPtrBase spb2(CreateDerived<TPtrDerived>()); // NOTE: this does not compile with gcc 4.3.1 also for std::auto_ptr; // it should work (Copy-initialization, base-from-derived) // according to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf // It does compile with Visual C++ 8 (need to test with 9) //UseBase<TPtrBase>(CreateDerived<TPtrDerived>()); // Quick fix UseBase<TPtrBase>(TPtrBase(CreateDerived<TPtrDerived>())); } int main(int argc, char *argv[]) { DoTest<AutoPtrBase, AutoPtrDerived>(); // OK DoTest<SmartAutoPtrBase, SmartAutoPtrDerived>(); // FIXME: eror: assignment of read-only reference 'val' return EXIT_SUCCESS; } ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-09-16 19:21 Message: Fixed bug by adding const overload of Clone function in DestructiveCopy policy class. Fixed in revision 1101. Test for fix is available in revision 1102. ---------------------------------------------------------------------- Comment By: Peter Kuemmel (syntheticpp) Date: 2008-12-15 14:26 Message: To fix the compile bug we have to disable the (const T&) ctor and use RefToValue, the way how it is done in auto_prt. But I'm not sure about the consequences of such a change. Index: loki/SmartPtr.h =================================================================== --- loki/SmartPtr.h (revision 910) +++ loki/SmartPtr.h (working copy) @@ -1175,6 +1175,7 @@ GetImplRef(*this) = OP::Clone(GetImplRef(rhs)); } + /* template < typename T1, @@ -1187,6 +1188,7 @@ SmartPtr(const SmartPtr<T1, OP1, CP1, KP1, SP1, CNP1 >& rhs) : SP(rhs), OP(rhs), KP(rhs), CP(rhs) { GetImplRef(*this) = OP::Clone(GetImplRef(rhs)); } + */ template < @@ -1205,7 +1207,10 @@ SmartPtr(RefToValue<SmartPtr> rhs) : SP(rhs), OP(rhs), KP(rhs), CP(rhs) - {} + { + SmartPtr& ref = rhs; + GetImplRef(*this) = OP::Clone(GetImplRef(ref)); + } operator RefToValue<SmartPtr>() { return RefToValue<SmartPtr>(*this); } ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2008-11-11 23:14 Message: I tried out the test case presented here. I saw the same error message shown here. The problem occurs because compiler is calling (and instantiating) this constructor Loki::SmartPtr<>::SmartPtr( const Loki::SmartPtr<> & other ) instead of this one: Loki::SmartPtr<>::SmartPtr( Loki::SmartPtr<> & other ) If the compiler used the SmartPtr copy-constructor with the non-const parameter, I don't think it would emitted the error message: "SmartPtr.h:721: error: assignment of read-only reference `val'" for the function: template < class P1 > static P ::Loki::DestructiveCopy::Clone( P1 & val ) Side note: Despite what the original title of this bug report says, I don't this bug is related to the Colvin-Gibbons trick. The code in question does not use RevToValue. It uses other functions in SmartPtr, but not any which make use of RefToValue. I checked the test case in as: loki/test/SmartPtr/colvin_gibbons_trick.cpp. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2080889&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-13 00:32:13
|
Bugs item #3224572, was opened at 2011-03-18 19:48 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3224572&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Richard Sposato (rich_sposato) Summary: SmartPtr: destructive copy from an rvalue is not working Initial Comment: SmartPtr with DestructiveCopy ownership policy can't perform copy construction from an rvalue. #include <Loki/SmartPtr.h> typedef Loki::SmartPtr<int, Loki::DestructiveCopy> Ptr; Ptr makePtr() { return Ptr(new int); } int main() { Ptr ptr = makePtr(); // error! } Constructor taking RefToValue seems to be never called because template constructor with const argument is favoured. Also there is no conversion between RevToValue holding reference to SmartPtr with different pointee types. It seems that the desired behaviour could be achieved by Colvin-Gibbons trick used in std::auto_ptr. However, it's more difficult to implement it in this SmartPtr. I've tried to write my own more lightweight policy-based SmartPtr and came up to some code which I attach here. It's not finished yet, but DestructiveCopy seems to be working. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-09-12 17:32 Message: This is a duplicate of bug 2080889. Closing this bug report so only one report exists for this problem. ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2011-09-08 16:40 Message: Added tests for DestructiveCopy policy. One test is commented out until this bug gets fixed. I did confirm compiler calls wrong constructor when SmartPtr is returned by value - thus leading to bug described here. revision 1097. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3224572&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-09 10:46:16
|
Feature Requests item #3406727, was opened at 2011-09-09 10:42 Message generated for change (Comment added) made by zhnmju123 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=3406727&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: ZenJu (zhnmju123) Assigned to: Nobody/Anonymous (nobody) Summary: Improvement for ScopeGuard Initial Comment: Hi, short version: I ask for a LOKI_ON_BLOCK_EXIT that does not emit a compiler warning about an unused variable on GCC and MSVC. long version: one use of ScopeGuard is as a convenient RAII "cleanup" mechanism, that is without calling "Dismiss()" later. The problem then is that GCC and MSVC emit compiler warnings about an unused variable. This happens both when using a dummy variable without dismissing it and more critically when using "LOKI_ON_BLOCK_EXIT", which is specifically designed for that purpose. As seen here, others have been looking for an answer, but with little success: http://stackoverflow.com/questions/219770/dealing-with-c-initialized-but-not-referenced-warning-for-destruction-of-scop For GCC, there is a nice and simple solution which could be implemented by the Loki library: replace: typedef const ScopeGuardImplBase& ScopeGuard; by __attribute__((unused)) typedef const ScopeGuardImplBase& ScopeGuard; Unfortunately there is no MSVC equivalent. Now with C++11, there might be light at the end of the tunnel: One way to silence the warning about unused variable in both GCC and MSVC is to get rid of the const-reference: typedef const ScopeGuardImplBase& ScopeGuard; -> typedef ScopeGuardImplBase ScopeGuard; It's clear that this creates problems for the general ScopeGuard case where the type is dependent from the number and types of arguments passed. But for LOKI_ON_BLOCK_EXIT, this shouldn't matter. What's still missing is a way to "pass the value without copying". Here C++11 r-value-refences are the fitting solution. You see, there are a few open questions, but my hope is that they can be figured out eventually. Best regards, ZenJu ---------------------------------------------------------------------- >Comment By: ZenJu (zhnmju123) Date: 2011-09-09 10:46 Message: > typedef const ScopeGuardImplBase& ScopeGuard; -> typedef ScopeGuardImplBase ScopeGuard; The example is wrong, but the main idea is to get rid of the reference and move to a value type. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=3406727&group_id=29557 |
From: SourceForge.net <no...@so...> - 2011-09-09 10:42:47
|
Feature Requests item #3406727, was opened at 2011-09-09 10:42 Message generated for change (Tracker Item Submitted) made by zhnmju123 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=3406727&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: ZenJu (zhnmju123) Assigned to: Nobody/Anonymous (nobody) Summary: Improvement for ScopeGuard Initial Comment: Hi, short version: I ask for a LOKI_ON_BLOCK_EXIT that does not emit a compiler warning about an unused variable on GCC and MSVC. long version: one use of ScopeGuard is as a convenient RAII "cleanup" mechanism, that is without calling "Dismiss()" later. The problem then is that GCC and MSVC emit compiler warnings about an unused variable. This happens both when using a dummy variable without dismissing it and more critically when using "LOKI_ON_BLOCK_EXIT", which is specifically designed for that purpose. As seen here, others have been looking for an answer, but with little success: http://stackoverflow.com/questions/219770/dealing-with-c-initialized-but-not-referenced-warning-for-destruction-of-scop For GCC, there is a nice and simple solution which could be implemented by the Loki library: replace: typedef const ScopeGuardImplBase& ScopeGuard; by __attribute__((unused)) typedef const ScopeGuardImplBase& ScopeGuard; Unfortunately there is no MSVC equivalent. Now with C++11, there might be light at the end of the tunnel: One way to silence the warning about unused variable in both GCC and MSVC is to get rid of the const-reference: typedef const ScopeGuardImplBase& ScopeGuard; -> typedef ScopeGuardImplBase ScopeGuard; It's clear that this creates problems for the general ScopeGuard case where the type is dependent from the number and types of arguments passed. But for LOKI_ON_BLOCK_EXIT, this shouldn't matter. What's still missing is a way to "pass the value without copying". Here C++11 r-value-refences are the fitting solution. You see, there are a few open questions, but my hope is that they can be figured out eventually. Best regards, ZenJu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=3406727&group_id=29557 |