Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "how to define C++ interface types". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

I.4 Make interfaces precisely and strongly typed (interface type should be accurate and strict) Reason (reason)

Type is the simplest and best document. Well-defined types can improve readability and can be checked at compile time. At the same time, code with well-defined types is usually better optimized.

Example, don't (negative example)

Consider: (consider the following code)

Void pass (void* data); / / weak and under qualified type void* is suspicious

The caller cannot determine what type the function can accept and whether the data can be modified (because it is not decorated with const). Note that all pointer types can be implicitly converted to void*, so that the caller can easily (casually) provide a value.

The callee must (by tacit understanding) convert the data statically to an unvalidated type in order to use it. Such code is error-prone and lengthy.

Const void* can only be used when passing data that C++ cannot describe in design. Otherwise, consider using variant or pointers to the underlying type as an alternative.

Optional: template parameters can often eliminate void* and use T * or T &. For general code, T here can be a universal or conceptually constrained template parameter.

Translator's note: concept is a new concept that Category 20 has decided to introduce.

Example, bad (negative example)

Consider: consider the following code:

Draw_rect (100,200,100,500); / / what do the numbers specify?draw_rect (p.x, p.y, 10,20); / / what units are 10 and 20 in?

The caller is clear in describing a rectangle, but does not know which aspects are being described (tetragonal coordinates or side lengths). At the same time, the shaping data can carry any form of information, and there are many possibilities for the unit, so we must guess the meaning of the four shaping parameters. The first two are probably x-ray coordinate pairs, but what about the last two?

Comments and parameter names can help, but we can express them more clearly (through parameter types):

Void draw_rectangle (Point top_left, Point bottom_right); void draw_rectangle (Point top_left, Size height_width)

Draw_rectangle (p, Point {10,20}); / / two cornersdraw_rectangle (p, Size {10,20}); / / one corner and a (height, width) pair

Obviously, we cannot catch all errors through the static type system (for example, the fact that the first parameter is the upper left corner is a convention (naming and comments)) Example, bad (negative example)

Consider: (consider the following code)

Set_settings (true, false, 42); / / what do the numbers specify?

The type and value of the parameter does not specify which settings will be modified, nor does it specify the meaning of the value.

This design is more explicit, safe and legible:

The following design is clearer, safer and more readable.

Alarm_settings s {}; s.enabled = true;s.displayMode = alarm_settings::mode::spinning_light;s.frequency = alarm_settings::every_10_seconds;set_settings (s)

For the case of a set of boolean values consider using a flags enum; a pattern that expresses a set of boolean values.

For cases where Boolean values are used in groups, consider using enumerated types; the following pattern can represent a set of Boolean values.

Enable_lamp_options (lamp_option::on | lamp_option::animate_state_transitions); Example, bad (negative example)

In the following example, it is not clear from the interface what time_to_blink means: Seconds? Milliseconds?

In the following example, the interface does not specify the meaning of time_to_blink: is it in seconds or milliseconds?

Void blink_led (int time_to_blink) / / bad-- the unit is ambiguous {/ /... / / do something with time_to_blink / /.}

Void use () {blink_led (2);} Example, good (example)

The std::chrono::duration type (Category 11) can make the unit of time interval clearer.

Void blink_led (milliseconds time_to_blink) / / good-- the unit is explicit {/ /... / / do something with time_to_blink / /.}

Void use () {blink_led (1500ms);}

This function can be designed to accept any unit of time interval.

Templatevoid blink_led (duration time_to_blink) / / good-- accepts any unit {/ / assuming that millisecond is the smallest relevant unit auto milliseconds_to_blink = duration_cast (time_to_blink); / /... / do something with milliseconds_to_blink / /...}

Void use () {blink_led (2s); blink_led (1500ms);}

Enforcement (implementation recommendations)

(Simple) Report the use of void* as a parameter or return type.

(simple) reports the use of void* as a parameter or return value.

(Simple) Report the use of more than one bool parameter.

(simple) reports cases where multiple Boolean values are taken as parameters.

(Hard to do well) Look for functions that use too many primitive type arguments.

(it's hard to do well) find functions that use too many primitive type parameters.

This is the end of the content of "how to define C++ interface types". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.