What's wrong with the language?
Pages: 12
So, I have been using C++ informally (and a ton of other things, but C++ was my first) since middle school, which was about 15 years ago. It was nice, all these years, anything I coded using the STL I could rely working on anywhere I took it. Unfortunately, STL doesn't really allow you to do much. So, if you want to try making a simple game or something, maybe a platformer or a shmups, just for fun, you have to grab SDL, OpenGL, mix a few, or something to that effect. So, when I first started using OpenGL, I ran into problems, but I solved them. Then, magically, OpenGL2 comes out.
Unfortunately, everything that you could do before is now totally deprecated, or just doesn't work. Well, that's great. You gotta update, so you do, or try to, but you find out that your hardware just might not be compatible with the new standard that you're trying to compile against. Well, that's even better, right? Ok, let's try SDL instead. Yeah, sure, unless you mix it with OpenGL, you're not going to get hardware acceleration. Oh well, at least it's stable, right? Oh no! SDL2.0! What's this? SDL1 code is broken? Ok, let's try java. Maybe I'll use that cool assembly trick that I learned some time ago that'll allow me to link C++ to Java and then I'll have my universal library! Wait, programs compiled for new JREs also occasionally face features being deprecated or removed?
Alright, so how about this? I stick with STL. STL's nice, and I don't really need it if I am coding on a microcontroller, since I'll have full hardware access. That'll be nice. Oh, it's 2015, and apparently C++ itself has been updated twice since I learned it, and no one even told me. The dinosaur itself is starting to face update/deprecation rot. So far, I haven't had any of my code break due to the new C++ changes. I'm sure someone would blast my coding style to pieces, even before the updates, but with the updates it's worse. But, how long until it does? I'm already reading that there were indeed breaking changes, but none of them had affected any of my code.
So, I look into these changes, the ones that are breaking code and the ones that aren't. We have cool things like Lambdas, which I agree can make some things safer, but were they ever really necessary? And then you have things like the "override keyword." C++ allows operator overloading, so if a class derives another class, writes it's own methods for that class and code intended to call the newer class isn't written right, so it calls the older class, it should be the class' fault, or at least responsibility to prevent it? I'm not even sure how the "override" keyword would even pull this off? Does it blanket out all overloaded functions, or what? Already, you only call the parent IFF the child doesn't have what you're looking for (or if you've casted the object). Just to make sure I wasn't loosing my mind, I decided to test this:
Yep, without a keyword, it already works. So, why did we add this? Now, I could also complain about how static variables in a class must be defined outside of the class (seriously, why?), but at least that behavior isn't particularly new. Then we have the enum class: enums worked before, but you had to be careful. Now we have a variation of the same thing (and any layman would easily ask why they chose to do it the way they did, instead of calling it strong_enum or typed_enum, which would've made things way, way more obvious), which isn't really necessary, outside of "now we can magically prevent more errors." And what's this about returning multiple variables from a function? I thought that's what passing by reference was for. When you see these kinds of massive additions to the language, you have to ask "Ok, how does this not only impact legacy code that so many businesses rely on, but also how does this affect documentation and tutorials as a whole?"
Don't get me wrong, it does need to be brought up to date a little, but I thought that's what C# was for. What needs to be updated (and also better standardized) is the STL: some of the STL changes have been very, very important and valuable. STL is the rock library of the language: if you want full C++ compiliance, you need to support the full STL (some archs support C++, but not the STL). Meanwhile, the STL has seen threading function support (something that will break STL for certain archs that might've supported STL before), but basic sound and 2d graphics (something like VBE+ [can specify a target resolution and get a linear frame buffer] alone would go a very, very long way, even accepting that it wouldn't be "hardware accelerated") support hasn't been implemented. Yet when you get a new compiler, sometimes you still have to figure out whether it's "<iostream>" or "<iostream.h>" just to use cout, which is a big deal for some new people, and don't get me started on if you want to use something like printf since it's easier to format the output without learning all of iomanip. Plus, you also have how many tutorials out there playing with things like "gotoxy" which doesn't even exist in the STL (i'd still like to know why we don't have a clear screen or gotoxy standardized, yet, to push pressure on the OSDevs to follow a simple universal standard for such a simple functionality).
So I ask, why is it that C++ can't be our rock? Why is it that the changes we're getting are more theoretical benefits, but fewer practical benefits? You'd think that C++ was a philosophy, rather than a tool, at this point. I'm ranting about C++, but this also applies to other old, but gold, languages. C/C++ is essentially everywhere, and I can go ahead and code on any platform with it, including android. I can sit down with my tablet (thanks to the Termux app), turn on a bluetooth keyboard, and code at a campground, just to get some peace from the rest of the world, or maybe on an airplane or at a restaurant. This is all thanks to the universal standards and consistency that has been afforded to C++ so far so that projects like clang and gcc, along with unix and posix standards, have been able to establish the environment in many places.
So, I ask again, what gives?
Unfortunately, everything that you could do before is now totally deprecated, or just doesn't work. Well, that's great. You gotta update, so you do, or try to, but you find out that your hardware just might not be compatible with the new standard that you're trying to compile against. Well, that's even better, right? Ok, let's try SDL instead. Yeah, sure, unless you mix it with OpenGL, you're not going to get hardware acceleration. Oh well, at least it's stable, right? Oh no! SDL2.0! What's this? SDL1 code is broken? Ok, let's try java. Maybe I'll use that cool assembly trick that I learned some time ago that'll allow me to link C++ to Java and then I'll have my universal library! Wait, programs compiled for new JREs also occasionally face features being deprecated or removed?
Alright, so how about this? I stick with STL. STL's nice, and I don't really need it if I am coding on a microcontroller, since I'll have full hardware access. That'll be nice. Oh, it's 2015, and apparently C++ itself has been updated twice since I learned it, and no one even told me. The dinosaur itself is starting to face update/deprecation rot. So far, I haven't had any of my code break due to the new C++ changes. I'm sure someone would blast my coding style to pieces, even before the updates, but with the updates it's worse. But, how long until it does? I'm already reading that there were indeed breaking changes, but none of them had affected any of my code.
So, I look into these changes, the ones that are breaking code and the ones that aren't. We have cool things like Lambdas, which I agree can make some things safer, but were they ever really necessary? And then you have things like the "override keyword." C++ allows operator overloading, so if a class derives another class, writes it's own methods for that class and code intended to call the newer class isn't written right, so it calls the older class, it should be the class' fault, or at least responsibility to prevent it? I'm not even sure how the "override" keyword would even pull this off? Does it blanket out all overloaded functions, or what? Already, you only call the parent IFF the child doesn't have what you're looking for (or if you've casted the object). Just to make sure I wasn't loosing my mind, I decided to test this:
|
|
Yep, without a keyword, it already works. So, why did we add this? Now, I could also complain about how static variables in a class must be defined outside of the class (seriously, why?), but at least that behavior isn't particularly new. Then we have the enum class: enums worked before, but you had to be careful. Now we have a variation of the same thing (and any layman would easily ask why they chose to do it the way they did, instead of calling it strong_enum or typed_enum, which would've made things way, way more obvious), which isn't really necessary, outside of "now we can magically prevent more errors." And what's this about returning multiple variables from a function? I thought that's what passing by reference was for. When you see these kinds of massive additions to the language, you have to ask "Ok, how does this not only impact legacy code that so many businesses rely on, but also how does this affect documentation and tutorials as a whole?"
Don't get me wrong, it does need to be brought up to date a little, but I thought that's what C# was for. What needs to be updated (and also better standardized) is the STL: some of the STL changes have been very, very important and valuable. STL is the rock library of the language: if you want full C++ compiliance, you need to support the full STL (some archs support C++, but not the STL). Meanwhile, the STL has seen threading function support (something that will break STL for certain archs that might've supported STL before), but basic sound and 2d graphics (something like VBE+ [can specify a target resolution and get a linear frame buffer] alone would go a very, very long way, even accepting that it wouldn't be "hardware accelerated") support hasn't been implemented. Yet when you get a new compiler, sometimes you still have to figure out whether it's "<iostream>" or "<iostream.h>" just to use cout, which is a big deal for some new people, and don't get me started on if you want to use something like printf since it's easier to format the output without learning all of iomanip. Plus, you also have how many tutorials out there playing with things like "gotoxy" which doesn't even exist in the STL (i'd still like to know why we don't have a clear screen or gotoxy standardized, yet, to push pressure on the OSDevs to follow a simple universal standard for such a simple functionality).
So I ask, why is it that C++ can't be our rock? Why is it that the changes we're getting are more theoretical benefits, but fewer practical benefits? You'd think that C++ was a philosophy, rather than a tool, at this point. I'm ranting about C++, but this also applies to other old, but gold, languages. C/C++ is essentially everywhere, and I can go ahead and code on any platform with it, including android. I can sit down with my tablet (thanks to the Termux app), turn on a bluetooth keyboard, and code at a campground, just to get some peace from the rest of the world, or maybe on an airplane or at a restaurant. This is all thanks to the universal standards and consistency that has been afforded to C++ so far so that projects like clang and gcc, along with unix and posix standards, have been able to establish the environment in many places.
So, I ask again, what gives?
I have no idea what's trying to be said in this rambling rant from a completely uninformed and woefully confused person.
Graphics and sound libraries are beyond the scope of the C++ standard library. You're also confusing the C++ standard library with the Standard Template Library, which is part of the C++ standard library.
Then you go on for several paragraphs about how things change and how new software is written. Erm... yep, that always happens. No one is forcing you to use the new software though. Still like OpenGL 1? Use it. Still like SDL 1.2? Use it. Don't like the new C++ features? Don't use them. I don't know what you're complaining about here.
I have to really scratch my head at this. Yes, they solve common problems and increase the expressiveness of the language by a lot.
You're confusing a lot of terms here, operator overloading is not the same as virtual function overloading. The override keyword makes it a compile-time error to attempt to override a virtual function, but to change its name or signature. This is a common error in C++, the override specifier is a good addition to the language.
Also, your example isn't even overriding a function. You've defined a new function in the child type with the same name. Again, you're confusing your terms here.
Yes, we have a strongly typed version of the same thing that doesn't pollute the namespace with all of its symbols. It's a vast, vast improvement over the classless enums. I don't know what you're complaining about here.
C# is a completely different language made by different people and with completely different goals. Despite the similar name and syntax, they're not really comparable.
It's <iostream>, it hasn't been <iostream.h> since the 90's. And C++ is not designed to be easy to learn, even though I don't see how this particular thing is an issue as long as the book you're learning from was written within the past two decades.
Simply because operating systems don't have a consistent way to handle this. Console IO is not even available on some operating systems. And finally, it's outside the scope of the C++ standard library. Use ncurses or something if you want to do that.
It is. You just have completely irrational expectations.
| Unfortunately, STL doesn't really allow you to do much. So, if you want to try making a simple game or something, maybe a platformer or a shmups, just for fun, you have to grab SDL, OpenGL, mix a few, or something to that effect. |
Graphics and sound libraries are beyond the scope of the C++ standard library. You're also confusing the C++ standard library with the Standard Template Library, which is part of the C++ standard library.
Then you go on for several paragraphs about how things change and how new software is written. Erm... yep, that always happens. No one is forcing you to use the new software though. Still like OpenGL 1? Use it. Still like SDL 1.2? Use it. Don't like the new C++ features? Don't use them. I don't know what you're complaining about here.
| We have cool things like Lambdas, which I agree can make some things safer, but were they ever really necessary? |
I have to really scratch my head at this. Yes, they solve common problems and increase the expressiveness of the language by a lot.
| And then you have things like the "override keyword." C++ allows operator overloading, so if a class derives another class, writes it's own methods for that class and code intended to call the newer class isn't written right, so it calls the older class, it should be the class' fault, or at least responsibility to prevent it? I'm not even sure how the "override" keyword would even pull this off? [...] Yep, without a keyword, it already works. So, why did we add this? |
You're confusing a lot of terms here, operator overloading is not the same as virtual function overloading. The override keyword makes it a compile-time error to attempt to override a virtual function, but to change its name or signature. This is a common error in C++, the override specifier is a good addition to the language.
Also, your example isn't even overriding a function. You've defined a new function in the child type with the same name. Again, you're confusing your terms here.
| Then we have the enum class: enums worked before, but you had to be careful. Now we have a variation of the same thing |
Yes, we have a strongly typed version of the same thing that doesn't pollute the namespace with all of its symbols. It's a vast, vast improvement over the classless enums. I don't know what you're complaining about here.
| Don't get me wrong, it does need to be brought up to date a little, but I thought that's what C# was for. |
C# is a completely different language made by different people and with completely different goals. Despite the similar name and syntax, they're not really comparable.
| Yet when you get a new compiler, sometimes you still have to figure out whether it's "<iostream>" or "<iostream.h>" just to use cout, which is a big deal for some new people |
It's <iostream>, it hasn't been <iostream.h> since the 90's. And C++ is not designed to be easy to learn, even though I don't see how this particular thing is an issue as long as the book you're learning from was written within the past two decades.
| i'd still like to know why we don't have a clear screen or gotoxy standardized, yet, to push pressure on the OSDevs to follow a simple universal standard for such a simple functionality |
Simply because operating systems don't have a consistent way to handle this. Console IO is not even available on some operating systems. And finally, it's outside the scope of the C++ standard library. Use ncurses or something if you want to do that.
| So I ask, why is it that C++ can't be our rock? |
It is. You just have completely irrational expectations.
Last edited on
| i'd still like to know why we don't have a clear screen or gotoxy standardized, yet, to push pressure on the OSDevs to follow a simple universal standard for such a simple functionality |
We should add unsupported (or unsupportable) functionality to C++ in the hopes that people writing operating systems will then change their operating systems to match C++?
| Graphics and sound libraries are beyond the scope of the C++ standard library. You're also confusing the C++ standard library with the Standard Template Library, which is part of the C++ standard library. |
My bad on the STL, thing, but there are things in the standard library that are also beyond the scope: like multithreading support. I figure, if we're going to play this game of forcing everyone to conform, why not go all the way? Why tip-toe?
| Then you go on for several paragraphs about how things change and how new software is written. Erm... yep, that always happens. No one is forcing you to use the new software though. Still like OpenGL 1? Use it. Still like SDL 1.2? Use it. Don't like the new C++ features? Don't use them. I don't know what you're complaining about here. |
That's the problem: long term you end up forced. I can't even download SDL1 libs anymore, for example. It's gone, because "deprecated." Someone thinks something is bad, so when you decide you want to continue to use it anyway, they take it from you. I'm not as worried about new things so much as old things ending up broken.
| I have to really scratch my head at this. Yes, they solve common problems and increase the expressiveness of the language by a lot. |
You can literally inline a function instead of using the inline keyword. Wow. Sure, i'll use them, too, if i find a need, but why?
| You're confusing a lot of terms here, operator overloading is not the same as virtual function overloading. The override keyword makes it a compile-time error to attempt to override a virtual function, but to change its name or signature. This is a common error in C++, the override specifier is a good addition to the language. |
So, hand holding addition, in a language not meant for beginners? As for "operator," sorry, i had a tab to a page on "operator precedence," which I was copying for an interpreter i'm building.
| Also, your example isn't even overriding a function. You've defined a new function in the child type with the same name. Again, you're confusing your terms here. |
But it is overriding: I'm not calling the parent version if i have a child object, or has overriding been taught to me completely wrong?
| Yes, we have a strongly typed version of the same thing that doesn't pollute the namespace with all of its symbols. It's a vast, vast improvement over the classless enums. I don't know what you're complaining about here. |
Confusion: increased complexity for little gain. Namespaces, for example, can prevent the clutter, as well as forms like X_Y.
| C# is a completely different language made by different people and with completely different goals. Despite the similar name and syntax, they're not really comparable. |
Could've fooled me, although I understand ISO and Microsoft are very different (although ISO took over C#, too).
| It's <iostream>, it hasn't been <iostream.h> since the 90's. And C++ is not designed to be easy to learn, even though I don't see how this particular thing is an issue as long as the book you're learning from was written within the past two decades. |
Yet when someone asked me a few years ago how to get started in C++, they couldn't compile "hello world," because you can still run into it trying to establish a noob friendly environment (GUI IDE). I've seen people fix the issue by sym-linking, but not everyone does. After trying out 3 different compilers (to be fair, he was trying to use stdio.h, not iostream), the guy gave up.
| Simply because operating systems don't have a consistent way to handle this. Console IO is not even available on some operating systems. And finally, it's outside the scope of the C++ standard library. Use ncurses or something if you want to do that. |
You'd think with abstractions like SDL that someone would've come up with a standard way of doing it. Heck, webassembly's likely to give me what I want in that regard, via javascript. Shame someone who's not familiar with CLI can't get it up and running. But, hey, while we're on the topic of scope and availability, how about that threading support? I've seen more systems with screens than systems with multiple CPUs and/or task management (hello microcontrollers). Sure, servers usually don't have screens, but the current setup requires some funky tricks to even get screens to stay up in the most common OS people will be using and coding for (windows).
| It is. You just have completely irrational expectations. |
Rocks don't change that often.
| We should add unsupported (or unsupportable) functionality to C++ in the hopes that people writing operating systems will then change their operating systems to match C++? |
I would honestly argue for making it a secondarly standard library, as standard library as it is unsupportable already in most platorms that can't support it, anyway. Code for windows or linux, you're probably going to have a screen and a graphics card. If you're coding for arduino, you don't even have threading support, which actually is in the standard library, now. But, no, long term, the idea is to have a basic interface for basic things.
But, I'm a bit more miffed at the idea that things are going away and becomming deprecated. If my code isn't even portable with the future, why am I using C++ for portability? It sure isn't ease of use, as there are things I can do more easily in assembly for pretty much any platform, than trying to fight with C++'s complaints about casting. Overall, it makes more sense to leave C++ the way it is, and maybe add some things to the standard library that's ancient and largely been tackled by 3rd parties to bring up to add much needed functionality (yes, I understand it's not meant to be comprehensive). "So, i hear people in the 90s were wondering why we couldn't just return multiple values from a single function, and they threw a fit when their teacher didn't explain pointers to them, so 20 years later to compete with other languages we're going to make it possible. To hell with things that we didn't already have a soltuion for; let's make updates and break things! [not actual quote]" C++ needs to either update, or it needs to stay the same. Same with C: they've been pretty reliable rocks for a while now, but now they're on an update frenzy, now that ISO has their hands on them. If only ISO had their hands on VBE or the creation of UEFI or something where their input would've been more constructive.
| I can't even download SDL1 libs anymore, for example. It's gone, because "deprecated." |
Did you try looking at the SDl library download pages?
https://www.libsdl.org/download-1.2.php
| Did you try looking at the SDl library download pages? |
I can't remember if it was when i was on Ubuntu or it was here on Fedora, but I remember not having access to the libs or something. I also remember much more clearly that when i looked up some "opengl tutorial" about 5 or 6 years ago that I ran into an issue where i had to choose between windows (which i wasn't using) or glut (or glew, or something to that effect, which was removed from repos before i could ever touch it, eventually after an hour i found the up-to-date one).
The overall big picture is that things become deprecated and if they become so, it usually ends up broken or gone, rather than the one thing you can depend on. I'm afraid of this happening in C++: we already know some code breaks (mostly wizardry so far), but how long until something like iostream or something from C gets removed from the standard library? How long until a caste method or something breaks, because "raw pointer math is bad [actual quote from someone, but someone unimportant to the big scheme of things]" (I know compilers have options like -std=c++17, but what if that becomes deprecated?)?
| I can't remember if it was when i was on Ubuntu or it was here on Fedora, but I remember not having access to the libs or something. |
Perhaps your internet was down that day. They've been right there on the LibSDL webpage for as long as I can remember. Or perhaps you weren't looking on the LibSDL webpage but instead were hoping it was in an easy-to-use Linux distribution repository and when it wasn't, you stopped looking.
I find that when I want to compile code written in a specific langauge, I have to use the right compiler. When I want to compile C_++98 code, I use the right compiler. When I want to compile Objective-C code, I use the right compiler. When I want to compile C++17 code, I use the right compiler.
If you have some C++98 code, and then you get a new compiler that's meant for C++17 code, and that new compiler complains, why did you get that compiler? If you want to compile Objective-C, get the right compiler. If you want to compile C++11 code, get the right compiler. If you want to compiler C++98 code, get the right compiler. Use the right tool for the job.
| which was removed from repos before i could ever touch it, |
Sounds like your real complaint here is that some old software gets removed from easy-to-use Linux distribution repositories as time goes on.
Last edited on
| there are things in the standard library that are also beyond the scope: like multithreading support. |
| I can't even download SDL1 libs anymore, for example. It's gone, because "deprecated." |
https://www.libsdl.org/download-1.2.php
| You can literally inline a function instead of using the inline keyword. Wow. Sure, i'll use them, too, if i find a need, but why? |
| Confusion: increased complexity for little gain. Namespaces, for example, can prevent the clutter, as well as forms like X_Y. |
| Could've fooled me, although I understand ISO and Microsoft are very different (although ISO took over C#, too). |
| But, hey, while we're on the topic of scope and availability, how about that threading support? I've seen more systems with screens than systems with multiple CPUs and/or task management (hello microcontrollers). Sure, servers usually don't have screens, but the current setup requires some funky tricks to even get screens to stay up in the most common OS people will be using and coding for (windows). |
You can have a console without stdout (although it would be unusual) and stdout without a console (common. Simple example: non-console Windows application with stdout redirected to a file)
You can have preemption without parallelism. x86 supported preemption since the mid-90s, even though SMP only appeared a decade later. Threads are useful even if you can't run things truly in parallel, because it lets you do other things while a task is waiting.
| But, I'm a bit more miffed at the idea that things are going away and becomming deprecated. |
The feature I know is in plans to be deprecated at an uncertain time in the future (who knows if it will ever be removed) is std::bind(), because lambdas completely supersede it.
And even with this, with a lot of compilers you can request adherence to a specific version of the standard, past or present. There's no reason to expect a future standard will make your code uncompilable, as long as it adheres to some current standard.
Your fear is completely irrational and out of touch with reality.
I don't really know what to say. I didn't come to this forum to flame people but literally everything you're saying is wrong. And I don't mean "your opinion differs, so you must be wrong" I mean you are horribly confused and completely misinformed on every single one of your points. If you were asking questions I'd be trying to answer them, but you're just complaining about thing you don't understand and there's nowhere else to go with that.
Last edited on
| So, hand holding addition, in a language not meant for beginners? |
"""hand-holding""". Yes, additional compile-time error checking is an absolutely helpful feature of C++. Why wouldn't you want a wrong program to be wrong at compile-time instead of run-time? That's just making it harder for you, by allowing more production bugs to slip through. But sure, you don't have to use the additional features... I'll take as much compile-time safety as possible. (Also, is type-safety also hand-holding, so should we just use void* everywhere, like in C?)
Also, not sure what you're trying to imply by saying it isn't a language "meant" for beginners. I don't agree with the premise, but let's say that's true that C++ isn't meant for beginners. C++ isn't meant for beginners, therefore let's not make additional features that will help both beginners and experienced programmers alike? I don't see the logic there.
Last edited on
arduino has a c++-like language. Its often convenient to even call it c++. But it isnt really. There are a ton of things it does differently and a lot of c++ things it does not support. Its another language, in truth, that was clearly derived from (older, pre c++ 11?) c++.
c# is the mess that came out of java vs microsoft lawsuit way back. M$ wanted to extend and mess with the java language with its windows junk and backwards ways of doing things, and they got into a fight (you can do what you want but you can't call it java anymore was the verdict). The result was a poorly named language (should have been J-fat, or something, c# is misleading twice, unless you read # as a weight/pound sign). It has nothing to do with C or C++, apart from java being a c++ rip-off so the twice derived language still looks a bit c++ish because that's what it once was.
anyone who can't compile hello world has done something very wrong. Never had any trouble with a properly installed compiler, and on windows, even a complex install like cygwin has been made mostly foolproof.
keeping a console open is easy. Start->cmd. Look, an open console. X.exe. Look, my program ran and it left its output up on the screen. The issue is just running x.exe from inside the gui. You can't do that and keep the output, by design. Knowing that, you would, of course, open a console if you wanted the output, or wrap it in a batch file eg: x.exe > output.txt notepad output.txt will toss the program's output to notepad if you are really unwilling to open a console. This is basic computer literacy stuff, though console work is not often taught as deeply as it used to be, computer programmers are expected to know the basics here.
c# is the mess that came out of java vs microsoft lawsuit way back. M$ wanted to extend and mess with the java language with its windows junk and backwards ways of doing things, and they got into a fight (you can do what you want but you can't call it java anymore was the verdict). The result was a poorly named language (should have been J-fat, or something, c# is misleading twice, unless you read # as a weight/pound sign). It has nothing to do with C or C++, apart from java being a c++ rip-off so the twice derived language still looks a bit c++ish because that's what it once was.
anyone who can't compile hello world has done something very wrong. Never had any trouble with a properly installed compiler, and on windows, even a complex install like cygwin has been made mostly foolproof.
keeping a console open is easy. Start->cmd. Look, an open console. X.exe. Look, my program ran and it left its output up on the screen. The issue is just running x.exe from inside the gui. You can't do that and keep the output, by design. Knowing that, you would, of course, open a console if you wanted the output, or wrap it in a batch file eg: x.exe > output.txt notepad output.txt will toss the program's output to notepad if you are really unwilling to open a console. This is basic computer literacy stuff, though console work is not often taught as deeply as it used to be, computer programmers are expected to know the basics here.
closed account (E0p9LyTq)
| keeping a console open is easy. Start->cmd. Look, an open console. |
I don't remember if it was before Windows 10 or not.
Open a drive/folder in File Explorer, type "cmd" in the address bar window, and *boom* A console window set to the location File Explorer has.
AFAIK you can't have that console window run with administrator privileges, though.
| Open a drive/folder in File Explorer, type "cmd" in the address bar window, and *boom* A console window set to the location File Explorer has. |
closed account (E0p9LyTq)
| Can confirm that this works on 8. |
I didn't "do" 8. I jumped from 7 to 10 without the (for me) needless pain of 8/8.1.
Nice to know the idea isn't new to Win 10, though. Thanks. :)
Well, not to derail the thread, but 10 has been nothing but headaches for me for the past six months. I don't know how much of it is 10 shittiness and how much it's hardware weirdness.
8 is comparatively rock-solid. And much snappier, to boot.
8 is comparatively rock-solid. And much snappier, to boot.
I dunno about 10. Honestly on 10 I have a batch file to open a console on my desktop. It works fine. I hate the new "i think im a phone" start menu and have largely ignored and bypassed it. 10 has been stable for me; my biggest complaint is that its ugly and poor quality interface. It works fine. Snappy is hard to rate as I got a hot new PC with it, hard to compare.
Last edited on
| But it is overriding: I'm not calling the parent version if i have a child object, or has overriding been taught to me completely wrong? |
If anything can be salvaged from this trainwreck of a thread, it's to help you clear up some of your misconceptions. There are two similar terms here: operator overloading and virtual function overriding. I won't talk about operator overloading here, but I will go over your overriding example again.
|
|
This is your example in a nutshell and it is not virtual function overriding. What you've done is to define two unrelated functions with the same name, kitten::meow and kitty::meow. In the function call in main it will match the most specific function it can, so kitten::meow in this case.
So what's "real" virtual function overloading? Let's break your example by replacing main and you'll see.
|
|
Which function is called here? There are no virtual functions in either class so all function calls here will be resolved at compile time. The compiler can't make assumptions about the actual type of kit, so it must assume that it's pointing to a kitty, so kitty::meow is called. You've lost all type information in doing this, and failed to override a member function. If this is how you've been overriding member functions, you're doing it wrong. You have bugs lurking in your code. Even if your classes aren't called through pointers or references to the base class, as soon as you start doing that then strange things will start happening. Your child class code won't be running, there will be no compiler warnings, there will be no errors, and it will possibly take you a long time to track that bug down because you've woefully misunderstood how C++ works.
So let's fix this up with some virtual functions.
|
|
Since meow is a virtual function, C++ knows it can't resolve this function call at compile-time. It will take your pointer, look up its run-time type information and look at the vtable (the table of virtual functions) for that type. Now what you intended to happen is to call kitten::meow here, but there's a typo. Instead of overriding the meow function we've accidentally introduced a bug by defining a new function called moew. This is an extremely common source of bugs in C++ because there is no compiler warning for this. A linter might pick it up, but the compiler will happily compile this technically correct but logically broken code. Let's add the override keyword in.
|
|
What happens now? Compiler error. We've added the override keyword which tells the compiler that we're not intending to define a new virtual function, we're intending to override a virtual function from a base class. A compiler error is the best thing that could happen here because this program is incorrect. One of the goals of C++ is to not allow incorrect code to compile, this is a good thing. If you fix that typo then finally kit->meow() will call the correct kitten::meow function.
You seem to think that things like this are training wheels, or "hand-holding" but they're not. Tools to ensure your program is correct is what makes languages like C++ great. If you look at languages like Ruby, Python or Javascript that don't even have strong type systems you will see that a great amount of work goes into making up for this by introducing test-driven development. Most tests in these languages would not be necessary if they had a strict compile-time error that stopped those bugs. C++ has that, this allows you to write higher quality software.
And yes, this feature is not only meant for beginners. Everyone should be using this feature because everyone makes mistakes. Professional programmers who have been using C++ every day for going on 30 years make mistakes. They make typos, they make thinkos, and the best thing that could happen when that occurs is a compiler error. If you think things like this are "hand holding," C is that way and you can abuse the weak type system and lack of compiler errors all day long if that what makes you happy. You may be able to write correct code that way but even if you're confident you got it right you may have lurking bugs. These are not the types of bugs that cause compiler errors or warnings, they're the types of bugs that cause your program to crash months after you deploy it. They're the kinds of bugs that programmers have nightmares about. If the compiler could prevent them then why would you not want that?
gaxio's post is great. I just have a very minor correction to make:
The compiler doesn't need to make any assumptions about the run-time type of *kit. Since kitty doesn't define or inherit any virtual functions, it knows that any calls made through kit can be correctly resolved statically.
There are other cases where calls can also be resolved statically even if virtual functions are involved, although they would be optimizations, so it's not guaranteed compiler behavior. For example:
b.foo() can be resolved statically because B overrides non-virtually A::foo(). There's no chance b.foo() could call any other function. If B::foo() was virtual the compiler may still be able to make the call static, if B has no derived classes and B is not an exported type (otherwise users of the library could derive from B, which would be unknown at the time f() is being compiled).
| The compiler can't make assumptions about the actual type of kit, so it must assume that it's pointing to a kitty, so kitty::meow is called. |
There are other cases where calls can also be resolved statically even if virtual functions are involved, although they would be optimizations, so it's not guaranteed compiler behavior. For example:
|
|
Last edited on
Pages: 12