JASL
[1.2.0]-2018-09-11
|
This repository contains C++** string classes with **static character array/C-string support.
Sometimes we would like to use hardwired text resources. For example throwing an exception where the message is user specified. Just like in case of std::runtime_error the message (const char* parameter named what_arg) is "typically stored internally", which means the parameter will be copied. But usually users use it like std::runtime_error("Coyote catched the Roadrunner!")
or std::runtime_error(__FILE__)
where the what_arg is actually a a hardwired text. In this cases the copying seems unnecessary.
Creating your own exception and using this library's jasl::static_string class will eliminate the unnecessary copy in a type-safe way. For example the compiler will generate an error in case of the following situation:
Continuing the previous example: What if we occasionally want to use the dynamic string, but in the majority of the cases we would like to use static string. The jasl::string class supposed to give a solution for this situation. Check the example:
This is a header-only library. Add the include
directory to your include directories.
Note: For building and running tests see Tests, Test Coverage and Performance Tests
This is a header-only library containing
classes.
Location: include
directory.
Pros:
Cons:
>Evaluating a string-literal results in a string literal object with static storage duration, initialized from the given characters as specified above. Source
Note: cppreference - literal types
PATH
environment variable.There is a build/build_helper.py
script. If it is called with --install
parameter, it will download the gn and ninja.
Once again: One doesn't have to deal with this. It is only for those who would like to see the test results themselves. (I've chosen https://chromium.googlesource.com/chromium/src/+/master/tools/gn/README.md "gn" because I wanted to understand and learn the technology a bit.)
After https://chromium.googlesource.com/chromium/src/+/master/tools/gn/README.md "gn" and ninja is installed it is easy (hopefully). Typically the output directory is inside the out
directory (which is part of the repo, but empty now). From command line from the project's root directory:
This will create a directory inside out
and generate the ninja files. It's time to build:
And we are done. This built and run the tests too.
There is a more build options for example:
These can be set by calling
and then editing the file which was opened.
For detailed options:
Following the previous steps will also run the tests. The test binaries are in the out directory (example: out/default) if someone would like to rerun them.
Source location: test/*.test.cpp
The project contains semantic error tests too. (For examples see section Motivation) These tests are also run by the building process.
Source location: test/*.test_build_err.cpp.c
.
Note: This files have a _.c_ extension. This is how gn can differentiate between the building commands. It is necessary because we expect a building error in case of these files.
In case of is_generate_test_coverage=true
gn argument the building will generate html code coverage reports. Works with clang.
Location of the test coverage results: out/<outdir>/*.coverage
directories.
Note: The coverage report is not perfect.
For example in case of the jasl::static_string's coverage report the jasl::string_view file's coverage is irrelevant. Also because of some function is constexpr
the compiler does its work and executes the code at compile time. In this case the method may seems uncovered. Another problem with the coverage is that the library's classes contain templates and the the C++ compilers only instantiate those which are used, the unused ones are not instatiated so those won't be seen in the report as an uncovered code.
Note: Generating coverage report with gcc is also works, but it only generates raw data.
Performance tests are compiled by the building process, but it won't run them.
After building, the performance binaries are in the out directory and they are ready to be run.
Source location: test/*.performance.cpp
JASL version: 1.0.0-beta (2018-07-19)
This performance test compares construction and destruction of the jasl::static_string and the jasl::string to std::string.
Parameters:
( sizeof(short_string_array), sizeof(long_string_array) ) := ( 6, 150 )
Remarks: The results depend on the size of the character array given to the std::string's constructor.
Hardware:
NOTE: Base type of the jasl::static_string and jasl::string is jasl::string_view.
Travis and Appveyor build and run the tests with more compiler than the following list.
JASL library uses the [MIT](LICENSE) license.