Switch to DuckDuckGo Search
   January 3, 2019
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31

Toggle Join/Part | bottom
[00:03:08] *** kitsunenokenja <kitsunenokenja!~kitsunech@68.91.220.96> has quit IRC (Ping timeout: 246 seconds)
[00:05:05] *** hz <hz!~hz@unaffiliated/hz> has quit IRC ()
[00:07:00] *** leafcutter <leafcutter!~leaf@216.169.22.45> has left ##C++-general ("Leaving")
[00:10:11] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[00:11:05] *** nshire <nshire!~nealshire@unaffiliated/nealshire> has joined ##C++-general
[00:13:26] *** manuelschneid3r <manuelschneid3r!~manuelsch@p200300E247231E000642CCEE8430FBE3.dip0.t-ipconnect.de> has joined ##C++-general
[00:14:24] *** immibis <immibis!~immibis@125-238-72-168-fibre.sparkbb.co.nz> has joined ##C++-general
[00:16:14] *** zap0 <zap0!~zap0@14-201-222-143.tpgi.com.au> has joined ##C++-general
[00:25:54] *** dsiypl4 <dsiypl4!~dsiypl4@196.74.131.188> has quit IRC (Ping timeout: 246 seconds)
[00:29:52] *** alyptik <alyptik!ayy@cpe-76-173-133-37.hawaii.res.rr.com> has quit IRC (Ping timeout: 272 seconds)
[00:29:52] *** ambro718 <ambro718!~ambro@unaffiliated/ambro718> has quit IRC (Ping timeout: 272 seconds)
[00:32:04] *** JPulowski <JPulowski!~JPulowski@188.119.61.179> has quit IRC (Ping timeout: 250 seconds)
[00:33:57] *** Tazmain <Tazmain!~Tazmain@unaffiliated/tazmain> has quit IRC (Quit: Left)
[00:36:09] *** jstein <jstein!~jstein@gentoo/developer/jstein> has quit IRC (Quit: quit)
[00:36:44] *** jan64 <jan64!~jan64@79.191.143.165.ipv4.supernova.orange.pl> has quit IRC (Ping timeout: 246 seconds)
[00:36:53] *** rburkholder <rburkholder!~blurb@96.45.2.121> has quit IRC (Read error: Connection reset by peer)
[00:37:05] *** rburkholder <rburkholder!~blurb@96.45.2.121> has joined ##C++-general
[00:40:59] *** genbattle <genbattle!~genbattle@2406:e007:5264:dc01:c837:16d7:b5cb:75c8> has joined ##C++-general
[00:42:40] *** genbattle <genbattle!~genbattle@2406:e007:5264:dc01:c837:16d7:b5cb:75c8> has quit IRC (Remote host closed the connection)
[00:44:56] *** JPulowski <JPulowski!~JPulowski@95.70.222.200> has joined ##C++-general
[00:50:07] *** mandeep <mandeep!mandeep@gateway/vpn/privateinternetaccess/mandeepb> has joined ##C++-general
[00:51:00] *** abraxxas <abraxxas!~phil@p5B0D9F8C.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)
[00:52:16] *** abraxxas <abraxxas!~phil@p5B0D9F8C.dip0.t-ipconnect.de> has joined ##C++-general
[00:52:51] *** marcofe <marcofe!~marcofe@host199-103-dynamic.55-82-r.retail.telecomitalia.it> has quit IRC (Quit: Konversation terminated!)
[00:59:49] *** fogbank <fogbank!~fogbank@net-188-153-77-173.cust.vodafonedsl.it> has quit IRC (Read error: Connection reset by peer)
[01:00:21] <zap0> in GCC __FILE__ give me /a/b/c/d/e/ffffff.cpp is there already something that can give me just the ffffff.cpp
[01:00:51] *** jinak <jinak!~jinak@190.176.227.82> has quit IRC (Read error: Connection reset by peer)
[01:00:54] <cbreak> what __FILE__ gives is implementation defined. But I guess boost::path stuff can do the things you want
[01:01:08] <cbreak> or just std::string's find_last_of function + substr
[01:01:42] <zap0> prefer a preprocessor, not runtime
[01:03:10] <zap0> { std::cout << __BASE_FILE__; }
[01:03:10] <geordi> 0
[01:04:29] *** JPulowski <JPulowski!~JPulowski@95.70.222.200> has quit IRC (Quit: Leaving)
[01:04:38] *** kitsunenokenja <kitsunenokenja!~kitsunech@68.91.220.96> has joined ##C++-general
[01:10:32] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has quit IRC (Read error: Connection reset by peer)
[01:10:42] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has joined ##C++-general
[01:10:58] <cbreak> zap0: compiler's not smart enough to constexpr that :( https://godbolt.org/z/s4kGFG
[01:12:05] <zap0> nice try!
[01:12:50] <cbreak> maybe with one of those template UDLs :)
[01:13:28] *** philipp_ <philipp_!~phil@p549EE6A2.dip0.t-ipconnect.de> has joined ##C++-general
[01:13:28] <zap0> if you have N, would not going backwards from N be potentially less distance, and perhaps hit processing limits less
[01:16:11] <cbreak> such optimization https://godbolt.org/z/gaJWRA
[01:16:52] <zap0> lol.. did it just unwind the loop
[01:17:08] *** abraxxas <abraxxas!~phil@p5B0D9F8C.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds)
[01:17:18] <cbreak> it did...
[01:17:52] <cbreak> GCC is significantly less dumb
[01:17:57] <cbreak> https://godbolt.org/z/oVykbG
[01:18:52] <cbreak> or clang in -O2 :)
[01:19:01] <zap0> why have a lastslash var. auto x=N-1; for ( ; path[x] != '/' ; x-- ); return &path[x+1];
[01:19:33] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!)
[01:20:09] <cbreak> I don't like backwards loops
[01:20:50] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has joined ##C++-general
[01:21:06] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has joined ##C++-general
[01:21:07] *** jthomas3 <jthomas3!~jthomas@ec2-35-160-103-195.us-west-2.compute.amazonaws.com> has quit IRC (Ping timeout: 240 seconds)
[01:21:28] *** linuxgorilla_ <linuxgorilla_!~linuxgori@2601:6c3:4100:99c:eca8:cc11:736c:4acc> has quit IRC (Remote host closed the connection)
[01:21:43] <zap0> GCC looks like it's worked. is clang not very good with constexpr ?
[01:21:46] *** linuxgorilla_ <linuxgorilla_!~linuxgori@2601:6c3:4100:99c:54b2:ca8:e32b:7d8a> has joined ##C++-general
[01:21:52] <cbreak> https://godbolt.org/z/JzeDPE
[01:21:57] <cbreak> with backwards searching it is
[01:22:07] <cbreak> it probably can't handle my if / state as well
[01:22:36] <ville> optimizers are fickle beasts. any small change can cascade
[01:23:47] <ville> ever wondered why your member functions are slow? because you didn't copy all state from member variables to function-local variables...
[01:24:02] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[01:24:11] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[01:24:44] <zap0> ville is that true of single threaded too?
[01:25:53] <ville> i've seen that happen, but that was years ago and on vc++.
[01:26:00] <zap0> or is it that if you call anything externally, that external thing could change some member state, therefore they can't be cached
[01:26:55] *** Serpent7776 <Serpent7776!~Serpent77@90-156-31-193.internetia.net.pl> has quit IRC (Quit: leaving)
[01:27:03] <ville> it's kind of hard for optimizers to prove that something is neverever touched by something else
[01:27:26] <cbreak> if there only was a way to annotate this
[01:27:57] <zap0> cbreak if only we we not restricted in our abilities to annotate this
[01:28:17] <cbreak> pass-by-value should work ok :)
[01:28:25] <cbreak> guaranteed alias free :)
[01:28:39] *** morfin60 <morfin60!~morfin@85.12.195.47> has quit IRC (Read error: Connection reset by peer)
[01:29:08] *** alyptik <alyptik!ayy@cpe-76-173-133-37.hawaii.res.rr.com> has joined ##C++-general
[01:30:15] <ville> like i said copying to function-locals, but then why did you make it a member function to begin with.
[01:30:42] <cbreak> still, the compiler isn't smart enough to notice that the parts before the / are not needed
[01:30:59] <cbreak> ville: in my tests some time ago, not interleaving writes and reads seemed effective
[01:34:24] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has quit IRC (Remote host closed the connection)
[01:34:46] *** gopar <gopar!~gopar@c-73-170-87-34.hsd1.ca.comcast.net> has quit IRC ()
[01:36:03] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has joined ##C++-general
[01:36:41] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has quit IRC (Client Quit)
[01:36:57] *** kadoban <kadoban!~mud@unaffiliated/kadoban> has joined ##C++-general
[01:38:03] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has joined ##C++-general
[01:38:36] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has quit IRC (Client Quit)
[01:39:13] <ville> could very well be, not an expert or even very experienced in this area, only occasionally look at this stuff.
[01:39:36] <ville> certainly get surprised lot of the time
[01:39:46] *** pulse_ <pulse_!~pulse@unaffiliated/pulse> has joined ##C++-general
[01:41:29] *** pulse <pulse!~pulse@unaffiliated/pulse> has quit IRC (Ping timeout: 246 seconds)
[01:41:34] <cbreak> zap0: this time clang's better :) https://godbolt.org/z/ePHa4L
[01:42:21] <zap0> nice!
[01:43:06] *** manuelschneid3r <manuelschneid3r!~manuelsch@p200300E247231E000642CCEE8430FBE3.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 260 seconds)
[01:44:30] *** SwiftMatt <SwiftMatt!~Objective@36.102.208.84> has joined ##C++-general
[01:46:34] *** kedziorno <kedziorno!~kedziorno@176.100.198.27.studiowik.net.pl> has quit IRC (Remote host closed the connection)
[01:47:53] *** SwiftMatt <SwiftMatt!~Objective@36.102.208.84> has quit IRC (Client Quit)
[01:50:11] *** eadthem <eadthem!~eadthem@pdpc/supporter/active/eadthem> has joined ##C++-general
[01:51:32] <zap0> this one https://godbolt.org/z/JzeDPE still stores the complete path in the .string section
[01:52:07] <zap0> oh, you already said that.
[01:52:21] *** ravi__ <ravi__!~ravi@2a02:908:698:68a0:fd66:75f8:3696:4763> has quit IRC (Ping timeout: 252 seconds)
[01:57:42] *** manuelschneid3r <manuelschneid3r!~manuelsch@p200300E2472CC5005F20BF21368481E4.dip0.t-ipconnect.de> has joined ##C++-general
[01:59:36] *** seni <seni!~Nimitz14@cpc91218-cmbg18-2-0-cust107.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[02:01:06] *** de-facto <de-facto!~de-facto@gateway/tor-sasl/de-facto> has quit IRC (Quit: See you around.)
[02:01:21] *** de-facto <de-facto!~de-facto@gateway/tor-sasl/de-facto> has joined ##C++-general
[02:01:39] *** jinak <jinak!~jinak@190.176.227.82> has joined ##C++-general
[02:07:06] <cbreak> I think it is because it can't assume that I only access the chars positive of the pointer
[02:10:05] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has joined ##C++-general
[02:22:24] <zap0> i think it can be determined. it's more likely that no one has bothered to write this optimization (of not storing parts of strings never referenced)
[02:22:25] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has quit IRC (Remote host closed the connection)
[02:23:51] *** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has joined ##C++-general
[02:28:49] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC (Read error: Connection reset by peer)
[02:28:49] <Aleric> Man, nothing works to stop youtube from asking "Are you still there?"
[02:32:58] *** kitsunenokenja <kitsunenokenja!~kitsunech@68.91.220.96> has quit IRC (Ping timeout: 250 seconds)
[02:34:09] *** mackal <mackal!~mike@pool-98-118-112-22.bstnma.fios.verizon.net> has quit IRC (Quit: BE VIGILANT.)
[02:35:34] *** Ingersol <Ingersol!~Ingersol@host-static-93-116-234-146.moldtelecom.md> has quit IRC (Ping timeout: 250 seconds)
[02:35:58] <zap0> :( __BASE_FILE__ and __FILE__ return the same thing, full path
[02:37:24] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has quit IRC (Quit: Leaving)
[02:39:03] *** Woodpecker <Woodpecker!uid241015@gateway/web/irccloud.com/x-cqqpmiwcunugsimw> has joined ##C++-general
[02:41:41] <Aleric> Oh! http://quick-bench.com/
[02:41:45] <Aleric> Kewlies
[02:42:14] *** sanett <sanett!~sanett@218.255.175.31> has joined ##C++-general
[02:43:48] *** sanett <sanett!~sanett@218.255.175.31> has quit IRC (Client Quit)
[02:46:23] *** jellycode <jellycode!~jellycode@2601:408:8000:6569:814f:9545:2d78:fe66> has joined ##C++-general
[02:47:16] *** lh_mouse <lh_mouse!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has joined ##C++-general
[02:52:16] *** Stanley00 <Stanley00!~Stanley00@unaffiliated/stanley00> has quit IRC (Remote host closed the connection)
[02:52:56] *** Stanley00 <Stanley00!~Stanley00@unaffiliated/stanley00> has joined ##C++-general
[02:55:03] *** gabrielschulhof <gabrielschulhof!~nix@unaffiliated/nix/x-562542> has quit IRC (Ping timeout: 245 seconds)
[02:57:20] *** mistergold <mistergold!~mistergol@77.243.26.11> has joined ##C++-general
[02:58:49] *** Forsaken87 <Forsaken87!~quassel@2a02:908:1869:4b20:f4b0:188b:cefd:b063> has joined ##C++-general
[03:02:28] *** mistergold <mistergold!~mistergol@77.243.26.11> has quit IRC (Ping timeout: 246 seconds)
[03:03:33] *** fairuz <fairuz!~textual@unaffiliated/fairuz> has joined ##C++-general
[03:04:26] *** philipp_ <philipp_!~phil@p549EE6A2.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 246 seconds)
[03:04:47] *** fairuz <fairuz!~textual@unaffiliated/fairuz> has quit IRC (Client Quit)
[03:09:04] *** mistergold <mistergold!~mistergol@77.243.26.11> has joined ##C++-general
[03:09:20] *** mistergold <mistergold!~mistergol@77.243.26.11> has quit IRC (Read error: Connection reset by peer)
[03:14:27] *** dx_ob_ <dx_ob_!~OtakuSenp@unaffiliated/neel> has joined ##C++-general
[03:15:26] *** dx_ob <dx_ob!~OtakuSenp@unaffiliated/neel> has quit IRC (Ping timeout: 250 seconds)
[03:22:13] *** PSvils <PSvils!~PDevelope@91.105.108.4> has quit IRC (Quit: Leaving.)
[03:25:18] *** LunarJetman <LunarJetman!LunarJetma@94.196.247.102.threembb.co.uk> has quit IRC (Ping timeout: 272 seconds)
[03:29:14] *** hubnerd <hubnerd!~weechat@2a02:8010:612b:1:6a05:caff:fe61:cbfb> has joined ##C++-general
[03:31:20] *** pulse_ <pulse_!~pulse@unaffiliated/pulse> has quit IRC (Quit: pulse_)
[03:31:54] *** dx_ob_ <dx_ob_!~OtakuSenp@unaffiliated/neel> has quit IRC (Ping timeout: 250 seconds)
[03:32:10] *** kitsunenokenja <kitsunenokenja!~kitsunech@68.91.220.96> has joined ##C++-general
[03:33:00] *** dx_ob <dx_ob!~OtakuSenp@unaffiliated/neel> has joined ##C++-general
[03:33:41] *** hubnerd <hubnerd!~weechat@2a02:8010:612b:1:6a05:caff:fe61:cbfb> has quit IRC (Ping timeout: 250 seconds)
[03:34:52] *** hubnerd <hubnerd!~weechat@2a02:8010:612b:1:6a05:caff:fe61:cbfb> has joined ##C++-general
[03:38:09] *** lh_ideapad <lh_ideapad!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has joined ##C++-general
[03:52:24] *** dx_ob <dx_ob!~OtakuSenp@unaffiliated/neel> has quit IRC (Ping timeout: 246 seconds)
[03:56:01] *** wildlander <wildlander!~wildlande@unaffiliated/wildlander> has quit IRC (Ping timeout: 246 seconds)
[03:59:53] *** dx_ob <dx_ob!~OtakuSenp@unaffiliated/neel> has joined ##C++-general
[04:00:01] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has joined ##C++-general
[04:00:21] *** manuelschneid3r <manuelschneid3r!~manuelsch@p200300E2472CC5005F20BF21368481E4.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 268 seconds)
[04:02:47] <Ameisen> Trying to use modules in Visual C++ 2017... is it normal for it to be unable to build them in the proper order?
[04:03:09] *** jellycode <jellycode!~jellycode@2601:408:8000:6569:814f:9545:2d78:fe66> has quit IRC (Quit: Leaving)
[04:03:15] <Ameisen> if I have modules that dpeend on one another, I have to compile them in the right order manually, otherwise I get an error stating that it could not find the imported module.
[04:09:44] *** esrse <esrse!~nil@175.126.171.165> has joined ##C++-general
[04:09:54] *** gehn <gehn!gehn@gateway/vpn/privateinternetaccess/gehn> has quit IRC (Quit: Leaving)
[04:10:03] <Stryyker> Ameisen: no idea of the answer but which version of VC++ 2017 do you have?
[04:10:10] <Stryyker> They have released many updates
[04:10:47] <Ameisen> I am entirely up to date, and have 2017 and 2019 Preview
[04:10:55] <Stryyker> 15.9.4 released last month
[04:11:08] <Stryyker> Does 2019 have the same issue?
[04:11:18] <Ameisen> yes
[04:12:29] *** fairuz <fairuz!~textual@unaffiliated/fairuz> has joined ##C++-general
[04:13:34] *** wildlander <wildlander!~wildlande@unaffiliated/wildlander> has joined ##C++-general
[04:17:35] *** eadthem <eadthem!~eadthem@pdpc/supporter/active/eadthem> has quit IRC (Remote host closed the connection)
[04:22:58] *** linuxgorilla_ <linuxgorilla_!~linuxgori@2601:6c3:4100:99c:54b2:ca8:e32b:7d8a> has quit IRC (Remote host closed the connection)
[04:23:26] *** linuxgorilla_ <linuxgorilla_!~linuxgori@2601:6c3:4100:99c:54b2:ca8:e32b:7d8a> has joined ##C++-general
[04:27:08] *** ViralTaco <ViralTaco!~dork@unaffiliated/d-b/x-8688605> has joined ##C++-general
[04:27:58] *** linuxgorilla_ <linuxgorilla_!~linuxgori@2601:6c3:4100:99c:54b2:ca8:e32b:7d8a> has quit IRC (Read error: Connection reset by peer)
[04:28:26] *** linuxgorilla_ <linuxgorilla_!~linuxgori@2601:6c3:4100:99c:54b2:ca8:e32b:7d8a> has joined ##C++-general
[04:29:54] *** SwiftMatt <SwiftMatt!~Objective@36.102.208.84> has joined ##C++-general
[04:30:03] *** SwiftMatt <SwiftMatt!~Objective@36.102.208.84> has quit IRC (Client Quit)
[04:30:07] *** jinak <jinak!~jinak@190.176.227.82> has quit IRC (Ping timeout: 240 seconds)
[04:31:58] *** linuxgorilla_ <linuxgorilla_!~linuxgori@2601:6c3:4100:99c:54b2:ca8:e32b:7d8a> has quit IRC (Read error: Connection reset by peer)
[04:32:01] *** jinak <jinak!~jinak@190.176.240.225> has joined ##C++-general
[04:32:26] *** linuxgorilla_ <linuxgorilla_!~linuxgori@2601:6c3:4100:99c:54b2:ca8:e32b:7d8a> has joined ##C++-general
[04:34:58] *** dx_ob <dx_ob!~OtakuSenp@unaffiliated/neel> has quit IRC (Ping timeout: 272 seconds)
[04:39:04] *** wildlander <wildlander!~wildlande@unaffiliated/wildlander> has quit IRC (Ping timeout: 246 seconds)
[04:39:50] *** SwiftMatt <SwiftMatt!~Objective@183.240.196.120> has joined ##C++-general
[04:43:01] *** fairuz <fairuz!~textual@unaffiliated/fairuz> has quit IRC (Ping timeout: 250 seconds)
[04:48:16] *** Lord_of_Life <Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362> has quit IRC (Ping timeout: 272 seconds)
[04:48:21] *** Lord_of_Life_ <Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362> has joined ##C++-general
[04:49:30] *** Lord_of_Life_ is now known as Lord_of_Life
[04:58:23] *** hubnerd <hubnerd!~weechat@2a02:8010:612b:1:6a05:caff:fe61:cbfb> has quit IRC (Quit: WeeChat 2.3)
[04:59:34] *** ogres <ogres!uid159312@gateway/web/irccloud.com/x-nnfgqkuruhdqlugn> has joined ##C++-general
[04:59:37] <ogres> Hello!!
[04:59:44] <ogres> Anyone know how to detach from a poco thread?
[05:02:27] *** dx_ob <dx_ob!~OtakuSenp@unaffiliated/neel> has joined ##C++-general
[05:08:11] *** SwiftMatt <SwiftMatt!~Objective@183.240.196.120> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[05:08:54] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has joined ##C++-general
[05:09:32] *** fc5dc9d4 <fc5dc9d4!~quassel@p5B081E7E.dip0.t-ipconnect.de> has joined ##C++-general
[05:10:31] *** freakazoid0223 <freakazoid0223!~matt@pool-108-52-159-210.phlapa.fios.verizon.net> has quit IRC (Remote host closed the connection)
[05:11:50] *** fc5dc9d4_ <fc5dc9d4_!~quassel@p5B3A806B.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 246 seconds)
[05:24:03] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[05:24:07] *** Roughy <Roughy!~mdaw45ns@188.126.203.78> has quit IRC (Quit: Meadow Fresh milk)
[05:24:11] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[05:27:30] *** Forsaken87 <Forsaken87!~quassel@2a02:908:1869:4b20:f4b0:188b:cefd:b063> has quit IRC (Ping timeout: 252 seconds)
[05:31:12] *** mackal <mackal!~mike@pool-98-118-112-22.bstnma.fios.verizon.net> has joined ##C++-general
[05:35:28] *** arch-1980 <arch-1980!~arch@93.114.71.39> has quit IRC (Remote host closed the connection)
[05:35:37] *** jthomas3 <jthomas3!~jthomas@c-98-202-237-95.hsd1.ut.comcast.net> has joined ##C++-general
[05:40:03] *** jthomas3 <jthomas3!~jthomas@c-98-202-237-95.hsd1.ut.comcast.net> has quit IRC (Ping timeout: 245 seconds)
[05:43:15] *** Woodpecker <Woodpecker!uid241015@gateway/web/irccloud.com/x-cqqpmiwcunugsimw> has quit IRC (Quit: Connection closed for inactivity)
[05:44:11] *** proteusguy <proteusguy!~proteus-g@cm-58-10-154-246.revip7.asianet.co.th> has quit IRC (Remote host closed the connection)
[05:50:36] <zap0> im having troubles with std::thread
[05:50:44] <zap0> keeps aborting
[05:51:52] *** lh_ideapad <lh_ideapad!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has quit IRC (Ping timeout: 250 seconds)
[05:53:45] <s_frit> aborting?
[05:55:46] *** tm <tm!~sinnlos@unaffiliated/tm> has quit IRC (Ping timeout: 250 seconds)
[05:56:58] *** AbleBacon_ <AbleBacon_!~AbleBacon@unaffiliated/ablebacon> has joined ##C++-general
[05:57:46] *** AbleBacon_ <AbleBacon_!~AbleBacon@unaffiliated/ablebacon> has quit IRC (Read error: Connection reset by peer)
[06:00:10] *** proteusguy <proteusguy!~proteus-g@mx-ll-183.89.213-60.dynamic.3bb.co.th> has joined ##C++-general
[06:00:34] *** tm <tm!~sinnlos@unaffiliated/tm> has joined ##C++-general
[06:00:57] *** zap0 <zap0!~zap0@14-201-222-143.tpgi.com.au> has quit IRC (Quit: zap0)
[06:02:42] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has quit IRC (Remote host closed the connection)
[06:03:00] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has joined ##C++-general
[06:06:19] <ViralTaco> abortion is murder ;-;
[06:08:42] *** kitsunenokenja <kitsunenokenja!~kitsunech@68.91.220.96> has quit IRC (Ping timeout: 268 seconds)
[06:12:40] *** UnDeRsOuL <UnDeRsOuL!~UnDeRsOuL@unaffiliated/undersoul> has quit IRC (Ping timeout: 250 seconds)
[06:14:25] *** jinak_ <jinak_!~jinak@190.176.240.225> has joined ##C++-general
[06:15:00] *** jinak_ <jinak_!~jinak@190.176.240.225> has quit IRC (Read error: Connection reset by peer)
[06:15:04] *** UnDeRsOuL <UnDeRsOuL!~UnDeRsOuL@unaffiliated/undersoul> has joined ##C++-general
[06:16:08] *** jinak <jinak!~jinak@190.176.240.225> has quit IRC (Ping timeout: 250 seconds)
[06:17:34] *** IceN9ne <IceN9ne!~ice9@kvirc/developer/IceN9ne> has quit IRC (Ping timeout: 272 seconds)
[06:29:09] *** josef_k <josef_k!~jeremy@ppp118-209-193-16.bras2.mel11.internode.on.net> has joined ##C++-general
[06:29:19] *** libertyp1ime <libertyp1ime!~libertypr@66.87.69.111.dynamic.snap.net.nz> has quit IRC (Ping timeout: 246 seconds)
[06:29:37] *** libertyprime <libertyprime!~libertypr@66.87.69.111.dynamic.snap.net.nz> has quit IRC (Ping timeout: 250 seconds)
[06:35:02] *** IceN9ne <IceN9ne!~ice9@kvirc/developer/IceN9ne> has joined ##C++-general
[06:36:45] *** josef__k <josef__k!~jeremy@1.136.110.155> has joined ##C++-general
[06:39:27] *** josef_k <josef_k!~jeremy@ppp118-209-193-16.bras2.mel11.internode.on.net> has quit IRC (Ping timeout: 240 seconds)
[06:41:45] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has quit IRC (Remote host closed the connection)
[06:41:58] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has joined ##C++-general
[06:43:08] *** led_dark_1 <led_dark_1!~Thunderbi@hotspot10.rywasoft.net> has quit IRC (Quit: led_dark_1)
[06:44:26] *** jinak <jinak!~jinak@190.176.240.225> has joined ##C++-general
[06:45:31] *** fattest <fattest!b4966b4b@gateway/web/freenode/ip.180.150.107.75> has joined ##C++-general
[06:46:47] *** dx_ob <dx_ob!~OtakuSenp@unaffiliated/neel> has quit IRC (Ping timeout: 240 seconds)
[06:49:08] *** dx_ob <dx_ob!~OtakuSenp@unaffiliated/neel> has joined ##C++-general
[06:52:06] *** quarterback <quarterback!~quarterba@160.238.72.235> has joined ##C++-general
[06:52:06] *** quarterback <quarterback!~quarterba@160.238.72.235> has quit IRC (Changing host)
[06:52:06] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has joined ##C++-general
[06:53:27] *** fairuz <fairuz!~textual@unaffiliated/fairuz> has joined ##C++-general
[06:53:49] *** rizzo <rizzo!~RizzoTheR@dyndsl-091-096-003-056.ewe-ip-backbone.de> has quit IRC (Ping timeout: 246 seconds)
[06:59:11] *** Wetmelon <Wetmelon!~wetmelon@2600:1700:2601:7c40:9570:2a39:3143:1250> has quit IRC (Ping timeout: 268 seconds)
[07:00:09] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[07:01:45] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has joined ##C++-general
[07:02:55] *** rizzo <rizzo!~RizzoTheR@dyndsl-037-138-168-245.ewe-ip-backbone.de> has joined ##C++-general
[07:03:37] *** SirFancyPantsOfP <SirFancyPantsOfP!~SirFancyP@37.186.119.154> has quit IRC (Ping timeout: 246 seconds)
[07:04:31] *** SirFancyPantsOfP <SirFancyPantsOfP!~SirFancyP@37.186.119.154> has joined ##C++-general
[07:05:44] *** batman_nair <batman_nair!~batman_na@111.92.74.136> has joined ##C++-general
[07:11:10] *** libertyprime <libertyprime!~libertypr@101.98.42.91> has joined ##C++-general
[07:11:19] *** libertyp1ime <libertyp1ime!~libertypr@101.98.42.91> has joined ##C++-general
[07:20:46] *** alyptik <alyptik!ayy@cpe-76-173-133-37.hawaii.res.rr.com> has quit IRC (Ping timeout: 246 seconds)
[07:24:03] *** dholmes3 <dholmes3!~dholmes@c-73-164-101-81.hsd1.mn.comcast.net> has joined ##C++-general
[07:24:42] *** dinfuehr <dinfuehr!~dinfuehr@91-113-43-70.adsl.highway.telekom.at> has quit IRC (Ping timeout: 272 seconds)
[07:25:42] *** dinfuehr <dinfuehr!~dinfuehr@91-114-128-221.adsl.highway.telekom.at> has joined ##C++-general
[07:26:37] *** fattest <fattest!b4966b4b@gateway/web/freenode/ip.180.150.107.75> has quit IRC (Ping timeout: 256 seconds)
[07:27:58] *** dholmes2 <dholmes2!~dholmes@c-73-164-101-81.hsd1.mn.comcast.net> has quit IRC (Ping timeout: 245 seconds)
[07:34:40] *** mitch0 <mitch0!~mitch@188-143-22-175.pool.digikabel.hu> has joined ##C++-general
[07:38:18] *** lh_ideapad <lh_ideapad!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has joined ##C++-general
[07:49:18] *** josef__k <josef__k!~jeremy@1.136.110.155> has quit IRC (Ping timeout: 250 seconds)
[07:49:29] *** XCE <XCE!~XCE@104-3-184-7.lightspeed.sntcca.sbcglobal.net> has joined ##C++-general
[07:49:40] *** bONE87 <bONE87!~bONE87@cable-24-135-40-101.dynamic.sbb.rs> has joined ##C++-general
[07:51:21] *** alyptik <alyptik!ayy@cpe-76-173-133-37.hawaii.res.rr.com> has joined ##C++-general
[07:53:12] *** Haohmaru <Haohmaru!~Haohmaru@195.24.53.110> has joined ##C++-general
[07:54:04] *** dinfuehr <dinfuehr!~dinfuehr@91-114-128-221.adsl.highway.telekom.at> has quit IRC (Ping timeout: 250 seconds)
[07:56:25] *** nblade42 <nblade42!~Miranda_4@ptr-91b6nnt8zwrtpt3vg7x.18120a2.ip6.access.telenet.be> has joined ##C++-general
[07:57:25] *** dinfuehr <dinfuehr!~dinfuehr@91-114-130-244.adsl.highway.telekom.at> has joined ##C++-general
[07:58:02] *** kallesbar <kallesbar!~kallesbar@188.126.80.24> has joined ##C++-general
[08:02:25] *** biberu <biberu!~biberu@c83-251-152-254.bredband.comhem.se> has joined ##C++-general
[08:03:18] *** fairuz <fairuz!~textual@unaffiliated/fairuz> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[08:06:12] *** dinfuehr <dinfuehr!~dinfuehr@91-114-130-244.adsl.highway.telekom.at> has quit IRC (Ping timeout: 250 seconds)
[08:06:47] *** dinfuehr <dinfuehr!~dinfuehr@194-166-77-139.adsl.highway.telekom.at> has joined ##C++-general
[08:11:02] *** dinfuehr <dinfuehr!~dinfuehr@194-166-77-139.adsl.highway.telekom.at> has quit IRC (Ping timeout: 246 seconds)
[08:11:25] *** alexge50 <alexge50!~alexge50@unaffiliated/alexge50> has quit IRC (Remote host closed the connection)
[08:11:46] *** dinfuehr <dinfuehr!~dinfuehr@91-113-47-125.adsl.highway.telekom.at> has joined ##C++-general
[08:13:39] *** riksteri <riksteri!~SpaceDino@213.152.161.15> has joined ##C++-general
[08:16:23] *** proteusguy <proteusguy!~proteus-g@mx-ll-183.89.213-60.dynamic.3bb.co.th> has quit IRC (Ping timeout: 244 seconds)
[08:22:25] *** Tazmain <Tazmain!~Tazmain@unaffiliated/tazmain> has joined ##C++-general
[08:24:57] *** gulzar <gulzar!~gulzar@14.139.123.36> has joined ##C++-general
[08:27:26] *** libertyprime <libertyprime!~libertypr@101.98.42.91> has quit IRC (Ping timeout: 250 seconds)
[08:27:52] *** libertyp1ime <libertyp1ime!~libertypr@101.98.42.91> has quit IRC (Ping timeout: 250 seconds)
[08:28:38] *** proteusguy <proteusguy!~proteus-g@mx-ll-183.89.213-60.dynamic.3bb.co.th> has joined ##C++-general
[08:32:43] *** esrse <esrse!~nil@175.126.171.165> has quit IRC (Read error: Connection reset by peer)
[08:35:10] *** esrse <esrse!~nil@175.126.171.165> has joined ##C++-general
[08:37:26] *** metaman <metaman!~metaman@108.166.152.162> has joined ##C++-general
[08:38:01] *** josef__k <josef__k!~jeremy@1.136.107.93> has joined ##C++-general
[08:39:59] *** Codyer <Codyer!~user@x5f74bfc8.dyn.telefonica.de> has joined ##C++-general
[08:40:01] *** libertyprime <libertyprime!~libertypr@101.98.42.91> has joined ##C++-general
[08:40:02] *** libertyp1ime <libertyp1ime!~libertypr@101.98.42.91> has joined ##C++-general
[08:42:28] *** jan64 <jan64!~jan64@79.191.143.165.ipv4.supernova.orange.pl> has joined ##C++-general
[08:45:28] *** dinfuehr <dinfuehr!~dinfuehr@91-113-47-125.adsl.highway.telekom.at> has quit IRC (Ping timeout: 246 seconds)
[08:46:20] *** dinfuehr <dinfuehr!~dinfuehr@91-114-131-44.adsl.highway.telekom.at> has joined ##C++-general
[08:52:07] *** zv <zv!~zv@unaffiliated/zv> has joined ##C++-general
[08:55:39] *** dx_ob <dx_ob!~OtakuSenp@unaffiliated/neel> has quit IRC (Ping timeout: 244 seconds)
[08:58:14] *** janco <janco!~janco@spf.debosschen.fiberwifihw.nl> has joined ##C++-general
[08:58:39] *** BOKALDO <BOKALDO!~BOKALDO@46.109.206.127> has joined ##C++-general
[08:59:25] *** PSvils <PSvils!~PDevelope@91.105.108.4> has joined ##C++-general
[09:01:34] *** libertyp1ime <libertyp1ime!~libertypr@101.98.42.91> has quit IRC (Ping timeout: 246 seconds)
[09:01:34] *** libertyprime <libertyprime!~libertypr@101.98.42.91> has quit IRC (Ping timeout: 246 seconds)
[09:03:15] *** klip <klip!tomas@klapka.cz> has joined ##C++-general
[09:04:07] <Aleric> I am going to design a fuzzy boolean class... One that has four possible values: true, probably, maybe and false.
[09:04:26] *** Appleman1234 <Appleman1234!~quassel@101.163.11.62> has quit IRC (Ping timeout: 244 seconds)
[09:04:52] <tz> why not 5? true/likely/maybe/unlikely/false? surely you can throw more in?
[09:05:17] <Aleric> Or actually... the probably is going to mean "it was true when I looked by maybe another thread changed it in the few nanoseconds that passed since".
[09:06:08] <Aleric> tz, I thought about that too - but rejected it as useful on intuition... based on the intended application (races)
[09:06:17] <s_frit> when is it true or false? when no other threads hold a reference?
[09:06:37] <Aleric> When it is not possible for another thread to change it.
[09:07:02] <s_frit> ok. so you have read-only clients and read/write clients
[09:07:47] <s_frit> i'm curious how you make the client join/leave protocol race-free
[09:07:51] <Aleric> I'm (still :() working on this buffer with one producer and one consumer. If the producer checks if the buffer is empty and it is, then that would be 'true'; but if it isn't then the result would be 'probably'.
[09:08:23] <Aleric> No, not probably... maybe.
[09:08:31] <s_frit> hmm
[09:08:46] <immibis> you forgot file_not_found
[09:08:50] <s_frit> isn't it better to model that as not-full and not-empty
[09:08:58] <Aleric> Not good words anyway... I want them to reflect that it was "no, a very short time ago, and maybe still no"
[09:09:05] <immibis> most people would just call the function isProbablyEmpty
[09:09:09] <immibis> and have it return true/false
[09:09:21] <immibis> or have a poll method that returns null or not-null
[09:09:43] <s_frit> "most people" is not necessarily a good heuristic for designing working software
[09:09:49] <Aleric> :)
[09:09:56] <immibis> actually a better idea is to see if you can do without this method
[09:09:59] <Aleric> I think this will work better for me.
[09:10:16] <Aleric> I can't... I've been trying for weeks.
[09:10:18] <immibis> what's the producer going to use the function for?
[09:11:03] <Aleric> Sorry, but I want to concentrate of making this now - not what the producer is going to use it for because I just got stuck on the whole thing. It's too complex.
[09:11:40] <immibis> it will be twice as hard to debug as it is to write.
[09:11:42] <s_frit> my two cents: it is better to use the idea of monotonic variables
[09:12:13] <Aleric> I like the likely / unlikely names by tz, but I'm wondering if there isn't a way to built into the name that the likeliness depends on the short time that was passed.
[09:12:26] <Aleric> Hmm... 'recently' ?
[09:13:02] <Aleric> true/recently/not_recently/false
[09:13:03] <s_frit> e.g. the producer's measurement of the fill-level can only be an accurate-or-overestimate, the consumer's view can only be an accurate-or-underestimate
[09:13:31] *** ViralTaco <ViralTaco!~dork@unaffiliated/d-b/x-8688605> has quit IRC (Quit: gnight)
[09:14:40] <Aleric> s_frit: true - but that is for integer values useful, not for a yes/no question.
[09:15:16] *** fairuz <fairuz!~textual@unaffiliated/fairuz> has joined ##C++-general
[09:15:54] <s_frit> Aleric: well, it still applies to two-valued problems.
[09:16:22] <s_frit> Aleric: in which case I think it's more-or-less what you're talking about
[09:16:25] <ville> just do: true, prefix_true, prefix_false, false. now whether you do "likely" or "recently" as prefix is upto you
[09:16:29] <immibis> what's wrong with: enum class fill_level_as_seen_by_producer {definitely_empty, maybe_not_empty};
[09:16:41] <s_frit> Aleric: what exactly is the problem you're trying to solve with these extra values?
[09:17:00] <immibis> s_frit: I already asked that, the answer was "I want to concentrate of making this now - not what the producer is going to use it for"
[09:17:20] <ville> is this some kind of lock-free queue?
[09:17:26] <Aleric> yeah
[09:18:12] <Aleric> If I were to block the producer just because the consumer wants to know if the buffer is full... that doesn't feel right :p
[09:18:20] <s_frit> as far as i can tell, the producer can only see two possible values, and the consumer can only see two possible values, so i'm not sure what 4-valued logic adds
[09:18:36] <s_frit> what?
[09:19:00] *** arch-1980 <arch-1980!~arch@93.114.71.39> has joined ##C++-general
[09:19:19] <ville> Aleric: lock-free doesn't mean wait-free
[09:19:22] <s_frit> the consumer should only care if there is data available, not whether the buffer is full
[09:19:33] <Aleric> ville: but what prefix to use to make clear that the 'measurement' was true just a split second ago?
[09:19:52] *** Appleman1234 <Appleman1234!~quassel@101.163.11.62> has joined ##C++-general
[09:19:55] *** fairuz <fairuz!~textual@unaffiliated/fairuz> has quit IRC (Ping timeout: 250 seconds)
[09:20:00] <s_frit> Aleric: ok, so you're just trying to model the actual semantics more accurately, not do anything special
[09:20:16] <Aleric> If I do 'recently' you can read that "it was recently, but not any longer" :/. Same with 'recently_true'.
[09:20:24] <s_frit> Aleric: in that case wouldn't it make sense to have two different two-valued types, not a single four-valued type?
[09:20:53] <ville> Aleric: ever watched tony van eerd's videos?
[09:20:57] <Aleric> s_frit: I might want to applied the NOT operator to it :/
[09:21:13] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has quit IRC (Ping timeout: 250 seconds)
[09:21:37] <Aleric> And yes, it is not anything special - it's just to make the code better readable and understand what is going on.
[09:22:03] <T`aZ_> Aleric: maybe before doing lock free structure, you should learn how to properly handle shared data
[09:22:14] <Aleric> lol
[09:22:39] <s_frit> i love how people love to give advice about whether or not to do lock-free when they clearly have insufficient info to make a judgement
[09:23:42] <Aleric> The urge to "defend" myself in those situation went away decades ago for me :p.
[09:23:47] <immibis> Aleric: are you *sure* it's easier than having isFree return a bool?
[09:24:00] <T`aZ_> because when you read a shared state, after the read/release that lock, that state might have changed, this is the basic behaviour, you should always have that in mind, this is not a tricky case, this is the default case
[09:24:03] <immibis> or more robust, or more maintainable, or whatever
[09:24:03] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[09:24:12] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[09:24:32] <T`aZ_> meaning that if you tr to solve the problem "but that state mught have changed now" you are doing it wrong
[09:24:39] <T`aZ_> might*
[09:24:51] <immibis> good point T`aZ_. *Every* piece of data has this problem, not just the buffer empty status.
[09:25:36] <Aleric> immibis: yes, because it contains more information. I could use a function called isMaybeEmpty() - but then I have to make sure I only call it from the ... hmm, that's what I mean, consumer or producer?
[09:25:36] <s_frit> T`aZ_: which is what i said originally: <s_frit> isn't it better to model that as not-full and not-empty
[09:26:04] <immibis> Aleric: well if you call it isEmpty then how does it know whether it's being called from the consumer, producer, or some other thread entirely?
[09:26:16] <T`aZ_> s_frit: yes indeed :)
[09:26:25] <immibis> the consumer can see full and maybe_empty, the producer can see maybe_full and empty, any other thread might see maybe_full and maybe_empty
[09:26:42] <immibis> (you might wonder what's the point of having a function that only returns maybes)
[09:26:55] <T`aZ_> s_frit: or maybe not, the point im making is to try to solve a solvable problem
[09:27:00] *** dzejrou <dzejrou!dzejrou@nat/suse/x-zpbibkobjntbznxa> has joined ##C++-general
[09:28:17] <T`aZ_> and seeing somebody speaking about lock free data structure without grasping basic concepts, i had to say something :p
[09:29:22] <Aleric> immibis: good point which I hoped you'd miss :p. Currently I am passing (empty) objects around that force me to realize which thread it is :/... So, yes, I will have two versions anyway - which could be called bool probablyEmpty(GetThread) and maybeEmpty(PutThread), but somehow I feel it's going to be easier if I don't have to think of a new name for every function like that - and just deal in the proper way with the results.
[09:29:42] <s_frit> T`aZ_: i don't generally learn linearly, so I'm generally loath to discourage people who want to jump in the deep end before they can float
[09:29:44] <T`aZ_> doing multithreaded code is already, based on my experience, very fscking hard, custom lockfree algorithm should be done after mastering that first
[09:30:50] <T`aZ_> well, to each his own way of studying
[09:31:11] <Aleric> This happens every time I ask for help with names :p ... people start to discuss the "is it needed" instead of suggesting correct english names :/
[09:31:18] *** josef__k <josef__k!~jeremy@1.136.107.93> has quit IRC (Ping timeout: 244 seconds)
[09:31:52] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has quit IRC (Quit: Leaving)
[09:32:40] <s_frit> Aleric: really you want a separate interface for each side (producer/consumer).. but i haven't worked out how to model that
[09:32:59] <Aleric> I just need four english words... true, or yes, or certain... on one side, and false, no, nope on the other side... but what to use in between? Where the meaning of the second (enum) value is that it was measured to be true but MIGHT have changed by another thread in the last 100 ns.
[09:33:26] <s_frit> Aleric: the fact that you can't find the words might point to a problem with your model :)
[09:33:27] <immibis> dont_know
[09:33:46] <s_frit> was_true, was_false
[09:34:13] <s_frit> was_true_but_could_become_false, was_false_but_could_become_true
[09:34:14] <T`aZ_> don't forget the 'was_true_and_still_true_maybe'
[09:34:21] *** quarterback <quarterback!~quarterba@160.238.72.235> has joined ##C++-general
[09:34:21] *** quarterback <quarterback!~quarterba@160.238.72.235> has quit IRC (Changing host)
[09:34:21] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has joined ##C++-general
[09:34:57] <Aleric> How about putting 'true' upfront.. that might repair the problem of misunderstanding it like I described before... Aka... true_recently. Seems better than recently_true
[09:35:01] <s_frit> i think was_true_and_still_true_maybe ~ was_true_but_could_become_false
[09:35:05] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[09:35:14] <Aleric> true_likely
[09:35:34] <s_frit> i always put modifiers first in names
[09:35:56] <nblade42> Aleric: definitely, probably, maybe, hardly
[09:36:11] <s_frit> trueish, falseish
[09:36:16] <Aleric> Me normally too - but in this case my problem with the short 'recently_true' is that reads like it was true recently but NOW it is false :/
[09:36:39] <Aleric> lol @ trueish ... pretty neat
[09:36:40] <s_frit> Aleric: no, it doesn't read like that
[09:36:44] *** mujjingun <mujjingun!~park@c-73-15-97-144.hsd1.ca.comcast.net> has joined ##C++-general
[09:37:20] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has joined ##C++-general
[09:37:33] <s_frit> i think was_true is good
[09:37:57] <ville> the good news is that no matter what you name it, no one will be able to make out of it afterwards anyway. that's just how lock-free works out in practice.
[09:38:12] *** janco <janco!~janco@spf.debosschen.fiberwifihw.nl> has quit IRC (Quit: janco)
[09:38:25] <ville> make sense
[09:38:26] <s_frit> ville: and it will probably have bugs that you are completely blind to until 3 years later
[09:38:34] *** janco <janco!~janco@spf.debosschen.fiberwifihw.nl> has joined ##C++-general
[09:38:36] <Aleric> ville: I have the feeling this buffer is the hardest thing I tried to code EVER :(.
[09:38:54] <immibis> that's because you don't know what it's supposed to do
[09:39:07] <Aleric> And normally I kinda always write code that nobody understands :p
[09:39:12] <immibis> well maybe not. but the thing you're saying it should do doesn't seem very useful to me
[09:39:16] <s_frit> concurrency is hard
[09:39:45] <immibis> it can either say "yes the buffer is empty" or "I don't know if the buffer is empty" (which is a lie, of course, because the function knows perfectly well that the buffer is not empty)
[09:40:05] <ville> Aleric: just out of curiousity why are you looking to make a lock-free spsc queue? on the surface of it this sounds like a low-yeld performance improvement situation. mpmc queue where you would imagine high contention likely sounds more like a good candidate
[09:40:13] <Aleric> Ok.. I'll go for was_true and was_false, cause s_frit says it reads the way I intended it to be.
[09:40:16] <nblade42> If you're not sure what to name something, just use numbers, letters, etc. to distinguish them: foo_alpha foo_beta foo_gamma foo_delta, etc. Later if those concepts have some better labels, you can use them. Or the letters become distinguishing enough already. Alpha and Beta software are examples. They are just letters, but their meaning has stuck.
[09:40:40] <s_frit> ^^ +1
[09:41:16] <immibis> call them "Aleric", "s_frit", "nblade42" and "ville"
[09:41:53] <Aleric> I think the right naming of your classes functions and variables makes all the difference. It is very important.
[09:42:13] <s_frit> I agree. but it's not always the right time to try to solve that problem
[09:42:43] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has joined ##C++-general
[09:42:53] *** kadoban <kadoban!~mud@unaffiliated/kadoban> has quit IRC (Quit: bye)
[09:42:57] <Aleric> I've had code that I just couldn't get right - until I changed the names of a few functions and classes and then everything became clear - half of it collapsed into something simple (often a sign you got it right)
[09:43:01] <s_frit> for what it's worth, i think you are misguided trying to design this in a vacum without considering how clients will use the interface
[09:43:33] <Aleric> That cause I don't have an overview now, it's too complex.
[09:43:49] <Aleric> I'm trying to separate the problem further and further into sub problems.
[09:44:10] <s_frit> yeah, well desiging abstractions without an overview is dangerous and potentially a huge waste of energy (in my experience)
[09:44:24] <Aleric> Once it compiles again ;) .... and well, works - then maybe I can remove stuff like this again to make it read even better.
[09:44:38] <Aleric> but right now it's just one big broken thing that I have no clue about
[09:45:49] <nblade42> Or read more about your domain problem (lock free programming, etc.) and see if the authors have talked about the same concepts and have come up with some good names for them.
[09:46:01] <Aleric> With a lot of #if 0 .. #endif's and FIXME's I now got my test project to compile again except for the main .cxx file of the buffer :/
[09:48:07] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has joined ##C++-general
[09:50:41] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has quit IRC (Ping timeout: 250 seconds)
[09:52:33] *** philipp_ <philipp_!~phil@p549EE6A2.dip0.t-ipconnect.de> has joined ##C++-general
[09:56:30] *** xeno <xeno!~xeno@unaffiliated/xeno> has joined ##C++-general
[10:00:05] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has quit IRC (Quit: Leaving)
[10:01:25] *** jan64 <jan64!~jan64@79.191.143.165.ipv4.supernova.orange.pl> has quit IRC (Ping timeout: 246 seconds)
[10:04:45] *** jan64 <jan64!~jan64@79.191.205.155.ipv4.supernova.orange.pl> has joined ##C++-general
[10:05:30] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[10:07:58] *** Albori <Albori!~Albori@216-229-75-72.fidnet.com> has quit IRC (Ping timeout: 268 seconds)
[10:08:20] <Ameisen> my understanding is that only like one build tool actually understands modules, and thus knows how to order them
[10:08:23] <Ameisen> and it's not msbuild
[10:10:20] *** nucleargrave <nucleargrave!~nucleargr@c-73-150-253-137.hsd1.nj.comcast.net> has quit IRC (Quit: WeeChat 2.3)
[10:11:34] *** irrenhaus3 <irrenhaus3!~xenon@ip-37-201-6-163.hsi13.unitymediagroup.de> has joined ##C++-general
[10:11:39] *** rokups <rokups!uid197268@gateway/web/irccloud.com/x-vlsjxvrvkvytscop> has joined ##C++-general
[10:13:51] *** ravi__ <ravi__!~ravi@2a02:908:698:68a0:fd66:75f8:3696:4763> has joined ##C++-general
[10:15:57] *** Starhowl <Starhowl!~Starhowl@p57876F59.dip0.t-ipconnect.de> has joined ##C++-general
[10:18:11] *** LunarJetman <LunarJetman!LunarJetma@94.196.247.102.threembb.co.uk> has joined ##C++-general
[10:20:17] <batman_nair> Aleric, by reading your concept of 4 states(yes, probably_yes, probably_no, no), my idea of implementation is having a boolean which will be locked if someone is changing the value. When another person B is trying to access he gets the value of the boolean if not locked, and if locked he gets a probably_yes/no depending on the previous value of the boolean before lock.
[10:21:22] <batman_nair> maybe my understanding of what you said is wrong but this thing sounded cool in my head :D
[10:21:27] *** tz <tz!~tz@orange.tzarc.io> has quit IRC (Ping timeout: 268 seconds)
[10:22:51] <Aleric> That won't work...
[10:23:08] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC (Ping timeout: 250 seconds)
[10:24:03] *** quarterback <quarterback!~quarterba@160.238.72.235> has joined ##C++-general
[10:24:03] *** quarterback <quarterback!~quarterba@160.238.72.235> has quit IRC (Changing host)
[10:24:03] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has joined ##C++-general
[10:26:26] *** goiko <goiko!~goiko@unaffiliated/goiko> has quit IRC (Quit: ﴾͡๏̯͡๏﴿ O'RLY? Bye!)
[10:26:46] *** batman_nair <batman_nair!~batman_na@111.92.74.136> has quit IRC (Remote host closed the connection)
[10:27:19] *** batman_nair <batman_nair!~batman_na@111.92.74.136> has joined ##C++-general
[10:27:49] *** Human_G33k <Human_G33k!~HumanG33k@62.147.242.8> has joined ##C++-general
[10:28:57] *** dadabidet <dadabidet!~dadabidet@choupi.libriciel.fr> has joined ##C++-general
[10:29:13] *** velco <velco!chill@nat/arm/x-xkydouzeacjerkuu> has joined ##C++-general
[10:30:49] *** rizzo <rizzo!~RizzoTheR@dyndsl-037-138-168-245.ewe-ip-backbone.de> has quit IRC (Ping timeout: 246 seconds)
[10:31:14] *** HumanG33k <HumanG33k!~HumanG33k@62.147.242.8> has quit IRC (Ping timeout: 244 seconds)
[10:31:45] *** immibis <immibis!~immibis@125-238-72-168-fibre.sparkbb.co.nz> has quit IRC (Ping timeout: 244 seconds)
[10:32:14] *** nshire <nshire!~nealshire@unaffiliated/nealshire> has quit IRC (Ping timeout: 250 seconds)
[10:32:28] *** Albori <Albori!~Albori@216-229-75-72.fidnet.com> has joined ##C++-general
[10:33:01] *** luke_penn <luke_penn!~luke_penn@147.162.229.146> has joined ##C++-general
[10:34:24] *** philipp_ <philipp_!~phil@p549EE6A2.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)
[10:34:36] *** abraxxas <abraxxas!~phil@p549EE6A2.dip0.t-ipconnect.de> has joined ##C++-general
[10:37:00] *** mujjingun <mujjingun!~park@c-73-15-97-144.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 250 seconds)
[10:37:03] *** zv <zv!~zv@unaffiliated/zv> has quit IRC (Ping timeout: 250 seconds)
[10:43:12] *** luke_penn <luke_penn!~luke_penn@147.162.229.146> has quit IRC (Remote host closed the connection)
[10:49:00] *** zv <zv!~zv@unaffiliated/zv> has joined ##C++-general
[10:50:36] <Aleric> Hmm - probably not useful, but if I wanted to add an && operator... True && X == X, False && X == False, X && Y == Y && X, X && X == X, and then the only case I don't have yet is, wasTrue && wasFalse
[10:50:50] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has joined ##C++-general
[10:51:45] <Aleric> I guess that is wasFalse?
[11:01:42] *** SirFancyPantsOfP <SirFancyPantsOfP!~SirFancyP@37.186.119.154> has quit IRC (Read error: Connection reset by peer)
[11:05:33] *** goiko <goiko!~goiko@pD95834FE.dip0.t-ipconnect.de> has joined ##C++-general
[11:05:33] *** goiko <goiko!~goiko@pD95834FE.dip0.t-ipconnect.de> has quit IRC (Changing host)
[11:05:33] *** goiko <goiko!~goiko@unaffiliated/goiko> has joined ##C++-general
[11:06:22] *** Codyer <Codyer!~user@x5f74bfc8.dyn.telefonica.de> has quit IRC (Ping timeout: 244 seconds)
[11:06:33] *** vdamewood <vdamewood!~vdamewood@unaffiliated/vdamewood> has joined ##C++-general
[11:12:53] *** manuelschneid3r <manuelschneid3r!~manuelsch@p200300E2472CC5005F20BF21368481E4.dip0.t-ipconnect.de> has joined ##C++-general
[11:14:53] *** JohnMS_WORK <JohnMS_WORK!~JohnMS_WO@host-193-59-178-3.gog.com> has joined ##C++-general
[11:17:06] *** metaman <metaman!~metaman@108.166.152.162> has quit IRC (Quit: Leaving)
[11:17:40] *** escanor <escanor!67157d4e@gateway/web/freenode/ip.103.21.125.78> has joined ##C++-general
[11:18:04] <escanor> Hello every one i am running tensorflow example using cpp api
[11:18:20] <escanor> I am getting different results for python and cpp
[11:18:22] *** Starhowl <Starhowl!~Starhowl@p57876F59.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
[11:18:37] <escanor> In both places i am using the same .pb file
[11:19:34] *** mitch0 <mitch0!~mitch@188-143-22-175.pool.digikabel.hu> has quit IRC (Remote host closed the connection)
[11:21:07] *** mitch0 <mitch0!~mitch@84-236-16-52.pool.digikabel.hu> has joined ##C++-general
[11:22:26] <ville> doesn't sound too surprising. presumably this involves some floating point operations?
[11:22:27] <escanor> hi running tensorflow using cpp
[11:22:46] <ville> also there's no need to repeat things after 5 minutes
[11:22:54] <escanor> I am getting different result for cpp and python eventhough using same .pb file
[11:23:06] <nblade42> escanor: Show a simple example that someone can reproduce here
[11:24:05] <escanor> BC
[11:24:35] <escanor> nblade42: Sure will be back
[11:24:45] <escanor> thanks for the response
[11:25:33] <quarterback> Are there any good source code formatting tools?
[11:26:30] <nblade42> quarterback: Clang format
[11:26:36] <ville> all depends on your requirements. good is not a universal definition.
[11:26:41] <quarterback> nblade42, Anything other than clang?
[11:26:52] <nblade42> indent, astyle
[11:27:08] <cbreak> I like clang format
[11:27:29] <nblade42> indent is the simplest, astyle is pretty good, and clang-format seems the most customizable.
[11:27:38] <TinoDidriksen> clang-format does everything you want. You can customize it to very high degree.
[11:28:11] <ville> most customizable probably goes to uncrustify. last i counted it had ~500 different options
[11:28:23] <Aleric> indent is broken - only works for C
[11:28:38] <nblade42> Why would you use anything other than C?
[11:28:45] *** janco_ <janco_!~janco@spf.debosschen.fiberwifihw.nl> has joined ##C++-general
[11:28:53] <nblade42> Or C++? Same thing as far indent is concerned.
[11:28:58] <ville> nblade42: there's a high likelyhood of that given the channel..
[11:29:04] <Aleric> THIS IS SPARTA... err, ##C++
[11:29:25] <ville> nblade42: not at all. both indent and astyle broke with c++ the last time i checked. albetit this was years ago
[11:30:10] <quarterback> I have some C++ files which are big, somehow their formatting all screwed up with tabs introduced at random places. I Know netbeans can correct this.
[11:30:45] <nblade42> indent was last updated in 2008 apparently. The manual says "While an attempt was made to get indent working for C++, it will not do a good job on any C++ source except the very simplest. "
[11:30:48] *** janco_ <janco_!~janco@spf.debosschen.fiberwifihw.nl> has quit IRC (Client Quit)
[11:31:13] *** janco <janco!~janco@spf.debosschen.fiberwifihw.nl> has quit IRC (Ping timeout: 250 seconds)
[11:31:20] *** josef__k <josef__k!~jeremy@1.136.106.165> has joined ##C++-general
[11:32:21] <ville> a simple example could be that you want the operator >> to have space around its usage, but you want it to be written as "operator>>" in declaration and keep std::vector<std::vector>> together as well
[11:32:23] <velco> given clang-format exists, it's just not worth talking about any other C or C++ formatter
[11:33:08] <ville> uncrustify certainly beats clang-format in options
[11:33:57] <nblade42> On the other hand many people still write >> as > > because they are afraid of getting it mixed up with operator>>. vector<vector> >. I don't think this is ever needed anymore since C++11, but old habits die hard.
[11:34:08] <Aleric> (man that movie 300 was good... in case someone didn't get the "this is sparta" remark: https://www.youtube.com/watch?v=4Prc1UfuokY)
[11:34:17] <ville> to a point where it can be difficult or at least time intensive to configure because there are so many buttons and knobs
[11:35:21] *** zv <zv!~zv@unaffiliated/zv> has quit IRC (Ping timeout: 252 seconds)
[11:36:31] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[11:37:08] *** Appleman1234_ <Appleman1234_!~quassel@58.165.125.172> has joined ##C++-general
[11:37:11] *** jthomas3 <jthomas3!~jthomas@c-98-202-237-95.hsd1.ut.comcast.net> has joined ##C++-general
[11:38:40] *** Appleman1234 <Appleman1234!~quassel@101.163.11.62> has quit IRC (Ping timeout: 272 seconds)
[11:39:07] *** Ingersol <Ingersol!~Ingersol@host-static-93-116-234-146.moldtelecom.md> has joined ##C++-general
[11:39:38] *** libertyprime <libertyprime!~libertypr@101.98.42.91> has joined ##C++-general
[11:39:50] *** libertyp1ime <libertyp1ime!~libertypr@101.98.42.91> has joined ##C++-general
[11:39:55] *** boot <boot!~news@unaffiliated/lisper> has joined ##C++-general
[11:40:04] <boot> hey, any boost experts around? :D
[11:41:23] *** jthomas3 <jthomas3!~jthomas@c-98-202-237-95.hsd1.ut.comcast.net> has quit IRC (Ping timeout: 246 seconds)
[11:42:03] *** Appleman1234_ <Appleman1234_!~quassel@58.165.125.172> has quit IRC (Ping timeout: 250 seconds)
[11:42:13] *** Appleman1234 <Appleman1234!~quassel@124.186.203.31> has joined ##C++-general
[11:42:56] *** esrse <esrse!~nil@175.126.171.165> has quit IRC (Ping timeout: 268 seconds)
[11:46:16] <boot> i currently have async ASIO operations using a lambda, and the lifetime of the object is extended via shared_from_this
[11:46:43] <boot> however, the lambda passed to async_write, etc causes an allocation i want to get rid of
[11:47:01] <boot> one possibility is putting the lambda as a member and contruct it once
[11:47:17] <boot> however, that approach doesn't seem to be compatible with shared_from_this?
[11:52:08] <ville> why would the lambda allocate anything directly? that sounds surprising.
[11:53:14] *** zv <zv!~zv@unaffiliated/zv> has joined ##C++-general
[11:53:15] <boot> ville: there's a wrapper that takes a std::function
[11:53:27] <boot> and that apparently allocates if you capture
[11:53:33] <cbreak> that's normal
[11:53:35] <boot> (more than a reference)
[11:53:36] <ville> right, well, std::function is known to allocate
[11:53:42] <boot> yep
[11:53:44] <ville> don't use them
[11:53:53] <cbreak> std::function needs to allocate to be able to accomodate lambdas with arbitrary size
[11:54:41] <boot> also, the callback is executed in the context of a different thread so it'll always heap allocate for the capture?
[11:54:55] <cbreak> captures are not heap allocated
[11:55:11] <cbreak> they're part of the lambda, with unspecified location
[11:56:06] <ville> is this std::function something you chose to use, or something asio forces on you?
[11:56:38] <boot> you can use bind and a member function
[11:56:52] <boot> the std function is because of a wrapper thingie
[11:57:09] <boot> we can use a template instead
[11:57:33] <ville> that doesn't really answer my question. did you choose to write it so there is std::function used or is it use of std::function coming from somewher eelse?
[11:57:39] <boot> out of curiosity... is the shared_from_this the only sensible way to manage lifetime of async-style objects?
[11:57:51] <cbreak> no
[11:57:59] <boot> ville: i didn't write it, don't know the original motivation
[11:58:08] <boot> cbreak: elaborate? :D
[11:58:14] <cbreak> it is not
[11:58:23] <cbreak> you can manage lifetime how ever you want
[11:58:35] <ville> boot: ok let me rephrase, not you personally, you as in the whole organization. is it something you control
[11:58:37] <cbreak> I never give my async callbacks ownership
[11:58:43] <cbreak> so I don't need shared_from_this
[11:59:18] <ville> boot: who mandates the introduction of std::function?
[11:59:42] <boot> yeah, we can do whatever we want, nothing mandates std::function
[12:00:08] <ville> ok, so write an std::function-like that uses a fixed buffer to do its type erasure with.
[12:00:22] <boot> cbreak: so the typical approach is, say, a Session object that manages its own lifetime by using shared_from_this for every async operation in flight
[12:00:23] <cbreak> or don't type erase :)
[12:00:33] <boot> cbreak: so your idea is to not let objects manage their own lifetimes?
[12:00:38] <cbreak> boot: doesn't sound typical at all
[12:00:45] <cbreak> objects should not manage their own lifetime
[12:00:46] <boot> cbreak: all the examples does it
[12:00:50] <boot> haha :)
[12:04:56] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[12:05:31] *** Starhowl <Starhowl!~Starhowl@p57876F59.dip0.t-ipconnect.de> has joined ##C++-general
[12:05:31] <dadabidet> I sense high frequency trading developers
[12:06:22] <cbreak> while (true) sell(Mood::panicking);
[12:07:53] <boot> I drop by every few years and cbreak is always around :D
[12:08:10] <boot> Good to have some stability
[12:08:20] *** proteusguy <proteusguy!~proteus-g@mx-ll-183.89.213-60.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[12:10:10] <quarterback> I sense a disturbance in their stock exchanges
[12:10:58] *** Zunino <Zunino!~zunino@187.94.103.249> has joined ##C++-general
[12:11:11] <cbreak> ... :(
[12:11:19] <cbreak> I tried stock gambling... it's painful :P
[12:12:57] <boot> even the ASIO designer recommends shared_from_this approach for keeping objects alive while there is work to do. doesn't necessarily mean it's a good idea, but he seems to know his shit
[12:13:08] *** multifractal <multifractal!~multifrac@194.73.87.179> has joined ##C++-general
[12:13:25] <cbreak> boot: for me it usually ended up in pain
[12:13:38] <cbreak> controling lifetime hierarchically gave better results
[12:14:44] <boot> cbreak: and you did that with asio?
[12:15:04] <cbreak> the lifetime thing? no
[12:15:12] <boot> would be nice to see some sort of example, I can't find *any* async asio code not using shared_from_this ;(
[12:15:17] <cbreak> I used ASIO for thread / callback management
[12:15:45] <cbreak> I'm not entirely happy with my code (and it's closed source so I can't show you :P)
[12:15:48] <cbreak> but it worked
[12:15:57] <boot> you tease
[12:16:15] <cbreak> but it's as you probably imagine
[12:16:17] *** batman_nair <batman_nair!~batman_na@111.92.74.136> has quit IRC (Read error: Connection reset by peer)
[12:16:26] <cbreak> objects are owned by parent objects as usual
[12:16:35] <cbreak> some object owns an io service
[12:16:40] <cbreak> and so on
[12:18:26] <boot> a simple example is reading a stream of chunked data with async_read. You start off by reading a header, you callback gets called. Then you read the chunk which may indicate more data is available, so you read that with async_read, etc, etc, etc, all the time extending lifetime with shared_from_this
[12:18:33] <boot> I *do* want the chunk_reader to die when done
[12:18:46] *** batman_nair <batman_nair!~batman_na@111.92.74.136> has joined ##C++-general
[12:18:46] <boot> trying to imagine how this simple example works without shared_from_this
[12:19:07] <boot> at some point you reach an end sentinel or something, and you're done
[12:20:07] *** batman_nair <batman_nair!~batman_na@111.92.74.136> has quit IRC (Read error: Connection reset by peer)
[12:23:59] <cbreak> boot: the data I read are members of an object
[12:24:06] *** borkr <borkr!~borkr@129-241-229-22-gw.cgn.ntnu.no> has joined ##C++-general
[12:28:12] *** Serpent7776 <Serpent7776!~Serpent77@90-156-31-193.internetia.net.pl> has joined ##C++-general
[12:31:59] *** dx_ob <dx_ob!~OtakuSenp@unaffiliated/neel> has joined ##C++-general
[12:32:09] *** libertyp1ime <libertyp1ime!~libertypr@101.98.42.91> has quit IRC (Quit: leaving)
[12:33:11] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has quit IRC (Ping timeout: 250 seconds)
[12:36:36] *** josef__k <josef__k!~jeremy@1.136.106.165> has quit IRC (Ping timeout: 250 seconds)
[12:36:54] *** gulzar <gulzar!~gulzar@14.139.123.36> has quit IRC (Quit: Konversation terminated!)
[12:48:56] <Aleric> I need a formula for something f(x,y) where f(1.5, 1.5) == 1.5, f(0, 0) == f(3, 3) == 0, f(0, 3) == f(3, 0) == 3
[12:49:37] <Aleric> So probably a symmetric function... What else is symmetric besides x+y ... :/
[12:49:53] <Aleric> x*y I guess?
[12:50:18] <cbreak> |, ||, &&, &, ^
[12:50:24] <Aleric> or maybe |x-y|
[12:50:48] <s_frit> that doesn't work with your first example
[12:50:57] <cbreak> sin, cos, pow
[12:51:26] <s_frit> i think you mean commutative not symmetric
[12:51:45] *** Codyer <Codyer!~user@x5f74bfc8.dyn.telefonica.de> has joined ##C++-general
[12:52:38] <Aleric> Too much math.. sorry. I am refering to symmetric as in invariant under permutation of x and y.
[12:53:10] <Aleric> So f(x,y) = g(x+y, abs(x-y)) something like that - should be easier to find g.
[12:56:02] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has joined ##C++-general
[12:56:04] <Aleric> Yeah, usually they use x+y and x*y (https://en.wikipedia.org/wiki/Elementary_symmetric_polynomial for n = 2)
[12:56:31] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[12:57:12] *** T`aZ_ <T`aZ_!~TaZ@83-101-52-56.access.a11.eu> has quit IRC (Ping timeout: 272 seconds)
[12:57:39] <Ingersol> Aleric, max(arg1,arg2) - as base return for func, then you can wrap it with module arithmetic with module you want?
[12:58:07] <Aleric> Good point, I was just looking at that..
[12:58:16] <Aleric> That would be...
[12:58:54] *** T`aZ <T`aZ!~TaZ@unaffiliated/taz/x-9554575> has joined ##C++-general
[13:00:34] <Aleric> std::max(std::min(3 - x, y), std::min(x, 3 - y))
[13:00:35] <Aleric> ?
[13:00:47] *** Appleman1234 <Appleman1234!~quassel@124.186.203.31> has quit IRC (Ping timeout: 240 seconds)
[13:01:57] <Aleric> At least this is symmetric in x and y :p ... hmm, and f(0,0) = max(min(3,0),min(0,3)) = max(0,0) = 0. Same for f(3,3)
[13:02:00] *** fogbank <fogbank!~fogbank@net-188-153-77-173.cust.vodafonedsl.it> has joined ##C++-general
[13:02:14] <Aleric> yup - this works
[13:04:34] *** tz <tz!~tz@orange.tzarc.io> has joined ##C++-general
[13:04:51] *** cbreak <cbreak!~cbreak@77-56-224-14.dclient.hispeed.ch> has quit IRC (Ping timeout: 264 seconds)
[13:06:45] *** syamaoka <syamaoka!~syamaoka@151.127.198.104.bc.googleusercontent.com> has quit IRC (Quit: ZNC 1.6.5 - http://znc.in)
[13:06:54] *** rajrajraj <rajrajraj!uid72176@gateway/web/irccloud.com/x-xhlbjglzlswbhmtt> has joined ##C++-general
[13:09:14] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.199.80.12> has joined ##C++-general
[13:13:51] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has quit IRC (Quit: Leaving)
[13:16:57] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined ##C++-general
[13:19:39] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has joined ##C++-general
[13:20:24] <Aleric> friend FuzzyBool operator==(FuzzyBool fb1, FuzzyBool fb2) { return static_cast<FuzzyBoolEnum>(std::max(std::min(3 - fb1.m_val, 0 + fb2.m_val), std::min(0 + fb1.m_val, 3 - fb2.m_val))); }
[13:20:25] <Aleric> lol
[13:20:37] *** Starhowl <Starhowl!~Starhowl@p57876F59.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
[13:20:48] <Aleric> Weird operator==
[13:23:21] *** jan64 <jan64!~jan64@79.191.205.155.ipv4.supernova.orange.pl> has quit IRC (Read error: Connection reset by peer)
[13:24:04] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[13:24:12] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[13:25:03] *** multifractal <multifractal!~multifrac@194.73.87.179> has quit IRC (Ping timeout: 245 seconds)
[13:26:51] *** jan64 <jan64!~jan64@79.191.205.155.ipv4.supernova.orange.pl> has joined ##C++-general
[13:28:27] *** gulzar <gulzar!~gulzar@14.139.123.36> has joined ##C++-general
[13:29:40] *** quarterback <quarterback!~quarterba@160.238.72.235> has joined ##C++-general
[13:29:40] *** quarterback <quarterback!~quarterba@160.238.72.235> has quit IRC (Changing host)
[13:29:40] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has joined ##C++-general
[13:29:48] *** tachoknight <tachoknight!~tachoknig@205.178.20.7> has quit IRC (Remote host closed the connection)
[13:30:20] *** tachoknight <tachoknight!~tachoknig@205.178.20.7> has joined ##C++-general
[13:36:01] *** tachoknight <tachoknight!~tachoknig@205.178.20.7> has quit IRC (Remote host closed the connection)
[13:36:26] *** tachoknight <tachoknight!~tachoknig@205.178.20.7> has joined ##C++-general
[13:36:58] *** merethan_w <merethan_w!~merethan_@546A62C5.cm-12-3b.dynamic.ziggo.nl> has joined ##C++-general
[13:43:46] *** Zunino <Zunino!~zunino@187.94.103.249> has quit IRC (Quit: WeeChat 1.9.1)
[13:45:44] *** jstein_ <jstein_!~jstein@gentoo/developer/jstein> has joined ##C++-general
[13:45:47] *** jstein_ is now known as jstein
[13:50:20] <Aleric> Ok, I implemented something that should work... https://github.com/CarloWood/ai-utils/blob/master/FuzzyBool.h
[13:50:21] *** gulzar <gulzar!~gulzar@14.139.123.36> has quit IRC (Quit: Konversation terminated!)
[13:51:25] *** fattest <fattest!b4966b4b@gateway/web/freenode/ip.180.150.107.75> has joined ##C++-general
[13:51:41] <Aleric> s_frit: ^^ any thoughts? :)
[13:53:33] *** tachoknight <tachoknight!~tachoknig@205.178.20.7> has quit IRC (Remote host closed the connection)
[13:54:00] *** tachoknight <tachoknight!~tachoknig@205.178.20.7> has joined ##C++-general
[13:55:03] <fattest> Does anyone know how I can print my Boost graph? https://wandbox.org/permlink/NDeY08JMsRFyBq5e I'm not sure what arguments I to provide the boost::print_graph function. Any help would be appreciated.
[13:59:04] *** karalaine <karalaine!karalaine@unaffiliated/karalaine> has joined ##C++-general
[13:59:47] *** libertyprime <libertyprime!~libertypr@101.98.42.91> has quit IRC (Ping timeout: 240 seconds)
[14:04:40] *** Praise <Praise!~Fat@unaffiliated/praise> has quit IRC (Ping timeout: 246 seconds)
[14:05:02] *** lh_ideapad <lh_ideapad!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has quit IRC (Remote host closed the connection)
[14:08:18] *** jinak_ <jinak_!~jinak@190.176.134.130> has joined ##C++-general
[14:08:45] *** jinak <jinak!~jinak@190.176.240.225> has quit IRC (Ping timeout: 244 seconds)
[14:10:23] <Aleric> It works if you use vecS
[14:11:18] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.199.80.12> has quit IRC (Remote host closed the connection)
[14:12:25] *** dx_ob <dx_ob!~OtakuSenp@unaffiliated/neel> has quit IRC (Read error: Connection reset by peer)
[14:13:01] <Aleric> ^^ fattest
[14:13:13] *** tachoknight <tachoknight!~tachoknig@205.178.20.7> has quit IRC (Remote host closed the connection)
[14:13:30] <fattest> Aleric: yes, but I want to use setS or hash_setS
[14:13:37] *** tachoknight <tachoknight!~tachoknig@205.178.20.7> has joined ##C++-general
[14:13:56] *** Forsaken87 <Forsaken87!~quassel@2a02:908:1869:4b20:f4b0:188b:cefd:b063> has joined ##C++-general
[14:13:59] <Aleric> I suppose you can't as second parameter of adjacency_list
[14:14:47] <Aleric> I have no idea what that parameter does, I never used this lib.
[14:14:49] *** ravi__ <ravi__!~ravi@2a02:908:698:68a0:fd66:75f8:3696:4763> has quit IRC (Remote host closed the connection)
[14:16:03] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.199.80.12> has joined ##C++-general
[14:18:14] *** JPulowski <JPulowski!~JPulowski@95.70.222.200> has joined ##C++-general
[14:19:33] *** Tachyon_ <Tachyon_!~andrei@84.117.209.5> has joined ##C++-general
[14:20:40] *** rafalcpp <rafalcpp!~racalcppp@84-10-11-234.static.chello.pl> has quit IRC (Read error: Connection reset by peer)
[14:20:57] *** rafalcpp <rafalcpp!~racalcppp@84-10-11-234.static.chello.pl> has joined ##C++-general
[14:22:51] *** Tachyon_ <Tachyon_!~andrei@84.117.209.5> has quit IRC (Client Quit)
[14:25:47] *** pulse <pulse!~pulse@unaffiliated/pulse> has joined ##C++-general
[14:28:38] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC (Remote host closed the connection)
[14:29:03] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined ##C++-general
[14:29:43] *** cbreak <cbreak!~cbreak@77-56-224-14.dclient.hispeed.ch> has joined ##C++-general
[14:29:56] *** ogres <ogres!uid159312@gateway/web/irccloud.com/x-nnfgqkuruhdqlugn> has quit IRC (Quit: Connection closed for inactivity)
[14:33:24] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[14:35:37] *** OtakuSen1ai <OtakuSen1ai!~OtakuSenp@unaffiliated/neel> has joined ##C++-general
[14:36:37] *** OtakuSen1ai is now known as Nawab
[14:39:15] <s_frit> Aleric: firstly, i would make fuzzy_false = 0, for obvious reasons
[14:39:25] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has joined ##C++-general
[14:39:43] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.199.80.12> has quit IRC (Remote host closed the connection)
[14:42:19] <s_frit> Aleric, secondly, you can encode your truth tables with 16 bits, so I would do something like { return eq_lookup_ & (1 << (fb1.m_val + fb2.m_val << 2)); } where eq_lookup_ is a constant representing the truth table for the operator (separate lookup tables for each operator)
[14:43:36] <s_frit> Aleric, ah, no, 32 bits... so a little more work, but the same idea applies
[14:47:01] *** fattest <fattest!b4966b4b@gateway/web/freenode/ip.180.150.107.75> has quit IRC (Quit: Page closed)
[14:52:40] *** Nawab <Nawab!~OtakuSenp@unaffiliated/neel> has quit IRC (Quit: Lost terminal)
[14:53:50] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has quit IRC (Quit: Konversation terminated!)
[15:01:18] *** rokups <rokups!uid197268@gateway/web/irccloud.com/x-vlsjxvrvkvytscop> has quit IRC (Quit: Connection closed for inactivity)
[15:01:47] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has quit IRC (Quit: Leaving)
[15:02:50] *** escanor <escanor!67157d4e@gateway/web/freenode/ip.103.21.125.78> has quit IRC (Quit: Page closed)
[15:05:57] *** Ralsei <Ralsei!~AllegroVi@aefn198.neoplus.adsl.tpnet.pl> has joined ##C++-general
[15:11:15] *** Nawab <Nawab!~Neel@unaffiliated/neel> has joined ##C++-general
[15:16:34] *** Starhowl <Starhowl!~Starhowl@p57876F59.dip0.t-ipconnect.de> has joined ##C++-general
[15:17:58] *** quarterback <quarterback!~quarterba@160.238.72.20> has joined ##C++-general
[15:17:58] *** quarterback <quarterback!~quarterba@160.238.72.20> has quit IRC (Changing host)
[15:17:58] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has joined ##C++-general
[15:23:15] *** Nawab <Nawab!~Neel@unaffiliated/neel> has quit IRC (Remote host closed the connection)
[15:31:12] *** Nawab <Nawab!~Neel@unaffiliated/neel> has joined ##C++-general
[15:33:44] *** janco <janco!~janco@ip54570871.direct-adsl.nl> has joined ##C++-general
[15:34:20] <Forsaken87> Hi there. Can someone help me getting started with my gtk3 application? I've followed the way a few tutorials I found so far handled creating a window and get a segmentation fault when calling "g_signal_connect" (Line 49 in the paste) https://ideone.com/FoDVXl
[15:35:07] <Forsaken87> The exact message is "0x00007ffff7ed0d39 in g_type_check_instance () from /usr/lib/libgobject-2.0.so.0"
[15:35:17] *** BOKALDO <BOKALDO!~BOKALDO@46.109.206.127> has quit IRC (Quit: Leaving)
[15:37:43] <vdamewood> Forsaken87: Is there a reason you're not using GTKmm?
[15:38:10] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC (Ping timeout: 250 seconds)
[15:38:46] *** multifractal <multifractal!~multifrac@194.73.87.179> has joined ##C++-general
[15:38:58] <Forsaken87> No I guess ;-) I just searched for gtk3 tutorials and everyone I came up with so far went the way I implemented it in my current code
[15:39:58] <Forsaken87> Thanks for the hint, I'll give it a shot
[15:43:26] <vdamewood> GTK+ is made for C, so it's not aware of C++ concepts like classes and overloaded (or mangled) functions. It also does things the C way which are unsafe and downright a pain in the ass with C++. If you're not very familiar with what's involved in using a C API from C++, you should stick to using GTK+ with C code, and GTKmm with C++ code.
[15:43:35] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.199.80.12> has joined ##C++-general
[15:43:57] <vdamewood> Forsaken87: Also, this example looks like it's more complex than it needs to be. Let me see if I can find a better tutorial.
[15:44:47] <Forsaken87> The class structure is done by me, I just followed the gtk calls from the tutorial
[15:45:28] <Forsaken87> But I will change that now anyway with the gtkmm bindings
[15:45:50] <vdamewood> https://developer.gnome.org/gtkmm-tutorial/stable/sec-basics-simple-example.html.en
[15:46:27] <Forsaken87> yeah thats what I was just looking at ;-)
[15:46:33] <velco> is Glade still a thing for GTK+ development ?
[15:47:32] <vdamewood> velco: I think so. But I think support for layout files has been implemented in GTK+ proper now.
[15:47:33] <velco> looks like a sane approach
[15:47:47] <Forsaken87> is there a way I can derive my ConfigurationWindow class from the Gtk::Window class? (the example uses Gtk::Application::create instead of a regular constructor)
[15:48:29] <Forsaken87> velco: I want to dynamically create ui elements which makes it at least difficult for that approach
[15:48:41] <velco> fair enough
[15:48:41] <vdamewood> Forsaken87: Gtk::Application::create is unrelated to Windos.
[15:48:55] <vdamewood> err Windows
[15:49:02] <Forsaken87> vdamewood: oh my bad
[15:49:22] <velco> (not that it's a good idea, as it results in a unusable UI :P )
[15:49:30] <vdamewood> Forsaken87: But yes, you can derive from Gtk::Windows without a problem.
[15:49:42] <vdamewood> err Gtk::Window
[15:51:03] *** Human_G33k <Human_G33k!~HumanG33k@62.147.242.8> has quit IRC (Ping timeout: 244 seconds)
[15:52:47] *** dinfuehr <dinfuehr!~dinfuehr@91-114-131-44.adsl.highway.telekom.at> has quit IRC (Ping timeout: 240 seconds)
[15:53:54] *** dinfuehr <dinfuehr!~dinfuehr@194-166-79-182.adsl.highway.telekom.at> has joined ##C++-general
[15:55:11] *** Nawab <Nawab!~Neel@unaffiliated/neel> has quit IRC (Read error: Connection reset by peer)
[15:59:10] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[16:00:42] *** JohnMS_WORK <JohnMS_WORK!~JohnMS_WO@host-193-59-178-3.gog.com> has quit IRC (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
[16:02:32] *** Tazmain <Tazmain!~Tazmain@unaffiliated/tazmain> has quit IRC (Read error: Connection reset by peer)
[16:03:48] *** lh_mouse <lh_mouse!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has quit IRC (Read error: Connection reset by peer)
[16:12:29] *** enfire <enfire!5e70fbeb@gateway/web/freenode/ip.94.112.251.235> has quit IRC (Ping timeout: 256 seconds)
[16:13:23] *** biberu <biberu!~biberu@c83-251-152-254.bredband.comhem.se> has quit IRC ()
[16:15:00] *** janco <janco!~janco@ip54570871.direct-adsl.nl> has quit IRC (Ping timeout: 250 seconds)
[16:15:56] *** shfil <shfil!uid293885@gateway/web/irccloud.com/x-uncikimozuqjorhw> has quit IRC (Quit: Connection closed for inactivity)
[16:15:58] *** dinfuehr_ <dinfuehr_!~dinfuehr@91-114-130-155.adsl.highway.telekom.at> has joined ##C++-general
[16:16:07] *** dinfuehr <dinfuehr!~dinfuehr@194-166-79-182.adsl.highway.telekom.at> has quit IRC (Ping timeout: 268 seconds)
[16:23:05] *** Human_G33k <Human_G33k!~HumanG33k@62.147.242.8> has joined ##C++-general
[16:24:37] *** janco <janco!~janco@ip54570871.direct-adsl.nl> has joined ##C++-general
[16:25:08] *** janco <janco!~janco@ip54570871.direct-adsl.nl> has quit IRC (Remote host closed the connection)
[16:25:29] *** janco <janco!~janco@ip54570871.direct-adsl.nl> has joined ##C++-general
[16:26:09] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[16:30:16] *** borkr <borkr!~borkr@129-241-229-22-gw.cgn.ntnu.no> has quit IRC (Ping timeout: 246 seconds)
[16:32:41] *** jan64 <jan64!~jan64@79.191.205.155.ipv4.supernova.orange.pl> has quit IRC (Read error: Connection reset by peer)
[16:32:53] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[16:32:56] *** dinfuehr_ <dinfuehr_!~dinfuehr@91-114-130-155.adsl.highway.telekom.at> has quit IRC (Ping timeout: 246 seconds)
[16:35:02] *** dinfuehr <dinfuehr!~dinfuehr@91-114-133-23.adsl.highway.telekom.at> has joined ##C++-general
[16:36:03] <Forsaken87> vdamewood: I've got a window (after setting up pkg-config to properly solve all the includes/libs in eclipse) *cheers* thanks again for the help :)
[16:36:26] <vdamewood> Forsaken87: No problem.
[16:37:18] *** manimax3 <manimax3!~manimax3@2a02:810d:a80:2d74:5c8c:2838:21c5:5b96> has joined ##C++-general
[16:37:49] *** BOKALDO <BOKALDO!~BOKALDO@46.109.206.127> has joined ##C++-general
[16:42:00] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[16:42:36] *** Human_G33k <Human_G33k!~HumanG33k@62.147.242.8> has quit IRC (Remote host closed the connection)
[16:44:14] *** led_dark_1 <led_dark_1!~Thunderbi@hotspot10.rywasoft.net> has joined ##C++-general
[16:45:00] *** dinfuehr_ <dinfuehr_!~dinfuehr@194-166-73-68.adsl.highway.telekom.at> has joined ##C++-general
[16:45:06] *** dinfuehr <dinfuehr!~dinfuehr@91-114-133-23.adsl.highway.telekom.at> has quit IRC (Ping timeout: 268 seconds)
[16:45:10] *** Haohmaru <Haohmaru!~Haohmaru@195.24.53.110> has quit IRC ()
[16:45:18] *** Lord_of_Life_ <Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362> has joined ##C++-general
[16:45:43] *** LunarJetman <LunarJetman!LunarJetma@94.196.247.102.threembb.co.uk> has quit IRC (Ping timeout: 268 seconds)
[16:47:45] *** dadabidet <dadabidet!~dadabidet@choupi.libriciel.fr> has quit IRC (Quit: Leaving)
[16:49:00] *** Lord_of_Life <Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362> has quit IRC (Ping timeout: 272 seconds)
[16:49:01] *** Lord_of_Life_ is now known as Lord_of_Life
[16:52:39] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has quit IRC (Quit: Leaving)
[16:53:01] *** nblade42 <nblade42!~Miranda_4@ptr-91b6nnt8zwrtpt3vg7x.18120a2.ip6.access.telenet.be> has quit IRC (Quit: Goodbye.)
[16:53:59] *** rizzo <rizzo!~RizzoTheR@dyndsl-037-138-168-245.ewe-ip-backbone.de> has joined ##C++-general
[16:54:35] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[16:56:14] *** led_dark_1 <led_dark_1!~Thunderbi@hotspot10.rywasoft.net> has quit IRC (Quit: led_dark_1)
[16:56:18] *** orizzle <orizzle!~oriz@66.42.252.112> has joined ##C++-general
[16:56:35] *** led_dark_1 <led_dark_1!~Thunderbi@hotspot10.rywasoft.net> has joined ##C++-general
[16:57:04] *** orizzle <orizzle!~oriz@66.42.252.112> has quit IRC (Client Quit)
[16:58:53] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.199.80.12> has quit IRC (Remote host closed the connection)
[16:58:57] *** jthomas3 <jthomas3!~jthomas@66-219-246-238.dynamic.ip.veracitynetworks.com> has joined ##C++-general
[16:59:22] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.199.80.12> has joined ##C++-general
[17:00:20] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.199.80.12> has quit IRC (Max SendQ exceeded)
[17:01:04] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.199.80.12> has joined ##C++-general
[17:01:49] *** zaptcha <zaptcha!~silus@2001:41d0:203:1641::> has joined ##C++-general
[17:05:01] <s_frit> size_t a, b; if i know that a >= b, what is the best way to write (a - b) without getting: warning: implicit conversion changes signedness: 'long' to 'unsigned long' [-Wsign-conversion] ?
[17:05:21] *** Tazmain <Tazmain!~Tazmain@unaffiliated/tazmain> has joined ##C++-general
[17:05:27] <s_frit> what i'm doing now: assert(a >= b); ... static_cast<size_t>(a - b) ...
[17:07:44] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.199.80.12> has quit IRC (Read error: Connection reset by peer)
[17:09:44] *** Roughy <Roughy!~mdaw45ns@188.126.203.78> has joined ##C++-general
[17:10:30] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has quit IRC (Quit: Leaving)
[17:16:34] *** tane <tane!~tane@dslb-178-011-228-154.178.011.pools.vodafone-ip.de> has joined ##C++-general
[17:18:15] *** jthomas3 <jthomas3!~jthomas@66-219-246-238.dynamic.ip.veracitynetworks.com> has quit IRC (Quit: WeeChat 2.1)
[17:18:51] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has quit IRC (Ping timeout: 252 seconds)
[17:20:35] <ville> where's the implicit conversion in (a - b)? they're both the same type
[17:22:21] *** freakazoid0223 <freakazoid0223!~matt@pool-108-52-159-210.phlapa.fios.verizon.net> has joined ##C++-general
[17:22:52] *** LunarJetman <LunarJetman!LunarJetma@94.196.247.102.threembb.co.uk> has joined ##C++-general
[17:24:04] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[17:24:13] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[17:28:01] *** symm- <symm-!~symm-@95.65.81.202> has joined ##C++-general
[17:28:02] <ville> velco: yes glade still works, last used it 1-2 years ago
[17:33:27] *** janco <janco!~janco@ip54570871.direct-adsl.nl> has quit IRC (Quit: janco)
[17:37:46] <velco> aye, I saw it had a release in 2018 ...
[17:44:07] *** dinfuehr_ <dinfuehr_!~dinfuehr@194-166-73-68.adsl.highway.telekom.at> has quit IRC (Ping timeout: 246 seconds)
[17:46:33] *** dinfuehr <dinfuehr!~dinfuehr@91-113-47-14.adsl.highway.telekom.at> has joined ##C++-general
[17:56:32] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[17:57:39] *** rburkholder <rburkholder!~blurb@96.45.2.121> has quit IRC (Ping timeout: 246 seconds)
[17:58:00] <s_frit> ville: you tell me. clang is giving me that warning
[17:58:08] *** rburkholder <rburkholder!~blurb@96.45.2.121> has joined ##C++-general
[17:59:49] <ville> sounds fishy
[18:00:46] <velco> WorksForMe(tm) https://gcc.godbolt.org/z/FZ1I2j
[18:01:00] *** dzejrou <dzejrou!dzejrou@nat/suse/x-zpbibkobjntbznxa> has quit IRC (Quit: WeeChat 2.2)
[18:01:39] <velco> probably on of the variables int's actually a size_t
[18:01:43] <velco> one*
[18:02:09] <velco> ugh, where's orbitz to make my typing look good ...
[18:03:46] *** weyland|yutani_ is now known as weyland|yutani
[18:03:55] *** ravi__ <ravi__!~ravi@2a02:908:698:68a0:6d70:760d:4923:5063> has joined ##C++-general
[18:08:11] *** bONE87 <bONE87!~bONE87@cable-24-135-40-101.dynamic.sbb.rs> has quit IRC (Remote host closed the connection)
[18:09:02] <s_frit> looks like i imagined it. it's only happening now with a, b pointers: https://gcc.godbolt.org/z/aq1yia
[18:09:18] *** gabrielschulhof <gabrielschulhof!~nix@ip68-4-75-24.oc.oc.cox.net> has joined ##C++-general
[18:09:35] <s_frit> in this case is the assert and a static_cast the best option?
[18:11:44] *** OpenSorceress <OpenSorceress!~opensorce@216-82-197-9.static.grandenetworks.net> has joined ##C++-general
[18:11:44] *** OpenSorceress <OpenSorceress!~opensorce@216-82-197-9.static.grandenetworks.net> has quit IRC (Changing host)
[18:11:44] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined ##C++-general
[18:12:00] *** rajrajraj <rajrajraj!uid72176@gateway/web/irccloud.com/x-xhlbjglzlswbhmtt> has quit IRC (Quit: Connection closed for inactivity)
[18:13:03] *** tm <tm!~sinnlos@unaffiliated/tm> has quit IRC (Remote host closed the connection)
[18:15:55] <velco> static_cast sounds good
[18:16:47] <velco> and the conversion is legit, given the a and b point into the same object and size_t can represent every object's size
[18:19:19] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined ##C++-general
[18:19:36] *** thomasross_ <thomasross_!~thomasros@69.17.174.21> has joined ##C++-general
[18:19:36] *** thomasross <thomasross!~thomasros@69.17.174.21> has quit IRC (Killed (cherryh.freenode.net (Nickname regained by services)))
[18:19:36] *** thomasross_ is now known as thomasross
[18:19:52] *** ravi__ <ravi__!~ravi@2a02:908:698:68a0:6d70:760d:4923:5063> has quit IRC (Remote host closed the connection)
[18:20:27] *** thomasross <thomasross!~thomasros@69.17.174.21> has quit IRC (Max SendQ exceeded)
[18:20:55] *** thomasross_ <thomasross_!~thomasros@69.17.174.21> has joined ##C++-general
[18:20:55] *** thomasross_ is now known as thomasross
[18:21:33] <s_frit> yes. thanks.
[18:21:35] *** longxia <longxia!~irc@unaffiliated/longxia> has joined ##C++-general
[18:27:30] <ville> yeah, ptrdiff_t is signed
[18:37:56] *** Albori <Albori!~Albori@216-229-75-72.fidnet.com> has quit IRC (Ping timeout: 272 seconds)
[18:43:30] *** dinfuehr <dinfuehr!~dinfuehr@91-113-47-14.adsl.highway.telekom.at> has quit IRC (Ping timeout: 268 seconds)
[18:44:03] *** Wetmelon <Wetmelon!~wetmelon@2600:1700:2601:7c40:3dc8:a2a5:c41:46f> has joined ##C++-general
[18:44:07] *** dinfuehr <dinfuehr!~dinfuehr@91-114-129-132.adsl.highway.telekom.at> has joined ##C++-general
[18:44:35] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[18:44:57] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[18:45:22] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[18:45:43] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[18:46:10] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[18:46:30] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[18:46:57] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[18:47:17] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[18:47:45] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[18:48:03] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[18:48:32] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[18:48:34] *** ambro718 <ambro718!~ambro@unaffiliated/ambro718> has joined ##C++-general
[18:48:53] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[18:49:20] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[18:49:41] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[18:50:07] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[18:50:23] *** jinak_ <jinak_!~jinak@190.176.134.130> has quit IRC (Remote host closed the connection)
[18:50:28] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[18:50:50] *** jinak_ <jinak_!~jinak@190.176.134.130> has joined ##C++-general
[18:50:55] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[18:51:14] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[18:51:33] *** ZaraFrax <ZaraFrax!~ZaraFrax@p200300D73BCEA100E04515A237BA3C66.dip0.t-ipconnect.de> has joined ##C++-general
[18:51:42] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[18:53:35] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[18:58:48] *** multifractal <multifractal!~multifrac@194.73.87.179> has quit IRC (Ping timeout: 250 seconds)
[19:00:46] *** nblade42 <nblade42!~Miranda_4@ptr-91b6nnuewwpuclthy89.18120a2.ip6.access.telenet.be> has joined ##C++-general
[19:00:46] *** jstein <jstein!~jstein@gentoo/developer/jstein> has quit IRC (Ping timeout: 268 seconds)
[19:01:21] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC (Remote host closed the connection)
[19:02:22] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has joined ##C++-general
[19:03:36] <Aleric> To continue my design, now that I have my FuzzyBool... Consider this monotic variable, where thread A can only increase the value and thread B can only decrease it. The variable itself is atomic of course, but without any locking the read value has to be considered an upperbound when thread A reads it and a lowerbound when thread B reads it.
[19:04:56] *** Albori <Albori!~Albori@216-229-75-72.fidnet.com> has joined ##C++-general
[19:05:20] *** jinak_ is now known as jinak
[19:06:41] <Aleric> If I turn that into a FuzzyBool by comparing it with some threshold value; lets say the value read is `val` and the threshold `th`; as in `val < th` then, although initially { true, false } of course, for thread A the result is { was_true, false } and for thread B the result is { true, was_false }.
[19:08:00] <Aleric> hmm
[19:08:41] <Aleric> no no - val is a upperbound for A.. so it can be lower but not higher - so true is certain.
[19:09:08] *** tm <tm!~sinnlos@unaffiliated/tm> has joined ##C++-general
[19:09:12] <Aleric> for thread A the result is { true, was_false } and for thread B the result is { was_true, false }.
[19:09:36] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[19:09:39] <Aleric> Now I need the following:
[19:11:30] <Aleric> Thread A does something like: BEGIN; FuzzyBool result = test(); if (result.likely()) do_atomic_op_A(); END.
[19:11:34] *** velco <velco!chill@nat/arm/x-xkydouzeacjerkuu> has quit IRC (Quit: Leaving)
[19:12:19] <Aleric> And thread B does something like: BEGIN; FuzzyBool = test(); if (result.unlikely()) do_atomic_op_B(); END.
[19:12:49] *** Nawab <Nawab!~Neel@unaffiliated/neel> has joined ##C++-general
[19:13:29] <Aleric> No, the other way around :/ ... the results have to be fuzzy of course.
[19:13:52] *** Nawab <Nawab!~Neel@unaffiliated/neel> has quit IRC (Remote host closed the connection)
[19:14:03] <Aleric> So, thread A: BEGIN; FuzzyBool result = test(); if (result.unlikely()) do_atomic_op_A(); END.
[19:14:16] <Aleric> And thread B: BEGIN; FuzzyBool = test(); if (result.likely()) do_atomic_op_B(); END.
[19:14:33] <Aleric> And thread B: BEGIN; FuzzyBool result = test(); if (result.likely()) do_atomic_op_B(); END.
[19:14:34] *** Nawab <Nawab!~Neel@unaffiliated/neel> has joined ##C++-general
[19:14:39] *** Nawab <Nawab!~Neel@unaffiliated/neel> has quit IRC (Max SendQ exceeded)
[19:16:10] *** Nawab <Nawab!~Neel@unaffiliated/neel> has joined ##C++-general
[19:16:13] <Aleric> Here the result as measured by thread A can change as a result of do_atomic_op_B(); aka - it can change from false to true.
[19:16:40] *** Nawab <Nawab!~Neel@unaffiliated/neel> has quit IRC (Max SendQ exceeded)
[19:16:52] *** nshire <nshire!~nealshire@unaffiliated/nealshire> has joined ##C++-general
[19:17:01] *** dsiypl4 <dsiypl4!~dsiypl4@41.251.0.248> has joined ##C++-general
[19:17:56] *** Nawab <Nawab!~Neel@unaffiliated/neel> has joined ##C++-general
[19:18:04] *** Nawab <Nawab!~Neel@unaffiliated/neel> has quit IRC (Max SendQ exceeded)
[19:19:04] *** Nawab <Nawab!~Neel@unaffiliated/neel> has joined ##C++-general
[19:19:43] *** Nawab <Nawab!~Neel@unaffiliated/neel> has quit IRC (Max SendQ exceeded)
[19:20:23] *** Jesin <Jesin!~Jesin@pool-72-83-62-150.washdc.fios.verizon.net> has quit IRC (Quit: Leaving)
[19:20:27] *** Nawab <Nawab!~Neel@unaffiliated/neel> has joined ##C++-general
[19:21:12] *** Nawab <Nawab!~Neel@unaffiliated/neel> has quit IRC (Max SendQ exceeded)
[19:21:48] <Aleric> meh.. I have to think a lot more :/
[19:21:55] *** Nawab <Nawab!~Neel@unaffiliated/neel> has joined ##C++-general
[19:22:05] *** Nawab <Nawab!~Neel@unaffiliated/neel> has quit IRC (Remote host closed the connection)
[19:23:15] <kalven> is this for your streambuf?
[19:23:45] <Aleric> yes
[19:23:48] *** gelignite <gelignite!~gelignite@55d4d344.access.ecotel.net> has joined ##C++-general
[19:24:46] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[19:26:38] *** wildlander <wildlander!~wildlande@unaffiliated/wildlander> has joined ##C++-general
[19:28:01] <Aleric> I'm trying to turn something into a more general, abstract thing - so I can make classes for it.
[19:28:17] <Aleric> I'm sure that will come in handy in the future ;)
[19:28:32] <Aleric> But I only have one practical example to go on right now :/
[19:29:03] <Aleric> The problem I ran into is this:
[19:29:08] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Ping timeout: 250 seconds)
[19:29:17] <Aleric> (I'm afraid this is really complex)
[19:29:41] *** ogres <ogres!uid159312@gateway/web/irccloud.com/x-cjlcgmvsmwcibjld> has joined ##C++-general
[19:30:12] <Aleric> It happens in the case of a Socket that is being connected to a remote EndPoint (IP# + port).
[19:30:29] <ogres> hello
[19:30:45] <ogres> has anyone had issues with ncurses where
[19:30:55] <ogres> if you "spam" the terminal
[19:31:01] <ogres> with let's say 100 lines per second
[19:31:04] <ogres> it just breaks?
[19:31:09] <ogres> and you end up with weird characters
[19:31:17] *** shfil <shfil!uid293885@gateway/web/irccloud.com/x-rzrxdspnaaaedych> has joined ##C++-general
[19:32:51] <Aleric> When at initialization there is nothing to write to the socket fd (which is kinda to be expected) then normally I'd not start to monitor the fd for writeability - however, in order to detect that the connect() succeeded one has to do that: as soon as the socket becomes writable, you know you are connected.
[19:35:16] <Aleric> Now, at some point the socket becomes writable and I do in the call back: if (connect flag not already set) { flag |= is_connected; if (need to signal that we connected) { connected(true); ... and then the comment: // Now there is not longer a need to monitor the fd for writablity if the output buffer is empty.
[19:35:21] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC (Remote host closed the connection)
[19:35:46] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined ##C++-general
[19:35:53] <Aleric> Hence, then follows: if (m_obuffer->buffer_empty()) stop_output_device();
[19:36:57] <Aleric> This is obviously in the thread that read from the buffer (the socket fd is writeable, so normally this thread would read from the buffer and write to the socket).
[19:37:26] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined ##C++-general
[19:38:07] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has joined ##C++-general
[19:39:36] <Aleric> Ok, found it :)... On the other hand, in the thread that writes to the buffer - we can do a flush, ie socket << "foo" << std::flush;
[19:39:54] *** PSvils <PSvils!~PDevelope@91.105.108.4> has quit IRC (Quit: Leaving.)
[19:40:24] <Aleric> That results in a call to streambuf::sync which ends up on my OutputDevice class (the sync() method), which does the following:
[19:40:55] <Aleric> if (!m_obuffer->buffer_empty()) start_output_device();
[19:41:25] <Aleric> So, it does that right after actually writing to the buffer.
[19:41:50] *** matrim <matrim!~mats_@83.243.153.252> has joined ##C++-general
[19:42:55] *** pi- <pi-!~Ohmu@mx-ll-171.6.248-134.dynamic.3bb.co.th> has quit IRC (Ping timeout: 258 seconds)
[19:43:03] <Aleric> The immediate problem is that if the Read thread calls m_obuffer->buffer_empty() and it returns true, and then the Write thread writes to the buffer and calls start_output_device(), that call could immediately be voided by the read thread that still will call stop_output_device();
[19:43:38] <kalven> what does start_output_device do?
[19:43:56] <Aleric> it starts monitoring the fd for writeability.
[19:44:10] <Aleric> Ie, adds it to epoll()
[19:44:59] <Aleric> With this code as described we could end up with data in the buffer without watching the fd for writeability - so the buffer would never be written out.
[19:45:41] <kalven> why aren't you always monitoring for writeability?
[19:46:35] <Aleric> Why would I when I have nothing to write? :/
[19:46:56] *** hellozee <hellozee!~hellozee@2409:4066:219:799c:1759:1406:2e39:a546> has quit IRC (Ping timeout: 268 seconds)
[19:47:45] <Aleric> It does a little more anyway... also reference counting, a call to stop_output_device() can destroy the whole output device when we're done with it.
[19:48:27] <kalven> because you probably will write?
[19:48:45] *** jan64 <jan64!~jan64@79.191.205.155.ipv4.supernova.orange.pl> has joined ##C++-general
[19:49:03] <Aleric> You changed the subject :/
[19:49:45] <Aleric> Err, it's way worse...
[19:50:09] <Aleric> If you keep monitoring the socket for writeability then you start using 100% CPU for nothing.
[19:50:21] <Aleric> Cause normally it is writable...
[19:51:02] <Aleric> so you get a call back: hey! The socket is writable! While you have nothing to write. Better tell libev to stop watching that fd then or it will keep flooding you with that call back.
[19:51:56] <Aleric> I don't stop monitoring a fd for readability ;).
[19:52:11] <Aleric> Well, unless my buffer is full.
[19:52:24] <Aleric> But back to the topic please...
[19:52:45] <Aleric> So, using this example, I have:
[19:53:47] <Aleric> Get Thread: BEGIN; if (m_obuffer->buffer_empty().is_likely()) stop_output_device(); END
[19:54:53] <Aleric> Put Thread: BEGIN; pbump(len); /* now buffer no longer empty */ if (!m_obuffer->buffer_empty()) start_output_device(); END;
[19:56:46] <Aleric> What I want here is that if start_output_device() (that is, the internal atomic point of it) was called (or passed, that point) while the Get Thread already executed BEGIN - then a call to stop_output_device() should be voided.
[19:58:00] *** jan64 <jan64!~jan64@79.191.205.155.ipv4.supernova.orange.pl> has quit IRC (Read error: Connection reset by peer)
[19:58:09] <kalven> you can use epoll in edge triggered mode, then you won't get repeated notifications
[19:58:16] <Aleric> More abstractly, I think, you can view BEGIN/END as a mutex lock/unlock - then see what the code should do - and then remove the lock but make the end result of both threads reaching END the same as if there had been a lock.
[20:00:23] <Aleric> yes, but libev is level triggered only and the author writes somewhere that that has a reason (aka, edge triggered doesn't work)
[20:01:06] <Aleric> http://lists.schmorp.de/pipermail/libev/2010q4/001162.html
[20:01:19] <Aleric> > Libev is Level-Triggered that means that as long as the socket write buffer
[20:01:19] <Aleric> > has
[20:01:19] <Aleric> > space you will keep getting the write event.
[20:01:21] *** m_ben <m_ben!~m_ben@unaffiliated/m-ben/x-5917362> has joined ##C++-general
[20:02:07] *** multifractal <multifractal!~multifrac@194.73.87.179> has joined ##C++-general
[20:02:22] <Aleric> That doesn't say why he doesn't support edge triggered, I read that else where.
[20:02:32] <kalven> sorry, didn't know you were using an abstraction on top of epoll
[20:02:33] *** nevodka <nevodka!~nevodka@184.75.223.195> has quit IRC (Ping timeout: 250 seconds)
[20:02:34] *** multifractal <multifractal!~multifrac@194.73.87.179> has quit IRC (Remote host closed the connection)
[20:02:35] <Aleric> but you keep changing the subject... this way I make no progress :p
[20:03:43] <kalven> well a lot of this complexity seems to come from using epoll in level triggered mode
[20:03:53] <Aleric> sigh
[20:04:25] *** nevodka <nevodka!~nevodka@184.75.223.195> has joined ##C++-general
[20:04:45] <Aleric> I knew I shouldn't have given the practical example.. immediately it is "you should not do this", or "you should this in another way" :/... I just want to talk about the ABSTRACT problem :/
[20:05:24] *** seni <seni!~Nimitz14@cpc91218-cmbg18-2-0-cust107.5-4.cable.virginm.net> has joined ##C++-general
[20:05:32] <Aleric> There are many cases where this a returning pattern in threading - so it is interesting to try and abstract it :/
[20:06:18] <Aleric> I solve a very similar case for my statefultask class too...
[20:06:58] <kalven> it just seems that you're more interested in setting up these programming challenges for yourself rather than coming up with the simplest design for the actual task.
[20:07:28] <Aleric> The idea there is that when two threads call f() and g() in a race - you want to be sure that the result is the same, whether first f and then g, or first g and f is called.
[20:08:13] <Aleric> If they commutive that is trivial of course - but I'm talking about start/stop things.
[20:08:49] <Aleric> So also there the idea is that you must be able to assume a certain order, while if the order is in fact different - the result is still the same.
[20:09:07] <Aleric> I can't use the solution of my state machine here though - it is different in a way.
[20:09:11] <Aleric> but the idea is the same.
[20:10:03] <Aleric> So now I want to abstract it for threads (in the statemachine case threads are lower level - and the abstraction as Tasks rather than threads - which are just a little different).
[20:10:18] <Aleric> s/as/are/
[20:12:06] <Aleric> So... in the given practical case, and don't start about epoll please, the intuitive order is: at connect, when buffer empty, stop_output_device(). ... When AFTER that you write to the buffer, so the buffer is not empty any more - call start_output_device();
[20:12:15] <Aleric> The order is: stop .. then start.
[20:12:44] <Aleric> If the order is start and then stop, then what should the result be?
[20:14:00] <Aleric> Again - if the time difference is large.... you write to the buffer... call start, ... (buffer is flushed and becomes empty)... and then you check if the buffer is empty and call stop - then the end result should obviously be "stopped".
[20:14:09] *** afowler <afowler!~afowler@38.140.181.26> has joined ##C++-general
[20:14:09] *** nevodka <nevodka!~nevodka@184.75.223.195> has quit IRC (Ping timeout: 268 seconds)
[20:14:30] <Aleric> but there is a situation where first start is called and then stop, but you STILL want the result to be "started".
[20:15:25] <Aleric> So, the challenge is to formulate exactly when that is the case.
[20:16:16] <Aleric> In the practical example we have a practical "guide"... the end result should be "started" when at the end the buffer isn't empty.
[20:16:23] *** kallesbar <kallesbar!~kallesbar@188.126.80.24> has quit IRC (Quit: Konversation terminated!)
[20:16:58] <Aleric> but - the Get Thread ONLY calls stop in the first place when it reads 'was_true' from buffer_empty().
[20:17:38] <Aleric> So - clearly - the case that we're looking for is where the Put Thread writes to the buffer after that point.
[20:18:30] <Aleric> But that is not enough - if it writes to the buffer after the Get Thread already executed stop(), then we just have the first case... we also need to call start() before stop() is called.
[20:19:27] <Aleric> So the order is: A:buffer_empty(), B:pbump(), B:buffer_empty(), B:start(), A:stop() in which case the stop() must be ignored.
[20:20:06] <Aleric> So, I put a "marker" in the code, the BEGIN and END:
[20:20:48] <Aleric> A:BEGIN, A:buffer_empty(), B:pbump(), B:buffer_empty(), B:start(), A:stop(), A:END.
[20:21:27] <Aleric> And intuitively I think that it is ok to ignore stop() when B:start() is called in between A:BEGIN and A:END.
[20:22:42] <Aleric> That would mean that we can move the B:pbump() to the left, but even moving it one step - left of A:buffer_empty() - already causes that to return false - so stop() is never called in the first place.
[20:23:51] <Aleric> while moving B:start() one step to the right, but still before A:END - is a trivial case too since then start() is called AFTER stop() - likely we won't ignore stop then... but that doesn't matter.
[20:24:50] *** mcgriff <mcgriff!~griff-in@50-202-20-122-static.hfc.comcastbusiness.net> has joined ##C++-general
[20:25:22] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC (Remote host closed the connection)
[20:25:30] *** OpenSorc_ <OpenSorc_!~opensorce@216-82-197-9.static.grandenetworks.net> has joined ##C++-general
[20:25:51] <Aleric> Last piece of the puzzle is that there needs to be some kinds of synchronization between the threads - so that B:start() is linked to the THIS specific "critical area" of A:BEGIN to A:END.
[20:26:41] <Aleric> That obviously will be B:BEGIN and B:END :p.
[20:29:06] <Aleric> I consider writing to the buffer slow - not to mention that that happens in a totally different part of the code; B:sync() only contains if (!buffer_empty()) start();
[20:31:05] <Aleric> So, if at all possible, it would be nice if it could be: B:pbump(), B:BEGIN, B:buffer_empty(), B:start(), B:END ... resulting in:
[20:32:00] <Aleric> A:BEGIN, A:buffer_empty(), B:pbump(), B:BEGIN, B:buffer_empty(), B:start(), [B:END], A:stop(), [B:END], A:END, [B:END] - with three possible places for B:END.
[20:32:54] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC (Remote host closed the connection)
[20:33:18] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined ##C++-general
[20:36:18] *** OpenSorc_ <OpenSorc_!~opensorce@216-82-197-9.static.grandenetworks.net> has quit IRC (Remote host closed the connection)
[20:38:10] <Aleric> Seems the only order required is: A:BEGIN --> B:BEGIN --> B:start() --> ignore A:stop() until A:END.
[20:39:30] *** jan64 <jan64!~jan64@79.191.205.155.ipv4.supernova.orange.pl> has joined ##C++-general
[20:39:38] <Aleric> Let A:BEGIN be the constructor of some object, then I can enforce it to be created by demanding such object in order to convert a FuzzyBool to a bool.
[20:42:33] *** libertyprime <libertyprime!~libertypr@101.98.42.91> has joined ##C++-general
[20:43:53] *** Appleman1234 <Appleman1234!~quassel@124.186.203.31> has joined ##C++-general
[20:46:02] *** nevodka <nevodka!~nevodka@184.75.223.195> has joined ##C++-general
[20:48:50] <Aleric> Um, first attempt... A:{ Fuzzy mark(obuffer); if (obuffer->buffer_empty(mark)) stop(mark); } B:{ pbump(); Fuzzy mark(obuffer); if (!obuffer->buffer_empty(mark)) start(mark); }
[20:50:08] *** hph^ <hph^!hph@ip98-186-247-88.mc.at.cox.net> has quit IRC ()
[20:50:48] *** PSvils <PSvils!~PDevelope@91.105.108.4> has joined ##C++-general
[20:51:37] *** Nawab <Nawab!~Neel@unaffiliated/neel> has joined ##C++-general
[20:51:48] *** afowler <afowler!~afowler@38.140.181.26> has quit IRC (Remote host closed the connection)
[20:51:54] *** libertyprime <libertyprime!~libertypr@101.98.42.91> has quit IRC (Ping timeout: 250 seconds)
[20:52:32] *** afowler <afowler!~afowler@38.140.181.26> has joined ##C++-general
[20:52:47] <Aleric> Not happy with the english names yet... but at least I'm getting somewhere now.
[20:52:57] *** Nawab <Nawab!~Neel@unaffiliated/neel> has quit IRC (Max SendQ exceeded)
[20:53:20] *** pi- <pi-!~Ohmu@171.6.248.134> has joined ##C++-general
[20:53:22] *** afowler_ <afowler_!~afowler@38.140.181.26> has joined ##C++-general
[20:53:49] *** Nawab <Nawab!~Neel@unaffiliated/neel> has joined ##C++-general
[20:54:12] *** Nawab <Nawab!~Neel@unaffiliated/neel> has quit IRC (Max SendQ exceeded)
[20:54:56] *** aiaiste <aiaiste!aiaiste@ip98-186-247-88.mc.at.cox.net> has joined ##C++-general
[20:56:24] *** OtakuSen1ai <OtakuSen1ai!~OtakuSenp@unaffiliated/neel> has joined ##C++-general
[20:57:16] *** afowler <afowler!~afowler@38.140.181.26> has quit IRC (Ping timeout: 272 seconds)
[20:57:47] *** pi- <pi-!~Ohmu@171.6.248.134> has quit IRC (Ping timeout: 240 seconds)
[21:03:51] *** libertyprime <libertyprime!~libertypr@66.87.69.111.dynamic.snap.net.nz> has joined ##C++-general
[21:05:11] *** OtakuSen1ai <OtakuSen1ai!~OtakuSenp@unaffiliated/neel> has quit IRC (Quit: Lost terminal)
[21:06:44] *** Ralsei <Ralsei!~AllegroVi@aefn198.neoplus.adsl.tpnet.pl> has quit IRC (Ping timeout: 244 seconds)
[21:07:07] *** LunarJetman <LunarJetman!LunarJetma@94.196.247.102.threembb.co.uk> has quit IRC (Ping timeout: 246 seconds)
[21:07:17] <Ingersol> obuffer->output_buffer, pbump->strange_abbreviation_potentially_pointer_to_something
[21:09:53] *** JPulowski <JPulowski!~JPulowski@95.70.222.200> has quit IRC (Quit: Leaving)
[21:12:40] *** riksteri <riksteri!~SpaceDino@213.152.161.15> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
[21:13:39] *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 246 seconds)
[21:14:57] *** linux_dr <linux_dr!uid130126@gateway/web/irccloud.com/x-hgiqyqkkpljqdmbr> has joined ##C++-general
[21:16:23] *** LunarJetman <LunarJetman!LunarJetma@94.196.247.102.threembb.co.uk> has joined ##C++-general
[21:24:05] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[21:24:13] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[21:24:40] <m0shbear> Aleric: iostreams is weird in many places yes
[21:25:35] *** afowler_ <afowler_!~afowler@38.140.181.26> has quit IRC (Remote host closed the connection)
[21:25:40] *** BOKALDO <BOKALDO!~BOKALDO@46.109.206.127> has quit IRC (Quit: Leaving)
[21:25:49] *** afowler <afowler!~afowler@38.140.181.26> has joined ##C++-general
[21:25:53] *** led_dark_1 <led_dark_1!~Thunderbi@hotspot10.rywasoft.net> has quit IRC (Ping timeout: 246 seconds)
[21:27:13] *** seni_ <seni_!~Nimitz14@cpc91218-cmbg18-2-0-cust107.5-4.cable.virginm.net> has joined ##C++-general
[21:29:36] *** seni <seni!~Nimitz14@cpc91218-cmbg18-2-0-cust107.5-4.cable.virginm.net> has quit IRC (Ping timeout: 250 seconds)
[21:41:08] <Ameisen> So, are you supposed to be able to import modules against one another with C++2a modules?
[21:41:15] <Ameisen> that is, module A imports module B, module B imports module A?
[21:41:20] <Ameisen> Visual C++ does _not_ like this
[21:41:47] <Ameisen> haven't tested clang yet
[21:43:05] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined ##C++-general
[21:43:38] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[21:45:42] *** led_dark_1 <led_dark_1!~Thunderbi@hotspot10.rywasoft.net> has joined ##C++-general
[21:45:48] *** PSvils <PSvils!~PDevelope@91.105.108.4> has quit IRC (Quit: Leaving.)
[21:47:03] <TinoDidriksen> Circular dependencies are not allowed.
[21:51:23] *** Praise <Praise!~Fat@host41-202-dynamic.56-79-r.retail.telecomitalia.it> has joined ##C++-general
[21:51:23] *** Praise <Praise!~Fat@host41-202-dynamic.56-79-r.retail.telecomitalia.it> has quit IRC (Changing host)
[21:51:23] *** Praise <Praise!~Fat@unaffiliated/praise> has joined ##C++-general
[21:52:22] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC (Remote host closed the connection)
[21:52:28] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined ##C++-general
[21:57:46] *** LunarJetman <LunarJetman!LunarJetma@94.196.247.102.threembb.co.uk> has quit IRC (Ping timeout: 250 seconds)
[22:00:58] *** tomboy64 <tomboy64!~tomboy64@gateway/tor-sasl/tomboy64> has quit IRC (Remote host closed the connection)
[22:01:40] *** nblade42 <nblade42!~Miranda_4@ptr-91b6nnuewwpuclthy89.18120a2.ip6.access.telenet.be> has quit IRC (Quit: Goodbye.)
[22:02:58] *** tomboy64 <tomboy64!~tomboy64@gateway/tor-sasl/tomboy64> has joined ##C++-general
[22:08:51] *** ogres <ogres!uid159312@gateway/web/irccloud.com/x-cjlcgmvsmwcibjld> has quit IRC (Quit: Connection closed for inactivity)
[22:09:43] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has joined ##C++-general
[22:10:40] *** kadoban <kadoban!~mud@unaffiliated/kadoban> has joined ##C++-general
[22:11:46] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has quit IRC (Remote host closed the connection)
[22:13:13] *** kadoban <kadoban!~mud@unaffiliated/kadoban> has quit IRC (Client Quit)
[22:15:03] *** m_ben <m_ben!~m_ben@unaffiliated/m-ben/x-5917362> has quit IRC (Quit: WeeChat 2.3)
[22:15:04] *** gelignite <gelignite!~gelignite@55d4d344.access.ecotel.net> has quit IRC (Quit: Good fight, good night!)
[22:15:09] *** kadoban <kadoban!~mud@unaffiliated/kadoban> has joined ##C++-general
[22:20:42] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has joined ##C++-general
[22:20:59] *** matrim <matrim!~mats_@83.243.153.252> has quit IRC (Remote host closed the connection)
[22:28:31] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC (Read error: Connection reset by peer)
[22:31:51] *** afowler <afowler!~afowler@38.140.181.26> has quit IRC (Remote host closed the connection)
[22:33:05] *** afowler <afowler!~afowler@38.140.181.26> has joined ##C++-general
[22:35:18] *** vdamewood <vdamewood!~vdamewood@unaffiliated/vdamewood> has quit IRC (Quit: Life Beckons)
[22:36:34] *** gehn <gehn!gehn@gateway/vpn/privateinternetaccess/gehn> has joined ##C++-general
[22:37:59] *** Mike11 <Mike11!~Mike@unaffiliated/mike11> has joined ##C++-general
[22:38:11] *** OpenSorceress <OpenSorceress!~opensorce@216-82-197-9.static.grandenetworks.net> has joined ##C++-general
[22:38:11] *** OpenSorceress <OpenSorceress!~opensorce@216-82-197-9.static.grandenetworks.net> has quit IRC (Changing host)
[22:38:11] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined ##C++-general
[22:41:00] *** bayoubengal01 <bayoubengal01!~bayoubeng@71-15-105-17.dhcp.ftwo.tx.charter.com> has quit IRC (Read error: Connection reset by peer)
[22:41:18] *** bayoubengal01 <bayoubengal01!~bayoubeng@71-15-105-17.dhcp.ftwo.tx.charter.com> has joined ##C++-general
[22:44:19] *** SirFancyPantsOfP <SirFancyPantsOfP!~SirFancyP@37.186.119.154> has joined ##C++-general
[22:45:40] *** afowler <afowler!~afowler@38.140.181.26> has quit IRC (Remote host closed the connection)
[22:45:54] *** afowler <afowler!~afowler@38.140.181.26> has joined ##C++-general
[22:45:58] *** Codaraxis <Codaraxis!~Codaraxis@142.196.31.53> has joined ##C++-general
[22:47:06] *** mujjingun <mujjingun!~park@c-73-15-97-144.hsd1.ca.comcast.net> has joined ##C++-general
[22:51:58] *** longxia <longxia!~irc@unaffiliated/longxia> has quit IRC (Quit: leaving)
[22:55:55] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##C++-general
[23:00:47] *** Betal <Betal!~Betal@unaffiliated/betal> has joined ##C++-general
[23:01:44] *** Starhowl <Starhowl!~Starhowl@p57876F59.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
[23:01:53] *** bayoubengal01 <bayoubengal01!~bayoubeng@71-15-105-17.dhcp.ftwo.tx.charter.com> has quit IRC (Ping timeout: 268 seconds)
[23:05:38] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC (Remote host closed the connection)
[23:09:26] *** bayoubengal01 <bayoubengal01!~bayoubeng@71-15-105-17.dhcp.ftwo.tx.charter.com> has joined ##C++-general
[23:09:33] *** renn0xtk9 <renn0xtk9!~max@2a02:8070:a19d:2500:1d85:9732:f2d3:bd74> has joined ##C++-general
[23:12:02] *** LunarJetman <LunarJetman!LunarJetma@94.196.247.102.threembb.co.uk> has joined ##C++-general
[23:13:29] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined ##C++-general
[23:18:21] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC (Ping timeout: 258 seconds)
[23:25:47] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined ##C++-general
[23:29:13] *** Codyer <Codyer!~user@x5f74bfc8.dyn.telefonica.de> has quit IRC (Ping timeout: 245 seconds)
[23:36:14] *** AbleBacon <AbleBacon!~AbleBacon@unaffiliated/ablebacon> has quit IRC (Quit: Leaving)
[23:37:08] *** thomasross <thomasross!~thomasros@69.17.174.21> has quit IRC (Remote host closed the connection)
[23:37:34] *** thomasross <thomasross!~thomasros@69.17.174.21> has joined ##C++-general
[23:41:43] <Ameisen> TinoDidriksen - that's a shame. I presume it would require two-pass building for it to be allowed
[23:41:46] <Ameisen> to generate signatures first
[23:42:20] <Ameisen> Also makes building parallelism more difficult with modules that may have dependency chains.
[23:52:54] *** Serpent7776 <Serpent7776!~Serpent77@90-156-31-193.internetia.net.pl> has quit IRC (Quit: leaving)
[23:54:37] <Ameisen> I presume they figured it would make implementation too difficult if circular dependencies between modules were allowed?
[23:56:11] <rpav> i'm not sure it's meaningful for circular dependencies to exist for modules
[23:56:24] <rpav> like headers sure but stop thinking headers and more "entire units of functionality"
[23:56:51] <rpav> if two things co-depend they should almost certainly be in the same module
[23:57:23] <rpav> what would it *mean* for two modules to both require each other? how would you resolve that?
[23:58:23] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)
[23:58:54] *** Tazmain <Tazmain!~Tazmain@unaffiliated/tazmain> has quit IRC (Quit: Left)
[23:59:52] *** afowler <afowler!~afowler@38.140.181.26> has quit IRC (Remote host closed the connection)
top

   January 3, 2019
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31