I'm fighting against the last compiler warnings in a legacy project (MS-COM server, C++-Builder 6), and there are a few warnings left that I ignored previously, because they were raised from generated code for type library stubs (I quote the original German ones, and added a my translation):
[C++ Warnung] utilcls.h(156): W8057 Parameter 'hr' wird nie verwendet.
(parameter 'hr' is never used)
[C++ Warnung] utilcls.h(156): W8057 Parameter 'file' wird nie verwendet.
(parameter 'file' is never used)
I tried "solving it" with local options and pragmas - without success!
Today, I found that the proper solution would be to include ComObj.hpp.
My project uses a set of precompiled headers (collected in one precompiled.h) starting with #include <vcl.h>. The warnings disappear if I include ComObj.hpp before vcl.h, but there are a lot of elements in the project (such as simple tool programs) that have nothing to do with MS-COM...
May it be harmful to include ComObj.hpp in an overall precompiled header set?
Related
it seems to be one of my dependancies but i have no clue whats going on here and i cant find anything on the internet.
(i clearly need to know more about webpack)
any help is muchly appreciated
weirdly enough this only started happening when i cloned my repo on my work pc, i hadnt even made any changes
this is the error im getting from my console
95% emitting
WARNING Compiled with 3 warnings 2:06:09 PM
warning in C:/Users/1/Documents/GitHub/GFS/client/node_modules/webpack/buildin/global.js
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* C:\Users\1\Documents\GitHub\GFS\client\node_modules\webpack\buildin\global.js
Used by 2 module(s), i. e.
C:\Users\1\Documents\GitHub\GFS\client\node_modules\node-libs-browser\node_modules\punycode\punycode.js
* C:\Users\1\documents\github\gfs\client\node_modules\webpack\buildin\global.js
Used by 2 module(s), i. e.
C:\Users\1\documents\github\gfs\client\node_modules\vue\dist\vue.esm.js
warning in C:/Users/1/Documents/GitHub/GFS/client/node_modules/webpack/hot/emitter.js
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* C:\Users\1\Documents\GitHub\GFS\client\node_modules\webpack\hot\emitter.js
Used by 1 module(s), i. e.
C:\Users\1\Documents\GitHub\GFS\client\node_modules\webpack-dev-server\client\index.js?http://localhost:8082
* C:\Users\1\documents\github\gfs\client\node_modules\webpack\hot\emitter.js
Used by 1 module(s), i. e.
C:\Users\1\documents\github\gfs\client\node_modules\webpack\hot\dev-server.js
warning in C:/Users/1/Documents/GitHub/GFS/client/node_modules/webpack/hot/log.js
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* C:\Users\1\Documents\GitHub\GFS\client\node_modules\webpack\hot\log.js
Used by 1 module(s), i. e.
C:\Users\1\Documents\GitHub\GFS\client\node_modules\webpack\hot nonrecursive /^\.\/log$/
* C:\Users\1\documents\github\gfs\client\node_modules\webpack\hot\log.js
Used by 2 module(s), i. e.
C:\Users\1\documents\github\gfs\client\node_modules\webpack\hot\dev-server.js
as it turns out, all i had to do was re navigate to the project dir from my terminal and i had to make sure i was using the correct capitlization there
(git bash sucks)
i used ../Documents/github... insteda of ../documents/github...
thank you internet.
yall have a great day and thanks for the help
No matter how I update the config file I seem to always end up with a space
System.assert(true); becomes System.assert (true);
This is only when the function is called assert
The following both format without a space before the '('
System.asser(true);
System.assertt(true);
Uncrustify config https://pastebin.com/4bnNXzhC
I believe your problem is that Java has an assert statement which Uncrustify's confusing your function call as. Although that wouldn't make much sense considering I tried to test if adding/removing spaces before control statements would change this behavior and it didn't.
I did find a workaround for you through the following configuration options parsing as Java. Since Java supports the assert statement it is a bit odd that they don't have a specific configuration option for it. It may be in your best interest to file a bug report / GH issue with the Uncrustify devs to help better resolve this problem.
# Add or remove space between the user function name and '(' on function
# calls. You need to set a keyword to be a user function in the config file,
# like:
# set func_call_user tr _ i18n
sp_func_call_user_paren = remove # ignore/add/remove/force
set func_call_user assert
Keep in mind that Apex is not an officialy supported language of Uncrustify. So if things don't work specifically for Apex then there's really not much else that can be done.
Is it legal to use variables in printf without supplying the formatting (such as %d, %f).
for example:
printf("value is ok\r\n",myvalue);
The command compiles without errors nor warning, though I am not absolutely sure if it is legal or dangerous.
This reference says
There should be at least as many of these arguments as the number of values specified in the format specifiers. Additional arguments are ignored by the function.
Base on this information, your statement is perfectly legal, however I don't thinks that this is a good idea, since you code could quickly become confusing, which might lead to bugs.
Edit: The original source does not explicitly mention the case of zero arguments. To add another source, the linux man pages states
The format string is composed of zero or more directives.
This source does not discuss what happens with additional arguments. However, combining these two sources gives a definitive answer.
We’ve just migrated a couple of thousand localised strings in an iOS project from an old struct to an enum. We’d now like to find any which are unused.
I’m looking for a way to find any cases of an enum which are not used anywhere within my project, short of searching the project for them one by one.
We have the strings in Objective-C and Swift versions, so either will work.
Any ideas?
About your only option is to comment out each enum value and see which ones result in an error. The ones that don't aren't being used.
If you have a lot of enum values, comment them out in batches of 10 or 15. Do a compile. Scan the errors and uncomment out the values reported in an error. This leaves the unused enum values commented out.
There is a way to automate this, recently I was asked to search for unused endpoints in a large project, to make this semi-automatic:
1- run this grep command, to search for used endpoints
grep -r --include='*.swift' "EndpointEnum"
2- use a text editor (I used sublime), to sort, make unique and save into used.txt
3- add all the enum values in all.txt
4- diff between the two files, and keep the lines starting with a "-"
this will give you the unused enum values.
How should is use yy_scan_buffer in (.y) file( lex and yacc). The return type of yy_scan_buffer is YY_BUFFER_STATE which is in lex.yy.c .
For background: it is an special function called from yy_scan_bytes, which in turn is called from yy_scan_string (likewise can be overridden).
According to String input to flex lexer, the return-type corresponds to a handle which should be deleted using yy_delete_buffer, but that yy_scan_buffer does the deletion. However (looking at the generated code), that does not appear to be correct — perhaps this depends upon the version of flex which is used.
According to these questions, you might want to use yy_scan_string, etc., in writing reentrant code (although the functions predate any work on flex to provide reentrancy):
how to use yy_scan_string(const char *str) (generated by lex yacc) in a separated file
how to use yy_scan_string in lex
Flex's current documentation mentions its use for multiple input buffers:
Some scanners (such as those which support “include” files) require reading from several input streams. As flex scanners do a large amount of buffering, one cannot control where the next input will be read from by simply writing a YY_INPUT() which is sensitive to the scanning context. YY_INPUT() is only called when the scanner reaches the end of its buffer, which may be a long time after scanning a statement such as an include statement which requires switching the input source.
The documentation goes on to provide examples of usage. Depending on what you want to do, those may be useful.