PTL Library

[bnpph]

PTL is a library I am working on that provides similar functionality to STD containers, but it is designed to be extremely fast and extendable.

Out of the box, PTL has a collection of simple containers:

Code: Select all

ptl::parray<typename>;
ptl::pstack<typename>;
ptl::pvector<typename>;
ptl::plist<typename>;
//etc.

These work very similar to the STD.

However, PTL also allows you to create your own containers:

Code: Select all

class carray :
PTL_ARRAY_INHERITANCE(Array, int, ptl::array_base, ptl::array_default_stencil) {
  PTL_ARRAY_DEFAULT_STENCIL_INCLUDES(Array, int);
  PTL_ARRAY_DEFAULT_STENCIL_MEMBERS(Array, int, m_data, m_capacity);
  private:
    int* m_data;
    unsigned int m_capacity;
  public:
    carray(int size) : m_capacity(size) {
      this->m_data = new int[m_capacity];
    }
    ~carray() {
      delete[] this->m_data;
    }
};

carray is defined as type ptl::array_base. This means it is expected to have these methods:

Code: Select all

data(), begin(), end(), at(unsigned int), size(), capacity()

You can either implement these yourself, or use a stencil. Inheriting a stencil provides all the needed methods. If you want to change a method of the stencil, you can simply override it by defining a new one in your container class.

Anyway, I got a lot of stuff to do before I release this. Criticism/feedback would be appreciated.

[TheBuzzSaw]

STD == STL ?

[Ginto8]

I should probably take this opportunity to point out why standard containers are good: they are GUARANTEED to have certain functionality, no matter what platform you're on. It may not be perfect, that's for sure, but if you're compiling a program for a platform with a shitty STL implementation, nothing is changing you from making a more efficient one for you compiler (provided you maintain the same interface). However, despite the possibility of a bad implementation, the STL is designed to be platform-agnostic to the point that if a program using the STL is written, it will compile and work in almost exactly the same way on any platform with a standards-compliant compiler. If making PTL is a learning experience for you, go for it. However, don't forsake standards simply because you think it can be done better your way.

[bnpph]

STD == STL ?

STL usually refers to C++ STD's containers and algorithms, but I don't think it is an official term.

I should probably take this opportunity to point out why standard containers are good: they are GUARANTEED to have certain functionality, no matter what platform you're on.

All of the code for PTL uses standard C++ right now - it should compile fine for nearly every architecture/compiler. The speed benefits from using it are all done higher up - no inline assembly needed.

It may not be perfect, that's for sure, but if you're compiling a program for a platform with a shitty STL implementation, nothing is changing you from making a more efficient one for you compiler (provided you maintain the same interface).

Users who wish to make more efficient containers is exactly what this library is for. The STD is great, but it fails to deliver when the user wishes to modify it. There are always STD allocators, but they are clunky and never seem to fulfill what needs to be done.

If making PTL is a learning experience for you, go for it. However, don't forsake standards simply because you think it can be done better your way.

Definitely not a learning experience.
One thing people need to understand is that STD is standardized, but that doesn't mean it is a standard to code by. You shouldn't blindly use it just because you need a certain container - there are likely much better solutions in other libraries, yet many people never discover them because they are too busy using the golden hammer known as STD.

What does one do when they see a small optimization that can be made in their program? Of course, nearly every programmer would implement it, but things get difficult when the code is hidden behind a wall of STD code. For instance, what if you want to remove every node in a linked list except the first and last node? Using the STD, you would end up with several unnecessary operations - you know you simply want to iterate+destroy the inner nodes, then set first pointer to last. This is exactly what PTL is for: create a new PTL container, then add in your method - no boilerplate code needed. Much better than having to rewrite an entire list class just to use a method that wasn't in the STD.

[Ginto8]

Although I disagree with your argument that the STL can't provide what you need, and that standards are bad, I took a closer look and put some more thought into evaluating your library's features, and I have to admit - it's pretty cool. The use of preprocessor macros to provide features reminds me of QObjects, and that's a good thing in my opinion. Keep up development, but don't disregard the importance of standards :P

[TheBuzzSaw]

STL usually refers to C++ STD's containers and algorithms, but I don't think it is an official term.

Um, STL is very much an official term; it just all lives inside the "std" namespace. I was trying to correct you politely.

Also, regarding your containers being "fast", have you benchmarked them against the STL equivalents?

[bnpph]

I took a closer look and put some more thought into evaluating your library's features, and I have to admit - it's pretty cool. The use of preprocessor macros to provide features reminds me of QObjects, and that's a good thing in my opinion. Keep up development, but don't disregard the importance of standards :P

Thanks.

STL usually refers to C++ STD's containers and algorithms, but I don't think it is an official term.

Um, STL is very much an official term; it just all lives inside the "std" namespace. I was trying to correct you politely.

Hm, okay. Thanks for the info.

Also, regarding your containers being "fast", have you benchmarked them against the STL equivalents?

I've run some quick tests, but there really is no good way to benchmark this sort of thing.

From my tests, running the default vector class against STD's version gave identical results. Both were as fast as a normal array.

[TheBuzzSaw]

I've run some quick tests, but there really is no good way to benchmark this sort of thing.

Do some large scale insertion, deletion, and maybe even sorting (though this opens a whole subsection of extra benchmarking).

[bnpph]

I've run some quick tests, but there really is no good way to benchmark this sort of thing.

Do some large scale insertion, deletion, and maybe even sorting (though this opens a whole subsection of extra benchmarking).

The reason why they are meaningless is because the user is the one who will be designing the new containers, and I can only test the default ones.

Anyway, I did those tests on the vector/array container and they performed as fast as STD.

[Falco Girgis]

I'm not really choosing sides here, but I am not of the opinion that STL is an "ultimate" solution. "Standardized" is a very loose term. It is standardized in the sense of an API or interface. The actual code underneath is completely compiler-dependent. GCC's STL and Visual Studio's STL are completely different (one of them sucks ass, one not so much).

In the same sense, you could simply use the STL interface with his PTL library, so that it's completely compatible with any STL container-based code (which is exactly what QT does (obviously they thought they could do a better job than STL)).

Quite frankly, it almost never matters on a PC anymore. However... not all code winds up on a PC. I even gave in and started using STL in ES... just for std::vector. And guess what? I am now having to roll my own implementation, because a 2MB+ dependency on a console with 16MB of RAM really DOES suck. So something that allows me to define my own lightweight containers (especially when I'm only using 1/10th of their functionality) with container-specific optimized utility methods does sound pretty useful.

I don't think there's anything wrong with rolling your own containers and not using STL.

[Ginto8]

I don't think there's anything wrong with rolling your own containers and not using STL.

Rolling your own containers is fine, but sometimes people do things for the wrong reason, and sometimes end up worse off than they were before. If you need more performance, fine. If you need some more functionality, fine. Even, or rather especially if you just want to learn how to make it, go for it. But not using things that are already provided to you just because you want your own is probably going to end up a waste of time.

[ismetteren]

I hope this is not too offtopic. I have been wondering about what the STL actually is. Is it just a specification of what interface the standard C++ containers should have, or is it an actual interface(You know, pure virtual functions). Is it the whole implementation or is it something else?

And why is it called the standard template library? Is it because it utilizes templates so you can use the containers with any type of object, or is there more to it?

[TheBuzzSaw]

I hope this is not too offtopic. I have been wondering about what the STL actually is. Is it just a specification of what interface the standard C++ containers should have, or is it an actual interface(You know, pure virtual functions). Is it the whole implementation or is it something else?

And why is it called the standard template library? Is it because it utilizes templates so you can use the containers with any type of object, or is there more to it?

It is a specification. There are multiple implementations. I've looked into the source code before; I'm pretty sure it does not have a layer of pure virtual functions. It seems to be implemented directly. And yes, a big part of it is the fact that it uses templates for everything. Even the familiar iostreams use templates underneath. That's part of why STL is so underused; a lot of programmers do not know you can override STL's allocators and other deep functions. They think the only thing you can specify is the data type it contains.