News

Make your C++ voice heard! Cross-industry survey from the VC++ team

The VC++ team is asking for your perspectives, whichever compiler you're using and whatever platform you're targeting:

Make your C++ voice heard! Cross-industry survey from the VC++ team

C++ is evolving, and so are our plans around it here at Microsoft. Recent investments by our team include the new cross-platform Visual Studio Code editor, CMake and Linux support in Visual Studio, a C++ language service which, when editing, can match your C++ compiler of choice, and support for remote debugging on any platform.

We would like to hear from you on what are your next set of challenges. Please take our survey to help shape our cross-platform C++ plans

Italian C++ Conference 2018: Call for papers and Call for sponsors--Marco Arena

The Italian C++ Conference is back:

Italian C++ Conference 2018: Call for papers and Call for sponsors

June 23, Milan

The Italian C++ Conference is the biggest event in Italy on C++ development, where professionals, companies and students meet and share experience. The conference is free and organized by the Italian C++ Community.
For an overview of the previous edition, including statistics and technical contents, read the wrap-up post.

 

Submit your talk by March 24!

We accept talk proposals in both English and Italian. One track will be in English.

Read here and submit your proposal

 

Call for sponsors

Since the event is free to attend, sponsors will cover the main consts. If you are interested in sponsoring the biggest and most important event about C++ development in Italy, please get in touch.

 

Next steps, agenda and registrations

After March 24, attendees from our past events, Italian C++ Community staff, and this year speakers will be involved in a voting process. Decisions will be sent to speakers by April 17.

The registrations will open in April and the agenda will be published ~2 months before the event date.

CopperSpice: Threads and Containers

New videos on the CopperSpice YouTube Channel:

Modern C++ Threads

by Barbara Geller and Ansel Sermersheim

About the video:

An overview of the C++11 threading library, including a discussion of why the C++11 memory model is so important. We also present information about atomics and the abstraction of multithreaded design.

What's in a container?

by Barbara Geller and Ansel Sermersheim

About the video:

A practical look at how containers are implemented in C++, including a discussion of when you should implement your own container, the potential pitfalls of hand-rolled containers, why Copy-On-Write is a bad idea and disallowed for containers in the standard library, and how to implement your own container adapters.

Please take a look and remember to subscribe!

Quick Q: Direct initialization with empty initializer list

Quick A: If there is an initializer list contructor, it will choose it.

Recently on SO:

Direct initialization with empty initializer list

When an argument is an initializer list ([dcl.init.list]), it is not an expression and special rules apply for converting it to a parameter type.

If the parameter type is std::initializer_list or “array of X” and all the elements of the initializer list can be implicitly converted to X, the implicit conversion sequence is the worst conversion necessary to convert an element of the list to X. This conversion can be a user-defined conversion even in the context of a call to an initializer-list constructor.

Otherwise, if the parameter is a non-aggregate class X and overload resolution per [over.match.list] chooses a single best constructor of X to perform the initialization of an object of type X from the argument initializer list, the implicit conversion sequence is a user-defined conversion sequence. If multiple constructors are viable but none is better than the others, the implicit conversion sequence is the ambiguous conversion sequence. User-defined conversions are allowed for conversion of the initializer list elements to the constructor parameter types except as noted in [over.best.ics].

Quick Q: Uses of destructor = delete;

Quick A: If you have an object which should never, ever be deleted or stored on the stack (automatic storage), or stored as part of another object, =delete will prevent all of these.

Recently on SO:

Uses of destructor = delete;

struct Handle {
  ~Handle()=delete;
};

struct Data {
  std::array<char,1024> buffer;
};

struct Bundle: Handle {
  Data data;
};

using bundle_storage = std::aligned_storage_t<sizeof(Bundle), alignof(Bundle)>;

std::size_t bundle_count = 0;
std::array< bundle_storage, 1000 > global_bundles;

Handle* get_bundle() {
  return new ((void*)global_bundles[bundle_count++]) Bundle();
}
void return_bundle( Handle* h ) {
  Assert( h == (void*)global_bundles[bundle_count-1] );
  --bundle_count;
}
char get_char( Handle const* h, std::size_t i ) {
  return static_cast<Bundle*>(h).data[i];
}
void set_char( Handle const* h, std::size_t i, char c ) {
  static_cast<Bundle*>(h).data[i] = c;
}

Here we have opaque Handles which may not be declared on the stack nor dynamically allocated. We have a system to get them from a known array.

I believe nothing above is undefined behavior; failing to destroy a Bundle is acceptable, as is creating a new one in its place.

And the interface doesn't have to expose how Bundle works. Just an opaque Handle.

Now this technique can be useful if other parts of the code need to know that all Handles are in that specific buffer, or their lifetime is tracked in specific ways. Possibly this could also be handled with private constructors and friend factory functions.