From deea17ed14a1741d0456394e15a126f84def55ab Mon Sep 17 00:00:00 2001 From: MA Laforge Date: Sun, 23 Aug 2020 11:19:58 -0400 Subject: [PATCH 1/6] Add C/C++ diff: scope, modules, packages. --- doc/src/manual/noteworthy-differences.md | 60 ++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/doc/src/manual/noteworthy-differences.md b/doc/src/manual/noteworthy-differences.md index 5ca2bfe6f6bad..1357517917e15 100644 --- a/doc/src/manual/noteworthy-differences.md +++ b/doc/src/manual/noteworthy-differences.md @@ -335,6 +335,66 @@ For users coming to Julia from R, these are some noteworthy differences: it's more general than that since methods are dispatched on every argument type, not only `this`, using the most-specific-declaration rule). +### Julia⇔C/C++: namespaces + * C/C++ `namespace`s correspond roughly to Julia `module`s. + * There are no private functions/variables/modules/... in Julia. Everthing is accessible through fully qualified paths (or relative paths, if desired). + * `using MyNamespace::myfun` (C++) corresponds roughly to `import MyModule.myfun` (Julia). + * `using namespace MyNamespace` (C++) corresponds roughly to `using MyModule` (Julia) - but only `export`ed symbols are pulled into the calling module. + * Caveat: `import`/`using` keywords (Julia) also *load* modules (see below). + * Caveat: `import`/`using` (Julia) works only at the global scope level (`module`s), whereas `using namespace X` (C++) works within arbitrary scopes (ex: function scope). + +### Julia⇔C/C++: Module loading + * When you think of a C/C++ "**library**", you are likely looking for a Julia "**package**". + * Caveat: C/C++ libraries often house multiple "software modules" whereas Julia "packages" typically house one. + * *Reminder*: Julia `module`s are global scopes - not necessarily "software modules". + * **Instead of build/`make` scripts**, Julia uses "Project Environments" (sometimes called either "Project" or "Environment"). + * C/C++ code typically target end-user applications, whereas "Project Environments" focus more on providing different package sets to analyze various problem spaces. Julia users typically use custom "scripts" for this type of analysis. + * Users can initialize separate "Project Environment" directories to house code for different end-user applications. + * Available packages are added to a "Project Environment" with the `pkg> add` tool. Note: `pkg> add` does not load said package. + * The list of available packages (direct dependencies) for a "Project Environment" are saved in its `Project.toml` file. + * The *full* dependency information for a "Project Environment" is auto-generated & saved in its `Manifest.toml` file. + * **Directory-based package repositories** (Julia) can be made available by adding repository paths to the `Base.LOAD_PATH` array. By default, Julia also treats the current working directory as a type of "package repository". + * Directory-based packages do not require using the `pkg> add` tool to be used. + * Directory-based package repositories are the **quickest solution** to developping local libraries of "software modules". + * Packages ("software modules") available to the "Project Environment" are loaded with `import` or `using`. + * In C/C++, you `#include ` to get object/function delarations, and link in libraries when you build the executable. + * In Julia, whatever is loaded is available to *all other* loaded modules through its fully qualified path (no header file required). + * Use `import SomePkg: SubModule.SubSubmodule` (Julia) to access package submodules. +### Julia⇔C/C++: Assembling modules + * In C/C++, `.c`/`.cpp` files are compiled & added to a library with build/`make` scripts. + * In Julia, `import [PkgName]`/`using [PkgName]` statements load `[PkgName].jl` located in a package's `[PkgName]/src/` subdirectory. + * In turn, `[PkgName].jl` typically loads associated source files with calls to `include "[someotherfile].jl"`. + * `include "./path/to/somefile.jl"` (Julia) is very similar to `#include "./path/to/somefile.jl"` (C/C++). + * However `include "somefile.jl"` (Julia) is not used to include header files (not required). + * `include "somefile.jl"` (Julia) **should not be used** to load code from other "software modules" (use `import`/`using` instead). + * `include "path/to/some/module.jl"` (Julia) would instantiate multiple versions of the same code in different modules (creating distinct types (etc.) with similar names). + * `include "somefile.jl"` is typically used to assemble multiple files *within the same software module (Julia package)*. It is therefore relatively easy to ensure a file is `include`d only once (No need for `#ifdef`s). + +### Julia⇔C/C++: Module interface + * C++ exposes interfaces using "public" `.h`/`.hpp` files whereas Julia `module`s `export` symbols that are intended for their users. + * Often, Julia `module`s simply add functionality by generating new "methods" to existing functions (ex: `Base.push!`). + * Developers of Julia packages therefore cannot rely on header files for interface documentation. + * Interfaces for Julia packages are typically described using docstrings, README.md, static web pages, ... + * Some developers choose not to `export` all symbols required to use their package/module. + * Users might be expected to access these components by qualifying functions/structs/... with the package/module name (ex: `MyModule.run_this_task(...)`). + +### Julia⇔C/C++: Quick reference + +| Software Concept | Julia | C/C++ | +| :--- | :--- | :--- | +| unnamed scope | `begin` ... `end` | `{` ... `}` | +| function scope | `function x()` ... `end` | `int x() {` ... `}` | +| global scope | `module MyMod` ... `end` | `namespace MyNS {` ... `}` | +| software module | A Julia "package" | `.h`/`.hpp` files
+compiled `somelib.a` | +| assemble sw module | `SomePkg.jl`: ...
`import subfile1.jl`
`import subfile2.jl`... | assemble `*.o`⇒`somelib.a` | +| import sw module | `import SomePkg` | `#include `
+link in `somelib.a` | +| module library | `LOAD_PATH[]`, \*Git repository
\*\*custom package registry | more `.h`/`.hpp` files
+bigger compiled `somebiglib.a` | + +\* The Julia package manager supports registering multiple packages from a single Git repository. This allows users to house a library of related packages in a single repository.
+\*\* Julia registries are primarily designed to provide versionning \& distribution of packages.
+\*\* Custom package registries can be used to create a type of module library. + + ## Noteworthy differences from Common Lisp - Julia uses 1-based indexing for arrays by default, and it can also handle arbitrary [index offsets](@ref man-custom-indices). From b23367c977f914d35d38a056a33665e3d09b7f9f Mon Sep 17 00:00:00 2001 From: MA Laforge Date: Sun, 23 Aug 2020 12:25:47 -0400 Subject: [PATCH 2/6] Tweak C/C++ info & wrap lines. --- doc/src/manual/noteworthy-differences.md | 108 +++++++++++++++-------- 1 file changed, 70 insertions(+), 38 deletions(-) diff --git a/doc/src/manual/noteworthy-differences.md b/doc/src/manual/noteworthy-differences.md index 1357517917e15..6de83f785a900 100644 --- a/doc/src/manual/noteworthy-differences.md +++ b/doc/src/manual/noteworthy-differences.md @@ -335,50 +335,81 @@ For users coming to Julia from R, these are some noteworthy differences: it's more general than that since methods are dispatched on every argument type, not only `this`, using the most-specific-declaration rule). -### Julia⇔C/C++: namespaces +### Julia ⇔ C/C++: Namespaces * C/C++ `namespace`s correspond roughly to Julia `module`s. - * There are no private functions/variables/modules/... in Julia. Everthing is accessible through fully qualified paths (or relative paths, if desired). + * There are no private functions/variables/modules/... in Julia. Everthing is accessible + through fully qualified paths (or relative paths, if desired). * `using MyNamespace::myfun` (C++) corresponds roughly to `import MyModule.myfun` (Julia). - * `using namespace MyNamespace` (C++) corresponds roughly to `using MyModule` (Julia) - but only `export`ed symbols are pulled into the calling module. + * `using namespace MyNamespace` (C++) corresponds roughly to `using MyModule` (Julia) - though + only `export`ed symbols are made available to the calling module. * Caveat: `import`/`using` keywords (Julia) also *load* modules (see below). - * Caveat: `import`/`using` (Julia) works only at the global scope level (`module`s), whereas `using namespace X` (C++) works within arbitrary scopes (ex: function scope). + * Caveat: `import`/`using` (Julia) works only at the global scope level (`module`s), whereas + `using namespace X` (C++) works within arbitrary scopes (ex: function scope). -### Julia⇔C/C++: Module loading +### Julia ⇔ C/C++: Module loading * When you think of a C/C++ "**library**", you are likely looking for a Julia "**package**". - * Caveat: C/C++ libraries often house multiple "software modules" whereas Julia "packages" typically house one. - * *Reminder*: Julia `module`s are global scopes - not necessarily "software modules". - * **Instead of build/`make` scripts**, Julia uses "Project Environments" (sometimes called either "Project" or "Environment"). - * C/C++ code typically target end-user applications, whereas "Project Environments" focus more on providing different package sets to analyze various problem spaces. Julia users typically use custom "scripts" for this type of analysis. - * Users can initialize separate "Project Environment" directories to house code for different end-user applications. - * Available packages are added to a "Project Environment" with the `pkg> add` tool. Note: `pkg> add` does not load said package. - * The list of available packages (direct dependencies) for a "Project Environment" are saved in its `Project.toml` file. - * The *full* dependency information for a "Project Environment" is auto-generated & saved in its `Manifest.toml` file. - * **Directory-based package repositories** (Julia) can be made available by adding repository paths to the `Base.LOAD_PATH` array. By default, Julia also treats the current working directory as a type of "package repository". + * Caveat: C/C++ libraries often house multiple "software modules" whereas Julia + "packages" typically house one. + * Reminder: Julia `module`s are global scopes (not necessarily "software modules"). + * **Instead of build/`make` scripts**, Julia uses "Project Environments" (sometimes called + either "Project" or "Environment"). + * C/C++ code typically target more conventional applications, whereas "Project Environments" + (Julia) provide a set of packages to experiment with particular problem spaces. + Julia users typically use custom "scripts" for this type of experimentation. + * To develop a "conventional" application/project, you can initialize its root directory + as a "Project Environment", and house your application-specific code/packages there. + This will provide good control over project dependencies, and future reproducibility. + * Available packages are added to a "Project Environment" with the `pkg> add` tool. + Note: `pkg> add` does not load said package. + * The list of available packages (direct dependencies) for a "Project Environment" are + saved in its `Project.toml` file. + * The *full* dependency information for a "Project Environment" is auto-generated & saved + in its `Manifest.toml` file. + * **Directory-based package repositories** (Julia) can be made available by adding repository + paths to the `Base.LOAD_PATH` array. + * By default, Julia also treats the current working directory as a type of "package repository". * Directory-based packages do not require using the `pkg> add` tool to be used. - * Directory-based package repositories are the **quickest solution** to developping local libraries of "software modules". - * Packages ("software modules") available to the "Project Environment" are loaded with `import` or `using`. - * In C/C++, you `#include ` to get object/function delarations, and link in libraries when you build the executable. - * In Julia, whatever is loaded is available to *all other* loaded modules through its fully qualified path (no header file required). - * Use `import SomePkg: SubModule.SubSubmodule` (Julia) to access package submodules. -### Julia⇔C/C++: Assembling modules + * Directory-based package repositories are the **quickest solution** to developping local + libraries of "software modules". + * Packages ("software modules") available to the "Project Environment" are loaded with + `import` or `using`. + * In C/C++, you `#include ` to get object/function delarations, and link in + libraries when you build the executable. + * In Julia, whatever is loaded is available to *all other* loaded modules through its + fully qualified path (no header file required). + * Use `import SomePkg: SubModule.SubSubmodule` (Julia) to access package submodules. + +### Julia ⇔ C/C++: Assembling modules * In C/C++, `.c`/`.cpp` files are compiled & added to a library with build/`make` scripts. - * In Julia, `import [PkgName]`/`using [PkgName]` statements load `[PkgName].jl` located in a package's `[PkgName]/src/` subdirectory. - * In turn, `[PkgName].jl` typically loads associated source files with calls to `include "[someotherfile].jl"`. - * `include "./path/to/somefile.jl"` (Julia) is very similar to `#include "./path/to/somefile.jl"` (C/C++). - * However `include "somefile.jl"` (Julia) is not used to include header files (not required). - * `include "somefile.jl"` (Julia) **should not be used** to load code from other "software modules" (use `import`/`using` instead). - * `include "path/to/some/module.jl"` (Julia) would instantiate multiple versions of the same code in different modules (creating distinct types (etc.) with similar names). - * `include "somefile.jl"` is typically used to assemble multiple files *within the same software module (Julia package)*. It is therefore relatively easy to ensure a file is `include`d only once (No need for `#ifdef`s). + * In Julia, `import [PkgName]`/`using [PkgName]` statements load `[PkgName].jl` located + in a package's `[PkgName]/src/` subdirectory. + * In turn, `[PkgName].jl` typically loads associated source files with calls to + `include "[someotherfile].jl"`. + * `include "./path/to/somefile.jl"` (Julia) is very similar to + `#include "./path/to/somefile.jl"` (C/C++). + * However `include "..."` (Julia) is not used to include header files (not required). + * **Do not use** `include "..."` (Julia) to load code from other "software modules" + (use `import`/`using` instead). + * `include "path/to/some/module.jl"` (Julia) would instantiate multiple versions of the + same code in different modules (creating *distinct* types (etc.) with similar names). + * `include "somefile.jl"` is typically used to assemble multiple files *within the same + Julia package ("software module")*. It is therefore relatively straightforward to ensure + file are `include`d only once (No `#ifdef` confusion). -### Julia⇔C/C++: Module interface - * C++ exposes interfaces using "public" `.h`/`.hpp` files whereas Julia `module`s `export` symbols that are intended for their users. - * Often, Julia `module`s simply add functionality by generating new "methods" to existing functions (ex: `Base.push!`). - * Developers of Julia packages therefore cannot rely on header files for interface documentation. - * Interfaces for Julia packages are typically described using docstrings, README.md, static web pages, ... +### Julia ⇔ C/C++: Module interface + * C++ exposes interfaces using "public" `.h`/`.hpp` files whereas Julia `module`s `export` + symbols that are intended for their users. + * Often, Julia `module`s simply add functionality by generating new "methods" to existing + functions (ex: `Base.push!`). + * Developers of Julia packages therefore cannot rely on header files for interface + documentation. + * Interfaces for Julia packages are typically described using docstrings, README.md, + static web pages, ... * Some developers choose not to `export` all symbols required to use their package/module. - * Users might be expected to access these components by qualifying functions/structs/... with the package/module name (ex: `MyModule.run_this_task(...)`). + * Users might be expected to access these components by qualifying functions/structs/... + with the package/module name (ex: `MyModule.run_this_task(...)`). -### Julia⇔C/C++: Quick reference +### Julia ⇔ C/C++: Quick reference | Software Concept | Julia | C/C++ | | :--- | :--- | :--- | @@ -386,11 +417,12 @@ For users coming to Julia from R, these are some noteworthy differences: | function scope | `function x()` ... `end` | `int x() {` ... `}` | | global scope | `module MyMod` ... `end` | `namespace MyNS {` ... `}` | | software module | A Julia "package" | `.h`/`.hpp` files
+compiled `somelib.a` | -| assemble sw module | `SomePkg.jl`: ...
`import subfile1.jl`
`import subfile2.jl`... | assemble `*.o`⇒`somelib.a` | -| import sw module | `import SomePkg` | `#include `
+link in `somelib.a` | -| module library | `LOAD_PATH[]`, \*Git repository
\*\*custom package registry | more `.h`/`.hpp` files
+bigger compiled `somebiglib.a` | +| assembling
software modules | `SomePkg.jl`: ...
`import subfile1.jl`
`import subfile2.jl`
... | `$(AR) *.o` ⇒ `somelib.a` | +| import
software module | `import SomePkg` | `#include `
+link in `somelib.a` | +| module library | `LOAD_PATH[]`, \*Git repository,
\*\*custom package registry | more `.h`/`.hpp` files
+bigger compiled `somebiglib.a` | -\* The Julia package manager supports registering multiple packages from a single Git repository. This allows users to house a library of related packages in a single repository.
+\* The Julia package manager supports registering multiple packages from a single Git repository.
+\* This allows users to house a library of related packages in a single repository.
\*\* Julia registries are primarily designed to provide versionning \& distribution of packages.
\*\* Custom package registries can be used to create a type of module library. From 5cc7ac079a0b8c9d84354c635f30607f87d4b730 Mon Sep 17 00:00:00 2001 From: MA Laforge Date: Sun, 23 Aug 2020 12:54:32 -0400 Subject: [PATCH 3/6] More tweaks to the C++ differences. --- doc/src/manual/noteworthy-differences.md | 44 +++++++++++++----------- 1 file changed, 24 insertions(+), 20 deletions(-) diff --git a/doc/src/manual/noteworthy-differences.md b/doc/src/manual/noteworthy-differences.md index 6de83f785a900..c34099e779505 100644 --- a/doc/src/manual/noteworthy-differences.md +++ b/doc/src/manual/noteworthy-differences.md @@ -340,11 +340,12 @@ For users coming to Julia from R, these are some noteworthy differences: * There are no private functions/variables/modules/... in Julia. Everthing is accessible through fully qualified paths (or relative paths, if desired). * `using MyNamespace::myfun` (C++) corresponds roughly to `import MyModule.myfun` (Julia). - * `using namespace MyNamespace` (C++) corresponds roughly to `using MyModule` (Julia) - though - only `export`ed symbols are made available to the calling module. + * `using namespace MyNamespace` (C++) corresponds roughly to `using MyModule` (Julia) + * In Julia, only `export`ed symbols are made available to the calling module. + * In C++, only elements found in the included (public) header files are made available. * Caveat: `import`/`using` keywords (Julia) also *load* modules (see below). - * Caveat: `import`/`using` (Julia) works only at the global scope level (`module`s), whereas - `using namespace X` (C++) works within arbitrary scopes (ex: function scope). + * Caveat: `import`/`using` (Julia) works only at the global scope level (`module`s) + * In C++, `using namespace X` works within arbitrary scopes (ex: function scope). ### Julia ⇔ C/C++: Module loading * When you think of a C/C++ "**library**", you are likely looking for a Julia "**package**". @@ -353,24 +354,20 @@ For users coming to Julia from R, these are some noteworthy differences: * Reminder: Julia `module`s are global scopes (not necessarily "software modules"). * **Instead of build/`make` scripts**, Julia uses "Project Environments" (sometimes called either "Project" or "Environment"). - * C/C++ code typically target more conventional applications, whereas "Project Environments" - (Julia) provide a set of packages to experiment with particular problem spaces. - Julia users typically use custom "scripts" for this type of experimentation. - * To develop a "conventional" application/project, you can initialize its root directory - as a "Project Environment", and house your application-specific code/packages there. - This will provide good control over project dependencies, and future reproducibility. - * Available packages are added to a "Project Environment" with the `pkg> add` tool. - Note: `pkg> add` does not load said package. + * Build scripts are only needed for more complex applications + (like those needing to compile, or download C/C++ executables :) ). + * C/C++ code typically target more conventional applications, whereas Julia + "Project Environments" provide a set of packages to experiment with particular problem + spaces. Julia users typically use problem-specific "scripts" for this type of experimentation. + * To develop a "conventional" application/project in Julia, you can initialize its root directory + as a "Project Environment", and house application-specific code/packages there. + This provides good control over project dependencies, and future reproducibility. + * Available packages are added to a "Project Environment" with the `pkg> add` tool + (This does not **load** said package, however). * The list of available packages (direct dependencies) for a "Project Environment" are saved in its `Project.toml` file. * The *full* dependency information for a "Project Environment" is auto-generated & saved in its `Manifest.toml` file. - * **Directory-based package repositories** (Julia) can be made available by adding repository - paths to the `Base.LOAD_PATH` array. - * By default, Julia also treats the current working directory as a type of "package repository". - * Directory-based packages do not require using the `pkg> add` tool to be used. - * Directory-based package repositories are the **quickest solution** to developping local - libraries of "software modules". * Packages ("software modules") available to the "Project Environment" are loaded with `import` or `using`. * In C/C++, you `#include ` to get object/function delarations, and link in @@ -378,6 +375,13 @@ For users coming to Julia from R, these are some noteworthy differences: * In Julia, whatever is loaded is available to *all other* loaded modules through its fully qualified path (no header file required). * Use `import SomePkg: SubModule.SubSubmodule` (Julia) to access package submodules. + * **Directory-based package repositories** (Julia) can be made available by adding repository + paths to the `Base.LOAD_PATH` array. + * By default, Julia also treats the current working directory as a type of "package repository". + * Packages from directory-based repositories do not require the `pkg> add` tool prior to + being loaded with `import` or `using`. They are simply available to the project. + * Directory-based package repositories are the **quickest solution** to developping local + libraries of "software modules". ### Julia ⇔ C/C++: Assembling modules * In C/C++, `.c`/`.cpp` files are compiled & added to a library with build/`make` scripts. @@ -391,9 +395,9 @@ For users coming to Julia from R, these are some noteworthy differences: * **Do not use** `include "..."` (Julia) to load code from other "software modules" (use `import`/`using` instead). * `include "path/to/some/module.jl"` (Julia) would instantiate multiple versions of the - same code in different modules (creating *distinct* types (etc.) with similar names). + same code in different modules (creating *distinct* types (etc.) with the *same* names). * `include "somefile.jl"` is typically used to assemble multiple files *within the same - Julia package ("software module")*. It is therefore relatively straightforward to ensure + Julia package* ("software module"). It is therefore relatively straightforward to ensure file are `include`d only once (No `#ifdef` confusion). ### Julia ⇔ C/C++: Module interface From 535b53408df9180fbc91dfc3912ca6ff5668f46c Mon Sep 17 00:00:00 2001 From: ma-laforge Date: Sun, 23 Aug 2020 14:00:33 -0400 Subject: [PATCH 4/6] Update doc/src/manual/noteworthy-differences.md Co-authored-by: Stefan Karpinski --- doc/src/manual/noteworthy-differences.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/manual/noteworthy-differences.md b/doc/src/manual/noteworthy-differences.md index c34099e779505..fa37b9f075867 100644 --- a/doc/src/manual/noteworthy-differences.md +++ b/doc/src/manual/noteworthy-differences.md @@ -339,7 +339,7 @@ For users coming to Julia from R, these are some noteworthy differences: * C/C++ `namespace`s correspond roughly to Julia `module`s. * There are no private functions/variables/modules/... in Julia. Everthing is accessible through fully qualified paths (or relative paths, if desired). - * `using MyNamespace::myfun` (C++) corresponds roughly to `import MyModule.myfun` (Julia). + * `using MyNamespace::myfun` (C++) corresponds roughly to `import MyModule: myfun` (Julia). * `using namespace MyNamespace` (C++) corresponds roughly to `using MyModule` (Julia) * In Julia, only `export`ed symbols are made available to the calling module. * In C++, only elements found in the included (public) header files are made available. From 2fe6daf28a35b4eb1a4e4658fee8055e1cccff31 Mon Sep 17 00:00:00 2001 From: MA Laforge Date: Sun, 4 Oct 2020 12:12:39 -0400 Subject: [PATCH 5/6] correction: cwd is not a package repo by default. --- doc/src/manual/noteworthy-differences.md | 1 - 1 file changed, 1 deletion(-) diff --git a/doc/src/manual/noteworthy-differences.md b/doc/src/manual/noteworthy-differences.md index fa37b9f075867..be5c41bc62538 100644 --- a/doc/src/manual/noteworthy-differences.md +++ b/doc/src/manual/noteworthy-differences.md @@ -377,7 +377,6 @@ For users coming to Julia from R, these are some noteworthy differences: * Use `import SomePkg: SubModule.SubSubmodule` (Julia) to access package submodules. * **Directory-based package repositories** (Julia) can be made available by adding repository paths to the `Base.LOAD_PATH` array. - * By default, Julia also treats the current working directory as a type of "package repository". * Packages from directory-based repositories do not require the `pkg> add` tool prior to being loaded with `import` or `using`. They are simply available to the project. * Directory-based package repositories are the **quickest solution** to developping local From 843306d6471ac60f65ccf5b5ede8d27ba4b7004b Mon Sep 17 00:00:00 2001 From: Jameson Nash Date: Tue, 25 Oct 2022 10:54:01 -0400 Subject: [PATCH 6/6] Apply suggestions from code review --- doc/src/manual/noteworthy-differences.md | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/doc/src/manual/noteworthy-differences.md b/doc/src/manual/noteworthy-differences.md index edfc1a5a01c1f..81a36e2e60743 100644 --- a/doc/src/manual/noteworthy-differences.md +++ b/doc/src/manual/noteworthy-differences.md @@ -353,7 +353,7 @@ For users coming to Julia from R, these are some noteworthy differences: ### Julia ⇔ C/C++: Namespaces * C/C++ `namespace`s correspond roughly to Julia `module`s. - * There are no private functions/variables/modules/... in Julia. Everthing is accessible + * There are no private globals or fields in Julia. Everything is publicly accessible through fully qualified paths (or relative paths, if desired). * `using MyNamespace::myfun` (C++) corresponds roughly to `import MyModule: myfun` (Julia). * `using namespace MyNamespace` (C++) corresponds roughly to `using MyModule` (Julia) @@ -371,29 +371,25 @@ For users coming to Julia from R, these are some noteworthy differences: * **Instead of build/`make` scripts**, Julia uses "Project Environments" (sometimes called either "Project" or "Environment"). * Build scripts are only needed for more complex applications - (like those needing to compile, or download C/C++ executables :) ). - * C/C++ code typically target more conventional applications, whereas Julia - "Project Environments" provide a set of packages to experiment with particular problem - spaces. Julia users typically use problem-specific "scripts" for this type of experimentation. - * To develop a "conventional" application/project in Julia, you can initialize its root directory + (like those needing to compile or download C/C++ executables). + * To develop application or project in Julia, you can initialize its root directory as a "Project Environment", and house application-specific code/packages there. This provides good control over project dependencies, and future reproducibility. - * Available packages are added to a "Project Environment" with the `pkg> add` tool + * Available packages are added to a "Project Environment" with the `Pkg.add()` function or Pkg REPL mode. (This does not **load** said package, however). * The list of available packages (direct dependencies) for a "Project Environment" are saved in its `Project.toml` file. * The *full* dependency information for a "Project Environment" is auto-generated & saved - in its `Manifest.toml` file. + in its `Manifest.toml` file by `Pkg.resolve()`. * Packages ("software modules") available to the "Project Environment" are loaded with `import` or `using`. * In C/C++, you `#include ` to get object/function delarations, and link in libraries when you build the executable. - * In Julia, whatever is loaded is available to *all other* loaded modules through its - fully qualified path (no header file required). - * Use `import SomePkg: SubModule.SubSubmodule` (Julia) to access package submodules. + * In Julia, calling using/import again just brings the existing module into scope, but does not load it again + (similar to adding the non-standard `#pragma once` to C/C++). * **Directory-based package repositories** (Julia) can be made available by adding repository paths to the `Base.LOAD_PATH` array. - * Packages from directory-based repositories do not require the `pkg> add` tool prior to + * Packages from directory-based repositories do not require the `Pkg.add()` tool prior to being loaded with `import` or `using`. They are simply available to the project. * Directory-based package repositories are the **quickest solution** to developping local libraries of "software modules". @@ -436,7 +432,7 @@ For users coming to Julia from R, these are some noteworthy differences: | function scope | `function x()` ... `end` | `int x() {` ... `}` | | global scope | `module MyMod` ... `end` | `namespace MyNS {` ... `}` | | software module | A Julia "package" | `.h`/`.hpp` files
+compiled `somelib.a` | -| assembling
software modules | `SomePkg.jl`: ...
`import subfile1.jl`
`import subfile2.jl`
... | `$(AR) *.o` ⇒ `somelib.a` | +| assembling
software modules | `SomePkg.jl`: ...
`import("subfile1.jl")`
`import("subfile2.jl")`
... | `$(AR) *.o` ⇒ `somelib.a` | | import
software module | `import SomePkg` | `#include `
+link in `somelib.a` | | module library | `LOAD_PATH[]`, \*Git repository,
\*\*custom package registry | more `.h`/`.hpp` files
+bigger compiled `somebiglib.a` |