* Prefix notation
* Higher order functions
* Closures
* Lexical scoping
* Garbage collection
* First-class continuations
* Tail-call optimization
* Hygienic macros
* Full numerical tower
* Code as data
Name:
Anonymous2012-02-24 20:07
>>162
Good thing Sexprs aren't on your list, I would have had to rape your little queer anus if you catch my drift.
Name:
Anonymous2012-02-24 20:42
>>162 * Prefix notation
Use GMP or define macros. * Higher order functions
Already has them. See bsearch, qsort and signal. * Closures
Use C++ lambdas or a context struct. * Lexical scoping
Use C++ lambdas. * Garbage collection
Implementation-dependent. Undefined behavior means that the standard does not state what happens to malloced regions when they are no longer reachable. * First-class continuations
Use setjmp and longjmp with an implementation that lets you use jmp_bufs at any time after the caller returns. * Tail-call optimization
Implementation-dependent. Some compilers already do it. * Hygienic macros
Use nested scopes using do{}while(0), token concatenation, or inline functions. * Full numerical tower
C has no operator overloading. How does it add bignums? Terrible! * Code as data
Implementation-dependent. In some cases it's impossible because code and data are in different address spaces and code is execute-only. In other cases, casting a function pointer to a char * could return a string containing the C source of the function, and casting back could compile a string as C code. Those are all possibilities of undefined behavior.
>>1
I would add SEXP-s to allow robust macros, then lambdas and dynamic typing with optional type signatures. Some package management would be nice too - glVertex crud in global namespace looks ugly.
Name:
Anonymous2012-02-24 21:28
>>166 glVertex crud in global namespace looks ugly.
Also, I cant have several versions of GL library running.
Name:
Anonymous2012-02-24 22:45
>>167
You'd have to change the whole library model to be able to do that.
Most of you guys don't seem to realize what C was created for. I wouldn't change a single thing about C because it's great for what it's meant to be and do.
Tagged unions. tagged_union generic_object {
FILE *file;
struct {
size_t len;
char *buf, *current;
} buffer;
int sock;
};
int read_generic(tagged_union generic_object g) {
switch(g) {
case file:
case buffer:
case sock:
}
}
If the types are known at compile time, inlining and dead code elimination could allow the functions to be replaced by inline cases and the tags to be removed at compile time. Regular unions which are tagged with an enum or integer aren't as efficient because there's no standard way to associate enum values with union members.
Name:
Anonymous2012-02-25 21:57
C was already changed, its called C++. I use C++ to do C programming because I prefer cin/cout and the string class to C's insane I/O.
http://en.wikipedia.org/wiki/ALGOL_68
I would deprecate C and bring back the ALGOL standardization committee. It's pretty sad when languages from the 60's like Lisp, ALGOL and APL are more advanced and modern than junk languages like Java, PHP and Go. I wonder what 60's scientists and engineers who thought we would be vacationing on Mars and talking to strong AIs in the year 2000 would think about our current state of computing if they arrived in a time machine?
>>181
Hmmm, this sounds harsh but I guess it's true.
Name:
Anonymous2012-02-25 23:32
>>181 I wonder what 60's scientists and engineers who thought we would be vacationing on Mars and talking to strong AIs in the year 2000 would think about our current state of computing if they arrived in a time machine?
MacCarthy's last project was Elephant http://www-formal.stanford.edu/jmc/elephant/elephant.html Elephant programs themselves can be represented as sentences of logic. Their extensional properties follow from this representation without an intervening theory of programming or anything like Hoare axioms.
which sounds like an interactive version of Wolfram Alpha, where user can input facts himself.
>>186
Yes, it is much better for a program to subtly crash and have memory corruption based exploits than, *gasp* use garbage collection.
Name:
Anonymous2012-02-27 0:19
This thread is fucking fail. C needs:
1. Real string library. Yes, ASCIIZ was a mistake.
2. Expanded standard library. File system abstractions are the big one. Why do we assume all implementations will have files but not folders? struct packing is another problem that is incredibly common and frequently done horribly horribly wrong, but solved with a very simple library.
3. Minor stylistic fixes including non-semicolon terminated labels before end of block, const const cast fixes, remove the untagged nested struct/union bubbling crap, remove the sole register storage class semantic.
4. Better specified sequence point model, in particular synchronizing the order of execution of side-effects between sequence points with the order of evaluation.
5. Consolidation of types. The int, short, long, long long, uint, ushort, ulong, size_t, ptrdiff_t, int, uintn_t, intn_t, intptr_t, int_fastn_t, uint_fastn_t, int_leastn_t, uint_leastn_t, uintptr_t crap is just remarkably stupid. int and char should be implementation defined widths, but it does not make sense for anything else.
6. Better error handling mechanisms. Huge swathes of most large codebases are dedicated to checking return values, the errno crap is incredibly stupid, not thread safe, not even internally consistent. Look at the code for parsing a long in man 3 strtol, and compare with Java catch(NumberFormatException e).
7. Unicode support, wide characters are a fucking plague.
>>190 1. Real string library. Yes, ASCIIZ was a mistake.
Your "real strings" are in C++. Use that instead of turning C into C++. 2. Expanded standard library. File system abstractions are the big one. Why do we assume all implementations will have files but not folders? struct packing is another problem that is incredibly common and frequently done horribly horribly wrong, but solved with a very simple library.
Folders are different in every filesystem. How would a standard way of representing directories work since different OSes and filesystems use '\', '/', '::', ':', and '.' as path separators? How would the files be enumerated in directories? What would it do with a directory called C/C++ standard headers? How would it handle drive letters in Windows or DOS? What about future OSes? <dirent.h> is only useful for POSIX directories. _Alignof and _Alignas were added to C11 for struct packing. 3. Minor stylistic fixes including non-semicolon terminated labels before end of block, const const cast fixes, remove the untagged nested struct/union bubbling crap, remove the sole register storage class semantic.
Why remove register? It's a hint that the address of the object cannot be taken. 4. Better specified sequence point model, in particular synchronizing the order of execution of side-effects between sequence points with the order of evaluation.
C leaves the order of ++/-- and argument evaluation unspecified to make it easier for the compiler to optimize for that machine. If you care about the order, use the comma operator or split it into separate statements. Scheme also leaves the order of argument evaluation undefined. 5. Consolidation of types. The int, short, long, long long, uint, ushort, ulong, size_t, ptrdiff_t, int, uintn_t, intn_t, intptr_t, int_fastn_t, uint_fastn_t, int_leastn_t, uint_leastn_t, uintptr_t crap is just remarkably stupid. int and char should be implementation defined widths, but it does not make sense for anything else.
Not everything uses 8-bit bytes and 32-bit longs. Some Crays use a whole 64 bits for chars because it's faster than using shift and mask. For people who only use MSVC, this doesn't matter, but people who care about portability want to make sure their code still compiles 60 years from now. 6. Better error handling mechanisms. Huge swathes of most large codebases are dedicated to checking return values, the errno crap is incredibly stupid, not thread safe, not even internally consistent. Look at the code for parsing a long in man 3 strtol, and compare with Java catch(NumberFormatException e).
The Linux man pages are full of GNU-style crap which is usually the most compilcated way to write code. errno is thread-safe on all systems with multi-threaded C libraries (even Windows and Linux). If it isn't thread-safe and the OS is, you should file a bug report with the compiler manufacturer (if you're not using a 15-year-old compiler). Again, if you want C++ features like exceptions, use C++. errno = 0;
val = strtol(str, &endptr, base);
if (errno) {
/* handle error */
} 7. Unicode support, wide characters are a fucking plague.
Unicode has been added to C11. I checked the date on your post twice to make sure I wasn't responding to a post from 2006.
>>193 Your "real strings" are in C++. Use that instead of turning C into C++.
A feature being present in one language does not preclude it being needed in another. Length prefixed strings are not some newfangled high level concept, they are just an alternative to null terminated strings that have proved to be better. folders bla bla bla
Funny, files are different in every filesystem too, so is the size of a byte, and the basic execution character set. That "but.. but.. portability!" drivel might work on children, but not me sorry. _Alignof and _Alignas were added to C11 for struct packing.
I haven't read C11 yet, but in any case these aren't sufficient for the primary use case (serialization). You also _Byteorderof, _Bitorderof, _Paddingbyteof, and a whole host of other shit. Why remove register? It's a hint that the address of the object cannot be taken.
I didn't suggest removing it, reread what I said. C leaves the order of ++/-- and argument evaluation unspecified to make it easier for the compiler to optimize for that machine.
Irrelevant, reread what I said. In particular that statements like p = p->next = q; are undefined. Not everything uses 8-bit bytes and 32-bit longs.
Reread what I said. "int and char should be implementation defined widths" The Linux man pages are full of GNU-style crap
Point is well taken, but it was just an example. Do you care to rebut the point that managing exceptions and return values in C takes an inordinate amount of effort? If it isn't thread-safe and the OS is
What is an "OS"? Where is that mentioned in the C standard? Unicode has been added to C11.
I wasn't aware of that, thanks.
1. ASCIIZ still is the best solution for handling strings. It is absolutely overhead-free, which fits well with the rest of the language. One is always free to implement strings in some other way, and it is so simple to implement that even macros can handle the boilerplate. Trying to make strings look as if they were simple data types (as integers) is the real mistake;
2. True. However, I don't understand what you mean by "structure packing is another problem that is solved with a very simple library", care to elaborate? Structure packing is never a problem if one is versed in the standard.
3. Agreed.
4. Agreed.
5. Agreed, though it would be quite hard to solve this problem.
6. Agreed to an extent. Handling errors is -not- simple as people might expect -- error handling should actually be considered part of the business logic itself, and not something "exceptional" (pun intended). Do you have a suggestion on how to make this better? Also, errno is thread-local in systems featuring threads, and the C standard (up to C99) does not know what a "thread" is. I don't know about C11 though. If errno is -not- thread-local in C11, then yes, this is a serious defect.
7. Disagree. C is character encoding-agnostic, and that is Good. Unicode support is cancer.
Name:
Anonymous2012-02-27 10:35
>>193 If you care about the order, use the comma operator or split it into separate statements
A feature being present in one language does not preclude it being needed in another. Length prefixed strings are not some newfangled high level concept, they are just an alternative to null terminated strings that have proved to be better. struct string {
size_t length;
char str[];
}; Funny, files are different in every filesystem too, so is the size of a byte, and the basic execution character set. That "but.. but.. portability!" drivel might work on children, but not me sorry.
A filename in C is a string that references something that can be accessed using fopen. Path separators, drive letters, file versions, and resource fork IDs, if they exist at all, are all part of the string. A file in C doesn't have to have a size and doesn't have to be seekable. All it needs is some way to read and/or write bytes in either text or binary modes (which can be the same). Data written to a file can be reread on the same machine no matter what character set, byte size, or byte order is used by reading and writing the same data types. Data can be read portably on any machine by serializing the bytes with shifts and masking and using a translate table where e.g. table['a'] == 97;. Whether a file is a regular file, device, pipe, symbolic link, memory-mapped data, or any other type, it can always be accessed as a stream of bytes. You can portably open argv[1] if it's a valid filename no matter what filesystem or path separators are in use.
Directories are not simple streams of bytes or lines of text. They contain other items and standardizing directories is useless unless there is a way to list these items. Can directories contain subdirectories? What about symbolic links? Should they be followed? If they are followed, how would a directory that contains a link to itself be handled? What about resource forks? If the file has resource forks, programmers will want to be able to see them. Should these multiple resource forks or data streams be viewed by opening the file as a directory? This won;t work if symbolic links or directories have resource forks separate from their referenced files. Do hidden files begin with a "." or have an attribute? Should there be a way to access hidden files? How do you determine the path separator? What about determining what drive letters are accessible? What about files with multiple versions like in VMS?
POSIX sys/stat.h mentions inodes and group IDs, but doesn't mention hidden attributes, access control lists, alternate data streams or type codes. dirent.h says nothing about them either. I haven't read C11 yet, but in any case these aren't sufficient for the primary use case (serialization). You also _Byteorderof, _Bitorderof, _Paddingbyteof, and a whole host of other shit.
I agree that there should be some way to improve portably serializing structs. I think C should add functions similar to hton* and ntoh* functions. I would have the "network" side of these functions be an array of unsigned char with a maximum of 255 even if bytes are more than 8 bits. If you read the C11 standard you will find that _Alignas controls padding bytes. What is an "OS"? Where is that mentioned in the C standard?
"OS" meaning some collection of functions that is included with the system but is not part of the C standard or the compiler's extensions. This "OS" might support threads even if the compiler and C library do not. If the compiler implementer claims to support threads and errno is not thread-safe, you should file a bug report.