rapptz/gears

C++ Utilities

gears's Issues

functional

A module that would contain functional things such as currying, higher-ordered functions and maybe some LINQ-like stuff. Probably based on Lia but improved upon or changed to match the API.

String utilities

Things that help with std::basic_string like:

Algorithms

• trim, trim_left, trim_right, etc
• join
• split
• left, right
• reverse
• iequal, istart_with, iend_with, start_with, end_with, all, contains, etc
• replace_first, replace_last, replace_nth, replace_all
• erase_first, erase_last, erase_nth, erase_all
• find_first_of, first_last_of, etc.
• to_upper, to_lower, etc

Classifications

• Regular classifications based on locale.

String Builder

• _s literal provided to ease building of std::string.
• String builder helper class (wrapper around std::stringstream).

Add a variant data type.

Another homage to Boost. This time a C++11 aware variant. I'm leaning on putting this under the utility module. Having it in its own module would be conflicting with the current naming standards set in, as it'd make it gears::variant::variant which is awfully redundant. An exception to the rule could be made so it'd end up being gears::variant but I'm not too convinced.

Meta Programming

Basic meta programming module that contains the following:

• Actual type traits
• Meta functions
• Aliases to common type traits.
• Indices
• Expand variadic templates

A better type list.

std::tuple is a poor man's type list. A better alternative should exist in gears. Maybe called gears::meta::list which would be similar to boost::mpl::vector I suppose.

Process and Cross Platform Utilities.

It might be a good idea to have a new module, i.e. system, that would handle certain cross platform things such as process IDs, subprocess, etc. At the moment I'm not too keen on the idea but it's worth thinking about in the future.

Various issues in fprint.

There are a lot of unnecessary null checks in fprint.h, for example (not all):

Gears/gears/io/fprint.hpp

Line 37 in c04125d

while(*str && (*str >= zero && *str <= zero + 9)) {

Gears/gears/io/fprint.hpp

Line 101 in c04125d

if(*str && Trait::eq(*str, out.widen(':'))) {

Potential issue: format string is totally ignored if no additional arguments were passed. You mentioned this was by design, but I strongly recommend you to reconsider it as it potentially breaks generic code that relies on fprint, and if a user really wants the faster "unformatted formatting" they can always resort to just calling out << str .

Doc issue: format-string is a confusing identifier in your grammar since you have the format string, containing literal text and format-strings. See the issue? I suggest taking over Pythons terminology and calling it a "replacement field".

Critical issue: formatting is not stateless, as you do not correctly set default fill parameters, and they can carry over from replacement field to replacement field. For example: https://gist.github.com/orlp/a0aba247345baaf8c393 I only checked this for fill, but the same probably applies to precision, align, width and potentially more.

Checking issue: you do not check if an integer came after the dot in ["." precision]. An example invalid format string that you do not throw an exception on is |:.|

Missing feature: std::hexfloat - you said GCC didn't support this, but I list it here for completion anyway.

Missing feature: std::showpoint - I suggest changing p to std::showpoint and assigning + to std::showpos.

For ideas of how I solved some of these problems/set up my solution see https://github.com/orlp/libop/blob/master/bits/io.h .

Unit tests and travis-ci

Set up some unit tests and link it to travis-ci.

Use subnamespacing

Subnamespacing will be ideal for the following reasons:

1. It allows the use of shortcuts such as namespace gx = gears::stuff;
2. Following reason one, it allows the use of using namespace gears::stuff without dragging the entire gears namespace.
3. It allows for duplicate names. e.g. gears::modone::f(10) would be different from gears::modtwo::f(10).

Current plans would be to have this be consistent with the module it's imported in. e.g. in the strings module everything would be gears::string

Subnamespacing is already in use with gears::literals and gears::operators. Changes would have to include deeper subnamespacing, e.g. gears::string::literals and gears::string::operators.

This follows the convention of Boost.

Any

A form of type erasure.

Maybe<T> fixes

maybe<T> should undergo the same process that happened with Gears.Meta. A rename to fit the standard amongst other things. This is a breaking change.

• Rename maybe<T> to optional<T>
• Rename nothing to nullopt
• Rename just to make_optional
• Allow optional<T&>
• Allow optional<optional<T>>

Crash with optparse when using long option names

There's a crash when you do --help with the default formatter due to bad handling of indentation.

The code does something like this:

auto&& max_name = std::max_element(opts.begin(), opts.end(), [](const option& lhs, const option& rhs) {
    return lhs.name < rhs.name;
});

But this just gets the maximum in terms of lexicographical order, so e.g. verbose will be higher than myreallylongname due to the lexicographical comparison.

The fix is simple, just use lhs.name.size() to get the actual size instead.

The Great Rename of Meta

This is a breaking change.

Since C++14 got accepted, the (unfortunate) naming of template aliases has been standardised and it's best to be consistent with the standard. I propose the following renames:

• Type<T> -> eval<T>
• All template aliases will go from PascalCase to snake_case_t
• And -> all
• Or -> any
• Not -> negate
• If -> if_
• LazyIf -> lazy_if
• Const -> constant
• Integer -> integer
• Metafunctions etc turned from PascalCase to snake_case.
• Make indices follow the C++14 standard naming.

PascalCase should be reserved for concepts only.

Clean up concepts

At the moment, the concepts module is pretty messy. Lots of small traits that compose, some aren't exactly right, many are just ThisCase version of existing type traits without actually being part of the concept. Maybe it's time to clean up concepts into something a little more sane. People using the library have no sane way of defining their own traits as the documentation is scarce and only the provided ones are sane enough to use. Building blocks would be nice to have to maul over the impending release of C++1z.

Change the way includes are done

At the moment I do #include "../stuff/file.hpp" when I should be using #include <gears/stuff/file.hpp> instead. single.py will have to be modified to take this into account too.

operators

Modernisation of Boost.Operators with no compiler work-arounds and possibly (somehow?) constexpr. Sub-namespacing is another problem with this one, albeit minor. At the moment the sub-sub-namespace operators is used for operators to inject to the global namespace. This shouldn't be an issue with the sub-namespace though.

Chrono stuff

Stuff for <chrono>.

Such as:

• stopwatch class
• literals to aid with creation

Maybe in the future there will be more in the Chrono module, but as of now that's all there is.

maybe<T>

Something to represent an optional value I suppose. It's similar to Boost.Optional but not really since it'll disallow references. This will be part of C++14 soon but it's a good addition to gears.

Documentation

One of the first things I have wanted to do when remaking Gears was to provide documentation as I went along, however this didn't happen. By the time I get around to Issue #11 documentation will probably be worked on. It'll use Doxygen.

Clean up meta.

At the moment, the meta module is really messy. Everything is lodged into alias.hpp or meta.hpp with little to no in between.

Possible solutions that are open to consideration:

• Make every meta function into its own header, e.g. if.hpp, and.hpp, etc.
• Better grouping of meta functions.
• Better documentation for the meta module.

Concepts

Basic

• Movable, MoveAssignable, etc
• Copyable, etc
• POD, StandardLayout
• Constructible, etc
• Assignable
• ContextualBool
• Integral, Arithmetic, FloatingPoint
• Unsigned, Signed
• Pointer, LValueReference RValueReference
• Fundamental, Compound, Reference
• EqualityComparable
• LessThanComparable
• NullablePointer
• Comparable
• Regular
• Semiregular
• Dereferenceable
• Incrementable
• Decrementable

Iterator

• RandomAccessIterator
• MutableRandomAccessIterator
• ForwardIterator
• MutableForwardIterator
• OutputIterator
• BidirectionalIterator
• MutableBidirectionalIterator
• InputIterator
• Iterator

Function

• Function
• Callable
• Generator
• Predicate
• UnaryFunction
• BinaryFunction
• UnaryPredicate
• BinaryPredicate

Container

• Container
• ReversibleContainer
• AssociativeContainer
• UnorderedAssociativeContainer
• SequenceContainer
• AllocatorAware
• Allocator

Format stuff

Such as:

• print formats
• format strings
• scan formats

Math utilities

Math stuff:

Algorithms

• Prime stuff
• fibonacci
• factorial
• gcd, sum_of_divisors, etc

High Precision Integer

• Specify bits in template parameter or -1 for "infinite" precision
• Can specify the Digit and Digits template parameter
• Addition, increment
• Subtraction, decrement
• Division
• Multiplication
• Comparisons
• Modulus

Mathematical Constants

• Templated constants without the use of variable templates (e.g. pi<double>())
• Variable precision depending on the template given.

Iterators

Itertools!

Inspired by a post on reddit and just something I've generally always wanted to do.

Based on these itertools. But here they are for listing sakes.

Infinite

• count
• cycle
• repeat

Functional

• chain
• drop_while
• take_while
• group_by
• filter
• slice
• map
• zip
• zip_longest

Miscellaneous

• lines
• keys
• values
• enumerate

Improve documentation.

I'm not really satisfied with the way documentation is done. There isn't too much I could do since it's Doxygen. Doxygen makes a separate page for every struct and class so it doesn't work very well for documentation of metaprogramming facilities. Something like how Boost.MPL does its documentation might be better.

Some ideas to throw around to improve meta documentation:

• Describe what an integral constant is, i.e. std::integral_constant.
• Describe a metafunction. Higher-ordered stuff, things that return either ::type or ::value.
• Consistent use of vocabulary.

Migrate from SCons to Ninja

SCons is a bit of a pain in the ass. I've migrated everything else to ninja, and might as well do it for Gears too.

Implement Filesystem TS

The C++14 Filesystem TS has been published. That means it's probably a good time to make an implementation of it. The TS could be found here.

Program Options

Command line parsing utility. Something akin to Boost.ProgramOptions except in modern C++11.

Containers

Containers that are useful would be nice to have. The new module could also contain utilities that aid the usage of the C++ standard containers, such as allocators.

General Requirements

• Allocator aware (for some anyway).
• Meet SequenceContainer requirement set forth by the C++11 standard.
• Exception safety guarantee similar to std::vector.

Containers

• static_vector
• flat_set
• flat_map