| --- Log opened Tue Mar 11 00:00:37 2014 |
| 00:02 | < [R]> | Probably because he was moatly harmless |
| 00:10 | < Shiz> | @Azash â tbf, IRC clients probably can't be improved forever anyway |
| 00:10 | < Shiz> | yes they can |
| 00:13 | <@Thalass> | Why wouldn't they be? |
| 00:16 | <@Azash> | Shiz: I was under the impression the IRC protocol doesn't really change much? |
| 00:16 | <~Vornicus> | IRC itself hasn't changed that much in the past ten years. |
| 00:16 | <~Vornicus> | However that doesn't mean you can't improve the way you interact with it. |
| 00:17 | < [R]> | IRC's getting meta-data extensions |
| 00:17 | < [R]> | But that seems to be dead in the water, as it needs servers/networks to support it. |
| 00:18 | <@Azash> | Vornicus: That's true, but you're still likely to hit a point where progress will taper off and most devs will lose interest |
| 00:18 | <~Vornicus> | sure. |
| 00:19 | < Shiz> | Azash: http://ircv3.atheme.org |
| 00:19 | <@Reiv> | What metadata would you want to add to IRC? |
| 00:19 | < Shiz> | arbitrary. |
| 00:20 | < Shiz> | http://ircv3.atheme.org/specification/metadata-3.2 |
| 00:20 | < Shiz> | there's predefined keys here though |
| 00:20 | <@Reiv> | I struggle to find a purpose whatsoever. |
| 00:20 | <@Azash> | Shiz: UnrealIRCd? Good luck with that |
| 00:20 | < [R]> | The only real useful one is the time one, for bouncers |
| 00:20 | < Shiz> | what about unreal |
| 00:21 | <@Thalass> | Eventually, i guess, but IRC is a pretty efficient communication medium. |
| 00:21 | <@Azash> | Shiz: I remember that one guy when he used to hang around mordor |
| 00:21 | <@Thalass> | Though i do tend to sometimes confuse IRC with PSK31 and other low bandwidth text communication systems |
| 00:21 | <@Azash> | It was more a show of sympathy than anything |
| 00:21 | <@Azash> | Lol |
| 00:21 | < Shiz> | i don't know any unrealIRCd guy |
| 00:22 | < Shiz> | [R]: multi-prefix and SASL are quite useful |
| 00:22 | < Shiz> | as is extended-join |
| 00:23 | < Shiz> | as far as ircv3.2, uhnames and chghost are useful |
| 00:23 | < Shiz> | the rest depends on what you like I suppose |
| 00:39 | | Orthia [orthianz@Nightstar-ufscb0.callplus.net.nz] has joined #code |
| 00:39 | | mode/#code [+o Orthia] by ChanServ |
| 00:46 | < [R]> | multi-prefix/ |
| 00:48 | < [R]> | nm |
| 00:48 | < Shiz> | basically that nicks are listed with all their channel statuses |
| 00:48 | < Shiz> | e.g. if a user is +qo, it will show ~@Nickname in the nicklist |
| 00:48 | < Shiz> | instead of ~Nickname |
| 00:49 | < Shiz> | so if -q is set on the user it will still show @Nickname in the client, like it should |
| 00:49 | < Shiz> | instead of statusless |
| 00:54 | | Derakon[AFK] is now known as Derakon |
| 00:57 | < [R]> | Ah, okay that make sense |
| 00:57 | <@celticminstrel> | What's chghost? |
| 00:57 | < Shiz> | notificaions when a user had their host changed |
| 00:57 | < Shiz> | for whatever reason |
| 00:57 | < Shiz> | so anyone in common channels with said user will receive a CHGHOST message |
| 00:58 | < [R]> | Usually for +x/-x or for a vhost (when the network allows them) |
| 00:58 | <@celticminstrel> | Ah, I parsed that as ch-ghost. |
| 00:59 | <@celticminstrel> | I think when it happens on Freenode we get a part-join. |
| 00:59 | < Shiz> | yep, which is kind of a hack |
| 00:59 | < Shiz> | it's a quit-join even |
| 00:59 | <@celticminstrel> | Is it? I can't tell the difference on my client. |
| 01:00 | <@celticminstrel> | I think. |
| 01:00 | < Shiz> | I know it's one because my client library deconstructs client state on a quit |
| 01:00 | < Shiz> | so it being quit-join is actually an annoyance to me |
| 01:00 | < Shiz> | ehrm, deconstructs user state for that user* |
| 01:00 | <@celticminstrel> | Not sure what that means. |
| 01:00 | < Shiz> | my library has a certain state for every user we know of |
| 01:01 | < Shiz> | and are in common channels with |
| 01:01 | < Shiz> | stuff like nick, user, host, is authenticated to nickserv, etc |
| 01:01 | < Shiz> | when a user quits that state is deleted |
| 01:03 | | Harlow [harlow@Nightstar-2kn67a.cc.il.us] has joined #code |
| 01:17 | | Harlow [harlow@Nightstar-2kn67a.cc.il.us] has quit [Connection closed] |
| 01:21 | <~Vornicus> | arg, hatred! |
| 02:01 | | Araleith [Araleith@Nightstar-gqo.7co.175.108.IP] has joined #code |
| 03:21 | | Thalass [thalass@Nightstar-nuh9sg.bigpond.net.au] has quit [Ping timeout: 121 seconds] |
| 03:42 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 03:43 | | Thalass [thalass@Nightstar-nuh9sg.bigpond.net.au] has joined #code |
| 03:43 | | mode/#code [+o Thalass] by ChanServ |
| 04:03 | | Kindamoody[zZz] is now known as Kindamoody |
| 04:03 | | Turaiel is now known as Turaiel[Offline] |
| 04:03 | | Derakon is now known as Derakon[AFK] |
| 04:05 | | Turaiel[Offline] is now known as Turaiel |
| 05:02 | | Red_Queen [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 05:02 | | mode/#code [+o Red_Queen] by ChanServ |
| 05:06 | | celticminstrel [celticminst@Nightstar-mhtogh.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 06:07 | | Kindamoody is now known as Kindamoody|out |
| 06:21 | | ErikMesoy|sleep is now known as ErikMesoy |
| 06:30 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has joined #code |
| 06:35 | | himi [fow035@Nightstar-q9amk4.ffp.csiro.au] has quit [Ping timeout: 121 seconds] |
| 06:47 | | Turaiel is now known as Turaiel[Offline] |
| 06:48 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has quit [[NS] Quit: Gone.] |
| 06:51 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has joined #code |
| 07:29 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 07:56 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has quit [[NS] Quit: Leaving] |
| 09:28 | <@froztbyte> | http://gabrielecirulli.github.io/2048/ |
| 09:52 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 09:52 | | mode/#code [+o himi] by ChanServ |
| 09:59 | | Thalass [thalass@Nightstar-nuh9sg.bigpond.net.au] has quit [[NS] Quit: argh*splode*] |
| 10:26 | | mode/#code [+o RichyB] by ChanServ |
| 10:49 | | Syka [the@Nightstar-1ip.u9g.126.1.IP] has joined #code |
| 10:49 | | mode/#code [+o Syka] by ChanServ |
| 11:00 | | * TheWatcher eyes this stuff |
| 11:00 | <@TheWatcher> | Where are these zero width spaces coming from? |
| 11:07 | <@Syka> | space! |
| 11:08 | <@Syka> | the nbsps from planet neptune |
| 11:12 | <@TheWatcher> | Ohgoes, I missed this |
| 11:12 | <@TheWatcher> | *ohgods |
| 11:12 | <@TheWatcher> | Apparently there was a guest lecture here yesterday about how "PHP is awesome" and "its bad reputation is a thing of the past" |
| 11:13 | <@TheWatcher> | I think I would have attended that just for the comedy value alone |
| 12:12 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 12:16 | <@simon_> | I just got access to the local research department's beast of a computer. |
| 12:17 | <@simon_> | it's "just" 64 cores (maybe hyperthreaded, no idea) with four GPUs and a 20MB/s line |
| 12:17 | <@simon_> | also, it's idle. |
| 12:17 | <@simon_> | so... it's dogecoin time! |
| 12:25 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 12:25 | | mode/#code [+o himi] by ChanServ |
| 12:26 | | * simon_ just learned of OpenSSH's ProxyCommand. |
| 12:27 | <@simon_> | ProxyCommand ssh my.proxy nc -q0 remote.addr 1337 |
| 12:28 | <@simon_> | and if I put my SSH keys on both my.proxy and remote.addr, I don't have to place my SSH key on my.proxy! |
| 12:28 | <@simon_> | the private one, that is. |
| 12:34 | | * TheWatcher blinks at this error |
| 12:35 | <@TheWatcher> | Apparently today is Break-Chris'-Brain-With-Weird-Shit Dday |
| 12:36 | <@TheWatcher> | s/Dd/D/ |
| 12:43 | | * TheWatcher facepalms as he realises what he's done, when running the code via the debugger |
| 12:44 | <@TheWatcher> | However much sense it makes to call the function 'import', doing so is actually a really bad idea >.< |
| 12:48 | < [R]> | whyso |
| 12:49 | <@AnnoDomini> | Keyword? |
| 12:50 | < [R]> | Oh, I was assuming C here. |
| 12:51 | <@TheWatcher> | No, perl. And it's aproblem because perl's "use" function calls the import for the supplied package |
| 12:51 | < [R]> | Ah |
| 12:51 | <@Syka> | perl debugging? |
| 12:52 | <@Syka> | just make sure you clean the pentagram off the carpet |
| 12:56 | <@TheWatcher> | The pentagram is easy |
| 12:56 | <@TheWatcher> | This candle wax might be another thing |
| 12:57 | <@AnnoDomini> | How about the goat blood? |
| 12:58 | <@TheWatcher> | I fyou spill that, you've got more things to worry about than getting it out of the carpet |
| 13:16 | <&McMartin> | "Back in my day we used every part of the camel." |
| 13:18 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 13:31 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 13:31 | | mode/#code [+o himi] by ChanServ |
| 13:40 | | gnolam_ [lenin@Nightstar-78p9a9.cust.bredbandsbolaget.se] has joined #code |
| 13:40 | | gnolam [lenin@Nightstar-kndvr9.cust.bredbandsbolaget.se] has quit [NickServ (RECOVER command used by gnolam_)] |
| 13:40 | | gnolam_ is now known as gnolam |
| 13:40 | | mode/#code [+o gnolam] by ChanServ |
| 14:13 | | celticminstrel [celticminst@Nightstar-mhtogh.dsl.bell.ca] has joined #code |
| 14:13 | | mode/#code [+o celticminstrel] by ChanServ |
| 15:26 | | You're now known as TheWatcher[afk] |
| 15:46 | <&ToxicFrog> | Ok, question for anyone knowledgeable about gcc and C++ virtual methods here. |
| 15:47 | <&ToxicFrog> | I have a class BaseClass { virtual bool foo() const { return foo(true); } virtual bool foo(bool x) const = 0; } |
| 15:47 | <&ToxicFrog> | And class SubClass { virtual bool foo(bool x) { return !x; } } |
| 15:48 | <&ToxicFrog> | And this produces a warning "SubClass::foo hides overloaded virtual function BaseClass::foo with different number of parameters" |
| 15:48 | <&ToxicFrog> | Bwuh? |
| 15:58 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 16:03 | < Xon> | ToxicFrog, nfi that looks wierd. see what another compiler does? |
| 16:05 | <&ToxicFrog> | Xon: not an option. |
| 16:07 | < Xon> | ToxicFrog, don't you need 'const' in the SubClass's function definition? |
| 16:08 | <&ToxicFrog> | Yes, and it's there in the actual code. |
| 16:08 | <&ToxicFrog> | This looks like a deliberate feature of C++: http://stackoverflow.com/a/1629074 |
| 16:10 | < Xon> | what a wierd design feature |
| 16:10 | <&McMartin> | Ah, I see you beat me to it |
| 16:10 | <&McMartin> | Yes, if you override some but not all copies of an overloaded function, C++ lifts an eyebrow at you and will hide all the base class ones |
| 16:11 | <&McMartin> | This is, IIRC, so that you don't suddenly get behavior shifts because someone extended your base class behind your back. |
| 16:11 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 16:11 | | mode/#code [+o himi] by ChanServ |
| 16:11 | <&ToxicFrog> | That is really annoying. |
| 16:13 | <&McMartin> | That sai |
| 16:13 | <&McMartin> | d |
| 16:13 | <&McMartin> | The idiomatic way to do what you wrote there is to use optional arguments |
| 16:13 | <&McMartin> | That is, only define virtual bool foo(bool x = true) const = 0 |
| 16:20 | <&ToxicFrog> | Argh. |
| 16:20 | <&ToxicFrog> | So, the root problem I'm trying to solve is that I have a base class with pure virtual HasFoo(e) and AddFoo(e), and impure virtual DoFoo(e) that calls both. |
| 16:21 | <&ToxicFrog> | DoFoo(e) now needs to become DoFoo(e, bool use_bar) |
| 16:21 | <&ToxicFrog> | Which affects both HasFoo and AddFoo, since it needs to look for the foo in a different place if use_bar is set. |
| 16:21 | <&McMartin> | And use_bar is specific to the subclass? |
| 16:22 | <&ToxicFrog> | Further complicating matters, this only actually matters for one subclass - all other subclasses either support bar inherently or don't care about it at all. |
| 16:22 | <&McMartin> | ... and yet Bar needs to show up in the superclass? |
| 16:24 | <&ToxicFrog> | So, the way this is used is, FELINE ASSEMBLER instantiates some subclass of this thing depending on what type of configuration it's processing, and then calls instance->DoFoo(e, <value derived from command line flags>) |
| 16:25 | <&ToxicFrog> | The "common" subclass needs to support both use_bar=true and use_bar=false. Everything else has its own implementations of HasFoo and AddFoo that do the right thing regardless. |
| 16:26 | <&ToxicFrog> | For Reasons that I don't fully agree with but can't change, splitting the common subclass ("common" here as in "used by multiple teams", not "inherited by multiple things") into a bar-using one and a bar-ignoring one is not an option. |
| 16:28 | | celticminstrel [celticminst@Nightstar-mhtogh.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 16:30 | <&ToxicFrog> | Colleague of mine has pointed out that the instance will always be used for the same type of configuration once created and thus we can do this with a member variable set at construction time. |
| 16:31 | <&McMartin> | This is a significant improvement over an API change. |
| 16:31 | <&McMartin> | C++ object APIs are baked into the structure mechanics in ways that make them incredibly brittle when changed; any shift in method signatures will require making equivalent changes in Every Subclass Forever, at the binary level if not the source one. |
| 16:33 | <&ToxicFrog> | Yeah, that's what I was discovering and hoping to avoid. |
| 16:34 | <&McMartin> | This normally goes double for fields, but that's what the so-called pimpl idiom lets you abstract away by hand and which, say, Java and C# end up doing as a matter of course |
| 16:35 | <&ToxicFrog> | "pimpl"? |
| 16:35 | <&McMartin> | "pointer to implementation" |
| 16:35 | <&McMartin> | Basically, you have a class with one field that is a pointer to the class that actually does the work and which subclasses some interface |
| 16:36 | <&McMartin> | And then you also implement that interface or an equivalent one (actually being that interface is optional, when you get down to it) whose methods are all defined inline as, say, "int foo(double a) { return pImpl->foo(a); }" |
| 16:37 | <&McMartin> | And then your constructor, which has access to the header files for the implementation class, go and fill in pImpl where the clients can't see it |
| 16:38 | <&McMartin> | And now you have something that implements an interface, hides the real implementation, is nominally virtualizable with multiple implementation types, and which has a well-defined size when you put it on the stack or build arrays out of it (basically, one or two pointers, depending on whether or not your shell class makes its methods virtual. It doesn't have to!) |
| 16:39 | <&McMartin> | It is essentially defining a vtable by hand, and insisting that the real data always lives on the heap. |
| 16:40 | <&McMartin> | http://en.wikipedia.org/wiki/Opaque_pointer gives examples in several languages |
| 16:40 | <&McMartin> | Monocle in particular uses the Hell out of the C version of this as its primary method for being FFI-friendly |
| 16:40 | <&ToxicFrog> | Goddamn so much of this code would be simpler if C++ supported structural typing |
| 16:41 | <&McMartin> | C++ has the opposite of structural typing as an explicit design goal, so, um |
| 16:41 | <&ToxicFrog> | Well, yes |
| 16:41 | <&McMartin> | "This code would be so much simpler if Haskell were imperative" |
| 16:42 | <&ToxicFrog> | There's just a bunch of ugly code in here for "we have multiple classes here with identical APIs but no is-a relationship thanks to terrible decisions made five years ago, and we need to support all of them" |
| 16:42 | <&ToxicFrog> | I eagerly await the day everyone else catches up on this migration and we can burn it all down |
| 16:42 | <&McMartin> | Yes, that is a common experience |
| 16:42 | <@RichyB> | McMartin, Haskell is a *wonderful* imperative language. (*) |
| 16:43 | <&McMartin> | One of the new guys here was poking around yesterday and found himself in the middle of a function that was a thousand lines long |
| 16:43 | <@RichyB> | (* IO is not perfect, but ContT IO is nicer.) |
| 16:43 | <&McMartin> | As it happens, it's all straight-line code and organized into stanzas, so my reaction was "yeah, you could refactor it sanely, but that would then make it even longer, so, uh, either way you're kind of hosed") |
| 16:44 | <&ToxicFrog> | I was super stoked to deploy the new FELINE ASSEMBLER yesterday before discovering that it's dropping critical parts of the configuration into the wrong fields because the team maintaining it hasn't bothered to migrate to the new, non-terrible ones yet |
| 16:44 | <&McMartin> | Is FELINE ASSEMBLER so named because it herds cats? |
| 16:44 | <&McMartin> | This also is making me think of the Catvengers and/or Mewovel vs. Catcom |
| 16:44 | <&McMartin> | *Meowvel |
| 16:45 | <&McMartin> | http://fc08.deviantart.net/fs71/f/2011/265/7/1/ultimate_meowvel_vs_catcom_3_by_s uzuran-d3b6we9.jpg |
| 16:46 | <&ToxicFrog> | McMartin: close. We have a lot of cat-themed names here because the overarching domain is CAT, Content Ads Targeting. |
| 16:47 | <&ToxicFrog> | This is specifically the bit that handles taking the correct version of the experiment configuration, updating it with various pieces of out-of-band configuration information, and then propagating it to all of the servers. |
| 16:47 | <&ToxicFrog> | And it's that second step where everything was going horribly wrong. |
| 16:49 | <&McMartin> | Heh. |
| 16:49 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 16:49 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 16:50 | <&ToxicFrog> | (thankfully no actual servers are reading from this configuration channel yet) |
| 17:01 | | Derakon [chriswei@Nightstar-5fqf0m.ca.comcast.net] has joined #code |
| 17:01 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 17:05 | <@simon_> | C++ advice... this code: assert(fin.good() && "Error opening input.data file!"); |
| 17:05 | <@simon_> | as far as I can see, fin.good() returns true if I'm able to read |
| 17:05 | <@simon_> | is the '&& "..."' part an idiom? I don't understand what this means. |
| 17:06 | <&Derakon> | Looks like it's attaching a human-meaningful error string to the assert. |
| 17:06 | <&Derakon> | If you don't do something like that, you get an error message "Assert failed: fin.good()" which is kind of opaque. |
| 17:06 | <@simon_> | oh. strings evaluate to true. |
| 17:06 | <&Derakon> | Right. |
| 17:06 | <&Derakon> | Well, non-empty strings do. |
| 17:06 | <&Derakon> | I don't remember if C++ empty strings are true. |
| 17:07 | <&McMartin> | Yes |
| 17:07 | <&McMartin> | Well |
| 17:07 | <&Derakon> | Your statement is ambiguous~ |
| 17:07 | <&McMartin> | Those are C strings |
| 17:07 | <@simon_> | stackoverflow said "Since a string always evaulates to true, ..." |
| 17:07 | <&McMartin> | C strings always evaluate to true because they are (a) pointers and (b) not NULL |
| 17:13 | <&ToxicFrog> | ...but C++ boolean operators short-circuit. Doesn't (fin.good() && "Error opening input.data file!") evaluate to false if fin.good() returns false? |
| 17:13 | <&McMartin> | Yes |
| 17:13 | <&McMartin> | And then the assert fails |
| 17:13 | <&ToxicFrog> | And then the error message never actually makes it out |
| 17:13 | <&Derakon> | But the assert error message prints the entire line being asserted. |
| 17:13 | <&Derakon> | IIRC. |
| 17:13 | <&McMartin> | And then you get "assert failed the condition "fin.good() && "Error opening input.data file!"", which is better than "failed: fin.good()" which could be *any* failing IO op |
| 17:13 | <&ToxicFrog> | Unless it's doing cpp trickery to convert its entire argument into the error message. |
| 17:13 | <&ToxicFrog> | Aah. |
| 17:13 | <&McMartin> | That is exactly what it does, yes |
| 17:14 | <@simon_> | smrt. |
| 17:15 | <&Derakon> | If it wasn't doing trickery, I'm pretty sure you wouldn't even be able to get an error message containing "fin.good()". |
| 17:15 | <&Derakon> | It'd just have to say "assert failed" and leave it at that. |
| 17:15 | <&Derakon> | Since all that gets passed to assert() is a boolean. |
| 17:24 | <@RichyB> | is assert a macro that stringifies its arguments? |
| 17:24 | <&McMartin> | Part of it is, AIUI. |
| 17:24 | <@RichyB> | oh yes, that's what McM and TF said. |
| 17:36 | <@simon_> | I'm cleaning up a set of C++ benchmarks, each of which has a set of implementations. there are some libraries specific to each benchmark and a general library for all benchmarks. currently it works by #include "../include/foo.h" and #include "../../include/foo.h" - I wonder, is it good style to have relative paths going backwards like this, or should I seek to have those directories included with -I? |
| 17:38 | <&Derakon> | IMO absolute namespacing is preferable to things magically appearing in-scope, even in situations like this. |
| 17:38 | <&Derakon> | Though I question the overall structure of this codebase. |
| 17:39 | <@simon_> | I question it, too. that's why I'm hired. ;) |
| 17:40 | <@simon_> | this is my first touch with C++, though, so I'm treading lightly. one thing I've been told by two people already is to leave full functions declarations in .h files. |
| 17:40 | <&Derakon> | That's pretty common, yeah. |
| 17:41 | <&Derakon> | Generally any function or class that gets "exposed" outside of its own file should have a .h file declaring all of the things that are so exposed. |
| 17:42 | <@simon_> | no |
| 17:42 | <@simon_> | I mean, the functions are *in there*, not just the prototypes! |
| 17:42 | <&Derakon> | ...wut |
| 17:42 | <@simon_> | *shrug* |
| 17:42 | <&Derakon> | That's a definition, not a declaration. |
| 17:42 | <@simon_> | sorry, I'm kind of stuck with functional programming terminology |
| 17:43 | <@simon_> | so the reason I got was this: template-related code is supposedly forced to be in .h files because it doesn't go across compilation units. |
| 17:43 | <&Derakon> | It's been too long since I worked with templates for me to be able to tell if that's bullshit or not. |
| 17:44 | <@simon_> | it probably is. I can't see any template code, but then again I don't know what I'm looking for. ;) |
| 17:44 | <&Derakon> | Angle brackets. |
| 17:44 | <@simon_> | another reason (which I made up myself) is that the 'inline' keyword might not translate across compilation units, although I don't know and I haven't tested it. if it were anything other than benchmark code, I'd disregard it. |
| 17:45 | <@RichyB> | simon_, yes. Templates go in headers because they aren't concrete code. Code files instantiate them. |
| 17:45 | <&Derakon> | Like "std::iterator<MyClass* c>" is an iterator for a linked list of MyClass* |
| 17:45 | <&Derakon> | ...my syntax may be off there. |
| 17:45 | <&Derakon> | Like I said, been awhile. |
| 17:45 | <@simon_> | ok. well, no polymorphism here. |
| 17:45 | <&McMartin> | std::list<MyClass* c>::iterator. |
| 17:46 | <@simon_> | really, I suspect it's because the author is lazy. |
| 17:46 | <&Derakon> | Thanks, McM. |
| 17:46 | <@simon_> | I'll get around to refactoring that |
| 17:46 | <&McMartin> | simon_: The rules for what the standard said you needed to do, what you *actually* need to do, and what various compilers would accept, and what various compilers would actually handle correctly... |
| 17:46 | <&McMartin> | ... all have varied drastically over the past 20 years that templates have been part of C++ |
| 17:47 | <&McMartin> | In short: this code may be written to the de-fact requirements prior to about 2005 or so. |
| 17:47 | <@simon_> | the answer is never simple! |
| 17:47 | <&McMartin> | *de-facto |
| 17:47 | <&McMartin> | But yeah, at this point they *do* work across compilation units, and you *don't* have to hand-instantiate each set of types that you intend to ultimately use in the library that defines them |
| 17:48 | <&McMartin> | And a good thing too or the STL Wouldn't Fucking Work At All |
| 17:48 | <&McMartin> | (PS: The STL Didn't Fucking Work At All until about 2005 on most C++ implementations unless you copied it bodily into your sources) |
| 17:48 | <&Derakon> | Still worth it~ |
| 17:49 | <&Derakon> | I mean, Boost has similar issues, doesn't it? |
| 17:49 | <@simon_> | McMartin, thanks a lot! |
| 17:49 | <&McMartin> | Derakon: Not anymore, beyond components that exist only as header files |
| 17:50 | <&McMartin> | And most of those got absorbed into the C++11 standard that nobody implements yet |
| 17:50 | <@RichyB> | McMartin, what did the STL do instead of working in 2004? |
| 17:50 | <&Derakon> | Require you to copy it bodily into your sources, apparently. |
| 17:50 | <&McMartin> | You'd define a std::vector<MyClass> and libstl.a didn't have the relevant methods defined. |
| 17:50 | <&McMartin> | So you'd fail to link. |
| 17:52 | <&McMartin> | Or, you could include the complete implementation in your sources and then have a line in the MyClass header that included something like "typedef std::vector<MyClass> MyVectorClass;" or similar and it would tell the code generator "Oh, I'll need to build std::vector stuff for that" |
| 17:53 | <&McMartin> | Alternately, you could put all of std::vector's implementation in <vector>, and then it will inline the definitions as needed. |
| 17:53 | <&McMartin> | But the upside is that linking kinda does require you to have compilation steps now. |
| 17:53 | <&McMartin> | I don't remember the full set of steps you need to perform. |
| 17:54 | <&McMartin> | I think the current rule is that any method that refers to the templated type directly needs to be defined in the headers so that it can generate the code when you define MyClass. |
| 18:09 | <@simon_> | okay, so I want to change "../../include/Util.h" and "../includeC/Constants.h" into something like "Util.h" and "Constants.h", but I worry that is confusing, so perhaps "general/Util.h" and "benchmarkName/Constants.h" |
| 18:10 | <@simon_> | McMartin, thanks for the insight :) |
| 18:11 | <&McMartin> | This is why uniform reference is important in your ABI, kids |
| 18:19 | <@simon_> | it's not too verbose to have a benchmark/include/benchmark/foo.h just so I can #include "benchmark/foo.h", right? I've seen that in various linux programs. |
| 18:24 | <&ToxicFrog> | The approach we take here is headers next to implementation and include everything from repo root. |
| 18:24 | <&ToxicFrog> | So you get benchmark/foo.h and benchmark/foo.cc, and the latter #includes "benchmark/foo.h" |
| 18:31 | <@simon_> | ToxicFrog, thing is, I have a bunch of sidelined implementations that share headers. if I put them next to each other, it becomes hard to see which files belong to which benchmarks. |
| 18:31 | <@simon_> | ToxicFrog, the other extreme is having includes completely separate from implementation, right? |
| 18:31 | <@simon_> | (I currently have something in-between) |
| 18:31 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 18:41 | | Araleith [Araleith@Nightstar-gqo.7co.175.108.IP] has left #code ["Leaving"] |
| 18:45 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 18:45 | | mode/#code [+o himi] by ChanServ |
| 19:09 | | Syka [the@Nightstar-1ip.u9g.126.1.IP] has quit [Ping timeout: 121 seconds] |
| 19:17 | < Shiz> | /w 14 |
| 19:17 | <&ToxicFrog> | simon_: what do you mean by "a bunch of sidelined implementations that share headers"? |
| 19:52 | <@simon_> | ToxicFrog, I wanna make a directory structure next to my .cpp files that only contains headers. |
| 20:05 | | Red_Queen [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 20:44 | | Kindamoody|out is now known as Kindamoody |
| 20:54 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection reset by peer] |
| 21:23 | | celticminstrel [celticminst@Nightstar-mhtogh.dsl.bell.ca] has joined #code |
| 21:23 | | mode/#code [+o celticminstrel] by ChanServ |
| 21:36 | | Kindamoody is now known as Kindamoody[zZz] |
| 22:21 | | ErikMesoy is now known as ErikMesoy|sleep |
| 22:29 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 22:59 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 23:00 | | Derakon [chriswei@Nightstar-5fqf0m.ca.comcast.net] has quit [[NS] Quit: leaving] |
| 23:16 | | You're now known as TheWatcher |
| --- Log closed Wed Mar 12 00:00:52 2014 |