Advantages of removing includes which are already in precompiled header? - precompiled-headers

I'm aware of disadvantages, but is there an improvement in compile time when you clean your sources from #include statements which are already in precompiled header?
I understand that header guards (be it #pragma once or #ifdef guards) will ensure that headers which are redundant will be quickly skipped, but is there a slowdown when accessing the header file and checking for the guard? I'm working on quite big project and even minor speedups in small scale could help in big scale.

In my test I inserted header files from precompiled header to the "Force include" field, but the compilation time was the same. So I don't think, than you can get any measurable benefit from removing includes.

Related

How do I overwrite a bitbake conf which references an include

I have an openembedded build for some custom hardware that has a BSP layer. When I build, BSP layer throws an error because the size of one of the file systems is too large. I found this issue in my (names deliberately changed)
meta-my-bsp/conf/machine/machineA.conf
In machineA.conf, there's a line:
require conf/machine/include/machineA.inc
In machineA.inc is the value I need to change to resize my filesystem to make it the right size. When I edit this directly in the meta-my-bsp layer, this compiles and creates the filesystem correctly.
Now, I need to put it into meta-my-layer which is has a higher value than the BSP layer (overrides the BSP layer recipes). So I copied the files into my layer.
meta-my-layer/conf/machine/include/machineA.inc <--- Modified with the value I need
meta-my-layer/conf/machine/machineA.conf (No modifications)
However, when I rebuild everything, it doesn't look like my machineA.inc is getting picked up. Is this the right way to go about it, or am I missing something? I can pull in the whole meta-my-bsp conf and recipes into meta-my-layer, but that seems totally overkill and a bad design. What is the proper way to override this configuration?
To use the machineA.inc from meta-my-layer you should do
require ${COREBASE}/meta-my-layer/conf/machine/include/machineA.inc

Empty CSS/SCSS files and do Angular problems occur?

Sonarqube is displaying errors for empty css/scss files in the Angular application. What are the effects of having empty scss files? Do they cause issues with performance, side bugs/errors, future problems, what are the compound negative issues? These are generally leftover when we do ng generate component
Sonarqube flag: Remove this empty stylesheet
Article below states to ignore it, compiler will take care of it, however more interested in the effects of leaving empty files, if there are any.
Empty style (.css/.scss) files
Company would have to go through 1000+ empty scss files in large application, interested to know if its worth the time.
As far as I can tell from looking into this, the best answer is to just leave it. The compiler will indeed handle the empty files appropriately.
SonarQube is just picking it up as code smell, empty files should probably be removed to keep a project in its least complex state possible. In the example you gave with a company going through that many files it is a complete waste of time.
I come from the future and I face the same problem, our solution was to delete the files that were already empty and generate the new components with the --inline-style option, this way no css/scss files are created by default when create the components.

Merge conflict -strange characters appearing

I am working on an ASP.Net MVC5 project and using vimdiff as my mergetool.
I am getting a merge conflict on a .csproj. This is not unexpected as files get added in different branches all of the time, however it seems that the process of merging is adding some junk data?
This is the state of the csproj on local, base and remote:
And this is the apparent merge conflict:
As far as git is concerned the whole file is now a conflict...
<<<<<< HEAD
WHOLE CS PROJ FILE WITH CHARACTERS AT START
======
WHOLE CS PROJ FILE WITHOUT CHARACTERS AT START
>>>>>> develop
This obviously makes performing a proper merge kind of difficult.
I cannot see these characters in either branch before I try the merge.
Any ideas?
This is an UTF-8 BOM, indicating that the file is encoded as UTF-8. It is only recognised at the start of a file, and since <<<<<< HEAD has been inserted before it, it is no longer at the start of the file, and has been made visible by a tool that does not detect / no longer detects the file as UTF-8.
Ensure that all tools you use to modify the file agree on whether the BOM should be there. If they all agree, then it should never cause a conflict. If some add the BOM when it isn't present, and others remove the BOM when it is present, conflicts are unavoidable.
You just remove the lines you would not see in your source. git add the file(s) and make a commit, so you resolved a conflict.

How to reduce the building time for a Qt program

I have a Qt project which will take around 15 mins to build the program. Each time when I make a small modification I have to wait for long time.
Is there a method to reduce this build time? Or is there a way to "make only the file which I had modified" and then execute the program?
Well check whether your are rebuilding in all your program runs. And also whether you are cleaning your project before running it. Because if you do so, it have to regenerate all those moc files and output[.o] files needed for execution.
But normally upon a small change, the build doesn't take too much time. I have been developing a project by qt creator, it doesn't take too much time while building upon a small modification. But if there is clean/rebuild step while every execution, it will definitely take whole build time. And again even if you manually build your project via terminal without the help of IDE, it won't take that much time provided you don't remove the moc files and .o files manually before building after small modifcation.
If you are using qrc in your app and there are many files in it, it takes too much time to generate qrc.cpp and qrc.obj files. So try to minimize the number of files in qrc system and also try to minimize the sizes of each file.
As far as I know, usage of precompiled headers may help, but effect of that may varay according to you program structure.
The general C++ ways to reduce compile time apply. Don't #include what you don't need. Use class declarations instead of #include'ing the definitions if possible. etc.
It depends where you do that small modification: if you modify something in a header that is included pretty much in every file in your project...
Additionally to above responses, if you work with linux, check out ccache (https://ccache.samba.org/)

QtCreator: a big lot of stray errors

Project was doing fine, running fine, compiling fine. Until some seemingly random time it stopped being fine.
At the moment I'm getting around 200 stray errors:
./new:4: error: stray '\376' in program
./new:4: error: stray '\377' in program
./new:5: error: stray '\376' in program
./new:5: error: stray '\377' in program
From reading other posts it seems I have some bad characters in my code which I cannot see. So I emptied the whole file I was working on, but no luck. This error persists whatever I do.
Also, when compiling main.cpp (which it does first), it first and foremost includes #include , which is the start of the chain of "from 'file'" messages. This means it didn't really parsed much of main.cpp yet but gets borked from reading internal Qt files?
I'm totally gazing in the dark here, what could this possible be, and how would I resolve this?
Thank you!
I'm using Qt 4.7.2, GCC 4.5.0 and Win7.
Copy your code into notepad and save it. Then remove your main.cpp and add the notepad one to your project. Rebuild and check the result. If it still persists then most probably the problem is not with your source but with the Qt or gcc and/or gnulibc libraries. They probably got corrupted or are stored in a different, unsupported encoding.
Octal \376 \377 is 0xFEFF, which is the Unicode Byte-Order Mark. It is used to signal the endianness of a UTF-16 text file, and also to signal that a file is UTF-8-encoded. It should only occur at the start of a file, but it seems to have crept into the header comments in your library header file new, at lines 4 and 5. Locate this file, and delete those lines. (But only if they're comments!)
to me things like these happend in the past when I copied source from some web page. Only typing it again solved the issue. But maybe some tool to convert the encoding might fix the issue as well.
Your source file is probably encoded in UTF-16 or something like that.
Try copy-pasting the code in a new file and see if that helps.
A conflict might exist. For example, I created a project named QTcpServer.pro, but when I tried to #include QTcpServer, I got many stray errors. Renaming my project (QTcpSvr.pro) solved this error.

Resources