how to use STL library in c language

[umarriaz]

Dear All,
I am using this code in my c++ code and now i want to use this same
code for a c language project...
would some one please guide me what to do ??

===============================================================
#include "stdafx.h"
#include <vector> // for vector STL

using namespace std; // required

// for testing
struct MODEM
{
int index;
int snumber;
char flag;
};

int main(int argc, char* argv[])
{
vector<MODEM*> v; // vector is defined in STL (working as dynamic
array)

// mem allocate for modem structure
MODEM* test = (MODEM*)malloc(sizeof(MODEM));

// test values
test->index = 1;
test->snumber = 5556;
test->flag = 'p';

// vector array dynamically grow (index 0)
v.push_back(test);


// now get back the second modem values
MODEM* temp = v[0];

printf("MODEM[1] Index Value %d\n", temp->index);
printf("MODEM[1] Serial Number Value %d\n", temp->snumber);
printf("MODEM[1] Flag Value %c\n", temp->flag);
return 0;
}
=============================================================

waiting for an urgent response ....

 

[Martin Ambuhl]

Dear All,
I am using this code in my c++ code and now i want to use this same
code for a c language project...
would some one please guide me what to do ??

Learn C. Why you think the obfuscations of C++ should be part of C is a
mystery.

There is no "stdafx.h" in either C nor C++, although your implementation
may provide one, so anything related to "stdafx.h" belongs in an
implementation-specific newsgroup, not one for C or C++.

C has no STL, <vector>, "using" statement (which is, BTW, *not* required
for your C++ program, no matter what you write in your comments), no
types with names like foo<bar> (so obviously no members index, snumber,
or flag), and no functions named v.push_back.

Casting the return value of malloc is bad style in C; using malloc
without a declaration is a sin, even in C89 where it would be
interpreted falsely as returning an int.

 

[Ian Collins]

Dear All,
I am using this code in my c++ code and now i want to use this same
code for a c language project...

Looks like a mish mash of a hybrid.

Just use a linked list where you use vector.

 

[Richard Heathfield]

(e-mail address removed) said:

Dear All,
I am using this code in my c++ code and now i want to use this same
code for a c language project...
would some one please guide me what to do ??

Step 1: throw away your code.
Step 2: learn C++, so that you understand why "stdafx.h" is not part of the
language, but part of the pollution that your badly-designed IDE has
crufted into your program, but which can easily be removed. Dealing with
the consequences of that removal is off-topic here, but that's pretty easy
to do too.
Step 3: learn C.
Step 4: write your code properly in C.

 

[David Resnick]

Looks like a mish mash of a hybrid.

Just use a linked list where you use vector.

Not that it is on topic, but assuming <vector> was chosen with any care
at all a linked list is a poor replacement. <vector> is generally
selected because random access is wanted, or at least random access is
more important than poor performance when inserting new elements.

I think OP should consider just using a malloc'd array and reallocing
it when needed. If you are only adding to the end, this isn't very
bad, just grow it (say by a factor of two) when you are adding things
and no longer have room and you should be fine. You just need a couple
of variables for bookkeeping, say the current allocated size of the
array and the current last element. for example, you could have this:

struct modem_array {
size_t last_element_index;
size_t allocated_size;
MODEM **array;
};

When you want to add an element, see if the last_element_index + 1 ==
allocated_size, if so use realloc to double the size of the array,
update the allocated_size field, and you are set.

You could also write pretty easily a generic set of utility functions
that handles dynamic arrays of void* pointers and use that for this and
other projects...

-David

 

[Tom St Denis]

Learn C. Why you think the obfuscations of C++ should be part of C is a
mystery.

There is no "stdafx.h" in either C nor C++, although your implementation
may provide one, so anything related to "stdafx.h" belongs in an
implementation-specific newsgroup, not one for C or C++.

IIRC "stdafx.h" is the default header that VS produces for C++
projects. It's where you are supposed to put your windows header
includes in I think...

[it's also the first file I remove from my VS projects...]

Tom

 

[Richard Heathfield]

Tom St Denis said:

IIRC "stdafx.h" is the default header that VS produces for C++
projects.

IIRC it's only required if you are using pre-compiled headers, which is one
excellent reason for turning pre-compiled headers OFF.

[it's also the first file I remove from my VS projects...]

I simply don't bother inserting it in the first place.

 

[Nelu]

Not that it is on topic, but assuming <vector> was chosen with any care
at all a linked list is a poor replacement. <vector> is generally
selected because random access is wanted, or at least random access is
more important than poor performance when inserting new elements.

I think OP should consider just using a malloc'd array and reallocing
it when needed. If you are only adding to the end, this isn't very
bad, just grow it (say by a factor of two) when you are adding things
and no longer have room and you should be fine. You just need a couple
of variables for bookkeeping, say the current allocated size of the
array and the current last element. for example, you could have this:

struct modem_array {
size_t last_element_index;
size_t allocated_size;
MODEM **array;
};

When you want to add an element, see if the last_element_index + 1 ==
allocated_size, if so use realloc to double the size of the array,
update the allocated_size field, and you are set.

You could also write pretty easily a generic set of utility functions
that handles dynamic arrays of void* pointers and use that for this and
other projects...

But that means copying all the elements for every new allocation and
it's getting worse

 

[Nelu]

Not that it is on topic, but assuming <vector> was chosen with any care
at all a linked list is a poor replacement. <vector> is generally
selected because random access is wanted, or at least random access is
more important than poor performance when inserting new elements.

I think OP should consider just using a malloc'd array and reallocing
it when needed. If you are only adding to the end, this isn't very
bad, just grow it (say by a factor of two) when you are adding things
and no longer have room and you should be fine. You just need a couple
of variables for bookkeeping, say the current allocated size of the
array and the current last element. for example, you could have this:

struct modem_array {
size_t last_element_index;
size_t allocated_size;
MODEM **array;
};

When you want to add an element, see if the last_element_index + 1 ==
allocated_size, if so use realloc to double the size of the array,
update the allocated_size field, and you are set.

You could also write pretty easily a generic set of utility functions
that handles dynamic arrays of void* pointers and use that for this and
other projects...

I hit send by mistake on the last follow-up. Sorry.
Implementing vector like that can make it slower to allocate new
memory as the array grows because all the elements must be copied to
the new location (if a new location is required) and some systems may
refuse to reallocate memory if it gets too fragmented.
Another way would be to have an array that holds arrays of the same
size (predefined) and whenever you add something new and the arrays
are full you just reallocate the array that holds them (which is
smaller) and add a new array there. This way realloc has less elements
to copy (only the index array) and you allocate smaller chunks instead
of reallocating one huge array. Also you don't need to have to memory
zones occupied at the same time until the copy completes.

 

[David Resnick]

I hit send by mistake on the last follow-up. Sorry.
Implementing vector like that can make it slower to allocate new
memory as the array grows because all the elements must be copied to
the new location (if a new location is required) and some systems may
refuse to reallocate memory if it gets too fragmented.
Another way would be to have an array that holds arrays of the same
size (predefined) and whenever you add something new and the arrays
are full you just reallocate the array that holds them (which is
smaller) and add a new array there. This way realloc has less elements
to copy (only the index array) and you allocate smaller chunks instead
of reallocating one huge array. Also you don't need to have to memory
zones occupied at the same time until the copy completes.

Yeah, but (off topic) if you are trying to simulate a C++ <vector>
you have to do that I think. C++ mandates that there be an underlying
normal array for a STL <vector>, or at least that it behave as such.
For example, if you take the address of the zeroth element of a vector,
you get a pointer to the underlying array that is allowed to be used
in normal array context (pointer arithmetic/etc). Hard to fake that
in a way you described above. e.g. see Josuttis's "The C++ Standard
Library" section 6.2.3 Using Vectors ad Ordinary Arrays.

Behavior of a dynamic array if you double its size with each forced
realloc isn't too
bad usually, particularly for an array of pointers rather than an array
of objects.

-David

 

[Nelu]

Yeah, but (off topic) if you are trying to simulate a C++ <vector>
you have to do that I think. C++ mandates that there be an underlying
normal array for a STL <vector>, or at least that it behave as such.
For example, if you take the address of the zeroth element of a vector,
you get a pointer to the underlying array that is allowed to be used
in normal array context (pointer arithmetic/etc). Hard to fake that
in a way you described above. e.g. see Josuttis's "The C++ Standard
Library" section 6.2.3 Using Vectors ad Ordinary Arrays.

I didn't know that about vector. I haven't used C++ much and haven't
used STL at all (a little MFC and Qt). However if you use vector in
C++ that's to avoid using array so a similar class in C doesn't
necessarily need to provide access to the underlying structure .

Behavior of a dynamic array if you double its size with each forced
realloc isn't too
bad usually, particularly for an array of pointers rather than an array
of objects.

The problem with doubling the size is that you get to waste a lot of
memory at some point. JAVA does the same thing with HashMap, I
believe.

 

[Andrew Poelstra]

The problem with doubling the size is that you get to waste a lot of
memory at some point. JAVA does the same thing with HashMap, I
believe.

Define "a lot of memory". At the very most you will use (n-1)*2 bytes
of memory, where n is the number of items in your list. Since that
occurance will happen log_2m/m percent of the time (where m is some
theorietical maximum), you will almost certainly be wasting much less
memory.

Since statistically, 50% of numbers can be rounded down to a power of
two while 50% will be rounded up, on average your list will waste
n / 3 bytes, which isn't too terrible a waste considering the efficiency
of multiple allocations.

 

[Nelu]

Define "a lot of memory". At the very most you will use (n-1)*2 bytes
of memory, where n is the number of items in your list. Since that
occurance will happen log_2m/m percent of the time (where m is some
theorietical maximum), you will almost certainly be wasting much less
memory.

Since statistically, 50% of numbers can be rounded down to a power of
two while 50% will be rounded up, on average your list will waste
n / 3 bytes, which isn't too terrible a waste considering the efficiency
of multiple allocations.

I was thinking about an array of objects (not pointers).

Why (n-1)*2?

 

[Andrew Poelstra]

I was thinking about an array of objects (not pointers).

Why (n-1)*2?

If there are 128 bytes, you've allocated 128 bytes.
If there are 129 bytes, you've allocated 256 bytes.

(You only reallocate once you've reached max+1 items).

 

[Nelu]

If there are 128 bytes, you've allocated 128 bytes.
If there are 129 bytes, you've allocated 256 bytes.

(You only reallocate once you've reached max+1 items).

Yes. I was looking at n and didn't read your text properly. Sorry.

 

[Ian Collins]

Not that it is on topic, but assuming <vector> was chosen with any care
at all a linked list is a poor replacement. <vector> is generally
selected because random access is wanted, or at least random access is
more important than poor performance when inserting new elements.

The thing is, we don't know what the OP wants to do. If he wants to
store and iterates though a group of objects, a list is a good choice.
If he wants random access and isn't too concerned about the cost of
insertions, then it isn't.

We just don't know.

 

[REH]

(e-mail address removed) wrote:
C has no STL, <vector>, "using" statement (which is, BTW, *not* required
for your C++ program, no matter what you write in your comments).

Actually, as written, the using directive (not statement) is required for
his program. Which is why you should have just said OT and be done with it.

REH

 

[Ben C]

The thing is, we don't know what the OP wants to do. If he wants to
store and iterates though a group of objects, a list is a good choice.
If he wants random access and isn't too concerned about the cost of
insertions, then it isn't.

We just don't know.

We do know that he used std::vector rather than std::list, so based on
that, better to replace it with an array than with a linked list.

 

[Stephen Sprunk]

Dear All,
I am using this code in my c++ code and now i want to use this same
code for a c language project...
would some one please guide me what to do ??

As the name implies, the Standard Template Library requires templates. C
does not have templates. Therefore, the STL cannot be used with C. QED.

S