For the use case of pointers to particular places in memory, you can force-cast (type in parens before the value) a const int into a pointer to the type and then "dereference" it into a reference variable. Sure this doesn't initialize the object at that address, but if you're statically specifying pointer addresses in your code, those aren't getting implictly initialized either. If you want it initialized before you get a reference to it, make a function that creates the reference, initializes the object, and then returns the reference. Heck, that could be a static method in a singleton class with deleted constructors. Now, references aren't as flexible as pointers when doing fancy type template gymnastics, but if you're manually specifying addresses, you're not putting things in template types anyway! I think this tells us to lean more towards factoring out definite pointers and leaving maybe pointers alone when they must exist.
Then it will be very difficult to learn programming. I assume that you at some point in life did not understand pointers, or perhaps you where born with the knowledge of pointers?
No one should ever work in a gun shop who does not understand how to shoot. Yet that doesn't mean they should fire them in the regular course of their workday. Yes, we who program for a living should understand pointers, and that understanding should be more than enough to convince us to let the compiler handle the nitty-gritty details most of the time.
I assume you're talking about C and C++ here, and I assume you're talking about writing a single line of code *in production*. In that case, I agree. Every professional C and C++ programmer needs a solid understanding of pointers. But even in a team where everyone knows pointers perfectly well, I'd still want as much help as possible from the compiler to catch the inevitable mishaps, and from the type system to make the intentions of the API clearer.
If null is a problem for you, then you're doing programming wrong. For starters, pointers shouldn't be passed as return values, and pointers shouldn't be shared between contexts. Prohibition won't fix incompetence, and every example you give is of bad code. Null isn't the problem here, bad programming practices are.
"If null is a problem for you, you're not doing programming right". If getting bit by snakes is a problem for you, you're not going to the zoo correctly. Is the onus really on the programmer? Pointers are inherently ambiguous, they simultaneously encode the idea that there may or may not be an object, and that you don't have a local copy to do with as you please. Type systems are how we tell the compiler about the things involved in the problem we're trying to solve. If we can't express these two ideas separately, it can't help us avoid simple but extremely costly mistakes. Ideally, the optional type wouldn't even let you extract the value directly, only operate on it in the optional context, as that would eliminate all null errors.
Yes, the onus really is on the programmer. There is nothing ambiguous about pointers if used correctly, the problem is bad coding practices. Of course, this is a talk about C++ which has bad programming practices built in as a feature of the language.
Indeed, Andrew, malloc() is one of the great mistakes of libc. bool allocate(void** pointer, size_t requested) { if (!memory_available(requested)) return 0; /* allocate memory */ (*pointer) = allocated; return 1; } It's not difficult.
I wish coders at Adobe saw this talk :) But seriously, I disagree with most of his assumptions. The bottom line is that noobs should not code in C or even C++. So go learn C# or Java instead. Low level stuff is not for you. PS. And this part 20:08 about references being a safe alternative to pointers, is also bogus. Who stops someone from doing this? Artist* artist = NULL; Album album(*artist);
Everything he says in this talk is basic professional practice, and has been for quite a while now. There are probably quite a few crusty old codebases (and coders) that haven't changed, but you expect that with C++. Of course nothing (except a static checking program) stops you from dereferencing a null pointer: the point is that you (the caller of the function) made the error by dereferencing it. You can functionally have 'null' references, as they are probably just pointers under the hood anyway, but only as a result of some previous operation that is invalid, like your null-dereference. Taking a parameter as a reference is the writer of the function saying 'don't pass me some random invalid pointer here, dumbass, I'm not going to check it'- you can still be a dumbass and call the function with a dereferenced invalid pointer, but it's just really obvious you are being a dumbass.
Couldn't agree more. I'm sick and tired and on a huge deja vu from the java introduction time when i hear again that all the new tools and language features will now make us able to hire highschool students from pakistan for a bowl of rice. There is nothing wrong with pointers and null and i really have never seen any significant study that getting rid of them is helping a lot. Smartpointers are way to expensive for me to use in C++. If i want something like this i would use a garbage collected language.
@sent4dc you seem to have completely missed the point. The null problem is just as much of a problem in C# or Java as it is in C++, or indeed even more so because _every_ object is passed by pointer in these languages. By contrast, C++ references _are_ a safe alternative to pointers. Not in the sense that they don't stop you from writing bugs _elsewhere_ with pointers as you did with that `Artist* artist = nullptr;` example. However, the error is in this case in dereferencing the null pointer which happens _outside_ of the reference-accepting function, i.e. it shifts you from an effect-site error to a cause-site error.
"Who stops someone from doing this?" In an ideal world, the compiler or any analysis tool. However, in practice that is very difficult since most nulls don't come from a direct assignment like this. Also, this is against the standard in dcl.ref paragraph 5. The basic reasoning is a reference to a null object would require dereferencing a null pointer, and this is undefined behaviour. Undefined behaviour should be read as an error that the compiler doesn't assign an explicit required way of handling, since it could end up penalising one platform. But there has been work on operator . in hopes to get a proper smart reference to deal with things like this. Making a re-seatable reference would be really useful.
For the use case of pointers to particular places in memory, you can force-cast (type in parens before the value) a const int into a pointer to the type and then "dereference" it into a reference variable.
Sure this doesn't initialize the object at that address, but if you're statically specifying pointer addresses in your code, those aren't getting implictly initialized either. If you want it initialized before you get a reference to it, make a function that creates the reference, initializes the object, and then returns the reference. Heck, that could be a static method in a singleton class with deleted constructors.
Now, references aren't as flexible as pointers when doing fancy type template gymnastics, but if you're manually specifying addresses, you're not putting things in template types anyway!
I think this tells us to lean more towards factoring out definite pointers and leaving maybe pointers alone when they must exist.
That thing about not having optional references is a little weird, but hey, design by committee is the main reason C++ syntax is so clunky anyway.
Dude my knowledge stopped with C++11, this language is not recognizable anymore and I feel like I should learn it from scratch.
No one should ever write a single line of code who does not understand pointers.
Then it will be very difficult to learn programming. I assume that you at some point in life did not understand pointers, or perhaps you where born with the knowledge of pointers?
@@tordjarv3802 I mean for a living.
No one should ever work in a gun shop who does not understand how to shoot. Yet that doesn't mean they should fire them in the regular course of their workday.
Yes, we who program for a living should understand pointers, and that understanding should be more than enough to convince us to let the compiler handle the nitty-gritty details most of the time.
I assume you're talking about C and C++ here, and I assume you're talking about writing a single line of code *in production*. In that case, I agree. Every professional C and C++ programmer needs a solid understanding of pointers. But even in a team where everyone knows pointers perfectly well, I'd still want as much help as possible from the compiler to catch the inevitable mishaps, and from the type system to make the intentions of the API clearer.
If null is a problem for you, then you're doing programming wrong. For starters, pointers shouldn't be passed as return values, and pointers shouldn't be shared between contexts. Prohibition won't fix incompetence, and every example you give is of bad code. Null isn't the problem here, bad programming practices are.
safe space culture for programmers
"If null is a problem for you, you're not doing programming right". If getting bit by snakes is a problem for you, you're not going to the zoo correctly. Is the onus really on the programmer? Pointers are inherently ambiguous, they simultaneously encode the idea that there may or may not be an object, and that you don't have a local copy to do with as you please. Type systems are how we tell the compiler about the things involved in the problem we're trying to solve. If we can't express these two ideas separately, it can't help us avoid simple but extremely costly mistakes. Ideally, the optional type wouldn't even let you extract the value directly, only operate on it in the optional context, as that would eliminate all null errors.
Yes, the onus really is on the programmer. There is nothing ambiguous about pointers if used correctly, the problem is bad coding practices. Of course, this is a talk about C++ which has bad programming practices built in as a feature of the language.
sorry malloc(), your a bad return value :)
Indeed, Andrew, malloc() is one of the great mistakes of libc.
bool allocate(void** pointer, size_t requested)
{
if (!memory_available(requested)) return 0;
/* allocate memory */
(*pointer) = allocated;
return 1;
}
It's not difficult.
I wish coders at Adobe saw this talk :)
But seriously, I disagree with most of his assumptions. The bottom line is that noobs should not code in C or even C++. So go learn C# or Java instead. Low level stuff is not for you.
PS. And this part 20:08 about references being a safe alternative to pointers, is also bogus. Who stops someone from doing this?
Artist* artist = NULL;
Album album(*artist);
lol the talk says it's a beginner level topic,get off your high horse
Everything he says in this talk is basic professional practice, and has been for quite a while now. There are probably quite a few crusty old codebases (and coders) that haven't changed, but you expect that with C++.
Of course nothing (except a static checking program) stops you from dereferencing a null pointer: the point is that you (the caller of the function) made the error by dereferencing it. You can functionally have 'null' references, as they are probably just pointers under the hood anyway, but only as a result of some previous operation that is invalid, like your null-dereference. Taking a parameter as a reference is the writer of the function saying 'don't pass me some random invalid pointer here, dumbass, I'm not going to check it'- you can still be a dumbass and call the function with a dereferenced invalid pointer, but it's just really obvious you are being a dumbass.
Couldn't agree more. I'm sick and tired and on a huge deja vu from the java introduction time when i hear again that all the new tools and language features will now make us able to hire highschool students from pakistan for a bowl of rice. There is nothing wrong with pointers and null and i really have never seen any significant study that getting rid of them is helping a lot. Smartpointers are way to expensive for me to use in C++. If i want something like this i would use a garbage collected language.
@sent4dc you seem to have completely missed the point. The null problem is just as much of a problem in C# or Java as it is in C++, or indeed even more so because _every_ object is passed by pointer in these languages. By contrast, C++ references _are_ a safe alternative to pointers. Not in the sense that they don't stop you from writing bugs _elsewhere_ with pointers as you did with that `Artist* artist = nullptr;` example. However, the error is in this case in dereferencing the null pointer which happens _outside_ of the reference-accepting function, i.e. it shifts you from an effect-site error to a cause-site error.
"Who stops someone from doing this?" In an ideal world, the compiler or any analysis tool. However, in practice that is very difficult since most nulls don't come from a direct assignment like this.
Also, this is against the standard in dcl.ref paragraph 5. The basic reasoning is a reference to a null object would require dereferencing a null pointer, and this is undefined behaviour. Undefined behaviour should be read as an error that the compiler doesn't assign an explicit required way of handling, since it could end up penalising one platform.
But there has been work on operator . in hopes to get a proper smart reference to deal with things like this. Making a re-seatable reference would be really useful.