Forem: mdh81

Unraveling the inline mess in C++

mdh81 — Sun, 05 Jun 2022 23:28:32 +0000

In my previous post about inline keyword, I loudly wondered:

I still don't know if a function that's implicitly inline is actually inlined when it's invoked. There is this c++ maxim that says "inline is only a hint and the compiler is free to ignore it". Does that apply to implicitly inlined functions? In other words, if I were to stick a 500 line definition for a function that's defined in the class definition, will the compiler still inline it?

Turns out, this is a valid question because the compiler is NOT guaranteed to inline a member functions that are present in class definitions even though defining them in the class definition implicitly defines them as inline

The answers in this SO clearly states that it's still up to the compiler's discretion to actually inline the calls to this function. I have highlighted the relevant sections from an upvoted answer:

The last comment is more telling because it exactly talks about what was happening to the non-member friend function defined in Foo.h in the previous post. If you were to create a header only library, if you don't use the inline keyword for your non-member functions, you will end up make your library useless. You won't catch this error unless you include your header in multiple sources in your tests (something that's easy to do).

In short, I'm not a fan of this C++ feature. I see SO responses that go to great lengths to explain the feature, but I don't think even the gurus can point to this feature as a strength of the language.

ODR: Member vs non-member functions

mdh81 — Sun, 05 Jun 2022 22:09:10 +0000

I have always found inline keyword in C++ to be a confusing and poorly designed concept. Here is an additional use-case for inline that's designed to obey the one-definition-rule (ODR).

A common C++ operation is to overload the stream insertion operator so you can print your custom types with the expression output stream << <instance of my type>; The correct definition for such an overload is this:

#ifndef FOO_H
#define FOO_H

#include <iostream>


class Foo {
    public:
        Foo() { m_id = 0; }
    private:
        int m_id;

    friend std::ostream& operator<<(std::ostream& os, Foo& f);

};

std::ostream& operator<<(std::ostream& os, const Foo& f) {
    os << f.m_id << std::endl;
    return os;
} 


#endif

Now, if in a source file you do cout << Foo(), the compiler will happily resolve the call to the friend function overload above.

But, what happens when you include Foo.h in two different source files? You run into the dreaded multiple-definitions error for the function operator << (ostream&, const Foo&).

There are two ways to fix this, create a Foo.cpp and move the definition of operator << (ostream&, const Foo&) to that source file and then to build that source file with the rest of your program. The other option is to keep the function definition in the header file but with the addition of the keyword inline like below:

inline std::ostream& operator<<(std::ostream& os, const Foo& f) {
    os << f.m_id << std::endl;
    return os;
}

The presence of the inline keyword tells the compiler to use this definition found in the header file in every translation unit (a source file) where this function is used.

In essence, if you have a function defined in a header file, it better be an inline function, otherwise when multiple source files include it, you will have multiple definitions of that function that run afoul of the ODR rule.

Now, you might wonder why the same doesn't apply to member functions defined in the header file

For example, let's say we add a new member function called getId() to the Foo class like below:

#ifndef FOO_H
#define FOO_H

#include <iostream>


class Foo {
    public:
        Foo() { m_id = 0; }
        int getId() { return m_id; }
    private:
        int m_id;

    friend std::ostream& operator<<(std::ostream& os, Foo& f);

};

inline std::ostream& operator<<(std::ostream& os, const Foo& f) {
    os << f.m_id << std::endl;
    return os;
} 


#endif

Now, one would naturally wonder if two translation units calling getId() would get two definitions of getId() since the same happened when we had operator <<(ostream&, const Foo&) defined in the Foo.h and when two source files included Foo.h.

But, this is not the case--you can include Foo.h in any number of source files and all of them resolve to the single definition of getId() defined in Foo.h. Why is this? In their infinite wisdom C++ designers choose to implicitly inline all member functions defined in the class definition

I still don't know if a function that's implicitly inline is actually inlined when it's invoked. There is this c++ maxim that says "inline is only a hint and the compiler is free to ignore it". Does that apply to implicitly inlined functions? In other words, if I were to stick a 500 line definition for a function that's defined in the class definition, will the compiler still inline it?

There you have it. If you find inline keyword confusing, you're not alone. It makes no sense to me to make a language feature so unintuitive.

C++ Concepts In Action

mdh81 — Sun, 15 May 2022 05:23:16 +0000

C++20 has a new feature called Concept that allows developers to specify constraints on template parameters. Template meta programming is a complex topic that stumps even seasoned veterans. I found an interesting usage of this feature to ensure that I can write an overloaded stream insertion operator that can output C++ containers that support range based iteration (basically types that have begin and end methods).

#include <iostream>
#include <unordered_map>
#include <array>
#include <vector>
using namespace std;

template<typename ContainerType>
concept SupportsRangeBasedFor = requires(ContainerType container) {
    container.begin();
    container.end();
};

template<typename KeyType, typename ValueType>
ostream& operator<<(ostream& os, const pair<KeyType, ValueType>& p) {
    os << p.first << "->" << p.second;
    return os;
}

ostream& operator<<(ostream& os, SupportsRangeBasedFor auto&& container) {
    os << "[ ";
    for (const auto& element : container) {
        os << element << ' ';
    }
    os << ']' << endl;
    return os;
}

int main()
{
    cout << vector<int>{1,2,3} << endl;
    cout << array<int,3>{4,5,6} << endl;
    cout << unordered_map<int,int>{{8,9},{10,11},{11,12}} << endl;
    //struct Foo {};
    //cout << Foo {} << endl; // Compiler Error: No overload for operator<< that accepts Foo
    return 0;
}

Running this program produces this output:

~/code/cpp/concepts > ./concept
[ 1 2 3 ]

[ 4 5 6 ]

[ 11->12 10->11 8->9 ]

So, we have a single overload that can support any container that has a begin and end method. This is not magic, you could have got this to work without SupportsRangeBasedFor concept, but the magic is what the concept prevents from happening:

Without the constraint on the template parameter, compiler would have happily chosen operator<< overload for Foo and you would get an indecipherable blob of errors caused by the fact that Foo doesn't have begin and end methods. You will see errors of this nature:

concept.cpp:22:30: error: invalid range expression of type 'Foo'; no viable 'begin' function available
    for (const auto& element : container) {
                             ^ ~~~~~~~~~
concept.cpp:35:10: note: in instantiation of function template specialization 'operator<<<Foo>' requested here
    cout << Foo {} << endl;

Not only that, the compiler would match any ostream.operator<<(...) call to this overload because the template parameter type (introduced by auto type specifier) will match all types.

The type constraint expressed by the concept explicitly forbids the compiler from picking up your template function for types that you don't wish to support. This is a pretty neat feature and I hope to be using this quite widely in my future development to limit the types that my implementation should be chosen for :)

Tab/window management with titles

mdh81 — Thu, 21 Apr 2022 04:16:12 +0000

Do you get lost managing multiple tabs or windows in your terminal emulator? If so, this trick might be handy to your shell toolbox.

Define a function like this in your shell profile

function title {
    echo -ne "\033]0;"$*"\007"
}

And then when you open your all important terminal window or tab, call the function and pass a string to it like so:

$ title <title string>

Viola, you have a handy way of identifying your terminal window/tab and not be lost in a forest of tabs or windows.

Isn't this neat?

Now, let's explain this function a bit. echo needs no introduction. -n stands tells echo not to print a new-line after the message. -etells echo to interpret escape sequences.

The trick that makes this work is the text flanked by xterm escape sequences and sequences themselves.

\033 Escape
\077 Bell
]0; Identifier for window title and icon
"$*" String that contains all arguments passed to echo

Most terminal emulators support these xterm sequences. I tested in iterm and it works beautifully. Go ahead, try it out and help yourself navigate the terminal tab/window maze.

References:

https://tldp.org/HOWTO/Xterm-Title-3.html
Stackoverflow threads on this topic.

Integer to void* conversion

mdh81 — Sun, 10 Apr 2022 15:36:41 +0000

I came across this intriguing OpenGL code snippet

glVertexAttribPointer(colorAttrib,              
                      1,                        
                      GL_FLOAT,                 
                      GL_FALSE,                 
                      3*sizeof(float),          
                      (void*)(2*sizeof(float)) // FTW?!
                      );

glVertexAttribPointer's signature says the last argument is of type void*. This argument is supposed to tell OpenGL what the offset is into a vertex buffer array data.

This looked surely wrong to me--how the hell can you cast an integral type to a pointer and use that pointer meaningfully? To demonstrate that this doesn't compute, I wrote a simple program like so:

#include <iostream>
using namespace std;


void fooFunc(void* ptr) {
    int* intptr = reinterpret_cast<int*>(ptr);
    cout << *intptr << endl; // **Crashes here as expected**
}


int main() {
    fooFunc((void*)(12*3));
    return 0;
}

Sure enough, it crashes when it tries to de-reference the int pointer because the void* that the int* is converted from is pointing to garbage memory.

While it was clear that it was garbage memory, it wasn't immediately clear to me how the value of that pointer could be used. Understanding that was the key to unlocking how this awkward OpenGL API was working.

In fooFunc, ptr's value was 0x24. Clearly, garbage memory. But, it's also the result of the integer expression 12*3 from which the pointer was created in the calling code! Now, how can this be useful for anyone?!

Consider this new version of fooFunc

void fooFunc(void* ptr) {
    size_t intval = reinterpret_cast<size_t>(ptr);
    cout << intval << endl; // ** prints 36 **
}

Now, we have managed to make something out of the dangling void pointer! We have managed to get the integral value that the caller wanted to pass to this function without passing an integral value, instead the caller passed a pointer!

Now, why can't glVertexAttribPointer simply use an integer parameter type and save us the trouble of staring hard at this mysterious looking code? The answer, like it most often is in cases like this is--legacy. Apparently, there was time when OpenGL would allow glVertexAttribPointer()'s last parameter to be used to specify a pointer to the vertex data array in the CPU memory. Post VBOs, we transfer the vertex data to the GPU via glBufferData() call and don't need to pass it via glVertexAttribPointer() call. The Khronos group decided to make this API backward compatible and decided to overload the last parameter to allow the user to set an offset into vertex buffer array data. So, we ended up with this awkward (void*)(2*sizeof(float) cast from integer to pointer.

References:
https://stackoverflow.com/questions/28063307/in-opengl-why-does-glvertexattribpointer-require-the-pointer-argument-to-be-p
https://stackoverflow.com/questions/58679610/how-to-cast-an-integer-to-a-void-without-violating-c-core-guidelines

Answer: C++ inlining class methods causes undefined reference

mdh81 — Wed, 23 Feb 2022 07:01:53 +0000

answer re: C++ inlining class methods causes undefined reference

Jan 22 '11

7.1.2/4 of the Standard:

An inline function shall be defined in every translation unit in which it is used...

You use TestMethod in main.cpp, but it's not defined there.

... If a function with external linkage is declared inline in one translation unit, it shall be declared inline in all…

Open Full Answer

Answer: MacOSX: which dynamic libraries linked by binary?

mdh81 — Tue, 22 Feb 2022 07:05:01 +0000

answer re: MacOSX: which dynamic libraries linked by binary?

May 22 '19

Rob Mayoff's answer is a great solution when working with executables. If you find you need to check the runtime dependencies of a dylib, the following script my-ldd may be useful.

#!/usr/bin/env bash 

while getopts "r" OPTION; do
  case $OPTION in   
    r) export DYLD_PRINT_RPATHS=1;;
  esac
done
shift $((OPTIND-1))

cp `which

…

Open Full Answer

Answer: How to initialize private static members in C++?

mdh81 — Sun, 06 Feb 2022 03:23:53 +0000

answer re: How to initialize private static members in C++?

Oct 9 '08

617

The class declaration should be in the header file (Or in the source file if not shared).
File: foo.h

class foo
{
    private:
        static int i;
};

But the initialization should be in source file.
File: foo.cpp

int foo::i = 0;

If the initialization is in the header file then…

Open Full Answer

Answer: Am I using the copy_if wrong?

mdh81 — Sat, 05 Feb 2022 23:15:11 +0000

answer re: Am I using the copy_if wrong?

Mar 25 '11

The copy_if algorithm looks something like this(taken from MSVC2010):

template<class InIt, class OutIt, class Pr> inline
OutIt copy_if(InIt First, InIt Last, OutIt Dest, Pr Pred)
{
    for (; First != _Last; ++First)
        if (Pred(*_First))
            *Dest++ = *First;
    return (Dest);
}

And as you can see the copy_if does not do…

Open Full Answer

Answer: Why would one use nested classes in C++?

mdh81 — Sat, 05 Feb 2022 06:16:55 +0000

answer re: Why would one use nested classes in C++?

Dec 31 '10

262

Nested classes are cool for hiding implementation details.

List:

class List
{
    public:
        List(): head(nullptr), tail(nullptr) {}
    private:
        class Node
        {
              public:
                  int   data;
                  Node* next;
                  Node* prev;
        };
    private:
        Node*     head;
        Node*     tail;
};

Here I don't want to expose Node as other people may decide to use the…

Open Full Answer