next »

[MorleyDev]

It's less that pointers are wrong, bad or difficult, it's more that pointers are a low level concept. They don't need to exist naked at the higher levels of your code, so ideally should be 'hidden' away by RAII concepts. That's no different from any other part of code: you use abstractions to separate the low level from high level.

Naked pointers in high-level code are just another code smell that often, but not always, indicate that the Dependency Inversion Principle is being violated.

[Sik]

The problem programmers have with pointers really is that they're memory addresses and as such you can get said address as a value (and if you manipulate that value you can end up with an invalid address). Higher level languages replace pointers with references, which are practically the same thing except because you aren't allowed to retrieve or manipulate the address.

[eigenbom]

It also depends on how much you know/trust the system you're using and the volatility and lifetime of the things being pointed to. For instance, I pass PhysicsSystem* around my code because I know there's one and only one for the lifetime of the program. On the other hand, entities (monsters, weapons, particle systems) all get accessed through a handle ID:uint32 and therefore can be shuffled around in memory without any trouble. Retrieving an invalid entity returns a null entity, so calling code can either check it's null-ness or just operate on it anyway.

[InfiniteStateMachine]

yeah actually I've had trouble when using 3rd party libraries that aren't clear about who is supposed to perform memory cleanup.

[He-Who-Develops-Games]

Python 2 and Lua, probably. I use Lua every day (I use Love2D for my games) and I write a shit-ton of Python scripts and also all my level editors are Python because I've not taken the time to figure out love.filesystem yet.

[Geti]

Personally, I'm quite comfortable with pointers and pointer arithmetic.  Getting into data-oriented design and cache-friendly code has really shown me how fundamental and simple pointers are. I think the problem most people have with pointers is that they're not used to thinking of everything as it is stored in memory.

You just went up in my estimations, Boreal.

I'm not even going to step into the whole "pointers" discussion, I have too many feelings on the subject.

[Boreal]

It's less that pointers are wrong, bad or difficult, it's more that pointers are a low level concept. They don't need to exist naked at the higher levels of your code, so ideally should be 'hidden' away by RAII concepts. That's no different from any other part of code: you use abstractions to separate the low level from high level.

Naked pointers in high-level code are just another code smell that often, but not always, indicate that the Dependency Inversion Principle is being violated.

I agree.  That's why I implement long-term references as handles that can be translated to pointers temporarily (i.e. valid for a single frame).

In general, I have two layers for each storage.  On the bottom is the actual memory, usually using a pool allocator.  On top I have the index list, which is used when translating handles to pointers.  When an object is deleted, I can simply move the last object to the newly emptied slot and update one pointer in the index list.

[Cheezmeister]

Naked pointers in high-level code are just another code smell that often, but not always, indicate that the Dependency Inversion Principle is being violated.

http://en.wikipedia.org/wiki/Dependency_inversion_principle

Today I learned something new! Thanks for that.

[Adam_]

I think C# is pretty neat. Would consider myself proficient in C++ as well, but I always find myself cursing it for missing feature X, requiring boilerplate Y or just getting me lost in dependency hell once again. I do realize that C++'s "you don't pay for what you don't use" attitude as well as hardware vicinity are vital to a lot of projects and especially high-performance and lowlevel development, but... I don't know, it just feel really outdated and duct-taped when C# is in the same room. Maybe it's just me.

[Enhex]

C++, and Lua for scripting.

[SolarLune]

Never liked Lua because of the "syntactic sugar" they put over function declarations in tables to try to make them work like class functions. Either make them always work like class functions, or don't, but don't make them work like class functions if you both define the function and run the function a certain way. It just feels inconsistent and introduces two points of failure for no particular reason, as far as I can tell. I could probably get used to it or get an external module to "add" class-like structures, but...

[Geti]

I dunno man, It's not particularly scary or verbose, and you have to explicitly call the function that way to get the "method" sugar. Interesting to hear that it annoys you - in my eyes it just saves you passing the object directly if you're storing it's methods inside itself, and the colon operator isn't used for anything else since lua doesn't have C's ternaries so there's not much chance for confusion if you're looking at syntax highlighted code (though I feel : and . are very similar when unhighlighted, and maybe :: would have been a better choice)

Code:

local something = {a = 5, b = 3};

function f(self)
{
  return self.a + self.b;
}

-- inject here so that it's clear that it's just a "normal" function
-- could also have declared it as function something:f() though,
-- or inline when we defined something
something.f = f;

something:f();

At various points I've kind of liked how Go and co do a similar thing allowing "method call syntax" for things that are written like methods; it feels very OO-y but if you're writing that kind of code, imo it makes sense to have the syntax for it ( and it looks 100x nicer than something.f(something) for sure ).

The thing that turns me off Lua isn't the language, it's binding it and passing crap back and forward between language barriers all the time.

[Boreal]

The thing that turns me off Lua isn't the language, it's binding it and passing crap back and forward between language barriers all the time.

But that's unavoidable when you use an embedded scripting language.

[Geti]

At some level sure, but some languages make binding to C or C++ significantly cleaner and faster, without bringing in dependencies like SWIG; not requiring wrapper functions in most cases and allowing you to work directly with your internal types in the scripting language. That's the reason we went with Angelscript for KAG.
LuaJIT has this with its FFI Extension but then you end up writing a lot of low level safety or environment checking in your scripts, and need to include metadata about what functions you want to use in each script.

[Boreal]

At some level sure, but some languages make binding to C or C++ significantly cleaner and faster, without bringing in dependencies like SWIG; not requiring wrapper functions in most cases and allowing you to work directly with your internal types in the scripting language. That's the reason we went with Angelscript for KAG.
LuaJIT has this with its FFI Extension but then you end up writing a lot of low level safety or environment checking in your scripts, and need to include metadata about what functions you want to use in each script.

Maybe it's just me, but I prefer to explicitly define the binding between my native code and script, and Lua provides a convenient and simple interface to do so.

[Geti]

You still do in Angelscript, you just don't have to interact with the VM in wrappers

Code:

                                 //scripting-side type the binding is for
r = engine->RegisterObjectMethod("CBlob",
                                     //scripting side method sig
                                     "CBlob@ getTouchingByIndex(int index)",
                                     //macro expanding to the correct function pointer
                                     WRAPPER_MEMBERPR( CBlob, getTouchingByIndex, (int), CBlob*),
                                     //the calling convention used to call it
                                     CALLING_CONV);
//ensure the binding went correctly - can figure out exactly what went wrong if you're interested
assert(r >= 0);

Trim out the contents and it's a nice, compact way of controlling what's bound, binding it correctly and ensuring you can find out if anything goes drastically wrong without needing wrappers or to write VM interaction code if all you want to do is call something from scripts.

I've never heard Lua's binding interface referred to as "convenient" before, to the point where the page about it lists tens of libraries developed for both C and C++ to make it easier.

[SolarLune]

I dunno man, It's not particularly scary or verbose, and you have to explicitly call the function that way to get the "method" sugar. Interesting to hear that it annoys you - in my eyes it just saves you passing the object directly if you're storing it's methods inside itself, and the colon operator isn't used for anything else since lua doesn't have C's ternaries so there's not much chance for confusion if you're looking at syntax highlighted code (though I feel : and . are very similar when unhighlighted, and maybe :: would have been a better choice)

To me it's just something in the way. Why would you ever not want to pass the instance of the table into a function that's stored in the table? If Lua doesn't have classes or instances, and tables are the answer, why not make it as simple to use as possible instead of seeming like an afterthought with a separate operator to access it? It just seems unnecessary (this is coming from just a couple of hours of time accumulated working with it, making mistakes where I mean instance:function instead of instance.function or vice-versa or whatever).

P.S. Your example seems a bit hard to follow? Why are you passing in a and b at the bottom? Shouldn't it be blank, because self (something) is passed in automatically?

[InfiniteStateMachine]

Glad this discussion is arising. I plan to make a new thread regarding the current state of binding scripting languages to c++ but I need a bit of time to properly asses my requirements.

chaiscript sounds good in theory but I'm working off a stackoverflow thread from our very own Klaim that is dated 2010.

I need some time to properly think about what and why I need a scripting interface though.

[Geti]

To me it's just something in the way. Why would you ever not want to pass the instance of the table into a function that's stored in the table? If Lua doesn't have classes or instances, and tables are the answer, why not make it as simple to use as possible instead of seeming like an afterthought with a separate operator to access it? It just seems unnecessary (this is coming from just a couple of hours of time accumulated working with it, making mistakes where I mean instance:function instead of instance.function or vice-versa or whatever).

P.S. Your example seems a bit hard to follow? Why are you passing in a and b at the bottom? Shouldn't it be blank, because self (something) is passed in automatically?

The math table is the most obvious example where you dont want the instance of the table passed in at each point. math.sin, math.acos, math.random are all accessed through the math table, which is not passed into any of those functions (they're called using dot syntax, not colon). This allows tables to act as namespaces as well as objects, and keeps the grammar clear and well defined. If the table was always passed, every instance of a function stored in a table would have to accept a self parameter - by differentiating colon and dot call syntax there's no restriction on what you can store where, but still a convenient way of applying OOP if you so desire.

Re: PS why are you passing a and b??? - nice catch - fixed :^) was writing it at 1am after a few beers and moved a and b inside the table towards the end to show it actually using "self", must have not removed the parameters.

[Thecoolestnerdguy]

Javascript for everything.

I deserve to be punished.

JS programmers high five!

Seriously, I love Javascript.

I don't specially like the web environment, but I just love the language.

To be fair, it's the first and only language I learned for real, so...