4 ms·

Have you made any effort trying to understand what I'm saying? Because you're almost making all my points. How does your definition of "in plain sight" not make

Have you made any effort trying to understand what I'm saying? Because you're almost making all my points. How does your definition of "in plain sight" not make a difference between "I can see which functions are called from a piece of code printed out on paper" and "I need to look up the type to see if there's an overloaded operator or method or a non-default constructor/destructor, and to get there I might need an advanced code browser, probably based on compiler infrastructure -- and I must like actually hit go-to-definition to navigate to the site"? > The fun part is that you can still use plain old objects if you really really want to deal with C-Strings. Strings are just buffers like any other, nothing special. It's easy to see you've never seriously programmed C, because strings are like 0.1% of my concerns. They just work where they have to, and otherwise string manipulation is 99% done in places where a C programmer wouldn't even do it. If string manipulation in C becomes annoying, you should have written a Python script. > The fun part is that you can still use plain old objects if you really really want to deal with C-Strings. I'm sure you've heard this before, but... how exactly do I know that anything is a POD structure? And if everything is, so I can assume that anything is, where's all the advantages gone?

josefx 4y ago
> and I must like actually hit go-to-definition to navigate to the site"? If you feel like it is too much effort you can just not do it? I can't remember the last time I checked, ctors and dtors should do basic setup and teardown. Counterquestion, how do you know a specific C struct wont overflow your stack without looking? We are assuming that everything important is visible inline, right? > Strings are just buffers like any other, nothing special. It's easy to see you've never seriously programmed C I have seen way too many hand rolled parsers on C, they may have been only 0.1% of the total code but they amounted for at least 50% of the bugs, along with the constant manual memory management and badly initialized variables. > If string manipulation in C becomes annoying, you should have written a Python script. That is an interesting statement to make for someone who claims to almost never write C string handling code. As someone who has to deal with strings, std::string is simply supperior in most cases so I prefer to use C++ where I have the choice. > where's all the advantages gone? That was in response to the "locked into a framework" claim.
- jstimpfle 4y ago
  > I have seen way too many hand rolled parsers on C, they may have been only 0.1% of the total code but they amounted for at least 50% of the bugs, along with the constant manual memory management and badly initialized variables. I have written a number of parsers for programming languages and can't recall ever having a string bug. It's all about creating the right abstractions. A parser is not about string handling! The typical (lexical) parser scans input from left to right and builds up (identifier and string literal) tokens by appending. So basically, you need a function input_read_char() and string_push_char(). When the string is built up, it gets allocated in the global parser state. The "string" now is a pointer or pointer+length, and you can freely copy it around by value as you like, knowing that the string memory is immutable and allocation is already taken care of. The string memory management is just a large shared push buffer in the parser that pools all the strings in a central place. If you ever need to release resources, you clear out all strings in one swoop by freeing the push buffer. There is no need to track individual strings. Allocating string storage using a general-purpose memory allocator, and tracking them individually is wrong. It's a general-purpose approach that lacks the right structure, wastes memory and is super slow. std::string doesn't change any of that. As I said, if you have lots of string allocations then write a script. You're done, there is no other string indexing or string allocation in a parser. > That is an interesting statement to make for someone who claims to almost never write C string handling code What I want to say is that if you're dealing with a lot of strings, you're working in a high-level glue domain. And there is no point in using either C or C++. You're probably making a web API, or an ad-hoc throwaway thing. I do write lots of mini-programs to support development. It need not be python, possibly it should even be a shell or awk script. Most of them they live and die in my command-line history, or as a 5-line script in my /tmp folder. Using C++ for these tasks would slow me down by 10x.

josefx 4y ago

> and I must like actually hit go-to-definition to navigate to the site"? If you feel like it is too much effort you can just not do it? I can't remember the last time I checked, ctors and dtors should do basic setup and teardown. Counterquestion, how do you know a specific C struct wont overflow your stack without looking? We are assuming that everything important is visible inline, right? > Strings are just buffers like any other, nothing special. It's easy to see you've never seriously programmed C I have seen way too many hand rolled parsers on C, they may have been only 0.1% of the total code but they amounted for at least 50% of the bugs, along with the constant manual memory management and badly initialized variables. > If string manipulation in C becomes annoying, you should have written a Python script. That is an interesting statement to make for someone who claims to almost never write C string handling code. As someone who has to deal with strings, std::string is simply supperior in most cases so I prefer to use C++ where I have the choice. > where's all the advantages gone? That was in response to the "locked into a framework" claim.

jstimpfle 4y ago
> I have seen way too many hand rolled parsers on C, they may have been only 0.1% of the total code but they amounted for at least 50% of the bugs, along with the constant manual memory management and badly initialized variables. I have written a number of parsers for programming languages and can't recall ever having a string bug. It's all about creating the right abstractions. A parser is not about string handling! The typical (lexical) parser scans input from left to right and builds up (identifier and string literal) tokens by appending. So basically, you need a function input_read_char() and string_push_char(). When the string is built up, it gets allocated in the global parser state. The "string" now is a pointer or pointer+length, and you can freely copy it around by value as you like, knowing that the string memory is immutable and allocation is already taken care of. The string memory management is just a large shared push buffer in the parser that pools all the strings in a central place. If you ever need to release resources, you clear out all strings in one swoop by freeing the push buffer. There is no need to track individual strings. Allocating string storage using a general-purpose memory allocator, and tracking them individually is wrong. It's a general-purpose approach that lacks the right structure, wastes memory and is super slow. std::string doesn't change any of that. As I said, if you have lots of string allocations then write a script. You're done, there is no other string indexing or string allocation in a parser. > That is an interesting statement to make for someone who claims to almost never write C string handling code What I want to say is that if you're dealing with a lot of strings, you're working in a high-level glue domain. And there is no point in using either C or C++. You're probably making a web API, or an ad-hoc throwaway thing. I do write lots of mini-programs to support development. It need not be python, possibly it should even be a shell or awk script. Most of them they live and die in my command-line history, or as a 5-line script in my /tmp folder. Using C++ for these tasks would slow me down by 10x.