468,512 Members | 1,382 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,512 developers. It's quick & easy.

how to use STL library in c language

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 ....

Jul 14 '06 #1
18 4244
um******@gmail.com wrote:
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.
Jul 14 '06 #2
um******@gmail.com wrote:
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.

--
Ian Collins.
Jul 14 '06 #3
um******@gmail.com 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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 14 '06 #4
Ian Collins wrote:
um******@gmail.com wrote:
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.

--
Ian Collins.
Not that it is on topic, but assuming <vectorwas chosen with any care
at all a linked list is a poor replacement. <vectoris 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

Jul 14 '06 #5

Martin Ambuhl wrote:
um******@gmail.com wrote:
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++.
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

Jul 14 '06 #6
Tom St Denis said:

<snip>
>
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 14 '06 #7
"David Resnick" <ln********@gmail.comwrites:
Ian Collins wrote:
um******@gmail.com wrote:
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.

--
Ian Collins.

Not that it is on topic, but assuming <vectorwas chosen with any care
at all a linked list is a poor replacement. <vectoris 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

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Jul 14 '06 #8
"David Resnick" <ln********@gmail.comwrites:
Ian Collins wrote:
um******@gmail.com wrote:
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.

--
Ian Collins.

Not that it is on topic, but assuming <vectorwas chosen with any care
at all a linked list is a poor replacement. <vectoris 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.

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Jul 14 '06 #9

Nelu wrote:
"David Resnick" <ln********@gmail.comwrites:

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

Jul 14 '06 #10
"David Resnick" <ln********@gmail.comwrites:
Nelu wrote:
"David Resnick" <ln********@gmail.comwrites:

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.
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.

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Jul 14 '06 #11
On 2006-07-14, Nelu <sp*******@gmail.comwrote:
"David Resnick" <ln********@gmail.comwrites:
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.
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.

--
Andrew Poelstra <http://www.wpsoftware.net/projects/>
To email me, use "apoelstra" at the above domain.
"You people hate mathematics." -- James Harris
Jul 14 '06 #12
Andrew Poelstra <ap*******@nowhereat.allwrites:
On 2006-07-14, Nelu <sp*******@gmail.comwrote:
"David Resnick" <ln********@gmail.comwrites:
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.

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?

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Jul 14 '06 #13
On 2006-07-14, Nelu <sp*******@gmail.comwrote:
Andrew Poelstra <ap*******@nowhereat.allwrites:
>On 2006-07-14, Nelu <sp*******@gmail.comwrote:
"David Resnick" <ln********@gmail.comwrites:
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.

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?
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).

--
Andrew Poelstra <http://www.wpsoftware.net/projects/>
To email me, use "apoelstra" at the above domain.
"You people hate mathematics." -- James Harris
Jul 14 '06 #14
Andrew Poelstra <ap*******@nowhereat.allwrites:
On 2006-07-14, Nelu <sp*******@gmail.comwrote:
Andrew Poelstra <ap*******@nowhereat.allwrites:
On 2006-07-14, Nelu <sp*******@gmail.comwrote:
"David Resnick" <ln********@gmail.comwrites:
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.


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?

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.

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Jul 14 '06 #15
David Resnick wrote:
Ian Collins wrote:
>>um******@gmail.com wrote:
>>>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.

Not that it is on topic, but assuming <vectorwas chosen with any care
at all a linked list is a poor replacement. <vectoris 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.

--
Ian Collins.
Jul 14 '06 #16
REH

"Martin Ambuhl" <ma*****@earthlink.netwrote in message
news:4h***********@individual.net...
um******@gmail.com 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
Jul 15 '06 #17
On 2006-07-14, Ian Collins <ia******@hotmail.comwrote:
David Resnick wrote:
>Ian Collins wrote:
>>>um******@gmail.com wrote:

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.

Not that it is on topic, but assuming <vectorwas chosen with any care
at all a linked list is a poor replacement. <vectoris 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.
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.
Jul 15 '06 #18
<um******@gmail.comwrote in message
news:11*********************@75g2000cwc.googlegrou ps.com...
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

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

Jul 17 '06 #19

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Torbak | last post: by
43 posts views Thread by Steven T. Hatton | last post: by
4 posts views Thread by Chris F Clark | last post: by
87 posts views Thread by Robert Seacord | last post: by
9 posts views Thread by vasudevram | last post: by
20 posts views Thread by Frank-O | last post: by
20 posts views Thread by J de Boyne Pollard | last post: by
24 posts views Thread by Aaron Gray | last post: by
reply views Thread by NPC403 | last post: by
1 post views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.