Earlier quoted context omitted.
For the third time, the API for setting stack size should be implementation defined because there are perfectly practical implementations for which any specification would be meaningless. Another reason is that almost all prevailing contemporary environments use virtual memory, and the prevailing embedded architecture (ARM) is about to go 64 bit (the desktop/server world already has). In a world with virtual memory,…
Please give an example of an implementation of this thread API where having the ability to specify the desired stacksize would "be meaningless" ? Even on 64bit machines you can and will have memory fragmentation when you approach a million threads. PS: A bad analogy is like a wet screwdriver.
ISO C is increasingly moronic
71–80 of 175 posts
Re: ISO C is increasingly moronic
#72Earlier quoted context omitted.
Funny you should say that: I've always wondered how it worked in the inside. I'm not claiming it is a great opera house, but it is a very good example of using modern building tools. When Utzon died, one of our (Danish) newspapers explained that the required maintenance is now necessary because the architects original plan to cap the "top-seams" with metal was judged too expensive, and some plastic-sealant ("Caulk" ?…
Basically Utzon designed it to look awesome. And it does. As a work of sculpture it's really lovely, and the engineering to make it stand up is difficult and impressive. But as I said, Utzon and his offsiders obviously did not care about the actual purpose of the building, or whether their beautiful design would be at all practical. It's not. Even Frank Gehry, whose work I find to be obnoxious, has managed to design…
The internals of the building were not built to Utzon's design; they were redesigned and built after Utzon resigned in 1966.
Re: ISO C is increasingly moronic
#73Earlier quoted context omitted.
Maybe the ISO committee is conspiring to destroy C with mediocrity so that a shiny new systems language can take its place, correcting C's deeper warts in the process. That would be nice, if only I believed it.
Exactly. I've long since lost track of which shiny new systems language we're supposed to be using.
Re: ISO C is increasingly moronic
#74Earlier quoted context omitted.
You have absolutely no idea what, or rather: who, you are talking about: I'm the second most active committer to FreeBSDs kernel over the project lifetime and I'm the author of Varnish, I even have C-code running in ATC systems, heck when it comes to that: My code scrambles your password. It's exactly because I am responsible for so much old code that I say we should not cripple the future for it.
Do you think a new language (Go, maybe?) will take C's place, given your distaste for ISO's handling of the standard?
Re: ISO C is increasingly moronic
#75Earlier quoted context omitted.
Initial underscore followed by a capital letter is a reserved "namespace" since 1990, as a previous commenter noted. (And for the record, identifiers that begin with two underscores are reserved for use by the implementation, and identifiers followed by a lowercase letter are guaranteed to be unreserved as long as they are file-scoped symbols, and not globally visible.)
Yes, I realize this, but since it's only "reserved" in the specification and the compiler doesn't enforce this, there is a massive amount of code that does this today. The spec could contain, "don't add any bugs into your C programs" but that doesn't magically mean that everyone would write bug free code. Reserving a namespace and not having a mechanism to enforce it was a massive fail on the part of the standards co…
How do you expect the compiler to enforce the "identifiers that begin with two underscores are reserved for use by the implementation" rule? Some things just belong in the documentation.
Re: ISO C is increasingly moronic
#76Earlier quoted context omitted.
Basically Utzon designed it to look awesome. And it does. As a work of sculpture it's really lovely, and the engineering to make it stand up is difficult and impressive. But as I said, Utzon and his offsiders obviously did not care about the actual purpose of the building, or whether their beautiful design would be at all practical. It's not. Even Frank Gehry, whose work I find to be obnoxious, has managed to design…
Your remarks are superficially plausible and fit many people's pet theories about architects. The only flaw is that they don't have any relation to the reality of the construction of the actual Sydney Opera House. The internals of the building were not built to Utzon's design; they were redesigned and built after Utzon resigned in 1966.
My understanding is that Utzon's original design was, basically, impossible. The new design was a compromise made during intense negotiations with physical reality after Utzon had quit.
The further point is that those compromises rule out little things such as the ochestral pit or the tower. Things that are sorta kinda really really useful for ochestras.
If it was up to me I'd build the usual mausoleum somewhere else and turn the "opera house" into something else. A museum perhaps.
> Your remarks are superficially plausible and fit many people's pet theories about architects.
Availability bias. We never hear about the vast majority of architects who stick to designing safe, sensible and non-hideous buildings. We do hear about self-promoting designers of monuments to their own egos, such as Gehry. And naturally this tilts the public view of architecture.
Re: ISO C is increasingly moronic
#77Earlier quoted context omitted.
You have absolutely no idea what, or rather: who, you are talking about: I'm the second most active committer to FreeBSDs kernel over the project lifetime and I'm the author of Varnish, I even have C-code running in ATC systems, heck when it comes to that: My code scrambles your password. It's exactly because I am responsible for so much old code that I say we should not cripple the future for it.
Do you think a new language (Go, maybe?) will take C's place, given your distaste for ISO's handling of the standard?
Go was a reaction to Java back to almost center.
C is close to hardware, which is important for things like game engine cores, video drivers, varnish and the list of use-cases goes on and on.
Finally, people tend to complain about their tools even when those tools work. Be thankful if you didn't have to write the tool yourself. But if you would feel compelled to complain, write a better one yourself first instead. :)
@phk: When was the last time you wrote inline asm in C to solve any problem on an non-embedded system? Mine was 1996.
Re: ISO C is increasingly moronic
#78I don't see this as particularly monstrous - it's reasonably succinct, and in this case a macro implementation does the job just as well as a built-in linked list would, and with much more flexibility. #define VTAILQ_INSERT_BEFORE(listelm, elm, field) do { \ (elm)->field.vtqe_prev = (listelm)->field.vtqe_prev; \ VTAILQ_NEXT((elm), field) = (listelm); \ *(listelm)->field.vtqe_prev = (elm); \ (listelm)->field.vtqe_prev…
There are many things horrible about it. Its arguments are evaluated many times which is different than what you would expect. The fact that you have to pass field is just plain clumsy. C could benefit tremendously from a parameterized type mechanism.
True - I would like to see the GCC extension that allows this to be done safely standardized, or improved.
> The fact that you have to pass field is just plain clumsy.
Sort of. I think the C trick of having linked list pointers inside the struct rather than the usual external wrapper is quite nice: it has good performance (especially in cases with multiple lists, to the extent that Boost has Boost.Intrusive even though it's really gross in C++), and explicitly codifying "struct A is a member of exactly one A-list" makes things feel simpler to me. You could have some kind of magic object in the list head that defines which member field it uses, but I don't know if that's worth the downside of the implementation no longer being trivial (and thus easy to understand).
I mean, there are lots of generally ugly points to C macros, but I have yet to see a better option for this kind of stuff that doesn't sacrifice either performance or simplicity - although the macro language itself could certainly be vastly improved.
Re: ISO C is increasingly moronic
#79Earlier quoted context omitted.
First off, I didn't realize. I'm sorry. I am responsible for so much old code that I say we should not cripple the future for it. I had to read that a few times. Are you advocating a clean break so that whatever that is future is clearly not called C or even purports to be backwards compatible with C? That would be difficult wouldn't it? It simply wouldn't get traction.
I'm not sure I have a coherent proposal. Clearly ISO-C is a cul-de-sac by now, and will have to be ditched. What we should replace it with is not clear to me. It is a big problem that so many standards, requirements and tools (from EMACS to Coverity over lint) have their fingers in the C-syntax. The autocrap abomination is a further complication. So I guess a good place to start is to swear that we will never touch o…
A long period of stability may also make it easy for C to interact with other languages. I'm out of my depth here. Some standard specifications for pinning memory from garbage collection, if Scheme could specify TCO, perhaps C-consolidation release could improve its toolability for things like Coverity; A better autoconf; Makefiles; Standard compilation error codes; Something that would clean up all the rough edges in supporting C compilers.
Re: ISO C is increasingly moronic
#80Earlier quoted context omitted.
Your remarks are superficially plausible and fit many people's pet theories about architects. The only flaw is that they don't have any relation to the reality of the construction of the actual Sydney Opera House. The internals of the building were not built to Utzon's design; they were redesigned and built after Utzon resigned in 1966.
> The internals of the building were not built to Utzon's design; they were redesigned and built after Utzon resigned in 1966. My understanding is that Utzon's original design was, basically, impossible. The new design was a compromise made during intense negotiations with physical reality after Utzon had quit. The further point is that those compromises rule out little things such as the ochestral pit or the tower.…
As a kid I wanted to be an architect. Maybe I'm suffering from armchair expertise. "I use buildings, therefore I'm an architect".
But sometimes mistakes are so visible that end users can point them out. My personal bête noire is the business school building at the University of Western Australia. Just a stunning array of dumb details, but it's visually bold and jaunty. I guess that's what sold.