weird way of declaring a struct

[Red Squirrel]

I'm looking at a pthread tutorial as I forgot the syntax to send multiple arguments and I noticed they are declaring a struct like this:

typedef struct str_thdata
{
    int thread_no;
    char message[100];
} thdata;

I have never seen this before, why it is declared that way. What's thdata and why typedef? I thought that was for making an alias or something.

 

[KIAman]

That's a standard way of declaring a struct in c or c++.

"thdata" is the struct datatype name.

"typedef" is a keyword that allows you to declare a struct data type without using the keyword "struct."

 

[Crusty]

That's not weird by any means. That's just the C style way of declaring structs.

Think of it as doing the following

typedef struct str_thdata thdata;
struct str_thdata{
    int thread_no;
    char message[100];
};

 

[Net]

http://stackoverflow.com/questions/252780/why-should-we-typedef-a-struct-so-often-in-c
http://www.cplusplus.com/forum/beginner/15967/

 

[Red Squirrel]

Ohh I see. But I don't get why one would do that though, why not just name it the short form in first place? You can't use that name anywhere else anyway, right? So why not just do

struct thdata
{
    int thread_no;
    char message[100];
};

I'm not used to working with structs, I usually work with classes, so that's why this seemed odd for me. Really, one of these days I need to write a thread class. Doing it the long way is tedious.

 

[Crusty]

Ohh I see. But I don't get why one would do that though, why not just name it the short form in first place? You can't use that name anywhere else anyway, right? So why not just do

struct thdata
{
    int thread_no;
    char message[100];
};

I'm not used to working with structs, I usually work with classes, so that's why this seemed odd for me. Really, one of these days I need to write a thread class. Doing it the long way is tedious.

How is writing your own threading library shorter than learning the API of another?

If you are having a hard time understanding threads, writing the code to implement a threading library(quite hard btw) might help you, but there are far better ways to go about it. At a bare minimum you'll need to understand process control blocks, thread control blocks, virtual memory, context switching, and some other fundamental operating system concepts.

You are far better off understanding threads from a practical aspect, then it doesn't matter what API you choose. Locks, mutexes, semaphores and condition variables are all going to follow the same theory no matter what API you are using. Knowing what they are how to use them properly will help you a LOT more than hacking together some threading library that probably doesn't even implement a real thread.

 

[Markbnj]

It's just a holdover from C where the names of structs, enums, and unions were implicitly contained in a namespace of "tags". So you could declare a struct without using typedef, but every time you wanted to define an instance of it you'd have to repeat the keyword 'struct.' This style isn't necessary with C++, in which the type names of structs, enums, and unions are kept in the namespace in which they are declared.

 

[Merad]

Ohh I see. But I don't get why one would do that though, why not just name it the short form in first place? You can't use that name anywhere else anyway, right? So why not just do

struct thdata
{
    int thread_no;
    char message[100];
};

I'm not used to working with structs, I usually work with classes, so that's why this seemed odd for me. Really, one of these days I need to write a thread class. Doing it the long way is tedious.

In C, declaring a struct that way means that you would have to use "struct" when declaring variables, eg

struct thdata myData;

Using the typedef allows you to simplify it to look like what you're more familiar with in C++:

thdata myData;

 

[TecHNooB]

typedef struct sStructName
{
} StructName, * pStructName;

I've seen code like the above.

 

[Red Squirrel]

How is writing your own threading library shorter than learning the API of another?

If you are having a hard time understanding threads, writing the code to implement a threading library(quite hard btw) might help you, but there are far better ways to go about it. At a bare minimum you'll need to understand process control blocks, thread control blocks, virtual memory, context switching, and some other fundamental operating system concepts.

You are far better off understanding threads from a practical aspect, then it doesn't matter what API you choose. Locks, mutexes, semaphores and condition variables are all going to follow the same theory no matter what API you are using. Knowing what they are how to use them properly will help you a LOT more than hacking together some threading library that probably doesn't even implement a real thread.

Oh I'd still use pthreads, just would write a wraper class so I'm not dealing with the dirty stuff each time.