1
  • If String is a class (see reference source) then why object creation is not required for a string(System.String) using a new keyword?
  • A String is a reference type and Int is a value type but why string behaves like value type?
Bill Tür stands with Ukraine
  • 3,425
  • 30
  • 38
  • 48
Rohit Patel
  • 201
  • 3
  • 8

1 Answers1

1
  1. because the compiler treats literal strings "like this" differently; and they aren't "new" anyway - they come from an interned pool via the IL ldstr instruction; note that you can use the new string(...) constructors for advanced scenarios that really do create "new" string instances (except when they don't! it is complex)
  2. because string is immutable, and int is immutable; the behavior you're talking about is (presumably) immutability; the differences in copy semantics between value-types and reference-types don't really demonstrate anything once you are immutable
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Thanks for your response @marc. but I have another question here if string is immutable then why its reference type? – Rohit Patel Jan 21 '20 at 08:52
  • @RohitPatel because value-types have a fixed size, and a `string` does not; `string` is one of only a few types in .NET where the size varies between individual instances (along with arrays, and a couple of others); the payload in a string is **part of the raw object** - it isn't another indirection away. Now; .NET *could* have implemented `string` as a value-type that was a *facade* around a reference pointer the the actual data, but: they didn't. I guess that's because that *is what a "reference" is anyway*, so... might as well use the "reference" for that. – Marc Gravell Jan 21 '20 at 08:59
  • @RohitPatel - also, being immutable (or not) and being a reference type (or not) does not need to correlate. You can create immutable reference types yourself very easy by a) not providing any setters and b) only using other immutable types. For example: `public sealed class ImmutableThing { public ImmutableThing(string name, int id) { Name = name; ID = id; } public string Name { get; } public int ID { get; } }`. The properties can only be set during construction. You can't even say `Name = "something else";` in a method inside the class anywhere outside the context of construction. – Corak Jan 21 '20 at 10:28
  • 1
    Further to what @Corak says; in the case of value-types, there is also now a syntax to *guarantee* this; instead of `struct Foo`, you can use `readonly struct Foo` - then the compiler doesn't let you mess it up. It is perhaps a shame that it doesn't also allow `readonly class Bar`, but: the main *problem* that `readonly struct` is trying to solve doesn't really apply to classes, so... I guess it is fine – Marc Gravell Jan 21 '20 at 10:31
  • See also: [Write safe and efficient C# code](https://learn.microsoft.com/dotnet/csharp/write-safe-efficient-code#declare-readonly-structs-for-immutable-value-types) – Corak Jan 21 '20 at 10:40