Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

C modules

Name: Anonymous 2012-02-24 19:19

This just dawned on me today. I think in the ``what would you add to C'' thread, someone wanted nice modules, and they had some sort of export preprocessor thing to get stuff like MyModule.Function(). What about using a simple struct solution, i.e.

In the .h file:
#ifndef INCLUDE_MYMODULE_H
#define INCLUDE_MYMODULE_H

void LongassHiddenName_MyModule_Foo();
int LongassHiddenName_MyModule_Bar(int);

struct _LongassHiddenName_MyModulePackage {
    void (*Foo)();
    int (*Bar)(int);
};
struct _LongassHiddenName_MyModulePackage MyModule;

#endif


And in the .c file:
/* ... */
#include "mymodule.h"

MyModule.Foo = &LongassHiddenName_MyModule_Foo;
MyModule.Bar = &LongassHiddenName_MyModule_Bar;

/* Define the methods ... */


So that other things including mymodule.h now can do shit like MyModule.Foo(); or MyModule.Bar(42);. Sure it's not great, but has anyone done shit like this? Or some const variation?

Name: Anonymous 2012-02-24 19:42

What's the point of writing MyModule.Foo when you can just spell mm_foo?

Name: Anonymous 2012-02-24 20:10

Using static functions prevents them from being visible outside the file in which they are defined.
FooBar.h:
#define interface struct
#define import extern
#define private static
#define public
interface FooBar {
     void (*Foo)();
     int (*Bar)(int);
};
#define FooBar(foo, bar) { foo, bar }

MyModule.c:

#include "FooBar.h"
private void foo(void) {
     /* ... foo implementation ... */
}

private int bar(int i) {
     /* ... bar implementation ... */
}

public interface FooBar MyModule = FooBar(foo, bar);

main.c
#include "FooBar.h"
import interface FooBar MyModule;

int main(void) {
     MyModule.Foo();
     MyModule.Bar(5);
}

Name: Anonymous 2012-02-24 21:14

>>3
#defne private static
.    .    .

Name: Anonymous 2012-02-24 22:35

I didn't want `nice' modules. I wanted binary modules. Currently compiler has to parse A LOT of header files FOR EVERY SOURCE FILE. Something similar was proposed for C++11 but didn't make it in: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2316.pdf

Name: Anonymous 2012-02-24 22:41

>>5
Meh, if those are your goals, Squeak Smalltalk is far better. Squeak and eToys are a fantastic way of teaching programming, and the environment is infinitely more interactive than some silly web page. Heck, the entire freakin' programming environment and user interface is part of the system, which means you can rip it apart and dig around in its guts.

Of course, people aren't trying to teach programming or that instinct for self-learning and exploration that really differentiates the average from the exceptional. They're trying to teach "marketable skills". And that, of course, is where it all falls flat...

Name: Anonymous 2012-02-24 22:46

>>6
You're missing the point.

Name: Anonymous 2012-02-25 1:20

>>5
hmm, yeah that could definitely be improved. A compact representation for all the different types of declarations found in headers could be created, and each header file could be compiled down to a binary header file. Or maybe they could be merged into a common header data base for the project, and when a header file was updated, its entries in the data base would be updated, or added, or removed.

It would work out for almost every case, but it is technically valid C to have a curly bracket begin in one header file and end in a different header file. Which is really weird and confusing for most people when they make they type of mistake.

Name: Anonymous 2012-02-25 1:29

>>5
That's what precompiled headers are for.

Name: Anonymous 2012-02-25 9:27

>>9
Except when you're working with 10KLOC or more of templates.

Name: Anonymous 2012-02-25 10:34

Excuse me, >>10-san, but this is a thread about C. If you have grievances with some other language, please take them to some other thread.

Name: Anonymous 2012-02-25 10:49

>>9
Well, you're probably right. /thread

Don't change these.
Name: Email:
Entire Thread Thread List