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

Linus vs C++, again

realworldtech.com

Post reply on HN
Print view View original

81–90 of 209 posts

Re: Linus vs C++, again

#81

Post by ramidarigaz »

tptacek wrote: post #42
mojuba wrote: post #31

Earlier quoted context omitted.

write(fd, buf, size); Can you list all the caveats, possible side effects, reasons of failure of this simple C function call? Hint: remember, fd can be a file, as well as a NFS-mounted file, pipe, network or local socket, FIFO, device, etc. Hint2: I doubt anyone can give a comprehensive description of the possible consequences of this call. Bottom line being, C can be incredibly hard to understand, or C++ can be clea…

That's userland code. In the kernel, write(2) very quickly finds the open file based on the fd and passes the call off to extremely explicit code that handles the write(). Stripping off ambiguity is almost the write syscall handler's only job. It's worth mentioning here that not only is the convenience vs. explicitness tradeoff different in application code than in bare-metal systems programming code, but that that s…

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

Re: Linus vs C++, again

#82

Post by albertzeyer »

Many of the arguments he gave are mostly just based on the fact that there aren't that much powerful tools around which can do what he requests (and what of course is something you want to have).

Like grepping for all usages of some function. Or getting some code snippet in a way that it comes with all necessary context. Or whatever.

Though, with recent development (particularly on clang), these things may become much more easier. Of course, you will not be able to do magic things (like checking at what places what particular virtual function implementation is called exactly) but it will be trivial to check for example all calls on std::string::size etc.

In the same way, you could also implement some small helper tool for sharing code snippets which will add some meta information about the context. So that when you share some code like 'a += "foo";' it will contain the meta information that a is an std::string.

LLVM/clang is anyway also kind of a disprove to his arguments about maintainability. I would say that one reason that working on/with the LLVM/clang code is so much nicer compared to working on/with the GCC code is because it is written in C++.

Re: Linus vs C++, again

#83

Post by bdr »

alnayyir wrote: post #78
chromatic wrote: post #64

Earlier quoted context omitted.

Perl does this, Perl 6 especially.

Sadly x86/arm/mips/sparc/power processors aren't Perl machines and Perl6 thusly can't be used to make a kernel for a Unix derivative.

Yes, I think we all wept when we first learned that.

Re: Linus vs C++, again

#84

Post by numeromancer »

j_baker wrote: post #13
MarkPNeyer wrote: post #5

C as a context free language? Bullshit. How many global variables are there? How many functions with ridiculous names like htons? Edit: I realize that "context free language" was a poor choice of words; i meant it in the sense that linus did - his claim that you can 'look at a piece of code and understand what it does' is laughable in the face of accepted c programming styles.

I'm not really sure you understand what a context-free language[1] is. I suppose global variables can be seen as being context-sensitive, but functions with weird names definitely don't qualify a language as context-sensitive. [1] http://en.wikipedia.org/wiki/Context-free_grammar

The "context-free"dom you reference here is purely syntactic. Linus here is certainly discussing the semantics of the language, since he is discussing reading and understanding the code. For that you need at least a (perhaps mental) syntax tree, of which there may be many for a given program, and which requires semantic context to disambiguate.

Re: Linus vs C++, again

#85

Post by eru »

ramidarigaz wrote: post #81
tptacek wrote: post #42

Earlier quoted context omitted.

That's userland code. In the kernel, write(2) very quickly finds the open file based on the fd and passes the call off to extremely explicit code that handles the write(). Stripping off ambiguity is almost the write syscall handler's only job. It's worth mentioning here that not only is the convenience vs. explicitness tradeoff different in application code than in bare-metal systems programming code, but that that s…

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

It refers to sections of the man pages. They are organized like this:

1. General Commands

2. System Calls

3. Subroutines

4. Special Files

5. File Formats

6. Games

7. Macros and Conventions

8. Maintenence Commands

Re: Linus vs C++, again

#86

Post by gxti »

ramidarigaz wrote: post #81
tptacek wrote: post #42

Earlier quoted context omitted.

That's userland code. In the kernel, write(2) very quickly finds the open file based on the fd and passes the call off to extremely explicit code that handles the write(). Stripping off ambiguity is almost the write syscall handler's only job. It's worth mentioning here that not only is the convenience vs. explicitness tradeoff different in application code than in bare-metal systems programming code, but that that s…

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

It's the "man" section. According to "man man", 2 is the section for system calls. Often you'll have manpages for the same name under different sections, for example sync(1) is a command while sync(2) a system call (which, unsurprisingly, the sync command uses).

Re: Linus vs C++, again

#87

Post by jbarham »

ramidarigaz wrote: post #81
tptacek wrote: post #42

Earlier quoted context omitted.

That's userland code. In the kernel, write(2) very quickly finds the open file based on the fd and passes the call off to extremely explicit code that handles the write(). Stripping off ambiguity is almost the write syscall handler's only job. It's worth mentioning here that not only is the convenience vs. explicitness tradeoff different in application code than in bare-metal systems programming code, but that that s…

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

The Unix manual is divided into sections (http://en.wikipedia.org/wiki/Man_page#Manual_sections). Section 2 is for system calls. Specifying the section number allows you to disambiguate which section of the manual you want to look in if a man page exists in multiple sections (e.g., "man 1 write" vs. "man 2 write").

Re: Linus vs C++, again

#88

Post by bretthoerner »

ramidarigaz wrote: post #81
tptacek wrote: post #42

Earlier quoted context omitted.

That's userland code. In the kernel, write(2) very quickly finds the open file based on the fd and passes the call off to extremely explicit code that handles the write(). Stripping off ambiguity is almost the write syscall handler's only job. It's worth mentioning here that not only is the convenience vs. explicitness tradeoff different in application code than in bare-metal systems programming code, but that that s…

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

It's the man page section number. I believe this dates back to when the man(uals) were actually printed out. You'd go to section 2 to find X to disambiguate from a different Y.

http://www.december.com/unix/ref/mansec.html

Re: Linus vs C++, again

#89

Post by stonemetal »

ramidarigaz wrote: post #81
tptacek wrote: post #42

Earlier quoted context omitted.

That's userland code. In the kernel, write(2) very quickly finds the open file based on the fd and passes the call off to extremely explicit code that handles the write(). Stripping off ambiguity is almost the write syscall handler's only job. It's worth mentioning here that not only is the convenience vs. explicitness tradeoff different in application code than in bare-metal systems programming code, but that that s…

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

It is where it lives in man. man write returns write(1) an application that sends a message to another user. man 2 write returns write(2) the system call mentioned above(or at least it does on Ubuntu).
Post reply on HN