Databases
StackOverflow2013
Postsdbo
POUse of Literals, yay/nay in C++
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POUse of Literals, yay/nay in C++
    primarykey
    data
    text
    <p>I've recently heard that in some cases, programmers believe that you should never use literals in your code. I understand that in some cases, assigning a variable name to a given number can be helpful (especially in terms of maintenance if that number is used elsewhere). However, consider the following case studies:</p> <p>Case Study 1: Use of Literals for "special" byte codes.</p> <p>Say you have an if statement that checks for a specific value stored in (for the sake of argument) a <code>uint16_t</code>. Here are the two code samples:</p> <p>Version 1:</p> <pre><code>// Descriptive comment as to why I'm using 0xBEEF goes here if (my_var == 0xBEEF) { //do something } </code></pre> <p>Version 2:</p> <pre><code>const uint16_t kSuperDescriptiveVarName = 0xBEEF; if (my_var == kSuperDescriptiveVarName) { // do something } </code></pre> <p>Which is the "preferred" method in terms of good coding practice? I can fully understand why you would prefer version 2 if <code>kSuperDescriptiveVarName</code> is used more than once. Also, does the compiler do any optimizations to make both versions effectively the same executable code? That is, are there any performance implications here?</p> <p>Case Study 2: Use of <code>sizeof</code></p> <p>I fully understand that using sizeof versus a raw literal is preferred for portability and also readability concerns. Take the two code examples into account. The scenario is that you are computing the offset into a packet buffer (an array of <code>uint8_t</code>) where the first part of the packet is stored as <code>my_packet_header</code>, which let's say is a <code>uint32_t</code>.</p> <p>Version 1:</p> <pre><code>const int offset = sizeof(my_packet_header); </code></pre> <p>Version 2:</p> <pre><code>const int offset = 4; // good comment telling reader where 4 came from </code></pre> <p>Clearly, version 1 is preferred, but what about for cases where you have multiple data fields to skip over? What if you have the following instead:</p> <p>Version 1:</p> <pre><code>const int offset = sizeof(my_packet_header) + sizeof(data_field1) + sizeof(data_field2) + ... + sizeof(data_fieldn); </code></pre> <p>Version 2:</p> <pre><code>const int offset = 47; </code></pre> <p>Which is preferred in this case? Does is still make sense to show all the steps involved with computing the offset or does the literal usage make sense here?</p> <p>Thanks for the help in advance as I attempt to better my code practices.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USLenin
    1. USIt'sPete
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POUse of Literals, yay/nay in C++
      1. This table or related slice is empty.
      1. VTApproveEditSuggestion
    2. VO
      singulars
      1. POUse of Literals, yay/nay in C++
      1. This table or related slice is empty.
      1. VTUpMod
    1. COTHE reason for me is, suppose you want to use 0xBEEF in more than one place you'd have to copy-paste it which is nearly always a sign of violating DRY. If you use the constant instead, you just reuse the constant and at the moment you change BEEF to DEADBEEF everybody is happy since they get the updated value (except the beef since it;s now dead :)
      singulars
      1. POUse of Literals, yay/nay in C++
      1. USstijn
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload