Messages

16

Programming / Re: D language - class

« on: November 16, 2014, 11:50:14 PM »

While the answer to your syntactical question is simply "because that's the way D syntax works",  the answer to your implementation question about class memory allocation may have more of an answer:

I was completely unfamiliar with D (other than being aware that it exists), so I did some investigation and found the following:

http://forum.dlang.org/thread/juspoa$5g9$1@digitalmars.com#post-juspoa:245g9:241:40digitalmars.com
http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack
http://wiki.dlang.org/Memory_Management
https://issues.dlang.org/show_bug.cgi?id=5270

Short answer seems to be: D used to allow classes to be allocated to the stack, but deprecated this option because it caused memory corruption in some circumstances.

17

Programming / Re: D language - class

« on: November 16, 2014, 02:40:04 PM »

It's in the first message of this thread.

Yes, I saw that 

Why you can create class only using new in D. I think it doesn't make sense unless it's for garbage collection. But who knows.

Which reads to me like "why doesn't D use C++'s syntax", but perhaps I'm still misunderstanding.

18

Programming / Re: D language - class

« on: November 14, 2014, 02:15:40 PM »

Yes, some guy thought it is because garbage collection. I guess it makes sense? Well I'm not too worried about it, but I don't know why they don't explain it better.

You mean explain why the syntax is different from Language X? Probably because Language X could be C, C++, C#, Java, Ada, Lisp, SmallTalk, Python, Fortran, Haskel, COBOL, WhiteSpace, BrainF*ck, BASIC.... no language is going to explain every syntactical difference between itself and every other language.

Or perhaps I misunderstood what you wanted them to explain?

19

Programming / Re: [Python] Conditionals and reading list elements

« on: October 25, 2014, 12:43:03 AM »

The real question is do you want to learn better ways of doing things? 

Coding best practises aren't what they are "Just Because." They exist to make it easier to write, maintain, and (ahem) debug code.

Anyway, there's no way of figuring out where your bug is with just the code shown.  Where is the code that you use to put firstquestitem in quest_items_inventory, for instance? And what did you do to determine that it's populated? You said you verified this, but didn't say how.

But, really, difficult-to-find bugs are what best-practises and non-ugly code exit to avoid. If you don't learn the right way of doing something because it's "just a hobby" and "it's ugly but it works" (except when it doesn't, and the bug is hard to find), you're just making things more difficult for yourself, not easier.

Any good advice you get about your code will probably involve substantial revision, rather than just a quick "change this small thing to fix your bug". If that's what you're looking for, lets see the rest of the relevant code . If you just want a quick answer to "make it work", I doubt I'll be able to help you -- I can't speak for anyone else.

20

Programming / Re: LIBTCODPY (Doryen Library) keyboard input question

« on: October 24, 2014, 04:53:10 PM »

That said, it's just occurred to me (thanks to your message putting into  writing some concepts which I'd mostly grasped but didn't quite have a nice mental image for) that maybe it's just the fact that within tcod itself this stuff is already defined. And so all that's needed is to reference it, essentialy setting the dominoes falling within the tcod module itself, and that's how it works. That's a guess, anyway.

Yup, based on the code shown,

tcod.console_wait_for_keypress(True)

would have worked just as well as

key = tcod.console_wait_for_keypress(True),

but it can be kind of a habit to grab the return result just in case you need it later.

21

Programming / Re: [Python] Conditionals and reading list elements

« on: October 24, 2014, 04:46:57 PM »

Hi!

Just some clarification first of all.  Are you saying that even when the first quest item is in the quest items inventory, you are still getting the "where is questitem" message as though it were not?

Also, I'm a bit confused by the first line of your example code. Are you really checking for a string in the object name to verify who you're talking to?

it might be helpful to see the relevent class code that's being used here, to better understand what's going on.

22

Programming / Re: LIBTCODPY (Doryen Library) keyboard input question

« on: October 22, 2014, 09:38:41 PM »

Hi!

I'm not familiar with the inner workings of this library, but I think I can partially answer your question .

this is using object oriented programming, which can be counterintutive if you're not familar with it -- as you've discovered!

'tcod' is an "object". With object-oriented programming, you can create 'objects' which maintain a state (that is, store the value of several variables internally), and also have their own methods which act on them.

Thus, 'console_wait_for_keypress' and 'console_is_key_pressed' are functions belonging to, and acting on, the tcod object.

What I suspect is happening here is that the 'console_wait_for_keypress' is waiting for a keypress and then storing it's value internally within the tcod object. It also passes the key as a return value, but this is just 'extra'.

The 'console_is_key_pressed' functions are then probably checking against this internal value. So, the intial function was neccesary (to wait for the keypress, and to store the value internally), even though the 'key' variable isn't used.

'KEY_KP8', and such, are constants stored within the tcod object, those fucntions are comparing the internally stored key-value against the various constant values.

Hope this helped a little bit? It's hardly a comprehensive introduction to OOP, but hopefully it removes at least a bit of the WTF.