LLVM? More likely LoLVM

LLVM has some ENTERPRISE QUALITY.

It has function createMCSubtargetInfo in Target class that creates subtarget for processor and its features. Unless you pass "help" string to it instead of CPU model.

In this case this function prints everything to stderr and calls exit(1), shutting down your whole application.

You write GUI program that has no stderr? Well, sucks to be you.
You can't get list of processors or features otherwise. Only by passing "help" and quiting application.
Thanks goodness LLVM has a nice license.

>>2
Typical unix retard "hurr, durr, text output is good and parsable". It isn't. Function that creates targets should not print output and terminate program. It's called "createMCSubtargetInfo", not "createMCSubtargetInfoPrintHelpAndExitWithoutCleanup".
Only complete moron could thing otherwise.


>>3
But I want to rant and vent. I already patched local version.

>>5
It's because of Unix retards like you that modern computing sucks. Guess what? ASCII text isn't the best representation for everything. Sometimes records, arrays, lists, hash tables, pictures, numbers, non-ASCII text or even a combination of these are desirable.
Go back to masturbating to your hacked up RFC ``specifications''.

>>7
ASCII text is the best representation for everything.  Binary blobs can be encoded with base64.  COME AT ME BRO.

>>8
Go die in a fire piece of shit. Base64 is an abomination that should never have existed.

>>7

and ascii is good for somethings, like help messages and usage examples, which your program intentionally invoked, by passing "help" in somewhere that triggered a help message.

>>7
Text IS the best when you want to be able to communicate with a bunch of different programs and services.
It's human readable - so easy to detect errors and debug.
It's universal and easy to parse - don't have to look up some shitty documentation for the shitty binary format.

like I cant believe people are still using C++ when they could be optimizing their code with performance aware CYTHON

>>10
Yeah, sure. Not like you'd ever want your program's documentation to contain links, text formatting, foreign characters or pictures.

>>11
Yeah, sure. A base64'd picture is more human readable than a visualisation of said picture.

>>9
If it wasn't for base64, how else would you store binary data in XML files, huh tough guy?

>>4
I already patched local version.
Send it; if they reject it, then rant and vent as much you want.
Also, ignore UNIXtards, they're delusional.

>>13

we are talking about a help message that is embedded in the binary here. This is a bare minimum sort of thing that can help keep you straight on invocations if you have no access to the documentation. Images and links are easy to represent in HTML, which can provide the actual documentation.

>>14
EZ. <blob length="[i]Length of the blob[/i]">[i]The actual unaltered blob: no XML escaping, no base64[/i]</blob>
The closing tag isn't actually necessary and XML is shit though.

>>17
That's not valid XML, niggershit.  ASCII and Base64 are the way!