Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / DarkGDK SWIG wrapper, 22 new programing languages!

Author
Message
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 27th May 2012 22:16 Edited at: 6th Jun 2012 18:02
Link
This is a little swig wrapper i made originally for PureGDK 2.0 but with the new DarkGDK 2.0 change it was trivial to make it work for the new system so here it is.

The original post at the PureGDK forum has a little more info: http://forum.thegamecreators.com/?m=forum_view&t=196481&b=38

Basically it just uses SWIG to wrap the standing includes for any given DarkGDK 2.0 project.

This wrapper comes with a setup/installer for use with python(2.x tested only) but using the provided wrapper files it is very simple to make a wrapper for any of the SWIG compatible languages!

README.txt is included for more info and there is also a python version of the example DarkGDK 2.0 project using the python wrapper, it is all very simple.

Use this however you want, modify, redistribute anything its for the good of all.

For more info or questions email me or reply to this thread.

If it is requested i may be able to make setup scripts for the other SWIG languages as i have done with python already but for most languages the SWIG docs provide enough info to compile your own.

DarkGDK 2 Wrapper Generator Download HERE

I swear to the programmers bible that I shall not harm the FPS.

Attachments

Login to view attachments
Back to top
Profile PM
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 28th May 2012 00:31
Link
This looks extremely promising! Keep up the good work.

ACER Aspire 5920G: Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.60 + DarkGDK 2.0
Back to top
Profile PM Website
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 28th May 2012 00:56
Link
Thanks mate!

Just a note on a issue that I'm not sure on. It may not be a good idea to actually distribute a product made with this wrapper with an interpreted/scripting language. I'm just not sure if there are any licensing issue but i will investigate.

The problem being that if you, for example, made a game with python and used this wrapper you would have to package the python DarkGDK wrapper which may be able to be extracted on its own and there you go free full copy of DarkGDK 2.0 for anyone to use with python.

Using python packaging utilities can help mitigate this issue but i don't think it can solve it.

Also i would like to make the wrapper setup/building easier by including the headers and .cpp (the normal DarkGDK includes) files with the wrapper interface files that are there already so that you guys don't have to move the right files into the right place and make the minor adjustments to build it but i believe that would represent a licensing issue as well as posting the download link here would be rather public... Maybe there is something Mistrel can do by making the download link available on the PureGDK website to product owners only, who knows.

I just want to make it easier for all us devs but i don't want to overstep my bounds so if anyone has any ideas on these problems do share please.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 28th May 2012 12:43 Edited at: 28th May 2012 13:14
Link
Just taking this off top of my head:

What if there would be a version of 'gdkengine.dll' compiler that would allows us to provide a MD5 checksum of the main source file, for example the one that initialises DGDK dll, it's kind of code signing. So if you try to tamper with the python script and run it, it would say that code signature does not match with the one integrated in the dll. A well informed person could hack the checksum but it would require some utility to be written to automate this.

[Edit] While developing one would use the clean version of dll and substitute it with signed version on public release.

ACER Aspire 5920G: Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.60 + DarkGDK 2.0
Back to top
Profile PM Website
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 28th May 2012 23:36 Edited at: 28th May 2012 23:38
Link
Something like that could work but it would have to be made into the dll and i don't think we can do that alone it would have to be made as an option in the dll build step that mistrel would have to provide.

The problem with the python source files is that even if you package your python game into an exe the exe can be opened with say 7zip or some such and you can view the source files and just read the md5 sum and manually place it in yourself. Once again this can be mitigated, but only slightly, by distributing only the .pyc files with the exe and not the .py files which would require the additional step of using the decompyle type python package which gives you a source like view of it anyways at least enough to extract where the md5 comes from enough to replicate it.

Unless maybe the md5 or some kind of code can be provided to the dll from a python module that is actually compiled C++ code... this could be done using cython to take a normal .py file and convert it to c++ and compile the code into the module. although it removes some of the portability of python when the dev has to compile the extensions most of this portability is lost anyway with a directx only engine so maybe that might be the way to go so long as devs use cython.

Regardless of how its implemented in other languages i do think being able to compile the gdkengine.dll with some kind of lock code would be very nice and useful for such languages.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 29th May 2012 01:58
Link
My idea was to store it in the dll so during the final compilation we would provide the MD5 to "compile engine with plugins.bat" as a command line parameter. During the start-up dll would verify fingerprint of main py source file with the fingerprint stored in the dll. I'm not sure how easily extractable it would be but essentially it means that any change in py file will render "gdkengine.dll" illegible.

ACER Aspire 5920G: Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.60 + DarkGDK 2.0
Back to top
Profile PM Website
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 29th May 2012 02:19
Link
Yeah that's what i thought you meant however i don't think that could be done exactly because it would mean that the engine would have to have the python runtime compiled into it itself so that it can know what is the main py source file which means the dll would have to become an exe like python.exe but with the engine compiled into it as well.

While this could be possible as a fork of the DarkGDK 2.0 project it would be infeasible to make it a part of the main product unless TGC specifically wanted to make python support.. which i am so down for by the way, however i don't see that happening.

Also this would not exactly be consistent with the design/goals of DarkGDK and would require significant modifications (as far as i can tell) which is why i posited the simpler and more likely way to do it while still keeping the dll almost exactly as it is. Like you said make the "compile engine with plugins.bat" take an optional key but be provided to it by the source code and fail to work if it is incorrect. This would also allow other interpreted languages to work as well and not have to make a separate build system just for python keeping with the spirit of this wrapper to provide more languages as easily as possible.

Mistrel or rather no one from TGC has commented on my wrapper so i assume they are not concerned with these problems (really i did intend for python support just for prototyping and i was going to do my final work in D but swig still has complications with D) which if that is true then the ideas to secure the dll is rather a moot point. As such i will maintain the wrapper with the design it has for now until i am told it needs to be changed or if someone has any ideas on how to extend the wrapper.

Security aside i was thinking of trying to make a collection of C++ functions for common tasks that would be compiled into the wrapper as well to alleviate some of the overhead of the wrapper especially in interpreted languages. Whats the point of making a function in python that only calls a few dll functions to do something simple or something that most people will want to do but must be run often. This could cause a large performance drain so why not package in some simple but common functions to alleviate the penalties.

If anyone has any ideas what kinds of functions these should be or even if you would like to submit a function for the wrapper yourself i would be happy to make it so.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 29th May 2012 12:26
Link
I think the whole idea of this SWIG wrapper is brilliant. From what I've heard Mistrel (and I guess TGC as well) are quite interested in porting DBP to as many languages as possible. You just need to inform them. I suggest sending an email to Mistrel (you can get his contact details from www.darkgdk.com) and promoting this. Guess he just haven't noticed it yet.

ACER Aspire 5920G: Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.60 + DarkGDK 2.0
Back to top
Profile PM Website
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 29th May 2012 14:20
Link
Yeah i saw in the PureGDK/DarkGDK statement that they wanted to bring it to many more languages and then i looked for all these other languages that can be used with it and found i rather... lacking at this stage so i sought to fix that. I am glad at least one person has validated my work, so thanks Olby you have made me happy.

Your right i should probably at least make sure Mistrel knows this exists and ask if it poses any concerns for him. If it does i would like to try to work with him to sort them out as i am sure we can all agree that the GDK could really use something like this wrapper.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
Mistrel
Retired Moderator
19
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 30th May 2012 10:46 Edited at: 30th May 2012 11:05
Link
About the core engine and wrappers:

It's fine if you post information on how to do this. However, you cannot distribute the compiled gdkengine.dll with it as a complete solution.

For example, making a "game making tool" is a touchy subject because TGC doesn't want people to wrap up each individual command and release it as an "engine" for people to use.

One of the major differences between DarkGDK 1.0 and DarkGDK 2.0 is the move from static linking to dynamic linking which created this problem. There is no easy solution so a lot of it will rely upon good faith. But it's not so different from asking people not to share a serial number.

The bottom line is that distributing your engine dll is "ok" but don't do it in such a way that duplicates the product itself. Headers which do not include the engine you're linking to are perfectly fine.

Why your solution is different from the current implementation:

The way DarkGDK 2.0 supports additional languages includes more than just the wrapper itself. In addition to the headers, the language plugin also generates all of the language-specific documentation. So whenever a change is made somewhere which affects the docs, parameters, command names, etc, all of that will automatically get propagated out to every supported language.

Because SWIG is its own wrapper solution it doesn't fit the requirements necessary for me to advertise that it is truly supported. The first thing people tend to ask for is the documentation, right? Hence why I designed DarkGDK 2.0 the way I did.

Back to top
Profile PM Email Website
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 30th May 2012 17:03
Link
OK so keeping the wrapper the way it is, a 1:1 wrapper of the c++ includes is OK then? But if i was to add functions (a thought i mentioned earlier) that would not be, that's perfectly fine.

I understand that the way swig does things is different but like i said i wanted to use more languages now so i went swig. Is there any way people can write their own language plugin? or is it only the TGC guys who can do that?

What other languages are you intending to target in the future. Personally i just want Python and D support, anything that can support C++, Python, and D is a well rounded and legendary system.

So the idea of python being modifiable with a distributed .dll is fine? we just say this wrapper supports interpreted languages for in house testing and prototyping only and that should be all good yes?

Also i don't except anyone to advertise that this is truly supported by DarkGDK 2.0, although if showing people how to make a wrapper is OK maybe rather then just a wrapper i should distribute my wrapper gen script.

I wrote a python script that can wrap the engine or perhaps any c/c++ project for swig use automatically. That way i may keep providing 1:1 wrapping that is always up to date all you need is one script and it should be forwards compatible with future DarkGDK 2.0 versions.

Thanks for helping to sort out the questions Mistrel, I just want to help not hinder or harm.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 30th May 2012 18:33 Edited at: 30th May 2012 18:34
Link
Have you tried reading this section in the help file:

DarkGDK > How to > Engine Customization > DarkGDK SDK > Adding Language Support

Sums up everything you need to know on how to add support for any language.

ACER Aspire 5920G: Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.60 + DarkGDK 2.0
Back to top
Profile PM Website
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 30th May 2012 18:55
Link
Thanks Olby, how did i miss that!

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 2nd Jun 2012 01:48
Link
I am working on making a gdk-dlang.dll that is compatible with the DarkGDK buildlibs and i am trying to understand a little more on the returnData.

so i have the following fields in returnData to provide the buildlibs:


What i would like to know is what happens if i don't touch one of them, exactly what becomes what. i understand header and lib but what about the others what are they meant to contain just text on how to include (for instance) this source file from other files and how do i know exactly where this file will be placed.

I have gotten rather far doing this based off of the DarkGDK 2.0 docs but its just lacking (in my opinion) more info on how the data that comes into, and is expected to come out of, the two exported functions is meant to be formatted or look.

Also with D (that's what i am making the dll for at the moment) you only need a .d file which serves as both header and source. so would i then provide only the header or only the lib.

Sorry if i missed some glaringly obvious deceleration that explains these questions as apparently i tend to somehow miss large, important things.

Thanks, and may i say the way buildlibs works to convert the templates to any language is rather ingenious and i find it very interesting.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
Mistrel
Retired Moderator
19
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 2nd Jun 2012 02:32 Edited at: 2nd Jun 2012 02:36
Link
Did you read the section "How to use the LibBuilder Return structure" which covers this structure? If so, which parts should be clarified?

Quote: "Also with D .. you only need a .d file which serves as both header and source."


From the docs:

For either of these files to be written to disk then the pointer for these fields header and library must be non-null, otherwise they will be ignored.

Quote: "how do i know exactly where this file will be placed"


The language-specific include string must be defined such that the inclusion path be relative to the current file. The include string must also contain the token '{__INCLUDE}' which will be replaced by buildlibs.exe with the correctly name file to be included.

For example, in C++:



The "prefix" and "ext" fields allow you to specify a prefix or extension to the file base name. The buildlibs.exe tool doesn't know what extension to use.

In C++ the basename would be .cpp for extLib and .h for extHeader.

It is advisable to not go crazy with the "ext" and "prefix" fields as this can also be customized by the "--prefix" and "--ext" command line switches available in buildlibs.exe. Generally, you should only need to provide the file extension (.d for example).

In case you weren't aware, the source code for the C++ and PureBasic plugins are included in the "Program Files\DarkGDK\sdk" directory.

Back to top
Profile PM Email Website
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 2nd Jun 2012 04:16 Edited at: 2nd Jun 2012 04:21
Link
Ah OK so when defining an language specific include i the {__INCLUDE} will be replaced with a relative path automatically.

Yeah i understand the ext and prefix and i intend to do very little with the by default and leave it up to the command line switches.

The main the main thing i wanted to be sure on really was that if i only define lib and make it call the lib a .d then that will be all that is created and it would be OK with that.

Sorry if i seemed a tad touchy, been a long night and i don't like working in c++ (i know everyone loves to hate) but i have now got a working language dll... well by that i mean it connects up to buildlibs fine and executes its commands correctly.

Actually it was quite simple to do however i had to (as usual) make it harder for myself didn't i. I decided that i didn't like doing so much string bashing (manipulation) in c so i actually made the dll with python embedded into it so i can use some much simpler python functions to handle the parsing and such. After string bashing in python its hard to go back, i know I've got it bad.

However the way i have made the dll that has python embedded is completely target language independent bar the python file to load which is a simple #define, when i finish the first version of the d language support i will also release the code for the dll because it would be really simple to change the #define to load a different python file and then write the parser in python which is simpler and generally easier to write for something that doesn't necessarily need the complication or power of c++. So maybe i or others can do some push out more language support with this, i don't know.

So now i will implement the d parser in python. Thanks so much for the examples in Program Files\DarkGDK\sdk it will help a lot, i did know they where there but i hadn't really taken too much of a look at it because of the amount of custom c string manipulation functions and all that i just felt yucky so i jumped straight on to embedding python.

Thanks for the support Mistrel, even when I'm being stupid, your a legend.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 5th Jun 2012 08:06 Edited at: 5th Jun 2012 08:12
Link
OK, i have been slaving away and i am in the testing and polishing (adding niceties like more customizable options) for my D programming language dll for DarkGDK 2.0 but i am at a point in testing where i am having an issue i am not understanding.

Here is the link to download my current dll and the python source, you will need a python27.dll in your path or alongside the libbuilder exe, sorry about that: DOWNLOAD DLANG ALPHA

So i have it converting all the data types correctly (seems so i am not up to testing it in D yet but fixing those problems would be trivial) and it returns the string back to the returnData but after that buildlibs freezes with no error i just get a windows box saying buildlibs has stopped working.

I made the python source also dump its constructed returnData into a file called testout.d that will be created alongside buildlibs. looking at this it seems that i am giving buildlibs what it needs but it is just freezing.

I know that this still needs work i am just stuck on a part of my early testing. i have scrapped the code for this and started anew multiple times now and this model seems as simple and clear as i can make it a this point. I will still have to incorporate more options and also provide proper help printing etc along with writing up a little documentation on how to use python to write a gdk language dll.

NOTE: the download is meant to have its contents extracted into "program files/darkgdk/engine/" and i have included a bat file to run the test case on DarkGDK.gdt. Also i have provided the source code of the gdk_dlang.dll which loads the python module dlang and provides it with the parserData, options and returnData.

I hope someone can help, sorry its a bit complex in parts using two languages but it is rather nice to use and change so i have mostly succeeded on that point alone.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 5th Jun 2012 20:37
Link
I have managed to fix the crash, turns out i was handing the string back from python to the c returnData improperly and it caused it to crash. i have fixed that and replaced the download link in the post above with the correct one which i will attach here as well just in case my link goes bad or something.

Now it doesn't crash and the testout.d that python prints (which is the exact return data given to buildlibs) however the file that buildlibs creates is empty.

I don't know whats going on here as the internal workings of buildlibs is all hidden and what not making it a bit harder to debug what goes wrong once the returnData is handed to it. Any help Mistrel or anyone else that has experience with buildlibs would be awesome at this point as i believe i am almost done.

I swear to the programmers bible that I shall not harm the FPS.

Attachments

Login to view attachments
Back to top
Profile PM
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 6th Jun 2012 16:42 Edited at: 6th Jun 2012 17:29
Link
Well as i have hit a wall with the testing of the D language .dll for buildlibs that i mentioned above, i have had time to go back over the original swig wrapper and make some improvements.

Firstly, the largest change. I didn't like the idea of finding the minor alterations that break this wrapper each time DarkGDK is patched/updated so i have made the wrapper automatically construct a fully working swig wrapper out of the c++ headers and now will automatically patch the stdint support of the correct file so all you need to do is drop your headers into position and run.

Speaking of running although the wrapper generator is written in python i don't want to restrict or make it harder for people who want to use other languages so i have made the generator into a single stand alone exe that has the python dll packaged in so you don't even need python installed to run the wrapper generator.

When you run the exe it will provide you with details and instructions and give you the option of generating the additional python support. While this doesn't have to be used even if you want to use python, it will provide you with a working setup script so you can install it immediately and will also provide a readme that has information on using the wrapper in python including the spinning cube tutorial in python.

I will update the download link on the OP, so if you want the new wrapper that should be future proofed for all coming versions of DarkGDK 2 (provided there arent any sweeping changes to the way it all works) then just look up!

EDIT: there was a problem with the first upload and RC4 support. but that has now been fixed and the OP downloads have been updated.

Enjoy gents, it has been fun making this work. Cant wait to get this D language dll done though.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 6th Jun 2012 18:10
Link
Quote: "Enjoy gents, it has been fun making this work. Cant wait to get this D language dll done though."


I wish I knew how to work Python. But it looks like you managed to get done and over nonetheless. Well done.


Intel Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.60 + DarkGDK 2.0
Back to top
Profile PM Website
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 8th Jun 2012 12:51
Link
well after having a good break from the gdk_dlang.dll to provide D language support for GDK i found my earlier problem was caused by a very silly typo.

I will start doing compilation tests later tonight or tomorrow morning but i was wondering how the default language dll's manage to place extra files in the output headers directory that are not based on gdt templates, specifically the initDarkGDK and simpleWindow.

I can build an implementation of these directly into core.DarkGDK but i would prefer to implement them separately as Mistrel has not just to keep with the current format but to allow people to use a different windowing method without including simpleWindow at all.

I cannot see anything in the buildheaders.bat that would provide these files so i assume its part of the language dlls.

@Mistrel: Also with the new rc4 for c++ you are providing .cpp files for initDarkGDK and simpleWindow but in the compile headers.bat you are only deleting the .h files each time it re compiles the headers. just a little forgotten piece i guess or maybe it has a reason if so sorry, just thought i should mention it.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
Mistrel
Retired Moderator
19
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 8th Jun 2012 14:07
Link
Quote: "I will start doing compilation tests later tonight or tomorrow morning but i was wondering how the default language dll's manage to place extra files in the output headers directory that are not based on gdt templates, specifically the initDarkGDK and simpleWindow."


These files do not need to be rebuilt so they are simply installed alongside the headers. They are not generated by the language plugin.

Back to top
Profile PM Email Website
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 8th Jun 2012 14:34
Link
oh, so the darkgdk install includes those and if i wanted to provide my own i would have to package them with my dll, no way of automatically getting them in the app data folder then. also what about the core/darkgdk.h or core/darkgdk-plugins.h are they constructed or installed. because they depend on the correct header names.

For simpleWindow i am going to have to go through it line by line and try to make a D version. main problem is finding the d equivalents of the system includes like deque and map. then there are a few bugs to sort out in the construction of commands with no arguments and tid bits like that and i am ready to test.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
Mistrel
Retired Moderator
19
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 8th Jun 2012 15:05 Edited at: 8th Jun 2012 15:05
Link
Quote: "What about the core/darkgdk.h or core/darkgdk-plugins.h"


Those are built automatically by buildlibs if you pass it the "--header" option.

Quote: "For simpleWindow i am going to have to go through it line by line and try to make a D version."


deque and map are C++ STL classes. I would assume that D has something similar to this?

Back to top
Profile PM Email Website
FlexiCat
14
Years of Service
User Offline
Joined: 15th Jun 2010
Location:
Posted: 8th Jun 2012 15:17
Link
Ah i will look into that option in the morning then.

Yeah im sure D has something like them however they may be renamed or the functionality provided by the C++ STL classes may be functionality provided in a subset of a completely different class making the name hard to find.

Either way tomorrow i will get on the D irc and ask around if i cannot find it directly. For now though its time to sleep, thanks Mistrel and sorry about posting my code asking for help for a dumb typo.

I swear to the programmers bible that I shall not harm the FPS.
Back to top
Profile PM
Dar13
16
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 8th Jun 2012 16:32
Link
D uses something similar to Boost's generic container system.
link

It does have containers that are similar to C++ STL though, std::vector would be Array, std::list would be SList(singly-linked though), and std::map would be RedBlackTree. There doesn't seem to be a deque or queue type containers(though you could just make your singly-linked list into a queue or deque).

Follow WTLD's progress on Twitter
Git repository for WasTeLanD
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-11-19 00:41:25
Your offset time is: 2024-11-19 00:41:25