M
morangolds
Hi all,
I work as a glue coder and often have to interface existing mechanisms
with other platforms. Creating bridge code between command-line
functionality and desktop GUIs takes up a lot of that definition,
along with creating abstraction layers for older-style C code. I've
been working with .net (almost exclusively with C++.net, just a bit of
C#) to create end-user interfaces with a relatively good deal of
success (I'm used to ansi/STL and the like).
(I'll be getting to the point any moment now...)
When importing non-managed code I either use 'extern "C" {}' or
'#pragma managed', though, to be perfectly honest, '#pragma managed'
isn't something that I know I can nail immediately in more involved
situations. I mention this because I think that this falls under what
'#pragma managed' is supposed to achieve, even if indirectly.
I've been trying to use a standard C library which has variables in it
that are named "generic". This isn't the first time this has happened,
but previously this was in code that was encapsulated and I could just
search-and-replace. This time it's in a very large, frequently
updated, open-source library: FreeType.
I tried googling in two separate directions: First, anyone using
FreeType in a managed project (it could happen, the library gives you
access to font file info that .net doesn't yet make accessible), and,
more generally, is there any way to name a variable "generic" within
a /clr project. Neither vectors of mining turned up anything that I
could use (which may just mean that I'm a bad googler, granted).
So I tried solving the problem using the shortest equation possible: I
created a console CLR project, and tried to get it to accept a
variable named "generic". Something like:
#pragma managed(push, off)
void testing(){
int blah;
int generic;
int something;
}
#pragma managed(pop)
It seems ironic, to me at least, that the error message reads:
"error C3282: generic parameter lists can only appear on managed
classes, structs, or functions"
But didn't I place that entire block of code within the non-managed
pragma zone? Shouldn't it simply ignore the "generic" keyword?
If you try this you'll also receive a bunch of syntax errors, since of
course this isn't a proper declaration of generics. It'll end with a
"fatal error C1506: unrecoverable block scoping error".
I've tried other combinations of futile attempts, but most of them
probably have nothing to do with the problem, and will just complicate
matters in the "why did you think this would work?..." direction.
To clarify a couple of specifics: when trying to compile a test
program that makes use of the library without /clr, VS2005 doesn't
have any problem. When /clr is turned on, it finds three instances of
the word "generic" in a header file:
freetype.h(914) : error C2059: syntax error : 'generic'
freetype.h(914) : error C2238: unexpected token(s) preceding ';'
Wrapping the include (#include <ft2build.h>) with #pragma managed
doesn't do anything, but that was obvious by now.
If anyone has any insight into the subject, any pointers will help.
Thanks.
I work as a glue coder and often have to interface existing mechanisms
with other platforms. Creating bridge code between command-line
functionality and desktop GUIs takes up a lot of that definition,
along with creating abstraction layers for older-style C code. I've
been working with .net (almost exclusively with C++.net, just a bit of
C#) to create end-user interfaces with a relatively good deal of
success (I'm used to ansi/STL and the like).
(I'll be getting to the point any moment now...)
When importing non-managed code I either use 'extern "C" {}' or
'#pragma managed', though, to be perfectly honest, '#pragma managed'
isn't something that I know I can nail immediately in more involved
situations. I mention this because I think that this falls under what
'#pragma managed' is supposed to achieve, even if indirectly.
I've been trying to use a standard C library which has variables in it
that are named "generic". This isn't the first time this has happened,
but previously this was in code that was encapsulated and I could just
search-and-replace. This time it's in a very large, frequently
updated, open-source library: FreeType.
I tried googling in two separate directions: First, anyone using
FreeType in a managed project (it could happen, the library gives you
access to font file info that .net doesn't yet make accessible), and,
more generally, is there any way to name a variable "generic" within
a /clr project. Neither vectors of mining turned up anything that I
could use (which may just mean that I'm a bad googler, granted).
So I tried solving the problem using the shortest equation possible: I
created a console CLR project, and tried to get it to accept a
variable named "generic". Something like:
#pragma managed(push, off)
void testing(){
int blah;
int generic;
int something;
}
#pragma managed(pop)
It seems ironic, to me at least, that the error message reads:
"error C3282: generic parameter lists can only appear on managed
classes, structs, or functions"
But didn't I place that entire block of code within the non-managed
pragma zone? Shouldn't it simply ignore the "generic" keyword?
If you try this you'll also receive a bunch of syntax errors, since of
course this isn't a proper declaration of generics. It'll end with a
"fatal error C1506: unrecoverable block scoping error".
I've tried other combinations of futile attempts, but most of them
probably have nothing to do with the problem, and will just complicate
matters in the "why did you think this would work?..." direction.
To clarify a couple of specifics: when trying to compile a test
program that makes use of the library without /clr, VS2005 doesn't
have any problem. When /clr is turned on, it finds three instances of
the word "generic" in a header file:
freetype.h(914) : error C2059: syntax error : 'generic'
freetype.h(914) : error C2238: unexpected token(s) preceding ';'
Wrapping the include (#include <ft2build.h>) with #pragma managed
doesn't do anything, but that was obvious by now.
If anyone has any insight into the subject, any pointers will help.
Thanks.