string constants / conversion from const char * to String

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

kelvin.koogan@googlemail.com - 22 Jun 2007 13:11 GMT

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

Reply to this Message

Ben Voigt [C++ MVP] - 22 Jun 2007 16:51 GMT

>I want to declare an array of constant strings. In unmanaged C++ I'd
> do this
[quoted text clipped - 13 lines]
> 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

Reply to this Message

kelvin.koogan@googlemail.com - 22 Jun 2007 17:41 GMT

> <kelvin.koo...@googlemail.com> wrote in message
>
> news:1182514312.987741.243970@p77g2000hsh.googlegroups.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.

Reply to this Message

Ben Voigt [C++ MVP] - 22 Jun 2007 21:39 GMT

>> <kelvin.koo...@googlemail.com> wrote in message
>>
[quoted text clipped - 13 lines]
>
> 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.

Reply to this Message

kelvin.koogan@googlemail.com - 25 Jun 2007 09:22 GMT

> <kelvin.koo...@googlemail.com> wrote in message
>
[quoted text clipped - 27 lines]
>
> - 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.

Reply to this Message

Ben Voigt [C++ MVP] - 25 Jun 2007 13:35 GMT

>> <kelvin.koo...@googlemail.com> wrote in message
>>
[quoted text clipped - 38 lines]
> 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/library/ms173266(vs.80).aspx
and this: http://msdn2.microsoft.com/En-US/library/aa290048(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.

Reply to this Message

string constants / conversion from const char * to String

Free Magazines