>>5
If it fits on one line, it's too short to deserve to be its own function, and relying on the compiler to pick up the slack of your own incompetence is a counterproductive habit.
>>8
I remember when people would put some effort into these discussions, instead of just pretending their opponents were trolls as soon as they realised they were wrong.
>>15
Your post is proof that space can indeed be wasted.
Name:
Anonymous2010-04-11 14:59
I write real code so we actually use the same standard on all functions.
// style.h
#define RETURN_TYPE
#define FUNCTION_NAME
#define PARAMETERS (
#define PROTOTYPE );
#define DEFINITION_BEGIN ){
#define DEFINITION_END }
// frozen.h
RETURN_TYPE int
FUNCTION_NAME frozen
PARAMETERS int arg
PROTOTYPE
// frozen.c
RETURN_TYPE int
FUNCTION_NAME frozen
PARAMETERS int arg
DEFINITION_BEGIN
return arg + 23;
DEFINITION_END
>>19
You need more #defines
#define RETURNING
#define FUNCTION
#define TAKES (
#define AND ,
#define AS
#define INPUT )
#define BEGIN {
#define END }
#define NOW
#define SUM +
RETURNING int
FUNCTION sum
TAKES int a
AND int b
AS INPUT
BEGIN
return TAKES a SUM b AS INPUT NOW
END
>>20
style.h has a lot more defines. We don't use function declaration defines in our code, though. We also have an AND for multiple variables:
PARAMETERS int a
AND int b
That is how the style guide says to do it.
Name:
Anonymous2010-04-11 17:26
int frozen(int arg) {return arg + 23;}
>>5
Agreed. You should generally not worry about this at all during development because it's an optimization step that a) has hard to predict results (making even small functions inline might significantly worsen performance), and b) is extremely easy to change at the end of the development cycle (just move the dang thing to the header file and put 'static inline' in front.) The best solution is of course to let the compiler do it for you; use PGO and LTO where available (and turn off default inline for class scope functions) so you never have to think about manually inlining anything.
Inlining too much can also cause excessive header file dependencies; if an inline function calls another function, you have to move its include to your own header file, causing more dependencies and longer rebuild cycles. If in doubt, don't inline.
That being said, when writing a function like the above, I will put it in the header file as static inline upon writing, since a) the current platforms I'm targeting don't support LTO, b) it's obvious that optimizes down to a single processor instruction on almost all architectures, c) it doesn't require any header file dependencies, and d) it's typesafe (as opposed to a macro).
Name:
Anonymous2010-04-11 17:46
>>24 move the dang thing to the header file in the header file as static inline
Are you mental?
I can't tell who's trolling who. Where does one place an inline function if not in a header file?
And static inline is necessary because gnu99 differs from c99 which also differs from c++ in the behaviour of bare inline. In gnu99, bare inline emits a non-inline function definition. In c99 it does not. In c++ it emits a static function definition.
Instead of trying to preproc all this bullshit, it's better to simply mark it static, and just don't take the address of an inline function. Most linkers are able to merge these definitions anyway (c++ linkers generally have to in order to avoid generating gigantic executables).
Name:
Anonymous2010-04-12 4:51
>>41
Sorry, that should read gnu89. Apparently gcc fixed the behaviour in gnu99.
I don't know how clang handles it but I assume it matches the spec, since it's one of the most pedantic compilers out there. Visual studio also differs from both gcc's c modes; it doesn't support inline in c, but using __inline emits as static inline iirc.
To sum it all up, not using static inline is going to break at some point on something somewhere.
Name:
Anonymous2010-04-12 5:50
#define i int
#define rt return
#define fr frozen
#define ar arg
i fr(i ar){rt ar+23;}
Name:
Anonymous2010-04-12 6:12
This ITT thread is full of COBOL-fags plus some ``Me is smarter than ur compiler''-pussies. Great!