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

291–300 of 536 posts

Re: The Development of the C Language (1993)

#291

Post by _kst_ »

nathants wrote: post #289

everyone should learn c/c++. you need it when exploring the performance ceiling of a workload. without an understanding of performance ceiling, you can’t design a system well. if you want to approach that ceiling[1], you need to implement c/c++. if not, it’s better to have chosen not than been forced not. between ccls, clangd, and clion, tooling is fantastic now. it’s a great time to start. 1. https://github.com/nath…

What exactly is "c/c++"? Do you mean C and C++? Though they're obviously closely related, they're two distinct languages.

Re: The Development of the C Language (1993)

#292

Post by 1vuio0pswjnm7 »

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?

CSS can control a web browser (software). C can control a computer (hardware).

That is how I see it. Others may see it differently.

Re: The Development of the C Language (1993)

#293

Post by coliveira »

zer8k wrote: post #267
coliveira wrote: post #228

Earlier quoted context omitted.

Why not? You seem to underestimate the ability of AI tools to understand code. Undefined behavior is something that a good AI tool may avoid without major problems.

The issue to me is not the generation of code. It's that the person using it is inexperienced with the given language. We will never be able to place 100% faith in AI. At least in my lifetime. Given that, I think it's a relative danger that is washed away in all the hype. A junior dev copy-pasting code from chatgpt. I couldn't imagine a more dangerous combination.

Junior dev copy-pasting from stack overflow: this is already happening! Whatever bad thing AI tools can do, this is already reality all over the world.

Re: The Development of the C Language (1993)

#294

Post by bathMarm0t »

pjmlp wrote: post #264
falcrist wrote: post #52

Earlier quoted context omitted.

Microcontrollers exist. Their libraries are written in/for C. The programs running on them are small and need tight, efficient memory management. I also like the minimalist nature of the language itself. I get that for desktop applications, you usually want more integration with the operating system so you can say "I want a window here and a button here" rather than having to manually build the window from scratch, b…

Are the Arduino and ESP32 microcontrollers? Hint, might check their libraries/SDKs before answering.

Don't think I'm too crazy but last time I checked:

1. Yes they are microcontrollers.

2. Yes they use C/C++. (check the libraries/SDKs, 1 layer under the hood it's all .h/.cpp files, and most of the arduino calls are just #defines)

Re: The Development of the C Language (1993)

#295

Post by [deleted] »

flohofwoe wrote: post #167
creata wrote: post #148

Earlier quoted context omitted.

> If a line of code doesn't look like a function call, it's not calling anything. Why is that important to you?

It's important for reading other people's code. When I see a function call then I know that "anything" can happen inside that function, so I better investigate. For anything that's not a function call it is obvious what happens under the hood. In languages like C++ I potentially need to check every operator if it is overloaded, and find the place where that happens (I think I haven't seen any IDE support to help with…

[deleted]

Re: The Development of the C Language (1993)

#296

Post by c_crank »

synergy20 wrote: post #282
zabzonk wrote: post #130

Earlier quoted context omitted.

they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe. i will never understand why C programmers get so upset about C++. of course, the latest revisions of C introduce some new features not in C++, but nothing really major. if you want good type checking, compile your C code with C++, and fix all the type errors you will get.

I dreamed about a simplified c++, that is better/safer than c but much simpler than existing c++, call it c+, a subset c++ that enhances c but not bringing in all those c++ complexities that I 99% do not need in daily coding.

There is such a language called D.

Re: The Development of the C Language (1993)

#297

Post by c_crank »

aldanor wrote: post #260
synergy20 wrote: post #112

Earlier quoted context omitted.

neither does the IDE tools I feel, it's going to take a while, and Rust has been here for 17 years.

IDE tools like what? LSPs for Rust are on par / better than that of C/C++, partially because of language being stricter, no #include nonsense etc. Unlike C/C++, sane build system and dependency management system that are universally agreed upon actually exist. What exactly is "going take a while"?

People universally agree that replicating NPM's dependency hell was a good idea?

Re: The Development of the C Language (1993)

#298

Post by c_crank »

_kst_ wrote: post #291
nathants wrote: post #289

everyone should learn c/c++. you need it when exploring the performance ceiling of a workload. without an understanding of performance ceiling, you can’t design a system well. if you want to approach that ceiling[1], you need to implement c/c++. if not, it’s better to have chosen not than been forced not. between ccls, clangd, and clion, tooling is fantastic now. it’s a great time to start. 1. https://github.com/nath…

What exactly is "c/c++"? Do you mean C and C++? Though they're obviously closely related, they're two distinct languages.

C for utilities and your OS, C++ for your video game.

Re: The Development of the C Language (1993)

#299

Post by nitrix »

messe wrote: post #256
heywhatupboys wrote: post #83

Earlier quoted context omitted.

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

If I remember correctly, it assumes the size of a char is greater than or equal to seven bits, and a char is defined to be the smallest addressable unit. C does not support bit-addressing.

The width is defined as CHAR_BIT >= 8 (C11 5.2.4.2.1p1). The size, sizeof (char), is always 1.

Re: The Development of the C Language (1993)

#300

Post by nitrix »

Kamq wrote: post #217
heywhatupboys wrote: post #83

Earlier quoted context omitted.

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)

C11 3.6p1 byte "addressable unit of data storage large enough to hold any member of the basic character set of the execution environment"
Post reply on HN