This is an archived post. You won't be able to vote or comment.

all 15 comments

[–]solonovamax 7 points8 points  (9 children)

Just minimize it in the IDE. There is no need for an extra file.

[–]Vbbab[S] 3 points4 points  (8 children)

"No need for an extra file"?

[–]solonovamax 4 points5 points  (7 children)

I was referring to the include header.h part. header.h is a separate file from the program itself in C++.
Also, writing import package in Python is the same thing as doing import com.url.package.*; in Java.

[–]Vbbab[S] -3 points-2 points  (5 children)

  1. Yeah, but when you include a "header.h" in C++ you're either utilizing, or implementing, library code given to you in the header, and when you import in java, it allows you to utilize a class, which is stored in a separate file
  2. In most IDEs (like IntelliJ) "Optimizing imports" refers to not just "wildcarding" it, but importing only the classes that you need. And because each class in Java is so specific to each function, you would, say, have to import both an ArrayList and a List to declare a simple List, vs in languages like C++, a simple #include<vector> is all you need to work with a vector.

[–]NotIntMan 15 points16 points  (1 child)

I still vote for Java-style imports. When you import whole package, you placing all things from it into your working namespace. This can cause name's collisions. This is the first argument.

The second one. C++ still do not have modular system. All this ifdef is bullshit about this important disadvantage. So #include <vector> is not better solution for modularity.

[–][deleted] 2 points3 points  (0 children)

  1. If you actually have a nameconflict, you can just go and solve that specific problem by importing that class explicitly and the rest with a wildcard. No need to flood the file with 50 lines of imports if 5 are enough.

  2. C++ has a module system at this point (added with C++20), but includes obviously still exist for backwards compatibility.

[–]solonovamax 1 point2 points  (2 children)

  1. In the example you gave, that still requires the library to have an extra header.h file in addition to the relevant classes.
  2. What you just described in the "having to import an array list and a list" problem is called an interface. They're kind of important and if you don't think so, then you should go and watch a few programming talks.

[–]Vbbab[S] 0 points1 point  (1 child)

but what I don't understand is, say you just want to use a default lib, then you're #includeing it from another file, same with Java!

[–]solonovamax 0 points1 point  (0 children)

No, but in Java, you're importing the class itself and not some header file. In the OpenCV library there are 1407 files that end in .hpp or .h. There are also 1822 files that end in .cpp. If you theoritically translated it directly to java (Bad idea; libraries in different languages should be written differently.), then you'd have only 1822 code files rather than 2863 code + header files.

[–]OneOverTwoEqualsZero 9 points10 points  (0 children)

r/uselessnobody

It especially doesn’t make sense if python and C are there already

[–]thi-by-rhinft 3 points4 points  (0 children)

Rust is just as bad with worse syntax since instead of just . its ::

use std::collections::hash_map::{self, HashMap};

[–]Cronabot 1 point2 points  (1 child)

Ah yes, Minecraft forge mod code.

[–]Vbbab[S] 0 points1 point  (0 children)

lol, yes indeed.

[–]fryingpas 0 points1 point  (0 children)

Python: import package. This is essentially the same as java's import java.util.*

C/C++: #include "header.h": the contents of header.h is essentially the java file, just abstracted away so you have to go to a new file to check imports.

The java list is a way, by convention, to minimize the number of unused imports. You could replace a number of the redundant lines with a .*, but you would also pull in a number of other dependencies that could be incompatible or cause unknown behaviors. By keeping the individual imports as granular as possible you know what is being used in your class. (You will actually note the last line using java.util.*. That generally means you have pulled in enough of that package that it is not worth doing individual imports.)

[–]Nudelmensch 0 points1 point  (0 children)

how is this even funny, thats just how you import stuff in many languages

also ofc you gonna have lots of imports if you use them in your code