|
Managed to order mine without much difficulty, took a couple of minutes mainly due to fact that unusually, I had a mobile signal that was strong enough to receive the OTP that day.
My problem was the postman. I have noticed in the past that reading addresses does not seem to be his strong point judging from what he pushes through our door and, he duly delivered my tests to the right house number in the wrong street.
|
|
|
|
|
My Windows 10 Update and security keeps nagging me about "2021-06 Cumulative Update Preview for Windows 10 Version 21H1 for x64-based Systems (KB5003690)".
I don't do "Previews". What is this one about? Have you tried it? Did you like or hate it? Was it any help?
Curious in NOLA
|
|
|
|
|
I am also a compulsive updater who wondered about that...
But I guess I am becoming less compulsive in my old age and thought screw it, I will just ignore that! 
|
|
|
|
|
Super Lloyd wrote: , I will just ignore that!
Until the settings delay is done and then they don't ask anymore, you just download it without knowing and get only prompted "when do you want to restart" once the silent install got to the point... 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
now ignore.. until it goes from preview to it's good know, install it, and then it does!
|
|
|
|
|
Me too!
What ever happened to XP?
|
|
|
|
|
This is why I run a domain with a WSUS server at home. The nightly cleanup scripts eliminate non en-us language updates, preview updates, and a whole host of other updates that don't apply to myself or my wife.
|
|
|
|
|
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..
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
