It is guaranteed that sizeof(char) == 1, so you can skip the sizeof.
I see that it is in C99. But it wasn't when I was learning C in the 1980s.
Since you specifically mentioned strlen, I can tell that you are doing the wrong thing.
Well I don't use C strings at all, except in the infrequent occasions I'm using a C library from Objective-C that uses them.
Aside from this particular example, what is your beef with sizeof? Do you know an alternative for compile-time size calculations?
Sure. Don't use a language that encourages pointer calculations. If you're working in the kernel or hardware drivers maybe. But for applications C is probably the wrong tool.
One of the big ingredients in Apple's turnaround was running their own stores, where they could display their products to their best advantage, control the message given to consumers, and give the best support in the business.
When they had been selling solely through general computer stores, the sales staff had no incentive to put Apple's products in their best light.
Well it was also kind of important for being able to process data that you didn't know the size of until you actually hit the end, especially if you couldn't hold the whole contents in memory at one time, and you needed to be able to do something with it. Think streams
They're typically handled in blocks, regardless of language. And blocks are either fixed size or store their length in a header.
stdin and stdout are character streams but they come about as part of the philosophy of C, rather than C's null terminated strings being a good way to deal with them. And in any case they never actually hit their end, so neither termination nor length are relevant.
I believe none of you actually programmed in C. A string terminated by \0 can be represented by a single pointer and an have any length. You can also easily let the string keep growing (until the allocated memory is finished.)
You're missing something. You can't have a string longer than the amount of memory that is reachable by a pointer. Hence my comment that you wrongly think incorrect.
C was invented by exceptionally bright people.
A VERY long time ago. We've learned a lot about what makes good and bad language features since then. What made for a good language in the 70s, sucks now.
And yes, there is a difference in programming prowess between kernel / library programmers and application programmers.
You don't say. Sounds like this is relatively new to you.
The former must be very concise
That's complete nonsense. Source code size has nothing to do with object size, let alone suitability of a language for different problem domains. C's conciseness was useful in the 1970s and 80s, where memory used for source code whilst editing and compiling was a significant factor. Nowadays 10s or hundreds of K of source code is irrelevant in GB sized PC memories. The conciseness is worthless.
Hey, just because you don't know the language doesn't mean it's necessarily wrong.
And just because you do know it doesn't make it right. Just because a language operates according to it's documentation isn't any evidence that it wasn't a bad feature idea.
It's often paired with malloc to allocate memory for something.
So to allocate a string you have to multiply sizeof with strlen and add 1 for the null terminator? This kind of nonsense should have been obsolete decades ago.
For the first year they are all using the same design, so they're just going to learn the lessons from that. Innovation will come in subsequent years.
As to F1, it's easy to think theres nothing happening because of all the restrictions. But restrictions are exactly what fosters innovation. Blue sky ideas come along infrequently, but getting with less is the way progress is made day to day, and is exactly what EVs need.
I agree innovation has slowed in F1, but that's the point I already made, it has already advanced so much, the cars had got so good, that the excitement was lessened for the viewing public. EVs provide fresh problems to solve, and so is more likely to be interesting like F1 used to be, not like it is now.
I actually don't disagree with the balanced view you've written. In part, as is my inclination, I'm being the devil's advocate and contrarian.
Time complexity was my premier example of something you may miss out on if you don't do a CS degree. And I also pointed out that you only needed to know the details of sorting when you are implementing rather than using APIs. So we agree on a lot.
It sounds like a you're doing a reasonable amount of actual computer science along with your programming, and of course the degree helped setting the fundamentals for that.
But the vast majority of programmers, with or without degrees aren't doing that. They are writing applications that use libraries for most of the difficult stuff. And that's true right across pay scales. That most certainly doesn't mean they are not learning on the job as they go. They just are learning stuff at a higher abstraction than you.
I'm one of those people who know that in youth people invariably have a false confidence in their ability. When they get older they begin to realise how much they didn't know back then. That's one of the key elements of wisdom. But it's no point telling younger people that. They have to experience it for themselves.
There's going to be a lot more room for innovation in a new formula than in one that's been on-going for decades. And EVs need innovation much more than ICE does now, so it's good to have.
How do you know which of a variety of algorithms to choose, or even that there's a useful question you could go ask the Internet, if you aren't even aware of the possibilities that are out there?
Because even non-degree programmers aren't stupid, and this kind of general knowledge about their profession is acquired as they go.
Sure, I could go read a bunch of papers every time I needed to choose which tool to choose, but if I had to do that then someone who actually knew their data structures and algorithms would be getting useful stuff done while I was reading.
The number of times you are dealing with stuff that was learned in a CS degree is minimal. Again for most programmers this kind of fundamental stuff is implemented in APIs that they use. Every programmer has a bunch of stuff that they already know and a bunch of stuff that is new to them and they need to research before doing a task. The proportion is mostly dictated by amount of experience, not whether they have CS degrees or not.
What you just said is much sillier. Optimise logical operations in code using De Morgans laws? Ha ha! This is what Knuth means by premature optimisation being the root of all evil. It's extremely unlikely to make any difference as the compiler will optimise it in te best way anyway. And if you do need to optimise for speed you'll be doing so with a profiler, not De Morgan's laws.
Don't complicate code and excuse it by commenting.
What did you not understand about "a few things" and "such as"? Though much of what you list is either learned as you go, or is entirely unnecessary, depending on your particular niche.
As to "software engineer", some jurisdictions may require a qualification to call yourself "engineer". The piece of paper justification for a degree counts here. Other than that the term is interchangable with programmer. "Software Engineer" is just chosen as something to go on a business card by people who think it sounds better than programmer. Often with the word "senior" in front of it, even when they have no supervisory responsibilities. It's usually good for demanding a better salary too.
Say what you will, but the middle class needs work. We need something for the vast majority of people who aren't scientists, engineers or politicians to do. That used to be traditional assembly-line manufacturing.
That's working class, not middle class. The managers will qualify as middle class, but not workers on an assembly line.
In any case, it's not "a gigafactory" it's "The Gigafactory". It's a proper name. Tesla can call it what they like, just as you can call any children you have exactly what you want.
Look! De Morgan's Theorem just let me reduce those 5 lines of code to 2.
So what? The 5 lines probably represent the set of logical questions that makes sense to a human. Once it's been manipulated by De Morgan's laws, the connection to the problem is lost. (If it was maintained, you wouldn't have needed De Morgan to optimise them.) You have fewer logic operations, but less legible code.
De Morgan was useful when computers were underpowered. And even more useful for hardware engineers. But they are useless to the mainstream software engineer. I haven't had any call for them in probably 25 years.
Same goes for most things they used to (and maybe still do) teach in CS. As another example, understanding half a dozen sort algorithms is pointless. If you're writing your own sort function, you're doing it wrong. Just call the one in the API. In the extremely rare case of someone having to implement sort from first principles - the internet will get you the best algorithm for your use case in no time.
There's a few things from CS that programmers would be better for knowing, such as time complexity of algorithms. But there's not enough of them to make the time and money to do a CS degree worth it.
"In your head" means that you'll be sharing passwords between multiple services, as you can't possibly remember a unique password for every service. And this in itself is a big threat. Once hackers discover one password from one hacked site they will have access to other sites that use the same credentials.
The answer to the nightmare situation of losing the password database is a paper copy somewhere safe, like at home. Whilst it's vulnerable to burglars, they are usually more interested in stealing objects than passwords, and depending on where you put the paper are unlikely to find it anyway. It's vulnerable to police searches, but that's not an issue for most people.
The risks of passwords on paper are less than the risks of reusing passwords on multiple services.
Slashdot Mirror
It is guaranteed that sizeof(char) == 1, so you can skip the sizeof.
I see that it is in C99. But it wasn't when I was learning C in the 1980s.
Since you specifically mentioned strlen, I can tell that you are doing the wrong thing.
Well I don't use C strings at all, except in the infrequent occasions I'm using a C library from Objective-C that uses them.
Aside from this particular example, what is your beef with sizeof? Do you know an alternative for compile-time size calculations?
Sure. Don't use a language that encourages pointer calculations. If you're working in the kernel or hardware drivers maybe. But for applications C is probably the wrong tool.
One of the big ingredients in Apple's turnaround was running their own stores, where they could display their products to their best advantage, control the message given to consumers, and give the best support in the business.
When they had been selling solely through general computer stores, the sales staff had no incentive to put Apple's products in their best light.
Well it was also kind of important for being able to process data that you didn't know the size of until you actually hit the end, especially if you couldn't hold the whole contents in memory at one time, and you needed to be able to do something with it. Think streams
They're typically handled in blocks, regardless of language. And blocks are either fixed size or store their length in a header.
stdin and stdout are character streams but they come about as part of the philosophy of C, rather than C's null terminated strings being a good way to deal with them. And in any case they never actually hit their end, so neither termination nor length are relevant.
I believe none of you actually programmed in C. A string terminated by \0 can be represented by a single pointer and an have any length. You can also easily let the string keep growing (until the allocated memory is finished.)
You're missing something. You can't have a string longer than the amount of memory that is reachable by a pointer. Hence my comment that you wrongly think incorrect.
C was invented by exceptionally bright people.
A VERY long time ago. We've learned a lot about what makes good and bad language features since then. What made for a good language in the 70s, sucks now.
And yes, there is a difference in programming prowess between kernel / library programmers and application programmers.
You don't say. Sounds like this is relatively new to you.
The former must be very concise
That's complete nonsense. Source code size has nothing to do with object size, let alone suitability of a language for different problem domains. C's conciseness was useful in the 1970s and 80s, where memory used for source code whilst editing and compiling was a significant factor. Nowadays 10s or hundreds of K of source code is irrelevant in GB sized PC memories. The conciseness is worthless.
If C were a weapon it'd be a wooden club.
Zero termination is simpler, and more flexible.
And far slower, more buggy and more insecure.
Also, it avoids having to choose the appropriate number of bytes for the size field.
Pointer sized means that you couldn't handle a longer zero terminated string in memory anyway.
Besides, if you want strings with size field, it's simple enough to implement that yourself.
Heck implement all the rest of a language too and you won't have to put up with C at all.
Hey, just because you don't know the language doesn't mean it's necessarily wrong.
And just because you do know it doesn't make it right. Just because a language operates according to it's documentation isn't any evidence that it wasn't a bad feature idea.
It's often paired with malloc to allocate memory for something.
So to allocate a string you have to multiply sizeof with strlen and add 1 for the null terminator? This kind of nonsense should have been obsolete decades ago.
Interesting. It's a shame C wasn't abandoned at the same time as punch cards.
For the first year they are all using the same design, so they're just going to learn the lessons from that. Innovation will come in subsequent years.
As to F1, it's easy to think theres nothing happening because of all the restrictions. But restrictions are exactly what fosters innovation. Blue sky ideas come along infrequently, but getting with less is the way progress is made day to day, and is exactly what EVs need.
Compare an F1 car of today with an F1 car of the 1950s, 70s or even 90s. EVERYTHING has changed. http://formula1.ferrari.com/wp...
I agree innovation has slowed in F1, but that's the point I already made, it has already advanced so much, the cars had got so good, that the excitement was lessened for the viewing public. EVs provide fresh problems to solve, and so is more likely to be interesting like F1 used to be, not like it is now.
I actually don't disagree with the balanced view you've written. In part, as is my inclination, I'm being the devil's advocate and contrarian.
Time complexity was my premier example of something you may miss out on if you don't do a CS degree. And I also pointed out that you only needed to know the details of sorting when you are implementing rather than using APIs. So we agree on a lot.
It sounds like a you're doing a reasonable amount of actual computer science along with your programming, and of course the degree helped setting the fundamentals for that.
But the vast majority of programmers, with or without degrees aren't doing that. They are writing applications that use libraries for most of the difficult stuff. And that's true right across pay scales. That most certainly doesn't mean they are not learning on the job as they go. They just are learning stuff at a higher abstraction than you.
I'm one of those people who know that in youth people invariably have a false confidence in their ability. When they get older they begin to realise how much they didn't know back then. That's one of the key elements of wisdom. But it's no point telling younger people that. They have to experience it for themselves.
There's going to be a lot more room for innovation in a new formula than in one that's been on-going for decades. And EVs need innovation much more than ICE does now, so it's good to have.
Thanks for the attempt at mentoring. You obviously are much more qualified than me to distinguish what makes a
You're welcome. And yes, unless you've had more than 3 decades of being a programmer and/or senior software engineer, I am more qualified, yes.
How do you know which of a variety of algorithms to choose, or even that there's a useful question you could go ask the Internet, if you aren't even aware of the possibilities that are out there?
Because even non-degree programmers aren't stupid, and this kind of general knowledge about their profession is acquired as they go.
Sure, I could go read a bunch of papers every time I needed to choose which tool to choose, but if I had to do that then someone who actually knew their data structures and algorithms would be getting useful stuff done while I was reading.
The number of times you are dealing with stuff that was learned in a CS degree is minimal. Again for most programmers this kind of fundamental stuff is implemented in APIs that they use. Every programmer has a bunch of stuff that they already know and a bunch of stuff that is new to them and they need to research before doing a task. The proportion is mostly dictated by amount of experience, not whether they have CS degrees or not.
Are you saying it's not actually a factory, but something completely different called a "Gigafactory"?
Someone called Cooper doesn't necessarily make barrels. A Mini-Cooper isn't a small barrel maker.
It's a factory called "The Gigafactory". And Giga isn't a prefix in that sense as its a proper noun, not a type of factory.
What you just said is much sillier. Optimise logical operations in code using De Morgans laws? Ha ha! This is what Knuth means by premature optimisation being the root of all evil. It's extremely unlikely to make any difference as the compiler will optimise it in te best way anyway. And if you do need to optimise for speed you'll be doing so with a profiler, not De Morgan's laws.
Don't complicate code and excuse it by commenting.
What did you not understand about "a few things" and "such as"? Though much of what you list is either learned as you go, or is entirely unnecessary, depending on your particular niche.
As to "software engineer", some jurisdictions may require a qualification to call yourself "engineer". The piece of paper justification for a degree counts here. Other than that the term is interchangable with programmer. "Software Engineer" is just chosen as something to go on a business card by people who think it sounds better than programmer. Often with the word "senior" in front of it, even when they have no supervisory responsibilities. It's usually good for demanding a better salary too.
Be concerned for your own understanding of English.
No less and no more than in the proper noun "Gigafactory".
Say what you will, but the middle class needs work. We need something for the vast majority of people who aren't scientists, engineers or politicians to do. That used to be traditional assembly-line manufacturing.
That's working class, not middle class. The managers will qualify as middle class, but not workers on an assembly line.
Looking at the dictionary it means exactly what I thought it did.
But given your limited idea of what it means, who says it fits "gigafactory". Hmm?
"Gigas" and "gigantism". Two words with the giga prefix that don't meet your set, specific meaning. Your rule is broken.
We should certainly NOT stop making up words. We don't want a dead language thank you very much. Here, watch this:
http://www.ted.com/talks/erin_...
In any case, it's not "a gigafactory" it's "The Gigafactory". It's a proper name. Tesla can call it what they like, just as you can call any children you have exactly what you want.
Look! De Morgan's Theorem just let me reduce those 5 lines of code to 2.
So what? The 5 lines probably represent the set of logical questions that makes sense to a human. Once it's been manipulated by De Morgan's laws, the connection to the problem is lost. (If it was maintained, you wouldn't have needed De Morgan to optimise them.) You have fewer logic operations, but less legible code.
De Morgan was useful when computers were underpowered. And even more useful for hardware engineers. But they are useless to the mainstream software engineer. I haven't had any call for them in probably 25 years.
Same goes for most things they used to (and maybe still do) teach in CS. As another example, understanding half a dozen sort algorithms is pointless. If you're writing your own sort function, you're doing it wrong. Just call the one in the API. In the extremely rare case of someone having to implement sort from first principles - the internet will get you the best algorithm for your use case in no time.
There's a few things from CS that programmers would be better for knowing, such as time complexity of algorithms. But there's not enough of them to make the time and money to do a CS degree worth it.
"In your head" means that you'll be sharing passwords between multiple services, as you can't possibly remember a unique password for every service. And this in itself is a big threat. Once hackers discover one password from one hacked site they will have access to other sites that use the same credentials.
The answer to the nightmare situation of losing the password database is a paper copy somewhere safe, like at home. Whilst it's vulnerable to burglars, they are usually more interested in stealing objects than passwords, and depending on where you put the paper are unlikely to find it anyway. It's vulnerable to police searches, but that's not an issue for most people.
The risks of passwords on paper are less than the risks of reusing passwords on multiple services.