Switch to DuckDuckGo Search
   January 7, 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:00:57] *** kitsunenokenja <kitsunenokenja!~kitsunech@68.91.220.96> has joined ##C++-general
[00:02:29] *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined ##C++-general
[00:07:31] *** r734 <r734!~r734@unaffiliated/r734> has joined ##C++-general
[00:09:16] *** Starhowl <Starhowl!~Starhowl@p5787E63C.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
[00:14:03] *** bmt_ <bmt_!~bmt@affs239.neoplus.adsl.tpnet.pl> has joined ##C++-general
[00:18:00] *** bmt <bmt!~bmt@affs239.neoplus.adsl.tpnet.pl> has quit IRC (Ping timeout: 272 seconds)
[00:19:23] *** pulse <pulse!~pulse@unaffiliated/pulse> has joined ##C++-general
[00:20:17] *** zap0 <zap0!~zap0@14-201-222-143.tpgi.com.au> has joined ##C++-general
[00:21:10] *** bmt_ is now known as bmt
[00:23:37] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined ##C++-general
[00:27:15] *** kitsunenokenja <kitsunenokenja!~kitsunech@68.91.220.96> has quit IRC (Ping timeout: 252 seconds)
[00:29:13] *** Unlimiter <Unlimiter!uid281704@gateway/web/irccloud.com/x-flcwwpdglwazjumt> has joined ##C++-general
[00:29:58] <Unlimiter> What is the library for basic OS operations
[00:29:59] <Unlimiter> ?
[00:31:19] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[00:31:45] *** symm- <symm-!~symm-@95.65.81.202> has quit IRC (Ping timeout: 252 seconds)
[00:40:21] <kalven> Unlimiter: like what?
[00:40:32] *** Tazmain <Tazmain!~Tazmain@unaffiliated/tazmain> has quit IRC (Quit: Left)
[00:42:09] *** libertyprime <libertyprime!~libertypr@122-62-48-103-fibre.sparkbb.co.nz> has quit IRC (Ping timeout: 268 seconds)
[00:43:22] *** jstein <jstein!~jstein@gentoo/developer/jstein> has quit IRC (Quit: quit)
[00:46:11] *** bmt <bmt!~bmt@affs239.neoplus.adsl.tpnet.pl> has quit IRC (Quit: Leaving)
[00:53:05] *** loginerrorholdon <loginerrorholdon!~lalilulel@177.72.98.78> has joined ##C++-general
[00:56:02] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[00:56:59] *** lalilulelo <lalilulelo!~lalilulel@177.72.98.78> has quit IRC (Ping timeout: 246 seconds)
[00:57:19] *** nucleargrave <nucleargrave!~nucleargr@c-73-150-253-137.hsd1.nj.comcast.net> has quit IRC (Quit: WeeChat 2.3)
[00:57:38] *** nucleargrave <nucleargrave!~nucleargr@c-73-150-253-137.hsd1.nj.comcast.net> has joined ##C++-general
[01:02:16] *** serviscope_minor <serviscope_minor!~Telequipm@88.97.56.26> has quit IRC (Ping timeout: 250 seconds)
[01:08:20] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC (Ping timeout: 250 seconds)
[01:09:30] *** philipp_ <philipp_!~phil@p549EEEB7.dip0.t-ipconnect.de> has joined ##C++-general
[01:12:47] *** abraxxas <abraxxas!~phil@p5B0D9AC8.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 240 seconds)
[01:15:39] *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 252 seconds)
[01:17:47] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined ##C++-general
[01:18:28] *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined ##C++-general
[01:18:49] *** loginerrorholdon <loginerrorholdon!~lalilulel@177.72.98.78> has quit IRC (Ping timeout: 246 seconds)
[01:24:14] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[01:24:23] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[01:24:54] *** loginerrorholdon <loginerrorholdon!~lalilulel@177.72.98.78> has joined ##C++-general
[01:25:24] *** loginerrorholdon <loginerrorholdon!~lalilulel@177.72.98.78> has quit IRC (Remote host closed the connection)
[01:26:06] *** XCE <XCE!~XCE@104-3-184-7.lightspeed.sntcca.sbcglobal.net> has quit IRC (Ping timeout: 250 seconds)
[01:28:41] *** matrim <matrim!~mats_@83.243.153.252> has quit IRC (Remote host closed the connection)
[01:31:51] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has joined ##C++-general
[01:33:34] *** xekz <xekz!~kexmex@unaffiliated/kexmex> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[01:33:41] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has quit IRC (Remote host closed the connection)
[01:36:21] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has joined ##C++-general
[01:37:26] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has quit IRC (Remote host closed the connection)
[01:44:44] *** DatJohnny <DatJohnny!~johnny@89-74-252-30.dynamic.chello.pl> has quit IRC (Ping timeout: 250 seconds)
[01:48:34] *** Albori <Albori!~Albori@216-229-75-72.fidnet.com> has quit IRC (Ping timeout: 246 seconds)
[02:00:14] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[02:01:06] *** de-facto <de-facto!~de-facto@gateway/tor-sasl/de-facto> has quit IRC (Quit: See you around.)
[02:01:06] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[02:01:23] *** de-facto <de-facto!~de-facto@gateway/tor-sasl/de-facto> has joined ##C++-general
[02:01:24] *** jan64 <jan64!~jan64@79.191.177.206.ipv4.supernova.orange.pl> has quit IRC (Ping timeout: 246 seconds)
[02:07:21] *** mitch0 <mitch0!~mitch@84-236-35-247.pool.digikabel.hu> has joined ##C++-general
[02:09:20] *** philipp_ <philipp_!~phil@p549EEEB7.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)
[02:11:31] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[02:15:44] *** Albori <Albori!~Albori@216-229-75-72.fidnet.com> has joined ##C++-general
[02:29:39] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.219.247.64> has joined ##C++-general
[02:32:41] *** AmR|EiSa <AmR|EiSa!~AmR|EiSa@156.219.247.64> has quit IRC (Remote host closed the connection)
[02:38:40] *** Unlimiter <Unlimiter!uid281704@gateway/web/irccloud.com/x-flcwwpdglwazjumt> has quit IRC (Quit: Connection closed for inactivity)
[02:41:58] *** lh_mouse <lh_mouse!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has joined ##C++-general
[02:43:30] *** rjframe <rjframe!~rjframe@c-73-146-232-195.hsd1.in.comcast.net> has quit IRC (Quit: Leaving)
[02:48:51] *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 260 seconds)
[02:54:43] *** kitsunenokenja <kitsunenokenja!~kitsunech@68.91.220.96> has joined ##C++-general
[03:01:51] *** QuietLurker <QuietLurker!~QuietLurk@bmtnon1328w-lp130-02-70-27-108-208.dsl.bell.ca> has joined ##C++-general
[03:03:37] *** Stanley00 <Stanley00!~Stanley00@unaffiliated/stanley00> has joined ##C++-general
[03:14:38] *** wildlander <wildlander!~wildlande@unaffiliated/wildlander> has quit IRC (Ping timeout: 245 seconds)
[03:15:47] *** irrenhaus3 <irrenhaus3!~xenon@ip-37-201-6-163.hsi13.unitymediagroup.de> has quit IRC (Quit: Lost terminal)
[03:18:29] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC (Remote host closed the connection)
[03:18:55] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined ##C++-general
[03:22:50] *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined ##C++-general
[03:24:44] *** r734 <r734!~r734@unaffiliated/r734> has quit IRC (Quit: Leaving)
[03:28:20] *** solidfox <solidfox!~solidfox@unaffiliated/snake/x-2550465> has joined ##C++-general
[03:33:12] *** lh_ideapad <lh_ideapad!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has joined ##C++-general
[03:38:53] *** kadoban <kadoban!~mud@unaffiliated/kadoban> has joined ##C++-general
[03:40:15] *** QuietLurker <QuietLurker!~QuietLurk@bmtnon1328w-lp130-02-70-27-108-208.dsl.bell.ca> has quit IRC (Read error: Connection reset by peer)
[03:53:52] *** mujjingun <mujjingun!~park@216.251.157.178> has joined ##C++-general
[03:54:31] *** esrse <esrse!~nil@175.126.171.165> has joined ##C++-general
[03:57:15] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has joined ##C++-general
[03:58:26] <amosbird> this is nonsense, https://la.wentropy.com/3gVb how can it segfault at ++required_columns_with_duplicate_count[name];?
[03:59:01] <amosbird> oops, missing a line, using String = std::string
[03:59:21] *** nejni-marji <nejni-marji!~nejni-mar@unaffiliated/nejni-marji> has joined ##C++-general
[04:02:12] <Stanley00> amosbird: make a testcase that generate the segfault please. That snippet seems fine to my
[04:02:14] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has quit IRC (Read error: Connection reset by peer)
[04:04:32] <Svitkona> what is String?
[04:04:34] <Svitkona> oh
[04:04:39] <Svitkona> i see
[04:05:44] <amosbird> hmm, it must have segfaults in previous call stacks then
[04:06:16] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC (Ping timeout: 268 seconds)
[04:07:45] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined ##C++-general
[04:11:55] *** libertyprime <libertyprime!~libertypr@118.149.138.185> has joined ##C++-general
[04:28:51] *** proteusguy-satri <proteusguy-satri!~proteus-g@cm-58-10-154-246.revip7.asianet.co.th> has quit IRC (Remote host closed the connection)
[04:30:42] *** jellycode <jellycode!~jellycode@c-76-112-105-225.hsd1.mi.comcast.net> has joined ##C++-general
[04:30:58] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has joined ##C++-general
[04:34:13] *** Betal <Betal!~Betal@unaffiliated/betal> has quit IRC (Remote host closed the connection)
[04:50:52] *** Lord_of_Life <Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362> has quit IRC (Ping timeout: 258 seconds)
[04:51:14] *** ^Manu <^Manu!48d3e45a@gateway/web/freenode/ip.72.211.228.90> has joined ##C++-general
[04:51:21] <^Manu> does anyone know what "@PLT" on the end of symbol names means?
[04:51:35] <Stanley00> ^Manu: https://reverseengineering.stackexchange.com/a/1993
[04:53:27] *** Lord_of_Life <Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362> has joined ##C++-general
[04:54:01] <^Manu> hmmm
[04:54:02] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has quit IRC (Read error: Connection reset by peer)
[04:54:44] <^Manu> so is the linker smart with these symbol names? let's say I extern to `foo`, and there is `foo@plt` or `foo@PLT` in the library; will it find the right thing?
[04:55:23] <^Manu> I'm not even seeing consistency between `@PLT` and `@plt` :/
[04:56:11] *** proteusguy <proteusguy!~proteus-g@mx-ll-183.89.213-60.dynamic.3bb.co.th> has joined ##C++-general
[04:56:34] <Stanley00> ^Manu: plt or PLT is depends on the compiler. And it just a reference inside your code, the real function in library will be place in .plt section
[04:58:27] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has joined ##C++-general
[04:58:44] *** xekz <xekz!~kexmex@unaffiliated/kexmex> has joined ##C++-general
[04:59:40] <^Manu> i understand, but the linker must link the calling code to a call shim or something no?
[05:00:07] <Stanley00> ^Manu: it could be a job of the loader
[05:00:14] *** mujjingun <mujjingun!~park@216.251.157.178> has quit IRC (Ping timeout: 246 seconds)
[05:00:46] <^Manu> what causes the compiler to append that to the symbol name?
[05:00:58] <^Manu> for instance, in my disasm, i see: jmp _ZnwmSt11align_val_t@PLT
[05:01:12] <^Manu> why would the compiler emit that symbol name for the call?
[05:01:30] <^Manu> the compiler doesn't know what it's linking to...
[05:02:01] *** mandeep <mandeep!mandeep@gateway/vpn/privateinternetaccess/mandeepb> has quit IRC (Remote host closed the connection)
[05:02:38] <Stanley00> did you try disasmble the .plt section? and check code for _ZnwmSt11align_val_t@PLT in there
[05:04:35] *** fc5dc9d4 <fc5dc9d4!~quassel@p5B081E8B.dip0.t-ipconnect.de> has joined ##C++-general
[05:04:50] <^Manu> the symbols are present, but i'm trying to understand why the compiler's doing this... the calling code doesn't know anything about the linking environment.
[05:05:03] <^Manu> it
[05:05:15] <^Manu> it's like the compiler's just arbitrarily affixing the suffix.
[05:07:56] *** Unarelith <Unarelith!~Quent4234@static-176-158-117-112.ftth.abo.bbox.fr> has quit IRC (Ping timeout: 268 seconds)
[05:08:36] *** Shikadi <Shikadi!~Shikadi@cpe-98-10-45-235.rochester.res.rr.com> has quit IRC (Quit: Leaving)
[05:08:53] *** fc5dc9d4_ <fc5dc9d4_!~quassel@p5B0814AF.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 258 seconds)
[05:13:06] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has quit IRC (Read error: Connection reset by peer)
[05:20:27] *** wawasho is now known as Guest21820
[05:20:27] *** Guest21820 <Guest21820!~wawasho@c-66-56-4-158.hsd1.ga.comcast.net> has quit IRC (Killed (kornbluth.freenode.net (Nickname regained by services)))
[05:21:12] *** wawasho_ <wawasho_!~wawasho@2601:c0:c780:19c8:a3e3:d955:1fb6:719b> has joined ##C++-general
[05:24:15] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[05:24:23] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[05:27:13] *** mujjingun <mujjingun!~park@216.251.157.178> has joined ##C++-general
[05:30:48] *** solidfox <solidfox!~solidfox@unaffiliated/snake/x-2550465> has quit IRC (Quit: WeeChat 2.3)
[05:35:32] *** SirFancyPantsOfP <SirFancyPantsOfP!~SirFancyP@37.186.119.154> has joined ##C++-general
[05:35:43] *** mujjingun <mujjingun!~park@216.251.157.178> has quit IRC (Ping timeout: 258 seconds)
[05:36:44] *** Seakseq_ <Seakseq_!~Seakseq@49.218.44.116> has joined ##C++-general
[05:37:54] *** zap0 <zap0!~zap0@14-201-222-143.tpgi.com.au> has quit IRC (Quit: zap0)
[05:46:21] *** UnDeRsOuL <UnDeRsOuL!~UnDeRsOuL@unaffiliated/undersoul> has quit IRC (Ping timeout: 244 seconds)
[05:47:08] *** UnDeRsOuL <UnDeRsOuL!~UnDeRsOuL@unaffiliated/undersoul> has joined ##C++-general
[05:48:07] *** tm <tm!~sinnlos@unaffiliated/tm> has quit IRC (Ping timeout: 240 seconds)
[05:49:08] *** kitsunenokenja <kitsunenokenja!~kitsunech@68.91.220.96> has quit IRC (Ping timeout: 258 seconds)
[05:53:07] *** tm <tm!~sinnlos@unaffiliated/tm> has joined ##C++-general
[05:58:00] *** josef_k <josef_k!~jeremy@116.250.193.181> has joined ##C++-general
[06:06:21] *** Seakseq_ <Seakseq_!~Seakseq@49.218.44.116> has quit IRC (Read error: Connection reset by peer)
[06:07:08] *** Klox <Klox!~Klox@c-73-22-66-195.hsd1.il.comcast.net> has quit IRC (Ping timeout: 268 seconds)
[06:07:37] *** Klox <Klox!~Klox@c-73-22-66-195.hsd1.il.comcast.net> has joined ##C++-general
[06:12:16] *** Seakseq_ <Seakseq_!~Seakseq@49.218.44.116> has joined ##C++-general
[06:13:51] *** SwiftMatt <SwiftMatt!~Objective@223.255.127.136> has joined ##C++-general
[06:19:14] *** shfil <shfil!uid293885@gateway/web/irccloud.com/x-vuwiwzeqztcciklu> has quit IRC (Quit: Connection closed for inactivity)
[06:24:24] *** absence <absence!~RizzoTheR@host-091-097-038-014.ewe-ip-backbone.de> has joined ##C++-general
[06:26:14] *** immibis <immibis!~immibis@125-238-72-168-fibre.sparkbb.co.nz> has joined ##C++-general
[06:27:39] *** SwiftMatt <SwiftMatt!~Objective@223.255.127.136> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[06:27:47] *** rizzo <rizzo!~RizzoTheR@dyndsl-091-096-043-182.ewe-ip-backbone.de> has quit IRC (Ping timeout: 240 seconds)
[06:28:15] *** libertyprime <libertyprime!~libertypr@118.149.138.185> has quit IRC (Read error: Connection reset by peer)
[06:29:58] *** alexge50 <alexge50!~alexge50@unaffiliated/alexge50> has quit IRC (Ping timeout: 246 seconds)
[06:35:31] *** Galik <Galik!~galik@unaffiliated/galik> has quit IRC (Remote host closed the connection)
[06:35:33] *** pulse <pulse!~pulse@unaffiliated/pulse> has quit IRC (Quit: pulse)
[06:38:05] *** led_dark_1 <led_dark_1!~Thunderbi@hotspot10.rywasoft.net> has quit IRC (Quit: led_dark_1)
[06:43:05] *** alexge50 <alexge50!~alexge50@unaffiliated/alexge50> has joined ##C++-general
[06:51:06] *** josef_k <josef_k!~jeremy@116.250.193.181> has quit IRC (Ping timeout: 250 seconds)
[06:53:29] *** zeduckmaster <zeduckmaster!~zeduckmas@85.106.1.181> has joined ##C++-general
[06:58:24] *** lilabsence <lilabsence!~RizzoTheR@host-091-097-135-113.ewe-ip-backbone.de> has joined ##C++-general
[07:01:09] *** josef_k <josef_k!~jeremy@116.250.193.181> has joined ##C++-general
[07:01:47] *** absence <absence!~RizzoTheR@host-091-097-038-014.ewe-ip-backbone.de> has quit IRC (Ping timeout: 240 seconds)
[07:02:25] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##C++-general
[07:04:39] *** jellycode <jellycode!~jellycode@c-76-112-105-225.hsd1.mi.comcast.net> has quit IRC (Ping timeout: 258 seconds)
[07:12:28] *** Seakseq_ <Seakseq_!~Seakseq@49.218.44.116> has quit IRC (Read error: Connection reset by peer)
[07:19:38] *** z8z <z8z!~x@FL1-119-240-240-156.tky.mesh.ad.jp> has joined ##C++-general
[07:23:44] *** josef_k <josef_k!~jeremy@116.250.193.181> has quit IRC (Ping timeout: 246 seconds)
[07:25:02] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC (Ping timeout: 244 seconds)
[07:26:35] *** Seakseq_ <Seakseq_!~Seakseq@49.218.44.116> has joined ##C++-general
[07:30:45] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined ##C++-general
[07:33:34] *** ^Manu <^Manu!48d3e45a@gateway/web/freenode/ip.72.211.228.90> has quit IRC (Quit: Page closed)
[07:34:56] *** lh_ideapad <lh_ideapad!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has quit IRC (Ping timeout: 258 seconds)
[07:35:07] *** xekz <xekz!~kexmex@unaffiliated/kexmex> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[07:36:15] *** Stanley00 <Stanley00!~Stanley00@unaffiliated/stanley00> has quit IRC (Read error: Connection reset by peer)
[07:38:28] *** BOKALDO <BOKALDO!~BOKALDO@46.109.200.222> has joined ##C++-general
[07:40:06] *** Stanley00 <Stanley00!~Stanley00@unaffiliated/stanley00> has joined ##C++-general
[07:41:02] *** rdad <rdad!~rdad@ool-2f117e59.dyn.optonline.net> has joined ##C++-general
[07:41:23] <rdad> I want to define and use a: const char* char[] strs = {"foo", "bar" } in a hearder file. How can I go about doing that?
[07:42:18] <rdad> Currently I get various kinds of errors, Ex: multiple definition when I compile a lib
[07:42:34] <JWatkins> rdad: In general, you can't. You're going to have to modify your requirements somehow
[07:42:53] <rdad> putting it in a struct I get undefined reference
[07:43:02] <rdad> Hmm
[07:43:14] <rdad> is there any constexpr trick for that?
[07:43:59] <JWatkins> One option would be to put the storage in a function (const char*[] getStrs(static shar* strs[] = {...}; return strs;)
[07:44:25] <JWatkins> Another would be to declar the array in the header and have a .cpp file that defines the storage for the array
[07:44:47] <rdad> can I declare and initialize the array in the header?
[07:44:48] <JWatkins> There are probably other options too. Which is best for your situation is really up to you
[07:45:33] <rdad> basically I want to declare an enum and corresponding strings right next to each other in the header
[07:45:33] <JWatkins> If you go with the function route I outlined above everything would be in the header
[07:45:46] <rdad> the enum will index into the str array
[07:45:57] <rdad> for the corresponding str
[07:46:17] <JWatkins> Yeah, that's just fundementally hard in C++. Personally, I've done the same thing with a backing .cpp file
[07:46:33] <rdad> I was hopping to avoid creating additional if-else if, checks
[07:46:39] <JWatkins> I just comment the hell out of the header warning future devs to make sure they update the .cpp file too
[07:46:57] <rdad> right
[07:46:58] *** hero100 <hero100!~zzl@119.145.5.45> has joined ##C++-general
[07:48:25] <JWatkins> It's not a great solution. I've managed to forget to update both files at least once that I can recall, but I haven't found a better solution yet
[07:49:07] <JWatkins> You just can't declar storage in a header because that storage will be placed in every source file that includes the header, as you've already discovered
[07:49:23] <rdad> At some point I'll have the enum code generated along with corresponding strings, etc.
[07:49:30] <rdad> but I don't have the time for that solution now
[07:50:07] *** V-ille <V-ille!~vivoutil@85-23-140-45.bb.dnainternet.fi> has quit IRC (Ping timeout: 240 seconds)
[07:52:25] *** Haohmaru <Haohmaru!~Haohmaru@195.24.53.110> has joined ##C++-general
[07:55:01] *** alyptik <alyptik!ayy@cpe-76-173-133-37.hawaii.res.rr.com> has quit IRC (Ping timeout: 246 seconds)
[07:56:06] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC (Ping timeout: 250 seconds)
[08:02:26] <rdad> To be continued ...
[08:02:40] *** lh_ideapad <lh_ideapad!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has joined ##C++-general
[08:02:51] <rdad> thanks all. Have a good day/night!
[08:03:03] *** rdad <rdad!~rdad@ool-2f117e59.dyn.optonline.net> has quit IRC ()
[08:07:47] *** Tazmain <Tazmain!~Tazmain@unaffiliated/tazmain> has joined ##C++-general
[08:09:53] *** batman_nair <batman_nair!~batman_na@111.92.77.160> has joined ##C++-general
[08:10:29] *** Forsaken87 <Forsaken87!~quassel@2a02:908:1869:4b20:f4b0:188b:cefd:b063> has joined ##C++-general
[08:16:49] *** arch-1980 <arch-1980!~arch@93.114.71.39> has joined ##C++-general
[08:18:42] *** arch-1980 <arch-1980!~arch@93.114.71.39> has left ##C++-general
[08:25:18] *** JohnMS_WORK <JohnMS_WORK!~JohnMS_WO@host-193-59-178-3.gog.com> has joined ##C++-general
[08:25:29] *** alyptik <alyptik!ayy@cpe-76-173-133-37.hawaii.res.rr.com> has joined ##C++-general
[08:31:49] *** kallesbar <kallesbar!~kallesbar@46.246.105.19> has joined ##C++-general
[08:32:21] *** trittweiler <trittweiler!~trittweil@46-126-77-151.dynamic.hispeed.ch> has joined ##C++-general
[08:34:06] *** Forsaken87 <Forsaken87!~quassel@2a02:908:1869:4b20:f4b0:188b:cefd:b063> has quit IRC (Ping timeout: 252 seconds)
[08:36:06] *** Seakseq_ <Seakseq_!~Seakseq@49.218.44.116> has quit IRC (Read error: Connection reset by peer)
[08:38:27] *** gulzar <gulzar!~gulzar@14.139.123.36> has joined ##C++-general
[08:41:17] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Read error: Connection reset by peer)
[08:44:04] *** Unarelith <Unarelith!~Quent4234@static-176-158-117-112.ftth.abo.bbox.fr> has joined ##C++-general
[08:44:39] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[08:45:12] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Client Quit)
[08:47:59] *** janco <janco!~janco@83-160-103-27.ip.xs4all.nl> has joined ##C++-general
[08:50:40] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[08:51:27] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has joined ##C++-general
[08:52:27] *** V-ille <V-ille!~vivoutil@192.89.120.53> has joined ##C++-general
[08:52:58] *** V-ille <V-ille!~vivoutil@192.89.120.53> has quit IRC (Client Quit)
[08:53:11] *** V-ille <V-ille!~vivoutil@192.89.120.53> has joined ##C++-general
[08:55:19] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has joined ##C++-general
[09:07:51] *** janco <janco!~janco@83-160-103-27.ip.xs4all.nl> has quit IRC (Ping timeout: 244 seconds)
[09:07:53] *** AbleBacon <AbleBacon!~AbleBacon@unaffiliated/ablebacon> has quit IRC (Quit: Leaving)
[09:13:48] *** wPSvils1 <wPSvils1!~PDevelope@83.243.92.42> has quit IRC (Ping timeout: 272 seconds)
[09:14:47] *** apa <apa!mfqr@nat/digia/x-fiojmbxtxeevfvmd> has joined ##C++-general
[09:20:48] *** serviscope_minor <serviscope_minor!~Telequipm@88.97.56.26> has joined ##C++-general
[09:24:15] *** xynt <xynt!~xynt@unaffiliated/xynt> has joined ##C++-general
[09:24:15] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[09:24:29] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[09:27:19] *** fogbank <fogbank!~fogbank@net-188-153-77-173.cust.vodafonedsl.it> has joined ##C++-general
[09:29:18] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has quit IRC (Read error: Connection reset by peer)
[09:30:06] *** alexge50 <alexge50!~alexge50@unaffiliated/alexge50> has quit IRC (Ping timeout: 252 seconds)
[09:32:52] *** rokups <rokups!uid197268@gateway/web/irccloud.com/x-ezkrhyoecsecasfn> has joined ##C++-general
[09:34:12] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has joined ##C++-general
[09:38:48] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Quit: ZNC - https://znc.in)
[09:40:06] *** Wetmelon <Wetmelon!~wetmelon@2600:1700:2601:7c40:79ca:704b:a785:ea> has quit IRC (Ping timeout: 250 seconds)
[09:42:54] *** alexge50 <alexge50!~alexge50@unaffiliated/alexge50> has joined ##C++-general
[09:45:47] *** dinfuehr <dinfuehr!~dinfuehr@91-114-129-132.adsl.highway.telekom.at> has quit IRC (Ping timeout: 240 seconds)
[09:45:58] *** dinfuehr <dinfuehr!~dinfuehr@91-114-129-132.adsl.highway.telekom.at> has joined ##C++-general
[09:47:18] *** noboruma <noboruma!~noboruma@213.146.129.60> has quit IRC (Quit: leaving)
[09:48:25] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[09:51:35] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has quit IRC (Quit: Leaving)
[09:53:10] *** quarterback <quarterback!~quarterba@160.238.73.156> has joined ##C++-general
[09:53:10] *** quarterback <quarterback!~quarterba@160.238.73.156> has quit IRC (Changing host)
[09:53:10] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has joined ##C++-general
[09:56:25] *** z8z <z8z!~x@FL1-119-240-240-156.tky.mesh.ad.jp> has quit IRC (Quit: Quitting)
[09:57:01] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has quit IRC (Quit: Konversation terminated!)
[10:00:05] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[10:00:38] *** SwiftMatt <SwiftMatt!~Objective@36.102.208.84> has joined ##C++-general
[10:00:51] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has quit IRC (Read error: Connection reset by peer)
[10:01:10] *** dzejrou <dzejrou!dzejrou@nat/suse/x-nixfsxzsapnnbmfg> has joined ##C++-general
[10:01:49] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has joined ##C++-general
[10:08:35] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Ping timeout: 246 seconds)
[10:09:22] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[10:09:25] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has quit IRC (Ping timeout: 258 seconds)
[10:09:32] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[10:09:44] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has joined ##C++-general
[10:11:16] *** ZaraFrax <ZaraFrax!~ZaraFrax@p200300D73BC6790091E293FA1CBF6AD3.dip0.t-ipconnect.de> has joined ##C++-general
[10:11:55] *** serviscope_minor <serviscope_minor!~Telequipm@88.97.56.26> has quit IRC (Ping timeout: 244 seconds)
[10:13:53] *** OpenSorc_ <OpenSorc_!~opensorce@216-82-197-9.static.grandenetworks.net> has quit IRC (Remote host closed the connection)
[10:18:14] *** SwiftMatt <SwiftMatt!~Objective@36.102.208.84> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[10:18:38] *** MrCrackPotBuilde <MrCrackPotBuilde!~MrCrackPo@161.142.89.253> has joined ##C++-general
[10:20:03] *** alyptik <alyptik!ayy@cpe-76-173-133-37.hawaii.res.rr.com> has quit IRC (Ping timeout: 245 seconds)
[10:22:18] *** rajrajraj <rajrajraj!uid72176@gateway/web/irccloud.com/x-lxoqnfmijvtppsip> has joined ##C++-general
[10:30:26] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Ping timeout: 272 seconds)
[10:31:39] *** shfil <shfil!uid293885@gateway/web/irccloud.com/x-ugjffxuconbbirzt> has joined ##C++-general
[10:31:47] *** lilabsence <lilabsence!~RizzoTheR@host-091-097-135-113.ewe-ip-backbone.de> has quit IRC (Ping timeout: 240 seconds)
[10:32:08] *** josef_k <josef_k!~jeremy@116.250.193.181> has joined ##C++-general
[10:33:11] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[10:34:10] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[10:34:32] *** bumbar_ <bumbar_!~bumbar@unaffiliated/bumbar> has quit IRC (Quit: Leaving)
[10:41:22] *** Gyro <Gyro!~user@x4d01b642.dyn.telefonica.de> has joined ##C++-general
[10:45:47] *** immibis <immibis!~immibis@125-238-72-168-fibre.sparkbb.co.nz> has quit IRC (Ping timeout: 240 seconds)
[10:45:58] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Ping timeout: 250 seconds)
[10:46:00] *** Tazmain <Tazmain!~Tazmain@unaffiliated/tazmain> has quit IRC (Ping timeout: 252 seconds)
[10:49:28] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined ##C++-general
[10:50:52] *** Elirips <Elirips!~Elirips@242.109.22.178.ftth.as8758.net> has joined ##C++-general
[10:51:10] *** velco <velco!chill@nat/arm/x-twcubgtdpdfunlor> has joined ##C++-general
[10:51:51] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[10:53:47] *** Seakseq <Seakseq!~Seakseq@49.218.44.116> has quit IRC (Ping timeout: 240 seconds)
[10:54:12] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC (Ping timeout: 250 seconds)
[10:54:49] *** Seakseq_ <Seakseq_!~Seakseq@49.218.44.116> has joined ##C++-general
[10:55:15] *** Seakseq_ <Seakseq_!~Seakseq@49.218.44.116> has quit IRC (Client Quit)
[10:56:26] *** Tazmain <Tazmain!~Tazmain@unaffiliated/tazmain> has joined ##C++-general
[10:58:24] *** Starhowl <Starhowl!~Starhowl@p5787E63C.dip0.t-ipconnect.de> has joined ##C++-general
[11:01:17] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Ping timeout: 268 seconds)
[11:01:42] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[11:08:36] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has joined ##C++-general
[11:11:22] *** nshire <nshire!~nealshire@unaffiliated/nealshire> has quit IRC (Ping timeout: 246 seconds)
[11:12:31] *** biberu <biberu!~biberu@host-95-195-130-122.mobileonline.telia.com> has joined ##C++-general
[11:13:37] *** trittweiler <trittweiler!~trittweil@46-126-77-151.dynamic.hispeed.ch> has quit IRC (Ping timeout: 268 seconds)
[11:18:18] *** jstein_ <jstein_!~jstein@gentoo/developer/jstein> has joined ##C++-general
[11:18:21] *** jstein_ is now known as jstein
[11:26:51] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Ping timeout: 260 seconds)
[11:27:52] *** alyptik <alyptik!ayy@cpe-76-173-133-37.hawaii.res.rr.com> has joined ##C++-general
[11:28:03] *** rafalcpp <rafalcpp!~racalcppp@84-10-11-234.static.chello.pl> has quit IRC (Ping timeout: 246 seconds)
[11:28:03] *** queip <queip!~queip@unaffiliated/rezurus> has quit IRC (Ping timeout: 246 seconds)
[11:31:26] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[11:38:17] *** josef_k <josef_k!~jeremy@116.250.193.181> has quit IRC (Ping timeout: 268 seconds)
[11:38:19] *** Starhowl <Starhowl!~Starhowl@p5787E63C.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 246 seconds)
[11:44:29] *** biberu <biberu!~biberu@host-95-195-130-122.mobileonline.telia.com> has quit IRC ()
[11:45:52] *** rafalcpp <rafalcpp!~racalcppp@84-10-11-234.static.chello.pl> has joined ##C++-general
[11:46:59] <gulzar> I have a text file like this http://paste.debian.net/1059014/ . where first column is key and second is value (separated with spaces). I need only few of these key:value pairs. I am doing like this line.substr(0,x) == "mykey" , and boost::split() to get the value. Is it a good idea or any other way to get the key,values?
[11:47:09] *** queip <queip!~queip@unaffiliated/rezurus> has joined ##C++-general
[11:55:47] *** symm- <symm-!~symm-@95.65.81.202> has joined ##C++-general
[11:57:27] *** esrse <esrse!~nil@175.126.171.165> has quit IRC (Ping timeout: 246 seconds)
[12:02:02] *** biberu <biberu!~biberu@c83-251-152-254.bredband.comhem.se> has joined ##C++-general
[12:02:14] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Ping timeout: 250 seconds)
[12:03:47] *** Lyberta <Lyberta!~Lyberta@fsf/member/FaTony> has joined ##C++-general
[12:03:59] <Lyberta> how can I manage several builds of GCC on 1 machine without them conflicting?
[12:04:39] <cbreak> Lyberta: install them into different prefixes?
[12:04:47] <cbreak> that should work I think...
[12:05:07] <cbreak> I think they also have different suffixes sometimes, like gcc-5, gcc-6 and so on
[12:05:24] <cbreak> if you install them via a package manager, you should get that automatically
[12:06:38] <Lyberta> cbreak, I want to build a couple of SVN branches
[12:07:06] <cbreak> then a custom suffix or install prefix should do?
[12:07:31] <cbreak> I've never built gcc myself raw, but there should be ./configure flags for that if it's like other gnu projects
[12:07:37] *** proteusguy <proteusguy!~proteus-g@mx-ll-183.89.213-60.dynamic.3bb.co.th> has quit IRC (Remote host closed the connection)
[12:08:33] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[12:08:55] <sonOfRa> Lyberta: do you just want different versions, or the same version, but with different build options?
[12:09:35] <Lyberta> sonOfRa, I want modules branch and trunk which are both 9.0.0 right now
[12:09:48] *** multifractal <multifractal!~multifrac@194.73.87.179> has joined ##C++-general
[12:10:20] <sonOfRa> build them and install them to different prefixes, and then have a shell script that adjusts your paths between the two, I guess
[12:10:29] <sonOfRa> Gonna be a bit of manual work, obviously
[12:10:48] <Lyberta> sonOfRa, it looks like everything in /bin respects suffix but not /lib
[12:11:20] <Lyberta> sonOfRa, how can I uninstall my current build from ~/.local?
[12:11:34] <cbreak> make uninstall? :(
[12:12:19] <Lyberta> "the uninstall target is not supported in this tree" wow
[12:17:50] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Ping timeout: 250 seconds)
[12:18:37] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[12:23:31] *** shake <shake!~shake@cable-95-168-139-220.cust.telecolumbus.net> has joined ##C++-general
[12:24:41] *** proteusguy <proteusguy!~proteus-g@cm-58-10-154-246.revip7.asianet.co.th> has joined ##C++-general
[12:27:13] *** Starhowl <Starhowl!~Starhowl@p5787E63C.dip0.t-ipconnect.de> has joined ##C++-general
[12:29:58] *** alexge50 <alexge50!~alexge50@unaffiliated/alexge50> has quit IRC (Ping timeout: 250 seconds)
[12:34:42] *** tesuji <tesuji!~tesuji@unaffiliated/tesuji> has joined ##C++-general
[12:36:22] *** jan64 <jan64!~jan64@79.191.168.92.ipv4.supernova.orange.pl> has joined ##C++-general
[12:37:39] <quarterback> What do these compilation errors mean in Visual studio? http://codepad.org/bT0joCd6
[12:38:50] <quarterback> The source code compiles without warnings in MinGW G++ under C++11. The program compiles with warnings with Visual studio 2017 but execution is like a infinite loop without any result.
[12:40:13] <quarterback> The executable functions without errors when compiled with MinGW G++11
[12:41:20] <quarterback> I had used std::algorithm functions std::sort and std::transform in filename.cpp
[12:41:26] *** janco <janco!~janco@83-160-103-27.ip.xs4all.nl> has joined ##C++-general
[12:44:09] *** alexge50 <alexge50!~alexge50@unaffiliated/alexge50> has joined ##C++-general
[12:44:14] <quarterback> The program works without faults when compiled with MinGW G++ as ISO C++11 code.
[12:45:09] <cbreak> quarterback: int to char conversion is lossy
[12:48:10] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Ping timeout: 250 seconds)
[12:48:33] *** Zee- <Zee-!~Zee-@78.143.97.84> has joined ##C++-general
[12:48:34] <quarterback> cbreak, I will look where its occurring.
[12:48:44] <cbreak> it tells you
[12:50:50] <quarterback> cbreak, std::transform(Searchstring.begin(), Searchstring.end(), Searchstring.begin(), ::tolower); This is the line. I'm converting a string to all lowercase.
[12:51:00] <cbreak> tolower returns int
[12:51:50] <quarterback> I am ignoring the value returned by tolower. Is that the error?
[12:52:14] <cbreak> you don't ignore it
[12:52:28] <cbreak> you write it into Searchstring
[12:52:42] <quarterback> so, where is the fault?
[12:52:48] <cbreak> it's a warning
[12:52:54] <cbreak> you convert int to char
[12:52:58] <quarterback> How to fix this warning?
[12:53:01] <cbreak> and that's a lossy conversion
[12:53:07] <cbreak> force the conversion with a static_cast
[12:53:16] <cbreak> that should make the compiler shut up
[12:53:35] <quarterback> static_cast< signed int> ?
[12:56:47] <quarterback> What would be the correct syntax of that line if Searchstring is of type std::string?
[12:58:58] <cbreak> quarterback: you want char
[12:59:01] <cbreak> right?
[12:59:23] <quarterback> yes, std::string is of char type data.
[12:59:28] <cbreak> so cast to char
[12:59:35] <cbreak> instead of int
[13:00:08] <cbreak> ... [](char c) { return static_cast<char>(tolower(c)); })
[13:00:39] <Aleric> Anyone else ever felt the urge to recompile after making a huge change to the documentation (comments) in a file? %-).
[13:01:29] <quarterback> It is trying to convert int(int) to char - This is a error
[13:02:14] <quarterback> A simple tolower function would do instead of standard tolower
[13:02:33] *** proteusguy <proteusguy!~proteus-g@cm-58-10-154-246.revip7.asianet.co.th> has quit IRC (Ping timeout: 245 seconds)
[13:02:34] <cbreak> or do what I just gave you :)
[13:02:46] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[13:10:26] <quarterback> cbreak, Execution time is longer with executable produced in VC++ 2017 in C++14 compared to MinGW g++ C++11. What could be the reason?
[13:10:46] <cbreak> crapy optimization?
[13:10:57] <cbreak> run a profiler and find out
[13:12:50] <quarterback> It is like 30x longer in executable from VS.
[13:15:43] *** lh_ideapad <lh_ideapad!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has quit IRC (Ping timeout: 268 seconds)
[13:21:45] *** zap0 <zap0!~zap0@14-201-222-143.tpgi.com.au> has joined ##C++-general
[13:23:14] <quarterback> Amazing. Decryption algorithms take ages to compute with VC++ without any optimizations.
[13:23:17] <Lyberta> quarterback, debug build?
[13:24:00] <quarterback> Lyberta, The build completes without errors in VS but the executable is taking ages to get a result. With G++ it is superfast.
[13:24:16] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[13:24:24] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[13:24:47] <Lyberta> quarterback, if it is debug build maybe VC uses a lot of additional checks like safe iterators, etc
[13:25:14] <quarterback> Lyberta, Possibly. I'm not very familiar with all features of VC++ 2017 yet.
[13:27:14] *** TheSchaf <TheSchaf!~foobar@unaffiliated/theschaf> has joined ##C++-general
[13:27:49] <quarterback> Lyberta, It's also the same in release build too in VS.
[13:28:25] <Lyberta> quarterback, then I have no idea
[13:28:54] <quarterback> Lyberta, Maybe I can put the project on a git if you want to take a look.
[13:29:26] <quarterback> Lyberta, It has heavy algorithm processing with possibly a few million function calls.
[13:29:52] <Lyberta> quarterback, I don't have VC
[13:32:31] <cbreak> quarterback: don't bother benchmarking debug builds
[13:45:22] *** symm- <symm-!~symm-@95.65.81.202> has quit IRC (Ping timeout: 250 seconds)
[13:49:36] *** gulzar <gulzar!~gulzar@14.139.123.36> has quit IRC (Quit: Konversation terminated!)
[13:51:44] *** lh_ideapad <lh_ideapad!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has joined ##C++-general
[13:52:35] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined ##C++-general
[13:53:18] *** pulse <pulse!~pulse@unaffiliated/pulse> has joined ##C++-general
[13:55:22] *** BOKALDO <BOKALDO!~BOKALDO@46.109.200.222> has quit IRC (Quit: Leaving)
[13:55:31] *** hero100_ <hero100_!~hero100@113.92.159.49> has joined ##C++-general
[13:56:55] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[13:57:24] *** batman_nair <batman_nair!~batman_na@111.92.77.160> has quit IRC (Remote host closed the connection)
[14:06:47] <markand> I wonder if there is a way to mimic a very simple ECS pattern using std::any
[14:07:43] <markand> e.g. a common object entity used for both client and server and you attach components using std::any (like graphics UI and network socket server side)
[14:08:35] *** mlehmk <mlehmk!~ThomFox@unaffiliated/mlehmk> has joined ##C++-general
[14:10:43] *** treehug88 <treehug88!~textual@pool-98-113-184-194.nycmny.fios.verizon.net> has joined ##C++-general
[14:10:55] <ville> why std::any? that seems like overkill
[14:11:06] <markand> what instead? void*?
[14:11:07] *** symm- <symm-!~symm-@95.65.81.202> has joined ##C++-general
[14:11:38] <markand> std::any has the advantage of not requiring dynamic memory management AFAIK
[14:11:43] <ville> presumably the component zoo is closed?
[14:12:23] <markand> e.g. struct position {int x; int y;} will be cheaply copied into a std::any if possible
[14:13:38] <Latexi95> likely any struct larger than a pointer will be dynamically allocated. But std::any has quite lot of overhead even when no dynamic allocation is required
[14:13:52] <ville> since std::any can hold literally anything i am not sure how it's going to work with out dynamicaly allocated buffer
[14:14:18] <ville> you can do sbo but i don't think any interface lets you control that
[14:14:27] <ville> i mean the implementation can do
[14:14:53] <markand> ah
[14:15:12] *** Roughy <Roughy!~mdaw45ns@188.126.203.78> has quit IRC (Quit: Meadow Fresh milk)
[14:16:11] *** mlehmk <mlehmk!~ThomFox@unaffiliated/mlehmk> has quit IRC (Remote host closed the connection)
[14:16:16] <Aleric> Is it me or does this really not make any sense? https://wandbox.org/permlink/9Jp6WVK84wu5sKQt
[14:16:27] <Aleric> warning: 'E::f' hides overloaded virtual function [-Woverloaded-virtual]
[14:16:47] *** mlehmk <mlehmk!~ThomFox@gateway.buch-schule.de> has joined ##C++-general
[14:16:51] *** mlehmk <mlehmk!~ThomFox@gateway.buch-schule.de> has quit IRC (Remote host closed the connection)
[14:17:03] <Aleric> But whatever it "hides" is a final private method of it's base class :/ .. totally inaccessible to begin with.
[14:17:07] *** Ralsei <Ralsei!~AllegroVi@aefw138.neoplus.adsl.tpnet.pl> has joined ##C++-general
[14:17:12] <Aleric> I don't see the point of the warning?
[14:17:23] <markand> https://github.com/skypjack/entt looks interesting
[14:19:32] *** mlehmk <mlehmk!~ThomFox@gateway.buch-schule.de> has joined ##C++-general
[14:19:36] *** mlehmk <mlehmk!~ThomFox@gateway.buch-schule.de> has quit IRC (Changing host)
[14:19:36] *** mlehmk <mlehmk!~ThomFox@unaffiliated/mlehmk> has joined ##C++-general
[14:20:20] *** mlehmk <mlehmk!~ThomFox@unaffiliated/mlehmk> has quit IRC (Remote host closed the connection)
[14:20:25] <Aleric> Um, better version: https://wandbox.org/permlink/PRbDn4DEvqMJrs4r
[14:21:26] <Aleric> gcc is not complaining about this.
[14:22:47] <Aleric> Oh it is when I use -Woverloaded-virtual
[14:24:39] <ville> Aleric: it could be just bad diagnostic, but it still hides the B::f
[14:25:46] <ville> also if i recall right there could be something "surprising" when access specifiers are considered in the process
[14:26:48] *** janco_ <janco_!~janco@83-160-103-27.ip.xs4all.nl> has joined ##C++-general
[14:26:53] <ville> they may be applied late in the process of finding out the overload set, and functions that will end up inaccessible due to access specifier still makes it in?
[14:27:31] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined ##C++-general
[14:27:48] *** mlehmk <mlehmk!~ThomFox@unaffiliated/mlehmk> has joined ##C++-general
[14:27:56] <Aleric> I can call B::f() just fine: https://wandbox.org/permlink/b0rb3NzTsXoVRPQS
[14:28:56] <ville> yes if you qualify the name for exampe, but you can't just do "f()"
[14:29:09] <ville> (or cast shenanigans or...)
[14:29:12] *** janco <janco!~janco@83-160-103-27.ip.xs4all.nl> has quit IRC (Ping timeout: 272 seconds)
[14:29:12] <Aleric> I believe that access specifiers are never taken into account for stuff like this :/ .. might be for a reason.
[14:29:12] *** janco_ is now known as janco
[14:29:40] <Aleric> I couldn't just do f() anyway, cause then I'd get D::f() which is private.
[14:30:11] *** janco <janco!~janco@83-160-103-27.ip.xs4all.nl> has quit IRC (Client Quit)
[14:30:32] *** janco <janco!~janco@83-160-103-27.ip.xs4all.nl> has joined ##C++-general
[14:31:44] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC (Ping timeout: 250 seconds)
[14:32:30] *** rokups <rokups!uid197268@gateway/web/irccloud.com/x-ezkrhyoecsecasfn> has quit IRC (Quit: Connection closed for inactivity)
[14:33:22] *** proteusguy <proteusguy!~proteus-g@cm-58-10-154-246.revip7.asianet.co.th> has joined ##C++-general
[14:33:46] <Aleric> I'm starting to question to usefulness of -Woverloaded-virtual actually
[14:35:00] <Aleric> I think the warning is intended to catch mismatched argument types - ie, when a base class changes the arguments then you get a warning when compiling a derived class that wasn't also adjusted.
[14:35:20] <Aleric> But that derived class should use 'override' now - which then will give a warning anyway.
[14:36:28] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[14:37:02] *** zap0 <zap0!~zap0@14-201-222-143.tpgi.com.au> has quit IRC (Quit: zap0)
[14:40:41] *** HumanG33k <HumanG33k!~HumanG33k@62.147.242.8> has joined ##C++-general
[14:41:26] *** HumanG33k <HumanG33k!~HumanG33k@62.147.242.8> has quit IRC (Remote host closed the connection)
[14:41:30] *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC (Ping timeout: 252 seconds)
[14:41:54] *** HumanG33k <HumanG33k!~HumanG33k@62.147.242.8> has joined ##C++-general
[14:47:37] *** lh_ideapad <lh_ideapad!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has quit IRC (Remote host closed the connection)
[14:50:47] *** MrCrackPotBuilde <MrCrackPotBuilde!~MrCrackPo@161.142.89.253> has quit IRC (Ping timeout: 258 seconds)
[14:54:10] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[14:55:11] *** DatJohnny <DatJohnny!~johnny@89-74-252-30.dynamic.chello.pl> has joined ##C++-general
[14:56:47] *** DatJohnny <DatJohnny!~johnny@89-74-252-30.dynamic.chello.pl> has quit IRC (Client Quit)
[14:57:23] <ville> ban virtual functions. problem solved.
[14:58:31] <mlehmk> how would you do polymorphism then?
[14:58:46] <ville> some kind of tagged union?
[14:59:12] <mlehmk> and how would you extend it later?
[15:00:31] <ville> sort of depends what you want exactly
[15:01:59] <mlehmk> like quite simple, if a library provides an interface that it'll call and the implementation is provided by the consumer of the library
[15:02:07] *** irrenhaus3 <irrenhaus3!~xenon@ip-37-201-6-163.hsi13.unitymediagroup.de> has joined ##C++-general
[15:02:31] <mlehmk> a simple use case for polymorphism
[15:03:59] <shake> static polymorphism.. just use templates ;)
[15:04:17] <ville> but are the types of the library user known at compile time, if they are then switching over to a function template
[15:05:20] *** janco <janco!~janco@83-160-103-27.ip.xs4all.nl> has left ##C++-general
[15:05:35] <mlehmk> the types are known as interfaces. The implementations of them are only known at link time
[15:05:54] <mlehmk> or in worst case, program loading
[15:06:02] *** janco <janco!~janco@83-160-103-27.ip.xs4all.nl> has joined ##C++-general
[15:06:07] *** BOKALDO <BOKALDO!~BOKALDO@46.109.200.222> has joined ##C++-general
[15:06:09] <ville> yes it gets more interesting in case of runtime loading of "plugins"
[15:07:59] <ville> then you're probably looking at maintaining some kind of "vtable" of your own if you really wanted to not use virtual functions
[15:09:20] <ville> storage as well may have to be switched over to pointer-to-things rather than actual things. depends if you can't place a reasonable upperbound for example on the type sizes
[15:11:44] <mlehmk> I see not much difference between using virtual functions as syntactic sugar to maintaining vtables
[15:12:27] <velco> ah, there's much difference :)
[15:12:43] <velco> I've tried one to maintain vtable-like structs by hand
[15:12:46] <mlehmk> so, yes. use dicipline and prefer templates to implement static polymorphism to virtual functions then, instead of outright banning them
[15:12:47] <velco> it's major PITA
[15:13:53] <mlehmk> they could actually be even faster, as I heard once that polymorphism through tagged unions is faster
[15:14:21] <ville> mlehmk: i'd say there's difference, but hard to say if there is an advantage one way or the other, certainly very hard to make a general claim one way or the other.
[15:14:45] <ville> mlehmk: "ban virtual functions. problem solved" was a joke. thought the harshness of the solution compared to the cause, enabling a -W flag made it obvious
[15:16:09] <ville> mlehmk: why i would say there is a difference is that often times when you choose inheritance+virtuals the solution also then gravitates to storage model where you have pointer-to-things rather than things, which can be harmful in some cases
[15:17:02] *** alan_w <alan_w!~alan_w@75.78.166.8> has joined ##C++-general
[15:17:04] <mlehmk> I also don't like raw pointers in C++. You can use pointer wrappers with RAII semantics and references instead
[15:17:14] <ville> mlehmk: pointer there includes fancy pointers
[15:17:40] <ville> mlehmk: whether it's fancy or plain pointer to things doesn't affect the negative sides of the indirection involved
[15:19:43] <TheSchaf> std::fancy_ptr
[15:20:40] <ville> mlehmk: if you have time and interest louis dionne has https://www.youtube.com/watch?v=OtU51Ytfe04 looking at how c++'s implementation of these particular aspects "entangles" multiple concepts
[15:21:52] *** Unlimiter <Unlimiter!uid281704@gateway/web/irccloud.com/x-zqlzrqreuomtslxq> has joined ##C++-general
[15:22:17] *** manuelschneid3r <manuelschneid3r!~manuelsch@p200300E2472CC5005F20BF21368481E4.dip0.t-ipconnect.de> has joined ##C++-general
[15:25:09] *** janco <janco!~janco@83-160-103-27.ip.xs4all.nl> has quit IRC (Quit: janco)
[15:25:30] *** zeduckmaster <zeduckmaster!~zeduckmas@85.106.1.181> has quit IRC (Quit: Leaving)
[15:26:05] *** janco_ <janco_!~janco@83-160-103-27.ip.xs4all.nl> has joined ##C++-general
[15:30:09] *** janco_ is now known as janco
[15:32:07] *** ZaraFrax <ZaraFrax!~ZaraFrax@p200300D73BC6790091E293FA1CBF6AD3.dip0.t-ipconnect.de> has quit IRC (Read error: Connection reset by peer)
[15:38:06] *** solidfox <solidfox!~solidfox@unaffiliated/snake/x-2550465> has joined ##C++-general
[15:38:28] *** Arfed <Arfed!~Arf@unaffiliated/arfed> has joined ##C++-general
[15:39:06] <urdh> neat
[15:39:47] *** Arlen0 <Arlen0!~Arlen0@cpe-24-243-33-35.satx.res.rr.com> has joined ##C++-general
[15:39:54] *** Arlen0 <Arlen0!~Arlen0@cpe-24-243-33-35.satx.res.rr.com> has quit IRC (Remote host closed the connection)
[15:40:34] *** Ingersol <Ingersol!~Ingersol@host-static-93-116-234-146.moldtelecom.md> has joined ##C++-general
[15:40:55] <mlehmk> ville, anyway, what interests me is, how to create objects on heap without having pointers?
[15:42:33] <Arfed> I want to use a shared pointer to create/store an object on thread A, pass (using shared pointers) the object to thread B for a prolonged time, and pass (using shared pointers) to async tasks. When it comes time to clean up, thread A puts a request to thread B to clean up the object, then A must wait for thread B and all async tasks to clean up the object and all shared pointers. When
[15:42:33] <Arfed> thread A determines that the reference count for its shared pointer is == 1 (it is holding the last reference), it will then invalidate the shareed pointer, destroying the object. How safe a model is this, for sharing an objet between threads and managing its lifetime? Thanks.
[15:45:07] <ville> mlehmk: that seems like an odd requirement. what do you propose would act as a "handle" to them if not a pointer at some level?
[15:45:17] <mlehmk> is that rather a bit complicated?
[15:45:41] <mlehmk> Arfed, I assume you have a resource that needs to be destroyed on the same thread where it was acquired?
[15:46:14] <urdh> seems fragile
[15:47:01] <ville> Arfed: sharing anything seems like something to avoid. can't you copy/move it between the threads as needed?
[15:47:08] *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 250 seconds)
[15:49:01] *** tachoknight_ <tachoknight_!~tachoknig@205.178.20.7> has quit IRC (Remote host closed the connection)
[15:51:26] *** drumer306 <drumer306!~alldayeve@149.151.96.78> has joined ##C++-general
[15:54:56] *** tachoknight <tachoknight!~tachoknig@205.178.20.7> has joined ##C++-general
[15:55:10] <amosbird> Hm, why does nested lambda increase compile time exponentially
[15:55:43] <TheSchaf> why not!
[15:56:22] *** symm- <symm-!~symm-@95.65.81.202> has quit IRC (Quit: Leaving...)
[15:56:48] *** PJBoy <PJBoy!~PJBoy@unaffiliated/pjboy> has joined ##C++-general
[15:58:42] *** matrim <matrim!~mats_@83.243.153.252> has joined ##C++-general
[15:59:02] <cbreak> because people use "exponentially" too much.
[15:59:51] <TheSchaf> do they use it exponentially?
[15:59:54] *** xekz <xekz!~kexmex@unaffiliated/kexmex> has joined ##C++-general
[16:00:35] <TheSchaf> i've been in this channel to long, today someone wrote "blah is in O(minutes), not O(hours)"
[16:00:41] <TheSchaf> and i got upset inside
[16:00:44] <velco> amosbird, testcase? For which compiler?
[16:01:51] <amosbird> gcc, no minimal test cases. just asking for experiences
[16:06:22] <Arfed> mlehmk: Yes, I'm aiming to destroy it on same thread it was created - more for consistency than necessity - though it may indeed be necessary.
[16:07:15] *** 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:07:42] <urdh> amosbird: "why does ..." asks for explanations, not experiences
[16:07:44] <Arfed> ville: Ideally I would do that, but I'm having to retrofit an existing system with multithreading, with an existing object/class hierarchy that has to be maintained for now - before I rewrite it all later
[16:08:53] <urdh> Arfed: why do you have to share ownership with the other threads if the first thread has to wait for them anyway?
[16:09:21] <urdh> use some other primitive to synchronize the threads, and keep the object in a unique_ptr (or just a value type) in thread A
[16:09:57] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[16:10:05] <mlehmk> it looks like reference counting is an aspect
[16:10:26] <urdh> not really, from the description
[16:10:54] *** dadabidet <dadabidet!~dadabidet@choupi.libriciel.fr> has joined ##C++-general
[16:11:22] <mlehmk> I'd model a "worker"-thread with a message queue, that recieves create and destroy requests and return objects in wrappers with a reference count of 1. If the wrapper's reference count goes to 0, it'd enqueue a destroy request into that message queue for the single "worker"-thread to terminate the object
[16:11:37] <amosbird> urdh: I'm asking for explanations from experience
[16:12:13] <mlehmk> although that'd change it, so thread B will request creation of the resource from thread A, which is answered asynchronously
[16:13:36] *** Tazmain <Tazmain!~Tazmain@unaffiliated/tazmain> has quit IRC (Remote host closed the connection)
[16:14:23] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[16:14:32] <Arfed> urdh: The object will exist a long time, and be in regular use in the other threads - I am making thread A responsible for both creating/destroying the object though, for consistency, as I want that thread in control of the lifetime of the object. Ref counting is an aspect, yes.
[16:15:03] <urdh> no, you're _making_ reference counting an aspect, unneccesarily so
[16:15:08] <Arfed> mlehmk: The problem is not thread A and thread B's communication, but the async tasks which may hold a shared pointer to the object, and have a hard-to-determine lifetimee - so, your idea would work if not for the async tasks
[16:15:18] <urdh> you've said it yourself, thread A is responsible for the lifetime
[16:15:21] <mlehmk> actually the ref counter controls the lifetime of the object, thread A is just responsible for creation/destruction
[16:15:37] <urdh> thread A should therefore hold a unique_ptr, and not share ownership with other threads
[16:15:51] <mlehmk> that's an implementation detail
[16:16:11] <rpav> er .. that's a significant fundamental design decision usually
[16:16:29] <rpav> "how ownership works"
[16:16:31] <mlehmk> it can be a structure that holds a reference counter, response address and unique_ptr to the object
[16:16:45] <rpav> i think urdh is saying, no refcounting, unique_ptr only
[16:17:10] <mlehmk> then you have another structure that manages the reference counter, interlock and creating the message for thread A in case the reference counter reaches 0
[16:17:20] <rpav> (which is often possible to "rotate out" shared_ptr into separate-owning-entity plus non-owning refs)
[16:17:31] <Arfed> it's mainly the ref counter I need, not even the shared pointers, as there is no need to guard access to the object - I'm using the ref counter within shared pointers, just as it's a ready packaged container that allows me to do that
[16:17:49] <urdh> that's not what a shared_ptr it, but ok
[16:18:01] <mlehmk> except that my guess is that shared_ptr is not thread safe to use
[16:18:07] <urdh> if you _really_ need refcounting, I would take the approach mlehmk suggests
[16:18:09] <Arfed> it is
[16:18:17] <urdh> but I still don't see why you need refcounting
[16:18:34] <Arfed> refcounting is needed to let thread A know when it is safe to destroy
[16:18:39] <mlehmk> we can just assume that refcounting is required. It's just fine to use
[16:18:40] *** tesuji <tesuji!~tesuji@unaffiliated/tesuji> has quit IRC (Ping timeout: 246 seconds)
[16:18:53] <urdh> Arfed: shared_ptr is not "thread safe" in the general sense (it depends on which parts you expect to be thread safe)
[16:19:03] <Arfed> I expect the ref count to be thread safe. it is
[16:19:11] <Arfed> for my purposes it is thread safe
[16:19:46] <urdh> just making sure; it's a common pitfall
[16:19:53] <Arfed> cool
[16:20:02] *** alyptik <alyptik!ayy@cpe-76-173-133-37.hawaii.res.rr.com> has quit IRC (Ping timeout: 272 seconds)
[16:20:33] <mlehmk> thus rolling your own shared resource holder with interlocked reference counting
[16:21:23] <Arfed> ok I may as well cut the discussion short, before gets too muddied: it sounds like my model will work the way I want, albeit it is not optimal.
[16:21:34] <urdh> my main concern here is that using shared_ptr _implies_ shared ownership, whereas you actually don't have shared ownership
[16:22:19] <mlehmk> it actually will not
[16:22:44] <mlehmk> at least not with shared_ptr
[16:23:02] <Arfed> ok let me refactor my idea:
[16:23:46] <urdh> (it's still unclear to me why you need reference counting, because from the description it seems to me like thread A owns the resource _and_ decides when the other tasks must terminate; only _after_ telling them to terminate will thread A check the reference count, correct?)
[16:23:48] *** Starhowl <Starhowl!~Starhowl@p5787E63C.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
[16:25:06] <amosbird> hmm, it's in fact the "as" command that takes extremely longer
[16:25:11] <amosbird> 1 second -> 20 seconds
[16:25:24] <Arfed> lets say I put a thread safe ref counter into the object, shared the object (using normal pointer) among thread A/B + async tasks - every thread that gets a pointer to the object, stores it an increments the ref counter - decrementing when getting rid of the object. The object is guaranteed to exist for as long as thread B and async tasks need it. When thread A wants to destroy the object,
[16:25:24] <Arfed> it notifies thread B and waits for async tasks to be done with it, then when the objects reference count is 1, it destroys it
[16:25:32] <Arfed> gets rid of the shared pointer confusion
[16:25:54] <cbreak> Arfed: you seem terribly confused
[16:25:55] <Arfed> I need a reference count because I don't know how long async tasks may hold onto the objecct
[16:26:08] <Arfed> cbreak: be helpful/constructive
[16:26:16] <cbreak> just forget about the pointer, then it'll be destroyed when the ref count reaches 0
[16:26:22] *** tesuji <tesuji!~tesuji@unaffiliated/tesuji> has joined ##C++-general
[16:26:38] <Arfed> but it may be destroyed in an unknown thread - it's a complex object, I want it destroyed in thread A, where it was created
[16:26:48] <cbreak> why does it matter?
[16:27:03] <cbreak> put in a custom deleter
[16:27:16] <cbreak> that instead of destroying the object passes it to the main thread
[16:27:19] <urdh> Arfed: how does thread A wait for the async tasks to decrement the reference counter wanyway?
[16:27:53] *** Starhowl <Starhowl!~Starhowl@p5787E63C.dip0.t-ipconnect.de> has joined ##C++-general
[16:27:56] <Arfed> cbreak: that's just a different way of achieving the same goal
[16:28:00] <cbreak> Arfed: no
[16:28:17] <cbreak> you don't need to implement a ref counter
[16:28:24] <cbreak> just use std::shared_ptr :)
[16:28:38] <Arfed> urdh: thread A will be doing other stuff, and won't block waiting for the async tasks
[16:28:54] <Arfed> cbreak: I don't need the shred pointer guarding the object ptr, it is slow
[16:28:56] <urdh> and it will poll the reference counter?
[16:29:12] <cbreak> Arfed: apparently you do need a ref counter
[16:29:21] <cbreak> shared_ptr gives a ref counter
[16:29:30] <Arfed> urdh: after a time it will check the ref counter
[16:29:42] <Arfed> cbreak - I know
[16:29:45] <urdh> so yes, polling
[16:29:51] <cbreak> ref counting is slow.
[16:29:54] <Arfed> polling that is likely to occur only once
[16:30:07] <urdh> still polling, but ok
[16:30:12] <cbreak> you won't be able to make it faster than std::shared_ptr
[16:30:24] <cbreak> unless you can give up on thread safety
[16:30:29] <cbreak> which you probably can not.
[16:30:34] <Arfed> ref counting is not slow when done at select/few times (creates/destroy). having to access an object frequently that is guardded by a shared pointer, is slow
[16:30:54] <cbreak> Arfed: you seem confused some more :/
[16:31:04] <Arfed> cbreak: be constructive. that isn't helpful
[16:31:07] *** riksteri <riksteri!~SpaceDino@213.152.162.114> has joined ##C++-general
[16:31:09] <cbreak> shared_ptr ref counting ONLY happens on create / destroy / copy
[16:31:22] <cbreak> Arfed: think :D
[16:31:35] <Arfed> cbreak: I know.
[16:31:46] <cbreak> just because something's in a shared pointer that doesn't mean you can not pass refs around to it
[16:31:48] <Arfed> shared pointers will work. I just don't need to guard access
[16:31:58] <cbreak> you only need to create new shared pointers when you want to transfer / extend ownerships
[16:32:38] <Arfed> cbrek, I know shared pointers work - I deliberately shifted focus to ref counters, as that is the critical part of the shared pointers I need. you're pointing out what I already know, and muddying things
[16:32:58] <cbreak> the problem's solved efficiently.
[16:35:17] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Ping timeout: 244 seconds)
[16:40:33] *** rikster <rikster!~SpaceDino@62.102.148.130> has joined ##C++-general
[16:41:03] <mlehmk> shared pointers won't really work in this case
[16:41:47] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has joined ##C++-general
[16:41:49] <mlehmk> the problem if having multiple threads and such. What is required for a resource that can only be destroyed by the same thread that created it, is a thread that is dedicated to creating/destroying these resources
[16:41:53] *** dadabidet <dadabidet!~dadabidet@choupi.libriciel.fr> has quit IRC (Quit: Leaving)
[16:42:57] *** riksteri <riksteri!~SpaceDino@213.152.162.114> has quit IRC (Ping timeout: 252 seconds)
[16:43:08] <mlehmk> although, you might also have the problem, that those resources also tend to have methods that also need to be ran on that same thread and not by other threads
[16:44:10] <cbreak> it'll work as I explained above.
[16:44:21] <cbreak> (the destruction part)
[16:45:03] <mlehmk> if the destruction part properly marshals the destruction to be ran on thread A
[16:45:42] <mlehmk> which could just be a simple message posting to an event queue of the guarded object
[16:46:17] <mlehmk> and while doing that, you could also make a thread safe implementation of a shared_ptr for that
[16:46:43] <cbreak> shared_ptr should be sufficiently thread safe for this
[16:47:20] <Arfed> it's inefficient to notify of destroy on a message queue for the object, when loads of async tasks will be referencing and unreferencing it all the time
[16:47:25] <cbreak> as I said above, all you need is to add a custom deleter that gives the object to the destroying thread for destruction instead of doing it itself
[16:47:26] <cbreak> done.
[16:47:27] <mlehmk> I don't see how the word "sufficiently" even applies to a simple yes/no thing
[16:47:55] <cbreak> that will be much more efficient than what you'd implement yourself
[16:48:16] <cbreak> mlehmk: "shared_ptr is as thread safe as a normal pointer"
[16:48:39] <cbreak> for lifetime tracking, more is not needed
[16:48:45] <mlehmk> Arfed, I don't see how loads of async tasks reference counting would even affect the amount of destroy messages on the message queue
[16:49:01] <mlehmk> as there is only one of these messages per destruction
[16:49:16] *** Lord_of_Life_ <Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362> has joined ##C++-general
[16:49:55] <cbreak> Arfed: if one message per destruction is too expensive for you to afford, maybe you should give up on destroying them
[16:49:58] <Arfed> oh, got you. well, I would have to poll a message queue then. might as well just poll the reference counter - which will likely only be polled once, except in excpetional circumstances (which is fine)
[16:50:30] <cbreak> and it's obviously cheaper than polling reference counter
[16:50:42] <Arfed> polling a reference counter once is fine
[16:50:43] <cbreak> especially since you only have to check one queue
[16:50:56] <cbreak> and not millions of ref counters for all the objects
[16:51:28] <mlehmk> You don't have to poll the message queue, you just wait the message queue
[16:51:33] <Arfed> a message queue is added complexity. using the ref counter is fine - don't need to optimize further
[16:51:50] <cbreak> a message queue is also trivial
[16:52:03] <cbreak> it can be as simple as a vector containing pointers of objects to delete
[16:52:08] <Arfed> it is but it's even more trivial just to use the shared ptr I'm going tobe using anyway
[16:52:14] <cbreak> (naturally, with thread safety added)
[16:52:30] *** Lord_of_Life <Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362> has quit IRC (Ping timeout: 246 seconds)
[16:52:30] *** Lord_of_Life_ is now known as Lord_of_Life
[16:53:08] <Arfed> I may need the ability to wait on an object to be destroyed, in very exceptional circumstances, so a queue won't suffice
[16:53:56] <mlehmk> message queue doesn't replace the ref counter
[16:54:09] <mlehmk> message queue is to avoid polling the ref counter
[16:54:18] *** Zee- <Zee-!~Zee-@78.143.97.84> has quit IRC (Ping timeout: 250 seconds)
[16:54:36] *** Zee- <Zee-!~Zee-@78.143.97.84> has joined ##C++-general
[16:54:49] *** Haohmaru <Haohmaru!~Haohmaru@195.24.53.110> has quit IRC ()
[16:54:52] <Arfed> thread A marks an object to be destroyed, adds it to vector/array Garbage, waits a while then polls Garbage array ref counts and destroys as necessary. if it needs to block/wait on destroy (if a subsystem is being shut down, needing everything cleaned up), then it can use the Garbage array to block/wait for all destroys to be done. a queue can't do that
[16:55:38] <Arfed> it's not going to be happening often enough, for the cost of polling a refcount, to matter
[16:55:53] <cbreak> you just complained about polling a queue
[16:56:00] <cbreak> ref counters are much more expensive to poll
[16:56:45] <Arfed> you have to poll a queue all the time, because you don't know when a destroy request will come. you only poll a Garbage array with ref counts, when needed, when an object is pending destroy (i.e. rarely ever)
[16:58:01] <cbreak> you only need to check the garbage queue if you expect to need to destroy something.
[16:58:06] <urdh> to poll your Garbage array, you'd first need to check if there's aything in it
[16:58:20] <Arfed> ya that's fine - it's just a normal vector/array
[16:58:20] <urdh> that's the same thing as polling the garbage queue cbreak is proposing
[16:58:41] <Arfed> is there overhead checking a queue?
[16:58:47] <cbreak> what you save when you do what I propose is:
[16:58:54] <cbreak> you don't have to implement some custom ref counting scheme
[16:59:01] <Arfed> or is checking a queue just the same (perf wise) as checking a pointer?
[16:59:03] <cbreak> just using shared_ptr will be easier and more efficient
[16:59:10] <Arfed> I'm not planning a custom ref counting scheme, just shared ptr
[16:59:28] <urdh> "if queue.size() > 0" doesn't have more overhead than "for (x in garbage) { if (x.refcount == 1) }", at any rate
[16:59:30] <cbreak> and you don't have to check ref counters
[17:01:04] <Arfed> if (Garbage.Num() > 0) is less overhead than anything queue.something
[17:01:11] *** drumer306 <drumer306!~alldayeve@149.151.96.78> has quit IRC ()
[17:01:19] <cbreak> no
[17:01:59] <Arfed> I've had a look at the container queue I'd have to be using, and it seems to b
[17:02:01] <Arfed> be
[17:02:09] <urdh> what a stupid queue
[17:02:15] <urdh> fix it
[17:02:23] <cbreak> checking the number of objects to be destroyed can be as easy as comparing a single number value with 0
[17:03:11] <cbreak> that's obviously cheaper than checking a single number and then other numbers
[17:04:48] *** xekz <xekz!~kexmex@unaffiliated/kexmex> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[17:05:04] <Arfed> I think that all of this is going over details that don't come to much, performance wise, anyway - it's more a matter of style/architecture, for how to implement the solution to a solved problem
[17:05:32] <Arfed> thanks for the help clarifying my thoughts on this, and challenging the implementation
[17:05:37] *** Lyberta <Lyberta!~Lyberta@fsf/member/FaTony> has quit IRC (Remote host closed the connection)
[17:09:04] <mlehmk> also, the reason of reference counting is, so thread A is not initiating deletion, but thread B and the async tasks keep the object alive as long as they need it
[17:09:30] <mlehmk> the other way round would be rather confusing
[17:10:08] *** AbleBacon <AbleBacon!~AbleBacon@unaffiliated/ablebacon> has joined ##C++-general
[17:10:56] *** rajrajraj <rajrajraj!uid72176@gateway/web/irccloud.com/x-lxoqnfmijvtppsip> has quit IRC (Quit: Connection closed for inactivity)
[17:11:38] <urdh> Arfed: I disagree that this is "details that don't come to much"
[17:12:08] <urdh> it's often very important that they code conveys its intent properly to the reader
[17:12:35] <urdh> and checking if the reference count of a shared_ptr is 1 is going to look weird when you read it in five months
[17:13:08] <urdh> whereas constructing a shared_ptr whose deleter pushes the pointer to a queue called "destroy" or whatever more clearly conveys the intent
[17:13:29] <urdh> (e.g. "here's a pointer you can use; put it over there when you're all done with it")
[17:16:41] <Arfed> true, but I'm ok with just putting a comment where the refcount check occurs - it only happens in one well-defined place
[17:18:54] *** lh_mouse <lh_mouse!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has quit IRC (Read error: Connection reset by peer)
[17:19:14] *** biberu <biberu!~biberu@c83-251-152-254.bredband.comhem.se> has quit IRC ()
[17:21:49] *** ZaraFrax <ZaraFrax!~ZaraFrax@p200300D73BC67900344C52B2270E645A.dip0.t-ipconnect.de> has joined ##C++-general
[17:24:07] *** led_dark_1 <led_dark_1!~Thunderbi@hotspot10.rywasoft.net> has joined ##C++-general
[17:24:16] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[17:24:25] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[17:26:51] *** lilabsence <lilabsence!~RizzoTheR@host-091-097-135-113.ewe-ip-backbone.de> has joined ##C++-general
[17:27:03] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##C++-general
[17:28:32] *** alyptik <alyptik!ayy@cpe-76-173-133-37.hawaii.res.rr.com> has joined ##C++-general
[17:31:01] *** SirFancyPantsOfP <SirFancyPantsOfP!~SirFancyP@37.186.119.154> has quit IRC (Ping timeout: 258 seconds)
[17:32:01] *** SirFancyPantsOfP <SirFancyPantsOfP!~SirFancyP@37.186.119.154> has joined ##C++-general
[17:34:27] *** renn0xtk9 <renn0xtk9!~max@2a02:8070:a19d:2500:41e6:6a4:c56b:a682> has joined ##C++-general
[17:35:34] *** biberu <biberu!~biberu@c83-251-152-254.bredband.comhem.se> has joined ##C++-general
[17:35:42] *** hero100_ <hero100_!~hero100@113.92.159.49> has quit IRC ()
[17:36:40] *** janco <janco!~janco@83-160-103-27.ip.xs4all.nl> has quit IRC (Quit: janco)
[17:37:45] *** Lyberta <Lyberta!~Lyberta@fsf/member/FaTony> has joined ##C++-general
[17:38:19] *** Zee- <Zee-!~Zee-@78.143.97.84> has quit IRC (Ping timeout: 244 seconds)
[17:39:11] <Lyberta> I want to write a cross-platform wrapper around OS specific API, I figured out that the best way is to put all OS-specific code into a separate file and class for each OS but how would I link it to public interface?
[17:41:07] *** Unlimiter <Unlimiter!uid281704@gateway/web/irccloud.com/x-zqlzrqreuomtslxq> has quit IRC (Quit: Connection closed for inactivity)
[17:44:05] <shake> What do you mean with link? Just make sure that when you #include <bla> on [OS], it points to [OS]/bla.hxx. And when you compile the lib/executable on [OS] that it compiles [OS]/bla.cxx. You only have to make sure that each OS-specific implementation adheres to the same standardized API design
[17:46:11] <Lyberta> shake, hmm, header magic is not something I had in mind
[17:47:21] <shake> Thats not at all magic, I guess. Can be as simple as using different header search paths.
[17:48:36] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[17:49:12] <shake> The actual mechanisms vary a bit depending on your build system. It'd probably be a one-liner in a CMake, for example
[17:50:33] <Lyberta> shake, hmm, I think I could instead rely on inline namespaces and hide an import behind a small macro, that way I won't need to have build system involved
[17:51:19] <shake> Talking about header magic ;)
[17:51:58] <shake> Sure, that's also possible.
[17:53:33] <mlehmk> I see the more problematic point in thread A trying to communicate a wanted object destruction to thread B
[17:53:35] <shake> So you have #include PLATFORM_HEADER(bla) and using PLATFORM::bla; in a "public" header
[17:54:25] *** Forsaken87 <Forsaken87!~quassel@2a02:908:1869:4b20:f4b0:188b:cefd:b063> has joined ##C++-general
[17:55:13] <shake> Even though I kind of advise against this pattern... I did that before and it is messy. Especially since implicit dependency scanners tend to bail out with it
[17:56:32] <shake> Anyway, you still need to do something with the build system in order to get it to compile the right implementation unless you want it to be header-only
[17:56:51] <shake> And even then you probably need to link against different libraries, etc.
[17:57:05] <Lyberta> shake, I mean I can always surround Os-specific code in header-wide #ifdef
[17:57:55] <shake> Yes, that's probably the classic way to deal with this
[17:58:39] *** trittweiler <trittweiler!~trittweil@217.194.50.132> has joined ##C++-general
[17:59:25] <Lyberta> shake, I'm really ashamed of current preprocessor mess: https://gitlab.com/ftz/platform/blob/master/Src/Library.cpp
[18:00:36] *** biberu\ <biberu\!~biberu@host-95-195-194-159.mobileonline.telia.com> has joined ##C++-general
[18:02:58] *** biberu <biberu!~biberu@c83-251-152-254.bredband.comhem.se> has quit IRC (Ping timeout: 246 seconds)
[18:03:48] *** trittweiler <trittweiler!~trittweil@217.194.50.132> has quit IRC (Ping timeout: 245 seconds)
[18:03:56] <shake> I agree that this is not elegant. And it becomes really messy when the number of platforms increases.
[18:05:07] <Lyberta> shake, though I feel like doing something similar to pimpl to have clean header and doxygen documentation from it
[18:08:15] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has quit IRC (Quit: Leaving)
[18:08:52] <shake> well, I am not a big fan of pimpl for hiding platform-specifics. Especially since you may want to enable access to the native types/handles (e.g. get the library handle). But that's a matter of taste, I guess.
[18:08:55] *** dzejrou <dzejrou!dzejrou@nat/suse/x-nixfsxzsapnnbmfg> has quit IRC (Quit: WeeChat 2.2)
[18:09:14] <ville> Lyberta: did you consider separate platform specific linux_header.hxx, windows_header.hxx that implement the actual things and then the a user-facing header.hxx that users of the library use. few alternatives in what ends up in the header.hxx.
[18:10:10] <ville> Lyberta: the header.hxx can be generated by your build system each time you build your library for a specific platform. it can essentially be a copy of the platform-specific header
[18:10:15] <Lyberta> ville, this is exactly what I'm talking about
[18:11:13] <ville> Lyberta: or if you're header-only then you can look at something like: #ifndef XXX_PLATFORM_LINUX #include "linux_heaader.hxx"... in the user-facing header.hxx
[18:11:17] <Lyberta> ville, but I'm trying not to do magic with build system, I feel like generating files during build would complicate the process a lot
[18:11:45] <shake> ville: Pretty close to what I initially suggested. However for some reason he is hesitant to touch the build system for this ;)
[18:12:05] <shake> Lyberta: but you are aware that there has to be some mechanism that you call "magic" *somewhere*?
[18:12:26] <ville> Lyberta: further you can try to detect in header.hxx what platform the user is on to automatically define the XXX_PLATFORM_LINUX offering the user the chance to provide the define before including header.hxx
[18:12:44] <ville> Lyberta: copying a file is hardly magic
[18:13:42] <Lyberta> shake, I'm thinking of having proxy objects that dispatch everything to implementation and implementation is chosen via "using namespace" inside a macro
[18:14:16] *** biberu\ <biberu\!~biberu@host-95-195-194-159.mobileonline.telia.com> has quit IRC ()
[18:14:20] <ville> you don't need pimpl. it just forces you to write unnecessary boilerplate
[18:18:48] *** quarterback <quarterback!~quarterba@160.238.73.156> has joined ##C++-general
[18:18:48] *** quarterback <quarterback!~quarterba@160.238.73.156> has quit IRC (Changing host)
[18:18:48] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has joined ##C++-general
[18:19:53] <Lyberta> ville, hmm, if I don't use proxy objects I'd need to copy-paste documentation to all implementations or use some insane text processing magic
[18:21:08] *** mlehmk <mlehmk!~ThomFox@unaffiliated/mlehmk> has quit IRC (Remote host closed the connection)
[18:25:24] <shake> Lyberta: FWIW, I had to deal with that problem and I ended up having documenting headers for "concepts" (i.e. I just wrote the headers to formalize concepts but they were never included anywhere).
[18:25:57] <Lyberta> shake, no doxygen?
[18:25:59] <shake> Then I simply put an \implements concepts::bla for each implementation in the doxygen header
[18:26:11] <shake> Sure, the project uses doxygen
[18:27:01] <shake> The good thing is that you can actually document the specifics for a platform there. But the generic conceptual interface is in common "pseudo" headers
[18:27:02] *** V-ille <V-ille!~vivoutil@192.89.120.53> has quit IRC (Ping timeout: 250 seconds)
[18:28:01] <Lyberta> shake, have a link to resulting html?
[18:28:18] <shake> It adds a bit of boilerplate for documentation but if it needs to be precise that's probably a good way to deal with this - at least I still think that
[18:28:42] <shake> No it's proprietary and belongs to my employer, sorry.
[18:29:09] <shake> But you can easily setup a toy project with this approach
[18:29:29] <shake> Just have a separate "doc/include" or whatever and put some header files in there, tell doxygen to scan that directory and you are set
[18:31:05] <shake> It will look like the platform specific types "derive" from the concept classes and that's actually fine with me (even though technically it's not really correct). However, it allows for easily navigating between concept and actual implementations of that concept
[18:33:36] *** multifractal <multifractal!~multifrac@194.73.87.179> has quit IRC (Ping timeout: 244 seconds)
[18:36:00] <Necktwi> please look into
[18:36:01] <Necktwi> RPi1B2:workspace Necktwi$ pump distcc --verbose gcc -c distcc-test.c -o distcc-test.o 2>&1 | wgetpaste -u
[18:36:05] <Necktwi> http://tinyurl.com/yahge3fm
[18:36:12] <Necktwi> GentooVM:~ Necktwi$ wgetpaste -u /var/log/distcc/distccd.log
[18:36:12] <Necktwi> http://tinyurl.com/ybcyfu5n
[18:37:54] *** krystcich <krystcich!~krystcich@088156132010.dynamic-ww-04.vectranet.pl> has joined ##C++-general
[18:39:34] <ville> Lyberta: for the case where you would copy a linux_header.hxx as the user-facing header.hxx you can switch to having an additional file which just declares and documents the things
[18:40:11] <ville> Lyberta: so rather than simply copy, you'd write the header with the declarations+documentation in first, then the contents of the linux_header.hxx
[18:42:27] <Lyberta> ville, but then it's harder to keep docs in sync, tradeoffs, tradeoffs, gotta think
[18:44:04] <ville> how is it harder to keep documentation in sync? presumably your documentation in the user-facing header is meant to document only public things not platform-implementation-specific things
[18:44:06] *** V-ille <V-ille!~vivoutil@85-23-140-45.bb.dnainternet.fi> has joined ##C++-general
[18:44:35] <ville> the declaration+documentation header snippet is the same for every build of your library
[18:44:54] *** batman_nair <batman_nair!~batman_na@111.92.77.160> has joined ##C++-general
[18:45:22] <Lyberta> ville, I usually update documentation after I change API, if they are in different files, the chance of me forgetting to update is higher
[18:54:07] *** mandeep <mandeep!mandeep@gateway/vpn/privateinternetaccess/mandeepb> has joined ##C++-general
[18:55:05] *** Arfed <Arfed!~Arf@unaffiliated/arfed> has quit IRC ()
[18:55:38] *** XCE <XCE!~XCE@104-3-184-7.lightspeed.sntcca.sbcglobal.net> has joined ##C++-general
[18:55:41] *** goiko <goiko!~goiko@unaffiliated/goiko> has quit IRC (Ping timeout: 246 seconds)
[18:55:54] *** vdamewood <vdamewood!~vdamewood@unaffiliated/vdamewood> has joined ##C++-general
[18:56:09] *** Serpent7776 <Serpent7776!~Serpent77@90-156-31-193.internetia.net.pl> has joined ##C++-general
[18:59:47] *** goiko <goiko!~goiko@unaffiliated/goiko> has joined ##C++-general
[19:01:17] *** mandeep <mandeep!mandeep@gateway/vpn/privateinternetaccess/mandeepb> has quit IRC (Remote host closed the connection)
[19:02:38] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has joined ##C++-general
[19:05:15] *** gelignite <gelignite!~gelignite@55d4fd5d.access.ecotel.net> has joined ##C++-general
[19:05:58] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has quit IRC (Remote host closed the connection)
[19:09:26] *** manuelschneid3r <manuelschneid3r!~manuelsch@p200300E2472CC5005F20BF21368481E4.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 260 seconds)
[19:14:35] *** shake <shake!~shake@cable-95-168-139-220.cust.telecolumbus.net> has quit IRC (Ping timeout: 246 seconds)
[19:16:58] *** shake <shake!~shake@cable-95-168-139-220.cust.telecolumbus.net> has joined ##C++-general
[19:19:45] *** irrenhaus3 <irrenhaus3!~xenon@ip-37-201-6-163.hsi13.unitymediagroup.de> has quit IRC (Read error: Connection reset by peer)
[19:20:44] *** irrenhaus3 <irrenhaus3!~xenon@ip-37-201-6-163.hsi13.unitymediagroup.de> has joined ##C++-general
[19:22:50] *** seni <seni!~Nimitz14@cpc91218-cmbg18-2-0-cust107.5-4.cable.virginm.net> has joined ##C++-general
[19:23:15] *** bigpet <bigpet!uid25664@gateway/web/irccloud.com/x-jmmqxlkrfrszeyjv> has quit IRC (Quit: Connection closed for inactivity)
[19:25:54] <seni> if I multiply two uint8 values with each other and want to represent the new value with int32, how do I do that? for `uint8_t a,b;` would it be (int32_t(a) * int32_t(b)) ? or is there a better way?
[19:27:08] <velco> just multiply them, they are promoted to int and the expression types is int (which is likely the same as int32_t)
[19:27:24] <quarterback> Type cast each uint8 type into a int32 type. Then it would be safe to multiply.
[19:28:03] <quarterback> seni, You seem to do it right.
[19:28:32] <seni> okay thank you!
[19:28:36] <velco> "(int32_t(a) * int32_t(b))" is correct
[19:29:21] <velco> though verbose and redundant; anyway it's generally good to not have implicit casts
[19:29:33] <velco> s/casts/conversions/
[19:35:33] *** wildlander <wildlander!~wildlande@unaffiliated/wildlander> has joined ##C++-general
[19:36:43] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has joined ##C++-general
[19:36:50] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has quit IRC (Max SendQ exceeded)
[19:37:31] <Lyberta> seni, unless you care about platforms with 16 bit ints (still supported by the standard) you don't need casts
[19:38:23] <Lyberta> wait, multiplication of 2 uint8 can't yield result that won't fin into 16 bit, so no need for cast at all
[19:38:28] <Lyberta> fit*
[19:39:19] <Lyberta> hm... singed 16 bit int won't fit... ok then cast on 16 bit platforms
[19:39:26] *** kallesbar <kallesbar!~kallesbar@46.246.105.19> has quit IRC (Quit: Konversation terminated!)
[19:44:42] *** velco <velco!chill@nat/arm/x-twcubgtdpdfunlor> has quit IRC (Quit: Leaving)
[19:46:57] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has quit IRC (Quit: Konversation terminated!)
[19:48:20] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[19:51:14] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined ##C++-general
[19:55:26] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Ping timeout: 250 seconds)
[19:55:45] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC (Ping timeout: 244 seconds)
[19:56:23] *** rikster <rikster!~SpaceDino@62.102.148.130> has quit IRC (Read error: Connection reset by peer)
[20:01:22] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[20:04:33] *** darnir <darnir!~darnir@go7box.xyz> has quit IRC (Read error: Connection reset by peer)
[20:15:39] *** Necktwi <Necktwi!~necktwi@175.101.146.135> has quit IRC (Quit: leaving)
[20:17:32] *** longxia <longxia!~irc@unaffiliated/longxia> has joined ##C++-general
[20:21:46] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[20:23:51] *** Starhowl_ <Starhowl_!~Starhowl@p5787e63c.dip0.t-ipconnect.de> has joined ##C++-general
[20:24:15] *** nshire <nshire!~nealshire@unaffiliated/nealshire> has joined ##C++-general
[20:24:33] *** tane <tane!~tane@dslb-178-011-228-154.178.011.pools.vodafone-ip.de> has joined ##C++-general
[20:26:09] *** Starhowl <Starhowl!~Starhowl@p5787E63C.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 268 seconds)
[20:26:24] *** piraye <piraye!~sevilay@176.41.255.178> has joined ##C++-general
[20:32:00] *** manuelschneid3r <manuelschneid3r!~manuelsch@p200300E2472CC5005F20BF21368481E4.dip0.t-ipconnect.de> has joined ##C++-general
[20:32:49] *** multifractal <multifractal!~multifrac@host-92-13-55-184.as43234.net> has joined ##C++-general
[20:33:37] *** Unarelith_ <Unarelith_!~Quent4234@static-176-158-117-112.ftth.abo.bbox.fr> has joined ##C++-general
[20:35:54] *** multifractal <multifractal!~multifrac@host-92-13-55-184.as43234.net> has quit IRC (Remote host closed the connection)
[20:36:32] *** Unarelith <Unarelith!~Quent4234@static-176-158-117-112.ftth.abo.bbox.fr> has quit IRC (Ping timeout: 272 seconds)
[20:39:19] *** Starhowl_ <Starhowl_!~Starhowl@p5787e63c.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
[20:40:25] <cbreak> Lyberta: 16 bit int platforms are quite common :)
[20:40:43] <cbreak> in micro controllers like those used on arduinos for example
[20:41:01] <cbreak> it'd suck if those weren't supported anymore ;)
[20:41:40] *** Starhowl <Starhowl!~Starhowl@p5787e63c.dip0.t-ipconnect.de> has joined ##C++-general
[20:56:45] *** ravi__ <ravi__!~ravi@2a02:908:698:68a0:7992:26ad:dd7d:9d32> has joined ##C++-general
[20:57:34] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[20:59:36] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has quit IRC (Read error: Connection reset by peer)
[20:59:48] *** symm- <symm-!~symm-@95.65.81.202> has joined ##C++-general
[21:03:15] *** serviscope_minor <serviscope_minor!~Telequipm@88.97.56.26> has joined ##C++-general
[21:03:30] *** matrim <matrim!~mats_@83.243.153.252> has quit IRC (Remote host closed the connection)
[21:06:10] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[21:06:40] *** Unarelith_ <Unarelith_!~Quent4234@static-176-158-117-112.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection)
[21:09:45] *** jan64 <jan64!~jan64@79.191.168.92.ipv4.supernova.orange.pl> has quit IRC (Read error: Connection reset by peer)
[21:09:47] *** Ralsei <Ralsei!~AllegroVi@aefw138.neoplus.adsl.tpnet.pl> has quit IRC (Ping timeout: 240 seconds)
[21:10:03] *** jan64 <jan64!~jan64@79.191.168.92.ipv4.supernova.orange.pl> has joined ##C++-general
[21:21:45] *** FroggyC <FroggyC!~claudio@141.ip-51-255-174.eu> has left ##C++-general ("WeeChat 2.3")
[21:24:17] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[21:24:25] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[21:28:46] *** serviscope_minor <serviscope_minor!~Telequipm@88.97.56.26> has quit IRC (Ping timeout: 246 seconds)
[21:30:09] *** immibis <immibis!~immibis@125-238-72-168-fibre.sparkbb.co.nz> has joined ##C++-general
[21:35:54] *** darnir <darnir!~darnir@go7box.xyz> has joined ##C++-general
[21:37:28] *** batman_nair <batman_nair!~batman_na@111.92.77.160> has quit IRC (Remote host closed the connection)
[21:37:31] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has quit IRC (Quit: Leaving)
[21:39:02] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined ##C++-general
[21:43:38] *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC (Ping timeout: 258 seconds)
[21:51:39] *** v1c7 <v1c7!~v1c7@112.79.137.9> has joined ##C++-general
[21:53:50] *** PJBoy <PJBoy!~PJBoy@unaffiliated/pjboy> has quit IRC (Ping timeout: 246 seconds)
[21:54:20] *** immibis <immibis!~immibis@125-238-72-168-fibre.sparkbb.co.nz> has quit IRC (Ping timeout: 268 seconds)
[21:55:05] *** SirFancyPantsOfP <SirFancyPantsOfP!~SirFancyP@37.186.119.154> has quit IRC (Read error: Connection reset by peer)
[21:59:06] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[22:00:19] *** ravi__ <ravi__!~ravi@2a02:908:698:68a0:7992:26ad:dd7d:9d32> has quit IRC (Remote host closed the connection)
[22:00:41] *** davr0s <davr0s!~textual@host109-155-88-203.range109-155.btcentralplus.com> has joined ##C++-general
[22:03:37] *** marcofe <marcofe!~marcofe@5.102.4.13> has joined ##C++-general
[22:10:15] *** manuelschneid3r <manuelschneid3r!~manuelsch@p200300E2472CC5005F20BF21368481E4.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 264 seconds)
[22:16:59] *** v1c7 <v1c7!~v1c7@112.79.137.9> has left ##C++-general ("Leaving")
[22:17:50] *** longxia <longxia!~irc@unaffiliated/longxia> has quit IRC (Quit: leaving)
[22:18:36] *** serviscope_minor <serviscope_minor!~Telequipm@88.97.56.26> has joined ##C++-general
[22:25:48] *** serviscope_minor <serviscope_minor!~Telequipm@88.97.56.26> has quit IRC (Ping timeout: 250 seconds)
[22:28:38] *** gelignite <gelignite!~gelignite@55d4fd5d.access.ecotel.net> has quit IRC (Quit: Good fight, good night!)
[22:31:07] *** Starhowl <Starhowl!~Starhowl@p5787e63c.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
[22:36:11] *** Roughy <Roughy!~mdaw45ns@188.126.203.78> has joined ##C++-general
[22:36:55] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)
[22:37:32] *** m_ben <m_ben!~m_ben@unaffiliated/m-ben/x-5917362> has joined ##C++-general
[22:43:51] *** piraye <piraye!~sevilay@176.41.255.178> has quit IRC (Quit: Leaving)
[22:47:23] *** serviscope_minor <serviscope_minor!~Telequipm@88.97.56.26> has joined ##C++-general
[22:51:16] *** Serpent7776 <Serpent7776!~Serpent77@90-156-31-193.internetia.net.pl> has quit IRC (Quit: leaving)
[22:57:14] *** Codaraxis_ <Codaraxis_!~Codaraxis@142.196.31.53> has quit IRC (Ping timeout: 258 seconds)
[22:57:46] *** Unarelith <Unarelith!~Quent4234@static-176-158-117-112.ftth.abo.bbox.fr> has joined ##C++-general
[23:00:06] *** BOKALDO <BOKALDO!~BOKALDO@46.109.200.222> has quit IRC (Quit: Leaving)
[23:00:27] *** Codaraxis <Codaraxis!~Codaraxis@142.196.31.53> has joined ##C++-general
[23:04:41] *** marcofe <marcofe!~marcofe@5.102.4.13> has quit IRC (Quit: Konversation terminated!)
[23:05:40] *** symm- <symm-!~symm-@95.65.81.202> has quit IRC (Ping timeout: 250 seconds)
[23:09:08] *** m_ben <m_ben!~m_ben@unaffiliated/m-ben/x-5917362> has quit IRC (Quit: WeeChat 2.3)
[23:21:06] *** ExoUNX <ExoUNX!~ExoUNX@unaffiliated/exounx> has quit IRC (Quit: later fam...)
[23:38:23] *** renn0xtk9 <renn0xtk9!~max@2a02:8070:a19d:2500:41e6:6a4:c56b:a682> has quit IRC (Quit: Konversation terminated!)
[23:39:17] *** tane <tane!~tane@dslb-178-011-228-154.178.011.pools.vodafone-ip.de> has quit IRC (Quit: Leaving)
[23:40:46] *** alyptik <alyptik!ayy@cpe-76-173-133-37.hawaii.res.rr.com> has quit IRC (Ping timeout: 250 seconds)
[23:52:05] *** symm- <symm-!~symm-@95.65.81.202> has joined ##C++-general
[23:59:29] *** jan64_ <jan64_!~jan64@79.191.160.221.ipv4.supernova.orange.pl> has joined ##C++-general
top

   January 7, 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 | >