Static_assert: Boost StaticAssert Library for C++

Boost StaticAssert Library

The Boost StaticAssert library provides static assertions for C++, this library is the ancestor to C++ native static_assert's and can be used on older compilers which don't have that feature.

The full documentation is available on boost.org.

Support, bugs and feature requests

Bugs and feature requests can be reported through the Gitub issue tracker (see open issues and closed issues).

You can submit your changes through a pull request.

There is no mailing-list specific to Boost StaticAssert, although you can use the general-purpose Boost mailing-list using the tag [static_assert].

Development

Clone the whole boost project, which includes the individual Boost projects as submodules (see boost+git doc):

git clone https://github.com/boostorg/boost
cd boost
git submodule update --init

The Boost StaticAssert Library is located in libs/static_assert/.

Running tests

First, make sure you are in libs/static_assert/test. You can either run all the tests listed in Jamfile.v2 or run a single test:

../../../b2                        <- run all tests
../../../b2 static_assert_test     <- single test

Overview and Tutorial

Use at namespace scope.

Use at function scope

Use at class scope

Use in templates

The header <boost/static_assert.hpp> supplies two macros:

BOOST_STATIC_ASSERT(x)
BOOST_STATIC_ASSERT_MSG(x, msg)

Both generate a compile time error message if the integral-constant-expression x is not true. In other words, they are the compile time equivalent of the assert macro; this is sometimes known as a "compile-time-assertion", but will be called a "static assertion" throughout these docs. Note that if the condition is true, then the macros will generate neither code nor data - and the macros can also be used at either namespace, class or function scope. When used in a template, the static assertion will be evaluated at the time the template is instantiated; this is particularly useful for validating template parameters.

If the C++0x static_assert feature is available, both macros will use it. For BOOST_STATIC_ASSERT(x), the error message will be a stringized version of x. For BOOST_STATIC_ASSERT_MSG(x, msg), the error message will be the msg string.

If the C++0x static_assert feature is not available, BOOST_STATIC_ASSERT_MSG(x, msg) will be treated as BOOST_STATIC_ASSERT(x).

The material that follows assumes the C++0x static_assert feature is not available.

One of the aims of BOOST_STATIC_ASSERT is to generate readable error messages. These immediately tell the user that a library is being used in a manner that is not supported. While error messages obviously differ from compiler to compiler, but you should see something like:

Illegal use of STATIC_ASSERTION_FAILURE<false>

Which is intended to at least catch the eye!

You can use BOOST_STATIC_ASSERT at any place where you can place a declaration, that is at class, function or namespace scope, this is illustrated by the following examples:

Use at namespace scope.

The macro can be used at namespace scope, if there is some requirement must always be true; generally this means some platform specific requirement. Suppose we require that int be at least a 32-bit integral type, and that wchar_t be an unsigned type. We can verify this at compile time as follows:

#include <climits>
#include <cwchar>
#include <limits>
#include <boost/static_assert.hpp>

namespace my_conditions {

   BOOST_STATIC_ASSERT(std::numeric_limits<int>::digits >= 32);
   BOOST_STATIC_ASSERT(WCHAR_MIN >= 0);

} // namespace my_conditions

The use of the namespace my_conditions here requires some comment. The macro BOOST_STATIC_ASSERT works by generating an typedef declaration, and since the typedef must have a name, the macro generates one automatically by mangling a stub name with the value of __LINE__. When BOOST_STATIC_ASSERT is used at either class or function scope then each use of BOOST_STATIC_ASSERT is guaranteed to produce a name unique to that scope (provided you only use the macro once on each line). However when used in a header at namespace scope, that namespace can be continued over multiple headers, each of which may have their own static assertions, and on the "same" lines, thereby generating duplicate declarations. In theory the compiler should silently ignore duplicate typedef declarations, however many do not do so (and even if they do they are entitled to emit warnings in such cases). To avoid potential problems, if you use BOOST_STATIC_ASSERT in a header and at namespace scope, then enclose them in a namespace unique to that header.

Use at function scope

The macro is typically used at function scope inside template functions, when the template arguments need checking. Imagine that we have an iterator-based algorithm that requires random access iterators. If the algorithm is instantiated with iterators that do not meet our requirements then an error will be generated eventually, but this may be nested deep inside several templates, making it hard for the user to determine what went wrong. One option is to add a static assertion at the top level of the template, in that case if the condition is not met, then an error will be generated in a way that makes it reasonably obvious to the user that the template is being misused.

#include <iterator>
#include <boost/static_assert.hpp>
#include <boost/type_traits.hpp>

template <class RandomAccessIterator >
RandomAccessIterator foo(RandomAccessIterator from,
                         RandomAccessIterator to)
{
   // this template can only be used with
   // random access iterators...
   typedef typename std::iterator_traits<
         RandomAccessIterator >::iterator_category cat;
   BOOST_STATIC_ASSERT(
      (boost::is_convertible<
         cat,
         const std::random_access_iterator_tag&>::value));
   //
   // detail goes here...
   return from;
}

A couple of footnotes are in order here: the extra set of parenthesis around the assert, is to prevent the comma inside the is_convertible template being interpreted by the preprocessor as a macro argument separator; the target type for is_convertible is a reference type, as some compilers have problems using is_convertible when the conversion is via a user defined constructor (in any case there is no guarantee that the iterator tag classes are copy-constructible).

Use at class scope

The macro is typically used inside classes that are templates. Suppose we have a template-class that requires an unsigned integral type with at least 16-bits of precision as a template argument, we can achieve this using something like this:

#include <limits>
#include <boost/static_assert.hpp>

template <class UnsignedInt>
class myclass
{
private:
   BOOST_STATIC_ASSERT_MSG(std::numeric_limits<UnsignedInt>::is_specialized, "myclass can only be specialized for types with numeric_limits support.");
   BOOST_STATIC_ASSERT_MSG(std::numeric_limits<UnsignedInt>::digits >= 16, "Template argument UnsignedInt must have at least 16 bits precision.")
   BOOST_STATIC_ASSERT_MSG(std::numeric_limits<UnsignedInt>::is_integer, "Template argument UnsignedInt must be an integer.");
   BOOST_STATIC_ASSERT_MSG(!std::numeric_limits<UnsignedInt>::is_signed, "Template argument UnsignedInt must not be signed.");
public:
   /* details here */
};

Use in templates

Normally static assertions when used inside a class or function template, will not be instantiated until the template in which it is used is instantiated. However, there is one potential problem to watch out for: if the static assertion is not dependent upon one or more template parameters, then the compiler is permitted to evaluate the static assertion at the point it is first seen, irrespective of whether the template is ever instantiated, for example:

template <class T>
struct must_not_be_instantiated
{
   BOOST_STATIC_ASSERT(false);
};

Will produce a compiler error with some compilers (for example Intel 8.1 or gcc 3.4), regardless of whether the template is ever instantiated. A workaround in cases like this is to force the assertion to be dependent upon a template parameter:

template <class T>
struct must_not_be_instantiated
{
   // this will be triggered if this type is instantiated
   BOOST_STATIC_ASSERT(sizeof(T) == 0);
};

Documentation

---

Author: boostorg
Source code: https://github.com/boostorg/static_assert
License: 

#cpluplus 

What is GEEK

Buddha Community

How to Run C/C++ in Sublime Text?

C and C++ are the most powerful programming language in the world. Most of the super fast and complex libraries and algorithms are written in C or C++. Most powerful Kernel programs are also written in C. So, there is no way to skip it.

In programming competitions, most programmers prefer to write code in C or C++. Tourist is considered the worlds top programming contestant of all ages who write code in C++.

During programming competitions, programmers prefer to use a lightweight editor to focus on coding and algorithm designing. Vim, Sublime Text, and Notepad++ are the most common editors for us. Apart from the competition, many software developers and professionals love to use Sublime Text just because of its flexibility.

I have discussed the steps we need to complete in this blog post before running a C/C++ code in Sublime Text. We will take the inputs from an input file and print outputs to an output file without using freopen file related functions in C/C++.

#cpp #c #c-programming #sublimetext #c++ #c/c++

Dicey Issues in C/C++

If you are familiar with C/C++then you must have come across some unusual things and if you haven’t, then you are about to. The below codes are checked twice before adding, so feel free to share this article with your friends. The following displays some of the issues:

1. Using multiple variables in the print function
2. Comparing Signed integer with unsigned integer
3. Putting a semicolon at the end of the loop statement
4. C preprocessor doesn’t need a semicolon
5. Size of the string matters
6. Macros and equations aren’t good friends
7. Never compare Floating data type with double data type
8. Arrays have a boundary
9. Character constants are different from string literals
10. Difference between single(=) and double(==) equal signs.

---

The below code generates no error since a print function can take any number of inputs but creates a mismatch with the variables. The print function is used to display characters, strings, integers, float, octal, and hexadecimal values onto the output screen. The format specifier is used to display the value of a variable.

1. %d indicates Integer Format Specifier
2. %f indicates Float Format Specifier
3. %c indicates Character Format Specifier
4. %s indicates String Format Specifier
5. %u indicates Unsigned Integer Format Specifier
6. %ld indicates Long Int Format Specifier

---

A signed integer is a 32-bit datum that encodes an integer in the range [-2147483648 to 2147483647]. An unsigned integer is a 32-bit datum that encodes a non-negative integer in the range [0 to 4294967295]. The signed integer is represented in twos-complement notation. In the below code the signed integer will be converted to the maximum unsigned integer then compared with the unsigned integer.

#problems-with-c #dicey-issues-in-c #c-programming #c++ #c #cplusplus

Boost.GIL: Generic Image Library | Requires C++14 Since Boost 1.80

 

Documentation	GitHub Actions	AppVeyor	Azure Pipelines	Regression	Codecov

Boost.GIL

• Introduction
• Documentation
• Requirements
• Branches
• Community
• Contributing
• License

Introduction

Boost.GIL is a part of the Boost C++ Libraries.

The Boost Generic Image Library (GIL) is a C++14 header-only library that abstracts image representations from algorithms and allows writing code that can work on a variety of images with performance similar to hand-writing for a specific image type.

Documentation

• Latest release
• Branch master (latest release with minor changes)
• Branch develop

See RELEASES.md for release notes.

See CONTRIBUTING.md for instructions about how to build and run tests and examples using Boost.Build or CMake.

See example/README.md for GIL usage examples.

See example/b2/README.md for Boost.Build configuration examples.

See example/cmake/README.md for CMake configuration examples.

Requirements

The Boost Generic Image Library (GIL) requires:

• C++14 compiler (GCC 6, clang 3.9, MSVC++ 14.1 (1910) or any later version)
• Boost header-only libraries

Optionally, in order to build and run tests and examples:

• Boost.Filesystem
• Boost.Test
• Headers and libraries of libjpeg, libpng, libtiff, libraw for the I/O extension and some of examples.

Branches

The official repository contains the following branches:

master This holds the most recent snapshot with code that is known to be stable.

develop This holds the most recent snapshot. It may contain unstable code.

Community

There is number of communication channels to ask questions and discuss Boost.GIL issues:

• GitHub Discussions
• Mailing lists (Boost discussion policy)
  • boost-gil (recommended) official Boost.GIL mailing list (archive)
  • boost-users for all Boost users
  • boost for all Boost developers
• Slack at cpplang.slack.com with Boost channels:
  • #boost-gil (recommended) official Boost.GIL channel
  • #boost-user for all Boost users
  • #boost for all Boost developers
• Gitter room boostorg/gil (old real-time chat space)
• You can also ask questions via GitHub issue.

Contributing (We Need Your Help!)

If you would like to contribute to Boost.GIL, help us improve the library and maintain high quality, there is number of ways to do it.

If you would like to test the library, contribute new feature or a bug fix, see the CONTRIBUTING.md where the whole development infrastructure and the contributing workflow is explained in details.

You may consider performing code reviews on active pull requests or help with solving reported issues, especially those labelled with:

• status/need-help
• status/need-feedback
• need-minimal-example

Any feedback from users and developers, even simple questions about how things work or why they were done a certain way, carries value and can be used to improve the library.

License

Distributed under the Boost Software License, Version 1.0.

---

Author:  boostorg
Source code: https://github.com/boostorg/gil
License: BSL-1.0 license

#cpluplus 

C# Source Generators to boost performance in .NET 5

A new C# compiler feature that inspects code and generates additional source files promises to improve performance in a number of scenarios.

Microsoft has introduced a preview of a C# compiler capability called Source Generators that can inspect a program and generate source files that can be added to a compilation. Microsoft says Source Generators can improve performance in a number of scenarios.

Introduced April 29, a Source Generator is a piece of code (a .NET Standard 2.0 assembly) that runs during compilation and can inspect a program to produce additional files that are compiled together with the rest of the code.

#c #c# #c++ #programming-c

How to solve the implicitly declaring library function warning in C

Learn how to solve the implicitly declaring library function warning in C

#c #c# #c++ #programming-c