151–158 of 158 posts
Earlier quoted context omitted.
Is there a good string-manipulation C library?
Yes, SDS from Redis project. https://github.com/antirez/sds However the moment you call into other C libraries, they naturally only expect a char *.
Earlier quoted context omitted.
My point regarding WG14 wasn't to add SDS as they are, rather vocabulary types for strings and arrays in the same spirit as SDS. When they exist as vocabulary types, the ecosystem can rely on their existence and slowly adopt their use, similarly to threads support introduction in C11, for example.
Apart from plain old fixed buffers, which is what is supported by C just fine and which covers 99% of string processing needs in the areas that C as a language is suited for anyway, ... there are 14 known ways of doing "strings" depending on circumstance, so I don't think it would be a good idea to introduce one mandatory version of them into the C standard. There is already C++ which has std::string, and there are a…
Earlier quoted context omitted.
Object Pascal/Free Pascal then is the obvious choice, it is The better C.
I do use Lazarus/FreePascal for multiplatform GUI apps. It is also very easy to write servers in. Unfortunately performance is worse vs C/C++ and frankly "batteries" included in C++ are way more powerful and simpler to use so I choose C++ for backends. As for all that FUD around C++ - I am not C++ expert at all but I find modern C++ to be very productive, fast for backend development and pretty safe unless one's goal…
Now if you do something like C++ with Qt, that's a very different proposition - but that applies both to batteries being included, and to the overall coding style.
Earlier quoted context omitted.
I remember writing CGI scripts in Perl in 1993 ( the year before Netscape ). I am not sure when CGI even became a thing but it could not have been long before that. Not only was “not so long ago” kind of at the very beginning of meaningful web history but it was also for a very brief moment in time ( if we are talking pre-Perl ). Pre-Perl CGI may have never been a thing though as Perl is older than CGI. I recall PHP…
It is true the time when it might have been sane to write CGI in C was very brief. Perl took over almost immediately (and to my chagrin, eventually PHP ate Perl's lunch). I remember reading CGI books that would explain how to do it in either Perl or C, the justification being "in case you need C for performance" but in reality I don't think a ton of C CGI was written. There was definitely some though; I recall poking…
This feels like an unreasonable eschewing of all the advancements in programmer ergonomics & tooling that have been made over the course of decades. "Just because you can, doesn't mean you should."
Imagine if you were a C developer who needed to create some web do-dads, this is probably a fantastic stack. If there was 1 right solution for the perfect stack we'd all be using it.
This feels like an unreasonable eschewing of all the advancements in programmer ergonomics & tooling that have been made over the course of decades. "Just because you can, doesn't mean you should."
> "Just because you can, doesn't mean you should." Ironically I could say the same about the JS ecosystem.
Earlier quoted context omitted.
Apart from plain old fixed buffers, which is what is supported by C just fine and which covers 99% of string processing needs in the areas that C as a language is suited for anyway, ... there are 14 known ways of doing "strings" depending on circumstance, so I don't think it would be a good idea to introduce one mandatory version of them into the C standard. There is already C++ which has std::string, and there are a…
The fact that C++ was able to eventually standardize on a single string type (despite the same mess of many dozens of incompatible implementations) shows that it is possible and desirable. It's not like raw buffers will go anywhere if you add a higher-level type. Nor does it have to be perfect - only "good enough" for use across the API surfaces of various libraries.
'const char *' arguments work just fine as parameters in libraries, and I don't see much of a use case (and insteaad more hazards) for a library that "resizes" a string argument destructively (like std::string does). The typical way to go about this is for the library to make a copy of the input string. On API boundaries, for memory that is needed longer than the function call lifetime, it is almost always an excellent idea to simply copy it. For data that doesn't make sense to copy (be it because of size or because only one side really needs it), the data should instead simply be created on the right side of the fence from the beginning.
I don't see myself needing a standardized string type because I'm not passing around string "objects", or concatening them, like it would be done in quick and dirty scripts. I honestly can't recall where that kind of thing would have been a good idea for my work in the last couple of years, and I'm much in favour of not growing the standard out of proportion. As said, if you desire C++ kind of ergonomics and want to solve more scripting-like tasks, there is already C++ and a ton of other languages.
What I can recall is skimming through a lot of C projects over the years that tries to do object-oriented and scripting type programming in C (often it wanted to be C++ or Java or even Python but it had to be C for some external reason), and that code is always, invariably, an unmaintainable mess where it's impossible to have a level of confidence that there are no memory errors and leaks. C is simply not suited for that style of programming.
Earlier quoted context omitted.
Yes, have you used any of their devices? They’re amazing in what they let you do, but their UI is a wall of settings. Doing something as simple as adding an access point will take you a full day if you aren’t familiar with it.
Never used it, but your description makes me want to try it ...
If you want something plug and play, I’d look elsewhere.