Would you use a very low-level C++ library?

[Chris Thomasson]

I am almost ready to post an initial prototype of my C++ memory allocator
library:

http://groups.google.com/group/comp....eee1f61fdbb52c
Anyway, I think my C programming skills are "forceing" there way into my
current design. Yes, it's low-level at its core, but I want to get some of
your thoughts on the issue of using only the "bare-bones" of the C++
language; think embedded, embedded, embedded! ;^)

Well, how would you feel about actually using a C++ library that contained
absolutely NO templates or exceptions?
Imaging the library in question provided a vary basic and "low-level"
interface. Something along the lines of pointer-FILLED stuff like the
following:
<very crude pseudo-code>
struct DoubleLink {
DoubleLink *m_Next;
DoubleLink *m_Prev;
};

class DoubleList {
DoubleLink *m_Front;
DoubleLink *m_Back;

public:
DoubleList() : m_Front(0), m_Back(0) {}

public:
void PushFront(DoubleLink *Link) {
//.
}
void PushBack(DoubleLink *Link) {
//.
}

DoubleLink* Pop(DoubleLink *Link) {
//.
return Link;
}

DoubleLink* PopFront() {
return Pop(m_Front);
}

DoubleLink* PopBack() {
return Pop(m_Back);
}

void MergeFront(DoubleList *Src) {
//..
}

void MergeBack(DoubleList *Src) {
//..
}
};


Would all of those pointers scare most C++ programmers away? I am NOT a
troll. I simply want to know how "useable and/or popular" a C++ library
geared towards the embedded environment is?
How many C++ programmers would say my library is fuc$king CRAP because it
uses no templates?

I am a C programmer at heart and I don't like my "hard-core" C++ skills that
much. Luckily for me! C++ can be a so-called perfect fit for me. I managed
to build 85% of my allocator in pure standard old-school C++, before
templates, and all that fancy stuff came into play.
I wanted to scrap the C++ project for C. But, I figured HEY! I don't HAVE to
misuse every feature of the modern C++ language. I am C; therefore I use C++
at bare bones level, suitable for embedded and operating system level work.
Can I actually get away with using, or misusing!, C++ this way?
Or, should I follow my initial urges to switch to C?
I am 100% comfortable with C++ at a nice low-level. I can use RAII without
templates. I can use encapsulation without any template fancy functor
classes.
ect.ect.
Any thoughts/suggestions/comments are encouraged and welcome!

P.S.

This is not a trolling attempt!!!

Please bear with be here. I would love to "master" C++ at a higher lever,
but, for the moment, I am right at home with old-school vanilla C++ style.
No templates, and TONS of pointers!

:^O

???

Thanks for all of your time in advance. Now try not to flame me too BAD!

:^)

[Ian Collins]

Chris Thomasson wrote:

I am almost ready to post an initial prototype of my C++ memory allocator
library:

http://groups.google.com/group/comp....eee1f61fdbb52c

Anyway, I think my C programming skills are "forceing" there way into my
current design. Yes, it's low-level at its core, but I want to get some of
your thoughts on the issue of using only the "bare-bones" of the C++
language; think embedded, embedded, embedded! ;^)

Well, how would you feel about actually using a C++ library that contained
absolutely NO templates or exceptions?

Imaging the library in question provided a vary basic and "low-level"
interface. Something along the lines of pointer-FILLED stuff like the
following:

Not me, pointers belong in C, C++ has safer ways of handling resources.

--
Ian Collins.

[Chris Thomasson]

"Ian Collins" <ia******@hotmail.comwrote in message
news:58**************@mid.individual.net...

Chris Thomasson wrote:

>I am almost ready to post an initial prototype of my C++ memory allocator
library:

[...]

>in C, C++ has safer ways of handling resources.

Agreed. The source-code for my prototype allocator makes extensive use of
RAII. I just happen to not be using templates for this stage of the
prototyping process; that's all... Also, I don't use exceptions. I want the
allocator to be able to fit into "various low-level embedded" environments.
I KNOW C can do it, and I know C++ can do it better... Well, C code is as it
is. C++ is as it is when you use it at a low-level. C++ is not at it is,
IMHO and PURELY BIASED C perspective , when it "automatically" adds function
pointer tables to your abstract data-structures! Virtual tables are used
everywhere in C:

http://groups.google.com/group/comp....f857051ca4029b

C++ is the same way at its root... Clever template tricks are fun:

http://groups.google.com/group/comp....305cb99ad5a24b

I can do that I guess... But, then I am dealing with a sort of
"implementation" issue. Think of your company wants does not want any aspect
of the source code to be made public... Templates technically do expose
so-called source-code to the public... I know C++ and Assembly Language is
the right answer for what I am doing now, IMHO, Assembly, then C is
perfect... But C++ is the exact same way... Less typing, and ease of mind
that RAII brings to the table...

;^)
I use RAII by customizing a plurality of "so-called" helper objects that
allow me to fairly customize aspects of immediate resource management as a
whole.

I am targeting embedded stuff because the memory allocator algorithm I
created can be solely based on the memory that makes up the data-structures
under the stacks of your applications threads.

Think of an environment that does not support a heap. I can do memory
allocator based on threads "dedicated and 'spare' " stack space. C++ is
low-level enough to get the job done. C is good. C++ can be just as
low-level, and a bit more confinement as well... Of course C++ convenience
(e.g., RAII) can be used at a low-level without adding unnecessary
overheads. Templates mixed with a very crappy compiler can technically
produce bloat. However, that's clearly a bug and/or poor programming style.
I don't want to use misuse templates. I am happy with C++ closeness with C.
Just a testament to the flexibility of the C++ programming language! ;^)
I can use RAII and pointers to get the job done in a very limited space...
Embedded C++, stripped down bare-bones standard library features...
Exceptions can be frowned upon in the early stages of operating system
lifetimes... Luckily C++ allows us to use it in that type of situation; no
problem indeed.

[Chris Thomasson]

"Chris Thomasson" <cr*****@comcast.netwrote in message
news:86******************************@comcast.com. ..

"Ian Collins" <ia******@hotmail.comwrote in message
news:58**************@mid.individual.net...

>Chris Thomasson wrote:

>>I am almost ready to post an initial prototype of my C++ memory
allocator
library:

[...]

>>in C, C++ has safer ways of handling resources.

Agreed. The source-code for my prototype allocator makes extensive use of
RAII. I just happen to not be using templates for this stage of the
prototyping process; that's all... Also, I don't use exceptions. I want
the allocator to be able to fit into "various low-level embedded"
environments. I KNOW C can do it, and I know C++ can do it better... Well,
C code is as it is. C++ is as it is when you use it at a low-level. C++ is
not at it is, IMHO and PURELY BIASED C perspective , when it
"automatically" adds function pointer tables to your abstract
data-structures! Virtual tables are used everywhere in C:

http://groups.google.com/group/comp....f857051ca4029b

C++ is the same way at its root... Clever template tricks are fun:

I am so used to C, that alls I basically see when I look through some of my
source-code here:

http://groups.google.com/group/comp....305cb99ad5a24b

is something like:

typedef struct funcall_s funcall_t;
typedef struct params_s params_t;
typedef void* (*fpcall_t) (void*);

struct params_s {
char param_depth;
char param_offset;
char param_count;
char reserved_for_future_use;
};

struct funcall_s {
fpcall_t fpcall;
params_t params;
unsigned char *param_membase;
};

/*

api goes here...

*/

humm...

[wij]

On 4¤ë11¤é, ¤W¤È10®É40¤À, "Chris Thomasson" <[e-mail]:

"Ian Collins" <[e-mail] in message

news:58**************@mid.individual.net...

Chris Thomasson wrote:

I am almost ready to post an initial prototype of my C++ memory allocator
library:

[...]

in C, C++ has safer ways of handling resources.

Agreed. The source-code for my prototype allocator makes extensive use of
RAII. I just happen to not be using templates for this stage of the
prototyping process; that's all... Also, I don't use exceptions. I want the
allocator to be able to fit into "various low-level embedded" environments.
I KNOW C can do it, and I know C++ can do it better... Well, C code is asit
is. C++ is as it is when you use it at a low-level. C++ is not at it is,
IMHO and PURELY BIASED C perspective , when it "automatically" adds function
pointer tables to your abstract data-structures! Virtual tables are used
everywhere in C:

I agree with the point of view from C.
You might like to see another non-truly "C BIASED" program.
http://sourceforge.net/project/downl...2.tgz&23664328

[anon]

Chris Thomasson wrote:

>

Well, how would you feel about actually using a C++ library that contained
absolutely NO templates or exceptions?

You can live without templates, but it would be crippled without exceptions.

>
Would all of those pointers scare most C++ programmers away? I am NOT a
troll. I simply want to know how "useable and/or popular" a C++ library
geared towards the embedded environment is?

We wrote our programs for our embedded platform (i386 CPU with Linux
running on it). I do not see why it has to be C for embedded stuff

[Roland Pibinger]

On Tue, 10 Apr 2007 17:52:41 -0700, "Chris Thomasson" wrote:

>I am almost ready to post an initial prototype of my C++ memory allocator
library:

Well, how would you feel about actually using a C++ library that contained
absolutely NO templates or exceptions?

Haven't looked at you library but in general I'd prefer any good C
library to a mediocre C++ library. C++ is a multi-paradigm language
which means that there are also multiple C++ styles.

>How many C++ programmers would say my library is fuc$king CRAP because it
uses no templates?

The very modest success of heavy templated stuff ('Boost' programming)
in the real world supports your point of view. Templates are sometimes
used in application programming (esp. for containers) but hardly ever
created.

>I am a C programmer at heart and I don't like my "hard-core" C++ skills that
much. Luckily for me! C++ can be a so-called perfect fit for me. I managed
to build 85% of my allocator in pure standard old-school C++, before
templates, and all that fancy stuff came into play.

What does 'old-school' mean for multi-paradigm language?

>I wanted to scrap the C++ project for C. But, I figured HEY! I don't HAVE to
misuse every feature of the modern C++ language. I am C; therefore I use C++
at bare bones level, suitable for embedded and operating system level work.

That's perfectly valid. As long as it compiles with a C++ compiler it
is C++.

>Can I actually get away with using, or misusing!, C++ this way?

I guess the mostly used C++ variant in the real world is C/C++, i.e. C
enhanced with classes. This style of programming often misses
important advantages of C++ (esp. exception handling with RAII) but it
is prevalent.

>Or, should I follow my initial urges to switch to C?

Maybe. Your library would be usable in a C program.
Many libraries are written in C (actually most libraries a typical C++
programmer uses are written in C) and provide a thin C++ wrapper.

>I am 100% comfortable with C++ at a nice low-level. I can use RAII without
templates. I can use encapsulation without any template fancy functor
classes.

You seem to associate templates with 'good' C++ propgramming. IMO,
this is absolutely not the case, on the contrary.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Mirek Fidler]

On Apr 11, 2:52 am, "Chris Thomasson" <[e-mail]:

I am almost ready to post an initial prototype of my C++ memory allocator
library:

http://groups.google.com/group/comp..../thread/beeee1...

BTW, I have tried very quickly to get a clue about what are you trying
to do. It seems to me that you are about to implement memory allocator
using only atomic operations like CAS, right?

IME/IMO, for the real performance, the much more fruitful approach is
per-thread cache of blocks. If you have one, locking of allocator
structures in negligible.

Mirek

[Ian Collins]

Mirek Fidler wrote:

On Apr 11, 2:52 am, "Chris Thomasson" <[e-mail]:

>>I am almost ready to post an initial prototype of my C++ memory allocator
library:

http://groups.google.com/group/comp..../thread/beeee1...

BTW, I have tried very quickly to get a clue about what are you trying
to do. It seems to me that you are about to implement memory allocator
using only atomic operations like CAS, right?

IME/IMO, for the real performance, the much more fruitful approach is
per-thread cache of blocks. If you have one, locking of allocator
structures in negligible.

Solaris libumem is worth a look:

http://www.usenix.org/event/usenix01...tml/index.html

--
Ian Collins.

[Chris Thomasson]

"Mirek Fidler" <cx*@ntllib.orgwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...

On Apr 11, 2:52 am, "Chris Thomasson" <[e-mail]:

>I am almost ready to post an initial prototype of my C++ memory allocator
library:

http://groups.google.com/group/comp..../thread/beeee1...

BTW, I have tried very quickly to get a clue about what are you trying
to do. It seems to me that you are about to implement memory allocator
using only atomic operations like CAS, right?

It only uses atomic operations when a thread tries to free a block of memory
that it did not allocate itself... Here is some more information on the
allocator algorithm I invented:

http://groups.google.com/group/comp....c40d42a04ee855

http://appcore.home.comcast.net/vzoom/round-2.pdf
(section 1.1)

IME/IMO, for the real performance, the much more fruitful approach is
per-thread cache of blocks. If you have one, locking of allocator
structures in negligible.

Agreed. The allocator is strictly based on per-thread pool of memory. It
doesn't use any global pointers. The memory can be allocated on the threads
stack. A thread makes allocations without using atomic operations, and makes
deallocations without using atomic ops if the deallocated block belongs to
it.
___

http://appcore.home.comcast.net/vzoom/round-1.pdf

[Mirek Fidler]

Agreed. The allocator is strictly based on per-thread pool of memory. It

doesn't use any global pointers. The memory can be allocated on the threads
stack. A thread makes allocations without using atomic operations, and makes
deallocations without using atomic ops if the deallocated block belongs to
it.

Do you have in state with simple "connection points" like "alloc/
free"?

I have quite nice allocator designed for U++ and heavy multithreaded
application to test with. I would enjoy plugging your code for
comparative benchmark.

Mirek

[Chris Thomasson]

"Ian Collins" <ia******@hotmail.comwrote in message
news:58**************@mid.individual.net...

Chris Thomasson wrote:

>I am almost ready to post an initial prototype of my C++ memory allocator
library:

[...]

Not me, pointers belong in C, C++ has safer ways of handling resources.

Well, what do you think of my C++ skills? ;^)

Here are some examples:

http://appcore.home.comcast.net/vzoo...cope-guard.cpp

http://appcore.home.comcast.net/vzoom/refcount/
(look at the c++ smart-pointer wrapper for the asm code...)

Any thoughts?