IRC logs for #openttd.dev on OFTC at 2012-12-02
⏴ go to previous day
03:42:10 *** Supercheese has joined #openttd.dev
04:44:29 *** Supercheese has joined #openttd.dev
05:48:24 *** Supercheese has joined #openttd.dev
08:23:54 *** Zuu has joined #openttd.dev
08:27:05 *** ntoskrnl has joined #openttd.dev
08:52:52 *** andythenorth has joined #openttd.dev
08:52:52 *** ChanServ sets mode: +v andythenorth
08:56:19 *** fonsinchen has joined #openttd.dev
08:56:20 *** ChanServ sets mode: +v fonsinchen
09:26:29 *** Alberth has joined #openttd.dev
09:26:29 *** ChanServ sets mode: +v Alberth
09:31:09 *** andythenorth has joined #openttd.dev
09:31:09 *** ChanServ sets mode: +v andythenorth
10:17:00 *** ntoskrnl has joined #openttd.dev
11:22:20 *** FLHerne has joined #openttd.dev
11:44:03 *** frosch123 has joined #openttd.dev
11:44:03 *** ChanServ sets mode: +v frosch123
12:19:44 <Alberth> but I don't know whether the Windows build likes that :p
12:20:33 <frosch123> well, iirc the point of FORCEINLINE was that yapf was significantly faster
12:20:52 <frosch123> replacing all inline with INLINE is certainly wrong
12:21:17 <frosch123> either the normal 'inline' works, or we need to reintro 'FORCEINLINE' for stuff were we really want it
12:21:22 <Alberth> I fully agree on not wanting INLINE :)
12:21:23 <frosch123> i hope SmatZ has a clue :)
12:22:30 <frosch123> many 'inline' are for 'static inline' functions in header files, and the only point of 'inline' is to suppress the 'function is unused' warning
12:24:04 <Alberth> yapf has getters like const VehicleType * GetVehicle() const { return m_veh; }
12:24:18 <Alberth> perhaps removing such stuff helps already
12:24:44 <frosch123> i would prefer FORCEINLINE above removing accessors .)
13:23:40 *** Zuu has joined #openttd.dev
14:35:58 <frosch123> summoning completed :)
14:37:10 <SmatZ> the problem with gcc is that sometimes, it won't inline a simple getter/setter because of reaching some limit, or because of wrongly guessing the effect of inlining.. I suppose MSVC has the same problem, so that's why FORCEINLINE was introduced
14:38:24 <SmatZ> I tried to do a systematic using of inline/FORCEINLINE
14:38:30 <SmatZ> but I wasn't really successful
14:38:58 <frosch123> well, FORCEINLINE was removed :) not it looks like we have to reintroduce it, just where :p
14:42:04 * Alberth prefers as few places as possible
14:43:51 <frosch123> well, all of pathfinders? all of map accessors? all of core/ ?
14:44:33 <frosch123> all of blitter/ ? :p
14:45:09 <frosch123> if you want to profile all of that stuff, that means a lot of boring work :p
14:47:42 *** FLHerne has joined #openttd.dev
14:51:56 <SmatZ> in the end, I decided not to touch using of inline/FORCEINLINE, and let the compiler do its work...
14:56:42 <Alberth> that seems the only sane way :)
14:57:01 <frosch123> hmm, who removed FORCEINLINE then?
14:57:37 <frosch123> ah, truebrain broke it all :p
15:00:00 <frosch123> maybe we could just use that list, and remove the things which obviously do not need it
16:26:53 *** ntoskrnl11 has joined #openttd.dev
16:27:11 *** Zuu_ has joined #openttd.dev
17:54:49 *** andythenorth has joined #openttd.dev
17:54:49 *** ChanServ sets mode: +v andythenorth
18:01:22 *** FLHerne has joined #openttd.dev
19:25:35 *** andythenorth has joined #openttd.dev
19:25:35 *** ChanServ sets mode: +v andythenorth
19:55:54 *** andythenorth has joined #openttd.dev
19:55:54 *** ChanServ sets mode: +v andythenorth
20:18:49 *** Supercheese has joined #openttd.dev
continue to next day ⏵