471,338 Members | 1,292 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,338 software developers and data experts.

The "generic" keyword and unmanaged code


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.

May 31 '07 #1
2 5847
mo********@gmail.com wrote:
#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"
That's clearly a bug - I'd suggest posting a bug report on
http://connect.microsoft.com/feedback/?SiteID=210

The only solution I could find involves modifying the header, or in this
case, your sample:

#pragma managed(push, off)

void testing(){

int blah;
int __identifier(generic);
int something;
}

#pragma managed(pop)

I imagine that you could use some preprocessor trickery before #including
the FreeType header files to #define generic as __identifier(generic), but
that may cause more problems than it solves. Might be worth a try though.

-cd

May 31 '07 #2

That's clearly a bug - I'd suggest posting a bug report onhttp://connect.microsoft.com/feedback/?SiteID=210
>>>

I imagine that you could use some preprocessor trickery before #including
the FreeType header files to #define generic as __identifier(generic), but
that may cause more problems than it solves. Might be worth a try though.

Thanks for the idea, that completely escaped me. I was going over the /
clr tweaks on:
http://msdn2.microsoft.com/en-us/lib...4s(VS.80).aspx
-- for the most part to try and find some way to jump to an unmanaged
zone and back again, apart from 'managed(push, off)'.

The only notable thing about the system configs that I've been trying
this on is that they're both vista installs. One at home (Vista
Ultimate, VS2005 Express), and one at work (Vista Business, VS2005
Standard). I'll have to find an XP system on which I can install VS on
and try it there (my current workplace provides these bridge
programming/hardware services which are outsourced to them, and once
vista was released, there was only need for XP machines to test the
final products on, while the development computers were upgraded).

I can't imagine why this would be the reason, but it's the only
commonality that comes to mind, since the hardware/software
configurations are completely different (that said, this particular
situation shouldn't have been so specific as to not have been noticed
yet, I think...).

I'll go over the submitted bugs and if I don't find anything close or
that covers it I'll submit a new one.

Thanks again for the reply.

May 31 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Vicente Nicolau | last post: by
2 posts views Thread by Jon Davis | last post: by
reply views Thread by Prasana | last post: by
1 post views Thread by jason | last post: by
2 posts views Thread by Bob Altman | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.