Times are UTC Toggle Colours
01:23:36 *** Supercheese has joined #openttd.dev 01:23:36 *** ChanServ sets mode: +v Supercheese 05:55:09 *** Alberth has joined #openttd.dev 05:55:09 *** ChanServ sets mode: +v Alberth 10:04:18 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r27378 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 11:30:43 *** Supercheese has quit IRC 11:31:16 *** Supercheese has joined #openttd.dev 11:31:16 *** ChanServ sets mode: +v Supercheese 12:32:53 *** tycoondemon has joined #openttd.dev 12:37:40 *** tycoondemon2 has quit IRC 12:38:10 *** gnu_jj_ has joined #openttd.dev 12:40:34 *** Yexo- has joined #openttd.dev 12:40:43 *** Yexo has quit IRC 12:43:57 *** gnu_jj has quit IRC 15:36:16 *** frosch123 has joined #openttd.dev 15:36:16 *** ChanServ sets mode: +v frosch123 17:10:50 *** keoz has joined #openttd.dev 18:41:10 *** Belugas has quit IRC 19: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. 19:08:42 *** Supercheese has quit IRC 19:13:37 <Rubidium> alternatively ZeroedMemoryAllocator is removed from ScriptText 19:14:33 <Rubidium> and we add a few memsets 19: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). 19:16:16 <michi_cc> The throw in destructor is still (and always was) a bad idea though. 19:19:48 <frosch123> hmm, can we move the throw into virtual int32 Release(); ? 19:19:56 <frosch123> it is also virtual 19:20:05 <frosch123> and seems to be the only place calling the destructor 19:20:27 <michi_cc> For 4: For some reason the StringParameters constructor used in that spot takes a uint64*. 19:22:36 <michi_cc> frosch123: Probably, but are you sure no Script class is ever created on the stack? 19:23:35 <frosch123> yes, since they are only created via factory functions called by squirrel 19:24:41 <michi_cc> Then this is probably the best solution of all. 19:25:10 <frosch123> https://paste.openttdcoop.org/pxkpq7bth?/pxkpq7bth <- let's try that 19:25:40 <frosch123> didn't c++ finally have a "finally" statement? 19:27:00 <michi_cc> http://www.stroustrup.com/bs_faq2.html#finally 19:27:47 <frosch123> ah, so i am supposed to first put the pointer into a unique_ptr :) 19:28:55 <frosch123> well, regression passes 19:29:06 <frosch123> but it likely does not test those :p 19:29:12 <frosch123> i need a test ai 19:31:41 <frosch123> uhm, how would i actually trigger that? 19:32:47 <michi_cc> No idea at all :) 19:35:16 <frosch123> figured it out 19:35:30 <frosch123> i can call destructors by assigning null 19:35:32 <michi_cc> No warnings from MSVC2015 with your patch, so from that side it is good :p 19:35:43 <frosch123> seems to work :) 19:36:21 <frosch123> shall i keep the catch () { delete this; throw } delete this ? 19:36:52 <frosch123> or do you prefer std:auto_ptr foo = this; FinalRelease() ? 19: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. 19:40:28 <Rubidium> is std:auto_ptr c++ancient? 19:41:05 <michi_cc> STL ancient, yes, but it might be removed in future c++ standards. 19:41:21 <frosch123> https://paste.openttdcoop.org/psoqsx609 19:41:50 <frosch123> auto_ptr is replaced by unique_ptr, but in this very simple usage they behave identical 19:44:13 <michi_cc> error C2440: "Initialisierung": "SimpleCountedObject *const " kann nicht in "std::auto_ptr<SimpleCountedObject>" konvertiert werden 19:44:23 <Rubidium> egg, chicken-ish I'd reckon auto_ptr until we make the actual switch 19:46:03 <frosch123> const? 19:46:09 <frosch123> Release() is no const method 19:46:35 <frosch123> hmm, or the pointer is const? yes, it is, but why can it not copy a pointer? 19:46:36 <michi_cc> error C2440: "Initialisierung": "SimpleCountedObject *const " kann nicht in "std::auto_ptr<const SimpleCountedObject>" konvertiert werden 19:48:11 <frosch123> std::auto_ptr<SimpleCountedObject> delete_after_throw(this); <- using explicit constructor syntax works for me 19:48:19 <michi_cc> Ah, std::auto_ptr<SimpleCountedObject> delete_after_throw(this); works, = does not. 19:49:02 <frosch123> yes, i think because the constructor is declared explicit 19:50:19 <frosch123> https://paste.openttdcoop.org/pn4dd0t8d <- so, 1 or 2? :p 19:51:52 <frosch123> there is currently no other instance of auto_ptr in ottd :) 19:55:07 <Rubidium> it's in MSVC 2003 19:55:41 <frosch123> unique_ptr? 19:56:01 <Rubidium> auto_ptr seems to be in gcc 2.95 19:56:16 <frosch123> it's c++98 19:56:31 <Rubidium> unique_ptr seems to be introduced in MSVC 2010 19:56:38 <frosch123> i have no doubt about auto_ptr being available currently 19:56:47 <frosch123> it's just that it is deprecated :) 19:56:56 <frosch123> and i do not know the right ifdef for unique_ptr :p 19:57:23 <Rubidium> yup, introduced in MSVC 2010 19:57:39 <Rubidium> and we imply to support 2005/2008 as well 19:58:20 <Rubidium> gcc 4.4 seems to have introduced unique_ptr 19: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 20:00:21 <frosch123> yay :) 20:02:16 *** Alberth has left #openttd.dev 20:04:33 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r27379 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:21:31 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r27380 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:24:14 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r27381 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:35:08 *** Supercheese has joined #openttd.dev 20:35:08 *** ChanServ sets mode: +v Supercheese 20:36:57 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r27382 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:54:06 *** keoz has quit IRC 21:14:07 *** frosch123 has quit IRC 21: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) 21:57:11 <Rubidium> likewise with win32 release 21:58:37 <Rubidium> https://paste.openttdcoop.org/pyvfen0ee/jwuo5d 21:58:56 <Rubidium> as if it doesn't fancy 'extern "C"' or so 22:16:43 <Rubidium> looking at the .i I can't figure out why it would go wrong 22:19:46 <Rubidium> oh... 22:19:55 <Rubidium> fttypes.h exists in the SDK 22:21:12 <Rubidium> moving the openttd useful includes before the sdk includes helps 22:38:30 <Rubidium> yay victory 22:41:41 <Rubidium> michi_cc: do you (still) have the PDBs of those libraries? Might be useful if MSVC can include that into the openttd PDB 22:43:03 *** keoz has joined #openttd.dev