|
I've been working on truetype font support for my GFX library. Anyway, I wanted to incorporate The FreeType Project[^] and use that in my code. Since it's tight and written in C I figured it would be easy to incorporate**. However, they use the CMake build system and their build scripts are complicated.
So I went on their mailing list/newsgroup and engaged with them about possibly producing a build that would work under platform IO.
I've gotten the go ahead, and some people even seemed excited about it, but I can't work my way through their build scripts, and all the headers have to be included in a very particular order, and and and... it's just too much to wrap my head around without intimately understanding the library's machinations and architecture.
So in the end I started writing my own TTF support because it was actually easier than moving their project off of CMake.
I wish I had never said anything on that newsgroup. That's what I get for trying to use other people's work in my stuff. At least I've had some better success with simpler projects.  I just feel bad getting people's hopes up and then ditching it.
** despite my code being C++, it doesn't use the STL because the Arduino framework doesn't make the STL available so it's easier to incorporate 3rd party C code than C++ code.
Real programmers use butterflies
|
|
|
|
|
Quote: I started writing my own TTF support because it was actually easier than moving their project off of CMake.
If this doesn't speak to the mind-numbing complexity of builds, I don't know what does. There has to be huge opportunity here, because the existing tools are pure shite.
|
|
|
|
|
The problem seems to be that people make things more complicated than they need to be.
This was C so there's only so much you can do about it, but why everyone doesn't just make C++ libs as pure HPP files is beyond me. The extra build complexity is not worth the little bit of extra code hiding you can get by using cpp files. With an HPP you just include the heckin thing.
I mean i get it if your code is proprietary and you want to distribute a static lib you need CPP files, but for anything else don't make it more complicated.
Again, freetype is C so I don't know what they could have done, but for CPP if you work your library right it is easy to build.
It's something that seems like it needs to be in the language. C needs an equiv of an HPP file.
Real programmers use butterflies
|
|
|
|
|
When I was programming C (and Objective-C), oh so many years ago now, I used to find the of .c and .h file very tedious to maintain. Glad there is only 1 file C#! 
That might be one I am not that big a fan of C# interface, compared to my colleagues...
|
|
|
|
|
I just use .hpp files and only use .cpp for the main program.
that way it works almost exactly like C# that way, although static initialization can be cumbersome in C++ especially with members of template classes, pre C++20 but still.
Real programmers use butterflies
|
|
|
|
|
Yea.. I had seen some library doing that last time I used C++....
I thought it pretty neat. 
I tried it myself and it was great except for the abysmal compile time anytime I changed something..  
|
|
|
|
|
yeah, but for the end user of your header it's great.
Real programmers use butterflies
|
|
|
|
|
Quote: why everyone doesn't just make C++ libs as pure HPP files is beyond me. The extra build complexity is not worth the little bit of extra code hiding you can get by using cpp files. With an HPP you just include the heckin thing.
There are a lot more reasons to not put implementations into header files than just hiding proprietary code: reducing dependencies, making code more readable and more maintainable, reducing build time.
You may not be able to appreciate any of this as long as you work on your own and your projects are small. But I assure you that it's well worth the effort for any project with a lifetime of more than 1 year, even if you're the only one maintaining it. And most certainly for any team project.
For example I currently work in plugin development, and our framework to help us create a plugin makes heavy use of templates, so it's header-only. However, these templates force the compiler to pull in pretty much the entire codebase as well as several large third party libraries such as boost, increasing the build time to more than a minute, whereas a simple plugin not using that framework can be built in a second.
It's so bad that I'm currently looking into replacing that framework with a different approach that minimizes dependencies (and therefore build-time). The key concept will be moving all the code that depends on third party libraries into cpp files and putting those into a pre-built library. Building the plugin will then no longer require pulling in hundreds of headers from third party libraries!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
We'll have to disagree on the maintenance thing. CPP files are hateful. You have duplicate too much. Too many potentials for getting that wrong and it's annoying to have to flip back and forth between files if you forget a signature while making the CPP. You can have it.
Besides, HPPs make an easier to use library.
The only reasons I'd use CPP for that are if the implementation in the library is proprietary and I was building a static lib or if the build times were too long.
Real programmers use butterflies
|
|
|
|
|
Quote: CPP files are hateful. You have duplicate too much. Too many potentials for getting that wrong and it's annoying to have to flip back and forth between files if you forget a signature while making the CPP.
With the right tools none of these things ever become an issue. And the advantages of having clean and minimalistic headers easily outweighs the minimal overhead of maintaining additional files and maybe having to actually bind a library to your program rather than just header files.
But as I said earlier, you can only start to really appreciate the benefits of cpp files once the projects get bigger, so I guess we'll never share the same view on this. Let's just leave it at that. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: I guess we'll never share the same view on this
I might, if I had the same requirements you did. I wouldn't like it, however.
I'm happy to agree to disagree though. However, you said something that particularly caught my interest:
Stefan_Lang wrote: With the right tools none of these things ever become an issue.
Okay so I use VS Code primarily for C++ development just because I like it better than Visual Studio for that.
Now, it's easy enough for me to open up another window to the right for my header file.
But what about the code duplication. You said you had tools for this? I'd love to know what you use.
Real programmers use butterflies
|
|
|
|
|
I haven't tried many tools, but VisualAssist for Visual Studio offers a function to change the signature of a function. This will change the function not only in the header and cpp file, it will also rename (if needed) any function calls in the rest of the code, and if you add a function argument, it will insert ToDo comments to help you locate code you need to adapt.
Not sure whether there's a version you can use with VSCode.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
P.S.: here's a description of the function I mentioned: Change Signature[^]
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Quote: and all the headers have to be included in a very particular order
Don't feel bad. You tried. If any build order that satisfies the partial ordering determined by their #include directives doesn't work, they deserve not to be helped, but horsewhipped.
modified 2-Jul-21 18:01pm.
|
|
|
|
|
It could just be me. I'm rough around the edges using make and cmake is almost entirely new to me.
But when i've tried to yank all the source files out and assemble them myself, i can't get anywhere at all.
One of the problems is that you have to include the main header and then a secondary header this way
#include <freetype/ftbuilds2.h>
#include FREETYPE_H
or some such
It's a zoo
Real programmers use butterflies
|
|
|
|
|
I feel ya...
Sometimes, when something is too complicated for what it's worth, I also like to roll my own! 
However, I am surprised the difficult part is the build process, how disappointing! 
|
|
|
|
|
It's just that I don't have an author who can sit me down and walk me through the source tree.
If someone had a few hours to do that with me I could do it no problem.
The issue - or one of them is that the includes don't include prerequisite includes - they expect them to have already been included upstream so..
in one file you might have
#include <stdlib.h>
#include <math.h>
#include <string.h>
int do_something(float x,float y);
and then later on you have another include file that uses do_something() without ever explicitly including the first file. That only works because some file included both of them before. Does that make sense?
So basically I can't unwind which includes depend on what, much less figure out what all the defines are supposed to be without completely reverse engineering their make and cmake files.
And there's many of them, and it's just a maze.
Real programmers use butterflies
|
|
|
|
|
Ha yes that jog some memory... I did have similar problem with GNUstep long time ago....
Which reminds me, on a totally different, yet vaguely related topic, I really like how they handle the dependency in the new C# project file format in visual studio..
|
|
|
|
|
I haven't played with it yet. I've only been using VStudio a little here and there. I've been neck deep in C++ and I use VS Code for that.
Real programmers use butterflies
|
|
|
|
|
"If you build it, they will come..."
For/From an (Indie) software development perspective, does this sentiment even slightly hold true?
Assuming you have identified some need and have found a good/efficient way of providing a (software) solution that works well and is user friendly, how do you get people to:
0) Find it
1) Try/Evaluate it (for free)
2) Get sufficiently engaged in it (i.e. post on message boards / forum / read documentation)
3) Buy or license it
asking for a friend.. ![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif) 
|
|
|
|
|
My perspective, from a somewhat different point of view:
When I create a new way I want things done I introduce it gently at first and then cut the cord and the old way is gone. I already learned years ago, that where I work, users want to do it they way they were doing it = even if it's stupid, irrational, and/or mistake-prone. I'm not overstating this.
So, pretty much I, my fearless leader, and our upcoming (welcome) third wheel make the decisions ourselves and that's how things are.
"Resistance is Futile"
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
As Jerry Pournelle used to write in the Chaos Manor column in Byte magazine (Yes I know I’m old!) -
‘Good enough is the enemy of better.’
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
I'd want more context for that quote.
I interpret it as meaning that a less-expensive product which is "good enough" will out-sell a "better" product which costs significantly more.
Just as MS-DOS outsold OpenVMS, and Ford outsells Porsche -- in numbers at least, if not dollars.
If so, then the quote also applies to "feature creep"; few will pay more for a product simply because it has more features if those features aren't required.
The result being that a developer who's trying to compete can't simply keep adding features in the hopes of gaining market share.
The quality (is job one) and price must remain competitive.
|
|
|
|
|
So let me throw this out there...
Hypothetically...
My software can do perhaps 10% of the things that my (closest/big) competitor can do, but I am offering it at 1% of the cost.
Assuming that the user base spans a sufficiently broad spectrum (not all of them need all of the features), if they currently have 10k users, would you expect my user base to be 100 or 1M?
|
|
|
|
|
I doubt you'd be pulling current customers away from them.
Would your mother buy a copy?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
