I am starting to be proficient enough with C++ so that I can write my own C++ based scripts (to replace bash and PHP scripts I used to write before).
I find that I am starting to have a very small collection of utility functions and sub-routines that I'd like to use in several, otherwise unrelated C++ scripts.
I know I am not supposed to reinvent the wheel and that I could use external libraries for some of the utilities I'm creating for myself. However, it's fun to create my own utility functions, they are perfectly tailored to the job I have in mind, and it's for me a large part of the learning process. I'll see about using more polished external libraries when I am proficient enough to work on more serious, long term projects.
So, the question is: how do I manage my personal utility library in a way that the functions can be easily included in my various scripts?
I am using linux/Kubuntu, vim, g++, etc. and mostly coding CLI scripts.
Don't assume too much in terms of experience! ;) Links to tutorials or places where relevant topics are properly documented are welcome.
"Shared objects for the object disoriented!"
"Dissecting shared libraries"
Just stick your hpp and cpp files in seperate directories somewhere. That way, it's easy to add the directory containing the C++ files to any new project, and easy to add the headers to the include path.
If you find compile time starts to suffer, then you might want to consider putting these files in a static library.
If you are compiling by hand you will want to create a makefile to remove the tedium of compiling your libraries. This tutorial helped me when I was learning to do what you are doing, and it has additional links on the site for more detailed tutorials on the makefile.
Unless it's very large, you should probably just keep your utility library in a .h file (for the declarations) and a .cpp file (for the implementation).
Just copy both files into your project folders and use #include "MyLibrary.h", or set the appropriate directory settings so you can use #include <MyLibrary.h> without copying the files each time you want to use them.
If the library gains substantial size, you might consider looking into static libraries.
Related
In the past I have created a jar file that contained many "helper functions" that I used and made common to many different applications. I felt this was important as anytime I used my "helper" jar file in any new applications or when making changes to any existing ones, the latest and most up to date version of my "helper" jar was always used. It was developed separately and had it's own version control.
I'm looking to do something similar with C/C++
At the moment I have a collection of headers, doing something similar to my "helper" jar in java but finding it cumbersome managing changes, ensuring the most up to date collections are used. So for example, if I made some changes to these "helper" headers, I need to copy them into each project and rebuild.
If we take the below as an example of what I do in Java;
and the below is the structure that I'd like to do something similar with in C++;
I'd like some way of keeping my_includes separate so that any changes I made to my_includes are automatically included in any existing or new applications, in the way Utilities.jar is in the above Java example
I accept that I cant build a library or such as it won't then be as portable, right?
I suspect I'm missing something quite obvious, just not to me.
All helpful comments appreciated, thanks in advance...
At first you could create a library from your utilitis.cpp and all include files independently and add this library to any project. I just provide URL for sample generate the static and shared library.
Create static and shared library (GCC)
And then you can add custom include files to any project in c++ just need to add the specific directories to your include Path in compile time base your platform or if you use cmake you can edit the "include_directories". And also you should link the generated library to your project as described in provided URL.
I have some C++ code (exposing a C-only interface through a header) which I will use for an iOS project.
I can either create a static library and link to this from my app project, or add the source files directly to the app project - which option is best?
All answers appreciated!
Add the sources if you expect them to change often. Otherwise a library will be more suitable and will make your project cleaner (however, you will have to put only the header files in your project)
I've used OpenCV in one of my app projects which is mostly written in C++. I've found that adding the source files to the app project worked better for me because I made some minor changes to the code wherever appropriate. Comes down to the use case basically.
I always prefer to add the source if I have it, simply because it makes debugging easier. If you're making a call into a library routine and getting back an unexpected result (or crashing, or whatever), it's much easier to step into the library code with the debugger and figure out what's going on. If you just have a static library, it's a black box and you can't see what's going on inside. It also allows you to change the library code more easily if you encounter a bug or a missing feature (just be careful if the library is shared among other projects, to make sure you keep the library code up to date in its own repository).
Xcode is good about letting you keep your project organized, so use those features to your advantage. Keep the library code and headers separate from your main application and link it in as needed.
I suppose by code you don't mean a well formed library, so I expect this code could get any kind of modification pressure in the future. The best way is then wrapping it. here is one very nice example, but you might do it differently: http://robnapier.net/blog/wrapping-cppfinal-edition-759
I am not sure this strictly a programming question, so I apologize if it is not.
I developed a few libraries in C++ that I mean to use in several different projects.
Till now I kept copying the updated library in the folders of the various projects.
As you can imagine this is not ideal, so I would like to create a "3rd-parties" folder
where I save the libraries I write and other that I might download in the future.
How can I do this? And considering I'll want to share/release my code later on what is the best strategy to be sure that the used libraries are included in the code I deploy?
There are no hard and fast rules. But if these are 1) general-purpose, for 2) global sharing, then I'd suggest /usr/local/lib (for your .a and .so libraries) and /usr/local/include (for the corresponding headers).
Here's a good description of "standard file locations" for Linux:
http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/Linux-Filesystem-Hierarchy.html
If you want to share your modules with new project its better to organise them in a single folder and mark this folder as included library path in your new projects.
how do I correctly implement Lua in a C++ program? I downloaded the Lua source, put the .c files in my src folder and the .h files in my include folder, included lua.h in my program's source code (with extern "C"{} of course) and hit "Build".
That's how all the tutorials tell me to use Lua with a C++ project.
But now I get the error "multiple definition of main" and some Symbols in the Lua code that could not be resolved. I understand what the first error means (conflict because Lua has a main and my program also has one), but how can I solve it?
Or did I understand something completely wrong about implementing Lua in a C++ program?
Check to make sure you didn't include luac.c, lua.c, and the source for any other programs that are included with Lua in with your source code. Lua's source includes a few extra utilities (i.e., luac), and chances are you've just included them in the project and forgotten to remove them, thus resulting in having more than one main.
In short, those are separate programs that you don't add to your project. If you can, just build Lua normally, link to the library, and include the header files as normal.
So, on the point of you misunderstanding how to use Lua, you probably did to some degree. It is entirely possible to just copy Lua's source into your code, though probably not advisable. What you really want to do is pull up the extracted Lua source in a terminal and build it. Then (according to Lua's INSTALL document), you'll want to type make platform, where you'll replace platform with whichever platform you're currently using (i.e., I'd use macosx, you might use linux, refer to the INSTALL for which platforms are supported). After that, it's up to you if you want to install it or not, but you'll just do make install (or sudo make install) to get that done.
After that, either add the appropriate linker flags when compiling to link to Lua (e.g., -llua) or alter your project's settings in your editor of choice to do roughly the same thing. That said, you'll want to refer to the INSTALL document provided with Lua for complete instructions on this.
I'm embedding Lua in my projects other way around, preferred way, IMO: compiled Lua as a static library.
Just comment the two main() blocks in Lua.c an Luac.c, then hit build and run again.
I made this on Lua 5.3.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
This questions concerns mostly Unix/Linux style C++ development. I see that many C++ libraries store their header files in a "include" folder and source files in an "src" folder. For the sake of conformance I adopted this in my own code. But it is not clear to me whether this should be done for application code as well. I've seen a few cases where a flat directory structure is used for that. What would be the recommended approach?
I also separate them, but not strictly on the extension, but on the access of the file.
Suppose you have a module that manages customer information and uses 2 classes to do this: Customer, CustomerValidityChecker.
Also suppose that other parts in your application only need to know about the Customer class, and that the CustomerValidityChecker is only used by the Customer class to perform some checking.
Based on these assumptions I store the files like this:
Public folder (or include folder):
customer.h
Private folder (or source folder):
customer.cpp
customervaliditychecker.h
customervaliditychecker.cpp
That way, it becomes immediately clear for callers of your module which parts are accessible (public) and which parts aren't.
We have a build system that auto-generates our makefiles. One thing it does is recursively descend any subdirectories and build them as libraries, linking them together with the main directory's objects to make the application. (In practice, these "subdirectories" are usually symbolic links.) Libraries are static unless the directory name ends in ".so". One thing that's nice about this is that a full build of our system, which has many executables, doesn't have to repeatedly compile the common libraries.
However, as a result of this, there's no separation of headers and sources. And it has never been a problem. Honestly, I think it's better this way because headers and source files have commonality of location, and you can grab a directory and know you got everything you need to use it. It also works great with Subversion's "externals" feature, and similar features in other VCSs.
One last place where an include/src separation fails is if you use any code generators, such as flex, bison, or gengetopts. Figuring out where these tools should put their outputs so they get built is tricky if you've spread things out.
It makes sense to separate them for shared libraries because they may be distributed in a compiled form without the source. I've seen projects that separate out "public" headers (headers that may be accessed from code outside your project or library) while leaving "private" headers and source files in the same directory. I think it's good to use a consistent approach whether you're writing shared library or application level code because you never know when you may want to turn something that you've written at the application level into a lower level library that is shared by multiple projects.
A lot depends on the size of project involved. Up to a few dozen files or so, keeping them in one directory tends to be more convenient. For a bigger application that includes hundreds or thousands of files, you start to look for ways to separate them (though in the projects I've worked on, it was done more on functional lines than src/include). In between those, it's probably open to question.
I don't do this; there seems little advantage in it. Since headers tend to have a different extension from source files, you can have your editor show them separately if you really feel the need -- Visual Studio does this by default, but I disable it since I prefer seeing them together
Bottom Line: sources and headers that are still changing go in /src. Code that has crystallised should go in /lib & /include (actually you could keep all .libs and their .hs in /lib).
Keep own sources and headers together, provided they are (a) specific to this project or (b) have not yet been factored out as a shared library.
Once certain sources in the main project have been factored out as a (relatively stable) library, place the .a or .lib into /lib, and its public interface header into /include.
All third party libraries and their public interface headers also go into /lib & /include.
As others note, it is often more compatible for tools / IDEs to access .h/.c from one folder. But from an organisational view it can be useful to separate changing local code from stable lib code.
There is no clear advantage to either in my view. I finally decided to keep program and header files together because my editor (Visual SlickEdit) happens to provide additional referential features when they are not separated.
I almost always create include and src folders to split up my source code. I think it makes the folder less cluttered and files are easier to find in my IDE. But I think this is just a matter of taste.
Either method is valid. It depends on the coding style you want to follow how you do this.
I place include (header) and source files in the same directory (folder). I create different folders for different themes. I get frustrated when trying to find header files (while debugging and also for researching). In some shops, there are only two folders: source and includes. These directories tend to grow exponentially. Reusing code becomes a nightmare at best.
IMHO, I believe organizing by theme is better. Each theme folder should build into at least one library. Different projects can easily include the themes by searching or including the folders. The projects only need to include the libraries. Smart build engines can list the theme folders as dependencies. This speeds up the build process.
The theme organization also adds a bit of safety to the project. Accidental damage to files (such as removing the wrong ones or replacing with different versions) is reduced since files are located in different directories. Deletion of files in the "Person" folder will not affect files in the "Shape" folder.
This is just my opinion, Your Mileage May Vary.
We have a build system which use this rule. This build system is sconspiracy a set of scripts to configure SCons and dedicated to the C++ world. You can see an example which use this tools : fw4spl