Thread: I'm out of ideas...

so then what of this little nugget...

Code:

while ( (k = txt = strstr( txt, "\n" )) ) { }

looks like hell.

and this...

Code:

if ( (ret = change_kvpair( kvpair, full->given, full->given, full->given, 1 )) != EXIT_SUCCESS ){ };

this works ?

I don't understand why you are defining values inside a condition like that.

you can assign and "compare" at the same time.

I'm assuming this scopes the variable to the block?

Prepare to be shocked

Code:

#include <stdio.h>
int main() {
    int a = 100, *b;
    if ( !(a = *b) ) printf("wtf?");
};

lol

Originally Posted by Structure

I'm assuming this scopes the variable to the block?

It would... if you're declaring the variable in the condition. awsdert declared the variables before that point, so no, it doesn't.

Originally Posted by awsdert

Code:

notice->ownerId = *(
            ((int*)(glance->idNodes.space.block)) + glance->process);

Have you considered the syntactic sugar of array notation:

Code:

notice->ownerId = ((int*)(glance->idNodes.space.block))[glance->process];

Originally Posted by awsdert

I used it that way because it provides the strongest indication to the compiler that that particular assignment and comparison can be optimized so that size need only be stored to, the comparison can be done on the same register that the result was filled into before being stored to size, doing it the other way means under some situations the compiler is less likely to optimize that pair of actions.

In other words I'm telling the compiler speed is wanted most there and I've no need to check the variable beforehand during debugging.

I think you'll find that any optimising compiler will be able to optimise to the same result either way. The way I see it, the usual reasons why people assign to variables within conditions is not to hint to the compiler for optimisation, but because they want to update a variable within a loop condition (e.g., your use of readdir), or they want to assign a variable and immediately check that it has a valid value (e.g., your use of opendir) while also prophylactically avoiding the case that a bug might introduced under maintenance such that the newly assigned variable is used before being checked.

Originally Posted by awsdert

The 2nd one was in the top code where I forgot to fill entryId with the id of the process being examined so that it could be used at the moment the process is determined to be possibly wanted

Traditionally, variables are declared at the start of functions in C even if they are used much later because declarations could not be mixed with "code" in the same scope, but if you're compiling with respect to C99 or later, you could consider a different style where variables are declared near first use. It would also be helpful to break down larger functions into smaller helper functions, e.g., your proc_notice_info is well over 110 lines: some of the sections that it consists of (those parts that you marked with comments, which is great) could have been moved into helper functions.

Originally Posted by awsdert

I normally compile without any optimization switches so I can experience the worst run it can give so I can find where code needs to be optimized

Where optimisation is concerned, that doesn't make sense: you should compile at the highest optimisation level that you're comfortable with so you can find where code needs to be optimised. If you instead compile without optimisations enabled when optimising, you'll increase your chances of finding code that you think needs to be optimised, but doesn't, hence wasting your time and effort.

Originally Posted by awsdert

this makes it easier for the compiler to optimize under ANSI C without extensions since there is no option of inline functions there

Inline functions were introduced to standard C over two decades ago.

Originally Posted by awsdert

It's never fruitless, and I'm not talking small functions the compiler can easily track everything and optimize, I'm talking largish or larger functions onilike proc_notice_info()

The reasoning still applies: if you don't enable optimisations when optimising, whatever measurements you do to determine bottlenecks etc will be inaccurate after you enable optimisations for production. Sure, optimising under such circumstances wouldn't always be fruitless, but it has a higher chance of wasting effort.

Originally Posted by awsdert

If I remember rightly it only become an official standard in c99 or higher

Yes, and that was 21 years ago, though I grant that it is true that support remains mediocre for that one major compiler vendor, but then their focus is on C++, not C.

Software engineering wisdom is that a function should be written to do one thing and do it well; this means breaking up large functions into smaller ones, and as you noted where function definitions are available, compilers can even inline without use of inline functions: in fact, one argument in recent years is that inline should be seen mainly as a way to satisfy the one definition rule when it would otherwise be broken, rather than a tool for optimisation. Refusing to do such sensible decomposition of functions in the name of optimisation is premature optimisation.

Originally Posted by awsdert

Lol, I already changed to that in code cause the plus didn't sit well with me, I just didn't bother posting it as it wasn't relevant to the
now fixed problem, so in answer, yes I have considered it


Like I said before this is just for those rare situations it doesn't, I normally compile without any optimization switches so I can experience the worst run it can give so I can find where code needs to be optimized


Helper functions I only make when more than one function does the same action, this makes it easier for the compiler to optimize under ANSI C without extensions since there is no option of inline functions there, sure if the compiler is smart enough it can do it anyway but this is for compilers that aren't smart enough, for example my mitsy compiler before it reaches stable stage won't be smart enough, up until beta I'll be working on features that don't involve optimization (such as actually compiling C XD), beta is where I'll focus on optimizing everything and implementing those features in the process while also dealing with any bugs peops raise (I'll make a thread when I have marked it beta to invite peops to start raising any issues they find)

It almost seems as if you think that the compiler optimises at the C level. It's quite reasonable to assume that optimising compilers do a better job when you do break up large functions (using "helper functions") because optimisation doesn't generally happen at the C level but on an intermediate (abstracted) representation of whatever you write (see Intermediate representation - Wikipedia). Besides that, large functions are difficult to maintain and hard to understand for humans. Most optimisations that have any relevance depend on choosing the correct algorithm in the first place (and in some cases using keywords like restrict so that the compiler can optimise more aggressively, for example. restrict - Wikipedia Don't bother with register in general... the compiler will use a register if it makes sense anyhow). Doing stuff like you're suggesting is not just premature optimisation, it might be doing the exact opposite of what you're trying to achieve.

I guess an example (maybe not a good one) similar to what you think you're doing is a project I was working on last year. A co-worker submitted a cunningly constructed micro-optimised function with a scary comment saying I should not rearrange things because it was carefully optimised to minimise x86 cache misses and that it'd fit in the pipeline or some mumbo jumbo. The problem is that we were prototyping on x86 and the actual target was ARM. So, of course the carefully constructed function was BS, the ARM code generated was not optimal and the compiler already did a better job. If it's not clear by now: I hate micro-optimisations or giving hints to the compiler (apart from well-defined hints like restrict and inline) because in 99.9% of cases I've come across the compiler does a better job. Write clear code, use the correct algorithm, break down large functions and in general the compiler will do a very good job.