3 ms·

> Other than operator overloads, you have all those same problems with C. How about no? RAII and exceptions do a lot of stuff that is hard to see (because most

> Other than operator overloads, you have all those same problems with C. How about no? RAII and exceptions do a lot of stuff that is hard to see (because most of the time, there literally isn't any written code that calls them).

josefx 4y ago
> (because most of the time, there literally isn't any written code that calls them). RAII code wont be invoked unless you literally declare an object in the function. You might as well complain that C implicitly reserves space on the stack for variables despite the fact that you did not explicitly call alloca to do it.
- jstimpfle 4y ago
  Well, operator overloads won't be invoked unless you literally write the operators. They can be surprising nevertheless, as the commenter above rightfully expressed. And RAII/constructors/destructors can be surprising and annoying, too. It means buying into a framework, giving up control. This can be a good thing, but it can be hard to control, and be hard to debug, too. alloca() vs stack variables is something different, it's dynamic vs static allocation. You can literally see (ignoring optimization to make this point) all the stack variables that are part of the stack frame. It's in plain sight, very explicit and obvious to the eye. While calls to operator overloads and ctors/dtors are not visible in the plain syntax (type resolution is needed), and in case of virtual methods they might not even be resolved until runtime. So please don't make me angry, this was a really weak refutal. Statements like this are why I am sometimes more critical at C++ than it maybe deserves.
  - josefx 4y ago
    > It means buying into a framework, giving up control The fun part is that you can still use plain old objects if you really really want to deal with C-Strings. > It's in plain sight, very explicit and obvious to the eye. And since RAII applies to variables the same is true in c++, unless you pretend to write C. > and in case of virtual methods they might not even be resolved until runtime. Except the type of a stack allocated object is known at compile time and ctors and dtors are part of that type. For operators you can also generally see from the type if they are overloaded and possibly virtual even if you are not dealing with directly stack allocated objects.
    - jstimpfle 4y ago
      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.

josefx 4y ago

> (because most of the time, there literally isn't any written code that calls them). RAII code wont be invoked unless you literally declare an object in the function. You might as well complain that C implicitly reserves space on the stack for variables despite the fact that you did not explicitly call alloca to do it.

jstimpfle 4y ago
Well, operator overloads won't be invoked unless you literally write the operators. They can be surprising nevertheless, as the commenter above rightfully expressed. And RAII/constructors/destructors can be surprising and annoying, too. It means buying into a framework, giving up control. This can be a good thing, but it can be hard to control, and be hard to debug, too. alloca() vs stack variables is something different, it's dynamic vs static allocation. You can literally see (ignoring optimization to make this point) all the stack variables that are part of the stack frame. It's in plain sight, very explicit and obvious to the eye. While calls to operator overloads and ctors/dtors are not visible in the plain syntax (type resolution is needed), and in case of virtual methods they might not even be resolved until runtime. So please don't make me angry, this was a really weak refutal. Statements like this are why I am sometimes more critical at C++ than it maybe deserves.
- josefx 4y ago
  > It means buying into a framework, giving up control The fun part is that you can still use plain old objects if you really really want to deal with C-Strings. > It's in plain sight, very explicit and obvious to the eye. And since RAII applies to variables the same is true in c++, unless you pretend to write C. > and in case of virtual methods they might not even be resolved until runtime. Except the type of a stack allocated object is known at compile time and ctors and dtors are part of that type. For operators you can also generally see from the type if they are overloaded and possibly virtual even if you are not dealing with directly stack allocated objects.
  - jstimpfle 4y ago
    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.