I've had a major annoyance with the C++ Builder IDE for some time now. When I code I always use a standard layout for the code files. I have a standard header that I use, including, ie. the License of the file, filename, date, etc.
But I haven't been able to find anywhere to insert this, so that when I - for instance - create a new unit, get this header inserted automatically. Of course I can just paste it in, every time, but it gets a bit irritating to use time doing this.
So my question is - is it possible to create a file template for default C++ files or modify the existing ones so that they always start with my predefined layout. My fear is that just as with most other things in the C++ Builder IDE, this is hardcoded into it.
Currently creating a new unit creates a .cpp file with:
//---------------------------------------------------------------------------
#pragma hdrstop
#include "Unit1.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
and a corresponding header file with:
//---------------------------------------------------------------------------
#ifndef Unit1H
#define Unit1H
//---------------------------------------------------------------------------
#endif
This is what I wish to alter to my own defined layout.
I'm using Codegear C++ Builder 2007.
See "Adding Items to the Object Repository" in the help file.
Basically,
1. Create the unit file(s) as you wish
2. Go to Project -> Add to Repository
3. Add information.
4. It will be available from the File -> New... area
There are also ways to share and edit repository items. The default distribution items are not quite as flexible, but creating your own should do just what you need.
For the defaults, see the answers to the question on reducing the "uses" clause boilerplate also located on stack overflow. This would require the same changes.
Related
I'm using C++Builder. I want to include a header file that is located in a separate folder from my project.
I tried to add the folder to the search path, and include the file in my project:
#include "GXWARE32\Include\gxutils.h"
but when I compile I have some errors in the file included
So, I tried to add all subfolders to the search path, and it works with a small folder but not with a big one.
According to the error log, maybe you missed some header file that gxutils.h relies on.
Without code, we can only guess... some libs need a specific #include order... some libs have hard-coded relative paths and by moving them you broke that... Some libs also need configuration macros defined before #include.
From the errors, you have #include'd some file more than once (and it's not protected by a header guard, like #pragma once or #ifndef file_id #define file_id ... #endif macros) and you are missing a previous #include for some datatype used.
Open the gxutils.h file and look around line 143 for the missing datatype. In the IDE, during compilation the cursor usually stops on the stuff directly. Then just search the files in your lib for the datatype, so you know what file to #include before...
All of these might happen sometimes if you include the wrong file... some libs need to include cpp instead of h...
Adding search paths will not do anything as the compiler is not complaining about files not found...
I need to add headers to an already existing program by transforming it with LLVM and Clang.
I have used clang's rewriter to accomplish a similar thing in the changing function names and arguments, etc.
But the header files aren't present in clang's AST. I already know we need to use PPCallbacks (https://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html) but I am in dire need of some examples on how to make it work with the rewriter if at all possible.
Alternatively, adding a #include statement just before the first
using namespace <namespace>;
Also works. I would like to know an example of this as well.
Any help would be appreciated.
There is a bit of confusion in your question. You need to understand in details how the preprocessor works. Be aware that most of C++ compilation happens after the preprocessing phase (so most C++ static analyzers work after that phase).
In other words, the C++ specification (and also the C specification) defines first what is preprocessing, and then what is the syntax and the semantics of the preprocessed form.
In other words, when compiling foo.cc your compiler see the preprocessed form foo.ii that you could obtain with clang++ -C -E foo.cc > foo.ii
In the 1980s the preprocessor /lib/cpp was a separate program forked by the compiler (and some temporary foo.ii was sitting on the disk and removed at end of compilation). Today, it is -for performance reasons- some initial processing done inside the compiler. But you could reason as if it was still separate.
Either you want to alter the Clang compiler, and it deals (like every other C++ compiler or C++ static analyzer) mostly with the preprocessed form. Then you don't want to add new #include-s, but you want to alter the flow of AST given to the compiler (after preprocessing), and that is a different question: you then want to add some AST between existing AST elements (independently of any preprocessor directives).
Or you want to automatically change the C++ source code. The hard part is determining what you want to change and at what place. I suppose that you have used complex stuff to determine that a #include <vector> has to be inserted after line 34 of file foo.cc. Once you've got that information (and getting it is the hard thing), doing the insertion is pretty trivial. For example, you could read every C++ source line, and insert your line when you have read enough lines.
I have a file which looks something like this:
#include <Shlwapi.h>
...
void SomeFunction()
{
UrlCombineW(...)
}
This compiled just fine until I installed another Delphi component in C++ Builder IDE but now reports unresolved external for UrlCombineW. The above call was fine before installing this component.
It seems that the component is overwriting this in some way so I need to explicitly tell the compiler where to look for UrlCombineW. This is a function from Shlwapi.dll.
Compiler does not complain, but how do I explicitly tell the linker where to look for this function and avoid unresolved external error?
Expanding my comment to an answer.
You need to link to Shlwapi.lib in order for the linker to find the functions. (This explanation glosses over a few things, but a .lib, a library file, can be either a static or import library. A static library contains the functions themselves - it's basically a collection of .obj files bundled together; an import library says that functions X, Y and Z are found in a specific DLL.) Either way, if you link the .lib in you will get the functions that you need.
There are a couple of ways to do tell the linker to link in the file:
Use #pragma comment(lib, "Filename.lib") in a .cpp file somewhere. For your case, this is #pragma comment(lib, "Shlwapi.lib").
Add it to the project options, which in turn adds it to the linker command line. In C++ Builder you do this by actually adding the .lib file to the project, ie drag and drop it onto the project in the Project Manager, or use File > Add To Project.
Which you prefer is up to you. I tend to link to localized things locally - so in my code, there's only one unit which uses Shlwapi.h and the fact it does so is an implementation detail hidden from the outside, it's not shown in the interface. Therefore, in that file, I link using #pragma comment at the point I include the header. On the other hand, if you have something used far more widely - to pick the widest example, kernel32.lib - I would add that the project itself. (Note this is an example, you don't actually need to explicitly link to kernel32, that will be done for you!)
I am new to HLSL and in all of the tutorials I found there always seems to be a #include "Fxaa3_11.fxh" in each of them. I include this file and then it also makes a reference to another header file #include "Fxaa3_11.h" and as it goes I also include this file into my content pipeline and still gives me an error X1507: failed to open source file:... whichever way I go.
Is there any way to make a clean, single FXAA.fx file without enabling all this mess of external files?
If you want to compile your shader on the fly , you can use this function
Most important part when using includes is to provide a CompilerIncludeHandler ,include resolves are not automatically done for you (which is a good thing).
You override the open method, then read the include path from the parameters and return the content as a string.
If you just want to have if processed in content manager, Easiest way is probably just to copy paste the content of those header files in the main shader file (where the include is), and delete the include statement. Bit ugly but pretty simple.
Hi I use interop to call C# code in Delphi.
C# code has a binary and in Delphi 5 Menu: Project-->Import Type Library
Click Add to add the tlb file: XXXX.tlb
Unit dir name: input the path where the delphi XXX_TLB.pas file is generated.
If the C# dll, tlb and delphi XXX_TLB.pas has already been there. Now I add one more function in C# code and hope Delphi can call this function as well. I need to recompile c# and regenerate delphi XXX_TLB.pas file. But by following the above steps, I see the newly generated XXX_TLB.pas includes my newly added function, but looks like the functions order in XXX_TLB.pas is totally different from before.
For example, in my C# binary I have function:
func1();
func2();
func3();
func4();//newly added
In the old XXX_TLB.pas, the function order is:
func1();
func2();
func3();
Now XXX_TLB.pas is like this:
func1();
func3();
func4();
func2();
The XXX_TLB.pas can still be used, looks like no functionality difference, but when I check in to tfs, I see it changes a lot from pervious version. Is there a way to keep this new XXX_TLB.pas the same order as before but add my function as well? How to do that? Thanks!
You cannot hope to keep the changes to a minimum unless you start writing the .pas file yourself. That sounds like a worse option.
Probably what is happening is that you have changed version of either one of your compilers since the last time you imported. Otherwise one would expect minimal differences.
Just check it in with a comment stating which versions of compiler and .ocx/.dll were used.
You can't, as far as I know.
I most cases, I'm able to consider them as a sort of "black box" anyway, and only occasionally have to peek in them to find a specific declaration.