Running the eclipse-mosquitto MQTT Broker in a docker container

I first wrote about MQTT and IoT back in 2012, when I developed a simple C based library to publish and subscribe Quality of Service (QoS) level 0 MQTT messages.

Subsequently, MQTT has grown to be one of the most widely used IoT connectivity protocols with direct support from service such as AWS. Back in 2010, the first open-source MQTT Broker was Mosquitto. Mosquitto is now part of the Eclipse Foundation, and an project, sponsored by

Another area that has grown during the interim period is the use of container technology, such as Docker, for both testing and deployment. We have, also, extensively covered Docker in previous blog posts.

For another internal dogfood project, I wanted to run a local MQTT Broker rather than a web-based broker, such as Mosquitto can be installed natively on Windows, Mac and Linux. Still, one of the significant benefits of Docker is not polluting your working machine with lots of different tools.

Running Mosquitto in a Docker container is, therefore, a perfect test environment. Rather than, as in the previous Docker blog articles, build our own Docker image containing Mosquitto, we can use the official Dockerhub image.

eclipse-mosquitto Docker image

Pull the latest image

I’m assuming you have Docker installed and configured for your local working environment.

First, pull the latest image from Dockerhub:

% docker pull eclipse-mosquitto

Note of caution: the instructions on the Dockerhub site are incorrect!

Run the docker image

Run the basic Docker image with default settings:

% docker run -it --name mosquitto -p 1883:1883 eclipse-mosquitto 
1582194844: mosquitto version 1.6.8 starting
1582194844: Config loaded from /mosquitto/config/mosquitto.conf.
1582194844: Opening ipv4 listen socket on port 1883.
1582194844: Opening ipv6 listen socket on port 1883.

The -p 1883:1883 argument maps the docker container’s default MQTT socket 1883 the localhost ( port 1883. Alternatively, we could map that onto another localhost port if it clashed with a locally running MQTT broker, e.g. -p 11883:1883.

Using the --name directive also allows the container to be stopped and restarted, using:

% docker stop mosquitto


% docker start mosquitto

Testing the eclipse-mosquitto Docker container

To test the setup of the running Mosquitto container, I used my original software, still available on github. To build this, you’ll need a C compiler (ideally gcc or clang) and CMake.

Alternatively, any MQTT client should work for test purposes.


Next, we must subscribe to a topic. In a command window invoke the subscribe client to a topic, the default for our project being hello\world on port, e.g.

% ./mqttsub
MQTT SUB Test Code
Connected to MQTT Server at
Subscribed to MQTT Service hello/world with QoS 0


To test publishing, open another command window and invoke the publisher-client. The publisher-client, by default, publishes 10 messages to the topic hello\world and then closes the connection, e.g.

% ./mqttpub 
MQTT PUB Test Code
Connected to MQTT Server at
Published to MQTT Service hello/world with QoS0
Sent 1 messages
Published to MQTT Service hello/world with QoS0
Sent 2 messages
Published to MQTT Service hello/world with QoS0
Sent 3 messages
Published to MQTT Service hello/world with QoS0
Sent 4 messages
Published to MQTT Service hello/world with QoS0
Sent 5 messages
Published to MQTT Service hello/world with QoS0
Sent 6 messages
Published to MQTT Service hello/world with QoS0
Sent 7 messages
Published to MQTT Service hello/world with QoS0
Sent 8 messages
Published to MQTT Service hello/world with QoS0
Sent 9 messages
Published to MQTT Service hello/world with QoS0
Sent 10 messages

Subscribe output

On returning to the subscriber window, we will see the received message displayed.

Message number 1
Message number 2
Message number 3
Message number 4
Message number 5
Message number 6
Message number 7
Message number 8
Message number 9
Message number 10

Mosquitto window output

Returning the window where the docker image was invoked, various log messages are shown:

1582194844: mosquitto version 1.6.8 starting
1582194844: Config loaded from /mosquitto/config/mosquitto.conf.
1582194844: Opening ipv4 listen socket on port 1883.
1582194844: Opening ipv6 listen socket on port 1883.
1582205221: New connection from on port 1883.
1582205221: New client connected from as default_sub (p1, c1, k30).
1582205225: New connection from on port 1883.
1582205225: New client connected from as default_pub (p1, c1, k30).
1582205235: Client default_pub disconnected.

Setting up persistent files

Mosquitto can be configured, for example, to change logging, password, listener-ports, etc. This is achieved using mosquitto.conf file.

To set up mosquitto.conf, first create a local working directory with a three sub-directories of config, data and log, e.g.

% cd
% mkdir docker-mosquitto
% cd docker-mosquitto
% mkdir mosquitto 
% mkdir mosquitto/config/ 
% mkdir mosquitto/data/
% mkdir mosquitto/log/

Create a config file

Next, create a test file called mosquitto.conf in the newly created subdirectory mosquitto/conf/:

% touch mosquitto/config/mosquitto.conf

Edit the config file

Using your favourite editor (okay vi isn’t my favourite, but it’s convenient):

% vi mosquitto/config/mosquitto.conf

And add the as a minimum set of conf directives.

# following two lines required for > v2.0
allow_anonymous true
listener 1883
persistence true
persistence_location /mosquitto/data/
log_dest file /mosquitto/log/mosquitto.log

The full list of configuration items can be found [here](].

Run the docker image with a mounted volume

Now, when invoking the docker image we use the -v flag mapping the local filesystem into the docker container. The running container will now pick up the locally defined mosquitto.conf. Invoke e.g:

% docker run -it --name mosquitto -p 1883:1883 -v $(pwd)/mosquitto:/mosquitto/ eclipse-mosquitto 


I hope this post gave you a useful overview of getting an MQTT Mosquitto Broker up and running using Docker.

Hopefully, in future posts, I will be able to share further details of the dogfood project.


Posted in General | Tagged , , | 12 Comments

Practice makes perfect, part 2 – foundation kata

In the previously article we looked at the need for repetitive practice – code kata.  In this article I want to  present some of my preferred foundational kata.

If you’re a beginner to C++ I recommend you fully internalize all these examples before having a look at the idiomatic kata.

If you’re a more experienced C++ programmer you may be looking at these kata and thinking “Jeez – these are so basic!  Who couldn’t do this!”.  Bear in mind though – we all started somewhere!  I still practice most of these kata regularly.   Remember, you practice exercises like this not until you get them right, but until you can’t get them wrong!

Continue reading

Posted in C/C++ Programming, Design Issues, training | Tagged , , , | 1 Comment

Practice makes perfect, part 1 – Code kata

Imagine you’re at a Jazz club, enjoying a smooth jazz quartet.  It’s time for the sax player’s solo.  All of a sudden, he stops the band, rifles in a bag a pulls out a book of music theory.

What the?!” you think.

The saxophonist looks to the audience, “I’ve just got to look up the notes for E-flat minor.  I can never remember them.”

It’s understandable you’re unlikely be too impressed with this particular musician.

If you’re a musician, a sportsperson, a dancer, martial artist or anyone who practices an activity that requires skill and competence you’ll be familiar with repetitive practice.

For a musician it means seemingly endless hours of practicing scales and arpeggios to learn music theory and even more hours practicing studies to learn techniques to play your chosen instrument more precisely, more effectively, more beautifully.

If you practice Japanese martial arts you repeat kihon (fundamentals) and kata (or, as they were known in the west, flourishes) to refine your movements and skills.

Almost every activity includes these two practices alongside more creative, freeform practices.  They are essential to developing muscle-memory.  Without them, any creative practice will always be clumsy and immature; and there will always be a ‘ceiling’ to what you can achieve.

What does this have to do with software engineering?

Continue reading

Posted in C/C++ Programming, Design Issues, training | Tagged , , , , | 3 Comments

Function function return return values values*

The latest C++ standard is now upon us, so it’s time to have a look at some of its new features.

To put one of the new features into context we’re going to have a look at – as the title suggests – multiple function return values

I should really distinguish between the following:

  • A Subroutine (or Subprogram) is a parameterised block of code that can be called multiple times from within a program.
  • A Procedure is a subroutine that may have multiple input and/or output parameters and usually does not return a value.  Procedures may change the state of the system
  • A Function is a subroutine that has only input parameters and produces a return value.  Functions are stateless – they will always produce the same result for the same inputs.

C++ programmers typically blur these distinctions (or ignore them).  To keep with the C++ vernacular I will use the term ‘function’ to mean any of the above.


(*Sorry – this is a really terrible pun for a title)

Continue reading

Posted in C/C++ Programming | Tagged , , , , | Leave a comment

Contract killing (in Modern C++)

If you work in high-integrity or safety-critical software then you have a duty-of-care to:

  • Ensure your code does what it should
  • Ensure your code doesn’t do what it’s not supposed to.

Moreover, you’re typically required to both demonstrate and document how you’ve achieved this duty-of-care. Typical mechanisms for demonstrating compliance include unit testing and static analysis; documentation usually includes function specifications and test results. The amount of testing, static analysis and documentation you (have to) do depends on the integrity level of your system.  The more critical the consequences of a failure, the more evidence you have to provide to demonstrate that you’ve considered, and alleviated, the failure.

I would argue that, even if your code could never kill someone, its failure will still ruin someone’s day. As a professional engineer you always have some duty-of-care to ensure your system works ‘properly’.  Therefore, you always should do an ‘appropriate’ level of testing, analysis and documentation.

Writing dependable code is a combination of two things:

  • Ensuring your code is implemented correctly (by you)
  • Ensuring your code is used correctly (by others)

In my experience, engineers are normally pretty good at implementing functionality correctly.  Where they are usually weaker is in taking the time and effort to specify exactly what they should be implementing.  In particular, error paths, corner cases and combination of these things tend to get overlooked.   That is, less experienced engineers tend to focus on the ‘sunny day’ scenario, and be overly optimistic of the other’s code around them.

Ensuring your code is used correctly is normally an exercise in documentation.  However, documentation suffers from a number of challenges:

  • We’re not given the time to do it well
  • No-one likes writing it.
  • Good documentation is a rarity; probably because of the above
  • No-one reads documentation anyway; also probably because of the above.
  • Your code can’t be automatically checked against the documentation

The above means that documentation is often an exercise in futility for the writer, and an exercise in frustration for the reader.

So, in this article I want to explore language features, existing and forthcoming, that can help us improve the quality of our code. For the purposes of this article I’ll concentrate on one aspect of C++ – functions.

In order to be more effective than simple text documentation these features must provide the following characteristics:

  • They should guide the implementer as to corner cases, error paths, etc.
  • They should establish a (bare minimum) set of unit test cases
  • They should specify any requirements imposed on the user
  • They should establish guarantees – promises – provided by the code to the client
  • They should be automatically checkable – ideally at compile-time
  • They should make code more readable
  • They should, wherever possible, improve a compiler’s ability to optimise code.



Since writing this article Contracts have been dropped from C++20.  The  code presented here remains incomplete and experimental.  Here’s hoping this very important feature makes it into a release sometime soon.

Continue reading

Posted in C/C++ Programming | Tagged , , , , , , , , , , , , , , | 3 Comments

Celebrating 10 years – my top 10 blog articles

It’s difficult to believe we’ve been writing articles for 10 years.  In that time I’ve written over 90 technical articles on C, C++ and embedded system design.

To celebrate I’ve picked my ‘Top 10’ articles, with a little background into why I enjoyed writing them so much, or the story behind them.

So, sit back, cue up At the Sign of the Swinging Cymbal“* and enjoy.


(* This really dates me!)

Continue reading

Posted in C/C++ Programming, Design Issues, Testing, UML | Tagged , , , , , , , | Leave a comment

Using a Raspberry Pi as a remote headless J-Link Server

Here at Feabhas we tend to favour using Segger J-Link’s as our ‘go-to’ solution for target flashing and debug, as they fall into that category of tools that just work.

As part of our ongoing work around Agile and CI (Continuous Integration), we’re always interested in addressing that challenging step of automating target based test in a cost-effective manner.

The Raspberry Pi (RPi) is a ubiquitous low-cost platform for numerous tasks. One useful tasks that it can be used for is as a network-based conjugate between a client machine and a target board, where the target board is connected to the RPi via a local J-Link.

Setting up the RPi

The Segger J-Link utilities are available for ARM-based systems, which means it should work on any Raspberry Pi. However, we have, so far, only tested it on a RPi3+, but intend to try the PiZero as well.

As we are using the RPi in a headless setup we installed Raspbian Stretch Lite, connected an HDMI screen plus keyboard and booted up the Pi.

We then proceeded through the usual Pi setup

  • ensured all software was updated
  • changed the pi user password (I know many people go further and swap out pi for a different user)
  • enabled SSH (this becomes useful later when remote working from a client):
$ sudo raspi-config
--> 5 Interfacing Options  Configure connections to peripherals  
--> P2 SSH         Enable/Disable remote command line access to your Pi using SSH 

In addition, make a note of the RPi’s IP address (assuming you’re using the WiFi interface), as we’ll need that later to connect:

$ ip addr show wlan0

and make a note of the inet number (e.g. 192.168.0.XXX or similar), or use ifconfig.

Installing the J-Link utilities

Connect your J-Link via USB to the Pi and to your target board via the appropriate header. Assuming SSH was set up we can now work remotely from the client machine.

On our client machine, log in to the RPi via ssh:

 $ ssh pi@192.168.0.XXX
pi@192.168.0.XXX's password: 
Linux raspberrypi 4.19.50-v7+ #1234 SMP Thu Jun 13 11:06:37 BST 2019 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jun 20 10:27:31 2019 from 192.168.0.YYY
pi@raspberrypi:~ $ 

In the pi user home directory, download and un-tar the Segger utilities for the Pi. Then configure the udev rules as per README.txt file in the JLink_Linux_V646g_arm directory.

$ wget --post-data 'accept_license_agreement=accepted&non_emb_ctr=confirmed&submit=Download+software'
$ tar xvf JLink_Linux_arm.tgz
$ cd JLink_Linux_V646g_arm/
$ more README.txt
$ sudo cp 99-jlink.rules /etc/udev/rules.d/
$ sudo reboot

This will close the ssh connection.

Starting the RPi’s J-Link Server Software

Re-login to the RPi via ssh.

Under the directory JLink_Linux_V646g_arm there are a number of utilities. As we are running from the command line we need to invoke the application JLinkRemoteServerCLExe on the RPi:

$ ./JLink_Linux_V646g_arm/JLinkRemoteServerCLExe -Port 19020
SEGGER J-Link Remote Server V6.46g
Compiled Jun 14 2019 19:38:47

'q' to quit '?' for help

Connected to J-Link with S/N xxxxxxxxx

Waiting for client connections... 

Reading the documentation, the -Port 19020 shouldn’t be required as it’s supposedly the default port, however, at the time of writing without specifying this the client connection always fails.

Connecting the client via CLI

On the client machine, download and install the Segger J-Link Software and Documentation Pack specific for your host OS (I’m using macOS).

Once installed, simply type the following (substituting the IP address as appropriate):

$ JLinkExe ip 192.168.0.XXX
SEGGER J-Link Commander V6.46g (Compiled Jun 14 2019 19:36:04)
DLL version V6.46g, compiled Jun 14 2019 19:35:53

Connecting to J-Link via IP...O.K.
Firmware: J-Link V10 compiled Jun 14 2019 19:25:26
Hardware version: V10.10
S/N: xxxxxxxxx
License(s): FlashBP, GDB

Type "connect" to establish a target connection, '?' for help

On the RPi you should see:

Conn. 8: Client connected.
Connected to J-Link with S/N xxxxxxxxx

To disconnect the client, simply type qc at the J-Link command line and the RPi should go back to:

Waiting for client connections... 

Connecting a client debugger

If the J-Link remotely connects correctly, then it is also possible to use tools such as Segger’s Ozone to do remote target debugging. For example, in Ozone simply set the IP address of the remote RPi in the J-Link Settings under the Tools menu.

You can then download and debug an image as if the target was local to the client machine:

Remote-remote connection!

Back in February if this year (2019), Segger announced a new feature call tunnelling. This enables remote connection to a J-Link Server via the internet.

To use this utility, then on the RPi, type:

$ ./JLink_Linux_V646g_arm/JLinkRemoteServerCLExe -UseTunnel -TunnelByName <some_name> -TunnelPW <some_password>


$ ./JLink_Linux_V646g_arm/JLinkRemoteServerCLExe -UseTunnel -TunnelByName feabhas_jlink_42 -TunnelPW monkey

And before you ask, no we don’t use monkey as our password 😉

On the client connect via:

$ JLinkExe ip tunnel:feabhas_jlink_42:monkey

Full details can be found at

Note: I was unsuccessful getting this to work with Ozone


It is important to note, that for the Linux ARM utilities, Segger clearly state that the : This package comes without any support.

I have found that quite regularly once I have quit the client I am then unable to reconnect, with the following error:

$ JLinkExe ip 192.168.0.XXX
SEGGER J-Link Commander V6.46g (Compiled Jun 14 2019 19:36:04)
DLL version V6.46g, compiled Jun 14 2019 19:35:53

Connecting to J-Link via IP...FAILED: Can not connect to J-Link via TCP/IP (192.168.0.XXX, port 19020)

And the Server application still thinks the client is connected. The only option I’ve found is to type q in the RPi session which quits JLinkRemoteServerCLExe and then to restart it from the command line. This is the major reason for using SSH as it allows JLinkRemoteServerCLExe can be restarted remotely.

The same issue was persistent when using tunnelling and, obviously, having no SSH connection to the RPi it proved pretty useless (if I use our VPN to connect to the RPi it negates the benefit of tunnelling).

However, others have indicated they have had no such problems (it may be something LAN specific?).


The use of a Raspberry Pi acting as a network-connected conduit to a target board is very attractive. RPi’s are easy to source and very inexpensive. Combined with Segger’s J-Link utilities, including applications to handle GDB and SWO, then it may provide a good platform for taking many CI pipelines to their next step.

Unfortunately, the issues of failed reconnection do seem to only be happening with the Linux Arm utilities. Running the same Remote Server commands a Linux laptop proved reliable, both on the local LAN and using tunnelling.

As Raspberry Pi’s support Docker, then my next angle of attack is to see if there is a way I can run the server software in a docker container, which would allow for simpler restarts without needing the SSH connection.

For now, we’ll live with the reconnection issue and continue to use SSH, but watch this space…


Posted in Agile, ARM, C/C++ Programming, Testing | Tagged , , | 7 Comments

Python 3 File Paths

If you’ve used Python for a while you will probably be familiar with the os module for working with files and directories; often called pathnames by Linux users. In moving to Python 3 you may continue to use the same os and os.path functions from Python 2.7, however a new pathlib module provides an alternative object-oriented (OO) approach.

In this posting, we examine the common file handling situations; comparing the OO approach of pathlib against the procedural approach of os functions.

Current Directory

To obtain the current working directory with os functions we use getcwd():

import os
cwd = os.getcwd()

The cwd variable is a standard Python string object containing the directory path:


On Windows this would be, for example:


In contrast, the OO approach provided by pathlib is to create a Path object with no arguments:

from pathlib import Path
cwd = Path()

Path objects encapsulate the concept of a path (the name of a file or directory on disk) but do not necessarily imply that the path exists. A Path object can be queried and used to manipulate pathnames. Converting a Path to a string for printing returns the simplest form of the path which for the current directory is always:


To get the full, or absolute, pathname use:


which will display the same string value as returned by os.getcwd().

Directory Listing

The names in the current directory are returned by os.listdir() as a list of strings:

names = os.listdir()

Normally you’d want to examine these files. In this example, we’ll simply get the file size and modification date. To start with we need to convert each name into a pathname using os.path.join():

for name in os.listdir(cwd):
    path = os.path.join(cwd, name)

We can now use this path variable to access the file on disk. If you’ve read the wrong tutorial you may, in the past, have written:

path = cwd + '/' + name

Which works but isn’t very Pythonic If you’re a Windows user and write:

path = cwd + '\\' + name

then you have missed the part that says Python treats both forward and backward slash characters as directory separators on both Linux and Windows. In other words, it doesn’t matter which form of slash character you use – it’s all the same to Python. Of course, you may have got around the forward/backward slash issue by using the host separator character from the os module:

path = cwd + os.sep + name

None of these concatenation solutions is as clean or maintainable as the os.path.join() function.

Returning to the directory listing example code, we can read the file size and modification timestamp using two separate os.path function calls, e.g.:

import os
From datetime import datetime
for name in os.listdir(cwd):
    path = os.path.join(cwd, name)
    size = os.path.getsize(path)
    mtime = datetime.fromtimestamp(os.path.getmtime(path))
    print(f'{name} {size} bytes, modified {mtime}')

For the pathlib.Path code example we can use iterdir() which is an iterator function, which also fits nicely with our for loop approach. As the iterator yields up Path objects there is no need to join the file name with the parent directory:

for path in cwd.iterdir():

Accessing file information from a Path object is a single method call. This returns all statistics in a single object which is likely to be more efficient than the multiple os.path function calls:

stats = path.stat()

The revised OO code looks thus:

from pathlib import Path
for path in cwd.iterdir():
    stats = path.stat()
    size = stats.st_size
    mtime = datetime.fromtimestamp(stats.st_mtime)
    print(f'{path} {size} bytes, modified {mtime}')

Building Pathnames

We’ve already looked at how os.path.join() is used to build filenames. With Path objects there is a similar joinpath() method used to access files from a directory path.

Consider where we want to access a file called ‘example.settings’ in a ‘conf’ sub-directory. Using os.path.join() we would write:

settings = os.path.join(cwd, 'conf', 'example.settings')

Using a Path object we now write:

settings = cwd.joinpath('conf').joinpath('example.settings')

Alternatively, we could use the / operator on a Path object and a string (or anther Path object):

settings = cwd / 'config' / 'example.settings'

Path objects also support wildcard filename expansion, e.g.:

py_files = list(cwd.glob('*.py'))

The glob() method returns an iterator; which in this case we’ve used to initialise a list containing Path objects.

The traditional approach for expanding wildcards is to use the glob module to get back a list of strings:

import glob
py_files = glob.glob('*.py')

Both versions of the glob() method/function also support recursive wildcards using ‘**’ (but the glob.glob() method requires a recursive=True argument to enable this feature):

py_files = list(cwd.glob('**/*.py'))
py_files = glob.glob('**/*.py', recursive=True)

This capability means that you no longer need to use the cumbersome os.walk() method if all you want to do is find files that match a wildcard pattern.

Manipulating Files

The os module has many functions for manipulating files. The following example checks for a file called example.log in the current directory and then deletes it.

Using the os module:
logfile = './example.log'
if os.path.exists(logfile):

The same solution using the pathlib module

logfile = Path('./example.log')
if logfile.exists():

Directories can be created using the os.mkdir() function or Path.mkdir() method and empty directories removed with the rmdir() function or method.

Opening Files

Finally, Python 3.6 upgraded the os and os.path functions as well as file open() to work with both strings and Path objects: this is formalised as a Path Like Object.

The procedural approach for opening all Python files in the current directory looks like:

for path in glob.iglob('*.py'):
    with open(path) as fp:

The object oriented approach looks like:

for path in Path().glob('*.py'):
    with open(path) as fp:

The Path class has a lot more capabilities in addition to those shown here. It is a more or less complete replacement for all of the os, os.path and glob functions and is described in the Python 3 pathlib documentation.


If you like OO languages such as C++ or Java you’ll probably prefer the Python 3 object-oriented approach using Path object. Whereas if you’re used to the procedural approach of C you may be be more comfortable using the os, os.path and glob functions.

As long as you’re aware that both approaches are available with Python 3 you can make an informed decision over which one to use, rather than continue to use the procedural approach without being aware that there is an alternative.

Posted in Python, Python3 | Leave a comment

Brace initialization of user-defined types

Uniform initialization syntax is one of my favourite features of Modern C++.  I think it’s important, in good quality code, to clearly distinguish between initialization and assignment.

When it comes to user-defined types – structures and classes – brace initialization can throw up a few unexpected issues, and some counter-intuitive results (and errors!).

In this article, I want to have a look at some of the issues with brace initialization of user-defined types – specifically, brace elision and initializer_lists.

Read on for more…

Continue reading

Posted in C/C++ Programming, General | Tagged , , , , , , , | 1 Comment

Thanks for the memory (allocator)

One of the design goals of Modern C++ is to find new ways – better, more effective – of doing things we could already do in C++.  Some might argue this is one of the more frustrating aspects of Modern C++ – if it works, don’t fix it (alternatively: why use lightbulbs when we have perfectly good candles?!)

This time we’ll look at a new aspect of Modern C++:  the Allocator model for dynamic containers.  This is currently experimental, but has been accepted into C++20.

The Allocator model allows programmers to provide their own memory management strategy in place of their library’s default implementation.  Although it is not specified by the C++ standard, many implementations use malloc/free.

Understanding this feature is important if you work on a high-integrity, or safety-critical, project where your project standards say ‘no’ to malloc.

Continue reading

Posted in C/C++ Programming, General | Tagged , , , , , , , , , , , | 8 Comments