Looking for C++ help

Every time I try to dive into C, C++, Objective-C, or any other high-level language that operates a little *too* close to the metal, I end up running into countless issues with toolchains. I have no problem understanding everything at the highest level (source code, pointers, memory allocation, typing, algorithms, etc) or the lowest level (memory mapping, instruction set architecture, registers, stack pointers, etc). But everything in between seems to be 50 years of historical baggage that I haven't been able to fully grasp.

After literal MONTHS on everything from StackOverflow to WikiPedia to YouTube to learncpp.com I have a theoretical understanding of:

>Name mangling
>Overloading
>Debug symbols
>Executable file formats
>"Fat" binaries
>Linking
>The C Standard Library
>Header search paths
>ANSI-C standards (most recently C++17, upcoming C++20)
>Pre-compiler directives
>Compiler directives
>etc

But not only am I always questioning my knowledge, whenever I try to apply it I run into countless roadblocks with the literal mountain of available tools (make, autoconf, CMake, gcc, clang, LLVM, Xcode, Visual Studio, lipo, binutils, etc) since I don't know exactly what role each tool is supposed to fill, what roles it DOESN'T fill, what it's automating for me, and what I'm expected to do myself. There are thousands of pages of documentation for these tools (ain't nobody got time for that) and hundreds of command line parameters or hidden configuration windows within GUIs and somehow the experts always know exactly which checkbox you need to tick to make your code run but I spend 18+ hours either staring at nonsensical errors or receiving NO meaningful feedback but not getting a working program.

Can anyone recommend a resource for filling in the gaps in my knowledge? Don't say college: I did that. They wasted four years teaching Python and talking about the history of ENIAC (but nothing about the history of Simula, Smalltalk, C, C++, Java, GCC, UNIX, etc)

Attached: cmake_error.png (1568x740, 208K)

Other urls found in this thread:

en.wikipedia.org/wiki/Category:High-level_programming_languages
en.wikipedia.org/wiki/High-level_programming_language
en.m.wikibooks.org/wiki/C++_Programming/All_Chapters
twitter.com/NSFWRedditVideo

As a side-note, I've already invested the time and energy into making sense of the years of baggage (albeit fewer years) related to PHP and JavaScript (both of which I've had to use at prior jobs), so feel free to use either of those as examples. For instance: I have a pretty good grasp on not just what NPM is (a package manager, like Composer) but how it actually operates, where it stores its cache files, WHY it stores cache files in the first place, how it locates binaries, WHY it has that tool for locating binaries, etc. I have a good grasp of the V8 engine and its various eccentricities that drive other programmers mad, and I understand how bundlers (e.g. Browserify / Webpack) work and how minifiers (e.g. UglifyJS / Closure) work. Those toolchains aren't a mystery to me. C has always eluded me.

>C, C++, Objective-C, or any other high-level language that operates a little *too* close to the metal
Not sure if serious or pasta. C is a low-level language, meaning close to the metal. C++ can be low-level, high-level, or somewhere in between, depending on what parts you're using. Objective-C is some Apple thing I wouldn't know about.

>Statically compiled languages
1. These abominations shouldn't exist.
2. Read again: 'Statically compiled' languages. That's how retarded most computer scientists are, and so it's no wonder that all of these toolchains are clusterfucks. If you must use something other than Forth or Erlang, then at least choose a modern language like Kotlin or Rust.

C is a high-level language because you work in abstract concepts like "for", "while", etc. A low-level language would be assembly. Just because it's lower level than you're used to doesn't mean it fails to meet the definition of a high-level language.

en.wikipedia.org/wiki/Category:High-level_programming_languages

You'll find C and C++ in that list, along with several old favorites like Squeak and Fortran

>C is a low-level language

Attached: 40786d_6779923.png (1300x1300, 147K)

Rust is my preferred language (although I disagree with a couple design choices they made, like making the parenthesis optional but the brackets required on conditional statements)

However if you're doing mobile application development then you often have to suffer with Objective-C. I currently find myself in that position at my work and I've spent an entire week having trouble compiling a simple library because one flag buried deep in the UI isn't set right, or some symlink expected to be on my system didn't exist, or the library I was attempting to link didn't contain a binary for my architecture,.... It's been one headache after another and I'm hoping that SOMEWHERE there exists a resource that starts at square one and actually TEACHES this shit so I'm not fumbling and guessing. A YouTube series, a website, a book,... ANYTHING

Also, what's with the hate for statically compiled languages? They operate like any well-designed algorithm should: they do the hard work once (compilation) and minimize what needs to be done repeatedly (runtime)

this is pathetic

Some people think anything with manual memory management is "low-level". So Java, PHP, Python, and Perl would be "high-level" and C, ASM, and Rust would be "low-level"

Helpful and informative. Thank you.

My answer is partly trolling, and I have much less knowledge than someone currently working. However, I learned enough in the past that I decided to quit. It's impossible to provide what you ask for, because the toolchains are maintained by a finite set of human beings. The the flag you mentioned is one of hundreds of thousands if not millions of things that have been overlooked, simply due to the number of man hours available.

As for the hate for static languages, just what Chuck Moore said. Repeatedly re-linking and re-compiling the same code whenever you want to change even one bit of data in your program is the most retarded idea ever. And yet this retarded industry continues to maintain a facade of professionalism with its concept of BUILDS.

in the time its taking you to be publicly butthurt that you didnt use the right compile flags you could just read the man pages like a functional human being

It’s a systems language with the ability to program at the machine level (literally assembly contained and used within your c/++ compiler.
It’s “medium” level at the highest as a result. An intermediary from assembly from which most high level languages were born.

My point went over your pathetic head. I don't want to use compile flags because I don't want to waste time by writing monolithic software. Oh and by the way the only functional human beings in the software world are Forth coders.

The definition of a high-level language is a language which is independent of the hardware it runs on. ASM depends on the architecture (MIPS ASM, x86 ASM, etc). C/C++ does not depend on the hardware - you right generic code that can be compiled to PowerPC, i386, or ARM

You're using your own definition of "high-level" and invented the term "medium-level", rather than using the industry-defined terms:

en.wikipedia.org/wiki/High-level_programming_language

I would argue that if you're changing your code frequently then there's a good chance you're not using your software well. A good program should be generic, configurable, and modular. You don't have to re-compile FFMPEG every time you want to transcode a different video.

Embedded devices, micro-controllers, and iOS all utilized statically compiled languages to improve run-time performance and reduce memory usage. You don't have to load an interpreter into memory, there's no garbage collector, and you don't have to parse the code every time it runs. But then iOS apps aren't updated 800 times a day. You make an app, put it on the app store, then maybe push an update every few weeks (if that)

I'll look up Chuck Moore (I don't know many industry names) and see if he had any recommendations for working around that issue of performance or if he just hand-waved it like many do by saying "Moore's Law will make computers fast enough"

Fuck you you wiki guzzler. Read a book. Here’s a big tech approved source for your newspeak faggot ass:
en.m.wikibooks.org/wiki/C++_Programming/All_Chapters
c++ is just ‘better assembly.’ In most use cases.
Binary is not a low level language by your strict requirement.

>en.m.wikibooks.org/wiki/C++_Programming/All_Chapters
Binary is a numeric base system. That's like saying "base 10 is not a low level language" or "algebra is not a low level language". They aren't even programming languages. Likely by "binary" you mean "machine code", which IS machine-dependent (google "instruction set architecture") and therefore it IS a low-level language

And that link you sent me?

>The Higher-level a language is, the harder it works to solve the problem of abstraction to the hardware (CPU, co-processors, number of registers etc...) by supporting portability of code and higher human intelligibility via added complexity in expression and constructs.
>Keep in mind that this classification scheme is evolving. C++ is still considered a high-level language

Also, if you want to read a book instead of WikiPedia, maybe try "The C Programming Language" by K&R (literally THE book on C, written by its creators) -- it describes C as a high level langauge

I'm not saying "C is extremely highly abstracted" -- it still has concepts of pointers, memory, threads, etc. So it's definitely less-abstracted than other languages like Java or PHP, and it's a LOT less abstracted than something like MATLAB. But it's portable, and therefore it's "high-level" -- it's just high-level with minimal abstractions.

>Binary is not a low level language by your strict requirement.

Binary is not a language.

>c++ is just ‘better assembly.’ In most use cases.
What, do you think Java doesn't have anything to do with machine code because it compiles into Java bytecode instead of machine dependent? The instructions have to be decoded and executed on the CPU at some point. Every language ever invented is just "better assembly".

Using that logic fucking Python is "better C" which is "better assembly" (which is "better machine code", which is "better electrical charges traveling inside silicone wafers", which is "better electrons being translated inside of a metaloid lattice", which is [...]) and by the logic of algebra: a > b & b > c => a > c.

Attached: skepticalmanwithglassesC7E5RM.jpg (869x1390, 164K)

I feel the same way. Could be wrong though.

Just use Visual Studio, it does everything for you (as in you don't need any other tool, but may need to fuck around with it sometimes). It shouldn't require any special knowledge and it's mostly intuitive (until you need to add strange dependencies that aren't on Nuget, but then again, most libraries have step by step configuration guides).

Your first two paragraphs refer to extant software that has undergone thousands upon thousands of compilations during the development phase. Development would have been much easier on a fully interactive system. In addition, on inherently static systems, there's a great deal of duplicate code. Think of all the implementations of "println" in different software. The code for all of these implementations are repeatedly loaded into and out of ram as the programs are context switched.

In theory the performance issue is solved by designing cpus to handle threaded code, which I believe Chuck Moore did with his microcontrollers. There are some problems he didn't care to solve like how to avoid bricking the cpu, but this problem also exists with embedded systems written in C etc.