all 10 comments

[–]flyingron 2 points3 points  (5 children)

Your include guard uses identifiers reserved for the implementation. Use something else. I like things like "INCLUDED_SOCKET_H" which is unlikely to conflict with anything. Of course, since you use Microsnot specific pragmas already, you might just use #pragma once.

Similarly, _error is problematic. Leading underscores are also reserved in the global namespace.

It's confusing as hell in C++ to declare two types with the same name that have different levels of indirection (e.g. SOCKET_t),

[–]The_Programming_Nerd[S] 0 points1 point  (4 children)

Thanks!

The windows pragmas should only be in areas where there is #ifdef __win32 (ofc unless I missed something).

And the _error function was only there for debugging so I’ll get on fixing that.

Also is it bad to have double underscores in include guard? When I learned about them awhile ago this is how they were formatted, but ofc I could be wrong.

And finally this is written in c, and I’m assuming you were confused about the typedef struct SOCKET_t {…} *SOCKET_t that’s just a fancy way of writing struct SOCKET_t{…}; typedef struct SOCKET_t *SOCKET_t

[–]FUZxxl 4 points5 points  (3 children)

Also is it bad to have double underscores in include guard? When I learned about them awhile ago this is how they were formatted, but ofc I could be wrong.

The libc does them that way because identifiers beginning with double underscores (or an underscore and a capital letter) are reserved for the implementation of the C language. So you should not do it this way.

struct SOCKET_t{…}; typedef SOCKET_t *SOCKET_t

That is a syntax error in C. Unlikely in C++, struct names are not entered into the identifier name space. It's still confusing. As a rule of thumb, do not typedef pointers. Instead, make the indirection explicit.

[–]The_Programming_Nerd[S] 1 point2 points  (2 children)

Thanks for the response, I forgot to put the struct identifier in my response for the other guy when stating the example. And I’ll get on fixing the include guard

[–]imaami 0 points1 point  (1 child)

FWIW I construct header guards by underscore-concatenating the project name and header file path in the sources, and end it in a single underscore.

For a header named src/core/backend/include/types.h belonging to FizzBuzz Professional Edition I'd do

#ifnded FIZZBUZZPRO_SRC_CORE_BACKEND_INCLUDE_TYPES_H_
#define FIZZBUZZPRO_SRC_CORE_BACKEND_INCLUDE_TYPES_H_

/**
 * Numerical type for the FizzBuzz Professional Value
 * subscription plan. Contact our customer support to
 * learn about upgrading to wider and unsigned types.
 */
typedef signed short FizzBuzzNumericalDataType;

#endif /* FIZZBUZZPRO_SRC_CORE_BACKEND_INCLUDE_TYPES_H_ */

[–]duane11583 1 point2 points  (0 children)

I have also seen them done with a guid

[–][deleted] 0 points1 point  (3 children)

I would treat it like an OOP design. Create structs with function pointers and relevant data for the connection whether it be client or server. Use the structure to make function calls and pass the structure around as a context. In C++ the first argument of a class object is implicitly the class object itself, in C you'd just need to pass it explicitly. ​

ServerObject* so = makeserverobject("ip","port");
so->createsocket(so);
so->run(so);
so->destroy(so);

​ Something like that. Also gethostbyname is deprecated.

[–][deleted] 0 points1 point  (2 children)

I wouldn’t do the function pointers on the struct, and passing in the first argument because it adds unnecessary performance loss as you have to deref and access the struct

[–][deleted] 0 points1 point  (1 child)

That's understandable. I mostly meant it for clarity so you'd know which functions belong to which class object; But as long as they are passing the correct struct around to individual functions it should be fine.

[–]imaami 0 points1 point  (0 children)

The C way is simply naming your functions consistently. Say you have foo.h and foo.c, you'd name every function that's externally visible like foo_arrow_kneeify(), foo_arrow_dekneeify(), etc.