[Question] Static versus const about tupm HOT 7 CLOSED

I forgot to mention that I altered one of the static definitions to const and found no compile time or runtime issues. This is the example I used in tupm.rs:

31 const DEFAULT_DATABASE_DIRECTORY: &'static str = ".tupm";
 32 static DEFAULT_DATABASE_FILENAME: &'static str = "primary";

As you can see I changed to first line to const (from static).

from tupm.

I altered all statics to const with no difference in execution (afaics). Would the language have changed the semantics for static and const?

from tupm.

Hi Guus,
I agree the usage of static vs. const may not be very consistent in tupm, and most of the statics might be better as consts. I may be trying to outsmart the compiler a bit by thinking "Well, this string necessarily must end up in the ELF .rodata section, so it's static," when the compiler would probably do a better job at deciding which constants to inline and which to store in .rodata.

With strings that are used in their entirety as strings by the code, I think that static and const likely generate identical code. In fact, looking at a disassembly diff, we can see that changing DEFAULT_DATABASE_DIRECTORY from static to const results in identical usage in get_default_database_path(), except the const version is stored at a slightly different address in .rodata:

    d1167:      e9 cb 00 00 00          jmpq   d1237 <_ZN4tupm25get_default_database_path17h0e28588d45951713E+0x367>
    d116c:      e9 8e fe ff ff          jmpq   d0fff <_ZN4tupm25get_default_database_path17h0e28588d45951713E+0x12f>
    d1171:      eb 00                   jmp    d1173 <_ZN4tupm25get_default_database_path17h0e28588d45951713E+0x2a3>
-   d1173:      48 8b 35 8e b7 c5 00    mov    0xc5b78e(%rip),%rsi        # d2c908 <_ZN4tupm25DEFAULT_DATABASE_FILENAME17h8a08d741aaf11f4aE>
-   d117a:      48 8b 15 8f b7 c5 00    mov    0xc5b78f(%rip),%rdx        # d2c910 <_ZN4tupm25DEFAULT_DATABASE_FILENAME17h8a08d741aaf11f4aE+0x8>
+   d1173:      48 8b 35 9e b7 c5 00    mov    0xc5b79e(%rip),%rsi        # d2c918 <_ZN4tupm25DEFAULT_DATABASE_FILENAME17h8a08d741aaf11f4aE>
+   d117a:      48 8b 15 9f b7 c5 00    mov    0xc5b79f(%rip),%rdx        # d2c920 <_ZN4tupm25DEFAULT_DATABASE_FILENAME17h8a08d741aaf11f4aE+0x8>
    d1181:      48 8d 05 28 51 65 00    lea    0x655128(%rip),%rax        # 7262b0 <_ZN3std4path7PathBuf4push17h521bfa1373615ab6E>
    d1188:      48 8d 7c 24 48          lea    0x48(%rsp),%rdi
    d118d:      ff d0                   callq  *%rax

Nonetheless, it may be best practice to prefer consts instead of using statics the way tupm does, so the compiler can make use of inline opportunities when they do happen to be possible.

from tupm.

Thank you for taking the time to explain! I get it. The compiler is a lot smarter than it used to be.

from tupm.

If you want to I can set all static definitions to const definitions.

from tupm.

Sure, you can submit a PR for changing the statics to consts, if you like. There are cases where I think static is more appropriate, but I don't see any static usages in the tupm source that would qualify.

As a quick experiment, to confirm there was no unexpected increase in program size, I did a quick search and replace and compared the results:

for i in `find src -type f -name *.rs`; do echo $i; sed -i '' 's/^\( *\)static /\1const /g' $i; done

Switching static to const saved a few bytes. Not much (~ -0.01%), but it at least didn't make the program larger. (And using const may be better for maintainability since it may more accurately express the intent, in these cases.)

from tupm.

Resolved by a contribution from @gbonnema in PR #8.

from tupm.