#bitfighter IRC Log

IRC Log for 2015-08-31

Timestamps are in GMT/BST.

00:10:01 DiannaAgron Quit (Quit: Leaving)
00:10:49 Flynn Quit (Quit: This computer has gone to sleep)
00:25:26 Nothing_Much has joined
01:35:37 Nothing_Much Quit (Quit: Leaving)
03:32:47 Darrel Quit (Read error: Connection reset by peer)
03:40:45 LordDVG Quit (Remote host closed the connection)
03:50:18 Darrel has joined
05:18:07 koda has joined
05:27:53 Darrel Quit (Ping timeout: 272 seconds)
05:28:14 Darrel has joined
06:02:58 koda Quit (Ping timeout: 260 seconds)
06:04:33 koda has joined
06:56:33 kodabb has joined
06:57:18 koda Quit (Ping timeout: 244 seconds)
06:59:07 koda has joined
07:01:18 kodabb Quit (Ping timeout: 260 seconds)
07:05:02 koda Quit (Ping timeout: 260 seconds)
07:08:15 koda has joined
07:13:16 kodabb has joined
07:14:23 koda Quit (Ping timeout: 244 seconds)
07:14:23 kodabb is now known as koda
07:17:01 kodabb has joined
07:20:02 koda Quit (Ping timeout: 264 seconds)
07:20:19 kodabb is now known as koda
07:24:15 kodabb has joined
07:26:53 kodabb_ has joined
07:27:07 koda Quit (Ping timeout: 250 seconds)
07:29:12 kodabb Quit (Ping timeout: 268 seconds)
07:29:30 koda has joined
07:31:40 kodabb_ Quit (Ping timeout: 268 seconds)
07:33:56 kodabb has joined
07:35:22 koda Quit (Ping timeout: 268 seconds)
07:35:22 kodabb is now known as koda
07:41:29 kodabb has joined
07:44:14 koda Quit (Ping timeout: 260 seconds)
07:44:14 kodabb is now known as koda
09:27:23 Nothing_Much has joined
10:29:00 Nothing_Much Quit (Remote host closed the connection)
12:28:30 kodabb has joined
12:30:13 koda Quit (Ping timeout: 240 seconds)
12:31:11 Nothing_Much has joined
12:32:09 koda has joined
12:33:08 kodabb Quit (Ping timeout: 252 seconds)
12:34:53 kodabb has joined
12:37:32 koda Quit (Ping timeout: 252 seconds)
12:37:46 kodabb_ has joined
12:40:05 Nothing_Much Quit (Quit: Leaving)
12:40:06 kodabb Quit (Ping timeout: 252 seconds)
12:40:20 Nothing_Much has joined
12:41:02 koda has joined
12:43:24 kodabb_ Quit (Ping timeout: 252 seconds)
12:43:42 kodabb has joined
12:45:44 koda Quit (Ping timeout: 250 seconds)
12:48:01 koda has joined
12:49:12 kodabb Quit (Ping timeout: 250 seconds)
12:53:02 kodabb has joined
12:55:01 koda Quit (Ping timeout: 272 seconds)
12:56:23 koda has joined
12:58:13 kodabb Quit (Ping timeout: 240 seconds)
12:59:16 watusimoto has joined
12:59:16 ChanServ sets mode +o
13:43:37 Nothing_Much Quit (Remote host closed the connection)
13:45:57 Nothing_Much has joined
13:46:16 Nothing_Much Quit (Read error: Connection reset by peer)
13:47:12 Nothing_Much has joined
15:05:57 Nothing_Much Quit (Remote host closed the connection)
15:26:03 koda Quit (Quit: koda)
17:20:55 fordcars has joined
18:20:24 koda has joined
19:51:29 DiannaAgron has joined
20:47:14 DiannaAgron Quit (Read error: Connection reset by peer)
20:54:03 DiannaAgron has joined
21:09:39 koda Quit (Quit: koda)
21:19:37 raptor has joined
21:19:37 ChanServ sets mode +o
21:22:14 raptor good day!
21:55:46 watusimoto Quit (Quit: Leaving.)
22:26:31 fprdcars has joined
22:27:06 fordcars Hi!
22:27:12 fordcars Didn
22:27:17 fprdcars Quit (Client Quit)
22:27:20 fordcars Oops
22:27:23 raptor hi
22:27:58 fordcars Hey raptor, if you have a pointer pointing to an object, and that object dies (gets destroyed), that pointer is null, right?
22:28:10 raptor nope!
22:28:15 raptor that's the fun of c
22:28:17 fordcars Hah!
22:28:26 raptor it still points to the same memory address
22:28:56 fordcars So how do you check if it is still valid?
22:29:03 raptor so when accessed again, aftter the object is destroyed, then it may call up some random chunk of memory and mess everything all up
22:29:07 raptor ah ha
22:29:12 fordcars Haha
22:29:15 fordcars Ok
22:29:27 raptor to address this issue, you use what's called a safe pointer
22:29:48 raptor or a 'smart pointer'
22:29:52 fordcars Oooo this
22:30:04 fordcars Yes I used one somewhere
22:30:06 raptor they keep track of the object and when it is destroyed, they set themselves to NULL
22:30:27 fordcars But I didn't use one this time because I thought I didn't need to for a const pointer
22:30:33 fordcars Uh, pointer to a const
22:31:05 raptor if you're not writing really tiny code and are pressed for memory or performance, the standard thing to do is always use a smart pointer
22:31:26 fordcars Okok
22:31:40 raptor if you're coding in c++11, then I think there's a standard one to use
22:31:56 fordcars Yeah, std::pointerss
22:32:02 fordcars But I am not sure wich one to take
22:32:04 raptor like this one:  http://en.cppreference.com/w/cpp/memory/shared_ptr
22:32:24 fordcars const Class *instance; is my pointer
22:32:42 fordcars Oh I guess it would be shared
22:32:53 raptor if you only access the object through *one* pointer, then use std::unique_ptr
22:32:57 fordcars Oh
22:33:08 fordcars But I don't want to ever delete this object by this pointer
22:33:16 fordcars It must be read only
22:33:24 raptor the pointer or object?
22:33:28 fordcars The object
22:33:38 fordcars The object is stored in a map
22:33:47 fordcars And the pointer is a const pointer pointing to it
22:33:52 fordcars For read-only
22:34:05 raptor const can be applied to both the object and the pointer
22:34:49 raptor if you don't ever want it destroyed, then perhaps you should make it a static object and just provide access to it via some method
22:36:15 fordcars Sorry it must only be destroyed by the map
22:36:45 fordcars But not by the pointer
22:36:52 raptor map<shared_ptr<Class> > myMap
22:37:18 fordcars Right now the map is actually holding actual objects
22:37:20 raptor these are the kind of talks that start me second-guessing myself
22:37:27 fordcars Haha
22:37:53 fordcars Ok let me make myself a bit clearer I suck at being clear
22:37:54 raptor well, maybe the actual objects should be wrapped in a shared_ptr
22:37:58 fordcars The map:
22:38:07 fordcars raptor: you think?
22:38:21 raptor that way access can be like you want
22:38:28 raptor yeah - we do that somewhere in bitfighter, too
22:38:45 raptor like in the editor, have a vector<shared_ptr<BfObject> >
22:39:04 fordcars Oh interesting
22:40:16 fordcars And shared_ptr would be the right pointer for this
22:40:22 raptor yes
22:40:33 fordcars Since it wouldn't deconstruct the object unless all of them are gone
22:40:43 raptor correct
22:40:51 fordcars That is some cool stuff
22:41:21 fordcars Thanks raptor!
22:41:34 raptor sure...  i hope something i said is right :)
22:41:43 fordcars Me too :)
22:41:56 fordcars But it is probably right
22:42:02 fordcars Coming from you ;)
22:42:49 raptor hah!  I think I'd confirm with coding first...
22:42:55 fordcars Hahaha
22:43:03 fordcars Yes I will :)
22:43:20 fordcars Well tomorrow night, school starts tomorrow, better go to bed early(er)
22:44:37 fordcars So night!
22:44:43 fordcars Quit (Quit: Page closed)
23:27:39 raptor Quit ()

Index Search ←Prev date Next date→

These logs were automatically created by BFLogBot on irc.freenode.net.

00:10:01		DiannaAgron Quit (Quit: Leaving)
00:10:49		Flynn Quit (Quit: This computer has gone to sleep)
00:25:26		Nothing_Much has joined
01:35:37		Nothing_Much Quit (Quit: Leaving)
03:32:47		Darrel Quit (Read error: Connection reset by peer)
03:40:45		LordDVG Quit (Remote host closed the connection)
03:50:18		Darrel has joined
05:18:07		koda has joined
05:27:53		Darrel Quit (Ping timeout: 272 seconds)
05:28:14		Darrel has joined
06:02:58		koda Quit (Ping timeout: 260 seconds)
06:04:33		koda has joined
06:56:33		kodabb has joined
06:57:18		koda Quit (Ping timeout: 244 seconds)
06:59:07		koda has joined
07:01:18		kodabb Quit (Ping timeout: 260 seconds)
07:05:02		koda Quit (Ping timeout: 260 seconds)
07:08:15		koda has joined
07:13:16		kodabb has joined
07:14:23		koda Quit (Ping timeout: 244 seconds)
07:14:23		kodabb is now known as koda
07:17:01		kodabb has joined
07:20:02		koda Quit (Ping timeout: 264 seconds)
07:20:19		kodabb is now known as koda
07:24:15		kodabb has joined
07:26:53		kodabb_ has joined
07:27:07		koda Quit (Ping timeout: 250 seconds)
07:29:12		kodabb Quit (Ping timeout: 268 seconds)
07:29:30		koda has joined
07:31:40		kodabb_ Quit (Ping timeout: 268 seconds)
07:33:56		kodabb has joined
07:35:22		koda Quit (Ping timeout: 268 seconds)
07:35:22		kodabb is now known as koda
07:41:29		kodabb has joined
07:44:14		koda Quit (Ping timeout: 260 seconds)
07:44:14		kodabb is now known as koda
09:27:23		Nothing_Much has joined
10:29:00		Nothing_Much Quit (Remote host closed the connection)
12:28:30		kodabb has joined
12:30:13		koda Quit (Ping timeout: 240 seconds)
12:31:11		Nothing_Much has joined
12:32:09		koda has joined
12:33:08		kodabb Quit (Ping timeout: 252 seconds)
12:34:53		kodabb has joined
12:37:32		koda Quit (Ping timeout: 252 seconds)
12:37:46		kodabb_ has joined
12:40:05		Nothing_Much Quit (Quit: Leaving)
12:40:06		kodabb Quit (Ping timeout: 252 seconds)
12:40:20		Nothing_Much has joined
12:41:02		koda has joined
12:43:24		kodabb_ Quit (Ping timeout: 252 seconds)
12:43:42		kodabb has joined
12:45:44		koda Quit (Ping timeout: 250 seconds)
12:48:01		koda has joined
12:49:12		kodabb Quit (Ping timeout: 250 seconds)
12:53:02		kodabb has joined
12:55:01		koda Quit (Ping timeout: 272 seconds)
12:56:23		koda has joined
12:58:13		kodabb Quit (Ping timeout: 240 seconds)
12:59:16		watusimoto has joined
12:59:16		ChanServ sets mode +o
13:43:37		Nothing_Much Quit (Remote host closed the connection)
13:45:57		Nothing_Much has joined
13:46:16		Nothing_Much Quit (Read error: Connection reset by peer)
13:47:12		Nothing_Much has joined
15:05:57		Nothing_Much Quit (Remote host closed the connection)
15:26:03		koda Quit (Quit: koda)
17:20:55		fordcars has joined
18:20:24		koda has joined
19:51:29		DiannaAgron has joined
20:47:14		DiannaAgron Quit (Read error: Connection reset by peer)
20:54:03		DiannaAgron has joined
21:09:39		koda Quit (Quit: koda)
21:19:37		raptor has joined
21:19:37		ChanServ sets mode +o
21:22:14	raptor	good day!
21:55:46		watusimoto Quit (Quit: Leaving.)
22:26:31		fprdcars has joined
22:27:06	fordcars	Hi!
22:27:12	fordcars	Didn
22:27:17		fprdcars Quit (Client Quit)
22:27:20	fordcars	Oops
22:27:23	raptor	hi
22:27:58	fordcars	Hey raptor, if you have a pointer pointing to an object, and that object dies (gets destroyed), that pointer is null, right?
22:28:10	raptor	nope!
22:28:15	raptor	that's the fun of c
22:28:17	fordcars	Hah!
22:28:26	raptor	it still points to the same memory address
22:28:56	fordcars	So how do you check if it is still valid?
22:29:03	raptor	so when accessed again, aftter the object is destroyed, then it may call up some random chunk of memory and mess everything all up
22:29:07	raptor	ah ha
22:29:12	fordcars	Haha
22:29:15	fordcars	Ok
22:29:27	raptor	to address this issue, you use what's called a safe pointer
22:29:48	raptor	or a 'smart pointer'
22:29:52	fordcars	Oooo this
22:30:04	fordcars	Yes I used one somewhere
22:30:06	raptor	they keep track of the object and when it is destroyed, they set themselves to NULL
22:30:27	fordcars	But I didn't use one this time because I thought I didn't need to for a const pointer
22:30:33	fordcars	Uh, pointer to a const
22:31:05	raptor	if you're not writing really tiny code and are pressed for memory or performance, the standard thing to do is always use a smart pointer
22:31:26	fordcars	Okok
22:31:40	raptor	if you're coding in c++11, then I think there's a standard one to use
22:31:56	fordcars	Yeah, std::pointerss
22:32:02	fordcars	But I am not sure wich one to take
22:32:04	raptor	like this one: http://en.cppreference.com/w/cpp/memory/shared_ptr
22:32:24	fordcars	const Class *instance; is my pointer
22:32:42	fordcars	Oh I guess it would be shared
22:32:53	raptor	if you only access the object through one pointer, then use std::unique_ptr
22:32:57	fordcars	Oh
22:33:08	fordcars	But I don't want to ever delete this object by this pointer
22:33:16	fordcars	It must be read only
22:33:24	raptor	the pointer or object?
22:33:28	fordcars	The object
22:33:38	fordcars	The object is stored in a map
22:33:47	fordcars	And the pointer is a const pointer pointing to it
22:33:52	fordcars	For read-only
22:34:05	raptor	const can be applied to both the object and the pointer
22:34:49	raptor	if you don't ever want it destroyed, then perhaps you should make it a static object and just provide access to it via some method
22:36:15	fordcars	Sorry it must only be destroyed by the map
22:36:45	fordcars	But not by the pointer
22:36:52	raptor	map<shared_ptr<Class> > myMap
22:37:18	fordcars	Right now the map is actually holding actual objects
22:37:20	raptor	these are the kind of talks that start me second-guessing myself
22:37:27	fordcars	Haha
22:37:53	fordcars	Ok let me make myself a bit clearer I suck at being clear
22:37:54	raptor	well, maybe the actual objects should be wrapped in a shared_ptr
22:37:58	fordcars	The map:
22:38:07	fordcars	raptor: you think?
22:38:21	raptor	that way access can be like you want
22:38:28	raptor	yeah - we do that somewhere in bitfighter, too
22:38:45	raptor	like in the editor, have a vector<shared_ptr<BfObject> >
22:39:04	fordcars	Oh interesting
22:40:16	fordcars	And shared_ptr would be the right pointer for this
22:40:22	raptor	yes
22:40:33	fordcars	Since it wouldn't deconstruct the object unless all of them are gone
22:40:43	raptor	correct
22:40:51	fordcars	That is some cool stuff
22:41:21	fordcars	Thanks raptor!
22:41:34	raptor	sure... i hope something i said is right :)
22:41:43	fordcars	Me too :)
22:41:56	fordcars	But it is probably right
22:42:02	fordcars	Coming from you ;)
22:42:49	raptor	hah! I think I'd confirm with coding first...
22:42:55	fordcars	Hahaha
22:43:03	fordcars	Yes I will :)
22:43:20	fordcars	Well tomorrow night, school starts tomorrow, better go to bed early(er)
22:44:37	fordcars	So night!
22:44:43		fordcars Quit (Quit: Page closed)
23:27:39		raptor Quit ()