[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: MSVC compiler support [patch 17]: octinterp.dll exported symbols

From: michael . goffioul
Subject: RE: MSVC compiler support [patch 17]: octinterp.dll exported symbols
Date: Fri, 27 Oct 2006 12:45:04 +0200

> Is it OK to do the use OCTAVE_EXPORT, and define that appropriately in
> config.h?  Currently, OCTAVE_EXPORT is defined to be empty unless
> _MSC_VER is defined, but that might change in the future.

> This seems to be needed because HAVE_ATEXIT is not defined.  Is atexit
> really not available, or is there some problem with it?  If there was
> a problem, I'd like to try to find a solution because we need to have
> some kind of atexit functionality.

atexit() is available under MSVC. I don't remember why I did it (probably
while trying something), but from a code point-of-view, such an include
would be necessary if HAVE_ATEXIT is not defined. From a MSVC point
of view, you can leave out this change.
> + #ifdef _MSC_VER
> + #ifndef OCTINTERP_API
> + #define OCTINTERP_API __declspec(dllimport)
> + #endif
> + #endif
> +  
>  #include "mexproto.h"

>   /* V4 floating point routines renamed in V5.  */
> I'm not sure I understand why this is defined here instead of in
> mexproto.h since no symbols in mex.h are tagged with OCTINTERP_API,
> but many symbols in mexproto.h are.  It would be better to have this
> declared in config.h or some other header that is included in
> mexproto.h.  Perhaps we need to have a header template like this

Yes, it would be better located in mexproto.h. The problem I had, while
porting a MEX file I had, was that when you simply include mex.h, config.h
is not included and OCTINTERP_API is not defined, leading to problems
at link time. So I added this manual OCTINTERP_API definition. But
maybe the idea is that the user is required to include config.h instead.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]