stmfd sp!, {lr}

You should have known this. Java applets have been unofficially deprecated since Java 8 (2013). There was even more dying restrictions put on them in the late portion of Java 7. There's actually pretty OK reasoning behind why Java is taught. It's a nice language to teach SOLID OOP with since it doesn't have the complexity of C++ or the Microsoft nuances of C#. Also, in my experience, unless it's their chosen field, most uni professors are dreadful programmers. Now, teaching JavaScript? I personally think that's a mistake. If I was going to teach languages on a university curriculum, I'd definitely include some C and assembly (perhaps nothing CISC, probably ARM or something), and then throw in something like Go or something.

Important note: It will actually deduce: std::pair<const TKey, TValue>. Which is another way that auto will save your ass. Since, if you used a range-based for loop with a map declared with, say, std::map<int, char> and tried to iterate it with a const reference to std::pair<int, char>, each iteration will produce a copy since the constness cast will be implicit. That's why using auto is a nice way to avoid situations where code that looks intuitive will actually produce implicit casts (and, therefore, copies). Sorry for being pedantic.

When I did it, it involved mmapping /dev/mem and performing basic bitwise operations at offsets. I also did it in ARM assembly the exact same way.

Keep in mind the majority of the python libraries aimed at the pi are just wrapping C libraries (python bindings). You could use both. I personally don't see the benefit in using C for the majority of the basic stuff you can do with the pi (e.g. GPIO - unless you manually wanna learn about how memory mapped I/O works). I'd always lean towards C since I dislike Python and see no benefit in using it. "but python seems to have better IDE" - I desperately hope you're not talking about IDLE or something (LOL). C and C++ have great IDEs. Unless you're doing something that requires C too (e.g. some kind of weird IPC or something), or needs all the performance it can get (I tend not to talk about performance of basic I/O operations, makes me cringe), or you wanna learn about how things like GPIO work, just go for python and save time in the long run.

1) To show intention, if you've got something that is pretty much guaranteed to be unsigned, you should use an unsigned type. Signed would imply there can be negative numbers. You're not gonna have an, for example, array's length as -4 or something. It's always >= 0. Hence things like strlen() return size_t which is unsigned. 2) You could use an STL container instead of allocating everything on the heap manually and having to free it (which you haven't done). 3) You'd have to delete all of the strings you create. You loop and use "new" (allocate on the heap) and never free the allocations. 4) The while getline loop. 5) Replace all the if statements checking the response with a switch statement.

No, you should always do it to show intention. An auto in unsigned contexts (e.g. a simple loop) should yield unsigned and warn you of unsigned to signed comparisons anyway.

Nah, it's perfectly on-topic in my opinion and there's actually a lot more issues that must be addressed in OP's code. OP: 1) Don't use int to represent any form of size. Use an unsigned type; most people would go for size_t. 2) Don't create a std::string pointer as it doesn't serve any purpose. If it's for an array, you should prefer an STL container. Strings are technically meant to be considered immutable hence why they are passed by const-reference so often but, if you know you're going to need a copy anyway, you should just copy it. You could actually move it (shallow copy it) if your intention is to just pass it and be done with it. If the strings are relatively short though, they'll be optimised via SSO and exist on the stack. So a move on an optimised string has the same overhead as copying anyway. 3) You never free any of the strings you create. 4) You've got a random {} scoped block. There is no benefit of having this. 5) Use a switch statement. 6) I'm not 100% convinced that ostream will handle this for you but: in files, newlines actually differ between Windows and *nix. 7) You've got no actual input validation or checking that things worked (e.g. checking std::cin's failbit, making sure file streams are valid, etc.).

The issue is you've masticated the meaning behind "knowing" programming languages. "Knowing" != having used. You have to be more honest in which languages you'd consider yourself proficient in. I often make a few assumptions that second people bring up languages because I'm a bitter, pessimistic, sceptic: - Knowing C: means nothing to me or anyone. I meet a lot of people who've read K&R and believe that's what "knowing C" means. Real utility of C would only become prominent when you have experience in things like WinAPI or *nix programming. - Knowing C++: I doubt everyone who claims to know C++. To be truly proficient at C++, you have to be dedicated to it. A lot of people ignorantly claim to know C++ because they've envisioned it as some form of greyish C with classes. This is so far from accurate. C and C++ may appear incredibly similar on the outside but the difference lies in the latter; C++ is a much larger language than C - in features and in the STL. Being proficient at C++ nowadays would mean being proficient at C++14. So, until you've mastered that (which I seriously doubt you have, no offence - as I said, I doubt everyone since being committed to modern C++ is quite an esoteric endeavour), you should revise your definition of "to know". - Knowing Java: in what sense? In the industry sense e.g. working with Spring or the hobbyist Swing and JavaFX developer? I could make points about the other languages you mentioned but I'm hoping you see my point by now. Please revise your list and tell me the languages you're proficient at; not the ones you've touched.

You'd have to give us a rundown of your current skillset. You'd need at least C and a fair amount of assembly (or just copy and paste from osdev), you'll also require a lot of OS theory that comes with it (someone else mentioned TempleOS - Terry gets credit for that because his system wasn't a complete rip off of UNIX. All these other projects are basically just hobbyist recreating UNIX). OSDev is a good resource. I've been meaning to write a mini kernel for my raspberry pi for a while now but, what you have to realise is: a full blown OS is a huge endeavour. You'll have to write your mini bootloader, memory related stuff (separate kernel and user memory, paging system, etc.), I/O primitives, hardware threading, handle other interrupts, etc. There's so much stuff you'd have to do on top of this. I don't think writing a basic kernel is a very challenging endeavour for a skilled C developer with the right resources (OSDev is great). A full-blown OS? Keep dreaming. Current operating systems have been in development for years with thousands of people working on them along with interest from third party companies to add hardware support etc. OP: If you're gonna install Arch in a VM, just use like Arch Anywhere or something. Will save you effort and will give you the same idea.

Clang lifestyle.

Microsoft has been pushing the idea of "apps" since Windows 8. Windows store apps became quite the craze within the Microsoft-ish sub-communities. I think it's down to things like UWP (https://docs.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp) that these terminologies have become more prominent. I'd still definitely recommend C# for Windows applications regardless (as Microsoft does, depending on features). What I don't understand is why Microsoft continue to push Visual C++. It seems more like a band-aid that perpetuates a messy project (they even revived the syntax choices for C++/CX). I've never truly believed in interop between managed and unmanaged languages (anything beyond a managed plugin system e.g. like something built on Boost::Python is a mess to me). I think Microsoft have too much time and money on their hands and need to employ some hipster to throw around "apps". The only Windows applications I've written post like 2014 have only supported Windows because Windows supports Qt applications (so it's coincidental for the most part).

Even though it's somewhat rare in this side of industry, I always recommend vim. I recommend vim because it saves me so much effort being able to just ssh into a server and make changes within a full-blown editor. Saying this, I'd only recommend it if your OS is a linux distro. I've always used Linux for development (mostly for the practicality of being able to develop locally without something like wamp or xampp). If you're on Windows then, as others have said: Sublime, Atom, Brackets, VSCode, etc. tend to be popular choices. I dislike Atom and VSCode with a passion because they're built on Electron (essentially a headless chrome instance). This means they're rather heavy for text editors. I, personally, don't require some of the fancy features that come in Bracket e.g. live preview. Having done web design for a number of years, I consider my brain a pretty accurate web rendering engine (I think most people who've been doing it long enough do as well - as soon as I see a layout, I can imagine exactly how I'd create it in HTML and CSS). I've designed a lot of things without a preview the whole way through and just refreshed at the end (I always end up adjusting a few things like colours and font sizes at the end but, for the most part, it's pretty easy to work without a live preview - the reason I stopped doing full stack web development, it was way too repetitive. If it wasn't, you wouldn't see things like Bootstrap popping up everyday). Modern web development isn't as much about reinventing the wheel as it is polishing somebody else's wheel (I hate how new designers quickly jump into front-end frameworks and then end up relying on them to the extent that they can't create websites without them - this is an example of a modern cop-out that you should try to avoid. Learn CSS first, then learn front-end frameworks - same with everything really. I've never bought into a framework without being pretty certain that I could create my own version of the framework myself. Perhaps not as polished, but the understanding aspect is there). Sorry for the mini rant at the end. tl;dr - I like vim. Others like really heavy editors like Atom.

Even though I personally dislike it, I'd recommend Java (as a basic start). You've stated no real ambition that would allow us to guide you to a specific language. Other people have brought up important points regarding what learning to program actually is. At first, you'll be bogged down in syntax and be developing a more logical way of thinking. After that, you'll consider the practical usages of the language. Java isn't really that well suited for the majority of things people give it credit for. It's an easy way to get a pretty mediocre job though. Good jobs beyond that will require esoteric abilities that go beyond simply 'knowing' a language. I reckon Java is taught at many universities because it's easier to introduce them to OOP without the Microsoft nuances that are thrown into C# (even though I'd say, as a language, C# is much better designed). It's a lot more simple to teach SOLID, GRASP, design patterns, etc. without these nuances getting in the way. Other factors such as: portability (inb4 CoreCLR - not my point), and out-of-education job prospects. Oracle also likes to push its certificates through education authorities. So, with that in mind I'll give my my rundown: Not sure what you want to do? Python or Java. Want to know more about programming in general? C. I consider C as fundamental (perhaps not the standard lib but the fundamentals it makes prominent are, as I said, fundamentals). Don't look at these suggestions and think I mean 1 language only. This is just a good start before you begin to prioritise your ambitions in a way that makes choosing a practical language a lot more viable.

OP: You may wanna use System.getProperty("line.separator"); instead of hardcoding "\n" since, in files, new lines actually differ between Windows and *nix systems. To ensure cross compatibility, either query the system's line separator or use PrintWriter class which will do this for you, automatically: https://docs.oracle.com/javase/7/docs/api/java/io/PrintWriter.html ("these methods use the platform's own notion of line separator rather than the newline character")

Something along the lines of like: std::cin.ignore(); does the trick.