Config
Log for #openttd.dev on 10th August 2015:
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

Powered by YARRSTE version: svn-trunk