Using Thread Local Storage in a Dynamic-Link Library - dll

i have a cross platform C++ project used thread_local variable ,and it will be provided in dll. this code works good in linux gcc,but in windows vc2019 platform ,it seems like i can not use __declspec(dllexport) and thread local together ,Or else it will generate
[Compiler Error C2492]
this is from Microsoft
code is a simple global int variable:
extern thread_local int threadid;
at last i get two wey:
first from microsoft ,it is a little complicated.
second,do not declare thread_local variable in head file ,and use a get function to access it,like this:
#ifdef OS_WIN
DLL_EXPORT int getThreadId();
DLL_EXPORT threadLocalWrap& getThreadLocalWrap();
#else
extern thread_local int threadid;
extern thread_local threadLocalWrap _threadLocalWrap;
#define getThreadId() threadid
#define getThreadLocalWrap() _threadLocalWrap
#endif

The correct way to use TLS in VS2019 is:
#define Thread __declspec( thread )
Them use in variable definition:
Thread static int myVar;

Related

Why do I need using "extern static" to define a constant in header file in Objective-C?

I know using static const to define a constant is better than use #define.
But in this SO question, why use **extern** static const in header file, and write another m file to actually define the value. Why not just use static int const kMyVar = 1; in header file and no more m file instead?
You should not use extern static. You should only use extern.
File.h
extern const int MyGlobalConstant; // NOTE: Not static
File.m
const int MyGlobalConstant = 12345; // NOTE: This is not static either
This creates a memory location in File.m which other files that import File.h can reference.
In contrast,
File.h
static const int MyGlobalConstant = 12345;
This creates a separate and distinct memory location in every .m file which includes File.h.
The difference is important. In the first example, you have 1 MyGlobalConstant. In the second example, you will have tens if not hundreds of separate MyGlobalConstants all with the same value.
It's more than just a waste of space. I can cause problems debugging and problems for a profiler.
You don't want to use static in this case, because then it will be defined for each compilation unit that include your header file.
With an int there won't be any problem, but when you introduce e.g. strings you can end up with multiple declarations and then the fast stringInstance == MyFirstConstant pointer comparison technique will not work.
static const int myvar declares that in this translation unit (e.g. the resulting object file for this compilation step) there should be a static variable of type int named myvar. The memory is allocated, statically, by the compiler in this object file.
extern static const int myvar declares that somewhere in the program there is a constant variable named myvar, but do not specify where this variable is allocated or what its value is: it will be the linker that replaces the address of this variable with the actual address of the variable when it links the translation unit where this variable is allocated. In some way the extern static specifier introduces a variable declaration, while the form without extern introduces a variable definition.

What is the standard for sharing constant defined variables

As the title says - in Java I would just make a class define the constants then import them into the classes that will be using them. Is it done the same way in Objective-C?
To make it clear, I want to
#define variable 1
#define variable 2.0
And use the same constants in different classes.
Put the macros in a header file, and #include or #import that header file whenever you need to access them.
There is another alternative to using macros. You can define them as global variables.
In Constants.h:
extern int variableX;
extern float variableY;
In Constants.m (typically after the imports, before any other code):
int variableX = 1;
float variableY = 2.0f;
There are a few advantages to this approach over macros:
Clients don't need to see the value.
If the value(s) change, there is no need to recompile every file that imports Constants.h.
The values can be initialized many different ways, not just with literals.
Type safety and compiler checking when you use the variables.
Your example is using C preprocessor macros. This works the same with Objective-C as in any other environment supporting C-style preprocessor macros: Stick them into a shared header and #import or #include it.
While that's perfectly ok, you were asking about class-related constants and Objective-C in particular. In Objective-C you'll often see constant NSStrings (e.g. for notification names or dictionary keys) and similar constants belonging to a specific class defined like this:
In the header (.h):
extern NSString * const LibraryEntryDidUpdateNotification;
extern const NSUInteger LibraryEntryDefaultStarRating;
#interface LibraryEntry : NSObject
...
In the implementation (.m):
NSString * const LibraryEntryDidUpdateNotification = #"LibraryEntryDidUpdateNotification";
const NSUInteger LibraryEntryDefaultStarRating = 3;
#implementation LibraryEntry
...
This is how Apple does it in their modern frameworks, and how it is done by many 3rd party developers. In my opinion it's easier to refactor than preprocessor macros (e.g. when renaming a class using the "refactor" button in Xcode, the same easily works with these constants), but preprocessor macros for constants do have their benefits as well.
See here and here for a more in-depth discussion of the topic in case you're interested.

Managed type/wrapper for extern keyword

I am writing a managed wrapper for a 3rd party API and I have access to only their header files and .lib file. In one of the header files there is a function:
extern "C" void functionName(unsigned int param);
To wrap this function, I can ignore the extern keyword right? It is just to tell the compiler to treat the declaration as if it were made in C, rather than C++ and I guess this shouldn't be an issue when writing a managed wrapper using C++/CLI?
Using extern "C" in a function declaration specifies C linkage for the function (i.e. no name mangling); see here: In C++ source, what is the effect of extern "C"? . It should not adversely affect a C++/CLI caller.

Variables inside protocols in Objective-C

Why is there a provision to include a variable inside a protocol declaration, when is this ever used.
#protocol SampProtocol
int i;
- (void)func;
#end
There isn't any such provision. clang issues an error if you try to compile that code; gcc considers the int i; statement as part of the parent scope (which is probably a bug).

How to manage lots of flag variables in interfaces

Sometimes my interfaces end up having a lot of flag variables, such as isThatFeatureEnabled. Or, even worse, I will have an interface containing only flags and instance information.
While reading some UIKit header files, I found out that some classes declare a structcontaining all the internal flags they need. For example UIView has this:
struct {
unsigned int userInteractionDisabled:1;
unsigned int implementsDrawRect:1;
unsigned int implementsDidScroll:1;
unsigned int implementsMouseTracking:1;
unsigned int hasBackgroundColor:1;
unsigned int isOpaque:1;
// ...
} _viewFlags;
How does this work and how is it used?
Also, (sorry if this may seem unrelated), take StoreKit's SKProduct, for example. It doesn't have any methods, just readonly properties for getting instance specific information, such as localizedDescription, localizedTitle and price. But how is it initialized? How does the code that initializes instances of this class set those properties in the first place if they're readonly? I see this class also has an id _internal ivar; what's that for?
Often I end up with interfaces similar to SKProduct, except that my properties can't be readonly, because I have no idea how to set them when I need to initialize an instance, for example in an XML parsing code.
The structure that you have presented is the way that C, C++ and Objective C have for declaring bitfields. It has an advantage over something like #define MYFLAG 0x0001 in that you get compiler checking, so that you don't do any of the following:
Accidentally assign the same bit to more than one flags
Accidentally overwrite a flag with a number (e.g. flag=34)
Accidentally use one #define with the wrong variable (e.g. myColor=FLAG_TEMPERATURE_HIGH).
You can set all of the variables at the same time doing a structure assignment in C++. You couldn't do that in C or Objective-C the last time I looked, but you may be able to do so now.
You set and get these flags like any other instance variable.