# Information hiding or modulization in Julia's C/C++ codes

**URL:** <https://discourse.julialang.org/t/information-hiding-or-modulization-in-julias-c-c-codes/55373>\
**Category:** Internals & Design\
**Created:** [February 16, 2021, 7:41am UTC](https://discourse.julialang.org/t/information-hiding-or-modulization-in-julias-c-c-codes/55373 "2021-02-16T07:41:20Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![kimikage](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kimikage/32/14534_2.png) [@kimikage](https://discourse.julialang.org/u/kimikage)\
**Post date:** [February 16, 2021, 7:41am UTC](https://discourse.julialang.org/t/information-hiding-or-modulization-in-julias-c-c-codes/55373/1 "2021-02-16T07:41:20Z")

</div>

As suggested in [https://github.com/JuliaLang/julia/issues/36903](https://github.com/JuliaLang/julia/issues/36903), I also believe that Julia’s ABI needs to be sorted out.  
In addition to the public/private distinction, IMO, it might be better to promote more modularization, even for private data and definitions.

One of the problems I’m facing is the inclusion of c/cpp files.

```julia
$ grep -nrE "#include .+\.cp?p?\"" src | sort
src/builtins.c:401:#include "iddict.c"
src/ccall.cpp:313:#include "abi_llvm.cpp"
src/ccall.cpp:315:#include "abi_arm.cpp"
src/ccall.cpp:316:#include "abi_aarch64.cpp"
src/ccall.cpp:317:#include "abi_ppc64le.cpp"
src/ccall.cpp:318:#include "abi_win32.cpp"
src/ccall.cpp:319:#include "abi_win64.cpp"
src/ccall.cpp:320:#include "abi_x86_64.cpp"
src/ccall.cpp:321:#include "abi_x86.cpp"
src/codegen.cpp:1443:#include "cgutils.cpp"
src/codegen.cpp:2133:#include "intrinsics.cpp"
src/crc32c.c:66:#include "crc32c-tables.c"
src/flisp/flisp.c:411:#include "cvalues.c"
src/flisp/flisp.c:412:#include "types.c"
src/flisp/flisp.c:419:#include "print.c"
src/flisp/flisp.c:811:#include "read.c"
src/flisp/flisp.c:815:#include "equal.c"
src/intrinsics.cpp:7:#include "ccall.cpp"
src/processor.cpp:841:#include "processor_x86.cpp"
src/processor.cpp:845:#include "processor_arm.cpp"
src/processor.cpp:849:#include "processor_fallback.cpp"
src/signal-handling.c:124:#include "signals-win.c"
src/signal-handling.c:126:#include "signals-unix.c"
src/signals-unix.c:229:#include "signals-mach.c"
src/support/hashing.c:51:#include "MurmurHash3.c"

```

I understand the rationale behind such a technique, but I think the disadvantages are greater. In particular, the chain “codegen.cpp” → “intrinsics.cpp” → “ccall.cpp” seems to inherit too many contexts.

I am unable to understand these codes without the assistance of the IDEs, and I use the VS Code as my IDE, but the IntelliSense and some static code analyzers also work hardly at all. Do you use any useful extensions?

I would like to make some improvements, but I am not sure where to start or what should be kept. I also don’t know whether this issue is shared among the developers.

Do you have any advice for me?

---

<div class="post-metadata">

**Author:** ![cdsousa](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cdsousa/32/215553_2.png) [@cdsousa](https://discourse.julialang.org/u/cdsousa)\
**Post date:** [February 16, 2021, 11:02am UTC](https://discourse.julialang.org/t/information-hiding-or-modulization-in-julias-c-c-codes/55373/2 "2021-02-16T11:02:46Z")

</div>

Hi, I’m not a core developer, but I want to say that I also face problems with IntelliSense on large codebases. I recommend you use **ccls** [ccls - Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=ccls-project.ccls) / [https://github.com/MaskRay/ccls](https://github.com/MaskRay/ccls) .

ccls is not so easy to install, and may also be slow sometimes like IntelliSense, but at least it usually indexes large codebases correctly.

EDIT: oh, it seems that **clangd** may also be good (or better), and has automatic installation: [https://clangd.llvm.org/](https://clangd.llvm.org/) / [clangd - Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.vscode-clangd)

---

<div class="post-metadata">

**Author:** ![kimikage](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kimikage/32/14534_2.png) [@kimikage](https://discourse.julialang.org/u/kimikage)\
**Post date:** [February 16, 2021, 11:51am UTC](https://discourse.julialang.org/t/information-hiding-or-modulization-in-julias-c-c-codes/55373/3 "2021-02-16T11:51:54Z")

</div>

Thanks for introducing the extension.  
I am trying the `clangd` now, and it looks very good in itself! 😍

However, it doesn’t seem to automatically resolve even the dependencies of c/cpp files (not header files). The editor pane (minimap) is still bright red. 😂

```julia
Too many errors emitted, stopping now

```

It is functioning “properly”.

---

<div class="post-metadata">

**Author:** ![cdsousa](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cdsousa/32/215553_2.png) [@cdsousa](https://discourse.julialang.org/u/cdsousa)\
**Post date:** [February 16, 2021, 12:05pm UTC](https://discourse.julialang.org/t/information-hiding-or-modulization-in-julias-c-c-codes/55373/4 "2021-02-16T12:05:07Z")

</div>

Yeah, I’ve just noticed now that Julia uses handwritten Makefiles, so it doesn’t (I think) generates a [compile\_commands.json](https://clang.llvm.org/docs/JSONCompilationDatabase.html) file which clangd and cia use to index codebases ☹

---

<div class="post-metadata">

**Author:** ![kimikage](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kimikage/32/14534_2.png) [@kimikage](https://discourse.julialang.org/u/kimikage)\
**Post date:** [February 16, 2021, 12:17pm UTC](https://discourse.julialang.org/t/information-hiding-or-modulization-in-julias-c-c-codes/55373/5 "2021-02-16T12:17:38Z")

</div>

If compilation dependency is a major reason for `#include`-ing c/cpp files, then I think that is a problem which should be solved by the build system.  
I have a lot of 🍇 for CMake, but I think it’s one of the realistic solutions.

---

<div class="post-metadata">

**Author:** ![Gnimuc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gnimuc/32/2194_2.png) [@Gnimuc](https://discourse.julialang.org/u/Gnimuc)\
**Post date:** [February 16, 2021, 12:33pm UTC](https://discourse.julialang.org/t/information-hiding-or-modulization-in-julias-c-c-codes/55373/6 "2021-02-16T12:33:01Z")

</div>

This might be of interest to you.

[https://github.com/rizsotto/Bear](https://github.com/rizsotto/Bear)

---

<div class="post-metadata">

**Author:** ![kimikage](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kimikage/32/14534_2.png) [@kimikage](https://discourse.julialang.org/u/kimikage)\
**Post date:** [February 19, 2021, 7:21am UTC](https://discourse.julialang.org/t/information-hiding-or-modulization-in-julias-c-c-codes/55373/7 "2021-02-19T07:21:00Z")

</div>

IIUC, the most common cause of this problem is file scoping (`static`).  
This is a chicken and egg situation. In order to do a separate compilation, we need to remove `static`s, and as a prerequisite, we need to prohibit the use of inappropriate global variables. However, we cannot know systematically if the use of global variables is appropriate until we stop `#include "*.{c|cpp}"`.

However, at least for C++, we can use namespaces.