Home » Blog » Categories »

POCO Release 1.8.0 Available

By Alex Fabijanic | Nov 10, 2017 01:18 PM | Tags: None

POCO 1.8.0 is now available:

POCO Release 1.8.0 is out

by POCO Team

POCO C++ Libraries release 1.8.0 is available. This release brings Unix Domain Socket support in the Net library, Zip64 support in the Zip library, an XML stream parser API, the new Redis client library, support for connection string URIs in the MongoDB client library and a couple of other improvements and bugfixes.

In addition to optional C++11/14 features support, this release still supports C++03 compilers, including Visual C++ 2008. Support for OpenVMS has been removed. Full C++11/14 support coming soon in release 2.0.

 

Quick Q: What does the explicit keyword mean?

By Adrien Hamelin | Nov 9, 2017 02:46 PM | Tags: basics

Quick A: It tell the compiler not to do any implicit conversions of types.

Recnetly on SO:

What does the explicit keyword mean?

The compiler is allowed to make one implicit conversion to resolve the parameters to a function. What this means is that the compiler can use constructors callable with a single parameter to convert from one type to another in order to get the right type for a parameter.

Here's an example class with a constructor that can be used for implicit conversions:

class Foo
{
public:
  // single parameter constructor, can be used as an implicit conversion
  Foo (int foo) : m_foo (foo)
  {
  }

  int GetFoo () { return m_foo; }

private:
  int m_foo;
};

Here's a simple function that takes a Foo object:

void DoBar (Foo foo)
{
  int i = foo.GetFoo ();
}

and here's where the DoBar function is called.

int main ()
{
  DoBar (42);
}

The argument is not a Foo object, but an int. However, there exists a constructor for Foo that takes an int so this constructor can be used to convert the parameter to the correct type.

The compiler is allowed to do this once for each parameter.

Prefixing the explicit keyword to the constructor prevents the compiler from using that constructor for implicit conversions. Adding it to the above class will create a compiler error at the function call DoBar (42). It is now necessary to call for conversion explicitly with  DoBar (Foo (42))

The reason you might want to do this is to avoid accidental construction that can hide bugs. Contrived example:

  • You have a MyString(int size) class with a constructor that constructs a string of the given size. You have a function print(const MyString&), and you call print(3) (when you actually intended to call print("3")). You expect it to print "3", but it prints an empty string of length 3 instead.

Enforcing code contracts with [[nodiscard]]

By bfilipek | Nov 7, 2017 10:43 AM | Tags: None

More details about a new C++17 attribute

Enforcing code contracts with [[nodiscard]]

by Bartlomiej Filipek

From the article:

[[nodiscard]] is an excellent addition to all the important code: public APIs, safety-critical systems, etc. Adding this attribute will at least enforce the code contract. The compiler will help you detect bugs - at compile time, rather than finding in in the runtime.

C++ User Group Meetings in November

By Meeting C++ | Nov 2, 2017 07:25 AM | Tags: usergroups meetingcpp community

The monthly overview on upcoming C++ User Group Meetings...

C++ User Group Meetings in November

by Jens Weller

From the article:

The monthly overview on upcoming C++ User Group Meetings! With next weeks Meeting C++ 2017 conference, many members of the new and established C++ User Groups will meet in Berlin! I hope to motivate again many visiting folks to start attending a near by C++ User Group, or to start their own User Group, if it does not yet exist.

There are 5 new C++ User Groups: Core C++, Israel, Brisbane, Moscow, Lissabon, Canterbury...

Common C++ Modules TS Misconceptions -- Boris Kolpackov

By Blog Staff | Nov 1, 2017 11:06 AM | Tags: None

boris-kolpackov.PNGAn illuminating "mini-FAQ" on a very current major feature progressing in ISO C++:

Common C++ Modules TS Misconceptions

by Boris Kolpackov

From the article:

It has become fashionable to criticize C++ Modules TS. My problem with this bandwagon criticism is that at best it's based on cursory reading of the specification but more commonly on just hearing others' knee-jerk reactions. Oftentimes the criticizing post cannot even get the terminology right. So in this article I would like to refute the most common Modules TS misconceptions...

  • I cannot have everything in a single file
  • I cannot export macros from modules
  • I cannot modularize existing code without touching it
  • No build system will be able to support modules

Better code understanding with Sourcetrail -- Bartlomiej Filipek

By bfilipek | Oct 31, 2017 11:54 PM | Tags: None

Let's have a look at Sourcetrail, a great tool for code (C++/Java) visualtiozation:

Better code understanding with Sourcetrail

by Bartlomiej Filipek

From the article:

I’m exploring the tool, and overall I am impressed! It works very well; the setup is easy to do, there’s a lot of help, beautiful and dynamic diagrams (even with smooth animations), under active development… what else would I want? smile

The C++ Bestiary -- Adi Shavit

By Adi | Oct 31, 2017 11:52 PM | Tags: None

Need some last minute Halloween costume inspiration?

The C++ Bestiary ��

by Adi Shavit

From the article:

C++ is blessed with a plethora of gotchas, traps, caveats, pitfalls and footguns. Within the C++ dungeons lurk many shady characters. ‘Tis the time of year to meet some of these bountifully spawned beasts.