• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Inline symbols visibility
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inline symbols visibility


  • Subject: Re: Inline symbols visibility
  • From: Guillaume Billard <email@hidden>
  • Date: Wed, 7 Apr 2010 15:23:14 +0200

Le 2 avr. 2010 à 19:10, Andreas Grosam a écrit :

You should be carefully, though with static declared member variables which may be accessed in inline member functions. The static member variable shall be visible, and all copies of an inline member function shall access this single instance. Usually, the compiler and linker takes care about all of this - but not always (see one of my previous post).

I checked, the inline function indeed accesses a static member variable (through a static member function). I would say that this static member variable is indeed visible, but how do I check that all copies of the inline member function do access this single instance? I'm not sure I understand.
Actually I'm not even sure what a "out-of-line copy of an inline member function" is, sorry. I've read the term many times but I'm still confused.

I found this thread where it seems that the same behavior occurred:
http://lists.apple.com/archives/xcode-users/2005/Jul/msg00609.html.

Adding the "default" visibility attribute to the inline method solved the problem.
If I'm not mistaken, the compiler gets to decide wether to inline methods or not, even when they're defined out of their class definition.
It appears that it can inline methods for classes that use  __attribute__((visibility("default"))), but I don't know if it can do the same for out-of-class methods. I'm hoping not.
I'd like to know if adding the attribute to a method of a visible class whenever it doesn't get exported is the right approach.
Actually, it will be *exported* , the function is in your header. Unless its declared private in the class, clients have "access" to it. Do you mismatch interfaces and visibility?

I don't mismatch the two but it's true, now that you make me think about it, how come this function would not be available? I want to believe you that it's not about visibility, but still adding the visibility attribute fixes my problem.
Below is a simplification of the code I'm working with. I'm sorry I don't have a reproducible sample.

************************************************************************************

// ---------------------------------------------------------------------------------------------------------------------
// gnReplicationDatagram.h, part of a mid-level dynamic library

#include "<path_to_low_level_library>/gnMetaClass.h"

class __attribute__((visibility("default"))) gnReplicationDatagram
{
private:
static gnMetaClass const* ms_pClass_gnReplicationDatagram;

public:
static gnMetaClass const& MetaClass()
{
return *ms_pClass_gnReplicationDatagram;
}

/*__attribute__((visibility("default")))*/ virtual gnMetaClass const& GetMetaClass() const
{
return gnReplicationDatagram::MetaClass();
}

public:
gnReplicationDatagram() {}
virtual ~gnReplicationDatagram() {}

gnReplicationDatagram(gnReplicationDatagramId a_eId): m_eId(a_eId) {}

private:
gnReplicationDatagramId m_eId;
};


// ---------------------------------------------------------------------------------------------------------------------
// gnReplicationObjectsCreationDatagram.h, part of the same mid-level dynamic library as above

#include "<path_to_mid_level_library>/gnReplicationDatagram.h"

class __attribute__((visibility("default"))) gnReplicationObjectsCreationDatagram: public gnReplicationDatagram, gnNoCopy<gnReplicationObjectsCreationDatagram>
{
private:
static gnMetaClass const* ms_pClass_gnReplicationObjectsCreationDatagram;

public:
static gnMetaClass const& MetaClass()
{
return *ms_pClass_gnReplicationObjectsCreationDatagram;
}

/*__attribute__((visibility("default")))*/ virtual gnMetaClass const& GetMetaClass() const
{
return gnReplicationObjectsCreationDatagram::MetaClass();
}

public:
gnReplicationObjectsCreationDatagram(): gnReplicationDatagram(gnReplicationDatagramId::eObjectCreation) {}
virtual ~gnReplicationObjectsCreationDatagram();

private:
// some non-static variable
};


// ---------------------------------------------------------------------------------------------------------------------
// gnReplicationDatagramUTestSuite.cpp, part of a Unit Test dynamic library

#include "<path_to_mid_level_library>/gnReplicationObjectsCreationDatagram.h"

class gnReplicationDatagramUTestSuite: public gnUTestSuite
{
private:
void ObjectsCreationDestructionDatagram()
{
gnReplicationObjectsCreationDatagram oCreationDatagram;
}
};

************************************************************************************

Enabling the 2 commented attributes fixes the link error that I have when I build the Unit Test library with -03 instead of -O0 or -Os:
Undefined symbols:
  "gnReplicationObjectsCreationDatagram::GetMetaClass() const", referenced from:
      gnReplicationDatagramUTestSuite::ObjectsCreationDestructionDatagram()       in gnReplicationDatagramUTestSuite.o

If that helps, using nm on the mid-level library I see this line:
001a9c30 t __ZNK36gnReplicationObjectsCreationDatagram12GetMetaClassEv
Which c++filt sees as:
gnReplicationObjectsCreationDatagram::GetMetaClass() const


To put things into context, the pieces of code about gnMetaClass that are almost identical in the 2 classes actually are an expanded macro defined in the low-level library, used to implement reflexivity.

Thanks a lot for your detailed answer, I hope this piece of code can help you helping me understand this! :)

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Inline symbols visibility
      • From: Andreas Grosam <email@hidden>
References: 
 >Inline symbols visibility (From: Guillaume Billard <email@hidden>)
 >Re: Inline symbols visibility (From: Andreas Grosam <email@hidden>)

  • Prev by Date: Re: Xcode build settings (such as llvm-config)
  • Next by Date: Re: Xcode-users Digest, Vol 7, Issue 149
  • Previous by thread: Re: Inline symbols visibility
  • Next by thread: Re: Inline symbols visibility
  • Index(es):
    • Date
    • Thread