string constants / conversion from const char * to String

[kelvin.koogan]

I want to declare an array of constant strings. In unmanaged C++ I'd
do this

static const char *string[] = { "One", "Two, "Three" };

However if I do this in .NET and want to pass these to a function
which takes an Object * then I get compilation errors. The only way to
avoid these seems to be to create a temporary string on the heap,
e.g.

String *str = new String(string[1]);
function(str);

Which seems a bit wasteful.

If I try to declare my static const array as Strings instead then I
get warnings about not being able to declare managed types as statics.

What is the right way to do this? Is there a better way to declare the
array of constant strings of a better way to convert const char * to
Object?

TIA,
KK

[Ben Voigt [C++ MVP]]

<ke***********@googlemail.comwrote in message
news:11**********************@p77g2000hsh.googlegr oups.com...

>I want to declare an array of constant strings. In unmanaged C++ I'd
do this

static const char *string[] = { "One", "Two, "Three" };

However if I do this in .NET and want to pass these to a function
which takes an Object * then I get compilation errors. The only way to
avoid these seems to be to create a temporary string on the heap,
e.g.

String *str = new String(string[1]);
function(str);

Which seems a bit wasteful.

If I try to declare my static const array as Strings instead then I
get warnings about not being able to declare managed types as statics.

Is that a function-local static? I know that static strings are allowed.
Please note that const doesn't work in managed code, but there is "initonly"
which is similar. In your case, however, you probably want "literal".

>
What is the right way to do this? Is there a better way to declare the
array of constant strings of a better way to convert const char * to
Object?

TIA,
KK

[kelvin.koogan]

On 22 Jun, 16:51, "Ben Voigt [C++ MVP]" <[e-mail]:

<[e-mail] in message

news:11**********************@p77g2000hsh.googlegr oups.com...

If I try to declare my static const array as Strings instead then I
get warnings about not being able to declare managed types as statics.

Is that a function-local static? I know that static strings are allowed.
Please note that const doesn't work in managed code, but there is "initonly"
which is similar. In your case, however, you probably want "literal".

I was trying

const String *strings[] = {S"One", S"Two", S"Three};

Note I'm using VS 2003.

[Ben Voigt [C++ MVP]]

<ke***********@googlemail.comwrote in message
news:11**********************@g4g2000hsf.googlegro ups.com...

On 22 Jun, 16:51, "Ben Voigt [C++ MVP]" <[e-mail]:

><[e-mail] in message

news:11**********************@p77g2000hsh.googleg roups.com...

If I try to declare my static const array as Strings instead then I
get warnings about not being able to declare managed types as statics.

Is that a function-local static? I know that static strings are allowed.
Please note that const doesn't work in managed code, but there is
"initonly"
which is similar. In your case, however, you probably want "literal".

I was trying

const String *strings[] = {S"One", S"Two", S"Three};

Note I'm using VS 2003.

That's not good. Microsoft has completely dropped support for Managed
Extensions for C++, and there are known bugs with all mixed-mode assemblies
that cannot be worked around. Everyone really needs to upgrade to C++/CLI
as soon as possible to get the compiler fixes, even if you continue using
the old syntax (/clr:oldSyntax). Visual C++ 2005 Express is preferable to
any edition of 2003 from that regard -- all the optimization in the matter
doesn't work if it deadlocks.

[kelvin.koogan]

On 22 Jun, 21:39, "Ben Voigt [C++ MVP]" <[e-mail]:

<[e-mail] in message

news:11**********************@g4g2000hsf.googlegro ups.com...

On 22 Jun, 16:51, "Ben Voigt [C++ MVP]" <[e-mail]:

<[e-mail] in message

>news:11**********************@p77g2000hsh.googleg roups.com...

If I try to declare my static const array as Strings instead then I
get warnings about not being able to declare managed types as statics.

Is that a function-local static? I know that static strings are allowed.
Please note that const doesn't work in managed code, but there is
"initonly"
which is similar. In your case, however, you probably want "literal".

I was trying

const String *strings[] = {S"One", S"Two", S"Three};

Note I'm using VS 2003.

That's not good. Microsoft has completely dropped support for Managed
Extensions for C++, and there are known bugs with all mixed-mode assemblies
that cannot be worked around. Everyone really needs to upgrade to C++/CLI
as soon as possible to get the compiler fixes, even if you continue using
the old syntax (/clr:oldSyntax). Visual C++ 2005 Express is preferable to
any edition of 2003 from that regard -- all the optimization in the matter
doesn't work if it deadlocks.- Hide quoted text -

- Show quoted text -

Sadly we're stuck with VS 2003. In this instance I'm trying to just
use .NET. My problem is that I'm only familiar with standard C++
syntax and I'm not sure what the right way to declare an array of
constant strings in .NET is.

[Ben Voigt [C++ MVP]]

<ke***********@googlemail.comwrote in message
news:11**********************@n2g2000hse.googlegro ups.com...

On 22 Jun, 21:39, "Ben Voigt [C++ MVP]" <[e-mail]:

><[e-mail] in message

news:11**********************@g4g2000hsf.googlegr oups.com...

On 22 Jun, 16:51, "Ben Voigt [C++ MVP]" <[e-mail]:
<[e-mail] in message

>>news:11**********************@p77g2000hsh.google groups.com...

If I try to declare my static const array as Strings instead then I
get warnings about not being able to declare managed types as
statics.

>Is that a function-local static? I know that static strings are
allowed.
Please note that const doesn't work in managed code, but there is
"initonly"
which is similar. In your case, however, you probably want "literal".

I was trying

const String *strings[] = {S"One", S"Two", S"Three};

Note I'm using VS 2003.

That's not good. Microsoft has completely dropped support for Managed
Extensions for C++, and there are known bugs with all mixed-mode
assemblies
that cannot be worked around. Everyone really needs to upgrade to
C++/CLI
as soon as possible to get the compiler fixes, even if you continue using
the old syntax (/clr:oldSyntax). Visual C++ 2005 Express is preferable
to
any edition of 2003 from that regard -- all the optimization in the
matter
doesn't work if it deadlocks.- Hide quoted text -

- Show quoted text -

Sadly we're stuck with VS 2003. In this instance I'm trying to just
use .NET. My problem is that I'm only familiar with standard C++
syntax and I'm not sure what the right way to declare an array of
constant strings in .NET is.

The correct way to do anything in .NET 1.1 is with C#. C++ code on .NET 1.1
suffers from the loader lock bug, and there is no workaround except for
upgrading to .NET 2.0 and VS 2005. Even the "/clr:pure" option that
prevents mixed-mode compilation isn't available until VC++ 2005.

So find whoever is mandating VS 2003, and show them this:
http://www.codeproject.com/scrapbook/semicolon_2.asp
and this: http://msdn2.microsoft.com/en-us/lib...66(vs.80).aspx
and this: http://msdn2.microsoft.com/En-US/lib...48(vs.71).aspx

Specifically:

"Second, when loading DLLs in versions 1.0 and 1.1 of the .NET Framework,
the CLR assumed that the loader lock was not held and performed several
actions that are invalid under loader lock. Assuming the loader lock is not
held is a valid assumption for purely .NET DLLs, but, because mixed DLLs
execute native initialization routines, they require the native Windows
loader and therefore the loader lock. Consequently, even if the developer
was not attempting to execute any MSIL functions during DLL initialization,
there was still a small possibility of nondeterministic deadlock with
versions 1.0 and 1.1 of the .NET Framework."

"Consequently, due to the way the loader works in version 1.0 and 1.1 of the
common language runtime, deadlock situations are always possible with mixed
DLLs, even though they are often quite rare in practice. The worst part of
this is that mixed DLLs that happen to work on most systems can begin
deadlocking if the system is stressed, the image is signed (since the
security functionality require more managed code to run during assembly
load), hooks are installed into the system, or the behavior of the runtime
changes through service packs or new releases. In summary, this is a serious
problem that must be addressed for all mixed DLLs."

I'm sorry, but there is no rationale for staying with VS 2003 that can
possibly trump a latent nondeterministic deadlock.