Why my friend had to retake his C++ course with a different professor
-
I'm pretty sure C# will run on anything with a working C# compiler.
Except you don't have much of those, mr Obvious
-
I'm pretty sure C# will run on anything with a working C# compiler.
betcha twenty thousand dollars that i can get C# code to run on a machine that lacks a C# compiler
-
I'm pretty sure C# will run on anything with a working C# compiler.
Assuming Mono is a working compiler, no it won't.
-
So Unity doesn't exist? The Sims post-1.0 doesn't exist? The Netduino doesn't exist? SteamPlay doesn't exist? Xamarin doesn't exist?
Man, that's a strange timepod you're crawling out of.
-
Alright, alright. C# will run on anything for which there is a working C# compiler.
Better now?
-
So Unity doesn't exist?
Last time I checked, it had pretty limited subset of C#. In particular, all the fun parts from .NET 3.5 and 4.0 were omitted. Maybe it had changed since. Dunno.The Sims post-1.0 doesn't exist? The Netduino doesn't exist? SteamPlay doesn't exist? Xamarin doesn't exist?
To me, they don't.Man, that's a strange timepod you're crawling out of.
No timepod, but a joke. Enjoy your
!
-
You pretty much proved my point. You can't get your C# app and just tell your compiler "build this for ARMv7 and then later for x86". You need a dedicated dev platform for each os/machine combination, and good luck trying to get your Sims post-1.0 code to work on a microcontroller. When in C++ you usually change build flags and done. Unless you're using something specific, ofc. Hell, I can even write firmware for my toothbrush in C++.
Nonetheless, I hope C# will become more generic and portable. I would love it to finally kill the abomination which is Java. As for systems languages like C++ - they will never die, because you just can't replace them with higher-level languages.
-
None of those things need special build flags, dev platforms, anything like that. They all run plain old bog standard .NET 2.0 MSIL, regardless of the underlying processor or OS. They offer different standard libraries for interacting with the outside world, but they all have the same underlying core -- and WinForms works on all of them save Netduino.
(And yes, I can put my Sims 3 mod on a Raspberry Pi and, with the rest of the Sims mocked up around it, run its code juuust fine, no rebuild required.)
-
They offer different standard libraries for interacting with the outside world
That's one of my points.
with the rest of the Sims mocked up around it
That's another of my points. You can't have your C# without some runtime, which uses the native runtime of the OS. That's one added layer. Using this logic all languages are totally portable - you just need to slap enough layers on it.
-
No and no. In terms of runtime - it's not. You mean efficient in terms of productivity; not the same thing. In the end it's a trade-off - write faster or have faster code.
Only one of those things matters.
Moore's Law takes care of the other.
In terms of portability - if you don't use any platform specific features, your C++ code will run on anything with a working C++ compiler. C# - nope.
Right; you have to swap the words "working C++ compiler" with "working CLR and C# compiler". Totally different.
-
You pretty much proved my point. You can't get your C# app and just tell your compiler "build this for ARMv7 and then later for x86".
Sure you can. What's stopping you?
-
Only one of those things matters.
Glad you're not making any middleware or system libraries, then.
Right; you have to swap the words "working C++ compiler" with "working CLR and C# compiler". Totally different.
And a working universal generic runtime, which is non-existent at the moment.Sure you can. What's stopping you?
The above (and I mean in a generic way, not only arm/x86 combo).
-
And a working universal generic runtime, which is non-existent at the moment.
By that standard, no programming language could ever be cross platform, because there's no such thing as a "universal generic runtime" (there sure as fuck ain't for C++) nor do I see there ever being the possibility of one existing.
-
Actually there is in C++ - the standard library. There is one in C too, which I hate. Those standard libraries are the same across all platforms - compile for one, compile for all. As mentioned above - you can't take The Sims post-1.0 code and use it with Unity.
-
Actually there is in C++ - the standard library.
Right; rewritten for each platform C++ runs on.
The only thing "standard" or "universal" about it is its specification-- which is out in the open so anybody can implement it. GUESS WHAT C# HAS THE SAME ARRANGEMENT.
As mentioned above - you can't take The Sims post-1.0 code and use it with Unity.
I don't know why people are using The Sims as an example of... something?... because I've never played it and I know almost nothing about it except they use "woohoo" as a euphemism for sex.
-
Right; rewritten for each platform C++ runs on.
The only thing "standard" or "universal" about it is its specification-- which is out in the open so anybody can implement it. GUESS WHAT C# HAS THE SAME ARRANGEMENT.
The only thing close to this is Mono, which is shit. C# has the possibility of having the same arrangement, and believe me, I wish it came to be.
I don't know why people are using The Sims as an example of... something?
Don't ask me. I was given this example and I also find it absurd.
-
Actually there is in C++ - the standard library. There is one in C too, which I hate. Those standard libraries are the same across all platforms - compile for one, compile for all. As mentioned above - you can't take The Sims post-1.0 code and use it with Unity.
Okay. How many real-world applications are out there which use the standard libraries exclusively?
-
I would say all which do not use Winapi or unistd.h (or other equivalents). Which pretty much is A LOT.
-
I would say all which do not use Winapi or unistd.h (or other equivalents). Which pretty much is A LOT.
I CAN WRITE in caps too. Doesn't make my claims true either.
-
Oh come on - are we nitpicking on using an emphasis?
-
Oh come oh - are we nitpicking on using an emphasis?
Nope. Nitpicking on "provide some sources".
-
I would say all which do not use Winapi or unistd.h (or other equivalents). Which pretty much is A LOT.
Bullshit.
For one thing, every application with a GUI of some sort has to go outside the STL.
-
I'm assuming you don't want me to list all portable software - this would be absurd right? The answer is simple - if something doesn't use system specific stuff - it's not dependent on the OS.
Bullshit.
For one thing, every application with a GUI of some sort has to go outside the STL.
Yes they do. But not every application is a GUI one.
-
I'm assuming you don't want me to list all portable software - this would be absurd right?
Yes.
The answer is simple - if something doesn't use system specific stuff - it's not dependent on the OS.
Everything uses system-specific stuff. There is no such thing as a program that uses no system-specific stuff (even if the "stuff" is just the CPU instructions; or I guess if you're radically redefining the term "system".)
Even your C++ application that uses nothing but a PPC CPU architecture and a console in/out won't run on (say) MacOS 8-- as that OS has no such thing as console in/out. (Of course, MacOS 8 wouldn't even recognize it as an application that is run-able unless you included a bunch of system-specific meta-data to it.)
-
Everything uses system-specific stuff. There is no such thing as a program that uses no system-specific stuff (even if the "stuff" is just the CPU instructions; or I guess if you're radically redefining the term "system".)
If you wish to take it to such an absurd level, then yes. But that's why we have standard libraries with languages to abstract us away from all that.
Even your C++ application that uses nothing but a PPC CPU architecture and a console in/out won't run on (say) Mac OS 8-- as that OS has no such thing as console in/out.
You can use cin and cout as a console in/out and it will compile on all platforms.
-
You can use cin and cout as a console in/out and it will compile on all platforms.
It'll build, it won't run. (Or rather: it might run, it certainly won't run the way the user expects on Mac Classic, since they'll never see the output and never have an opportunity to provide input.)
-
It'll build, it won't run. (Or rather: it might run, it certainly won't run the way the user expects on Mac Classic, since they'll never see the output and never have an opportunity to provide input.)
Well, that means someone wrote a shitty standard library implementation there - blame the vendor, not the library/language. Or is there a build flag to make it work (honest question)?
-
Well, that means someone wrote a shitty standard library implementation there - blame the vendor, not the library/language.
Oh, so we've given up on the concept of "universal generic runtime"? Your Mac Classic runtime needs to have all this stuff in it to draw console windows, handle the AppleEvents relevant to those console windows, etc; that's hardly "universal".
-
Oh, so we've given up on the concept of "universal generic runtime"? Your Mac Classic runtime needs to have all this stuff in it to draw console windows, handle the AppleEvents relevant to those console windows, etc; that's hardly "universal".
Again - that's faulty implementation. Other language runtimes use the same code so it won't work for them either. Underneath all standard library stuff, for any language, there's system stuff, and if that doesn't work as expected - that's not a language/library specific problem.
-
He wrote the book we used. (Run!)
Oh that's not necessarily the worst thing. Where it gets hairy is when you start to get practical assignments involving an in-vivo development version of accompanying software written by the lecturer.
Bonus points if there are known issues getting the software in question to run on the standard laptops issued to (more like foisted on...) students.
Even more bonus points if said software contains bugs that make assignments deterministically impossible to complete and you still get graded down for not completing them.
-
I'm assuming you don't want me to list all portable software - this would be absurd right? The answer is simple - if something doesn't use system specific stuff - it's not dependent on the OS.
That's still not a useful metric. You're repeating yourself.
Again, my question is: How useful is this actually? Does it actually have real-world implications on a large scale or is this just an exercise in masturbation?
-
From my experience, most of the generic libraries on Linux are platform independent - from file compression to image utilities. Most boost libraries are also platform independent. I dare say scientific stuff too, since those deal with maths (which is in the standard library).
-
That's still not saying anything about usefulness.
-
Well, look at the full dependency chain on some eg. KDE app and you'll see the usefulness of middleware. I get the impression you're treating me like I'm some kind of zealot, which you feel the urge to bring down. No worries - I'm not.
-
Underneath all standard library stuff, for any language, there's system stuff, and if that doesn't work as expected - that's not a language/library specific problem.
Mac Classic works EXACTLY as expected, by its designers, by its users, etc.
It's the inflexibility and idiocy of C++'s language designers who didn't account for the possibility of a system with no console. That's the problem here. The language you love so much, that you want to marry and have little C++ kids with? Yeah. The creators of it were COMPLETELY UNAWARE OF THE SECOND-MOST POPULAR OS IN THE WORLD AT THE TIME IT WAS CREATED.
I have a nice short simple word to describe people like that: morons.
So the end-all, be-all, is C++ does not have a "universal generic runtime", because it can't, because the designers of C++ were extraordinarily ignorant of the computer industry at the time they designed it.
-
Nope. I'm just not interested in broad and sweeping statements when they are not backed up by information which supports the argument.
-
he language you love so much, that you want to marry and have little C++ kids with?
Not really. On the other hand we here know that you would die defending any MS-technology, like C#.
The creators of it were COMPLETELY UNAWARE OF THE SECOND-MOST POPULAR OS IN THE WORLD AT THE TIME IT WAS CREATED.
The console was (and still is) a standard in the OS world. Even Windows has one. Actually, this is the first time I read about an OS with no form of console.So the end-all, be-all, is C++ does not have a "universal generic runtime", because it can't, because the designers of C++ were extraordinarily ignorant of the computer industry at the time they designed it.
Looking at your example - that's one OS, while the console is a standard for every other. I'd call the library "good enough" at this point. But true - you'd have to make a Mac OS classic version.Nope. I'm just not interested in broad and sweeping statements when they are not backed up by information which supports the argument.
That may come from different experience. I've dealt a lot in middleware and libraries, so for me, that's the standard. An application writer, for example, might not see it.As I said - I could list you a bunch of Linux libraries, but you're basically telling me "list me all the things I deem useful, and I'll see if it satisfies my definition of a lot".
-
The console was (and still is) a standard in the OS world.
LISA (the predecessor to Macintosh) came out in January 1983. It had no console. C++ development started in 1983. Also the Xerox Star came out in 1981, and I'm 99.44% sure it also had no console.
Actually, this is the first time I read about an OS with no form of console.
Then you are an ignorant motherfucker. Why should anybody respect your opinions?
I remind you again: Macintosh (Mac Classic) was the SECOND MOST POPULAR OS among home computers for something like 20 years-- from 1984 to 2004-ish. It peaked at like a 15-20% marketshare.
It's inexcusable that the makers of C++ would have ignored that OS if they were genuinely trying to create an OS that could make use of a single generic universal runtime. But of course they weren't. You made that shit up.
Looking at your example - that's one OS, while the console is a standard for every other.
Except it's not. You can't use the same C++ runtime on a x86 system that you use on an ARM system that you use on a 68k system that you use on a PPC system. Nobody's ever managed anything remotely close to that. Hell, just bridging the big endian/little endian thing is a pain in the ass.
The best anybody's done is "fat" binaries, which include the entire binary for multiple difference processors in a single file. With a loader smart enough to know which one to "pick".
The point I'm giving you: that a "correct" runtime for C++ can literally NEVER exist in Mac Classic because Mac Classic lacks one of the features required by C++'s STL is just the most blatant example. It's not nearly the only reason a single universal generic runtime is impossible.
The reality is, no. C++ runtimes are crafted for each platform C++ code runs on. They're not universal, and they're not (very) generic. They're just all based on the same specification.
Well guess what? C# is in the exact same situation. It has multiple runtimes on multiple platforms, all based on the same specification.
-
As I said - I could list you a bunch of Linux libraries, but you're basically telling me "list me all the things I deem useful, and I'll see if it satisfies my definition of a lot".
Well, currently we only have your definition of "a lot", so you kind of just defeated your own argument.
-
LISA (the predecessor to Macintosh) came out in January 1983. It had no console. C++ development started in 1983. Also the Xerox Star came out in 1981, and I'm 99.44% sure it also had no console.
Well Unix came '71 and it had one. Earlier systems used TTY console decades before - if dates are an argument for you. Nevertheless, it still doesn't change the fact that the console was and still is a standard.
Then you are an ignorant motherfucker.
And our discussions are over at this point. Have a good life.Well, currently we only have your definition of "a lot", so you kind of just defeated your own argument.
Ok, given the semantics, I view what I've seen over these years as "a lot" for me.
-
Well Unix came '71 and it had one.
And therefore?
Earlier systems used TTY console decades before - if dates are an argument for you.
Ok?
I don't get what point you're getting at. Ford, Chevy and Chrysler all used crank-starters in the 1920s. Therefore a service station attendant trained in 2015 should also learn how to crank-start a car. Right? Is that the logic you're going with here?
My point is that at the time C++ was being developed, systems with no console were ACTUALLY QUITE POPULAR. And if the makers of C++ didn't take that into account (assuming they were trying to create a universal runtime) then they were idiots.
And our discussions are over at this point. Have a good life.
Dude. You're in a computer forum. Arguing about computers. And you know nothing, not even the most basic fundamentals, about a hugely popular OS.
You are ignorant.
And probably also a motherfucker. But that was just an add-on.
If you want to ACTUALLY HAVE AN INTELLIGENT DEBATE you need to demonstrate you KNOW WHAT THE HOLY FUCK YOU'RE TALKING ABOUT. Now I, and everybody else in this forum, knows you do not know what the holy fuck you're talking about.
So my point still applies: why the fuck should we listen to what you think?
-
Knows that metaprogramming or threads are not satanic.
Metaprogramming isn't bad; it's incredibly useful, when done well.C++'s implementation thereof, however, is about as far from "done well" as you can possibly get without wandering into the realm of esolangs and similar stuff that was deliberately not done well just to troll the users. Templates are a mess and a half.
-
C++'s implementation thereof, however, is about as far from "done well" as you can possibly get without wandering into the realm of esolangs and similar stuff that was deliberately not done well just to troll the users. Templates are a mess and a half.
Yeah. D was supposed to take care of that, but it hasn't taken off really.
-
C++ metaprogramming was done "by accident". So yes, pretty far from "done well". It's an emergent property, not something that was designed. It also suffered from being unfamiliar at the time. Since people weren't familiar with templates, they wanted template syntax to be very explicit, so they knew they were using it. Naturally, that very same explicitness becomes annoying when the feature becomes well known and understood.
-
I'm not a specialist in the intricacies of the template system, but looking over the D template page, I don't see anything in particular that differentiates it from C++'s basic style of "here's a T, and here's the pattern that you substitute types into with a glorified search-and-replace mechanism." That's not metaprogramming done well; that's just a (sort of) strongly-typed version of C preprocessor macros.
You want a good metaprogramming system, have a look at the Boo language. (Another one that sadly has really not taken off.) Its metaprogramming constructs (macros, meta methods and AST attributes) are actual code that you execute inside the compiler. They take an AST as input and do things with it, usually either producing a new AST as output or transforming the one you gave it in some way.
For example, I once had to parse a bunch of files with a complicated binary format. After working out that it had a certain set of primitives that it used repeatedly to build structured data, (ints, strings, arrays, etc all saved in their own special way,) I wrote methods to parse those primitives, and then a bunch of macro invocations, one for each data structure type, that essentially looked like type definitions. But the macro rewrote the type definition into an entire class that called the primitive parser methods. What I ended up with was extremely clean and easy to read, and when I wanted to be able to save the data, I just added more stuff to the macro to have it add save methods to the generated classes, and got that functionality for free on the entire set of data types the next time I recompiled.
-
Alright, alright. C# will run on anything for which there is a working C# compiler.
Better now?
Nope. You need the .NET runtime installed.
-
Wah wah wah.
-
No, it's not useful to majority of real-world applications. You should know the characteristics of those: what they represent/do and what they are used for. But how to implement those? Why? To make another version along with a 1000 that's already there? That's pointless - that's NIH at it's finest. If you ever need to dig into the specifics, Google it, but don't waste years teaching it. Just know when to use what and what will be the effect.
If you are teaching someone how to write a good application, then of course you want to point them at what's in the standard library and tell them to use it and not try to reinvent it.
If you're teaching a course on data structures and algorithms, having the class implement classic structures, then test and debug and discuss the implementation is a great way to understand how these structures work, the advantages and disadvantages of using them. Good luck teaching this by simply reviewing someone else's optimized production code.
-
And you know nothing, not even the most basic fundamentals, about a hugely popular OS.
From 30 years ago. Get over it already. It wasn't really that popular.
-
Has anyone else noticed that the argument rapidly slipped from "C++ is more portable than C#" (i.e., an unarguably true statement) to "C++ runs on literally anything without any other libraries to abstract away platform dependencies"?
Also:
@blakeyrat said:Only one of those things matters.
Moore's Law takes care of the other.
Performance matters in a number of domains - like, for example, games. I've played games written in Unity. Terrible framerates and stuttering seem like they're pretty standard.
(I'm aware that part of this is that Mono is not great, and the particular version of Mono Unity is based off of is ancient. But what other non-windows C# runtimes are there?)
