Look around your working area and/or your home. Stuff scattered everywhere, on tables, on the floor? If so, stop using C and use a language that forces you to keep your stuff in the right place. Like C++ or Java. You may not be suited for a language that [ss]lets[/ss] forces you to do your own structuring.
It might be beause you're using C, are you going to develop an advanced program, you need to do low-level coding, which is hell for those not used to it.
I prefer Java and C#.
Name:
Anonymous2012-02-02 10:10
If you actually write c99 or c89 and not GNU_C there shouldn't be a problem.
>>20 u8 would be interpreted by 99.9% of C programmers to mean an unsigned 8-bit quantity. FrozenVoid uses it to mean an unsigned 64-bit quantity. C99 also already has the portable types like uint64_t so why make your own version?
FrozenVoid didn't even know the C standard let alone know how to code elegantly.
Name:
Anonymous2012-02-02 17:21
>>25
ooh I'd like to see an autistic FrozenVoid vs jobless_gallery_programmer showdown
Name:
Anonymous2012-02-02 17:25
>>26
I've never seen jobless_gallery_programmer actually write C code. He appears to know his standard, but not once did I ever see him write his own C code. Also he's a ENTERPRISE JAVA DEVELOPER while FV is just some basement dweller that self-taught himself C in a very poor manner and doesn't know shit about the actual language nor its standard
>>27
I've posted C code on here before. I just did it under Anonymous. And guess what? There wasn't one comment about undefined behavior or about me missing any kind of errors.
Name:
Anonymous2012-02-02 19:10
I've posted C code on here before. I just did it under Anonymous. And guess what? There wasn't one comment about undefined behavior or about me missing any kind of errors.
Name:
Anonymous2012-02-02 19:50
>>28 >>29
I did say you appear to know your standard kodak-san.
>>33
I can deal with that, all it takes is reading the manual for each common instruction. It's barely a few dozen pages, as opposed to the C fucking standard which is a bloated mess of undefined behaviour.
>>34 It's barely a few dozen pages
Maybe if you're writing programs for an XT. After all of the recent extensions and obsolete garbage introduced in the last 30 years it's several thousand. All of this garbage takes up space on the dies and in the minds of programmers but can't be thrown away because when x86 boots it's 16-bit and pretends it only has 1 MB of RAM. The OS needs this 16-bit garbage to unlock the modern instructions. MIPS doesn't have hundreds of pages of legacy garbage and short-sighted decisions like x86 does. The entire user-mode MIPS instruction set can be described in a few dozen pages. Why isn't MIPS popular in desktops today? Because SGI believed Intel about the Itanium and cancelled their MIPS designs. Soon after, they filed for bankruptcy.
>>37 SGI believed Intel about the Itanium and cancelled their MIPS designs. Soon after, they filed for bankruptcy.
That's just typical Kol Nidre behavior All personal vows we are likely to make, all personal oaths and pledges we are likely to take between this Yom Kippur and the next Yom Kippur, we publicly renounce. Let them all be relinquished and abandoned, null and void, neither firm nor established. Let our personal vows, pledges and oaths be considered neither vows nor pledges nor oaths.
Name:
Anonymous2012-02-03 2:50
Avoid structures and pointers whenever you don't absolutely need them.
Before using either, really think as to whether it will make your code easier to read and neater.
Rule of Simplicity: Design for simplicity; add complexity only where you must. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
Name:
Anonymous2012-02-03 9:05
>>37 MIPS doesn't have hundreds of pages of legacy garbage and short-sighted decisions like x86 does.
LOL. Anyway, you're completely ignoring the commodification of 3D hardware. Towards the end, SGI didn't offer anything you couldn't get somewhere else.
Name:
Anonymous2012-02-03 9:20
>>37
The bootloader does away with 16-bit mode. The only time you might encounter it is if you want to write a 16-bit interpreter for BIOS code in order to interact with the old BIOS interface, which you shouldn't because EFI is there. The legacy garbage is the manufacturer's problem, not the programmer's.