element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Code Exchange
  • Technologies
  • More
Code Exchange
Blog C++ moving and returning objects part 1: object as return value (embedded friendly C++)
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Code Exchange to participate - click to join for free!
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: Jan Cumps
  • Date Created: 19 Jul 2025 11:02 AM Date Created
  • Views 490 views
  • Likes 6 likes
  • Comments 3 comments
  • Modern C++
  • c++26
  • c++23
  • c++
  • c++20
Related
Recommended

C++ moving and returning objects part 1: object as return value (embedded friendly C++)

Jan Cumps
Jan Cumps
19 Jul 2025

You may read guidelines that say: "never use an object as return value of a function. Because of performance reasons". Because the object is copied into the receiving variable when returning from the function call. That was true in C++98. In modern C++, this is no longer true.

Initially (the old days):

  • the return object was locally constructed in your function
  • it was copied (via copy constructor) into the receiving variable
  • the function-local original object was destructed

Now (since 10 years):

  • the return object is directly constructed, on location, in the receiving variable

This behaviour (copy elision) is not optional, or an optimiser choice. C++ compilers have to do that for C++ standard 17 and later (i.e.: from GCC 7.x on).

Example code:

#include <iostream>

using std::cout;
using std::endl;

struct T {
    int value;
    T(int value); // ctor
    ~T();         // dtor
};

T::T(int value) : value(value) { cout << "ctor" << endl; }
T::~T() { cout << "dtor" << endl; }

inline T work() {
    // this object is constructed in place in the variable that's receiving this value (modern c++)
    // it is not created as a function-local variable, then copied and discarded (old days)
    return T(1);
}

int main() {
    T t = work();
    return 0;
}

You 'll notice that the object is constructed once. It's constructed by function work() directly on location in the memory area of variable t.
No copying, or destroying. It's just one object that's available to the caller after the function returns.

It will be destroyed when variable t goes out of scope: when main() exits.

In essence, the code above is using the same assembler as:

int main() {
    T t (1);
    return 0;
}

Run both versions of main(), and check in the output how many times the constructor and destructor are called. Is one more expensive than the other?

Next post: how to efficiently move objects in a program, while avoiding copying large data members.
hint: you can "move" members from one object to the other, instead of "copy, then destroy source"

Thank you for reading.

 C++ moving and returning objects part 1: object as return value (embedded friendly C++) 

 C++ moving and returning objects part 2: move and copy (embedded friendly C++) 

  • Sign in to reply
  • kmikemoo
    kmikemoo 2 months ago

    Good information. Thumbsup

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • DAB
    DAB 2 months ago

    Nice post Jan.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Jan Cumps
    Jan Cumps 2 months ago

    I'm using this technique sparsely in a GPS parser lib I wrote. Several developers that  wanted to use it, challenged performance because I sometimes return an object. This post can help put some context to that question.

    What I learned while writing C++ libraries, is that not a lot of people challenge the functionality. Virtual any comment is about the use of C++, STL, ... As if we were in 1998.
    While there is a lot to gain for embedded designs. Embedded firmware is close to hardware. It's an excellent candidate for object based designs.
    And OO designs come cheap this days. For memory and clock ticks. A lot of times the execution cost is 0 bytes, 0 ticks. But it's expensive for the designer community brain flex ...

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube