IRC logs for #openttd.dev on OFTC at 2015-08-10
⏴ go to previous day
03:23:36 *** Supercheese has joined #openttd.dev
03:23:36 *** ChanServ sets mode: +v Supercheese
07:55:09 *** Alberth has joined #openttd.dev
07:55:09 *** ChanServ sets mode: +v Alberth
13:31:16 *** Supercheese has joined #openttd.dev
13:31:16 *** ChanServ sets mode: +v Supercheese
14:32:53 *** tycoondemon has joined #openttd.dev
14:38:10 *** gnu_jj_ has joined #openttd.dev
14:40:34 *** Yexo- has joined #openttd.dev
17:36:16 *** frosch123 has joined #openttd.dev
17:36:16 *** ChanServ sets mode: +v frosch123
19:10:50 *** keoz has joined #openttd.dev
21:08:11 <michi_cc> Rubidium: Regarding patch 2: It's all the "fault" of virtual destructors. You can't add noexpect(false) in a derived class just as you can't drop a const. And if a class uses multiple inheritance, *all* base destructors have to have the same noexcept. All Script classes derive from SimpleCountedObject, but ScriptText also from ZeroedMemoryAllocator. ZeroedMemoryAllocator is often used in multiple inheritance.
21:13:37 <Rubidium> alternatively ZeroedMemoryAllocator is removed from ScriptText
21:14:33 <Rubidium> and we add a few memsets
21:15:25 <michi_cc> For 3: EditAndContinue conflicts with using SAFESEH, which has security advantages. The minimum version is the windows subsystem version and required to make the exe launch on WinXP. Newlines are the way MSVC2015 produced them (i.e. despite what the git diff suggests, I simply let the IDE convert the project as a first step, and the newlines are what the IDE produced).
21:16:16 <michi_cc> The throw in destructor is still (and always was) a bad idea though.
21:19:48 <frosch123> hmm, can we move the throw into virtual int32 Release(); ?
21:20:05 <frosch123> and seems to be the only place calling the destructor
21:20:27 <michi_cc> For 4: For some reason the StringParameters constructor used in that spot takes a uint64*.
21:22:36 <michi_cc> frosch123: Probably, but are you sure no Script class is ever created on the stack?
21:23:34 <frosch123> yes, since they are only created via factory functions called by squirrel
21:24:41 <michi_cc> Then this is probably the best solution of all.
21:25:40 <frosch123> didn't c++ finally have a "finally" statement?
21:27:47 <frosch123> ah, so i am supposed to first put the pointer into a unique_ptr :)
21:28:55 <frosch123> well, regression passes
21:29:06 <frosch123> but it likely does not test those :p
21:31:41 <frosch123> uhm, how would i actually trigger that?
21:35:30 <frosch123> i can call destructors by assigning null
21:35:32 <michi_cc> No warnings from MSVC2015 with your patch, so from that side it is good :p
21:36:21 <frosch123> shall i keep the catch () { delete this; throw } delete this ?
21:36:52 <frosch123> or do you prefer std:auto_ptr foo = this; FinalRelease() ?
21:39:21 <michi_cc> auto_ptr is strongly deprecated, but unique_ptr is of course not at all universally support yet. I don't really care either way.
21:40:27 <Rubidium> is std:auto_ptr c++ancient?
21:41:05 <michi_cc> STL ancient, yes, but it might be removed in future c++ standards.
21:41:50 <frosch123> auto_ptr is replaced by unique_ptr, but in this very simple usage they behave identical
21:44:13 <michi_cc> error C2440: "Initialisierung": "SimpleCountedObject *const " kann nicht in "std::auto_ptr<SimpleCountedObject>" konvertiert werden
21:44:23 <Rubidium> egg, chicken-ish I'd reckon auto_ptr until we make the actual switch
21:46:09 <frosch123> Release() is no const method
21:46:35 <frosch123> hmm, or the pointer is const? yes, it is, but why can it not copy a pointer?
21:46:36 <michi_cc> error C2440: "Initialisierung": "SimpleCountedObject *const " kann nicht in "std::auto_ptr<const SimpleCountedObject>" konvertiert werden
21:48:11 <frosch123> std::auto_ptr<SimpleCountedObject> delete_after_throw(this); <- using explicit constructor syntax works for me
21:48:19 <michi_cc> Ah, std::auto_ptr<SimpleCountedObject> delete_after_throw(this); works, = does not.
21:49:02 <frosch123> yes, i think because the constructor is declared explicit
21:51:52 <frosch123> there is currently no other instance of auto_ptr in ottd :)
21:56:01 <Rubidium> auto_ptr seems to be in gcc 2.95
21:56:31 <Rubidium> unique_ptr seems to be introduced in MSVC 2010
21:56:38 <frosch123> i have no doubt about auto_ptr being available currently
21:56:47 <frosch123> it's just that it is deprecated :)
21:56:56 <frosch123> and i do not know the right ifdef for unique_ptr :p
21:57:23 <Rubidium> yup, introduced in MSVC 2010
21:57:39 <Rubidium> and we imply to support 2005/2008 as well
21:58:20 <Rubidium> gcc 4.4 seems to have introduced unique_ptr
21:59:41 <michi_cc> I'd vote for try/trow. Solves all discussions and nobody's going to look at countedobj.cpp in the next couple years anyway :p
22:02:16 *** Alberth has left #openttd.dev
22:35:08 *** Supercheese has joined #openttd.dev
22:35:08 *** ChanServ sets mode: +v Supercheese
23:56:34 <Rubidium> michi_cc: the openttd-useful 6 I just downloaded seems to give some problems in MSVC 2015; primarily with freetype it seems (x64 release)
23:57:11 <Rubidium> likewise with win32 release
23:58:55 <Rubidium> as if it doesn't fancy 'extern "C"' or so
continue to next day ⏵