C++ Stockholm Syndrome

[TheCPUWizard]

@dkf said in C++ Stockholm Syndrome:

@gąska said in C++ Stockholm Syndrome:

When people say "throw", they usually mean "throw to the outside of currently running function".

IME, exceptions always pass over function boundaries because the throw machinery always delegates to a function to actually do the dirty deed. But that's totally an implementation detail. (I've not figured out yet why nobody makes the throwing a built-in intrinsic as there's always exactly one correct way to do it for a particular target and the compiler knows what that target is, but that's how it goes.)

Throwing is intrinsic, but catching is not. The "target" is not known until actual execution time as it is "somewhere up the call stack"

[dkf]

@thecpuwizard said in C++ Stockholm Syndrome:

Throwing is intrinsic, but catching is not.

The other way round. Throwing is done by calling out to a library (which is basically just a “does not return” function), but catching is built in to the code generated by the compiler as it intimately affects the flow graph.

[TheCPUWizard]

@dkf said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

Throwing is intrinsic, but catching is not.

The other way round. Throwing is done by calling out to a library (which is basically just a “does not return” function), but catching is built in to the code generated by the compiler as it intimately affects the flow graph.

foreach [using C# for this example] is intrinsic to the compile, but it calls out to a function also!

Catching an exception is not "built in to the code generated by the compiler", although the usage of try/catch/finally is.

There are many ways to process an exception (i.e. catch) it, but for most languages the intrinsic keyword throw is the only defined way to originate it.

[LB_]

@kian said in C++ Stockholm Syndrome:

Strictly speaking throwing in the destructor is fine, even if the destructor was called in the context of stack unwinding, as long as you don't let the exception leave the destructor.

Here's a fun example of that from an old thread on this forum: http://melpon.org/wandbox/permlink/PscHg988AnzjajyS

[pie_flavor]

@thecpuwizard said in C++ Stockholm Syndrome:

@pie_flavor said in C++ Stockholm Syndrome:

For the record, in C#, int is the same type as System.Int32 and string is the same type as System.String, so that first line is wrong as well.

What?

What what? [i.e. context for post, it is not clear the reference point of the question]

Ah, finally figured out what he was talking about. C# doesn't have 'primitive' types, so they aren't lowercase, but does have library types, which are pascal case. So it's still wrong.

[pie_flavor]

This post is deleted!

[TheCPUWizard]

@pie_flavor said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@pie_flavor said in C++ Stockholm Syndrome:

For the record, in C#, int is the same type as System.Int32 and string is the same type as System.String, so that first line is wrong as well.

What?

What what? [i.e. context for post, it is not clear the reference point of the question]

Ah, finally figured out what he was talking about. C# doesn't have 'primitive' types, so they aren't lowercase, but does have library types, which are pascal case. So it's still wrong.

All (build-in, as well as those custom that follow convention) .NET Types are ProperCasedIdentifiers. C# also has keywords [in lower case, just like virtually every language] that are aliases for certain Types.

[Kian]

@thecpuwizard said in C++ Stockholm Syndrome:

@kian said in C++ Stockholm Syndrome:

Was busy, so I'm going to answer some stuff even if I know I was ninja'd already.
@thecpuwizard said in C++ Stockholm Syndrome:

re: Constructors and Exceptions..... The reason for the "olde school" of NO, was because an exception in the constructor does not invoke the destructor.

This is not right. An exception in the constructor will invoke the destructors of the child items already constructed, in reverse order of construction, and this was always true. This required a tiny amount of careful planning around any resource acquisition in the constructor, in that you either can't have throwing operations between the time the resource is acquired and the constructor exits, or you had to immediately hand the resource to a container that handled the clean up for you (smart pointer members for memory allocations, for example).

You are right, but so was I (although I could have communicated it better). I was specifically referring to the destructor of the instance where the constructor threw the exception; not the destructor(s) of those members who had been successfully constructed.

foo()
{
p_bar = new bar();
p_bar->barf(); // throws exception
}

~foo()
{
delete p_bar();
}

Ok, yes, but you said that "this is why throwing constructors were not used" (paraphrased) when that's not correct. Even with C++98, you could throw perfectly safely, by just changing that to:

foo()
{
  std::auto_ptr<bar> barPtr = new bar();
  barPtr->barf();  // throws exception, auto_ptr handles cleanup
  p_bar = barPtr.release(); /* assuming you don't want your member to be an auto_ptr itself,
      which is reasonable since auto_ptr has been deprecated since C++11 and removed in C++17
      because of its weird copy behavior (copying actually transfers ownership) */
}

~foo()
{
  delete p_bar();
}

The reason people didn't like throwing constructors was not exception safety (the destructor not being run), which was always a solved problem, but simply that they were something new they distrusted. Avoiding constructors that could fail let them do two stage initialization the way they used to do it in C.

[TheCPUWizard]

@kian said in C++ Stockholm Syndrome:

Ok, yes, but you said that "this is why throwing constructors were not used" (paraphrased) when that's not correct. Even with C++98, you could throw perfectly safely, by just changing that to...

Clearly one could have changed the code. My point is that so much code existed, and the effort to transform (for a variety of reasons) took many years for the statistical majority of the existent code to move from what I posted to what you did.

The reason people didn't like throwing constructors was not exception safety (the destructor not being run), which was always a solved problem, but simply that they were something new they distrusted. Avoiding constructors that could fail let them do two stage initialization the way they used to do it in C.

Very much a similar point. And the reasons for "distrust" came from a number of directions - including a distrust that they would have caught 100% of the necessary transforms to make it safe without introducing potential bugs.

[Kian]

@thecpuwizard said in C++ Stockholm Syndrome:

Clearly one could have changed the code. My point is that so much code existed, and the effort to transform (for a variety of reasons) took many years for the statistical majority of the existent code to move from what I posted to what you did.

Not sure I understand what you mean. That style was available from day 1. There should not have been a need for any transformation, except for poor training making people write bad code. Which then becomes a matter of best practices taking time to develop and spread in a new language (especially before the internet) and not an issue of the design of the language.

[blakeyrat]

@dkf said in C++ Stockholm Syndrome:

That makes it sound like self-evolving magic.
Bullshit. The libraries are there because programmers wrote them. End of.

It's not even true.

Python's been around since 1995. Try finding a working SOAP library in it. Go ahead, try.

[TheCPUWizard]

@kian said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

Clearly one could have changed the code. My point is that so much code existed, and the effort to transform (for a variety of reasons) took many years for the statistical majority of the existent code to move from what I posted to what you did.

Not sure I understand what you mean. That style was available from day 1. There should not have been a need for any transformation, except for poor training making people write bad code. Which then becomes a matter of best practices taking time to develop and spread in a new language (especially before the internet) and not an issue of the design of the language.

That sounds like you do actually understand. It was never "an issue of the design of the language" it was about two things:

a) The work required to do a minimal transform into C++ [but not a full OO re-design]

b) The training of the people involved [remember a lot of "C" was written by engineers of different disciplines who had never been "formally" (I do not necessarily mean school/university) trained.

[boomzilla]

@blakeyrat said in C++ Stockholm Syndrome:

@dkf said in C++ Stockholm Syndrome:

That makes it sound like self-evolving magic.
Bullshit. The libraries are there because programmers wrote them. End of.

It's not even true.

Python's been around since 1995. Try finding a working SOAP library in it. Go ahead, try.

So if we can think of a particular thing that some ecosystem doesn't have then it doesn't have libraries?

[topspin]

@boomzilla Let's assume for a minute that his claim Python has no working SOAP library is correct (I doubt it, but I have no fucking clue).

The argument was:

• I'm using C++ because there's libraries I need, which aren't available in X.
• Not an issue, this will solve itself, just a matter of time until these libraries exist.
• That didn't work, for example, in Python, which is over 20 years old.

You can't prove something by example, but you can disprove by counter-example. If you were to accept his premise, the conclusion seems correct.

[Gąska]

@blakeyrat said in C++ Stockholm Syndrome:

@dkf said in C++ Stockholm Syndrome:

That makes it sound like self-evolving magic.
Bullshit. The libraries are there because programmers wrote them. End of.

It's not even true.

Python's been around since 1995. Try finding a working SOAP library in it. Go ahead, try.

For the second time this week, I'm completely stunned how much the world has changed in the last five years. Python used to have fairly decent* SOAP libraries, but now there is not a single one that's still maintained. Though if you're making a new web server, you're usually in complete control of what the protocol is, right? And for clients, there's Zeep.

* My decency standards are heavily skewed by C++.

[Gąska]

@topspin said in C++ Stockholm Syndrome:

Let's assume for a minute that his claim Python has no working SOAP library is correct (I doubt it, but I have no fucking clue).

Alas, it's true.

@topspin said in C++ Stockholm Syndrome:

You can't prove something by example, but you can disprove by counter-example.

And that's what he just did.

[boomzilla]

@topspin said in C++ Stockholm Syndrome:

The argument was:

I'm using C++ because there's libraries I need, which aren't available in X.

Not exactly. It was that popular languages eventually get libraries for "everything." Well, I'm sure we can go out and find holes in library coverage for any language out there. So it depends on whether you're reading "everything" as literal or as hyperbole.

Blakey is an idiot who always reads things the wrong way and I stand by my previous statement.

[Gąska]

@boomzilla for what it's worth, when I said "everything", I meant it quite literally. I really didn't expect something as popular as SOAP not being available for Python.

Well, let's just hope "everything" doesn't include SOAP anymore in 2025, just like it doesn't include Windows XP support now.

[Unperverted Vixen]

@gąska said in C++ Stockholm Syndrome:

Well, let's just hope "everything" doesn't include SOAP anymore in 2025, just like it doesn't include Windows XP support now.

2025 is optimistically early. Maybe ASP (classic) will finally be dead by then, but I bet my company will still be supporting software using SOAP for at least another 5-10 years past that.

[Gąska]

@unperverted-vixen said in C++ Stockholm Syndrome:

@gąska said in C++ Stockholm Syndrome:

Well, let's just hope "everything" doesn't include SOAP anymore in 2025, just like it doesn't include Windows XP support now.

2025 is optimistically early.

Yes, I could edit my earler post where I made that 5-10 years prediction, but that would be dishonest, and would leave a trace of my dishonesty in form of edit counter.

[ben_lubar]

@thecpuwizard said in C++ Stockholm Syndrome:

C# also has keywords

C# keywords are dark voodoo magic that work on an alien system of logic that just happens to line up with what a human would expect most of the time.

[dkf]

@blakeyrat said in C++ Stockholm Syndrome:

Try finding a working SOAP library

It's my experience that there are two mutually hostile camps when it comes to SOAP: Java and C#. Each claims that the other doesn't have a working SOAP library (because of subtle differences in the interpretation of the absolute shitload of standards in the space) and neither really accepts that the perfectly adequate but rather less baroque things done in virtually all the other languages out there are proper implementations at all. It's all a matter of what you get when you throw tens of thousands of cheapest-bidder contract programmers at a task and assume that what they've produced is correct, and that applies both ways; languages which don't pour a few million into implementing every minutiæ of SOAP (and why would you do that!?) tend to have less complex handlers, especially in the area of the more esoteric parts of WSDL handling.

Only really big corporate bothers with paying to bull through the colossal headache that is a full SOAP stack. Everyone else just doesn't need that crap and makes do with the smallest subset they can (or thinks “fuck that for a game of soldiers!” and uses REST, which just needs a reasonable HTTP library and JSON parser/generator on the client side).

[Gąska]

@ben_lubar said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

C# also has keywords

C# keywords are dark voodoo magic that work on an alien system of logic that just happens to line up with what a human would expect most of the time.

Really? It's very simple - type keywords are simple aliases for some specific types in standard library. When does it ever not line up with human expectations?

[ben_lubar]

@gąska said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

C# also has keywords

C# keywords are dark voodoo magic that work on an alien system of logic that just happens to line up with what a human would expect most of the time.

Really? It's very simple - type keywords are simple aliases for some specific types in standard library. When does it ever not line up with human expectations?

var var = await await; is valid syntax.

[Gąska]

@ben_lubar backwards compatibility is a hell of a drug.

[TheCPUWizard]

@ben_lubar said in C++ Stockholm Syndrome:

var var = await await; is valid syntax.

Only if the second await is something that is awaitable :) :) :) :)

[ben_lubar]

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

var var = await await; is valid syntax.

Only if the second await is something that is awaitable :) :) :) :)

If you can get a syntax error based on semantic data, that's even scarier.

[TheCPUWizard]

@ben_lubar said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

var var = await await; is valid syntax.

Only if the second await is something that is awaitable :) :) :) :)

If you can get a syntax error based on semantic data, that's even scarier.

Why, a lexical token is only a keyword if it is in a context where the keyword is valid, otherwise it is an identifier.

[blakeyrat]

@gąska said in C++ Stockholm Syndrome:

@boomzilla for what it's worth, when I said "everything", I meant it quite literally. I really didn't expect something as popular as SOAP not being available for Python.

Especially since all the "big data" people at your company are using Python because that's their language of choice. And "big data" frequently involves pulling in data from other people's APIs. And other people's APIs sometime happen to be SOAP. So if ANY language supported SOAP, you'd expect it to be Python, but nope.

Yet C# supports SOAP perfectly. Why? Because Microsoft paid people to make it support SOAP, and its library isn't just the result of volunteer efforts. Volunteers will never bother writing or maintaining "boring" code like SOAP API libraries. "Ew! I got XML all over my open source-y hands! This stinks, let's ditch this and go re-write Gnome from scratch again."

I guess the point is, unless Rust is paying people to give it good library coverage, it'll never have good library coverage. Because open source is shit in every way shape and form. Not that it's any better or any worse than any other language/platform maintained by people who think open source development model isn't shitty. (And sadly, C# is going to be that from this point on. So if you liked quality programming environments, sorry, they're gone forever now.)

[ben_lubar]

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

var var = await await; is valid syntax.

Only if the second await is something that is awaitable :) :) :) :)

If you can get a syntax error based on semantic data, that's even scarier.

Why, a lexical token is only a keyword if it is in a context where the keyword is valid, otherwise it is an identifier.

If var var = await await; gave a syntax error depending on the type of a variable, that would be scary.

[Gąska]

@blakeyrat said in C++ Stockholm Syndrome:

And "big data" frequently involves pulling in data from other people's APIs. And other people's APIs sometime happen to be SOAP.

Well, if pulling data is your goal, then Python has you covered. It really would help if you mentioned from the start if you meant SOAP server library or SOAP client library.

[pie_flavor]

@gąska said in C++ Stockholm Syndrome:

@blakeyrat said in C++ Stockholm Syndrome:

And "big data" frequently involves pulling in data from other people's APIs. And other people's APIs sometime happen to be SOAP.

Well, if pulling data is your goal, then Python has you covered. It really would help if you mentioned from the start if you meant SOAP server library or SOAP client library.

Why would blakey need to communicate his intentions? It's obviously your fault for not knowing them already.

[Gąska]

@pie_flavor the funny thing is that bad communication is the only reason I've agreed with him.

[dcon]

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

var var = await await; is valid syntax.

Only if the second await is something that is awaitable :) :) :) :)

If you can get a syntax error based on semantic data, that's even scarier.

Why, a lexical token is only a keyword if it is in a context where the keyword is valid, otherwise it is an identifier.

May be valid, but if that comes through in a code review... REJECT

[blakeyrat]

@gąska said in C++ Stockholm Syndrome:

It really would help if you mentioned from the start if you meant SOAP server library or SOAP client library.

1. I couldn't find a working version of either.
2. It's just an example. Picking apart the example doesn't change the point I was making.

[Gąska]

@blakeyrat said in C++ Stockholm Syndrome:

@gąska said in C++ Stockholm Syndrome:

It really would help if you mentioned from the start if you meant SOAP server library or SOAP client library.

1. I couldn't find a working version of either.

Maybe you suck at searching.

2. It's just an example. Picking apart the example doesn't change the point I was making.

But it's always fun to do! Anyway, even if not everything is there, most things are there. Writing the missing 2% is very different from having to write majority of things. Also, if it's not a right tool for your very specific, unique job, don't use it.

[LB_]

@ben_lubar said in C++ Stockholm Syndrome:

If a strongly-typed language gave a syntax error depending on the type of a variable, that would be scary.

I'm assuming your issue is the distinction between syntax error and compile error?

[TheCPUWizard]

@dcon said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

var var = await await; is valid syntax.

Only if the second await is something that is awaitable :) :) :) :)

If you can get a syntax error based on semantic data, that's even scarier.

Why, a lexical token is only a keyword if it is in a context where the keyword is valid, otherwise it is an identifier.

May be valid, but if that comes through in a code review... REJECT

Perhaps..... But consider a case where there was a large codebase that had been written many years ago. It just so happens that there are identifiers of "await" throughout the code, from a time where there was not even a rumor of this ever being a language feature...would you mandate a comprehensive sweep through the code [knowing this has a non-zero possibility of introducing a bug due to human error]????

[dcon]

@thecpuwizard said in C++ Stockholm Syndrome:

@dcon said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

var var = await await; is valid syntax.

Only if the second await is something that is awaitable :) :) :) :)

If you can get a syntax error based on semantic data, that's even scarier.

Why, a lexical token is only a keyword if it is in a context where the keyword is valid, otherwise it is an identifier.

May be valid, but if that comes through in a code review... REJECT

Perhaps..... But consider a case where there was a large codebase that had been written many years ago. It just so happens that there are identifiers of "await" throughout the code, from a time where there was not even a rumor of this ever being a language feature...would you mandate a comprehensive sweep through the code [knowing this has a non-zero possibility of introducing a bug due to human error]????

No, that is different. Annoying, but different. Now, if you're making changes in the code, it's a fair thing to request updating the code to current standards. Again, you have to take that risk factor into consideration...

[TheCPUWizard]

@dcon said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@dcon said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@ben_lubar said in C++ Stockholm Syndrome:

var var = await await; is valid syntax.

Only if the second await is something that is awaitable :) :) :) :)

If you can get a syntax error based on semantic data, that's even scarier.

Why, a lexical token is only a keyword if it is in a context where the keyword is valid, otherwise it is an identifier.

May be valid, but if that comes through in a code review... REJECT

Perhaps..... But consider a case where there was a large codebase that had been written many years ago. It just so happens that there are identifiers of "await" throughout the code, from a time where there was not even a rumor of this ever being a language feature...would you mandate a comprehensive sweep through the code [knowing this has a non-zero possibility of introducing a bug due to human error]????

No, that is different. Annoying, but different. Now, if you're making changes in the code, it's a fair thing to request updating the code to current standards. Again, you have to take that risk factor into consideration...

I tend to agree... I was merely responding to the big red REJECT in your response.... "Probably reject" seems more accurate.

[ObjectMike]

@pie_flavor said in C++ Stockholm Syndrome:

@thecpuwizard said in C++ Stockholm Syndrome:

@pie_flavor said in C++ Stockholm Syndrome:

For the record, in C#, int is the same type as System.Int32 and string is the same type as System.String, so that first line is wrong as well.

What?

What what? [i.e. context for post, it is not clear the reference point of the question]

Ah, finally figured out what he was talking about. C# doesn't have 'primitive' types, so they aren't lowercase, but does have library types, which are pascal case. So it's still wrong.

It's interesting how people's expectations from Java have made people think wrong things about C# from the very beginning. During the .NET 1.x days it was fairly common to see online questions of people trying to understand the lack of primitive types (understandable) to those assuming int=non-object primitive and Int32=object reference even though the C#/.NET documentation never said that. In fact they explicitly say that they're the same exact thing. It's kind of scary that is still something that gets mixed up.

[blakeyrat]

@mikehurley There are still people out there who think an OS that fills up its RAM allotment is "wasting" memory. And I mean people who ought to know better.

If you go to less technical people, there are still thousands of people who run registry cleaners and de-fragment their hard drives, because those things provided benefits in Windows 98, even though they've been useless for over a decade now.

[TheCPUWizard]

@blakeyrat said in C++ Stockholm Syndrome:

@mikehurley There are still people out there who think an OS that fills up its RAM allotment is "wasting" memory. And I mean people who ought to know better.

If you go to less technical people, there are still thousands of people who run registry cleaners and de-fragment their hard drives, because those things provided benefits in Windows 98, even though they've been useless for over a decade now.

Of less utility, sure. But there still are plenty of cases where there is an incremental value to doing so. Granted the vast majority of people who do them, are cargo cultists without the necessary technical expertise to know when it will have a meaningful impact.