Possibility to declare function attributes on the generated unmangled definitions in C code

[ghost]

Let's say I have a class

MyClass: class {
    doSomethingPublic: static unmangled func
    _doSomethingPrivate: static unmangled func
}

rock will generate following declarations for these two functions:

void doSomethingPublic();
void _doSomethingPrivate();

What I'd really like is the possibility to somehow mark the ooc definitions of the functions with a visibility attibute, so that rock could generate following C code instead:

void doSomethingPublic() __attribute__ ((visibility ("default")));
void _doSomethingPrivate() __attribute__ ((visibility ("hidden")));

Now I'm using a ld script to export only the public symbols (which is an acceptable solution), but it would be super cool to be able to do that at ooc level (and compile everything with -fvisibility=hidden by default).

[alexnask]

Just realized this was an issue in magic-lang, not ooc-lang

This can be easily achieved but the bottom line is that such C specific (and in this case, compiler specific) features will probably not make it into ooc-lang, unless there is a project specific modular way of defining modifiers.

[alexnask]

@sebastianbaginski

A visibility modifier + flag would be easy, that is.
For a more general solution like a attribute flag used like this: attribute(visibility = default) a little more time would be necessary but it is possible for sure.

Anyway, I have a three day weekend coming up, I'm planning on working on a couple of features so you can probably expect some solution this weekend :)

[ghost]

Thanks, great to read that :) I'm aware that my request is very gcc specific, but I guess that would be enough for us, for a start. Personally I'd be really happy to see this in ooc, even in the simpler, less general form of a simple visibility flag (but having a deprecated attribute in ooc in the future would be awesome). What do you think @thomasfanell @fredrikbryntesson @marcusnaslund ?

[marcusnaslund]

I don't know enough about how we use it, if we want to get "stuck" with gcc-specific stuff, and if it's critical enough to warrant implementing it into the language. @fredrikbryntesson is the boss here.

[alexnask]

A deprecated modifier would be useful indeed.

[ghost]

@marcusnaslund it does not have to be gcc specific at all, if rock could generate something like this:

/* attributes.h */
#ifdef _WIN32
  #define ATTRIBUTE_VISIBLE __declspec(dllexport)
  #define ATTRIBUTE_HIDDEN
#else
  #ifdef __GNUC__
    #define ATTRIBUTE_VISIBLE __attribute__ ((visibility ("default")))
    #define ATTRIBUTE_HIDDEN  __attribute__ ((visibility ("hidden")))
  #else
    #define ATTRIBUTE_VISIBLE
    #define ATTRIBUTE_HIDDEN
  #endif
#endif

...

/* MyClass.c */
#include <attributes.h>
...
void doSomethingPublic() ATTRIBUTE_VISIBLE;
void _doSomethingPrivate() ATTRIBUTE_HIDDEN;

then it should compile just fine with any C compiler supporting c99, and visibility attributes could simply be ignored if not supported by the compiler. Of course this is just an idea, I'm sure @shamanas can figure out something better ;)

[alexnask]

@sebastianbaginski

This is still compiler specific (aka non standard C99), which would be a first (I think?) in ooc codegen.
As I said, it would be ideal to have some way to extend modifiers in a project specific manner since this would also enable DLLexport modifiers or other __atrribute__ stuff but I see no elegant way to do this save for mappings in a usefile.

@fasterthanlime
What do you think?

[fredrikbryntesson]

I am a little skeptical if it is gcc-specific. It is not a bad idea, not at all, but I am worried it will come and bite us later.

[ghost]

@thomasfanell @fredrikbryntesson should we close this ? I guess this won't be fixed

[thomasfanell]

Most likely not.