How to define C++ Builder ProgramID? - configuration

I know where to change the ProgramID key, this isn't the issue.
By default, C++Builder defines ProgramID as com.embarcadero.$(ModuleName), but when I Google it, this format is not in line with MSDN's description (my guess is that ProgID is the same thing). According to MSDN, the format is: <Program>.<Component>.<Version>.
So, are MSDN ProgID and C++Builder ProgramID the same thing? What format should I use for my own programs?

Related

Does anyone know how to get argument name automatically in Visual Studio Code?

Look at the below-given image of Intellij IDEA -
When we use a function it automatically provides the argument name and when we copy a code-snippet then that argument name is not copied(it is just for our reference).
I want to do the same in my vs-code editor but, I can't find any way to do it.
Looks like Inline Parameters for VSCode extension you looking for.
There is a new version of VS Code, there they had given support for Parameter hint highlight See the release notes
This feature, called "parameter hints", requires support from the language server, so whether or not this is currently supported varies from language to language.
For C++, clangd has experimental support for this (enabled by adding --inlay-hints=true to "clangd.arguments") starting from clangd 13.
I'm not familiar with the status for other languages, so will let others answer on that front.

Where can I find WebAssembly's binary instructions table

I am making a webassembly compiler, and I need to know WebAssembly's binary instructions to generate the wasm file. The problem is that there seems to be no source of the opcodes. I can only find just some short examples, but I need the full instructions table. I also need to know how code blocks, functions and other statements are expressed (in raw binary format)
The primary source for this information is the WebAssembly specification which has a specific section that covers the binary format:
https://webassembly.github.io/spec/core/binary/index.html
There is also a non-official guide which is a little more compact and readable:
https://github.com/sunfishcode/wasm-reference-manual

checkstyle module name ConstantName vs ConstantNameCheck

I have a question to ask regarding checkstyle.
It seems that the checkstyle api accepts both module name,
ConstantName and ConstantNameCheck (ConstantName with Check concatenated) for the configuration file, checkstyle.xml.
I would like to ask why is there a double standard here even though documentations on http://checkstyle.sourceforge.net/ only promotes ConstantName module and what is the difference between using either of them? Will either one of them gets deprecated in future?
Thanks!
Behind the scenes, the ConstantName check is implemented by a Java class called
com.puppycrawl.tools.checkstyle.checks.naming.ConstantNameCheck.
You could actually refer to the module in checkstyle.xml by this so-called "fully qualified" name. The other notations are shorthand offered by Checkstyle for convenience. ConstantNameCheck is the simple name of the implementing Java class, and ConstantName is still shorter. Checkstyle will try all three variants when looking for the module in your checkstyle.xml. So, there is no difference between these notations.
The recommended way is to use the most concise form, ConstantName, but as far as I know, none of the other forms is going to get deprecated any time soon.

What is the difference between binary and source compatibility conceptually ?

In the context of webkit in chromium source code ,it says it is source compatible but not binary compatible. Does it suggest that we build .dll file of webkit and build it with chrome binary ?
(This answer doesn't talk about the specific context of WebKit - it's not clear what exactly you mean by the various "it says" parts. I've tried to give a more general answer.)
Suppose we have a library called LibFoo, and you have built an application called SuperBar which uses LibFoo v1.
Now LibFoo v1.1 comes out.
If this is binary compatible, then you should be able to just drop in the new binary, and SuperBar will work using the new code without any other changes
If this is only source compatible then you need to rebuild SuperBar against v1.1 before you'll be able to use it
I would think of it from the point of view of Linking
Linking is the process of taking a class or interface and combining it into the run-time state of the Java Virtual Machine so that it can be executed.
Linking a class or interface involves verifying and preparing that
class or interface, its direct superclass, its direct superinterfaces,
and its element type (if it is an array type), if necessary.
If introducing a new change breaks the linking, then it is not source (code) compatible (as well as binary compatible)
If introducing a new change does not break the linking, then it is at least binary compatible

Microsoft Translator: Does GetLanguagesForTranslation() translate language names into the browser language?

This may be a stupid question, but I have no way of testing this with multiple languages.
I am wondering if the Microsoft Translator translates the list of supported languages into the language detected by the browser? I assume is does, but would appreciate validation.
TIA
GetLanguagesForTranslate() returns the set of supported languages IDs.
GetLanguageNames() takes an array of languag IDs and returns the friendly name of the language in the language you specify in the "locale" parameter, where locale is the ISO639 language code.
You may listen to the browser's accept-language setting and pass the first element of it to the locale parameter. That's what the Bing Translator home page does (www.bing.com/translator)