WHY WOULD ANYONE WANT TO LEARN C?

FOR REALS? WHATS THE POINT? TOO MUCH MICRoMANAGED BULLSHIT THAT GETS YOU NO WHERE EXCEPT A HOLE IN THE HEAD. BESIDES, YOU CANT USE C FOR ANYTHING USEFUL!!!! WHY DONT YOU LEARN A REAL LANGUAGE LIKE JAVA OR C#??? OR BETTER YET, PHP.

MICRoMANAGED
How unsightly.  You dropped the Cruise Control for such a trivial vowel.

>>2
for

You shut your goddamn whore mouth!

>>1
cum in my anal

>>1
whats the....POINT?!
c

Well played, OP.

>>5
The ``OP'', as you called him, never wrote ``whats[sic] the'' in lower case, nor did he mangle ellipsis like you did.

>>6
u r a faget

>>7
Dis hole bored is fuhl uf fagits

>>1
http://sovietrussia.org/f/src/AAAAAAAA.swf

OP is partially right, though. I've used a lot of C lately and I feel that my ability to program in a non-strictly-procedural way is diminished.

>>10
That's odd, all C I do is pretty much OOP.

>>11
objective C

BAHAHAHA

C is a systems programming language. It was designed to allow the programmer to micromanage execution down to low level detail. If you are building large scale apps that require speed and efficiency, then you have to learn how to manage run time efficiency. Faster processors have not made low level languages obsolete, they merely enable a much larger scale of complexity.

there is no reason to use C or C++ unless you have the above mentioned requirement, Java, C# should be fine in any other situations

>>13
It has such an ugly syntax and an incredibly high learning curve. Why would anyone want to use it other than for games?

>>14
Its a matter of abstraction vs efficiency. Highly abstract languages make expressing thoughts clearer and more succinct to the programmers eye, but hide important details that are needed for making a program run efficiently. C programs are necessarily verbose because the programmer requires explicit control down to the level of how a program will execute at hardware level

420 program C erryday

>>15
but hide important details that are needed for making a program run efficiently

efficiency has nothing to do with it, this is implementation dependend.
in theory that is ofcourse, but i cant say that i know anything about how it is in practice. but i can imagine how inefficient most are.

efficiency has nothing to do with it, this is implementation dependend.

bullshit, C was meant to be a portable assembly language, implementation has NOTHING to do with it

>>18
bullshit, C was meant to be a portable assembly language, implementation has NOTHING to do with it

not even the compiler?
lol

>>15
C programs do not grant the programmer explicit control of how a program will execute at the hardware level on many architectures and with many optimizing compilers.  The resulting instructions for a given sequence of C statements compiled with a good optimizing compiler might not ostensibly correspond to the original statements. Advanced implementations of many instruction sets (all new x86 for over a decade, for example) are implemented in such a way that the  instruction set is not representative of the actual implementation inside the CPU.  Details like cache, virtual memory, etc. prevent nearly all programs from having any low-level control of how they work, excepting programs running in real mode using implementation-defined cache control/disable instructions (which are not part of C anyway).

>not even the compiler?
>lol

no, not even the compiler, like you even know what a compiler back end is

Guise i'm drunk with dxd, pixel-spotlight and greenie from dA lolomg

VIPPER has been unusually non-JEWSy lately.

>>21
like you
even know
how to quote

you guys are fuckin great.
anyone wanna tell me how to quote? [quote] IS FUKKEN BORK [/quote]

>>24
Please optimize your quotes!

>>20
The major problems these days that crop up with optimizing C compilers reordering statements occur in multi-threaded, multi-core environments.  In these environments, programming in assembly is only marginally better because the processor will reorder your stores and loads anyway.

If you look at Linux, memory ordering is handled by inserting different macros in your code.  Depending on the processor, these will expand to "asm volatile ..." or "__asm__ __volatile__ ..." or whatever is necessary.  The assembly instructions inside instruct the processor to be strict about some memory ordering, and the "volatile" keyword instructs the compiler to be strict.

You can't do that kinda shit in Java or C#.  Not by a long shot.  And you might as well use C, because C works, assembler takes way longer to write and maintain, and 90% of the programmers out there can't write assembler better than a C compiler anyway.

And the Java and Mono VMs are written mostly in C anyway, just like a good chunk of the C runtime is written in assembler.  C won't go away because there's nothing to replace it.

>>27
Actually, you can do it in Java and C#.

Java's volatile modifier keyword enforces strict memory ordering, it will end up translating to machine code that uses the target platform's atomic compare-and-swap instructions or memory fence instructions.

.NET has System.Threading.Interlocked class to atomically operate on integral types as well.

Unfortunately, both are kind of heavy weight and don't make use of platform specific optimizations. For example, on x86, memory loads and stores are in-order no matter what and you don't need to atomically synchronize everything, even in multi-threaded applications. You only need to worry about old data in various cores' cache, and making sure the cache is synchronized with the main system RAM.

C++0x and C1x both have new atomic types as part of their standard libraries that let you specify the type of memory ordering you want to use in the operations you perform on them. If you know the assembly language for your target platforms, it's trivial to write these libraries yourself today, without needing to wait for new compilers implementing the new specs. They don't rely on new language features.

>>28
Oh, and just to be clear, any atomic operations that need acquire or consume semantics on x86 can just be implemented using regular relaxed non-atomic instructions. Release, acquire-release, and sequentially consistent semantics need to be implemented using actual atomic instructions.

>>28
I'm sorry, I left out an implicit assumption that you also wanted to pin some of the memory to a specific place, e.g., to communicate with memory-mapped I/O.  Yeah, you can *do* that in unmanaged C# code but I'd stick with C.

>>30
Agreed, C or C++ are better for that kind of low-level stuff.

I use C for Unix OS programming.

>>28
thanks, I can't think about atomic operations without listening to the song Atomic by Blondie.

>>33
Heart of Glass is better.

>>34
I fail to connect Heart of Glass to atomic operations.

>>14
I wouldn't use C# for a botnet.

You wouldn't sage a shit thread.

>>37
No. I wouldn't. But I would bump one.

what's the basis of all programing?
CPU instructions, right?
CPU instructions is the most high-level language, after binary.
after it comes other languages like C, C++ etc...

Now, tell me what would have happenned if all of a sudden, devellopers had stopped bothering with CPU instructions when C became popular?

they wouldn't have been able to make more powerfull CPU architecture, and we wouldn't have our multitask, multicore, low voltage(etc...) CPUs..

>>39
I lol'd

>>39
>CPU instructions
>most high-level language

>>39
after binary
U MENU ``machine code''?

>>42
MENA*

>>42
U MENU
（　≖‿≖）

>>44
I already corrected my mistake, but thanks anyway.