Null Pointer Dereferencing Causes Undefined Behavior

I have unintentionally raised a large debate recently concerning the question if it is legal in C/C++ to use the &P->m_foo expression with P being a null pointer. The programmers' community divided into two camps. The first claimed with confidence that it wasn't legal while the others were as sure saying that it was. Both parties gave various arguments and links, and it occurred to me at some point that I had to make things clear.

Null Pointer Dereferencing Causes Undefined Behavior

by Andrey Karpov

From the article:

This code is incorrect in both C and C++ when the podhd pointer equals 0. If the pointer equals 0, undefined behavior occurs.

 

Cppcheck

I wish to introduce the CppCheck tool to the beginner programmers. Cppcheck is a static analyzer for C and C++ code. It is open-source, free, cross-platform and easy-to-use.

Cppcheck

by Andrey Karpov

From the article:

One of the basic advantages of the Cppcheck analyzer is that it is easy-to-use. It is good to teach and study the static analysis methodology: for instance, you install Cppcheck on a Windows system and get a GUI interface allowing you to immediately start checking your projects.

JSON Voorhees - Killer JSON for C++--Travis Gockel

Yet another JSON library for C++:

JSON Voorhees, GitHub link

by Travis Gockel

From the article:

JSON Voorhees is a JSON library written for the C++ programmer who wants to be productive in this modern world. What does that mean? There are a ton of JSON libraries floating around touting how they are "modern" C++ and so on. But who really cares? JSON Voorhees puts the focus more on the resulting C++ than any "modern" feature set. This means the library does not skip on string encoding details like having full support for UTF-8. Are there "modern" features? Sure, but this library is not meant to be a gallery of them – a good API should get out of your way and let you work. It is hosted on GitHub and sports an Apache License, so use it anywhere you need...

Iterators++, Part 2 -- Eric Niebler

Eric Niebler goes deeper into Iterator details in his new blog post

 

Iterators++, Pat 2

by Eric Niebler

From the article:

This is the third in a series about proxy iterators, the limitations of the existing STL iterator concept hierarchy, and what could be done about it. In the first post I explained what proxy iterators are (an iterator like vector<bool>‘s that, when dereferenced, returns a proxy object rather than a real reference) and three specific difficulties they cause in today’s STL:

  1. What, if anything, can we say in general about the relationship between an iterator’s value type and its reference type?
  2. How do we constrain higher-order algorithms like for_each and find_if that take functions that operate on a sequence’s elements?
  3. How do we implement algorithms that must swap and move elements around, like sort and reverse?

C++17 Library Papers for Cologne

The first part of a mini series about the Library Papers for the LWG Meeting in Cologne:

C++17 Library Papers for Cologne

by Jens Weller

From the article:

Last fall I did the last series about the Standardization papers for C++. I didn't had the time to finish the last part for the Library subgroup, as Meeting C++ 2014 was getting close too. I'll be attending the next meeting of the Library Working Group in Cologne, which is just a few days away, so I'll do a miniseries for the LWG papers...

Default Constructed Return Value: return {} -- Adi Shavit

Simplify your code using a default constructed return value with `return {}`:

Default Constructed Return Value: return {}

by Adi Shavit

From the article:

It is common for C/C++ functions to return default values, for example, if some internal condition fails.
This is straightforward for native return types. This pattern is often seen in factory methods or functions that return a polymorphic type via a base handle.

If the function has multiple early return points, this default construction needs to be repeated at each such point and each time stating the explicit return type just for calling the default ctor. This is annoying because the compiler already knows the return type.

CppCon 2014 Persisting C++ Classes in Relational Databases with ODB--Boris Kolpackov

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Persisting C++ Classes in Relational Databases with ODB

by Boris Kolpackov

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

ODB is an open source, cross-platform and cross-database (SQLite, PostgreSQL, MySQL, MS SQL Server, Oracle) object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL, and without manually writing any mapping code.

In the first part of this two-part talk we will cover the basics of transactionally persisting, loading, updating, and deleting simple C++ classes in a database as well as querying the database for objects. We will then look into persisting C++ classes that have more interesting data members, such as containers and pointers to objects, or that form a polymorphic hierarchy. Support for C++11, Qt, and Boost value types, containers, and smart pointers will also be covered.

Targeting 5 different database systems at the same time may sound like a daunting task but as we will see it is not that hard with ODB. Life would also be a lot easier if our C++ classes never changed. The next best thing is to have comprehensive tooling support. So we will conclude the first half with a discussion of database schema evolution and its support in ODB.

Ranges and Iterators for numerical problems

A guest blog post by Karsten Ahnert at Meeting C++ as a follow up of his talk!

Ranges and Iterators for numerical problems

by Karsten Ahnert

From the article:

In this blog post I am going to show some ideas how one can implement numerical algorithms with ranges. Examples are the classical Newton algorithm for finding the root of a function and ordinary differential equations. The main idea is to put the main loop of the algorithm into range such that the user can...

ODB C++ ORM 2.4.0 Released, Adds Bulk Operations Support

ODB C++ ORM 2.4.0 Released, Adds Bulk Operations Support

by Boris Kolpackov

ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code.

Major new features in this release:

  • Support for bulk operations in Oracle and SQL Server. Bulk operations can be used to persist, update, or erase a range of objects using a single database statement execution which often translates to a significantly better performance.
  • Ability to join and load one or more complete objects instead of, or in addition to, a subset of their data members with a single SELECT statement execution (object loading views).
  • Support for specifying object and table join types in views (LEFT, RIGHT, FULL, INNER, or CROSS).
  • Support for calling MySQL and SQL Server stored procedures.
  • Support for defining persistent objects as instantiations of C++ class templates.

A more detailed discussion of these features can be found on the blog. For the complete list of new features in this version see the official release announcement.

ODB is written in portable C++ (both C++98/03 and C++11 are supported) and you should be able to use it with any modern C++ compiler. In particular, we have tested this release on GNU/Linux (x86/x86-64/ARM), Windows (x86/x86-64), Mac OS X (x86/x86_64), and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-5.x, MS Visual C++ 2005, 2008, 2010, 2012, and 2013, Sun Studio 12u2, and Clang 3.x.

The currently supported database systems are MySQL, SQLite, PostgreSQL, Oracle, and SQL Server. ODB also provides optional profiles for Boost and Qt, which allow you to seamlessly use value types, containers, and smart pointers from these libraries in your persistent classes.

More information, documentation, source code, and pre-compiled binaries are available on the project's page.

How do I write complex initialization?--Stack Overflow

Quick A: Initialize it using a lambda that’s invoked immediately.

Recently on SO:

Best practice for declaring variable without initialising it, so auto is unavailable

I want to declare two variables of the same type, and have the compiler figure out the types. However I don't want to initialise one of the variables until later. I don't think I can use auto here, so what's the best option?

std::vector<int> v;

// `start` and `end` should be the same type
auto start = v.begin();
??? end;

// complicated code to assign a value to `end` (i.e. putting
// the code in a function or using ?: is not practical here) 
if (...) {
    end = ...;
} else {
    end = v.end();
}

What's the best way to tell the compiler that end should be the same type as start, but without having to initialise the variable?

auto start = v.begin(), end;  // Doesn't work, `end` has to be initialised
decltype(start) end;          // Does work, but not sure if it's best practice

Update

A couple of comments have suggested ways that would work in certain situations, so I am clarifying my situation here:

std::vector<int> v;
int amount = 123;

// `start` and `end` should be the same type
auto start = v.begin();
??? end;

// code to assign a value to `end`
if (amount) {
    end = start + amount;
    amount = 0;
} else {
    end = v.end();
}

I believe a lamda function would be trickier here, because amount is being reset to 0 after end is calculated, so in a lamda function that calculates a value for end, amount = 0 would have to come after the return statement. The only option would be to create more local variables, which would incur an (admittedly tiny) performance penalty.