Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Development of the C Language (1993)

bell-labs.com

Post reply on HN
Print view View original

211–220 of 536 posts

Re: The Development of the C Language (1993)

#211

Post by pjmlp »

zabzonk wrote: post #184
pjmlp wrote: post #140

Earlier quoted context omitted.

Petzold did the same on his highly acclaimed book for Windows 3.x book, also with a note on the preface regarding type safety. Likewise, Microsoft introduced windowsx.h header file, to improve type safety while using C for Windows 3.x applications.

> Petzold did the same on his highly acclaimed book takes me back. i thought it was crap. i used to work at The Instruction Set (one of UK's biggest tech training companies at the time) and everyone hated the Windows/C course based on Petzold. my boss came up to me (somehow I was the windows guy in a unix company) and said "we need a new windows course" and me said "OK, i need a framemaker license and to work at home…

Around 1991.

I mostly programmed on Windows 3.x with TPW and TC++, alongside OWL. Those nice Borland manuals.

For me, in what concerns C programming for Windows 3.x, the "Programmer's introduction to Windows 3.1" was a much better book.

Mainly due to its coverage of windowsx and message macros.

It's on the Internet Archive.

https://archive.org/details/programmersintro00myer

Re: The Development of the C Language (1993)

#212

Post by dang »

Related:

The Development of the C Language (2003) - https://news.ycombinator.com/item?id=19338525 - March 2019 (10 comments)

The Development of the C Language - https://news.ycombinator.com/item?id=15134903 - Aug 2017 (22 comments)

The Development of the C Language* by Dennis Ritchie (1996) - https://news.ycombinator.com/item?id=11973627 - June 2016 (1 comment)

The Development of the C Language (1993) - https://news.ycombinator.com/item?id=10749358 - Dec 2015 (28 comments)

The Development of the C Language - https://news.ycombinator.com/item?id=3439843 - Jan 2012 (1 comment)

The Development of the C Language - https://news.ycombinator.com/item?id=2258287 - Feb 2011 (7 comments)

The Development of the C Language - https://news.ycombinator.com/item?id=726519 - July 2009 (1 comment)

The Development of the C Language (Dennis Ritchie) - https://news.ycombinator.com/item?id=365080 - Nov 2008 (1 comment)

Re: The Development of the C Language (1993)

#213

Post by humanrebar »

xyzzy_plugh wrote: post #120
kaba0 wrote: post #114

Earlier quoted context omitted.

> You don't have to use an inefficient solution. You can always roll your own optimized solution or use a library That’s not true. You for example can’t write a generic, efficient vector implementation in C - the language itself can’t do that. You either have to copy paste the same code for different sizes, or make use of some monstrous hack of a macro. Instead projects use hacks like conventionally placing the next/…

You're talking about something that isn't related to efficiency. Copy and pasting, macros, generating code -- none of these preclude producing an efficient solution. There is nothing in C++ that is inherently more efficient than C.

C++ has a lot of compile time programming features that C cannot do practically. There are sometimes alternatives to those mechanisms in C, but they rely on mangling, macros, non-portable tricks, and so on.

On the topic of performance, the best counterargument to C++ from a C perspective would be that hand rolled code generation isn't all that bad in practice. It's just language theorists don't like that approach aesthetically.

Re: The Development of the C Language (1993)

#214

Post by variadix »

kaba0 wrote: post #162
binjooou wrote: post #122

Earlier quoted context omitted.

Generic things are rarely efficient, the most optimal code tends to be specialized and tailored to specific hardware and/or the kind of data its operating on. std::vector (which is a really inefficient way of doing dynamic arrays btw) can be cleanly implemented with macros (see stb stretchy buf) or by splitting the element data from the housekeeping data: int append(void *arr, size_t elemsize, size_t *capacity, size_…

How is std::vector is inefficient? Especially that that macro-hack from stretchy buf seems to do it in an even more naive way. Splitting the element data is a different implementation with very different performance characteristics - it’s quite a bad thing if I have to resort to that due to a language inefficiency, especially in case of a language that is supposedly close to the hardware.

There are various constraints on std::vector because of language in the standard which makes concessions for generic use that might not apply to your application. Small vector optimizations aren’t possible in std::vector, also some operations that could be done in-place can’t be. You also give up control of some meta-parameters and allocation strategies that may be more efficient for your use case.

Re: The Development of the C Language (1993)

#215

Post by flohofwoe »

dermesser wrote: post #209
flohofwoe wrote: post #161

Earlier quoted context omitted.

You can store your 'list items' in an array and still link to random items in the array - although an index instead of a pointer would make more sense in that case, but what else is an index than a pointer with fewer bits ;) The main advantage being that you don't need to alloc/free individual items.

Great, so now we're writing our own memory allocator?

If you want to call about 10 lines of trivial code a 'memory allocator', then yup, we're totally going to write our own 'memory allocator' ;)

Re: The Development of the C Language (1993)

#216

Post by Kamq »

marcosdumay wrote: post #170
kevin_thibedeau wrote: post #125

Earlier quoted context omitted.

Tagged memory architectures don't match the C model of linear memory. They're essentially obsolete now but C is still designed to accommodate them. A lot of the UB the people grouse about can generally be ignored because 99% of the platforms out there have the same behavior in areas where the standard is extra permissive for obsolete exotic hardware. Tagged memmory is dead, 1's complement is dead, big-endian is mostl…

The UB problems have no relation to the machine behavior. UB exists only on the compiler. The fact that many C developers keep confusing it with implementation dependent behavior gives me no confidence on their other opinions about the language.

> UB exists only on the compiler.

Sure, but UB exists so that compilers can generally do whatever's fastest on that particular architecture.

Your signed add instruction traps? Great, do that. Does one on a different architecture overflow? Fine. Just emit it and it's conformant.

Re: The Development of the C Language (1993)

#217

Post by Kamq »

heywhatupboys wrote: post #83
messe wrote: post #23

Earlier quoted context omitted.

Not the commenter you're replying to, but I suspect what they mean is that the C memory model is byte-addressable not bit-addressable. You can't point/refer to a specific bit in memory, instead you have to first read the byte and then select an individual bit using bitwise operations, much like most modern processors.

That has nothing to do with the C memory model, but how the CPU is structured. No modern CPU has an interface for bit-address accessing as far as I am aware... C makes no assumptions about the size of a byte

C doesn't really know about bytes. It has chars, but I believe there are some constraints on char, specifically, they have to be big enough to hold the ASCII charset. (I'm pulling real deep here, someone correct me if I'm wrong)

Re: The Development of the C Language (1993)

#218

Post by dahfizz »

Timpy wrote: post #207

My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?

I program in C (HFT) and I love it

Re: The Development of the C Language (1993)

#219

Post by [deleted] »

AnimalMuppet wrote: post #210
pravus wrote: post #70

Earlier quoted context omitted.

> C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. I guess because I just don't agree with this viewpoint at all. I've been writing C on and off for over 20 years now and I simply haven't encountered the amount of distress and pain that I see others deal with, especially when…

Well... I'm in embedded systems. In embedded systems, you almost never change compilers. You usually don't even upgrade the compiler. Whatever the compiler is for a project, that's what it will be for that project forever. And in your case, it sounds like you only compiled that code with one compiler. But as far as UB goes, that's cheating. We're playing on "easy mode". We know what that compiler is going to do, and…

[deleted]

Re: The Development of the C Language (1993)

#220

Post by bhasi »

Timpy wrote: post #207

My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?

I'm an embedded Linux engineer and I love C and Linux in particular. However, I'm considering dipping my toes in non-embedded stuff for a while, particularly full-stack development and wondering if the grass is greener on the other side from me, haha!
Post reply on HN