CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 5 of 5

Hybrid View

  1. #1
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    A neat way of exporting DLL symbols?

    I know that in MSVC we can export all symbols from a C++ class by using a suitable export specifier applied to the whole class. Or alternatively we can export certain functions selectively by preceding each declaration individually with __declspec(dllexport). But apparently the gcc processor has a neat little pragma for doing this - e.g.

    Code:
    #define MY_EXPORT_SPECIFIER  __attribute__ ((visibility ("default")))
    
    class MY_EXPORT_SPECIFIER MyClass 
    {
          // c'tor and d'tor get exported due to MY_EXPORT_SPECIFIER
          MyClass();
          ~MyClass();
    
    private:
          // Private data and functions are not exported
    #pragma GCC visibility push(hidden)
    
          // Declare private data and functions
    #pragma pop
    
    public:
          // Publicly declared functions are now exported again 
    }
    ;

    Okay, it might seem a bit lazy but I think that's quite neat - much better than the MSVC way of needing to address each function individually. Or is it? Is there any similar little trick we can do in MSVC?
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  2. #2
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: A neat way of exporting DLL symbols?

    exporting a single function and exporting a class serve different purposes.

    I kinda fail to see why you'd want to export a whole class, but then not export the private/protected parts thereof, that seems like a bad idea on so many levels.
    It means you can't extend the class properly through inheritance since part of the interface is inaccessible.
    and it means that some of the inline's may not even work.
    It probably gives you the false impression "it's a good idea", but if you only wanted the member functions... Then why did you export the whole class and give an apparent indication you want the class to be exptendable outside the dll.

    "being lazy" is a bad excuse for not doing something properly.

  3. #3
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: A neat way of exporting DLL symbols?

    Very good points but my question was more to find out if there's a way to "group" functions to be exported without either (a) exporting them all individually, or (b) exporting the entire class.

    For example... in a C++ DLL it's possible to remove name decoration from a bunch of 'C' functions like this:-

    Code:
    extern "C" {
          // A list of functions
    }
    so wouldn't it be useful to be able to do this:-

    Code:
    __declspec(dllexport) {
          // A list of functions
    }
    The GCC approach is slightly convoluted but in effect, that's what it achieves.
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  4. #4
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: A neat way of exporting DLL symbols?

    also... note that there was a reason to support the extern "C" {} syntax. namely to support including C headers and libraries from C++ without touching the header
    Code:
    extern "C" {
    #include "some_c_header.h"
    }
    whereas such a need never existed for __declspec.

  5. #5
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: A neat way of exporting DLL symbols?

    __declspec is part of the ansi c++ spec (the keyword is, the implementation isn't) so the way to use it has been very carefully chosen.

    I'm not sure a syntax like you propose would be syntactically viable or if it would cause issues/sideeffects in the parser/compiler.

    GCC added a keyword of their own. That's their choice, but it isn't part of the standard.

    Personally I don't really see much problem with it. it's not like adding a declspec is particularly hard, and you probably want to add a calling specification anyway (if at function level), so you end up macroing it anyway. exporting entire classes is non portable to another compiler anyway.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured