c++ versus masm

[hutch--]

Magnus,

The way it works with languages that make object modules that are placed in a library is that any module code that is called is added to the binary by the linker, if it is not called it does not get added. It is called "Linker Resolved Dependencies". If you make the effort to place every algorithm in a separate module, then you have the finest "granularity" and completely exclude unused code.

[jcfuller]

The tests I did awhile ago with VS 2017 indicated that all functions in #included .cpp source files were compiled and added to the exe. If all code was in a single file only those functions called were added.

Hutch:
  I thought /Gy was applicable when creating object modules with VC++ for a library so I did not have to be as granular with the sources. ???

James

[hutch--]

James,

You are talking to the wrong person here, I would not touch C++ with a barge pole. C is OK if written properly and I have seen decent C++ but a lot of it is crap.

[TimoVJL]

msvc -Gy don't help with C++ classes, as they are like structs. Same problems are with SQLite 3, default functions are included.

[daydreamer]

The way it works with languages that make object modules that are placed in a library is that any module code that is called is added to the binary by the linker, if it is not called it does not get added. It is called "Linker Resolved Dependencies". If you make the effort to place every algorithm in a separate module, then you have the finest "granularity" and completely exclude unused code.

I am doing it that as much as I can this last year,using IDE and separate source files and a main console test program
I go for similar kind of code in same module

[TimoVJL]

since ml.exe 12.00 support -Gy , making libs from a one source is possible.
now we have to wait that uasm support it too.

[aw27]

since ml.exe 12.00 support -Gy , making libs from a one source is possible.
now we have to wait that uasm support it too.

UASM probably supports COMDAT because it is mentioned in the JWASM Help file . I never tested, so can't say more.

[daydreamer]

C++ is maybe more portability,but you can trust masm to use register eax,ebx or any register you want to be what you see is what you get,a C++ compiler may or may not use register keyword and if you use masm to write SIMD packed instructions you get vectors to run fast,otherwise you have to trust compiler vectorize it for you and get performance boost
my suggestion is you let C++ compiler output assembly listing and compare that against your masm assembly listing

C++ changes standard different years,while x86/x64 masm stays the same,except adding support for newer opcodes and support use of bigger registers using same old mnemonics,32 to 64bit,256 to 512 bit

[hutch--]

Interestingly enough, ML64 also supports the -Gy switch so when I have some time to play with it, I will see what it does. This much, a library built the old way of one proc for each module, you don't have granularity problems. The -Gy switch may be a convenience but it will not make smaller code that a library written with one procedure for each mosule.

[xanatose]

One thing I like about assembler is that once you get rid of a bug, it will not come back.
Meanwhile with c++ you just remain with a time bomb until the next compiler change breaks your code.
Or when someone tries to "modernize" perfectly good code. Specially when doing it with automatic tools like clang-tidy. Thank goodness for git.