In the book example that I posted, the variable ‘previous’ is actually initialized to " ", as below:
// Counts repeated words
int main()
{
int number_of_words = 0;
string previous = " ";
string current;
while(cin>>current)
{
++number_of_words;
if(previous == current)
cout << "Word number " << number_of_words
<< " repeated: " << current << '\n';
previous = current;
}
}
There is an explanation for why it is initialized to " ", that >> ignores whitespace. But in my testing, it didn’t matter either way to initialize it with a " " or not.
On the first run, ‘previous’ should have no value (I should test this). So it won’t matter either way.
When I went through the beginner C book that I used, I ended up in many dozens of little rabbit wholes like this, figuring out how things might really work. It’s probably a distraction from getting on with it, but I wanted clarity on what is what.
I think they are if we want to understand things. Problem is that it ends of being so many of them and eats a ton of time. I remember reading in some programming books (pretty much every one I have looked at) that the biggest challenge for beginners is thinking like a computer in explicit steps, very literally. And I was thinking back as I read, that is the biggest challenge of reading this book, not being explicit in explanations of what is going on.
This has been my same biggest issue in electronics. I tend to think very literally when learning things, but authors tend to want to pass off things in vague ways. And down the rabbit holes I end up, sometimes getting too tired to carry on.
When I work on projects with my brother, this is the same issue we clash on. He thinks in blobs (and is very good at it), and I think in explicit steps. He gets an idea in his head and thinks that I must see it too from a vague explanation (I don’t). And when I have an idea and explain it, he says that I’m being way too precise like a robot. Ha ha.
Software stuff is much better than reality in that respect because there’s a finite and understandable path back to a known beginning and you need to be precise! Au revoir for now!
It has always been my one big regret about my IT career that I didn’t get more involved with software. I was always more of hardware/admin type and while that was rewarding, the real money turned out to be in software.
Good luck with it. I’m hoping that when I get to that point it isn’t a massive undertaking to get up to speed. But I figure it will be a long minute before I have to deal with that.
There’s still a lot of new stuff to learn with big updates like C++11 or C++20, sometimes I think it’s just too big and that something like Zig would be better to use long term.
Re taking their time, the C++ committee needs to stop meeting in meat space with the time constraints involved in that. If it was up to me I’d make Herb Sutter the benevolent dictator for a few years since every idea he has is a winner. They (not he) are looking at incorporating things like graphics, networking and audio into the standard too which is a waste of time. How about just committing to one cross platform package management standard once, so all of that library faff can fall into place and they can focus on the language?
I’m not so sure about that. Portability of graphics, networking, audio, etc. could be a great thing, even if it is minimal but complete enough to be really useful for building higher level things. I would like to see something like that for C actually. If it existed I probably wouldn’t be going back to C++.
When I think of languages that have a package manager, I think of Python. The amount and quality of stuff available is dizzying (as with linux distros), which is both good and bad. Tons of functionality to tinker with (and probably get lost in) but it seems to me that the focus gets shifted away from programming to sifting through tons of tools and gadgets, which also might break when development stops down the line (which I have seen happen).
It is the same sort of situation as with audio plugins. Focusing on using a handful of versatile high quality core plugins is going to be much more productive than having access to everything under the sun.
That problem can be sorted out with a simple official blessing of particular libraries: “We recommend BlahLib for starting with 2D graphics”. That has the flexibility of being able to take a hard detour when the landscape changes too.
Actually when I say package manager I mean tightly integrated build system and package manager spec for people to follow instead of the current wild west situation. The committee won’t commit to something as simple as a recommendation so are they committing to creating stuff from scratch because design by committee has a problem with upsetting pet projects?
I guess whether a programming language should have a graphics library (etc. library) is a matter of context. What are the motivations behind it? And are those motivations valid to the goals of developing the language? I’m sure that lots of inexperienced programmers, people who aren’t programmers who find themselves programming, and people who typically program outside of graphics context’s but would like to work with graphics (or other context’s / libraries) would benefit from it, as well as people who find themselves involved in education of programming, while some experienced programmers would of course find it less useful. And lots of people could benefit from a truly cross-platform well-maintained library of any type rather than depending on a third party library whose future is unknown. How much more popular would C be today among people who aren’t systems programmers if it had some fundamentals for graphics and audio? And how much less popular would many other languages be if C had those things and the others didn’t?
This reminds me a bit of the argument of Reaper getting some video editing functionality before that happened. Reaper could already play video and display images (and screen capture with licecap) and was developed from influence of Vegas. And lots of people were starting to make Reaper videos while going through the pain in the ass of using various free tools of the time to stitch together something of a kludgy workflow for making Reaper videos. But when requests came up about Reaper getting some fundamental video editing capabilities many people on the forum said that video editing was a waste of development time and that anyone making Reaper videos should go pay for screen capture software and a video editor. After fundamental video editing and the video processor arrived, it only made Reaper a better tool for the Reaper community to share things with each other and development of other aspects of Reaper carried on just the same. And tons of people are making Reaper videos these days. Of course, anyone can still go find third party software for doing the same, and that front has improved immensely since, but it is just so nice having that stuff builtin to Reaper when you need it.
I guess a relevant comment here for why not (audio library in this case):
By the way, for some reason it struck me last night that control flow and conditional statements have function notation. Is there anything of significance behind that or just coincidence?
It’s very different because in that analogy I am suggesting that there should be a checkbox in the installer that fully integrates much better video editing functionality than is in the program. The simplicity of that checkbox can’t exist without an official endorsement and a simple thing to put checkbox in (package manager) which is the problem.
Package manager + build system integration + official endorsement (plus financial support or the natural support of other devs contributing because it is The One) is the way forward. In case you don’t know, we just type:
xmake
This downloads any packages, builds them, builds the programs/libs in the build system and links everything together. No installing deps, no nothing. Everything installed in an .xmake dir separate from system libs to avoid system pollution too.
Where would C be for gfx/audio if it had had that from the beginning?* The tutorials from yesteryear could have had stuff about the current official recommendation, which would hopefully not be the same as today’s official recommendation because paradigms do thankfully shift. Vs how much inertia integrating one from ancient times would have from several angles?
I’ve never heard any explanation for the reasoning behind the syntax, there’s no practical info that springs to mind about it.
* think of all the effort wasted (for brand n00bs at least) on learning compiler/linker command line args’placement and IDE compiler/settings, makefile syntax, configure files, apt/pacman/dpkg/rpm/vcpkg etc required to install and link up things without a unified tool