definition of thread id data type

[Wolfgang]

Hi,

the documentation of PostDeferredCallToThread says that target thread id is of type unsigned long - while the function CmtGetCurrentThreadID returns a number of type unsigned int. I guess that both values should be compatible, and hence in one of the two docs there might be a typo...?

Wolfgang 

[menchar · Accepted solution]

The Win32 SDK defines a ThreadID as being of type DWORD.

DWORD is typedef'd to unsigned long CVI data types in cvidef.h

You can see the CVI data types in the CVI help (look for C data types in the index) and you'll see that unsigned long and unsigned int are both 32 bits in CVI.

The C89 standard says a long must be at least 32 bits.

limits.h, part of all standard c implementations, deopicts integer ranges.

See "C A ReferenceManual" Harbison & Steele  ISBN 0-13-089592-X

Here's limits.h from CVI 8.5:

/*============================================================================*/
/*                        L a b W i n d o w s / C V I                         */
/*----------------------------------------------------------------------------*/
/*    Copyright (c) National Instruments 1987-1999.  All Rights Reserved.     */
/*----------------------------------------------------------------------------*/
/*                                                                            */
/* Title:       limits.h                                                      */
/* Purpose:     Include file for ANSI Standard C for determining various      */
/*              properties of the integer type representations.               */
/*                                                                            */
/*============================================================================*/

#ifndef _LIMITS
#define _LIMITS

#define CHAR_BIT    8
#define MB_LEN_MAX  1

#define UCHAR_MAX   0xff
#define USHRT_MAX   0xffff
#define UINT_MAX    0xffffffff
#define ULONG_MAX   0xffffffffL
#define ULLONG_MAX  0xffffffffffffffffL

#define CHAR_MAX    SCHAR_MAX
#define SCHAR_MAX   0x7f
#define SHRT_MAX    0x7fff
#define INT_MAX     0x7fffffff
#define LONG_MAX    0x7fffffffL
#define LLONG_MAX   0x7fffffffffffffffL

#define CHAR_MIN    SCHAR_MIN
#define SCHAR_MIN   (-SCHAR_MAX-1)
#define SHRT_MIN    (-SHRT_MAX-1)
#define INT_MIN     (-INT_MAX-1)
#define LONG_MIN    (-LONG_MAX-1)
#define LLONG_MIN   (-LLONG_MAX-1)

#endif

[Wolfgang]

Dear Menchar,

Thank you for your explanation! I agree with you that a DWORD nicely corresponds to the C long int definition - while for int it might depend on the implementation. Therefore a consistent use of int and long int would be preferred over the implicit assumption that int equals long int, imho;

in particular as both function calls belong to the same library (and function class).

By the way, searching for 'C data types' in the help of CVI 9 returns the following result:

The intrinsic C data types that LabWindows/CVI defines are as follows:

int
long
short
char
unsigned int
unsigned long
unsigned short

That is, the type of implemtentation (16/32 bit) is not listed, unfortunately.

Actually this post was intended for NI to enable them further improving their documentation -:)

Wolfgang

[dummy_decoy]

i do totally agree with what Walfgang said.

(the type naming of the C language has proved particularly unportable over the years: int types changed size multiple times. we are now used to a specific size for our 15 years old 32-bit architecture, and this poses a problem now that 64-bit architectures are common...)

(off-topic: why am i kudo restricted ? i can't give any kudo !)

Message Edited by dummy_decoy on 04-22-2009 02:59 AM

[jr_2005]

I'm still using the on-line CVI 8.5 help, which lists the data types here.

JR

[Wolfgang]

Hi JR,

thanks for the link - which seems to imply that the documentation of version 8.5 might have been more complete than the current one (here only the leftmost column is given)...

Wolfgang

[LuisG]

Hello Wolfgang,

The help topic that JR linked to in the 8.5 help should still be in the 9.0 help. You can find it here. If you are using the help viewer, you can find it by navigating to:  "Using LabWindows/CVI>>Programmer Reference>>C Data Types and 32-Bit Compiler Issues>>Data Types".

The topic that you probably found (was it this one?) refers to the types as they are used in function panels ("Using LabWindows/CVI>>Instrument Drivers>>Instrument Driver Fundamentals>>Data Types>>Predefined Data Types>>Intrinsic C Data Types").

Luis

[menchar]

The C89 / C99 standards define the integer data types in terms of their relationships with each other - a long, for example, is guaranteed to be at least 32 bits wide and at least as wide, if not wider, than an int.  For CVI, longs and ints both happen to be 32 bits. 

The purpose of limits.h (and float.h) is to provide the developer the ability to programatically deal with the particular data widths offered by any given C-standard conforming implementation.

I've never really used limits.h or float.h programmatically - never had top deal with target processors of varying data widths.

Some IDE's make it really easy to see the built-in data type definitions, with CVI you have to hunt through the help files and / or programmer's guide.

I think they changed the rules on kudos - you have to be above a certain level in order to give one, maybe to get one too.

Menchar

[Wolfgang]

Hi Luis,

good to know that the information is still there...:-) Unfortunately I could not find it in the CVI help using the index or searching for 'C data types' as suggested by menchar. As you know, my stupid comments are meant to possibly further improve CVI...  and information that can not be found easily may not be as useful as it could be... I have tried key words such as 'compiler data', 'data types', 'integer' - with no positive result...

And Hi Menchar,

before my posting I was actually checking the internet for the C definition of int, long int etc. Hence I completely agree with you - all I wanted to say is that I consider it 'suboptimal' if two function calls, e.g. PostDeferredCallToThread and CmtGetCurrentThreadID, that both are using a thread id, employ different definitions of the same parameter, unsigned long and unsigned int - even if CVI treats int and long int as the same thing... You are completely right that from a practical point of view it does not make a difference...

Wolfgang

[LuisG]

Hi Wolfgang,

I can definitely sympathize with you. I've been frustrated myself searching for information in a help file, not knowing exactly which terms to search for. And this has certainly happened to me with the CVI help, not just with other products. For that reason, I oftentimes use both the Index and the Search tabs to look for things, in the hope that at least one of them will show me what I want. In this case, I suspect that you used only the Search tab of the help viewer (which in my experience is usually more helpful than the Index tab). But in this case, when the obvious terms to search for ("data" and "types") are so generic, the Search tab isn't very helpful, since the number of results is pretty overwhelming. Let me give me you a couple of tips of how to improve the search a bit:

1. Use double-quotes when appropriate: Using "data types" as the seach term gives better results than if you used data types instead since it only returns topics where those words appear together.

2. Double-click on the Location column in order to support by help file. This allows you to filter out more easily all the other help files that are merged into the CVI help (typically, these are help files for various drivers and toolkits that you also have installed) and it allows you focus only on the core CVI content, if that is what you're looking for.

Finally, do try the Index tab if the Search tab isn't being very productive. In this case, if you had typed data types in the Index, you would have obtained a hit on data types allowed in LabWindows/CVI, which is the topic that you were looking for.

You also raised the point of consistency in the documentation, with respect to using long versus int. This is a very good point. We haven't always done a very good job in enforcing this consistency, but there's no good reason why we shouldn't do a better job. I'll make a point of trying to improve this soon.

Thanks for all your feedback, as always. Please keep it coming!

Luis