IDE with advanced code analysis?

/prog/, what's the IDE with the most advanced code analysis features out there? I'm talking about things like:

- listing all the free variables that occur in selected code term
- warning the user when he shadows a binding from the outer scope
- finding all the places where a variable gets mutated
- showing all possible execution paths through a code term

>>40
You're just talking about the function invocation syntax, which yeah sort of looks like a function call syntax. But it's a blind text substitution with a completely separate, gimped language. It totally fucks up the syntax and semantics of the caller, unless you go through pains to wrap everything in your macro expansion properly, and even then you'll always end up hitting weird situation where the fucking blind text substitution doesn't quite do what you want because there's no actual syntax at work.

You're just talking about the function invocation syntax

*Macro* invocation syntax. Fuck, your stupidity is wearing off on me!

Macros are in fact orders of magnitude more powerful than functions:
http://s11.zetaboards.com/frozenbbs/topic/11177313/1/

██████████ ████ ████ ███████████ ██████████ ████ ████ ███████████ ███████████
██████████ ████ ████ ███████████ ██████████ ████ █████ ███████████ ███████████
████ ████ ████ ████ ████ ████ ████ ████ ███████████
████ ████ ████ ████ ████ ████ ████ ████ ██ ███ ██
████ ██████████████ ███████████ ████ █████████ ███████████ ██ ███ ██
████ ██████████████ ███████████ ████ █████████ ███████████ ██ ███ ██
████ ██████████████ ████ ████ ████ ████ ████ ██ ███ ██
████ ████ ████ ████ ████ ████ ████ ████ ██ ███ ██
██████████ ████ ████ ███████████ ██████████ ████ █████ ███████████ ██ ███ ██
██████████ ████ ████ ███████████ ██████████ ████ ███ ███████████ ██ ███ ██

>>41
I have yet to encounter a problem with function-like macros that can't be solved by wrapping the arguments in parentheses, and doing the same to the entire expression. And as mentioned above, functions ARE the better choice for anything that requires local variables, but for things that don't, macros are usually the better choice.

For example, to cube a number, you could use

int cube(int n) {
return n*n*n;
}

but there's no point in having n be a local variable, since it's not modified.

#define CUBE(n) ((n)*(n)*(n))

would probably be more suitable in this instance, since it wouldn't copy anything into a local variable. Depending on how many times it's used, it might result in a larger binary, but usually reducing memory usage is more important than reducing binary size. Additionally, the macro version would allow the compiler to automatically generate code appropriate for the type of n, while a function would be explicitly typed and require casting or force the programmer to create a different version for each type.

>>45
CUBE(f()) computes f 3 times.

use functions instead of macros, the compiler can inline them.

#define CUBE(n) ({typeof(n) result=n;result*result*result})
Problem solved

>>46
Only an issue if superfluous CPU usage is considered worse than superfluous memory usage.

>>47
GCC has extension __auto_type
#define CUBE(n) ({__auto_type result=n;result*result*result})

>>46
>>48
Also, isn't this a case where the compiler can optimize anyway? If, without using macros or functions, I just write int x = f(6) * f(6) * f(6), wouldn't the compiler be smart enough to recognize that it only needs to calculate f(6) once? And while it's still in the register after being returned from function f(), just multiply by three before storing it in x?

>>50
Only if f() is trivial enough to be inlined and doesn't have side-effects. This optimization is:
https://en.wikipedia.org/wiki/Common_subexpression_elimination

>>47
This macro works (if I add a semicolon after the final occurrence of "result"), but I'm not sure I understand why. result*result*result doesn't store its value anywhere, yet if the macro is used as an argument to say printf(), it does in fact print the cube of the input. So how can the function-like macro "return" this value, if it's not stored in a variable? Does this depend on undefined behavior?

>>52
Its a GCC extension
https://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Statement-Exprs.html

>>45
Your understanding and explanations of computing are grade-school level. Come back when you've done anything beyond the basics.

_{(this space intentionally left as a fuck you)}

Wow people in this thread are not nice at all. What crawled up all your asses?

>>54
Please elaborate.

>>57
The faggot in question only perceives software architecture as bound to C style compilation. In other words, he's still in the baby crib of computing.

>>58
Compilation is still the only practical way to achieve optimal runtime performance.

>>59
Obviously, but not C style compilation. There's even barely any C compilers that do whole-program optimization.

>>60
Define C style compilation.

>>61
C is an abbreviation for Common Lisp. C style compilation is a compiler that compiles your program into Common Lisp or a Common Lisp dialect like Scheme or JavaScript.

>>61
(non-exclusive list of compiler-constrained issues common in C)

If you make a function call, it always compiles in a function call unless an explicitly standardized inline feature is used. (the root one of the issues of this thread's faggot)

A linker which precludes whole-program optimization

No bounding of side effects, meaning the compiler cannot make assumptions on what mutable data is truly local. Coupled with all the tons of fucking undefined behavior meaning that any human, or any high level language could perform obvious transforms that the UB constrains the C compiler from performing.

No runtime optimizations. The same compile-time bytes that were created are applied to every runtime situation. If you move the binary to another compatible but different platform, the code doesn't take advantage of tuning for the new platform and is generally compiled to """compatible""" code.

>>61
C is just portable assembler. There's too much of a one-to-one correspondence between C and the generated machine code to allow the programmer to abstract. It's also too low level to allow the compiler flexibility and freedom to make larger optimizations, meaning the programmer has to hand-optimize absolutely everything. That model is poor and makes poor programmers who can't get past the low level.

>>61
Wouldn't "runtime optimizations" only be possible with JIT compilation? The only other way I see of doing it is incorporating optimized code for every single runtime situation into the binary, but 99% of it wouldn't be used in a typical run of the program so it would basically be needless bloat.

>>64
The problem with abstractions is that you need to teach the compiler to recognize them; if the user creates code that falls just outside of the compiler's ability to recognize the abstraction being used, the resulting binary will be a mess.

Check dubs

>>65
That's the entire problem with ahead-of-time binary compilation. It's bullshit made in the 1960s, that carried downsides for no other reason than programmers are nigger luddites who can't fucking deal with change, and who can't admit the shit that they built is shit when something better comes along.

Stuff like the Mill architecture, where there's cached compilation on startup per system is leagues better.

>>65
also, anybody who uses the word "bloat" needs to be shot. Fuck you, let the machine work. Extra storage doesn't slow anything down.

>>68
cache motherfucker

>>69
You didn't read the post, you literal retard. Code that is never executed, and data that is never read, doesn't hit the cache. If you care about packing of functions into tiny cache lines, you'll be doing that manually anyway.

>>67

That's the entire problem with ahead-of-time binary compilation.

You mean that it doesn't have machine-specific optimizations? I'd think compiling once from source when moving to a new machine would be the best of both worlds - you can optimize for the machine, without the JIT overhead.

>>68
If you can afford to not be bothered by inefficient algorithms or excessive memory use, you're not using the full capabilities of the computer. Of course, that's not necessarily a bad thing - most modern personal computers are intended to have at least some ability to run 3d games on, so it's basically impossible for say a text editor to stress the system, no matter how bloated it is. And sure, in those cases it may not be worth the programmer-hours it would take to 'de-bloat' it. But if you're actually the one writing 3d games, or simulations to run on a supercomputer, then efficiency is important.

>>1
Eclipse, netbeans, visual studio (probably)

And JSLINT

Hell, many IDEs have features like these, assuming you're working in a sane language

>>71
and this is the problem with you irritating piece of shit """bloat""" spewing fuckers. You whinge on about carrying megabytes around, then somebody calls you a stupid fuckhead for whinging about the stupidest of backwards ignorant shit, and then you talk about inefficient algorithms, which ISN'T BLOAT, you utter dipshit.

If I could kill you over the internet with my bare hands, I would. Die horribly and soon, you cancer on programming and society.

>>73
Chill out bro, rage is unhealthy

inefficient algorithms, which ISN'T BLOAT, you utter dipshit.

They and bloat are in the same general category of unoptimized binaries. The ideal is to have a small binary, which executes quickly, and doesn't use more memory than necessary.

>>75
You can't equate "Oh noes the binary will have unused baggage, BLOAT! -> You're a dipshit!" with "You advocate for inneficient AlGoreIthms!"

Plus, you utter ignorant fuck, faster algorithms tend to be LARGER than smaller simpler algorithm! You think caches, heuristic analysis, threading, load balancing, and all that shit that ACTUALLY makes things faster somehow makes smaller binaries? FUCK YOU, you empty headed piece of shit. You have no knowledge or authority to try to tell anybody anything. Go fuck off back to elementary school until you've done something significant, dick.

_{(this space intentionally left unoptimized)}

You can't equate "Oh noes the binary will have unused baggage, BLOAT! -> You're a dipshit!" with "You advocate for inneficient AlGoreIthms!"

Okay fine, I misspoke there. I was really referring to inefficient memory/CPU usage, not binary size.

>>70
i dont need to read your posts

>>79
It wasn't even my post, you dick. I wouldn't be surprised if the referenced one (>>65) was even by you, and you've achieved maximal rectal-cranial intersection by not knowing what I was referring to.