Recent changes to feature-requests

Loki not supported for Visual studio 2013

Salma — Thu, 06 Aug 2015 11:31:21 -0000

Currently am using Visual studio 2013 and am not able to build loki with visual studio 2013 . Require support for building loki using VS 2013

Improvement for ScopeGuard

Zenju — Fri, 09 Sep 2011 10:42:46 -0000

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

Include a text copy of the license

Sergio Pascual — Fri, 09 Jul 2010 20:54:27 -0000

The source code should include a text copy of the license under loki-lib is released

File Include variant

Zenju — Tue, 20 Apr 2010 08:21:24 -0000

Hi Rich,

> If you have further questions, please feel free to add them here.
Hopefully this doesn't seem like spamming, but you checked "Close comment posting" for the other ticket, so I need to create a new one ;)
Reference: https://sourceforge.net/tracker/?func=detail&atid=396647&aid=2989216&group_id=29557

> potential ambiguity
With "" There is a fixed sequence in which the preprocessor looks for the file. It first starts searching in the directory that holds the sourcefile using an "#include". If it is found, it stops, so there is no ambiguity for users.

So from a library user's point of view using "" doesn't seem to introduce any drawbacks, but at least saves one precondition (project include path). Looking at the style of the library as a whole, avoiding dependencies seems to be a major design goal?

Regards, ZenJu

File Include variant

Zenju — Mon, 19 Apr 2010 08:16:14 -0000

This is regarding ticket:
https://sourceforge.net/tracker/?func=detail&atid=396644&aid=2987337&group_id=29557

If using either of the following two styles is equivalent from Loki implementation point of view:
#include "File.h"
#include <loki/File.h>

Then I kindly ask for using the first style internally. The advantage would be to save the user from needing a project-global Include like "#include C:\LokiParentDir".
Instead one could include any of the Loki files directly without further prerequisites.
On the other hand the user could still use a project-global include to enable the "#include <loki/somefile.h> syntax for his projects. So the user of the library would have both options which is very flexible.

Regards, ZenJu

[threads] improving atomic ops.

Pawel Sikora — Sun, 01 Feb 2009 21:05:07 -0000

the current loki uses for AtomicIncrement/Decrement winapi critical sections or pthread mutexes.
this can be done faster:
- with winapi: InterlockedIncrement/Decrement
- with gcc: __sync_add/sub_and_fetch ) builtins that are translated into e.g. xadd opcode on x86.

#ifdef _MSC_VER
#include <windows.h>
#endif

long increment( long& counter )
{
return ::InterlockedIncrement( &counter );
}

long decrement( long& counter )
{
return ::InterlockedDecrement( &counter );
}

#elif ( __GNUC__ == 4 ) && ( __GNUC_MINOR__ >= 1 )

long increment( long& counter )
{
return __sync_add_and_fetch( &counter, 1 );
}

long decrement( long& counter )
{
return __sync_sub_and_fetch( &counter, 1 );
}

#else

// legacy implementation with mutextes.

#endif

Alternate Functor Implementation

Matthew Elkins — Sat, 31 Jan 2009 15:36:05 -0000

This is the zipped Alternate Functor Implementation code, as described in my topic of the same name. This is the same as I originally pasted, so the same notes apply.
-Matt Elkins

Function and Bind

Peter Kuemmel — Sun, 01 Jul 2007 18:32:38 -0000

https://sourceforge.net/forum/forum.php?thread_id=1706311&forum_id=93009

Cooperative Visitor

Peter Kuemmel — Sun, 01 Jul 2007 18:31:06 -0000

https://sourceforge.net/forum/forum.php?thread_id=1720363&forum_id=93010

Change to ScopeGuard - allow array deletion

Peter Kuemmel — Sun, 01 Jul 2007 18:18:37 -0000

https://sourceforge.net/forum/forum.php?thread_id=1723718&forum_id=93008