<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>C++ on Karpoke - Just Another Blog</title><link>http://karpoke.ignaciocano.com/tags/c++/</link><description>Recent content in C++ on Karpoke - Just Another Blog</description><generator>Hugo -- 0.167.0</generator><language>es</language><lastBuildDate>Fri, 05 Jun 2026 12:00:00 +0100</lastBuildDate><atom:link href="http://karpoke.ignaciocano.com/tags/c++/index.xml" rel="self" type="application/rss+xml"/><item><title>C++ Documentary is Now Available</title><link>http://karpoke.ignaciocano.com/2026/06/05/c-documentary-is-now-available/</link><pubDate>Fri, 05 Jun 2026 12:00:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2026/06/05/c-documentary-is-now-available/</guid><description>&lt;blockquote&gt;
&lt;p&gt;The Story of C++: The World&amp;rsquo;s Most Consequential Programming Language is
now available for free on YouTube.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;» Paul Thurrott | &lt;a href="https://www.thurrott.com/uncategorized/337056/c-documentary-is-now-available"&gt;thurrott.com&lt;/a&gt;&lt;/p&gt;</description></item><item><title>Bjarne Stroustrup, padre de C++: "Solo hay dos tipos de lenguajes de programación: aquellos de los que la gente se queja y los que nadie usa"</title><link>http://karpoke.ignaciocano.com/2026/04/01/bjarne-stroustrup-padre-de-c-solo-hay-dos-tipos-de-lenguajes-de-programacion-aqu/</link><pubDate>Wed, 01 Apr 2026 12:00:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2026/04/01/bjarne-stroustrup-padre-de-c-solo-hay-dos-tipos-de-lenguajes-de-programacion-aqu/</guid><description>&lt;blockquote&gt;
&lt;p&gt;Blog sobre informática, tecnología y seguridad con manuales, tutoriales
y documentación sobre herramientas y programas&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;» Blog elhacker.NET | &lt;a href="https://blog.elhacker.net/2026/04/bjarne-stroustrup-padre-de-c-solo-hay.html"&gt;blog.elhacker.net&lt;/a&gt;&lt;/p&gt;</description></item><item><title>46 Stories To Learn About C</title><link>http://karpoke.ignaciocano.com/2023/04/12/46-stories-to-learn-about-c/</link><pubDate>Wed, 12 Apr 2023 16:13:04 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2023/04/12/46-stories-to-learn-about-c/</guid><description>&lt;blockquote&gt;
&lt;p&gt;Learn everything you need to know about C via these 46 free HackerNoon
stories.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;» hackernoon.com | &lt;a href="https://hackernoon.com/46-stories-to-learn-about-c"&gt;hackernoon.com&lt;/a&gt;&lt;/p&gt;</description></item><item><title>Why We Need Build Systems</title><link>http://karpoke.ignaciocano.com/2021/06/07/why-we-need-build-systems/</link><pubDate>Mon, 07 Jun 2021 11:00:18 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2021/06/07/why-we-need-build-systems/</guid><description>&lt;blockquote&gt;
&lt;p&gt;Build systems were developed to simplify and automate running the
compiler and linker and are an essential part of modern software
development. This blog post is a precursor to future posts discussing
our experiences refactoring the training projects to use the CMake
build…&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;» Martin Bond | &lt;a href="https://blog.feabhas.com/2021/06/why-we-need-build-systems/"&gt;blog.feabhas.com&lt;/a&gt;&lt;/p&gt;</description></item><item><title>Threat hunting (VIII): cazando sin salir de casa. Creación de procesos (II)</title><link>http://karpoke.ignaciocano.com/2020/11/26/threat-hunting-viii-cazando-sin-salir-de-casa-creacion-de-procesos-ii/</link><pubDate>Thu, 26 Nov 2020 16:10:54 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2020/11/26/threat-hunting-viii-cazando-sin-salir-de-casa-creacion-de-procesos-ii/</guid><description>&lt;blockquote&gt;
&lt;p&gt;Threat hunting (VIII): cazando sin salir de casa. Creación de procesos (II)&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;» securityartwork.es | &lt;a href="https://www.securityartwork.es/2020/11/26/threat-hunting-viii-cazando-sin-salir-de-casa-creacion-de-procesos-ii/"&gt;securityartwork.es&lt;/a&gt;&lt;/p&gt;</description></item><item><title>How Do We Get a Balanced Binary Tree?</title><link>http://karpoke.ignaciocano.com/2020/09/01/how-do-we-get-a-balanced-binary-tree/</link><pubDate>Tue, 01 Sep 2020 22:28:34 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2020/09/01/how-do-we-get-a-balanced-binary-tree/</guid><description>&lt;blockquote&gt;
&lt;p&gt;A binary tree can be empty, implying zero nodes in the tree. The cool
thing about &lt;code&gt;binary trees&lt;/code&gt; is that they are recursive structures.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;» DEV Community | &lt;a href="https://dev.to/jacobjzhang/how-do-we-get-a-balanced-binary-tree-259e"&gt;dev.to&lt;/a&gt;&lt;/p&gt;</description></item><item><title>The Rule of The Big Three (and a half) – Resource Management in C++</title><link>http://karpoke.ignaciocano.com/2015/01/18/the-rule-of-the-big-three-and-a-half-resource-management-in-c/</link><pubDate>Sun, 18 Jan 2015 10:59:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2015/01/18/the-rule-of-the-big-three-and-a-half-resource-management-in-c/</guid><description>&lt;blockquote&gt;
&lt;p&gt;The dynamic creation and destruction of objects was always one of the
bugbears of C. It required the programmer to (manually) control the
allocation of memory for the object, handle the object’s
initialisation then ensure that the object was safely cleaned-up after
use and its memory returned to the heap. Because many C programmers
weren’t educated in the potential problems (or were just plain lazy or
delinquent in their programming) C got a reputation in some quarters
for being an unsafe, memory-leaking language.&lt;/p&gt;
&lt;/blockquote&gt;</description></item><item><title>Indian Developers Redesigning Linux Kernel With OOP, C++ Support</title><link>http://karpoke.ignaciocano.com/2014/10/05/indian-developers-redesigning-linux-kernel-with-oop-c-support/</link><pubDate>Sun, 05 Oct 2014 11:36:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2014/10/05/indian-developers-redesigning-linux-kernel-with-oop-c-support/</guid><description>&lt;blockquote&gt;
&lt;p&gt;DOS Lab IIT Madras and CDAC Chennai out of India are aiming to
redesign the Linux kernel as MOOL, or the Minimalistic Object Oriented
Linux. The project site explains, ”MOOL (Minimalistic Object Oriented
Linux) aims at redesigning the Linux kernel to reduce coupling and
increase maintainability by means of OO (Object Oriented)
abstractions. Excessive common coupling prevails in existing kernel.
Studies have shown that common coupling is increasing in successive
versions of Linux. This will make maintainability of Linux difficult
in coming years. As a starting step we have tried to reduce the number
of global variables of the kernel. Some global variables are used only
by two or three kernel modules. These are passed as function
arguments. The performance of the modified kernel is measured with the
standard performance analysis tools. The modified kernel performs
almost same as original. MOOL features a device driver framework to
write drivers in C++ and insert them as loadable kernel modules.”&lt;/p&gt;
&lt;/blockquote&gt;</description></item><item><title>An Introduction to Lock-Free Programming</title><link>http://karpoke.ignaciocano.com/2012/06/27/an-introduction-to-lock-free-programming/</link><pubDate>Wed, 27 Jun 2012 23:58:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2012/06/27/an-introduction-to-lock-free-programming/</guid><description>&lt;blockquote&gt;
&lt;p&gt;Lock-free programming is a challenge, not just because of the
complexity of the task itself, but because of how difficult it can be
to penetrate the subject in the first place.
I was fortunate in that my first introduction to lock-free (also
known as lockless) programming was Bruce Dawson’s excellent and
comprehensive white paper, Lockless Programming Considerations. And
like many, I’ve had the occasion to put Bruce’s advice into practice
developing and debugging lock-free code on platforms such as the Xbox
360.
Since then, a lot of good material has been written, ranging from
abstract theory and proofs of correctness to practical examples and
hardware details. I’ll leave a list of references in the footnotes. At
times, the information in one source may appear orthogonal to other
sources: For instance, some material assumes sequential consistency,
and thus sidesteps the memory ordering issues which typically plague
lock-free C/C++ code. The new C++11 atomic library standard throws
another wrench into the works, challenging the way many of us express
lock-free algorithms.
In this post, I’d like to re-introduce lock-free programming, first
by defining it, then by distilling most of the information down to a
few key concepts. I’ll show how those concepts relate to one another
using flowcharts, then we’ll dip our toes into the details a little
bit. At a minimum, any programmer who dives into lock-free programming
should already understand how to write correct multithreaded code
using mutexes, and other high-level synchronization objects such as
semaphores and events.&lt;/p&gt;
&lt;/blockquote&gt;</description></item></channel></rss>