Additions to C

What do you want in the next C standard? For me it's namespaces, damn they make libraries simple.

Anonymouse functions (standardize clang implementations).
Optional GC.
Templates.

Classes

Closures.

An IO class that makes IO easy.

>>5
C IO _is_ easy. C string manipulation is a royal pain in the ass, hence the need for sane template library with common containers.

>>3
Kind of. I'd be perfectly happy with classes but no inheritance whatsoever. Or maybe completely statically resolved inheritance only.

Native higher-order functions.

Namespaces.  Improve/widen the standard library.

a string type. that's all

FIOC

Higher order functions and lambda calculus.

Nothing, adding this shit you write will be like creating seeples out of it.

ONE WORD THE FORCED INDENTATION OF CODE

>>13
It wasn't one word.
HIBT?

>>12
not if it has GARBAGE COLLECTED PRIMITIVES

Enterprise-grade scalable virtual infrastructure leveraging JIT cloudsourced e-readiness.

Replace #includes and forward declaration with formal units and interfaces. Rip out half the syntax nobody uses. Trash free-form macros. Now you don't need to rely on $multi-billion companies to write parsers for you, and l33t fags can't write unreadable premature optimized code. It should also be easier to make an optimized compiler. Finally add arrays and strings as a native data types with bound checking, eliminating 90% of the bugs and security holes.

The sooner we can cut our losses with C, the sooner the software industry can start improving again.

>>16
You, sir, have a promising career ahead of you in Product Development and/or Marketing.

Suggest you...
- forget this faggot programming shit
- learn to schmooze it up like a pro
- network; not as in iBGP, OSPF, RIP and friend, more like the Old Boy Netork, the Bro Network, etc
- learn to play golf
- visit the Men's Warehouse for some tailored suits
- wonder what to do with all that money you'll be making (broad portfolios is these days especially, with a good position in precious/strategic metals)

The rest of us will still be here snickering at the Lispfags, wringing our hands at the FIOC, complaing about some shit or other, and generally being dorks here in Dilbertland

>>1
namespaces
Are an ugly hack. Stop giving your identifiers nondescript names, and you won't need them.

>>2
Optional GC
http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Personally I'd like to see some native coroutine support, or at least yield(). At the moment I'm using some library for this, but it's quite clumsy and involves a lot of extra code on both the generator-function and the calling function.

int coroutine() range(int lo, int hi) {
    for (int n = lo; n <= hi; n++) {
        yield(n);
    }
    return EOF;
}

void something() {
    int coroutine() gen = range(1, 10);
    int value;
    while ((value = gen()) != EOF)
        printf("generated %d\n", value);
}

The sentinel value is the responsibility of the program, which might make some kinds of functions slightly more complicated, but would greatly simplify the implementation and would introduce minimal changes in the language. One could also conceivably make a coroutine(int), coroutine(char *), etc., much like Python, wherein the yield() returns the value passed via gen().

>>18
lol @ truth in /prague/

>>17
Rip out half the syntax nobody uses
Such as?
Now you don't need to rely on $multi-billion companies to write parsers for you
0/10 because everybody uses free compilers (ie. gcc, and anything GNU is certainly not a "multi-billion dollar company")
and l33t fags can't write unreadable premature optimized code
Eh, stupid people will write stupid code no matter what we do to the language.
Finally add arrays and strings as a native data types with bound checking, eliminating 90% of the bugs and security holes.
I can actually agree with this, but ONLY if the current way of using strings/etc. is still allowed and existing code isn't broken (considering how much software is already written in C I doubt they will ever standardize something that would break legacy code)

>>1,19
Wtf? Namespaces are not a hack. This doesn't result from non-descript names; virtually all widespread C libraries manually namespace their functions (png_, sqlite3_, etc.; a notable exception is zlib). They have to do this regardless of how 'descript' their names are. Do you really want all of libpng's functions available to your linker without the png_ prefix?

Namespaces would be nice, but I doubt it will ever happen. There's just no way to add it in a backwards compatible way; it requires name mangling. Anyway, having to add a short prefix to all your functions is hardly a big deal, and it doesn't hinder code readability too much.

>>3,6
C already has these things. Embarrasingly, C structs are better than C++ classes, because by forward declaring structs they allow real information hiding without causing massive recompilation of dependencies when a class changes.

There are provisions in the type aliasing rules which allow inheritance and polymorphism; this is how Python's object model is implemented. You can add function pointers for virtual functions, which is hardly more difficult than its C++ counterpart, and has many advantages; there aren't bizarre "member-function pointers", you have more control over how the vtable is assembled, etc. The only thing C doesn't do is automatic pointer conversions up the inheritance tree, which in my opinion is A Good Thing.

>>6
C string manipulation is a royal pain in the ass, hence the need for sane template library with common containers.
Um, epic fail? Why the fuck do you need *templates* for a string library? There are excellent string libraries for C that don't rely on templates at all, like bstring.

>>19
would greatly simplify the implementation and would introduce minimal changes in the language
Minimal changes, really? Didn't knuth say coroutines would require eliminating the concept of a stack? Seems it would take a shitload of work; converting all local variables of coroutine functions into thread-local globals, etc.

Even if the changes are minimal, no compilers currently support this, and no one is really asking for it. Adding it to C1X would actually hinder its uptake; people wouldn't bother with C1X because they wouldn't want to implement the harder parts like this.

>>19
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
A library for GC is not equivalent to built-in compiler-supported GC because the library doesn't know whether something is actually a pointer. If a random bit pattern happens to look like a pointer, the GC has to assume it's a pointer so the memory survives longer than it should; entire trees fail to be reclaimed because of this. It also prevents heap compaction because you can't move memory, which is a fairly critical part of modern GCs in performance-tuned languages like *shudder* Java.

That said, I don't think C needs GC. Memory management in C programs is not that difficult because it doesn't have exceptions, threading, etc. When you add a threading library things can get complicated, but threads are evil; they should be as isolated as possible to begin with. Freely available malloc() implementations these days are extremely fast and good at preventing fragmentation. Nothing says you have to use the platform's malloc(); it's easy to replace with a better one.

Personally, what I'd like to see is standardized syntax and required support for many function and variable attributes in use (not the dllexport/dllimport types, but rather the ones that affect code generation, i.e. structure packing).

I'd also like to see some commonly used, but technically illegal, idioms be standardized, like using a union for type aliasing.

What I *DON'T* want to see is microsoft's 'safe' versions of stdlib functions making it into the standard, like the incredible bullshit that is memcpy_s. Unfortunately this is apparently one of the standard committee's priorities for C1X.

Remove complex numbers.  Why the fuck were they worrying about that garbage when there are so many better things they could be fixing with C?

>What I *DON'T* want to see is microsoft's 'safe' versions of stdlib functions making it into the standard, like the incredible bullshit that is memcpy_s. Unfortunately this is apparently one of the standard committee's priorities for C1X.
Seconded.  I wish there was something I could do about it.

>>22
microsoft

safe

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

What's wrong with Microsoft's "safe" libc equivalents? There's quite a few functions which are outright unsafe or can lead to bugs, and all Microsoft's "safe" functions provide is a way to limit things like buffer size to prevent many overflows, however there are plenty of such functions already in libc, and some of Microsoft's functions are just plain redundant, but not all of them.

>>1-25,27-
Use C++.

ADD LIST PROCESSING.

>>25,26
I lol'd

>>22
C doesn't have threading
what.

>>22
Seems it would take a shitload of work; converting all local variables of coroutine functions into thread-local globals, etc.
Globals, what?! You stuff the coroutine's state inside the stack frame of the function that calls it (within something(), in my example). The compiler could insert whatever boilerplate is needed to make this work, so that the programmer no longer needs to. At the moment, I have to make structs for any coroutine I write, and pass these around. This is annoying.

The point is, coroutines have already been implemented several times at the library level, they have been proven useful by the numerous other languages that support such a feature, it would not be thoroughly difficult to add in compiler support for the feature, and it would make for much cleaner code for applications that currently rely on libraries to accomplish the same thing (not to mention applications which use kludges to work around the lack of natively supported coroutines).

>>29
I believe they're talking about vanilla ANSI C's standard library. On any modern platform, C is capable of threading, networking, exceptin handling, and many other things, in non-standard, but well documented(extensions) ways. Effectively, you can do practically anything imaginable with third party libraries or libraries you build yourself, they're just not standardized.

This is a fairly common type of whining present in many languages which have been standardized in one form or the other. For example, Common Lisp is sntadardized and has a pretty rich standard library, but at that time threading, networking, FFI were not considered things on which people could agree on a common ground or were considered things which would reduce the chance of portability of the language to all kinds of obscure platforms, so they were never included in the standard. Now you see people say/whine that you can't do all kinds of low-level things in CL, when you have de-facto portable libraries for doing FFI, threading, networking. (De-facto means that someone spent some time to write a thin portability layer on top of whatever many of the popular implementations probide under the hood(documented) for doing these kinds of things). Practically, you can write your code using these libraries and achieve full portability, but people will still while because it's not engraved in the golden standard that every implementation must obey, lest they be deemed non-conforming.

...damn, I sure made a lot of typos in that post. That's what I get for typing while half-asleep and being too lazy to double check what I wrote.

>>32
That's what I get for being a lazy nigger.

FTFY

>>30
You stuff the coroutine's state inside the stack frame of the function that calls it (within something(), in my example).
Isn't this quite a limitation that normal coroutine support doesn't have? Why does each call to a coroutine have to happen from the same function? Why can't several different functions call a coroutine? Why can't the coroutine be thread-safe?

No, to implement coroutines properly you need to do what Knuth said; get rid of the stack.

>>31
Well, POSIX is a fine standard.

>>34
Well, sure, it could be allocated and memcpy'd and so on, in much the same way as any other stack variable.

>>25
They are all stupid. For instance strcpy_s and strcat_s already have strncpy and strncat. memcpy already has a length argument in it; what the fuck is the point of adding another in memcpy_s? And printf_s, supposed to be safe, doesn't actually do anything at all except not print if a format character is unrecognized. Nevermind the fact that printf is hideously unsafe with dynamic format strings and printf_s does nothing to alleviate that.

Tell me a single one of these _s functions that is actually useful.

>>36
Is it really native coroutine support if you have to pass around the function's state yourself?

>>37
I just looked up memcpy_s because I was curious. Seriously, WTF?!?!

>>39
"WTF"? Surely, you haven't seen strncpy_s - that's just plainly fucking ridiculous.

>>40
Why?  in strncpy the n is for the source, not protecting the destination buffer

>>41
The question is, why the fuck you have to provide TWO length argument, when one would be enough? If your buffer is not smaller than needed, it's no different than regular strncpy. If the buffer is smaller, your code is fucked up anyway.

>>42
yhbt by microsoft

polymorphism, tuples and pattern matching for it, well integrated support for parallellism via message passing and syntax for it, etc. Just fucking bring back alef and I'm pleased.

>>44
ℵ

I want c99 to be the fucking ANSI standard... it's about damn time!

How about function-overloading ^^. Or maybe some other basic aspect of a decent language.

>>47
Function overloading would be fine methinks

>>47
3/10, fucking stupid OOP pig

>>46
ISO standards are usually adopted as ANSI standards, and C99 is no exception. For the details see http://groups.google.com/group/comp.lang.c/browse_thread/thread/c7860d434df33cc7/499d64c4e126e306#499d64c4e126e306 .

You people are fucking nuts. The whole point of C these days is the simple export model to interface with other programs. If I create a function call "FuckOff" then in the executable/library it will be called "FuckOff". Doesn't anyone here no what name-mangling is? It's the reason you can't call C++ functions like C functions from other languages, because instead of being called "FuckOff" it's now "%$&&%%$FuckOff#@$@#%@#$%SomeBullshit".

Leave C alone and implement this shit in other languages like C++ or D, that's what they're for. Also, fuck off.

To the people who said function overloading, namespaces, templates, containers, higher order functions, garbage collection, coroutines, I say: STFU.  It's C.  Don't try to turn C into C++ or worse.  If you want namespaces, templates, and containers, just write C++... it supports all of those things, right now.  If you don't like the overhead of exceptions then turn them off.  What makes C useful is that it's good at its niche: systems programming, and writing low level code such as codecs.  It's also a great target language for compilers... there are compilers for Lisp, Scheme, Haskell, Objective-C, C++, and more that all target C because C is so light-weight it's practically assembly.  Lots of interpreters are written in C: Python, Ruby, Lua, and Perl come to mind.  None of these would really benefit from the cruft listed above.

To the person who said closures: Yeah, I'd like that too.  Apple did it, looks like it made it into clang and probably will come to GCC too.

My #1 wish for C1X is support for UTF-16 string literals.  And guess what?  I got my wish.  (I read the C1X draft... u"some string" is UTF-16, U"some string" is UTF-32.  sweet.)

>>52
I don't get this. Why UTF-32? You're basically wasting 3 bytes per character. Anything UTF-32 can do, UTF-8 can do in less space.

>>52
link to C1X

Port boost to it.

>>55
F, see me

>>52
My #1 wish for C1X is support for UTF-16 string literals.
Agreed until this. This is kindof insane. What i18n strings are you putting in *source code*? UTF-16 string literals belong in C less than anything else in your entire list.

>>54
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1401.pdf

but it's probably going to be a long time before there are any c1x compilers... just look at how long it took for c99. and last time i checked (about 3 months ago) i could only find 2, both closed-source, and one of them costs money.

>>51 YHBT
>>52 YHMBT
>>25
strlen_s ^[1]
IHBT


<sub>--
1. Yes, I know it's deprecated http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98694</sub>

>>40
It's like MS decided to just add byte counts to every single char* parameter, ignoring the fact that many of the existing functions ALREADY have one.

>>31
This is why they need to add to the standard library.  Instead of adding complex numbers and shit like that.

>>58
A non-free C compiler?  wtf is it called and does anybody bother?

>>14
IHBMT

>>61
Not sure which ones >>58-san is referring to, but I sometimes use Sun Studio C and Compaq C (yeah, I still use VMS), neither of which is free.

http://arstechnica.com/open-source/news/2009/11/go-new-open-source-programming-language-from-google.ars

One of the distinguishing characteristics of Go is its unusual type system. It eschews some typical object-oriented programming concepts such as inheritance. You can define struct types and then create methods for operating on them. You can also define interfaces, much like you can in Java. In Go, however, you don't manually specify which interface a class implements. Pike explained to me that the interface mechanism gives developers some of the flexibility of duck-typing, but it goes further by providing the advantages of compile-time checking.

One day earlier...

>>6
Kind of. I'd be perfectly happy with classes but no inheritance whatsoever. Or maybe completely statically resolved inheritance only.

Funny how these things happen.

>>52
That's still bullshit and you know it. Unicode is a huge pain to support in See/Sepples. You have to do a bunch of macro hacks and the like or just plain have an unmaintainable amount of mixing within the code.

Real support for UNICODE would be nice. Something like #define UNICODE 0, 8, 16, 32 or whatever.

>>52
My #1 wish for C1X is support for UTF-16 string literals.  And guess what?  I got my wish.  (I read the C1X draft... u"some string" is UTF-16, U"some string" is UTF-32.  sweet.)

Fucking ew. Didn't we already have L""? What was so wrong with that?

A non-free C compiler?  wtf is it called and does anybody bother?
well, there's sun studio, which is free as in beer, but closed source:
http://developers.sun.com/sunstudio/documentation/ss12u1/mr/READMEs/c.html
This compiler is in full compliance with ISO/IEC 9899:1999, Programming Language - C and is available on Solaris platforms when you compile with the -xc99 option. This compiler supports all C language features of ISO/IEC 9899:1999, Programming Language - C on all supported operating systems.

and then there's this thing:
http://www.edg.com/index.php?location=c_lang
The front end accepts the C++ language as defined by the ISO/IEC 14882:2003 standard. It also accepts the C language as defined by the ISO/IEC 9899:1990 ("C89") and ISO/IEC 9899:1999 ("C99") standards and the "Embedded C" extensions of ISO/IEC TR 18037.
http://www.edg.com/index.php?location=faq_q2_cost
So how much do you charge for a single copy for Windows?

Sorry, we don't sell end-user products. We only license source code, which probably costs more than you're looking to spend if all you need is a single end-user copy.

How much does a source code license cost?

Usually somewhere between $40,000 and $250,000. There are lots of different kinds of licenses, so you'll have to contact us to get a specific quote.

>>67
Why would someone want to pay for the EDG thing?  Is there something wrong with using GCC for commercial products?

>>68
using GCC for commercial products
*grabs dick*

>>68
Probably why there's many other commercial implementations for various languages: support, bug fixes, payed feature requests, strict compliance with standards, better code quality than gcc...

I like how people comment on gcc's code quality without even having a basic grasp on assembly.

>>70
Which one has better code quality than gcc? I'm not trolling, I just want to know.

>>71
I do know x86 asm pretty well, and I hate looking at gcc's code.
>>72
You could say GCC has the most supported platforms and average code quality through-out, but on most popular platforms you tend to find better compilers for them.

I do know x86 asm pretty well
That gets me every time, just like when someone says the know sepples pretty well

>>74
You're probably right if you phrase it that way, since x86 asm gets extended so much every few years, and is quite a big mess overall, but my point was that I've been using it for many years and I may not know SSSE3 instructions that well, or know the ins and outs of VT-x, but you don't need those for general purpose x86 asm coding, and it's not hard to look them up in the Intel manuals when you need to use them.

Well, what's wrong with gcc's code?

>>76
You sagefaulted this thread.

>>73
I asked WHICH one is better.

>>76
On platforms where it works well, it's just about average, things I personally dislike are: sometimes it generates fairly bloated code, other times it makes optimizations which are unnecessary and make the code both slower and harder to read(for someone that wants obfuscated code, that might not be such a bad idea after all), while some other compilers generate both fast and straightforward code. However, there's much worse compilers than GCC, so for all intents and purposes, GCC is the most universal compiler out there, since it supports just about everything, but you should always look for alternatives if your platform is one with other compilers.

>>79
You still did not tell me WHICH ONE is better than GCC, for instance on x86 or amd64

>>80
The Intel compiler is pretty good.

>>81
At haxxing anii, or at planting backdoors into your program?

>>82
Don't be silly, you can examine the code generated by most commercial compilers like Intel's C compiler or Microsoft's C compiler, just as well as you can examine the code generated by GCC.

>>82
Intel is a CPU manufacturer.
If they wanted to fuck with you, they could just "plant the backdoors" right on the chip.
Damn opensores weenies and their baseless FUD.

>>84
It's also trivial to reverse engineer compiled code, especially one that you compile yourself. Not only that, but you can have the compiler generate symbols, and assembly listings which you can examine. More likely things to happen are trojans which modify base libraries and you end up with trojaned binaries - there was a recent case of that, someone made a virus which infected Delphi system libraries.

>>85
People still use Delphi? How quaint. Yes, I'm aware people still use outdated languages, like Cobol, for more or less pragmatic reasons.

>>75
No, you see, saying "I know x86 asm pretty well" is like saying "I know C syntax pretty well", but actually worse.

>>87
You think C syntax is hard to know pretty well? Or did you mean Seppples?

>>86
Why wouldn't they? It's fucking awesome. It's like .NET, but without imposing the heinous runtime requirements on the poor souls that try to use your software.

>>89
Awesome? Granted, it's been a long time since I used Delphi, but I don't remember it being awesome.

>>89
I don't know about Delphi now, but about 2 years ago I saw a Hello World written in it that compiled to a 300 kilobyte binary.

>>91
And I thought it was retarded that an equivalent "Hello world" is 15 kb with gcc (MinGW).  (Although you can take it down to 5 kb with the -s flag.  But that's still excessive to print "hello world")

>>91
I don't use Delphi myself, but I've had some experience with it in the past. You only get such huge binaries if you statically link various libraries in with your application. If you use only what is strictly necessary, you will only get a few KB overhead. It's no different from statically linking libc costs about 60kb, statically linking MFC costs about 600KB, and dynamically linking either costs less than 1KB.
>>92
I'm not so sure about GCC, but in general it's possible to get pretty slim binaries if you dynamically link everything, strip/not include debug info(gcc tends to leave a lot of that around), use as little alignment as your executable format allows you, and optimize for less code space usage. Some further cutting down can be done by using a custom entrypoint. That should give you a tiny executable you could get without resorting to packers which compress the code and data and abuse various properties of the executable format to squeeze even more space(sometimes making illegal images, but still recognized by the OS loader).

>>93
How can I use a custom entry-point with gcc?  It would be nice to get rid of all the bullshit that gcc throws into my application by default (from msvcrt.dll I have __getmainargs, __p__environ, __p__fmode, __set_app_type, _cexit, _iob, _onexit, _setmode, abort, atexit, fflush, and signal, none of which I asked for.  And then there's SetUnhandledExceptionFilter, AddAtomA, FindAtomA, GetAtomNameA from KERNEL32.dll that I most certainly didn't ask for)

>>94
I'm not so sure about how to go about it in GCC, but in MS C compiler, you just pass /ENTRY:symbol_name to the linker(link), you can also pass /NODEFAULTLIB (to not link libc if you don't need it) and /ALIGN:# to change alignment. It should be noted though, that if you code in C and use the standard library, you will need to link against it(statically or dynamically). As for the entrypoint, you will no longer have main receive the usual parameters, instead you will probably have no params passed to you at all, in which case, you would have to obtain and parse the command line yourself if you need anything from it (along with whatever other things you may want). This all goes into platform specific code (different on windows and *nix'es), as for the exports you mention, msvcrt.dll stuff sounds like main() code, and it should go away if you set your own entrypoint, as well as the kernel32 code. SetUnhandledExceptionFilter was probably used for giving you a better error message than a simple crash of your application.

>>94
You can tag a function with __attribute__((constructor)) and gcc will cause it to be called before main(). Not sure if that's useful to you though, and afaik there's no way to order it with respect to anything else called/constructed before main().

>>95
Somewhat related reading:
http://www.catch22.net/tuts/minexe

Some of the information applies to old compilers and is a bit outdated, but the core concepts apply even though the methods have changed.

>>94
if you link explicitly instead of letting gcc do it, you gain a lot of flexibility. dump ld --help to a file and peruse it. there's lots of goodies there.

as for executable size, I don't think you can cut it down much below 2kb:

~% echo 'int hi(){puts("hello world");return 0;}' > test.c
~% i486-mingw32-gcc -Os -fomit-frame-pointer -c test.c
~% i486-mingw32-ld -s -O -init=hi test.o -lmsvcrt -o test.exe
~% wc -c test.exe
2048 test.exe
~% wine test.exe
hello world

naturally if you don't use puts you can cut it down because you don't need to link anything. doing the same as above (except for the -lmsvcrt of course) I ended up with a 1536 byte file. far cry from the 15kb or even 5kb that >>92 mentions, though it's certainly not 400 bytes it's not horrible either.
I know there's some way to strip off the DOS mode header from the file, I did it before, but I don't remember how. this can save some space. collapsing .idata into .text would help too, but I don't think there's any way to do that with mingw unfortunately.

>>97
You're executable will be very small
Is the grammar and/or overall quality of non-trolling 4chan posts so great that after reading 4chan for a while, stuff like this really stands out?

>>98
With MS's toolchain I can get it down to 1024 bytes:
D:\Documents and Settings\konata\Desktop>cl /MD /Os /O1 test.c /link /align:4096 /filealign:512 /entry:hi /subsystem:console
t /stub:stub64.exe
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

test.c
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:test.exe
/align:4096
/filealign:512
/entry:hi
/subsystem:console
/merge:.rdata=.text
/merge:.data=.text
/stub:stub64.exe
test.obj
stub64.exe : warning LNK4060: stub file missing full MS-DOS header; rebuild stub with /KNOWEAS 16-bit LINK option
LINK : warning LNK4108: /ALIGN specified without /DRIVER or /VXD; image may not run
LINK : warning LNK4078: multiple ".text" sections found with different attributes (40000040)
LINK : warning LNK4078: multiple ".text" sections found with different attributes (C0000040)

D:\Documents and Settings\konata\Desktop>wc -c test.exe
1024 test.exe
D:\Documents and Settings\konata\Desktop>test
hello world

I then removed several hundred null bytes from the end of the file which go it to 622 bytes. If mingw lets you play with the alignment options you can probably get similar results.

>>99
You're ^OS is bad and you need to _{LURK THE FUCK MORE}.

All commercial games for Sony's playstation portable are compiled with gcc.

>>99
Is the grammar and/or overall quality of non-trolling 4chan posts so great that after reading 4chan for a while, stuff like this really stands out?
That's what distinguishes the imageboard rejects from the people who remember world4ch. On /prog/, at least.

>>99
your an anus!

>>100
Hello /g/... now please return to where you belong.

>>99
I couldn't find any options for mingw to merge sections etc., although ELF ld/gcc can do it. Guess no one on the mingw team cares enough about cutting 1kb off the executable to implement that stuff.

And you can cut the file down further if you write it entirely in a hex editor. (and obviously more if you build a .com file, but that's a different subject)

Also, konata is my hostname.

^{HAX MY}ANUS

>>99
That's stood out to me since I was in grade school, so I can't really answer your question with respect to 4chan.

Anyone want some Bjarne?
http://csclub.uwaterloo.ca/media/C++0x%20-%20An%20Overview.html

Do you guys know that in Polish language the word Sepples sounds similar to "seplenić" which is the verb meaning "to lisp"?

Do you guys know that in the English language you can take the word Sepples and replace it with the sentence "hax my anus"?

>>108
Dunno lol. ヽ(´ｰ｀ )ﾉ

>>1 do you have any fucking idea how C compilers and likers work? for chists sake all you java niggers going on about how great namespaces are but you have no idea how this is COMPLETELY UNIMPLEMENTABLE.
IDIOTS.

>>111
I have a pretty good idea how they work and how one goes about implementing one. I don't see what the problem with implementing 'namespaces' is (you'll have to elaborate on a more exact definition of the term, but I'll assume it's either the Java/C# idea of a namespace or a module system like Scheme's, or a package system like Common Lisp's). It seems perfectly implementable to me, except that it just won't be C that you'll be implementing.

>>108
So a ``lispnik'' should really be referred to as a sepplenik.

>>112
C does not support name-mangling, all symbol names are exported as they appear in the source(with added underscore). This means you'll never see namespaces or classes or function overloading in C. If you really need those features, use C++.

>>114
It doesn't support something that could be supported, so it'll never happen.
Oh. Okay. Makes perfect sense.

...why write C when you could just write C++? If you really need to, you can write C in C++, but you also get access to a huge library and much more powerful programming concepts. I'm not trying to be a troll. I've really tried to like C. It's just that every time I read somebody else's C code, I have no fucking idea what's happening. I hacked C for a good year before I learned C++, and while I got very proficient, I just couldn't maintain my code when I came back to it later. Is there some sort of book which teaches proper C style? Even still, I see no reason to forsake C++'s extra goodness (especially with so much goodness in C++0x and/or boost.)

Somebody convert me!

>>116
It's just that every time I read somebody else's C code, I have no fucking idea what's happening
Don't blame C.  Blame the fuck-knuckles who don't understand how to write readable code in it.

>>116
Stop being 12. If you don't like C then use something else. *Please.*

>>118

That's not very helpful. I do like C. I love C. I just don't understand why restrict yourself to it alone? As I said before, I can write very readable C, and powerful C. But when I need a map data type, I know it's far more readable to use the STL than to roll my own (probably) flawed (probably) less efficient map type.

Please don't insult me, but offer a compelling exposition of your beliefs, and your reasons for holding them. Programmers tend to like logical and reasonable behaviour.

Is there an online resource, like Practical Common Lisp which teaches clean, reasonable C style and idioms?

>>119
your gay

^{HAXHAXHAXHAXHAXHAX}MY_{ANUSANUSANUSANUSANUSANUS}

>>116
[quote]Somebody convert me![/quote]
>>119
[quote]I love C.[/quote]

Mission accomplished.

>>119
>But when I need a map data type, I know it's far more readable to use the STL

std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >,
std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> >
  >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > > > >

How about no?

>>123
Now I am become Death, the destroyer of worlds

>>123
Your convoluted expression only matters in the context of errors with templates, which is a big verbosity/useless error problem.

However,

std::map<std::string, std::string, std::less<std::string> > is not as verbose and can even be decreased.

map<string, string, std::less<string> >

Pretty sure IHBT.

>>119
So let me get this straight. Is std::map really the only thing the STL has going for it? The map is the only goddamn thing everyone brings up over and over, so here, courtesy of google, some red-black tree maps in C:

http://www.mit.edu/~emin/source_code/red_black_tree/index.html
http://en.literateprograms.org/Red-black_tree_%28C%29
http://www.cs.utk.edu/~plank/plank/rbtree/rbtree.html
http://semanticvector.blogspot.com/2008/05/red-black-tree-in-2-hours.htm

Every goddamn fucking time the C/C++ debate comes up, everyone says over and over how you're going to waste time reimplementing stuff that's already in STL. Do you think C programmers are incapable of re-using code?

Because if I statically link one of the above into my app, it's going to be a fuck of a lot more portable than 'whatever broken STL implementation the platform supports', and it will be smaller anyway without all that template bullshit. And is it really the end of the world if I have to do map_at(mymap, "key") instead of mymap["key"]??

>>126
Oh even better, check this bitch out:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/tree.h?rev=1.12;content-type=text%2Fplain

OpenBSD's tree, a full red-black tree implementation in a single header file.

You may also be interested in uthash, a hash-table capable of holding any C struct, also in a single header file. Recall the STL doesn't actually have a hash table.

Remind me, why the fuck do I want STL again?

It makes me upset that a thread about a shitty new programming language from Google is the best thread on /prog/'s front page right now.  :(

AHAHAH YEAH TEMPLATE FAGGOTS ARE SUCH FAGGOTS, WHEN VOID* IS ALL YOU NNEED

>>129
I love void pointers. They are so beautiful.

Is "removing many features of C99 that really suck" an addition?

>>127
Except it does; std::tr1::unordered_map. That tree implementation is also bad. It's either impossible or extremely painful to debug macros. Luckily the people that designed it know precisely how to use it with no errors.

>>132
tr1 doesn't count; it's not widely implemented.

Only the OpenBSD tree is built with macros; you generate tree code for each type, template style. There are plenty of other implementations to choose from if you don't like it.

>>133
MY ANUS IS WIDELY IMPLEMENTED

_________________
posting from my ANSI C compiler

Albert Einstein, when asked to describe radio, replied: 'You see, wire telegraph is a kind of a very, very long cat.  You pull his tail in New York and his head is meowing in Los Angeles.  Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there.  The only difference is that there is no cat.'



[This fortune brought to you by AndroidFortune on the Google phone]

MY ANUS TRAVELS FASTER THAN THE SPEED OF LIGHT

>>131
What would you remove?

>>137

Is so? Then I'll book a seat on YOUR ANUS to Satori Station

>>137
So I guess it's infinitely dense? OH YEAH TIGHTEN UP

>>139
Your message was perhaps one of the strangest pieces of email I have ever received. Although it is flattering to have a ``faster-than-light anus'', in fact, it is a very bad idea. Unlike most of human society, science and engineering are based on the idea that each of us is capable of evaluating evidence and thinking on our own. Each of us can do experiments, work out the reasoning, and determine the truth for ourselves. There is no room in science or engineering for ``FTL anii'' representing group approval over individual thought. One of my heros, Galileo, put it very well:
In questions of science, the authority of a thousand is not worth the humble reasoning of a single individual.
I am pleased to talk with people about matters of science or engineering, so you and your colleagues may certainly send me mail. I hope to learn as much from your experiences as you may learn for me. But please get rid of the ``FTL anus'' way of thinking. The cult of the flying anus is unscientific and ultimately destructive.

>>141
But please get rid of the ``FTL anus'' way of thinking. The cult of the flying anus is unscientific and ultimately destructive.

it is was allways my dream to become a asstronaut and fly to mars.
why do you have to destroy my dream like this?

>>142
s/fly/fart

Say superluminal instead of FTL, makes you sound smarter.

Also, I lol'd at >>142's
asstronaut

HAX MY ANII, ANONYMOUS

>>99
I am now writing executables manually.

themacbook:~ haxus$ xxd mach-ex
0000000: cefa edfe 0700 0000 0300 0000 0200 0000  ................
0000010: 0200 0000 8800 0000 0100 0000 0100 0000  ................
0000020: 3800 0000 5f5f 5445 5854 0000 0000 0000  8...__TEXT......
0000030: 0000 0000 0000 0000 0010 0000 0000 0000  ................
0000040: c100 0000 0700 0000 0700 0000 0000 0000  ................
0000050: 0000 0000 0500 0000 5000 0000 0100 0000  ........P.......
0000060: 1000 0000 0000 0000 0c00 0000 b500 0000  ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000080: 0000 0000 0000 0000 0000 0000 a400 0000  ................
0000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000a0: 0000 0000 31d2 4053 5150 5204 03cd 8053  ....1.@SQPR....S
00000b0: 31c0 40cd 8068 656c 6c6f 2077 6f72 6c64  1.@..hello world
00000c0: 0a                                       .
themacbook:~ haxus$ ./mach-ex
hello world

Unfortunately getting the linker to do anything like this seems impossible.  It always wants to make (at least) 4 separate 4k-aligned segments.

>>147
macfag

>>148
phanboi

152 Name: Anonymous 2010-12-17 1:37

This post brought to you by the Gay Nigger Association of America