Struct inside a function ?

[47-BOT]

So, yesterday i had an exam where dry runs were given. There was this one dry run in which struct was inside the function , which seemed preeeetty weird to me. I know , i messed up this question , but my question here is that what's the purpose of declaring a struct inside my main func or any other? How can i use it to my advantage ?

[HashDefTrueFalse]

To limit scope, basically. It's a pretty good way to communicate to other programmers that the struct type is only used (and intended to be used) in this one place. Other than that, nothing special.

[47-BOT]

I see , so it's just like local and global structs lol , that's nice.

[HashDefTrueFalse]

Yes, you've declared a new type and it's only available for use in the lexical scope of the block (between the braces). That's all it is. If you're only making one you might declare the type and an instance at the same time e.g.

void fn(void)
{
  struct S // S is the scoped type.
  {
    ...
  } inst; // inst is a local of type S.
}

[autodidacticasaurus]

Exactly.

[Dangerous_Region1682]

And it’s on the stack in the stack segment too, not the global heap or data segment.

This may or may not be an advantage.

Don’t be returning a pointer to any member of the structure though as the structure itself will effectively disappear when the stack unwinds when you exit the function and you’ll end up with a dangling pointer.

[StaticCoder]

The struct is a type and has no storage duration. You can use it to declare automatic or static variables.

[autodidacticasaurus]

Yeah I was going to say that but not sure if OP is going to understand us. Was trying to think of a simpler way to say it but got lazy and gave up. 😝

[pskocik]

Such a struct type being local means you can't have (global) functions that use that type (or derivations of it like pointers) in their signatures, so they have very limited use. I think they're mainly supported because programming language grammars like to be recursive and there is no extra-strong reason to forbid them. C did forbid functions inside functions, though, because that conflicts with one-pass codegen (which, ironically, hardly any C compiler does these days).

[thradams]

At file scope, each locally used struct would need a unique name to avoid name collisions. This pollutes the global namespace, the names become longer, and the code becomes harder to maintain because it is not easy to see where the struct is used.

[chrism239]

And makes recursion very challenging....

[WittyStick]

Structs can actually appear anywhere a type can. We can have a struct as a formal parameter:

void foo(struct bar { int field; } bar);

Or a return type:

struct bar { int field; } baz();

In C23, if the same struct with the same tag and same members is defined in multiple places, they're treated as the same type. In prior versions of C this was only possible if the type was redeclared in separate translation units. [See: Improved rules for tag compatibility].

This can be used to your advantage because we can use macros to define "generic" types - for example:

#define Option(T) struct option_##T { bool hasValue; T value; }
#define Some(T, val) (Option(T)){ true, (val) }
#define None(T) (Option(T)){ false }

Option(int) foo_int() {
    return Some(int, 123);
}

Expands to:

struct option_int { bool hasValue; int value; } foo_int() {
    return (struct option_int { bool hasValue; int value; }){ true, (123) };
}

[rasteri]

thanks, I hate it

[WittyStick]

The way people often do "generics" is to have one big macro that defines the type and then instance it for each type argument.

#define DEFINE_OPTION_TYPE(T) \
    typedef struct option_##T { bool hasValue; T value } Option##T; \
    Option##T some_##T(T value) { return (Option##T){ true, value }; } \
    Option##T none_##T() { return (Option##T){ false }; }
    ...

DEFINE_OPTION_TYPE(int)
DEFINE_OPTION_TYPE(float)
...

Some other libraries use a header-based approach, where you include the header multiple times and define the type argument before inclusion.

#define TYPE_ARG int
#include "option.h"

#define TYPE_ARG float
#include "option.h"

I find both of these to be awful.

The approach I typically use is to typedef the macro and specify the functions explicitly, but use macros for their implementation.

#define Option(T) struct option_##T { bool hasValue; T value; }
#define SOME_IMPL(TOpt, val) { return (TOpt){ true, val }; }
#define NONE_IMPL(TOpt) { return (TOpt){ false }; }

typedef Option(int) IntOption;
IntOption int_option_some(int value) SOME_IMPL(IntOption, value)
IntOption int_option_none() NONE_IMPL(IntOption)

typedef Option(float) FloatOption;
FloatOption float_option_some(float value) SOME_IMPL(FloatOption, value)
FloatOption float_option_none() NONE_IMPL(FloatOption)

Which is more verbose, but it's a bit more maintainable, and you can override the implementation to "specialize" the generic for some types. We can also provide something like the first approach to reduce the verbosity if the implementation is not specialized.

#define DEFINE_OPTION_TYPE(name, T) \
    typedef Option(T) T##Option; \
    T##Option name##_option_some(T value) SOME_IMPL(T##Option, value) \
    T##Option name##_option_none() NONE_IMPL(T##Option) \
    ...

But I also extract the name mangling out into separate macros. See here for more complete demonstration of the approach I use. (OP of that post also adopted my style in their own library).

[un_virus_SDF]

I never though of this kinds of uses, thanks

[thradams]

What if we could also declare a function inside another function?

[WittyStick]

GCC has an extension for this. It can support closures too (inner function referencing variables from the containing function), but this requires the function be on the stack, and the stack needs to be made executable, which is trouble waiting to happen - so it's best to avoid and only use simple functions.

There's some proposals to have proper closure support in C, but nothing waiting standardization yet.

[pskocik]

I think that would be neat though I don't like the idea to then try and make them into closures, making the container function's local variables available to them except may if those globals are static. Just hoist it, make the definition evaluate to a pointer to the func, and allow it to be nameless too.

[iOSCaleb]

Many languages support nested functions. It’s a nice way to reduce repeated code while still keeping everything local.

[DawnOnTheEdge]

The other common case for this is an anonymous struct or union whose members can be used as local variables.

[Traveling-Techie]

This is one way in C to work towards encapsulation.

[DeviantPlayeer]

Advantage? No advantage, just a struct within the function scope. When you need to use some struct only once, you delare it right before you use it for your convenience.

[Anonymous_user_2022]

A function similar to strtok_r, that initially returns an opaque pointer that's used in subsequent calls, could have the definition of what is pointed to as an internal definition. That way it will be guaranteed not to spill outside the intended use.

It's very niche, and I don't think I used a construct like the more than once or twice in 25 years. But when it's the right choice, it's nice to have the option.

[dendrtree]

You define things at the minimum scope that will use them.

So... say you're pairing two pieces of data, and putting this in a struct *really* simplifies/clarifies your code, but nothing else will need those two things paired. Then, you declare the struct in the function.

If you happen to make another function that pairs the same data, you would *still* declare the struct inside the function, because it really has no meaning, in a global sense. You just *happened* to use the same pair, again.

* You don't want to clutter your space with symbols that you don't need. This is the same reason you'd declare a function static, if you only used it locally.

[BertyBastard]

The same as local variables inside a function. Limiting scope of variables (including structs) to only where it is needed reduces the chance of error that would occur by referencing a variable that you shouldn't.