To explicitly set the delimiting input character: ` std::getline(std::cin, line, ' ') ` I always like to start with the verbose form of a thing so I know what it is doing and can do, and to leverage the learning primacy effect; and only after that I will look I into the abridged forms and shortcuts. The first way you learn a thing tends to persist and be difficult to overcome even if it was wrong and corrected later.
You know whats gets to me even to this day? I/O feels like night and day depending on specifically the language type. For Dynamic Languages, you get alot of sugar to control the standard in and out, fairly easily. I mean, your Python script can interact with your shell, so that isn’t too surprising. However, for Static Languages, you kind of get the minimum but it is standardized the standard libraries. I remember getting to C++ and having to use >> and std :: and I was sold on running the other direction. 😂 That said, now I am older. I see why C/C++ go this route. Since they are the lingua franca, it only makes sense for IO in the STD library to be implementation agnostic. One thing I kind of miss about scripting languages is you can just ‘print’ and it would just work. Or ‘read’ or ‘get’ or anything like that. Sure, you trade off the speed of compilation, but in iteration development, you can go fast in a Juypter notebook. Anyway, all that aside, never neglect that standard library! If I wasn’t able to read D, Swift or Crystals library, I dont think I would get past making my own reinvented wheel just to read and print. And C++, for all of the ‘kitchen sink’ it throws at you, I am sure that I/O library is very helpful is all systems donains. Namely drivers. edit: never forget that c header iostream! 😂Another thing thats gets me. Yeah, I miss D and Swift already 😂.
In some ways when learning programming, I think learning I/O in C first may actually be a big win. All languages seem to abstract on the C library. Understanding buffered/unbuffered I/O is somewhat clearer in C, and then folks can use and read other APIs in languages/libraries that may offer more convenience or otherwise speedup iteration time :)
Hey mike! I am a self learning developer who is really interested in also learning with your OpenGL tutorials as well. I hope you don't mind my asking as to what would be a good stopping point on this C++ series to have everything I need to start with OpenGL and other API's. Thank you so much for your time, your videos have been an absolute treat to watch.
Basically if you're comfortable with functions, std::vector, references, lvalue, rvalue, stack memory, heap memory, static memory, and pointers that's probably enough. I try to program OpenGL in a trivial way so we can focus on the API. You can look at my course outline here which has all the C++ prerequisites (and a bit more) that I'd typically want someone to have prior to diving into OpenGL courses.mshah.io/courses/quick-start-introduction-to-modern-c-image-loader
Not sure yet -- long term support for C, C++, and Dlang series will continue (as well as other series in game and graphics development). Rust is certainly a candidate language to go in-depth. The one constraint before I add another language series however, is that I have to use it for a project first to get a little experience 🙂
@@MikeShah I'm really starting to rethink Rust, only reason being there is no standard library. Everything is handled by Cargo, which is literally npm. It leads to tons of micro-dependencies. Great systems language, horrible decision to use a package manager rather than a std lib
I see the rust has a crate for std, interesting. That is one risk of package managers introducing lots of dependencies -- those dependency chains never shrink. I'm assuming the std crate is otherwise carefully managed though? @@Onyx-it8gk
To explicitly set the delimiting input character: ` std::getline(std::cin, line, '
') `
I always like to start with the verbose form of a thing so I know what it is doing and can do, and to leverage the learning primacy effect; and only after that I will look I into the abridged forms and shortcuts. The first way you learn a thing tends to persist and be difficult to overcome even if it was wrong and corrected later.
You know whats gets to me even to this day?
I/O feels like night and day depending on specifically the language type.
For Dynamic Languages, you get alot of sugar to control the standard in and out, fairly easily. I mean, your Python script can interact with your shell, so that isn’t too surprising.
However, for Static Languages, you kind of get the minimum but it is standardized the standard libraries. I remember getting to C++ and having to use >> and std :: and I was sold on running the other direction. 😂
That said, now I am older. I see why C/C++ go this route. Since they are the lingua franca, it only makes sense for IO in the STD library to be implementation agnostic. One thing I kind of miss about scripting languages is you can just ‘print’ and it would just work.
Or ‘read’ or ‘get’ or anything like that. Sure, you trade off the speed of compilation, but in iteration development, you can go fast in a Juypter notebook. Anyway, all that aside, never neglect that standard library! If I wasn’t able to read D, Swift or Crystals library, I dont think I would get past making my own reinvented wheel just to read and print.
And C++, for all of the ‘kitchen sink’ it throws at you, I am sure that I/O library is very helpful is all systems donains. Namely drivers.
edit: never forget that c header iostream! 😂Another thing thats gets me. Yeah, I miss D and Swift already 😂.
In some ways when learning programming, I think learning I/O in C first may actually be a big win. All languages seem to abstract on the C library. Understanding buffered/unbuffered I/O is somewhat clearer in C, and then folks can use and read other APIs in languages/libraries that may offer more convenience or otherwise speedup iteration time :)
Hey mike! I am a self learning developer who is really interested in also learning with your OpenGL tutorials as well. I hope you don't mind my asking as to what would be a good stopping point on this C++ series to have everything I need to start with OpenGL and other API's. Thank you so much for your time, your videos have been an absolute treat to watch.
Basically if you're comfortable with functions, std::vector, references, lvalue, rvalue, stack memory, heap memory, static memory, and pointers that's probably enough. I try to program OpenGL in a trivial way so we can focus on the API. You can look at my course outline here which has all the C++ prerequisites (and a bit more) that I'd typically want someone to have prior to diving into OpenGL courses.mshah.io/courses/quick-start-introduction-to-modern-c-image-loader
when will we continue with wxwidget projects :) how to print a report in pdf using wxwidgets?
Any plans for going in-depth with Rust or "making the switch"?
Not sure yet -- long term support for C, C++, and Dlang series will continue (as well as other series in game and graphics development). Rust is certainly a candidate language to go in-depth. The one constraint before I add another language series however, is that I have to use it for a project first to get a little experience 🙂
@@MikeShah I'm really starting to rethink Rust, only reason being there is no standard library. Everything is handled by Cargo, which is literally npm. It leads to tons of micro-dependencies. Great systems language, horrible decision to use a package manager rather than a std lib
I see the rust has a crate for std, interesting. That is one risk of package managers introducing lots of dependencies -- those dependency chains never shrink. I'm assuming the std crate is otherwise carefully managed though? @@Onyx-it8gk