#pragma once

Imagine still using headers in 2019.

Attached: b74.png (498x246, 117K)

>avoid being non-portable
Literally an impossibility.
There are no steps you can take, no procedures you can put in place, that will stop the vendor from shipping a custom compiler that doesn't support scope braces or something.

The way includes are handled is a hot mess. You should just be able to include files without define guards. Often important data structures have to be in some header file somewhere instead of your main program. All the declarations in the header file is just more to maintain. Headers also mean adding another (largely meaningless) file into version control and it clutters up the directory.

I know the reasons why it's done the way it is but it's still a pain in the ass.

Attached: 1551988279071.gif (750x545, 333K)

This. Real programmers write everything in one big file.

I write all on one line. Saving those '\n' characters adds up :^)

The entire point of standards is that if the implementation does something different than the standard you can complain. Your complaints may not hold much weight over GCC, but if you're trying to port to a different vendor and you're paying lots of money for a high quality optimizing compiler, then they better get their shit together.

Not write, but shipping? Hell yes, amalgamated single translation unit builds are one of those things you have to use if you want to stay competitive.

why do people act like headers in general are bad and not c/c++'s implementation of them
it's a pretty safe bet most languages that compile to a portable intermediate bytecode, like java and c#, have a binary header at the beginning of every output file
which functions as the same thing, only hidden from the user

>why do people act like headers in general
In general, operating on anything that isn't raw text as raw text is a design mistake. Source code, SQL, HTML, XML, and regular expression patterns should never be created through raw string concatenation or raw string interpolation because of injection bugs and exploits. Include directives inject raw source code into another file, which gives cryptic errors and requires kludges like header guards. It's better to have the language handle modules and hide any details about headers inside the binary.

Attached: 1547823903932.jpg (600x399, 74K)

you've conceptually merged the idea of a language and it's compiler
they're separate, and this separation is important, especially in a native context
this idea that they should be completely hidden stems from interpreted languages where they are merged, where portability of produced binaries is left to the developers of the interpreter

they should not be completely hidden, however making their creation and modification solely up to the end developer is also a mistake
parts of the language standard should include keywords that effectively function as preprocessor annotations, which in the end is what sorta happened with #pragma once
while not officially part of the standard every compiler that matters supports it

computers are like magic boxes that nobody really understands and we're all wizards just like harry potter

I don't care about headers, i just don't want to type twice every functions ? I don't get your point

Why is it a mistake to merge the language and the compiler? Most of my favorite languages explicitly provide hooks into the compiler instead of using a preprocessor.

Attached: 1549642306944.jpg (1600x1200, 363K)

i can't say i know enough about compilers to answer that at length but
>a language is completely abstract and implementation independent
>a compiler isn't
doing so makes standardization very difficult and places all the responsibility of maintaining the language and ensuring portability on what is typically one organization

>doing so makes standardization very difficult and places all the responsibility of maintaining the language and ensuring portability on what is typically one organization
I don't see that. Common Lisp has access to the compiler, a standard, and several conforming implementations. I can't think of any other examples, but besides Fortran, Ada, C++, and C, how many languages even have real documented standards? I guess there's Ruby's ISO/IEC 30170:2012.

...

true and based

like i said
i don't know enough to know why it's important, that was mostly an educated guess
it just is

and common lisp doesn't merge the two as ideas either
the language and the compiler are still two separate things, they just happen to both be part of the common lisp standard