I was originally using the Release build, but recompiling to Debug I
get exactly the same behaviour. Also, I tried putting in a
printf("LogEntry: %p", __LOGENTRY__); at the bottom of a method to see
if that would stop the destructor being called straight away, but I
get the same messages.Cheers Andy On 11/17/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
Sounds about right. I've come across this problem before. Is this with a Release build? I'd expect a Debug build to switch that optimisation off. Cheers, On 17/11/06, Andrew Borley <[EMAIL PROTECTED]> wrote: > > Hi again Sebastien, > > I'm using the new logging stuff and have just noticed that the > logentry() macro doesn't seem to be working properly - the entry > message is always immediately followed by the exit message, even when > there are nested calls to other methods within the current one. e.g: > > >> tuscany::sca::SCARuntime::getInstance > << tuscany::sca::SCARuntime::getInstance > >> tuscany::sca::SCARuntime::SCARuntime > << tuscany::sca::SCARuntime::SCARuntime > >> tuscany::sca::SCARuntime::loadExtensions > << tuscany::sca::SCARuntime::loadExtensions > >> tuscany::sca::Library::Library > << tuscany::sca::Library::Library > >> tuscany::sca::Library::load > << tuscany::sca::Library::load > ... > AFAICT the logEntry() macro creates an EnabledLogEntry object named > __LOGENTRY__ which should then be cleaned up when the method exits. > The entry and exit messages are output at construction and destruction > of the EnabledLogEntry object, so it should work. But it looks like > the object is being cleaned up as soon as it is initialised - could > this be a compiler optimisation that's throwing away the object as it > is not used in the rest of the method? I see the same behaviour on > Windows and Fedora Core 5. > > Any ideas? > > Cheers > > Andy > > On 11/13/06, Andrew Borley <[EMAIL PROTECTED]> wrote: > > On 11/13/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > Andrew Borley wrote: > > > > Hi Sebastien, > > > > > > > > I'm getting a build failure on windows (VC7) dur to the new-style > > > > logging stuff you've put in: > > > > ../../../runtime\core\src\tuscany\sca\util\Logging.h(35) : error > > > > C2010: '.' : unexpected in macro formal parameter list > > > > > > > > I think this is due to the VC7 compiler not supporting variable-arg > > > > macros - doing a search for the error throws up this post: > > > > http://www.codeguru.com/forum/showthread.php?t=318438 which states > at > > > > the bottom that "macros with variable arguments are not supported by > > > > ANSI C++.". There is a suggested workaround that we could use which > > > > requires the arguments to be parenthesized: > > > > > > > > #define FUNC(foo) ThisFunc foo > > > > > > > > void ThisFunc(int, ...); > > > > > > > > int main() > > > > { > > > > FUNC((123, 456)); > > > > } > > > > > > > > What do you think? > > > > > > > > Cheers > > > > Andrew > > > > > > > > > > Andy, > > > > > > Sorry for breaking the VC7 build... VC++ express 2005 was happy with > the > > > new macros, I didn't imagine it would be different with VC7. > > > > > > I may have more time to look into it later this evening, but I made a > > > quick change to the loginfo/logwarning/logerror macros under revision > > > r474517 to be similar to the Windows Afx TRACE macro. This provides > the > > > same simple usage without __VA_ARGS or requiring the arguments to be > > > parenthesized. > > > > > > This builds OK on Linux, still builds OK on Windows with VC++ express > > > 2005. I think it will work with VC7 but I can't test it as I only have > > > VC++ express 2005. Would you mind giving it a try? > > > > > > > That builds fine on VC7 now - thanks Sebastien! > > > > Andy > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Pete
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
