I wrote a little test program about just that yesterday and found that clang strangely seems to bypass both the move and copy constructors/assignments for temporary values. It seemed as if it was initializing the values in place, and so I didn't mention it since I didn't really know how to quantify the behavior properly.
What you're describing sounds like return value optimization, but it's hard to say for sure without seeing your test program. It's definitely some form of copy elision, though:
Question, since I'm not a C(++): isn't it preferable when doing multi-core programming to pass small objects by value? Although they're copied it's better than escaping to the heap, no?
Fundamental types (i.e., integral types, floating point types, and pointers) should definitely be passed by value unless the function absolutely needs to modify the original variable. I said to "pass objects by reference" because fundamental types aren't generally thought of as objects in regular conversation (the C/C++ standard, however, uses "object" to describe pretty much anything with a memory address). A good rule of thumb would be "if
sizeof(type*) is greater than or equal to sizeof(type), pass type by value" or something.
I'd add to this that if you're passing by reference, unless you specifically intend for your function to modify the original object, declare it as a reference to a const so that your function explicitly isn't allowed to modify it.
Temporaries can't be bound to non-const lvalue references, so there's also a practical reason to include the const qualifier beyond clarifying your intent to the compiler/other people.
I second that, cppreference is infinitely better. And yes, that is the manifested behavior.
// Rough interface
// Shadows the stack and holds details like named variables, permissions etc.
// Acts as a reverse single-linked-list, allowing the stack to be traversed
struct InvocationContext;
// Holds type details
struct TypeHandle;
// Allocates objects when supplied a type
struct ObjectAllocator;
// Pairs a pointer with a type
struct ObjectHandle
{
// Untyped pointer to the object
void* handle;
// The type of the object
TypeHandle type;
};
// A simple smart pointer type
struct ReturnHandle
{
// The contained object
ObjectHandle object;
// The allocator it was created from
ObjectAllocator* allocator;
~ReturnHandle();
};
// Represents the details of a function invocation
struct Invocation
{
// The context the invocation takes place in
InvocationContext* context;
// The argument to the function
ObjectHandle argument;
// The result of the function
ReturnHandle result;
};
// A function
struct Function
{
// Actual implementation uses function pointers in place of virtual tables, simplified for brevity
virtual void Invoke(Invocation& invocation)=0;
};
// A basic addition function for integers
struct AddIntsFunction : public Function
{
void Invoke(Invocation& invocation) override final {
// Get the context
InvocationContext& context = *invocation.context;
// Try to treat the argument as a tuple and extra two integers from it
auto&& [argA, argB] = ExpandArgumentTuple<int, int>(context, invocation.argument);
// Do our calculation
int result = argA + argB;
// Get the allocator for locals
auto& allocator = context.getLocalAllocator();
// Create an object handle from a lifted int, with the int type
ObectHandle marshalledResult{allocator.Allocate<int>(result), GetType<int>()};
// Set our invocation result
invocation.result = ReturnHandle{marshalledResult, &allocator};
}
};
// Function can be called from c++ like this;
InvocationContext context{/*Construction details omitted*/};
int a = 3, b = 5;
// Create our tuple
Tuple argTuple{GetObjectHandle(a), GetObjectHandle(b)};
// Specify our invocation
Invocation invocation{&context, GetObjectHandle(argTuple), {}};
AddIntsFunction{}.Invoke(invocation);
// Retrieve the result
int result = GetObject<int>(context, invocation.result.object);
// Notes;
// The aforementioned function only works on ints, so in practice a meta function is used which
// deduces the correct add function by inspecting the operands' types before calling it.
// The C++ api is somewhat cumbersome, but a bytecode IL is already underway.
I think knowing how things are done in C gives you an idea of what's behind all the "magic beans" higher-level languages provide you, so you can use them wisely.
I totally get this. I went from oop to the modular type. Its a different shift. You'll pick OOP up just fine because there are a lot of concepts that are still present in higher level and gen purpose languages.
I don't know Objective-C, but roughly:
Does C++ let you go the the same depths of programming memory and threads as C?
Yes. Every standard C program can be rewritten in C++ with very little change. The one thing you could hit is that some environments may support C but not C++, e.g. the Linux kernel. The converse is possible but more rare.
Destructors are nice, and making up (simple) classes is nice. That is, compared to how you'd implement them in C.
I don't think anyone would disagree with you there. Bjarne Stroustrup bolted every language feature he'd ever heard of onto C to create C++, and the language suffered for it.
You'd have to set up your own local web server and database on your computer for it. This seems like it's not worth it for one person.