bloomberg / bde

Basic Development Environment - a set of foundational C++ libraries used at Bloomberg.
Apache License 2.0
1.68k stars 318 forks source link

Where can I ask questions about BDE C++ Coding Standards? #274

Closed tuchang closed 2 years ago

tuchang commented 2 years ago

in 7.2 Interface Conventions

4 Outputs must be passed by pointer, never by modifiable reference (except where required for con- sistency with an externally-defined API).

what is the reason for the rule? or where can I ask for explanations?

Thanks.

osubboo commented 2 years ago

This convention (historically) is motivated by the following reason: Passing by pointer allow users clearly see that the given parameter is an output parameter.

The hidden information in this convention is that the BDE API uses output parameters ( as opposite to returning by value). In the case where the output type is an allocator aware type, the caller constructs the object with the correct allocator and passes it to the function. Objects returned by value use default allocator and in some scenarios limit the correct usage of allocators on the client side.

tuchang commented 2 years ago

Thanks

tuchang commented 2 years ago

passed by pointer, never by modifiable reference

This convention (historically) is motivated by the following reason: Passing by pointer allow users clearly see that the given parameter is an output parameter.

The hidden information in this convention is that the BDE API uses output parameters ( as opposite to returning by value). In the case where the output type is an allocator aware type, the caller constructs the object with the correct allocator and passes it to the function. Objects returned by value use default allocator and in some scenarios limit the correct usage of allocators on the client side.

Passing by pointer (type*)as output value is opposite to returning by value. Modifiable reference(type&) is more like returning by value instead of an output parameter. Are these correct?

RMGiroux commented 2 years ago

Passing by pointer (type*)as output value is opposite to returning by value. Modifiable reference(type&) is more like returning by value instead of an output parameter. Are these correct?

I'm not sure I understand what you're asking completely, but we never use return by modifiable reference (unless we're implementing a standard method that's specified to use it, but I can't think of any offhand).

Consistently using return by pointer is better for all the reasons @osubboo mentioned, and, addtionally, makes it clearer what's going on at the call site:

int i;
int rc;

rc = f(i);  // Is 'i' passed in by value/const&, or by modifiable reference?  
            // In the bde code base, it's always a value or const &, and 
            // you don't have to worry about 'i' being modified.
rc = g(&i); // 'i' is likely to be modified by 'g'

Other code bases use other standards, and might indicate that an argument is likely to be modified by the name of the method, for instance, but the BDE code base consistently uses pointer types for output parameters.

tuchang commented 2 years ago

My question is that "what is the reasoning behind 'consistently uses pointer types for output parameters' and 'never by modifiable reference'?".
Previous answer seems saying "because using pointer type output parameters is as opposite to returning by value" "the reason is that a pointer parameter is an clear output parameter"
I believe that rc = g(&i);(modifiable ref)is more like rc=g((int*)ptr)(passing by pointer as output) instead of rc = f(const& i);(const ref) or rc = f(i);(return by value)
Therefore, a modifiable reference could also be a clear output parameter and as opposite to returning by value, so I got a littlle confused.

My currently understanding is that the reason behind the standard is that bde didnt implementing methods to use it. (otherwise a modified reference is ok, because it can also fulfill the requirements/principles of an output parameter)
I didn't know it before because I just read bde coding standards trying to find some best practices but I didnt check the implementation of bde yet.

Thanks