Menu
▾
▴
pclasses-devel — P::Classes developer mailing-list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(188) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(59) |
Feb
(13) |
Mar
(4) |
Apr
(1) |
May
(15) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Prochnow, C. <cp...@se...> - 2005-07-04 23:58:05
|
Hi List,
i just wanted to say that the Unicode support in P2 is making progress ...
after some beers, and writing a small test, i must definitely say it really
rocks !!
Look at this code:
--
File f("test.txt", File::Write); /* open "test.txt" for writing... */
TextStream strm(f); /* we want to stream text to the file ... */
String str("abcdefg");
str.append(Char(0x00e4)); /* adds a german umlaut to the string ... */
strm.setCodepage("ebcdic-de"); /* let's output in German EBCDIC encoding */
strm << str;
strm.setCodepage("utf32"); /* let's output in utf32 ... */
strm << str;
strm.setCodepage("utf8"); /* dont waste so much space .. use utf8 ;) */
strm << str;
--
cool .. isn't it ?
TextStream's on-the-fly codepage-conversion enables us to transparently
input/output text in any encoding ICU supports.
Thats it, back to the coding session ...
Greetings,
Christian
|
|
From: Prochnow, C. <pro...@se...> - 2005-05-31 11:13:46
|
Am Sonntag 29 Mai 2005 20:12 schrieb stephan beal:
> On Sunday 29 May 2005 19:54, Prochnow, Christian wrote:
> > see Factory.h Revision 1.21:
> > --
> > template <typename TypeName>
> > void registerType( const key_type & key, TypeName )
> > {
> > registerFactory( key,
> > Hook::FactoryCreateHook<InterfaceT,TypeName>::create );
> > }
>
> Nope. Check the CVS log, version 1.18:
> cproch:
> Added Factory::registerType(). Client code looks nicer when using it ;-)
>
> :)
Ups .. sorry, i forgot that ... ;-)
Anyway, we now have a registerType() method which doesnt require instantiating
the registered type.
Regards,
Christian
|
|
From: stephan b. <st...@s1...> - 2005-05-29 18:18:59
|
On Sunday 29 May 2005 19:54, Prochnow, Christian wrote:
> see Factory.h Revision 1.21:
> --
> template <typename TypeName>
> void registerType( const key_type & key, TypeName )
> {
> registerFactory( key,
> Hook::FactoryCreateHook<InterfaceT,TypeName>::create );
> }
Nope. Check the CVS log, version 1.18:
cproch:
Added Factory::registerType(). Client code looks nicer when using it ;-)
:)
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|
|
From: Prochnow, C. <pro...@se...> - 2005-05-29 17:54:08
|
Am Freitag 27 Mai 2005 19:09 schrieb stephan beal: > On Friday 27 May 2005 16:46, Prochnow, Christian wrote: > > but when using type_info::name().. the type_info object returns the > > mangled c++ ABI name of the type which _must_ be the same in all > > compilation units. > > > > see this: http://gnu.open-mirror.com/software/gcc/faq.html#dso > > i wish the GCC guys would all read that. ;) i will swear on my life i've > seen type_info::name() returns two different strings for the same type, > depending on their creation scope. That was way back in 3.0/3.1, too, > so maybe it doesn't happen anymore. > > In any case that page only applies to gcc. According to C++, what name() > returns is UNDEFINED. Scott Meyers covers this in detail in one of his > books. The way he puts it, even an implementation in which name() > returns an empty string for every class is fully compliant with the > standard. Not useful, but compliant. i will keep that in mind for further investigation... > > i think we can make the second argument a const reference type. > > That still requires instantiating it, a limitation i haven't ever needed > in a factory implementation. i've added a second Factory::registerType method which does not require constructing a temporary object. One could also use Factory::registerFactory like in your old implementation. Btw... you're old Factory implementation did also require constructing a temporary object ;-) see Factory.h Revision 1.21: -- template <typename TypeName> void registerType( const key_type & key, TypeName ) { registerFactory( key, Hook::FactoryCreateHook<InterfaceT,TypeName>::create ); } Greetings, Christian |
|
From: stephan b. <st...@s1...> - 2005-05-27 17:21:27
|
On Friday 27 May 2005 16:52, Prochnow, Christian wrote: > > i'm almost 100% certain that that's a side-effect of the Hook, not > > the Phoenix. i'm glad you changed the way that worked, anyway. > > Indeed, this was a side-effect of the Hook code. i'm glad you caught that. i just removed the hook-style code from the s11n tree. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-05-27 17:20:21
|
On Friday 27 May 2005 16:49, Prochnow, Christian wrote: > I think you use the toc-build system. Right - running the autotools which shipped with the last 2 versions of Suse cannot build the p1/p2 dialects of input files: stephan@owl:~/cvs/pclasses2> ./autogen.sh /usr/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/share/aclocal/paragui.m4:12: warning: underquoted definition of AM_PATH_PARAGUI aclocal:configure.in:241: warning: macro `AM_WITH_EXPAT' not found in library Putting files in AC_CONFIG_AUX_DIR, `admin'. /usr/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/share/aclocal/paragui.m4:12: warning: underquoted definition of AM_PATH_PARAGUI aclocal:configure.in:241: warning: macro `AM_WITH_EXPAT' not found in library configure.in:241: error: possibly undefined macro: AM_WITH_EXPAT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:252: error: possibly undefined macro: AC_raf_FUNC_WHICH_GETSERVBYNAME_R configure.in:286: error: possibly undefined macro: AC_PREFIX_CONFIG_H autoreconf: /usr/bin/autoconf failed with exit status: 1 i don't use autotools in any projects because the AT team insists on breaking compatibility on every new release, and i always had to spend dozens of hours having to un-break my source trees after upgrading my autotools. > If no native atomic-int support was detected, the preprocessor symbol > must not be defined and AtomicInt.xxxxx.cpp should not be compiled > into the library. i'll take a look. Thanks :) -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-05-27 17:16:13
|
On Friday 27 May 2005 16:46, Prochnow, Christian wrote: > but when using type_info::name().. the type_info object returns the > mangled c++ ABI name of the type which _must_ be the same in all > compilation units. > > see this: http://gnu.open-mirror.com/software/gcc/faq.html#dso i wish the GCC guys would all read that. ;) i will swear on my life i've seen type_info::name() returns two different strings for the same type, depending on their creation scope. That was way back in 3.0/3.1, too, so maybe it doesn't happen anymore. In any case that page only applies to gcc. According to C++, what name() returns is UNDEFINED. Scott Meyers covers this in detail in one of his books. The way he puts it, even an implementation in which name() returns an empty string for every class is fully compliant with the standard. Not useful, but compliant. > i think we can make the second argument a const reference type. That still requires instantiating it, a limitation i haven't ever needed in a factory implementation. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Prochnow, C. <pro...@se...> - 2005-05-27 14:58:18
|
Am Donnerstag 26 Mai 2005 15:32 schrieb stephan beal: > Doh?? i've never seen this problem in s11n, and i've used that approach > since well over a year. I ran into the problem when compiling on architectures other than x86. > ... > i'm almost 100% certain that that's a side-effect of the Hook, not the > Phoenix. i'm glad you changed the way that worked, anyway. Indeed, this was a side-effect of the Hook code. Greetings, Christian |
|
From: Prochnow, C. <pro...@se...> - 2005-05-27 14:49:15
|
Am Donnerstag 26 Mai 2005 17:54 schrieb stephan beal:
> g++ -pipe -Wall -Werror -g -DDEBUG -D_DEBUG -fPIC -I. -I../include
> -c -o AtomicInt.gcc-x86.o AtomicInt.gcc-x86.cpp
> AtomicInt.gcc-x86.cpp:30: error: template-id `set<>' for `void
> P::Traits::AtomicTraits<int>::set(int*, int)' does not match any
> template
> declaration
> AtomicInt.gcc-x86.cpp:30: error: syntax error before `{' token
> AtomicInt.gcc-x86.cpp:34: error: syntax error before `::' token
> AtomicInt.gcc-x86.cpp:39: error: syntax error before `::' token
> AtomicInt.gcc-x86.cpp:47: error: syntax error before `::' token
> AtomicInt.gcc-x86.cpp:57: error: syntax error before `::' token
> AtomicInt.gcc-x86.cpp:65: error: syntax error before `::' token
> make[1]: *** [AtomicInt.gcc-x86.o] Error 1
I think you use the toc-build system.
If you have a look in the header AtomicTraits.h, you will see that the
PCLASSES_HAVE_ATOMIC_INT preprocessor should be defined when
AtomicInt.gcc-x86.cpp is compiled into the library.
If no native atomic-int support was detected, the preprocessor symbol must not
be defined and AtomicInt.xxxxx.cpp should not be compiled into the library.
Greetings,
Christian
|
|
From: Prochnow, C. <pro...@se...> - 2005-05-27 14:46:22
|
Am Freitag 27 Mai 2005 16:06 schrieb stephan beal: > i'm going through the code now, and i've got a couple of concerns: > > #1: > return static_cast<Factory&>( > FactoryBase::instance(typeid(InterfaceT).name(), > typeid(ContextT).name(), &createHook)); > > typeid::name() OFFICIALLY provides undefined behaviour. Under gcc i have > seen cases where typeid(T*).name() will return 2 different values, > depending on whether T comes from a DLL or was statically linked. > > i spent months fighting with typeid::name() in s11n before finally > dropping it altogether. i promise: it cannot be trusted at all. that's not fully true. it's right that gcc emits type_info objects in the compilation unit where they are used, therefore you cannot simply compare two type_info objects, cause gcc does a address comparsion. but when using type_info::name().. the type_info object returns the mangled c++ ABI name of the type which _must_ be the same in all compilation units. see this: http://gnu.open-mirror.com/software/gcc/faq.html#dso > Also, why do you need the static cast there? the static_cast is needed to up-cast the FactoryBase to the Factory. > #2: > > template <class TypeName> > void registerType(const std::string& key, TypeName) > { > registerFactory(key, &typeCreateHook<TypeName>); > } > > Why are we forced to pass a TypeName object? That is not at all suitable > for large types. If i'm not mistaken, it also means that we cannot > call registerType if TypeName is an incomplete type, where we can > (i think) if the user does not pass a TypeName object. i think we can make the second argument a const reference type. Greetings, Christian |
|
From: stephan b. <st...@s1...> - 2005-05-27 14:12:35
|
On Wednesday 18 May 2005 16:28, Prochnow, Christian wrote:
> i've rewritten the Factory and PluginManager! The old one had some
> problems which could not be solved with the old implementation:
...
i'm going through the code now, and i've got a couple of concerns:
#1:
return static_cast<Factory&>(
FactoryBase::instance(typeid(InterfaceT).name(),
typeid(ContextT).name(), &createHook));
typeid::name() OFFICIALLY provides undefined behaviour. Under gcc i have
seen cases where typeid(T*).name() will return 2 different values,
depending on whether T comes from a DLL or was statically linked.
i spent months fighting with typeid::name() in s11n before finally
dropping it altogether. i promise: it cannot be trusted at all.
Also, why do you need the static cast there?
#2:
template <class TypeName>
void registerType(const std::string& key, TypeName)
{
registerFactory(key, &typeCreateHook<TypeName>);
}
Why are we forced to pass a TypeName object? That is not at all suitable
for large types. If i'm not mistaken, it also means that we cannot
call registerType if TypeName is an incomplete type, where we can
(i think) if the user does not pass a TypeName object.
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|
|
From: stephan b. <st...@s1...> - 2005-05-26 16:00:17
|
g++ -pipe -Wall -Werror -g -DDEBUG -D_DEBUG -fPIC -I. -I../include
-c -o AtomicInt.gcc-x86.o AtomicInt.gcc-x86.cpp
AtomicInt.gcc-x86.cpp:30: error: template-id `set<>' for `void
P::Traits::AtomicTraits<int>::set(int*, int)' does not match any
template
declaration
AtomicInt.gcc-x86.cpp:30: error: syntax error before `{' token
AtomicInt.gcc-x86.cpp:34: error: syntax error before `::' token
AtomicInt.gcc-x86.cpp:39: error: syntax error before `::' token
AtomicInt.gcc-x86.cpp:47: error: syntax error before `::' token
AtomicInt.gcc-x86.cpp:57: error: syntax error before `::' token
AtomicInt.gcc-x86.cpp:65: error: syntax error before `::' token
make[1]: *** [AtomicInt.gcc-x86.o] Error 1
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|
|
From: stephan b. <st...@s1...> - 2005-05-26 13:43:25
|
On Wednesday 18 May 2005 16:28, Prochnow, Christian wrote: > 1) The first problem was that using Phoenix<> inside of a template > leads to different instances used by client- and library-code. We > should keep that in mind - never use Phoenix<> inline or inside of a > template !! Doh?? i've never seen this problem in s11n, and i've used that approach since well over a year. > 2) The second problem was the FactoryInstanceHook code. I wondered > why Factory::create() could not create a type which should be ... > remember, the goal was that Factory can create types that are > dynamically registered by shared libraries, without even knowing > about shared libraries. Good :). The Hook thing was weird, and i wasn't really happy with it. > 1) Instances of Factory are now kept by the FactoryBase class, which ... > requested Factory > (Factory::createHook()). Sounds cool :). > A draw-back is that the new Factory implementation does not support a > variable key-type, since it is not possible for the non-templated > FactoryBase to have variable key-types. Maybe we can re-introduce > this feature, if it's really needed, by using key-string's generated > by LexT<>. That's a rarely-used feature, in my experience. i use it sometimes for mapping enum entries to types, but it's certainly not critical. > We now have an instance of the FileLogTarget class which got > dynamically registered by the shared-library, cool .. isnt it ? > > With the old Factory and PluginManager code clients had to be aware > that FileLogTarget did come from a plugin and therefore had to use > PluginManager<LogTarget>::create() instead of > Factory<LogTarget>::create(). i'm almost 100% certain that that's a side-effect of the Hook, not the Phoenix. i'm glad you changed the way that worked, anyway. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-05-26 13:41:17
|
Yo! i'm finally connected to the net at home, so i will start getting caught up, get any toc build files up to date, and whatnot... -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Prochnow, C. <pro...@se...> - 2005-05-18 14:55:58
|
Hi List, i've added a Tracing-solution to the core-module. To make use of it simply #include <pclasses/Trace.h> and make use of the two trace-macros. For trace-messages generated inside of a class use: P_TRACE(classname) << "My class trace message"; For global trace-messages use: P_TRACE_GLOBAL() << "My global trace message"; The message is flushed after the stream-operation is complete - eg. after ";". You dont have to use "endl". When compiled with debug enabled (-D_DEBUG) the trace-macros make use of the TraceLog and TraceStream classes. When compiled without debug the trace-macros will use the NullTraceStream class which should be optimized to zero overhead. The TraceLog class is thread-safe. Regards, Christian |
|
From: Prochnow, C. <pro...@se...> - 2005-05-18 14:27:57
|
Hi List,
i've rewritten the Factory and PluginManager! The old one had some problems
which could not be solved with the old implementation:
1) The first problem was that using Phoenix<> inside of a template leads to
different instances used by client- and library-code. We should keep that in
mind - never use Phoenix<> inline or inside of a template !!
2) The second problem was the FactoryInstanceHook code. I wondered why
Factory::create() could not create a type which should be dynamically loaded
by the PluginManager. After figuring out how the old code worked, i realized
that one had to use PuginManager::create() instead of Factory::create() to
make use of the "dynamically loadable types" feature, which was not feasible.
I remember, the goal was that Factory can create types that are dynamically
registered by shared libraries, without even knowing about shared libraries.
Ok, now the solution:
1) Instances of Factory are now kept by the FactoryBase class, which is
implemented in the library itself. Instances of Factory are retrieved and
created by a call to FactoryBase::instance(). FactoryBase::instance() uses a
callback to create an instance of the requested Factory
(Factory::createHook()).
2) FactoryBase holds a list of registered type-loader callbacks, which can be
registered via FactoryBase::registerLoader(). The type-loader callbacks are
called by Factory::create() whenever a type should be created, which is not
known to the Factory. This enables the PluginManager to register a
type-loader which tries to dynamically load types from shared libraries. The
PluginManager's type-loader is statically registered upon application init.
Some notes:
FactoryBase and PluginManager must distinguish between different Interface-
and Context-types, since these classes are non-templates, they use
type-strings obtained by a call to the RTTI typeid() function.
A draw-back is that the new Factory implementation does not support a variable
key-type, since it is not possible for the non-templated FactoryBase to have
variable key-types. Maybe we can re-introduce this feature, if it's really
needed, by using key-string's generated by LexT<>.
The Factory-class is now thread-safe. I added the CoreMutex class to get rid
of the dependency on the System-module in the AtomicTraits class, which
should be only used by classes in the core-module.
Example:
suppose we have a shared-library named "FileLogTarget.so" which implements the
LogTarget interface. The class inside the library is also named
"FileLogTarget".
// add directory where plugins are located
PluginManager::instance().addPluginDir<LogTarget>("./plugins");
// create an instance of FileLogTarget
LogTarget* target = Factory<LogTarget>::instance().create("FileLogTarget");
We now have an instance of the FileLogTarget class which got dynamically
registered by the shared-library, cool .. isnt it ?
With the old Factory and PluginManager code clients had to be aware that
FileLogTarget did come from a plugin and therefore had to use
PluginManager<LogTarget>::create() instead of Factory<LogTarget>::create().
Regards,
Christian
|
|
From: stephan b. <st...@s1...> - 2005-04-26 16:25:44
|
On Friday 25 March 2005 09:25, stephan beal wrote: > i'm finally moving into my new flat today and do not yet have any > sort of internet connection set up. Hiya! i'm all moved, but i still have no net connection at home. i now have an office with network, but i'm only there once a week or less. So... just to pop in and say that i've downloaded the last months' worth of mail, and if i owe any of you any replies i will have those on the way soon (probably sent in the same batch as this mail)... See ya! -- ----- st...@s1... http://s11n.net "Pleasure is a grace... not obedient to the commands of the will." -- Alan W. Watts. |
|
From: stephan b. <st...@s1...> - 2005-03-25 08:31:08
|
Yo! FYI: i'm finally moving into my new flat today and do not yet have any sort of internet connection set up. That means i'll be offline for some indeterminate amount of time until i get around to doing that. My net access at work is quite limited and i can't use that address to post to public forums, so i'm out of luck there, as well. Some of you have my mobile number or work email address: feel free to use them if you'd like to get in touch. Until then... Happy hacking! -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-03-12 14:33:02
|
i realized this morning: One of the reasons that the factory registrations works at all is because anonymous namespaces create per-complication-unit copies of the factory registration code. What this means is that some factories may be registered from multiple places: the main app and arbitrary DLLs. If we deregister a factory when a sentry destructs then we might remove a factory which has been registered multiple times, and therefor should not be removed. The obvious "solution" would be to implement factory registration tracking of some sort: track which sentry registers which factory. i'm not at all certain how feasible this is, nor whether it would actually solve the problem, though. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-03-04 01:23:35
|
Yo! i'm coding and needed a quick kludge to generate some make deps so i can generate some headers only if other code actually uses them. i wanted the make code to work both in toc makefiles and non-toc makefiles, so i had to find a portable way to clean up the temp deps file. i like the solution, shown on the last line: SS_DEPS = .sigslot.deps $(SS_DEPS): Makefile $(wildcard *.hpp *.cpp) @grep -le '# *include.*sigslot.hpp' *.?pp | \ sed -e 's/$$/: sigslot.generated.hpp/' \ > $@ include $(SS_DEPS) BOGO = $(shell rm $(SS_DEPS)) No more having to clean up deps files, assuming you use a deps generator which is fast enough (the one in the toc tree was taken from the linux source tree, and is FAST). -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-03-02 18:18:04
|
Hiya!
Last night i came up with a theory for solving what i will call the
"dangling factory" problem of closing plugins. Consider this scenario:
- Open Plugin X. That plugin contains several classes which
automatically register with P::Factory<SomeClass>, so that our factory
now knows about them.
- At some point we close the plugin.
- Someone calls Factory<SomeClass>::instance().create( "SomeClass" ).
Doh! The factory entry is still in Factory<>, but points to memory which
has been released. One of three things will happen:
a) If we're lucky, an immediate segfault. Undefined behaviour. We could
inject marker symbols into plugin DLLs and SharedLib could
theoretically check for those to perhaps avoid a segfault, and throw
SharedLibException instead.
b) If we're unlucky, something else is at that address which is
call-compatible with our factory and we call that code. Undefined
behaviour.
c) Something "really odd" happens and it somehow continues to work.
(Probably "not possible".) Undefined behaviour.
Now, let's consider the factory registration process, as it exists right
now in libs11n and in P2: when a DLL (or the main app) is opened,
statically-initialized POD variables get initialized. The
initialization code contains a function call to our factory
registration. This is what i call the "static initialization trick" of
classloader registration.
That trick works all fine and well, but has one significant problem:
closing the DLL in which it exists leaves the factory entry lying
around.
The scoped_signal class i posted the other night holds the key to that
problem: don't use PODs to initialize the factory registration, but use
static OBJECTS, instead. Now we have, instead of a pod, something like
this:
struct MyReg
{
static MyReg bogo;
MyReg() { register factory ... }
~MyReg() { deregister factory ... }
};
MyReg MyReg::bogo = MyReg();
IN THEORY, when we do dlclose(), the static destruction phase will kick
in and destroy bogo. Lass mich IN THEORY /stark/betonen/. What i do not
know is if dlclose() ever calls static destruction, especially if the
dlopen() call uses the equivalent of RESOLVE_IMMEDIATELY (or whatever
it's called) to resolve all symbols at the moment it's loaded (instead
of lazy resolution).
To be clear: this does NOT solve the whole inherent problem of dangling
resources when closing a DLL. It does solve the problem of dangling
factories (in theory).
?????????? Could this work ???????????
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|
|
From: stephan b. <st...@s1...> - 2005-02-28 16:50:25
|
On Monday 28 February 2005 13:04, Christian Prochnow wrote: > The calls to EventQueue::instance() and FdListenerList::instance() > should not be commented out, as they create the main-thread instances > of them ! > > I've removed the comments, so that the code calls instance() again. But then it won't compile with -Werror. Try removing the references which catch the return values: T & t = foo(); =====> foo(); The problem is that we've got named references but they're never used, so they're "unused variables". -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Christian P. <cp...@se...> - 2005-02-28 12:03:58
|
On Sunday 27 February 2005 18:18, stephan beal wrote: > Hiya! i just corrected a missing var in SimpleApp and came across this > code: > > #ifdef SIGTERM > > ::signal(SIGTERM, &signalHandler); > > #endif > #ifdef SIGQUIT > > ::signal(SIGQUIT, &signalHandler); > > #endif > #ifdef SIGINT > > ::signal(SIGINT, &signalHandler); > > #endif > > Coincidentally... please take a look at the attached class. It greatly > simplifies/safe-ifies this type of manipulation, and is EASY to use. > If it's okay with you i'll put it in the tree (or you can). Where should > it go (in App or System?). The signal-handling code in SimpleApp is obsolete. Signals are now handled by the SignalListener class. The calls to EventQueue::instance() and FdListenerList::instance() should not be commented out, as they create the main-thread instances of them ! I've removed the comments, so that the code calls instance() again. Greetings, Christian |
|
From: stephan b. <st...@s1...> - 2005-02-27 17:21:49
|
Hiya! i just corrected a missing var in SimpleApp and came across this code: #ifdef SIGTERM ::signal(SIGTERM, &signalHandler); #endif #ifdef SIGQUIT ::signal(SIGQUIT, &signalHandler); #endif #ifdef SIGINT ::signal(SIGINT, &signalHandler); #endif Coincidentally... please take a look at the attached class. It greatly simplifies/safe-ifies this type of manipulation, and is EASY to use. If it's okay with you i'll put it in the tree (or you can). Where should it go (in App or System?). ---------- Forwarded Message ---------- Subject: you ever work with C signals? Date: Sunday 27 February 2005 14:31 From: stephan beal <st...@s1...> To: James McCann <jm...@es...> Last night i came up with a handy little class for embedding C signal handlers in different scopes. It wraps up a signal handler for a given scope and then restores it to the original when it goes out of scope. This allowed me to easily solve most/all of the ctrl-c problems in teeny because i can more easily block of one specific block for signal handling without having to care about existing handlers. It doesn't inherently have any longjmp support, but i'm not yet sure if a) it needs it and b) that can be generically handled in a class like this. Attached - a standalone file suitable for inclusion in your projects... -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-02-27 03:26:38
|
On Sunday 27 February 2005 00:25, Christian Prochnow wrote: > i don't understand this warning cause the comparsion is against an > unsigned char, which can hold 0xff. wtf ? Right, but if that succeeds, then NONE of the rest of the if() can every be checked. That's the problem: you've covered all cases with that one check. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
