>> You need to write some C++ code.
Maybe you need to parse JSON,
establish a connection to a server,
or just write some unit tests.
Unfortunately, the C++ standard library
doesn't have what you're looking for.
Well, no need to write this logic from scratch.
There are thousands of open source C++ libraries out there.
You just need to find them and
somehow get them working with your project.
The trouble is, C++ libraries are not very easy to work with.
There are a couple of challenges you don't
typically see in other programming languages.
First, C++ dependencies need to be compiled in a way that
keeps them compatible with each
other and with the end application consuming them.
It matters a lot how you build them from a compiler and
version you're using to what operating system
and target architecture you're aiming for.
This makes it hard sometimes to just download
a prebuilt binary off the Internet because
if your project requires
a rarely used compiler flag or
you're looking for a more obscure library,
you might be wasting your time.
Of course, how do you know
the pre-built binary does what you think it does?
What if some malware is bundled in?
It gets even more complicated when
you have a few different dependencies.
Say you want to add libraries A and B to your project,
but unbeknownst to you,
A and B both depend on library C. Now,
you would need to also get library C
and you better hope that A and B don't
expect different versions of C
because then you can't combine these together.
You would need to pick a version of A and
a version of B that require
the same version of C to avoid what we call the diamond problem.
That's because in C++,
you can't request two different versions of
the same library in the same build graph,
and of course, library C might have dependencies of its own.
You would end up having to research
every single library you care about and every library depends
on all the way up to the top and come up with
a plan for getting source code and
binaries for all of these dependencies,
and then hopefully, everything will just build with your project.
Recent surveys conducted by the Standard C++ Foundation found that
C++ developers list managing libraries
is one of their top pain points.
Right up there with bill times.
This is a pattern that hasn't changed much over the years.
Furthermore, when we look at how
developers get their libraries working,
it looks like most of them do so manually.
This may be done using get some modules,
manually following build instructions for
individual libraries on their GitHub pages,
searching for prebuilt binaries online, and other methods.
I am here to tell you that it doesn't have to be this hard.
You should start using a package manager.
There are quite a few package managers
accessible to C++ developers.
First, you have system package managers.
These are utilities like apt,
brew, and winget.
System package managers often have
a selection of pre-built libraries you can
use along all the system utilities
and applications you can additionally install.
The problem is, well,
they're system package managers.
They're really designed for their
particular flavor of operating system.
If you need to build for multiple platforms,
you need multiple system package managers,
and of course, the pre-built libraries available may not
come in all the flavors you need and may not be up to date.
Ultimately, system package managers
have a significant scope and are designed
around downloading assets that do not
require further compilation or modification.
Maybe system package managers are not
the best solution for this particular problem.
But then you have language package managers.
In other languages, you may be familiar with
utilities like cargo for rust,
NuGet for.NET, npm for JavaScript,
and pip for Python.
C++ has a few language package managers
available like Hunter Conan and vcpkg.
Just a heads up, I do work on vcpkg and I will be
focusing on that tool in this video.
What's different about a C++ language package manager?
Well, for one, they're cross-platform.
The truth is, a huge amount of
C++ code needs to run on multiple operating systems,
architectures, and with various other compiler settings.
You really need flexibility because
libraries may be deployed in many different circumstances.
These package managers are also tailored for C++ development.
They recognize some of the problems unique to
C++ developers and have solutions for solving them.
For example, C++ has a variety
of build systems from Makefiles to Cmake,
time is built, and that's just the tip of the iceberg.
These specialized package managers are flexible
enough to work with a variety of different build environments,
so no matter how you structure your project,
you can still take advantage of these tools.
Let's talk about vcpkg. Vcpkg is
an open source C++ package manager
supported by Microsoft with over
1,900 unique open source libraries available,
the largest catalog of any C++ package manager.
Using it is as simple as running
a one line command to install pretty much anything you want,
regardless of what built system compiler or
target platform or architecture you need.
You can search for libraries,
declare dependencies in a manifest file or in a terminal window,
and pick what library versions you want.
You can also create your own catalogs of
libraries known as registries,
and integrate them into the same workflow
as your open source dependencies.
Vcpkg operates on a flexible built from
source model to ensure you end up
getting exactly the binaries that will work for your project.
But you can cache binaries in a shared location,
so you don't need to build them every time on
different machines or in your continuous integration pipeline.
Vcpkg automatically installs dependencies of dependencies too,
so you never have to worry about declaring them individually.
A library package in vcpkg is a build recipe called a port.
Running the recipe requires a source code and builds that library.
The vcpkg project is very active on GitHub with
over 15,000 stars and 4,400 forks.
Since it's open source,
anyone can contribute new libraries or
updates to existing ones at any time.
But what's really special about vcpkg is how this
1,900 strong open source catalog actually works.
Remember when I talked about the diamond problem?
When you not only need to pick
the best libraries for your project,
but the best versions of each library to have a successful build.
Well, the entire vcpkg open source catalog
has a baseline version set,
meaning at any point in time,
vcpkg has default versions for
all dependencies in the catalog
that work together without diamond problems.
You can actually avoid specifying package versions altogether and
still get the most recent stable versions
that can be successfully built together.
For this reason, versioning in
vcpkg is different than other package managers.
Now you can request
the minimum version above the baseline for a specific dependency,
or just force a specific version number
to be used with the particular package.
But the value in
the baseline is that you can avoid requesting versions
altogether and still get
recent stable dependencies and don't
introduce diamond problems through build graph.
When you want to update your dependencies,
it's best to update the baseline,
so all packages that can be successfully updated can move
forward in time at once without breaking anything.
We maintain stable baselines by rebuilding what we call the
cones of destruction whenever
the package is updated in our catalog.
The cone of destruction is a list of all the libraries that depend
on or are dependent by the package that gets updated.
Until this series of builds succeeds,
the library update will not be accepted. Let's recap.
You can use vcpkg to search through a large catalog of
open source libraries that can
probably already do the work you need done.
It can install them without you needing to
rebuild instructions on individual GitHub repos,
look up dependencies of dependencies,
or determine what the appropriate version of
each package will actually result in a working build.
You don't need to rely exclusively on header
only libraries or on source code or the SDL to be successful.
Vcpkg package is flexible enough to allow you to use
your own private libraries with it and set
version compiler target architecture
and other constraints as needed.
The fact that it builds packages from source by default means
you can control exactly what you end up getting,
but you can still cache the results of that build,
so you only have to do it once.
Before I close off,
I should say that we are working on
a new feature for vcpkg that lets you
download binary packages and we call these packages artifacts.
Artifacts are not intended to be
libraries since we don't think it's a good idea to never
plan to build your libraries from source and
binary caching is already a feature in vcpkg anyway,
but artifacts are developer tools like Compilers,
Platform SDKs, Debuggers and more.
We're still in early preview and we recommend staying tuned to
the Microsoft C++ team blog to learn more about this feature.
In the future, we want vcpkg to be
able to bootstrap your development environment from scratch,
not just your libraries.
You can learn more about
vcpkg artifacts at aka.ms/vcpkg/artifacts.
If you want to learn more about vcpkg overall,
go to vcpkg.io which is our web site as well
as github.com/Microsoft/vcpkg. Thanks for watching.