Introduction

Back then before 2010, one always used Valgrind to make sure that their C++ program isn't leaking memory. There's a whole modern way of using C++ that doesn't even make you need that. If you're using a C++11 program (and even if you're not), and you still require to keep checking whether your code is leaking memory, then you're most likely doing it all wrong. Keep reading if you wanna know the right way that saves you the trouble having to memory check all the time, and uses true object-oriented programming.

Basically this artice is about the concept named RAII, Resource Allocation Is Initialization, and why it's important from my perspective.

The golden rules of why you should do this

My Golden Rules in C++ development:

1. Humans do mistakes, and just an arrogant would claim that he doesn't (why else do we have something called "error handling"?)
2. Things can go wrong, no matter how robust your program is, and how careful you are, and you can't plan every possible outcome
3. A problem-prone program is no better than a program with a problem; so why bother writing a program with problems?

Once you embrace these 3 rules, you'll never write bad code, because your code will be ready for worst case scenario.

In the last few years, I never found a single lost byte in my Valgrind-analysed programs; and I'm talking about big projects, not in the single class level. The difference will be clear soon.

I'm going to start from simple cases, up to more complicated scenarios.

Scenario 1: If you're creating and deleting objects under pointers

Consider the following example:

void DoSomethingElse(int* var)
{
    std::cout << *x << std::endl;
    //... do stuff with x
}
void DoSomething()
{
    int* x = new int;
    DoSomethingElse(x);
    delete x;
}

Let me make this as clear as possible: If you ever, ever use a new followed by delete… you're breaking all the 3 rules we made up there. Why? Here are the rules and how you're breaking them:

1. You may do the mistake of forgetting to write that delete
2. DoSomethingElse() might throw an exception, and hence that delete may not be called.
3. This is a problem prone design, so it's a program with a problem.

The right way to do this: Smart pointers!

What are smart pointers?

I'm sure you've heard of them before, but if you haven't, the idea is very simple. If you define, for example, an integer like this:

void SomeFunction()
{
    int i = 0;
    // do stuff with i
} //here you're going out of the scope of the function

You never worry about deleting i. The reason is that once i goes out of scope, it's deleted automatically (through a destructor). Smart pointers are just the same. They wrap your pointer, such that they are deleted once they are out of scope. Let's look at our function DoSomething() again with smart pointers:

void DoSomething()
{
    std::unique_ptr<int> x(new int); //line 1
    DoSomethingElse(x.get());        //line 2
} //once gone out of scope, x will be deleted automatically, 
  //the destructor of unique_ptr will delete the integer

That's all the change you have to do, and you're done! In line 1, you're creating a unique_ptr, which will encapsulate your pointer. The reason why it's "unique" will become soon clear. Once the a unique_ptr goes out of scope, it'll delete the object under it. So you don't have to worry! This way, the 3 Golden Rules are served. In line 2, we're using x.get() instead of x, because the get() method will return the raw pointer stored inside the unique_ptr. If you'd like to delete the object manually, use the method x.reset(). The method reset() can take a parameter to another pointer, or can be empty to become nullptr.

PS: unique_ptr is C++11. If you're using C++03, you could use unique_ptr from the boost library

Why is it called "unique"?

Generally, multiple pointers can point to the same object. So, going back to the initial example, the following is a possible scenario:

void DoSomething()
{
    int* x = new int(1);
    int* y = x; //now x and y, both, point to the same integer
    std::cout << *x << "\t" << *y << std::endl; //both will print 1
    *x = *x + 1; //add 1 to the object under x
    std::cout << *x << "\t" << *y << std::endl; //both will print 2
    delete x; //you delete only 1 object, not 2!
}

But can you do this with unique_ptr? The answer is *no*! That's why it's called unique, because it's a pointer that holds complete *ownership* of the object under it (the integer, in our case), and it's unique in that. If you try to do this:

void DoSomething()
{
    std::unique_ptr<int> x(new int);
    std::unique_ptr<int> y = x; //compile error!
}  

your program won't compile! Think about it… if this were to compile, who should delete the pointer when the function ends, x or y? It's ambiguous and dangerous. In fact, this is exactly why auto_ptr was deprecated in C++11. It allowed the operation mentioned before, which effectively *moved* the object under it. This was dangerous and unclear semantically, which is why it's deprecated.

On the other hand, you can move an object from one unique_ptr to another! Here's how:

void DoSomething()
{
    std::unique_ptr<int> x(new int);
    std::unique_ptr<int> y = std::move(x);
    //now x is empty, and y has the integer, 
    //and y is responsible for deleting the integer
}

with std::move(x), you convert x to an rvalue reference, indicating that it can be safely moved/modified.

Shared pointers

Since we established that unique pointers are "unique", let's introduce the solution to the case where multiple smart pointers can point to the same object. The answer is: shared_ptr. Here's the same example:

void DoSomething()
{
    std::shared_ptr<int> x(new int(2)); //the value of *x is 2
    std::shared_ptr<int> y = x; //this is valid!
    //now both x and y point to the integer
}

Who is responsible for deleting the object now? x or y? Generally, any of them! The way shared pointers work is that they have a common reference counter. They count how many shared_ptrs point to the same object, and once the counter goes to zero (i.e., the last object goes out of scope), the last object is responsible for deleting.

In fact, using the new operator manually is highly discouraged. The alternative is use make_shared, which covers some corner cases of possible memory leaks. For example, if the constructor of the class use in shared_ptr has a multi-parameter constructor that may throw an exception. Here's how make_shared is used:

void DoSomething()
{
    std::shared_ptr<int> x = std::make_shared<int>(2); //the value of *x is 2
    std::shared_ptr<int> y = x; //this is valid!
    //now both x and y point to the integer
}

Note: Shared pointers change a fundamental aspect of C++, which is "ownership". When using shared pointers, it may be easy to lose track of the object. This is a common problem in asynchronous applications. This is a story for another day though.

Note 2: The reference counter of shared_ptr is thread-safe. You can pass it among threads with no problems. However, the thread-safety of the underlying object it points to is your responsibility.

Scenario 2: I don't have C++11 and I can't use boost

This is a common scenario in organizations that maintain very old software. The solution to this is very easy. Write your own smart pointer class. How hard can it be? Here's a simple quick-and-dirty example that works:

template <typename T>
class SmartPtr
{
    T* ptr;
    // disable copying by making assignment and copy-construction private
    SmartPtr(const SmartPtr& other) {} 
    SmartPtr& operator=(const SmartPtr& other) {return SmartPtr();}
public:
    SmartPtr(T* the_ptr = NULL)
    {
        ptr = NULL;
        reset(the_ptr);
    }
    ~SmartPtr()
    {
        reset();
    }
    void reset(T* the_ptr = NULL)
    {
        if(ptr != NULL)
        {
            delete ptr;
        }
        ptr = the_ptr;
    }
    T* get() const //get the pointer
    {
        return ptr;
    }
    T& operator*()
    {
        return *ptr;
    }
    T* release() //release ownership of the pointer
    {
        T* ptr_to_return = ptr;
        ptr = NULL;
        return ptr_to_return;
    }
};

and that's it! The method release(), I haven't explained. It simply releases the pointer without deleting it. So it's a way to tell the unique_ptr: "Give me the pointer, and forget about deleting it; I'll take care of that myself".

You can now use this class exactly like you use unique_ptr. Creating your own shared_ptr is a little more complicated though, and depends on your needs. Here's the questions you need to ask yourself on how to design this:

1. Do you need multithreading support? shared_ptr supports thread-safe reference counting.
2. Do you need to just count references, or also track them? For some cases, one might need to track all references with something like a vector of references or a map.
3. Do you need to support release()? Releasing is not supported in shared_ptr, since it depends on reference counting, there's no way to tell other instances to release.

More requirements will require more work, especially that prior to C++11, multithreading was not in the C++ standard, meaning that you're gonna have to use system-specific C++.

For a strictly single-threaded application with C++03, I created a shared pointer implementation that supports releasing. Here's the source code.

Scenario 3: Enable a flag, do something, then disable it again

Consider the following code, which is common in GUI applications:

void GUIClass::addTheFiles(const std::vector<FileType>& files)
{
    this->disableButton();
    for(unsigned i = 0; i < files.size(); i++)
    {
        fileManager.addFile(files[i]);
    }
    this->enableButton();
}

While this looks legitimate way to do things, it's not. This is absolutely no different that the pointer situation. What if adding fails? Either because of a memory problem, or because of some exception? The function will exit without reenabling that button, and your program will become unusable and the user will probably have to restart it.

Solution? Just like before. Don't do it yourself, and get the destructor of some class to do it for you. Let's do this. What do we need? We need a class that will call a function with a reference to some variable on exit. Consider the following class:

class AutoHandle
{
    std::function<void()> func;
    bool done = false; //used to make sure the call is done only once
    // disable copying and moving
    AutoHandle(const AutoHandle& other) = delete;
    AutoHandle& operator=(const AutoHandle& other) = delete;
    AutoHandle(AutoHandle&& other) = delete;
    AutoHandle& operator=(AutoHandle&& other) = delete;
public:
    AutoHandle(const std::function<void()>& the_func)
    {
        func = the_func;
    }
    void doCall()
    {
        if(!done) 
        {
            func();
            done = true;
        }
    }
    ~AutoHandle()
    {
        doCall();
    }
};

Let's use it!

void GUIClass::addTheFiles(const std::vector<FileType>& files)
{
    this->disableButton();
    AutoHandle ah([this](){this->enableButton();}); //lambda function that contains the function to be called on exit
    for(unsigned i = 0; i < files.size(); i++)
    {
        fileManager.addFile(files[i]);
    }
} //Now, the function enableButton() will definitely be called definitely on exit.

This way, you guarantee that enableButton() will be called when the function exits. This whole thing here is C++11, but doing it in C++03 is not impossible, though I completely sympathize with you if you feel it's too much work for such a simple task, because:

1. Since there's no std::function in C++03, we're gonna have to make that class template that accepts functors (function objects)
2. Since there's no lambda functions in C++03, we're gonna have to make the call a new functor for every case (depending on how much you would like to toy with templates, also another big topic)

Just for completeness, here's how you could use AutoHandle in C++03 with a Functor:

template <typename CallFunctor, typename T>
class AutoHandle
{
    bool done; //used to make sure the call is done only once
    CallFunctor func;
    // disable copying by making assignment and copy-construction private
    AutoHandle(const AutoHandle& other) {}
    AutoHandle& operator=(const AutoHandle& other) {return *this;}
public:
    AutoHandle(T* caller) : func(CallFunctor(caller))
    {
        done = false;
    }
    void doCall()
    {
        if(!done)
        {
            func();
            done = true;
        }
    }
    ~AutoHandle()
    {
        doCall();
    }
};

struct DoEnableButtonFunctor
{
    GUIClass* this_ptr;
    DoEnableButtonFunctor(GUIClass* thisPtr)
    {
        this_ptr = thisPtr;
    }
    void operator()()
    {
        this_ptr->enableButton();
    }
};

Here's how you can use this:

void GUIClass::addTheFiles(const std::vector<FileType>& files)
{
    this->disableButton();
    AutoHandle<DoEnableButtonFunctor,GUIClass> ah(this); //functor will be called on exit
    for(unsigned i = 0; i < files.size(); i++)
    {
        fileManager.addFile(files[i]);
    }
} //Now, the function enableButton() will definitely be called definitely on exit.

Again, writing a functor for every case is a little painful, but depending on the specific case, you may decide. However, in C++11 projects, there's no excuse. You can easily make your code way more reliable with lambdas.

Remember, you're not bound to the destructor to do the calls. You can also call doCall() yourself anywhere (equivalent to reset() in unique_ptr). But the destructor will *guarantee* that the worst case scenario is covered if something went wrong.

Scenario 4: Opening and closing resources

This could even be more dangerous than the previous cases. Consider the following:

void ReadData()
{
    int handle = OpenSerialPort("COM3");
    ReadData(handle);
    Close(handle);
}

This form is quite common in old libraries. I faced such a format with the HDF5 library. If you read the previous sections, you'll get the problem with such usage and the idea on how to fix it. It's all the same. You *should never* close resources manually. For my HDF5 problem, I wrote a SmartHandle class that guarantees that HDF5 resources are correctly closed. Find it here. Of course, the formal right way to do this is to write a whole wrapper for the library. This may be an over-kill depending on your project constraints.

Notes on Valgrind

If you follow these rules, you'll be 100% safe with the resources you use. You rarely will ever need to use Valgrind. However, when you write the classes that we talked about (such as AutoHandle, SmartPtr, etc), it's very, very important not only to test it with Valgrind, but also to write good tests that will cover every corner case. Because once you do these classes right, you never have to worry about them. If you do them wrong, the consequences could be catastrophic. Surprising? Welcome to object-orient programming! This is exactly what "separation of concerns" mean.

Conclusion

Whenever you have to do, then undo something, then keep in mind that you shouldn't have this manually done. Sometimes it's safe and trivial, but many times it may lead to simply bad and error-prone design. I covered a few cases and different ways to tackle the issue. By following these examples, I guarantee that your code will become more compact (given that you're using C++11) and way more reliable.

Just a side-note on standards and rules

Sometimes when I discuss such issues related to modern designs, people claim that they have old code, and they don't want to change the style of the old code for consistency. Other times they claim that this would be violating some standard issued by some authority. All these reasons don't show that doing or not doing this is right or wrong. It just shows that someone doesn't want to do them because they're "following the rules". To me (and I can't emphasize enough that this is my opinion), it just is like asking someone "Why do you do this twice a day, how does it help you?", and get the answer "Because my religion tells me I have to do it". While I respect all ideologies, such an answer is not a rational answer that justifies the pros and cons of doing something. That answer doesn't tell why doing that twice a day helps that guy's health, physically or mentally or otherwise. He just is following a rule *that shouldn't be discussed*. I'm a rational person and I like discussing things by putting them on the table, which helps in achieving the best outcome. If someone's answer is "I have a standard I need to follow it", then that effectively and immediately closes the discussion. There's nothing else to add. Please note that I'm not encouraging breaking the rules here. If your superior tells you how to do it, and you couldn't convince them otherwise, then just do what he tells you, because most likely your superior has a broader picture of other aspects of a project that don't depend on code only.

Qt Creator… the best IDE for developing C and C++ I’ve ever seen in my life. Since I like it that much, I’m sharing some of what I know about it.

DISCLAIMER: I’m not a lawyer, so don’t hold me liable for anything I say here about licensing. Anything you do is your own responsibility. 

What does using Qt Creator without Qt mean?

It simply means that you don’t have to install or use the Qt libraries, including qmake. There are many reasons why that may be the case:

• You may have an issue with licensing since qmake is LGPL licensed
• You may not have the possibility to install qmake alone without its whole gear, as is the case in Windows
• You may not want to compile the whole Qt libraries if the pre-compiled versions that work with your compiler is not available

While I love Qt and use it all the time, I follow the principle of decoupling my projects from libraries if I don’t use them. But since I love Qt Creator, I still want to use it! Reasons will become clear below.

What are the ingredients of this recipe?

1. Qt Creator
2. CMake
3. A compiler (gcc, MinGW or Visual Studio, or anything else)

You don’t need to download the whole Qt SDK. Just Qt Creator. It’s about 90 MB.

Basic steps

After installing the 3 ingredients, make sure that Qt Creator recognized that CMake exists on the computer. The next picture (click on it to magnify it) is how it looks like if CMake was found. If it doesn’t find CMake, on Windows, most likely the reason is that you chose in the installation not to add CMake to the system’s PATH. Eventually, you can just add it manually if it can’t be found automatically.

Next, make sure that Qt recognizes the compiler and the debugger as you see in the next pictures. Again, you can add them manually.

For Visual Studio to be found automatically, I guess the environment variable VS140COMNTOOLS has to be defined. “140” is version 14 of Visual Studio, which is the version number of Visual Studio 2015. It’s defined by default when Visual Studio is installed. For MinGW to be detected automatically, the bin of MinGW has to be in PATH.

Adding the complete tool-chain/kit

Go to the “Kits” tab. If you have Qt libraries installed and configured, you’ll see them there. I don’t like Qt SDK, and I usually compile my own versions of Qt. You’ll see that in the next screenshot.

What you see in the next screenshot are 3 kits that use Qt libraries, and another that do not. The free version of Visual Studio (2012 and later) comes with both 32-bit and 64-bit compilers. You can choose any one of them, or both (like I do). I don’t use MinGW often on Windows, so I install only 1 version of it (I use MinGW on Windows primarily because it offers the “-pedantic" flag, which gives the chance to experiment with C++ standard-approved features).

Now click “Add”, and choose the fields as shown below (most importantly, configure CMake correctly, it’s a little tricky, and the error on Qt Creator doesn’t tell you what you did wrong)

If you’re getting unexplained errors when running CMake, follow the following instructions carefully

Visual Studio

The following is a screenshot of how Visual Studio configuration should look like (screenshot is for 64-bit)

Set the following

• For the 32-bit compiler: Choose the compiler with (x86)
• For the 64-bit compiler: Choose the compiler with (x86_am64) or (amd64)
• Choose “None” for Qt version
• Choose the correct debugger
• Most importantly: After choosing CMake from the drop-down list, make sure that CMake generator is chosen to be “NMake Makefiles”, and the Extra generator to be CodeBlocks

The last piece of information is the invitation to all kinds of problems. If running CMake doesn’t work, you most likely configured that part incorrectly.

MinGW

The following is a screenshot of how MinGW configuration should look like:

• Choose “None” for Qt version
• Choose the correct debugger
• Most importantly: After choosing CMake from the drop-down list, make sure that CMake generator is chosen to be “MinGW Makefiles”, and the Extra generator to be CodeBlocks

The last piece of information is the invitation to all kinds of problems. If running CMake doesn’t work, you most likely configured that part incorrectly.

I have to say that from my experience, Qt Creator some times fails to run CMake with MinGW with no good reason. I fix this by switching the “Extra generator” to “CodeLite”, and back to “CodeBlocks”. I’m currently using Qt Creator 4.2.0. It might be a bug?

gcc/g++

It’s very easy to get gcc/g++ to work. The following is a screenshot:

• Choose “None” for Qt version
• Most importantly: After choosing CMake from the drop-down list, make sure that CMake generator is chosen to be “CodeBlocks – Unix Makefiles”.  It’s chosen by default, so nothing to worry about.

And you’re done!

What can I do with CMake + Qt Creator?

No ultimate dependence on Qt Creator!

Visual Studio solutions don’t work without Visual Studio. Netbeans configuration is stored in “netbeans project directory”. it’s very annoying that every IDE has its own weird format! I never stop hearing people complaining about porting their programs to other systems and having problems because of this.

One of the things I like most about Qt Creator is the fact that it doesn’t have any special project files for itself. The Makefile itself (CMake file, in this case, or qmake otherwise) is the project file. This ensures not only 100% portability (since both make systems are cross-platform) but also independence of Qt Creator itself. In the future, if the whole Qt Creator project goes down, your project won’t be affected at all.

What if I want to use Qt Creator just as an IDE without having to build a project through it?

I had the “luxury” of getting a project from a space agency to add some features to it, where they had their own build system. I wasn’t able to use Qt Creator to build the project, but…

But why use Qt Creator? Simply because you’ll get

• Syntax highlighting
• target functions and classes following
• advanced refactoring options (like renaming classes, functions, etc)
• Search capabilities in source files.
• Repository updates checking
• Type hierarchy navigation with a click
• And lots more!

With all these, yet, while the project contains a few thousand source files, I was able to add *all* files and parse them with Qt using a few CMake lines. And it was fast enough to handle all that!

How to do it? How to add all these files in one step?

CMake supports recursive adding of source files. Consider the following CMake file (always called CMakeLists.txt):

cmake_minimum_required(VERSION 3.0)
PROJECT(MyProject)

file(GLOB_RECURSE MySrcFiles
 "${CMAKE_SOURCE_DIR}/src/*.cpp"
 "${CMAKE_SOURCE_DIR}/src/*.h"
 )

add_library(MySrcFilesLib
 ${MySrcFiles}
 )

add_executable(MyExecutable main.cpp)

target_link_libraries(MyExecutable MySrcFilesLib)

The first two lines are obvious. The “file" part recursively finds all the files under the directory mentioned and saves them in the variable ${MySrcFiles}. The variable ${CMAKE_SOURCE_DIR} is basically the directory where you cmake file “CMakeLists.txt" is located. Feel free to set any directory you find fit.

The “add_library” part creates a library from the source (and header) files saved in ${MySrcFiles}.

The “add_executable” part  “creates” the executable, which is then linked to the libraries you added.

That last linking part is not necessary if you don’t want to build in Qt Creator.

With such a simple CMake file, Qt Creator was smart enough to add all the source files, parse them, and give me all the functionality I needed to edit that project successfully.

Introduction

Putty can be used to tunnel your connection through your SSH server. It creates a SOCKS proxy that you can use anywhere. The annoying part there is that if Putty disconnects for any reason, you’ll have to reestablish the connection manually. If you’re happy reconnecting putty manually all the time, then this article is not for you. Otherwise, keep reading to see how I managed to find a fair solution to this problem.

Ingredients

For this recipe, you need the following

1. Putty, of course. You could use “Putty Tray”, which supports being minimized to taskbar.
2. Python 3

I understand that you may not have or use Python, but the solution I used depends on it, unfortunately. You could download Miniconda 3,  which is a smaller version of Anaconda 3. Anaconda is my recommended Python release.

How does this work in a nutshell?

The idea is very simple.

1. Create a Putty session configuration that suites you
2. Configure the session to close on disconnect
3. Create a script that will relaunch your putty session on exit
4. Make sure that the launcher you’re gonna use doesn’t keep a command prompt window open (which is why I’m using Python; pythonw.exe solves this issue).

Configuring Putty

To create a putty tunnel proxy, load your favorite session configuration, and then go to the tunnels configuration, and use the following settings, assuming you want the SOCKS proxy port to be 5150. Choose any port you like.

After connecting with this configuration, this creates a SOCKS that you can connect to with the loopback IP-Address, 127.0.0.1 at port 5150.

One more important thing to configure in putty, is to set putty to exit on failure. This is important because we’re gonna set putty to reconnect through a program that detects that it exited to start it again.

Configuring Python and the launch script

Assuming you installed Python 3 and included in your PATH, now you have to install a package called tendo. This package is used to prevent running multiple instances of the program.

To install it, first, run the command prompt of Windows (in case Python is installed directly on the system drive, C:\, you have to run it as administrator). In the command prompt, to ensure that Python is working fine, run:

python -V

If this responds with no error and gives a message like:

Python 3.5.1 :: Anaconda 4.1.0 (32-bit)

Then you’re good to go! Otherwise, make sure that Python is added to PATH, and try again.

To install tendo, simply run in command prompt

pip install tendo

After that, in the directory of putty, write this script to a file:

import subprocess
from tendo import singleton
import time

me = singleton.SingleInstance() #exits if another instance exists

while True:
 print("Starting putty session...")
 subprocess.call('"putty.exe" -load "mysession"')
 print("Putty session closed... restarting...")
 time.sleep(5)   #sleep to avoid infinitely fast restarting if no connection is present

The name “mysession” is the name of your session in putty. Replace it with your session name.

This script simply checks first that the current instance is the only instance, and then runs an infinite loop that keeps running the program every time it exits. So we made putty exit on disconnect, and this program will just run infinitely

Save this script to some file like “MyLoop.pyw”.

Testing the loop

Python has two executables. First is “python.exe”, and the other one is “pythonw.exe”. The difference is quite simple. The first one, “python.exe”, runs your script as a terminal program. The second one, “pythonw.exe”, runs your script without a terminal. It’s designed for GUI applications. Now “python.exe” is not what we need, but it still is useful for debugging the script. So whenever you have a problem or when you want to run this for the first time, switch to/use “python.exe”. Once you’re done and everything looks fine, switch to “pythonw.exe”.

Final step: The execution shortcut

This is not necessary, but it makes things easy. It makes it easy to control whether you want to use “python.exe” or “pythonw”. It makes it also possible to make your script handy. Simple create a shortcut to “python.exe” or “pythonw.exe”, and the first command line parameter should be your script. Remember that “Start in” has to be the directory, where Putty is located. Following picture is an example of how that shortcut should look like.

And you’re good to go! Start with “python.exe”, and once it works, and you find that every time you exit putty or a disconnection happens it relaunches it, switch to “pythone.exe”, and you’re done.

Final notes

This is not a super-fancy solution. This is a solution that’ll get you through and get the job done. If you want to exit the looping script, you’ll have to kill Python from your task-manager.

You may create a fancy taskbar app that’ll do the looping and exits, which I would’ve done if I had the time. So please share it if you do! You can use PyQt or PySide for that.

Conclusion

With this, you’ll keep reconnecting on disconnect, and you can get all your software to use your ssh server as a SOCKS proxy. Cheers!

It sounds simple, I agree. But the problem is like designing a car. You could simply put some wheels together with simple set of chains and create a “car” that moves in your front lawn. But then if you want to design a professional car, you’ll spend much more time and professionalism to do it. And if you wanna build a sports car, you’ll have to fine tune every single parameter of your components to push the edge of what you can achieve.

This story doesn’t apply only to coils, but everything you design (actually I learned it from a book called “Professional C++” in a chapter discussing efficiency of algorithm writing, it’s not far from this case).

Concerning coils, if you just want to generate a few micro Tesla with no concerns about the homogeneity for the coil you’re designing, then it doesn’t matter how you do it. You could just wind a bunch of wires on your hand and your done. Today I’m not talking about such a thing. Today I’m gonna talk about coils that you want to use to generate relatively huge fields, with reasonable homogeneity.

For such specifications, if you’re careless about the details, you may end up wasting lots of time for experimental experience and money for cooling and power supplies. If you plan it carefully, you’ll save lots of money.

Parameters of the system

Any coils you design to generate magnetic fields will have a set of parameters that you have to tune. From those parameters I mention:

• Dimensions and geometry of the coils

• Magnetic field to be generated

• Thickness of the wires to be used

Where to start

The first thing one should determine for a coil system is the geometry of the coils. This is because the purpose of the coils is not just to generate a field, period. But it’s to generate a field over some region that is well defined for a specific experiment. One should know in advance what sample will be exposed to the magnetic field. If you don’t know that, you could spend days working on your coils, and eventually find out that your coils don’t fit your sample, or that your coils are so huge that you’re wasting so much power to generate fields you don’t need (math will show how important the size of your coils vs power is).

Therefore, start by defining the geometry of your coils. Once you know some characteristic radius or length of your coils, you have one step done. One more thing to pre-define, is how much wiring volume you want to use.

Optimum coil thickness

Any person starting with designing coils will have this question in mind: What’s the optimum wire thickness that should be used to have the optimum magnetic field. Guess what? If you know how much wire-volume you will use, then it doesn’t matter at all. Let’s do the math to verify this.

Suppose you have a slot to wind your wires that have a diameter $d$, and the slot has width $w$ and height $h$, as the figure shows. How can we optimally fill your wires in it? The optimal way is what the figure shows; it’s called “hexagonal packing”. This is in case we ignore third dimension’s problems, such as diagonal wires in the slots. This is a good approximation if the wires are wound carefully.

Notice that it’s very important to have a high number of circles per direction. This is to make sure that the flow of the current will be homogeneous in the volume. Imagine the opposite case, if you have one circle with diameter $d=h$. This will modify the magnetic field you expect from the wire as all the calculations of the magnetic field from a wire assume an infinitesimally thin wire.

With that said, let’s calculate the magnetic field from such a configuration. Any magnetic field generated from a current has the following form using the Biot-Savart law or Ampere’s law:

$$B=U\left(r\right)\cdot n\cdot I,$$

where $U\left(r\right)$ is a coefficient that depends on the dimensions of the coils with radius $r$, and $I$ is the electrical current, and $n$ is the number of total turns of the coil. We assumed that we know the geometry of your coil, meaning that $U\left(r\right)$ is fixed before starting this calculation. Let’s see how the wire diameter will modify your magnetic field.

From the definition of resistivity of a wire, we have

$$R=\rho\frac{\ell}{A}=\rho\frac{4\ell}{\pi d^{2}},$$

where R
is the resistance of the wire, $\ell$ is its length, $A=\pi\left(\frac{d} {2}\right)^{2}$ is its cross sectional area and $\rho$ is its resistivity. On the other hand, the power to be exerted on the coil is given by the formula

$$P=I^{2}R\quad\rightrightarrows \quad I=\sqrt{\frac{P}{R}},$$

and from the resistivity formula

$$I=\sqrt{\frac{P}{R}}=\frac{d}{2}\sqrt{\frac{\pi P}{\rho\ell}},$$

and we can put this in a form proportional to the magnetic field

$$B\propto n\cdot I=n\frac{d}{2}\sqrt{\frac{\pi P}{\rho\ell}}$$

There’s still one more question remaining to settle this; what’s the length of the wire required? The length of the wire depends on the diameter of the wire that will be used, since a thicker wire will occupy the area of the slot faster. Whether you wind your wire on a circle or a square, the length of the wire used will depend linearly on the side length or diameter of that geometry. If we call that $r$, then the length of the wire going to be $\ell=n\cdot k\cdot r$, where $k$ is $2\pi$ for a coil on the shape of a circle, and $4$ for a square coil, and $n$ is the number of turns. The formula of current then becomes:

$$n\cdot I=n\frac{d}{2}\sqrt{\frac{\pi P}{\rho\ell}}=n\frac{d}{2}\sqrt{\frac{\pi P}{\rho n\cdot k\cdot r}}=\frac{d}{2}\sqrt{\frac{\pi nP}{\rho\cdot k\cdot r}}.$$

Finally, the number of turns can be seen as the number of circles stacked in a hexagonal packing (as shown in the figure of the hexagonal packing). The number of circles (or cylindrical wires) with diameter $d$ packed in a slot of width $w$ and height $h$ can be approximated assuming a high number of circles (cylinders) per direction

$$n=\frac{w}{d}\cdot\frac{h}{d\cos30^{\circ}}=\frac{2}{\sqrt{3}}\frac{wh}{d^{2}},$$

where the factor $\cos30^{\circ}$ is simply due to the space saved with the hexagonal packing. In fact it doesn’t matter what packing you choose, since all packings will depend inversely on $d^{2}$, which is the important part. With this, the current formula becomes:

$$n\cdot I=\frac{d}{2}\sqrt{\frac{\pi nP}{\rho\cdot k\cdot r}}=\frac{1}{2}\sqrt{\frac{2\pi}{\sqrt{3}}}\sqrt{\frac{ whP}{\rho k r}}.$$

This result shows that the field doesn’t depend on the wire that we choose or the current we use. The magnetic field depends only on the power if the geometry of the coil is fixed.

One more important result here is that the power required is linearly proportional to $r$, which means that if your coils would have half the radius, half the power will be required. Thus it’s considerably important to make the coils as small as possible.

How to choose the wire diameter?

Having the magnetic field not depend on the wire thickness doesn’t mean we can choose it arbitrarily. In fact, the wire determines a very important characteristic, which is the voltage and amperage that we will need to generate. It doesn’t make sense to make a coil that will require 150 amperes and 0.1 volts, and that’s what the wire diameter determines for you. The thinner the wire is, the more resistance the coil will have, and thus more voltage will be required.

Thus, to fine-tune the production of your coil, decide the diameter of the wire after choosing the power supply that has the appropriate voltage and amperage.

Conclusion

It’s intuitive to think that the amount of current will tell how much field you’ll get, this is from simple, classical electromagnetism. However, in reality, it doesn’t really depend on the current. This is because the choice of the current depends on other parameters that are prioritized, such as the geometry of the coils. If the geometry of the coils is fixed, then it doesn’t matter how much current you put, but what matters is practically how much power one will put in.

This result is important for high field generators, since higher fields will entail higher power requirement, leading to heating problems. If your coils generate more heat that your system can dissipate, then it makes sense to think beforehand whether to whether the geometry should be made smaller or different, since smaller geometry means less power requirement.