C++ language knows nothing of DLLs. Your first error there is trying
to expose C++ - specific (and not only that, but potentially
particular compiler and standard library version version specific)
interface out of your module.
This is such a massive no-no that it's not even funny. You can only do
that if all modules will be compiled with same compiler (version,
too), and if interface uses standard library, if modules will use same
standard library version and even compilation options. For example,
with STL shipped with VS, compiling a DLL exposing standard containers
in it's interface with/without SECURE_STL breaks low-level binary
compatibility for any container.
It's not a question of liking at all. This sort of interoperability
works only under very specific circumstances (e.g. if you control, or
at least mandate, the build process and the deployment process
__entirely__).
Goran.
on 20/08/2010 01:06:51 said:Vladimir Jovic wrote:
thomas wrote:
Hi, I need your help.
----------
struct SvrList{
unsigned int uNum;
GameSvr svr[0]; //line A
};
---------
Once I declared a struct like this to store server list info.
It's supposed to be used like this.
----------
SvrList* pList = (SvrList*)malloc(sizeof(
SvrList) + svrNum*sizeof(GameSvr));
pList->uNum, pList->svr[0], pList->svr[1].... blabla..
I wouldn't call this fine. Even
pList->svr[0]
is accessing the element that is out of array's bounds, and
that is UB. How come your program is not crashing, or at
least going crazy? Maybe you are just unlucky to have a bug
hidden.
It's an old C programmers hack. I've come across this idiom in
lot's old C code, particularly driver and os code. Microsoft
Win32 is rife with it.
Except that it's not legal C, either. The C language was
carefully specified so that a bounds checking implementation
would be legal, and the above will fail in such cases.
In C++, of course, the declaration he's looking for is
std::vector<SvrList>, without any manual new.But I hate vectors. Different distributors may have different
implementations. When I pass vectors between dlls, things unexpected
may happen.
You could define interfaces using "C" linkage and send out vectors as
arrays by simply passing the address of the first element and the size
of the vector, just to make the communication layer happy and compatible.
On Aug 20, 2:01 am, Andrey Tarasevich <[email protected]>
wrote:
Pete Becker wrote:
Hi, I need your help.
----------
struct SvrList{
unsigned int uNum;
GameSvr svr[0]; //line A
};
---------
Once I declared a struct like this to store server list info.
It's supposed to be used like this.
----------
SvrList* pList = (SvrList*)malloc(sizeof(
SvrList) + svrNum*sizeof(GameSvr));
pList->uNum, pList->svr[0], pList->svr[1].... blabla..
I wouldn't call this fine. Even
pList->svr[0]
is accessing the element that is out of array's bounds, and
that is UB. How come your program is not crashing, or at
least going crazy? Maybe you are just unlucky to have a bug
hidden.
It's an old C programmers hack. I've come across this idiom in
lot's old C code, particularly driver and os code. Microsoft
Win32 is rife with it.
Except that it's not legal C, either.
Which is why it's referred to above as a "hack". Quite a common one, too.
Usually we use the term "hack" when the code relies on a specific
manifestation of undefined (or unspecified) behavior, but otherwise is
well-formed.
In this case the code is ill-formed, since 0-size array declaration is
illegal in C++ (as well as in C). In other words, arguing about the "out
of bounds" access here doesn't make much sense, since the code is
formally non-compilable.
Wait.. I don't think it's illegal in C++. At least I will definitely
object making it illegal by the standard community.
It can be dangerous but it can also do good. It depends on whether we
are using it correctly.
Will you guys getting crazy if we do things like this
-------code-----
struct A{
int num;
int p[0];};
A *pA = (A*)malloc(sizeof(A)+sizeof(int)*10);
printf("%d\n", &pA->p[10] - &pA->p[0]); //accessing out of
bounds.
------code---Crazy? Why? C++ compilers should not simply compile it by language
rules that does not allow zero-sized arrays. If a compiler compiles it
then it is non-standard extension.I have seen similar C code, but that used "int p[1];". If it was
compiled with C++ compiler and run-time bounds-checking on then it did
fault when accessing anything but p[0].In C++ you should use vector<int> instead, it is about as fast.
I hate vectors, again. C++ is not portable as binary code.
Passing vectors as arguments out of a dll in windows may crash the
system when accessing it.
On Aug 20, 2:01 am, Andrey Tarasevich <[email protected]>
wrote:
Pete Becker wrote:
Hi, I need your help.
----------
struct SvrList{
unsigned int uNum;
GameSvr svr[0]; //line A
};
---------
Once I declared a struct like this to store server list info.
It's supposed to be used like this.
----------
SvrList* pList = (SvrList*)malloc(sizeof(
SvrList) + svrNum*sizeof(GameSvr));
pList->uNum, pList->svr[0], pList->svr[1].... blabla..
I wouldn't call this fine. Even
pList->svr[0]
is accessing the element that is out of array's bounds, and
that is UB. How come your program is not crashing, or at
least going crazy? Maybe you are just unlucky to have a bug
hidden.
It's an old C programmers hack. I've come across this idiom in
lot's old C code, particularly driver and os code. Microsoft
Win32 is rife with it.
Except that it's not legal C, either.
Which is why it's referred to above as a "hack". Quite a common one, too.
Usually we use the term "hack" when the code relies on a specific
manifestation of undefined (or unspecified) behavior, but otherwise is
well-formed.
In this case the code is ill-formed, since 0-size array declaration is
illegal in C++ (as well as in C). In other words, arguing about the "out
of bounds" access here doesn't make much sense, since the code is
formally non-compilable.
Wait.. I don't think it's illegal in C++. At least I will definitely
object making it illegal by the standard community.
It can be dangerous but it can also do good. It depends on whether we
are using it correctly.
Will you guys getting crazy if we do things like this
-------code-----
struct A{
int num;
int p[0];};
A *pA = (A*)malloc(sizeof(A)+sizeof(int)*10);
printf("%d\n", &pA->p[10] - &pA->p[0]); //accessing out of
bounds.
------code---
Crazy? Why? C++ compilers should not simply compile it by language
rules that does not allow zero-sized arrays. If a compiler compiles it
then it is non-standard extension.
I have seen similar C code, but that used "int p[1];". If it was
compiled with C++ compiler and run-time bounds-checking on then it did
fault when accessing anything but p[0].
In C++ you should use vector<int> instead, it is about as fast.I hate vectors, again. C++ is not portable as binary code.
Passing vectors as arguments out of a dll in windows may crash the
system when accessing it.
Assuming binary compatibility without effort is wrong anyway. Are you
seriously claiming that such originally-posted hacks let you to
achieve binary compatibility between modules compiled with different C
compilers and under different compilation options?
gotcha!
On Aug 20, 2:01 am, Andrey Tarasevich <[email protected]>
wrote:
Pete Becker wrote:
Hi, I need your help.
----------
struct SvrList{
unsigned int uNum;
GameSvr svr[0]; //line A
};
---------
Once I declared a struct like this to store server list info.
It's supposed to be used like this.
----------
SvrList* pList = (SvrList*)malloc(sizeof(
SvrList) + svrNum*sizeof(GameSvr));
pList->uNum, pList->svr[0], pList->svr[1].... blabla..
I wouldn't call this fine. Even
pList->svr[0]
is accessing the element that is out of array's bounds, and
that is UB. How come your program is not crashing, or at
least going crazy? Maybe you are just unlucky to have a bug
hidden.
It's an old C programmers hack. I've come across this idiom in
lot's old C code, particularly driver and os code. Microsoft
Win32 is rife with it.
Except that it's not legal C, either.
Which is why it's referred to above as a "hack". Quite a common one, too.
Usually we use the term "hack" when the code relies on a specific
manifestation of undefined (or unspecified) behavior, but otherwise is
well-formed.
In this case the code is ill-formed, since 0-size array declaration is
illegal in C++ (as well as in C). In other words, arguing about the "out
of bounds" access here doesn't make much sense, since the code is
formally non-compilable.
Wait.. I don't think it's illegal in C++. At least I will definitely
object making it illegal by the standard community.
It can be dangerous but it can also do good. It depends on whether we
are using it correctly.
Will you guys getting crazy if we do things like this
-------code-----
struct A{
int num;
int p[0];};
A *pA = (A*)malloc(sizeof(A)+sizeof(int)*10);
printf("%d\n", &pA->p[10] - &pA->p[0]); //accessing out of
bounds.
------code---
Crazy? Why? C++ compilers should not simply compile it by language
rules that does not allow zero-sized arrays. If a compiler compiles it
then it is non-standard extension.
I have seen similar C code, but that used "int p[1];". If it was
compiled with C++ compiler and run-time bounds-checking on then it did
fault when accessing anything but p[0].
In C++ you should use vector<int> instead, it is about as fast.
I hate vectors, again. C++ is not portable as binary code.
Passing vectors as arguments out of a dll in windows may crash the
system when accessing it.Assuming binary compatibility without effort is wrong anyway. Are you
seriously claiming that such originally-posted hacks let you to
achieve binary compatibility between modules compiled with different C
compilers and under different compilation options?
nope.. I mean using vectors in module interface may cause
interoperability problems.
My hack can solve the problem in case using the same padding policy
for modules involved.
None of the C or C++ standards allow an array size of 0.
C99 has flexible arrays (which do basically the same thing), but they
are not included in C++03. Unfortunately, it doesn't look like C99
flexible arrays are part of C++0x either. The somewhat good news is that
GCC, Visual C++ 2010 (and presumably Intel C++) do support them.
(GCC and Visual C++ support 0-sized arrays as extension.)
On Aug 20, 2:01 am, Andrey Tarasevich <[email protected]>
wrote:
Pete Becker wrote:
Hi, I need your help.
----------
struct SvrList{
unsigned int uNum;
GameSvr svr[0]; //line A
};
---------
Once I declared a struct like this to store server list info.
It's supposed to be used like this.
----------
SvrList* pList = (SvrList*)malloc(sizeof(
SvrList) + svrNum*sizeof(GameSvr));
pList->uNum, pList->svr[0], pList->svr[1].... blabla..
I wouldn't call this fine. Even
pList->svr[0]
is accessing the element that is out of array's bounds, and
that is UB. How come your program is not crashing, or at
least going crazy? Maybe you are just unlucky to have a bug
hidden.
It's an old C programmers hack. I've come across this idiom in
lot's old C code, particularly driver and os code. Microsoft
Win32 is rife with it.
Except that it's not legal C, either.
Which is why it's referred to above as a "hack". Quite a common one, too.
Usually we use the term "hack" when the code relies on a specific
manifestation of undefined (or unspecified) behavior, but otherwise is
well-formed.
In this case the code is ill-formed, since 0-size array declaration is
illegal in C++ (as well as in C). In other words, arguing about the "out
of bounds" access here doesn't make much sense, since the code is
formally non-compilable.
Wait.. I don't think it's illegal in C++. At least I will definitely
object making it illegal by the standard community.
It can be dangerous but it can also do good. It depends on whether we
are using it correctly.
Will you guys getting crazy if we do things like this
-------code-----
struct A{
int num;
int p[0];};
A *pA = (A*)malloc(sizeof(A)+sizeof(int)*10);
printf("%d\n", &pA->p[10] - &pA->p[0]); //accessing out of
bounds.
------code---
Crazy? Why? C++ compilers should not simply compile it by language
rules that does not allow zero-sized arrays. If a compiler compiles it
then it is non-standard extension.
I have seen similar C code, but that used "int p[1];". If it was
compiled with C++ compiler and run-time bounds-checking on then it did
fault when accessing anything but p[0].
In C++ you should use vector<int> instead, it is about as fast.
I hate vectors, again. C++ is not portable as binary code.
Passing vectors as arguments out of a dll in windows may crash the
system when accessing it.
Assuming binary compatibility without effort is wrong anyway. Are you
seriously claiming that such originally-posted hacks let you to
achieve binary compatibility between modules compiled with different C
compilers and under different compilation options?nope.. I mean using vectors in module interface may cause
interoperability problems.
My hack can solve the problem in case using the same padding policy
for modules involved.
If same options and same compiler are used then these interoperability
problems you refer to are likely because you add elements to vector or
attempt to destroy it outside of that windows dll context. Your hack
does not even let to add more elements to it (it is like
vector<GameSvr> const) and you may face same problems with C if you
free() it outside of that dll.
Öö Tiib said:In C++ you should use vector<int> instead, it is about as fast.
Vladimir Jovic said:What is wrong with next code?
struct SvrList{
unsigned int uNum;
GameSvr *svr;
};
...
SvrList list;
list.uNum = 5;
list.svr = (GameSvr*) malloc( list.uNum * sizeof( GameSvr ) );
...
Since someone pointed out that the original code is used for
performances reasons, how is this worse then the code in the first post?
Vladimir Jovic said:Yes, I must admit I missed that when I posted that code, but later I
realised what was done. The question is still valid : why was it
declared like array of zero size, and not like pointer?
Your point with operator[] doesn't stand (else thread), as you can use
it for pointers as well.
I like your words.
In my understanding, your points are:
1. using STL containers in module interface may cause interoperability
problems.
2. my zero-sized array is illegal in C++, so may also cause
interoperability problems.
Both should be avoided.
So the only way is to using pointers or one-sized array.
On Aug 20, 2:01 am, Andrey Tarasevich <[email protected]>
wrote:
Pete Becker wrote:
Hi, I need your help.
----------
struct SvrList{
unsigned int uNum;
GameSvr svr[0]; //line A
};
---------
Once I declared a struct like this to store server list info.
It's supposed to be used like this.
----------
SvrList* pList = (SvrList*)malloc(sizeof(
SvrList) + svrNum*sizeof(GameSvr));
pList->uNum, pList->svr[0], pList->svr[1].... blabla...
I wouldn't call this fine. Even
pList->svr[0]
is accessing the element that is out of array's bounds, and
that is UB. How come your program is not crashing, or at
least going crazy? Maybe you are just unlucky to have a bug
hidden.
It's an old C programmers hack. I've come across this idiom in
lot's old C code, particularly driver and os code. Microsoft
Win32 is rife with it.
Except that it's not legal C, either.
Which is why it's referred to above as a "hack". Quite a common one, too.
Usually we use the term "hack" when the code relies on a specific
manifestation of undefined (or unspecified) behavior, but otherwise is
well-formed.
In this case the code is ill-formed, since 0-size array declaration is
illegal in C++ (as well as in C). In other words, arguing about the "out
of bounds" access here doesn't make much sense, since the code is
formally non-compilable.
Wait.. I don't think it's illegal in C++. At least I will definitely
object making it illegal by the standard community.
It can be dangerous but it can also do good. It depends on whether we
are using it correctly.
Will you guys getting crazy if we do things like this
-------code-----
struct A{
int num;
int p[0];};
A *pA = (A*)malloc(sizeof(A)+sizeof(int)*10);
printf("%d\n", &pA->p[10] - &pA->p[0]); //accessing out of
bounds.
------code---
Crazy? Why? C++ compilers should not simply compile it by language
rules that does not allow zero-sized arrays. If a compiler compiles it
then it is non-standard extension.
I have seen similar C code, but that used "int p[1];". If it was
compiled with C++ compiler and run-time bounds-checking on then it did
fault when accessing anything but p[0].
In C++ you should use vector<int> instead, it is about as fast.
I hate vectors, again. C++ is not portable as binary code.
Passing vectors as arguments out of a dll in windows may crash the
system when accessing it.
Assuming binary compatibility without effort is wrong anyway. Are you
seriously claiming that such originally-posted hacks let you to
achieve binary compatibility between modules compiled with different C
compilers and under different compilation options?
nope.. I mean using vectors in module interface may cause
interoperability problems.
My hack can solve the problem in case using the same padding policy
for modules involved.If same options and same compiler are used then these interoperability
problems you refer to are likely because you add elements to vector or
attempt to destroy it outside of that windows dll context. Your hack
does not even let to add more elements to it (it is like
vector<GameSvr> const) and you may face same problems with C if you
free() it outside of that dll.
Right, but how about passing out the address of the pointer?
The point is adding more elements may make it necessary to move
existing elements elsewhere, so we may need to modify the pointer in
dll.
Actually passing pointers between functions may also cause this kind
of problems, nothing special to communication between DLLs.
In which system, exactly?
Unfortunately 'new' (and 'delete') is a rather heavy operation with
most C/C++ standard memory allocators, and if you use std::vector in
the place of the struct hack, you will be doing two 'news' instead of
one malloc().
Additionally, using std::vector there will increase memory fragmentation,
making things even worse.
On Aug 20, 2:01 am, Andrey Tarasevich <[email protected]>
wrote:
Pete Becker wrote:
Hi, I need your help.
----------
struct SvrList{
unsigned int uNum;
GameSvr svr[0]; //line A
};
---------
Once I declared a struct like this to store server list info.
It's supposed to be used like this.
----------
SvrList* pList = (SvrList*)malloc(sizeof(
SvrList) + svrNum*sizeof(GameSvr));
pList->uNum, pList->svr[0], pList->svr[1].... blabla..
I wouldn't call this fine. Even
pList->svr[0]
is accessing the element that is out of array's bounds, and
that is UB. How come your program is not crashing, or at
least going crazy? Maybe you are just unlucky to have a bug
hidden.
It's an old C programmers hack. I've come across this idiom in
lot's old C code, particularly driver and os code. Microsoft
Win32 is rife with it.
Except that it's not legal C, either.
Which is why it's referred to above as a "hack". Quite a common one, too.
Usually we use the term "hack" when the code relies on a specific
manifestation of undefined (or unspecified) behavior, but otherwise is
well-formed.
In this case the code is ill-formed, since 0-size array declaration is
illegal in C++ (as well as in C). In other words, arguing about the "out
of bounds" access here doesn't make much sense, since the code is
formally non-compilable.
Wait.. I don't think it's illegal in C++. At least I will definitely
object making it illegal by the standard community.
It can be dangerous but it can also do good. It depends on whether we
are using it correctly.
Will you guys getting crazy if we do things like this
-------code-----
struct A{
int num;
int p[0];};
A *pA = (A*)malloc(sizeof(A)+sizeof(int)*10);
printf("%d\n", &pA->p[10] - &pA->p[0]); //accessing out of
bounds.
------code---
Crazy? Why? C++ compilers should not simply compile it by language
rules that does not allow zero-sized arrays. If a compiler compiles it
then it is non-standard extension.
I have seen similar C code, but that used "int p[1];". If it was
compiled with C++ compiler and run-time bounds-checking on then it did
fault when accessing anything but p[0].
In C++ you should use vector<int> instead, it is about as fast.
I hate vectors, again. C++ is not portable as binary code.
Passing vectors as arguments out of a dll in windows may crash the
system when accessing it.
Assuming binary compatibility without effort is wrong anyway. Are you
seriously claiming that such originally-posted hacks let you to
achieve binary compatibility between modules compiled with different C
compilers and under different compilation options?
nope.. I mean using vectors in module interface may cause
interoperability problems.
My hack can solve the problem in case using the same padding policy
for modules involved.
If same options and same compiler are used then these interoperability
problems you refer to are likely because you add elements to vector or
attempt to destroy it outside of that windows dll context. Your hack
does not even let to add more elements to it (it is like
vector<GameSvr> const) and you may face same problems with C if you
free() it outside of that dll.Right, but how about passing out the address of the pointer?
The point is adding more elements may make it necessary to move
existing elements elsewhere, so we may need to modify the pointer in
dll.
Actually passing pointers between functions may also cause this kind
of problems, nothing special to communication between DLLs.
All problems i have seen people facing there are still about different
c runtimes or memory/resource contexts between DLL and application. So
it is not about passing pointers if you can not free() the thing it
points at since it was malloc()'ed by different memory management.
Vladimir Jovic wrote:
thomas wrote:
Hi, I need your help.
----------
struct SvrList{
unsigned int uNum;
GameSvr svr[0]; //line A
};
---------
Once I declared a struct like this to store server list info.
It's supposed to be used like this.
----------
SvrList* pList = (SvrList*)malloc(sizeof(
SvrList) + svrNum*sizeof(GameSvr));
pList->uNum, pList->svr[0], pList->svr[1].... blabla..
I wouldn't call this fine. Even
pList->svr[0]
is accessing the element that is out of array's bounds, and
that is UB. How come your program is not crashing, or at
least going crazy? Maybe you are just unlucky to have a bug
hidden.
It's an old C programmers hack. I've come across this idiom in
lot's old C code, particularly driver and os code. Microsoft
Win32 is rife with it.
Except that it's not legal C, either. The C language was
carefully specified so that a bounds checking implementation
would be legal, and the above will fail in such cases.
In C++, of course, the declaration he's looking for is
std::vector<SvrList>, without any manual new.
But I hate vectors. Different distributors may have different
implementations. When I pass vectors between dlls, things unexpected
may happen.
In which system, exactly?
Unfortunately 'new' (and 'delete') is a rather heavy operation with
most C/C++ standard memory allocators, and if you use std::vector in
the place of the struct hack, you will be doing two 'news' instead of
one malloc().
If that's everything you are doing, then there's no practical difference.
However, if you are instantiating a million objects of the struct type,
then it starts making a big difference.
Additionally, using std::vector there will increase memory fragmentation,
making things even worse.
Really? DLLs are loaded to the current context and will be in the same
address space. How come the deallocation issue?
On Aug 20, 2:01 am, Andrey Tarasevich <[email protected]>
wrote:
Pete Becker wrote:
Hi, I need your help.
----------
struct SvrList{
unsigned int uNum;
GameSvr svr[0]; //line A
};
---------
Once I declared a struct like this to store server list info.
It's supposed to be used like this.
----------
SvrList* pList = (SvrList*)malloc(sizeof(
SvrList) + svrNum*sizeof(GameSvr));
pList->uNum, pList->svr[0], pList->svr[1].... blabla..
I wouldn't call this fine. Even
pList->svr[0]
is accessing the element that is out of array's bounds, and
that is UB. How come your program is not crashing, or at
least going crazy? Maybe you are just unlucky to have a bug
hidden.
It's an old C programmers hack. I've come across this idiom in
lot's old C code, particularly driver and os code. Microsoft
Win32 is rife with it.
Except that it's not legal C, either.
Which is why it's referred to above as a "hack". Quite a common one, too.
Usually we use the term "hack" when the code relies on a specific
manifestation of undefined (or unspecified) behavior, but otherwise is
well-formed.
In this case the code is ill-formed, since 0-size array declaration is
illegal in C++ (as well as in C). In other words, arguing about the "out
of bounds" access here doesn't make much sense, since the code is
formally non-compilable.
Wait.. I don't think it's illegal in C++. At least I will definitely
object making it illegal by the standard community.
It can be dangerous but it can also do good. It depends on whether we
are using it correctly.
Will you guys getting crazy if we do things like this
-------code-----
struct A{
int num;
int p[0];};
A *pA = (A*)malloc(sizeof(A)+sizeof(int)*10);
printf("%d\n", &pA->p[10] - &pA->p[0]); //accessing out of
bounds.
------code---
Crazy? Why? C++ compilers should not simply compile it by language
rules that does not allow zero-sized arrays. If a compiler compiles it
then it is non-standard extension.
I have seen similar C code, but that used "int p[1];". If it was
compiled with C++ compiler and run-time bounds-checking on then it did
fault when accessing anything but p[0].
In C++ you should use vector<int> instead, it is about as fast.
I hate vectors, again. C++ is not portable as binary code.
Passing vectors as arguments out of a dll in windows may crash the
system when accessing it.
Assuming binary compatibility without effort is wrong anyway. Are you
seriously claiming that such originally-posted hacks let you to
achieve binary compatibility between modules compiled with different C
compilers and under different compilation options?
nope.. I mean using vectors in module interface may cause
interoperability problems.
My hack can solve the problem in case using the same padding policy
for modules involved.
If same options and same compiler are used then these interoperability
problems you refer to are likely because you add elements to vector or
attempt to destroy it outside of that windows dll context. Your hack
does not even let to add more elements to it (it is like
vector<GameSvr> const) and you may face same problems with C if you
free() it outside of that dll.
Right, but how about passing out the address of the pointer?
The point is adding more elements may make it necessary to move
existing elements elsewhere, so we may need to modify the pointer in
dll.
Actually passing pointers between functions may also cause this kind
of problems, nothing special to communication between DLLs.All problems i have seen people facing there are still about different
c runtimes or memory/resource contexts between DLL and application. So
it is not about passing pointers if you can not free() the thing it
points at since it was malloc()'ed by different memory management.
Really? DLLs are loaded to the current context and will be in the same
address space. How come the deallocation issue?
Static variables in DLL are allocated in its own memory context.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.