However the practice of cramming as much functionality as possible into one line benefits nobody. It's mostly just showing off programing skills for the sake of feeling superior.
while (*p && *p++ != '\n')
continue;
I would certainly hope that anyone who calls themselves a C programmer would understand a very common idiom such as Bellard's ...Code: [Select]while (*p && *p++ != '\n')
continue;
... at a glance.
What do you need to understand?
- what *p and *p++ do
- that text data is often terminated with a 0 byte
- that '\n' is a newline
- that in C 0 is false and everything else is true
- how a short-circuit operator such as && works
- what continue and break do in loops
C is a very small language and those are all completely fundamental things.
C++ is a completely different matter. I think I understood pretty much all of C++ around 1989 and up to and including C++98. What we've got now though is an absolute horror of complexity and interactions and just Too Many Features.
while (*p != 0 && *p != '\n')
p++;
My reasoning behind this that the while condition is only checking the condition while the body of the loop is what is actually doing the work. So that when i look at it i go "So this loop is incrementing p, repeating it until p is zero or linefeed". But again that's just how my particular brain works. Yes i know the part with "!= 0" is completely unnecessary, but it just looks more sensible to me because I'm looking for the zero character. If i am looping until a unsigned variable x decrements to zero i might use instead "while(x > 0)" even tho again the "> 0" does nothing. But if i have something used as a flag and i don't care about its value i might just go "if(isEmpty)" Its like commenting your code without actually using a comment.while (*p && *p++ != '\n') continue;
If i was to write this code i would have probably done something like this:Code: [Select]while (*p != 0 && *p != '\n') p++;
#include <stdio.h>
int main () {
char s[]= "abc\n";
char* p= s;
char* q= s;
while (*p && *p++ != '\n') continue;
while (*q && *q != '\n') q++;
printf("%u\n", p == q);
}
But yours doesn't do the same thing...
and his monolithic kernel is a very bad idea in the long term.
I believe you have some valid points, although I am not sure that a
microkernel is necessarily better. It might make more sense to allow some
combination of the two. As part of the IPC code I'm writting for Linux I am
going to include code that will allow device drivers and file systems to run
as user processes. These will be significantly slower though, and I believe it
would be a mistake to move everything outside the kernel (TCP/IP will be
internal).
Actually my main problem with OS theorists is that they have never tested
there ideas!
But time has proven he wrong.
But yours doesn't do the same thing...
Sorry. I see i missed the fact that the original code has a special case for line feed characters where it skips over the first occurrence of a line feed.
This is exactly my point in why it is not a good idea to cram as much functionality as possible into a line of code. The special case is embedded among all the other logic and is easy to miss.
while(*p++ != '\n') continue;
In such a case i would add "if(*p == '\n') p++;" on the end of my loop so that its clear to anyone reading this that \n is treated differently and also make it clear in what way it is treated differently. A extra line or two of code is a small price to pay for having your code be clear in its intentions and difficult to interpret the wrong way at a glance. Code is written to be read by humans, not machines (They would prefer it if you just gave them machine code rather than this inefficient ascii stuff)
But it's not a special case! The whole point of this code is to skip to the start of the next line of text, including skipping over the newline.
Hopefully you'd find it clear as:Code: [Select]while(*p++ != '\n') continue;
The "*p &&" is there just to prevent sailing on past the end of the input string as a whole.
It's really, I would say, totally normal and idiomatic C and not in the least bit "tricky".
Ugh. That's just unnecessarily bulking up the amount of stuff to be read. And the amount of machine code generated.
If it was my code I'd be doing it a little differently. I'd make a function "skipToNextLine(char **p), with a comment or two, and maybe marked as "inline" (or maybe leave that up to the compiler).
Macrokernel "were" good only because they minimize the costs of context switches to bundle system calls in batches. This was a must-have for the previous hardware, but times have changed in the last twenty years, and nowadays modern hardware does not need this compromise, and this means it's the end of Linux.
We've seen Torvalds' style. Let's see Fabrice Bellard's:Code: [Select]while (*p && *p++ != '\n')
continue;
Yeah, altough I still find the above typical of bad C style.
I would write the above as, for instance, such:Code: [Select]while (*p != '\0')
{
if (*p++ == '\n')
break;
}
... just putting a comment "\\ Skip pointer to start of next line" in front of the loop is a nice way to do it.
... just putting a comment "\\ Skip pointer to start of next line" in front of the loop is a nice way to do it.That's not a comment
(I have always wondered how some people manage to mix up forward and backward slashes)
But time has proven he wrong.
no, he was not wrong.
Do you know how big is k5.4 on my HPPA2? ____24 MB___
(with all modules static compiled)
and this means it's the end of Linux.
Now try with make allnoconfig ... then add one by one only the things you really need.
Sorry, but I don't see the end of Linux anytime soon
Sorry, but I don't see the end of Linux anytime soonlast 5.* have a lot of code-regressions. This must mean something. Starting from "devs" (like AlanCox, and Miller) are tired, to ... nobody is probably no more willing to go ahead with the increased level of complexity stuffed monolithically into the kernel.
Even Linus.T. stood up and admitted it - "Linux is too bloated" - he said, yes, it is.
One thing that I forgot to mention, but which is critical to the success of Linux, is that there really is no such thing as monolithic "Linux." Linux is highly modular and can be trimmed down/beefed up to fit a wide variety of applications...on the developers' terms, not Red Hat's, Novell's, Canonical's, etc.
So, unlike Windows, which can only be what Microsoft dictates, Linux can truly be all things to all people, as "fat" or as "skinny" as the developer wants it to be. Ubuntu is obese compared to sub-100 KB uClinux distributions, for example. Both serve different, and useful, purposes.
Sorry, but I don't see the end of Linux anytime soon
last 5.* have a lot of code-regressions. This must mean something. Starting from "devs" (like AlanCox, and Miller) are tired, to ... nobody is probably no more willing to go ahead with the increased level of complexity stuffed monolithically into the kernel.
I googled that, and see what I stumbled uponQuoteOne thing that I forgot to mention, but which is critical to the success of Linux, is that there really is no such thing as monolithic "Linux." Linux is highly modular and can be trimmed down/beefed up to fit a wide variety of applications...on the developers' terms, not Red Hat's, Novell's, Canonical's, etc.
So, unlike Windows, which can only be what Microsoft dictates, Linux can truly be all things to all people, as "fat" or as "skinny" as the developer wants it to be. Ubuntu is obese compared to sub-100 KB uClinux distributions, for example. Both serve different, and useful, purposes.
https://www.cnet.com/news/linus-torvalds-linux-is-bloated/
What I don't get is, if you don't like it, why are you trying to shoehorn it into those vintage machines? There are not any microkernel alternatives?
What I don't get is, if you don't like it, why are you trying to shoehorn it into those vintage machines? There are not any microkernel alternatives?
"Microkernel" is a technical term which means that as little as possible code runs with elevated privileges and everything else talks to it and each other via the kernel. It doesn't make the total RAM impact smaller. Probably it makes it bigger.
Sadness is loneliness
The programmer was anticipating
Advent is extraordinary
The rush is uncomparable
Christmas takes joy and kindness
Your spirit is incredible
While joy is as high as kindness
Build your spirit up
Let joy be without kindness
Give back your spirit
AdventOfCode takes time (but it's plenty of fun)
Let fun be Christmas taking time, and Advent without the rush
If fun is as low as sadness
Give back sadness
Give back fun with AdventOfCode taking fun
The elves are thoughtful
Santa is overseeing
The time is now
While the time is right
Listen to the jingles
If the jingles ain't ok
Break it down
Let the jingles be without sadness
Let the elves be with Christmas taking the jingles, and Advent without the rush
Let Santa be with AdventOfCode taking the jingles
Shout the elves
Shout Santa
https://github.com/vstrimaitis/aoc-2019/blob/master/day1/sol_formatted.rockOn subject I feel this thing is worth some flaunting. I can't vouch for it's correctness - I haven't compiled the compiler. But allegedly it solves the first day's problem in this year's Advent of Code
From knowing some programming, it is kind of not completely impossible to interpret the general idea of most of the constructs. I think it serves as a nice reminder of how foreign programming probably is to someone outside the profession/hobby.