3 ms·

True. Other languages have it way easier because: - proper module system, none of this header file nonsense - no compiler flags to worry about - no preproces

True. Other languages have it way easier because: - proper module system, none of this header file nonsense - no compiler flags to worry about - no preprocessor definitions to worry about - as a consequence of the above, no dependencies that require their own linker flags, include directories and preprocessor definitions to work - no need to support different compilers/platforms with different configurations (which work differently with libraries that require different linker flags and include directories and...)

72deluxe 10y ago
Out of curiosity, how do other languages cope with: a. Targeting different release types (debug vs release) b. Changing behaviour of the compiler c. Having different code paths between debug and release (#ifdef _DEBUG) d. Having macros and helpful macro expansion I do not understand the dislike of header files: how would you recommend distributing DLLs and libs while exposing their functions to be developed against? I suppose you could implement everything in a header file if you wanted a simple "module" system (thinking of the header as a module), but this would establish a very simple system with no interdependencies or reusability.
- jayd16 10y ago
  In Java with maven as a package manager: a. Different build goals with different settings in a build file. b. Build steps can be changed in the build file but there are a lot of sane defaults. c. Plain constants and if statements. The compiler optimizes away dead code. d. Code gen is done as another step before the build and not really a task of the compiler.
- oblio 10y ago
  Examples from Java: a. debug/release doesn't matter much so all Java code is in "debug" mode (http://stackoverflow.com/questions/8613535/does-java-have-debug-and-release-build-mode-like-c http://stackoverflow.com/questions/8613535/does-java-have-de... ); the actual debugging is handled via source code/source code jars (jars are just zip files with a standard structure) -> Maven: https://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html https://maven.apache.org/plugins/maven-source-plugin/jar-moj... b. configuration files -> Maven: https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html https://maven.apache.org/plugins/maven-compiler-plugin/compi... c. don't do that? :) d. no macros and most people seem to agree that's a good thing; C macros are not really the kind of tool you want to be using, unless forced to; code generation is used instead Regarding header files: Javadoc for humans, code inspection on the class files for IDEs. No need for separate files in a system designed after the 70s :)
- winstonewert 10y ago
  > I do not understand the dislike of header files: how would you recommend distributing DLLs and libs while exposing their functions to be developed against? Do you enjoy writing out all your function signatures twice? Haven't you ever wished the compiler could automatically build the header file for you?

72deluxe 10y ago

Out of curiosity, how do other languages cope with: a. Targeting different release types (debug vs release) b. Changing behaviour of the compiler c. Having different code paths between debug and release (#ifdef _DEBUG) d. Having macros and helpful macro expansion I do not understand the dislike of header files: how would you recommend distributing DLLs and libs while exposing their functions to be developed against? I suppose you could implement everything in a header file if you wanted a simple "module" system (thinking of the header as a module), but this would establish a very simple system with no interdependencies or reusability.

jayd16 10y ago
In Java with maven as a package manager: a. Different build goals with different settings in a build file. b. Build steps can be changed in the build file but there are a lot of sane defaults. c. Plain constants and if statements. The compiler optimizes away dead code. d. Code gen is done as another step before the build and not really a task of the compiler.
oblio 10y ago
Examples from Java: a. debug/release doesn't matter much so all Java code is in "debug" mode (http://stackoverflow.com/questions/8613535/does-java-have-debug-and-release-build-mode-like-c http://stackoverflow.com/questions/8613535/does-java-have-de... ); the actual debugging is handled via source code/source code jars (jars are just zip files with a standard structure) -> Maven: https://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html https://maven.apache.org/plugins/maven-source-plugin/jar-moj... b. configuration files -> Maven: https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html https://maven.apache.org/plugins/maven-compiler-plugin/compi... c. don't do that? :) d. no macros and most people seem to agree that's a good thing; C macros are not really the kind of tool you want to be using, unless forced to; code generation is used instead Regarding header files: Javadoc for humans, code inspection on the class files for IDEs. No need for separate files in a system designed after the 70s :)
winstonewert 10y ago
> I do not understand the dislike of header files: how would you recommend distributing DLLs and libs while exposing their functions to be developed against? Do you enjoy writing out all your function signatures twice? Haven't you ever wished the compiler could automatically build the header file for you?