13

int and object have a parameterless constructor. Why not string?

Patrick Hofman
  • 153,850
  • 22
  • 249
  • 325
burnt1ce
  • 14,387
  • 33
  • 102
  • 162
  • Maybe because string is array of char(char[])? – Poomrokc The 3years May 01 '14 at 14:22
  • 5
    Why should it? What would you have the parameterless constructor do? – Damien_The_Unbeliever May 01 '14 at 14:24
  • 3
    Hm.. I was thinking if `int` can be initialized as `new int()` with a value of 0, why can't we do the same with `string` as `new string()` with a value of an empty string. It's a little bit inconsistent in my opinion but I also understand having a parameterless string constructor is useless, given that we have `String.Empty`. – burnt1ce May 01 '14 at 14:54
  • 2
    int is a value type, so it cannot exist without a value and cannot be null. However a string can be null or empty string, it is an exception to most objects in the way it behaves as both reference and value type (unlike say, java). Consider a `new ScrabbleTile("A")` to make an A tile in Scrabble. Would `new ScrabbleTile()` give you an empty tile `""` or a `null` tile because one hasn't been assigned? If you think, scrabble has blank tiles, you will want to distinguish between `null` and `""` which represents a blank tile. This ambiguity could be problematic and is resolved with no constructor. – NibblyPig May 02 '14 at 15:15

8 Answers8

14

Because there is no point in doing that.

string is immutable. Creating an empty string is just useless.

MSDN:

Strings are immutable--the contents of a string object cannot be changed after the object is created, although the syntax makes it appear as if you can do this.

As Jonathan Lonowski pointed out, we have string.Empty for that.

Patrick Hofman
  • 153,850
  • 22
  • 249
  • 325
5

Update:

To provide more information for you.

You don't have an empty Constructor with a string, however you do have String.Empty. The reason is because a string is an immutable object every instance of a string you modify is actually creating a new string in memory.

For instance: string name = ""; though it is an empty string it will still hold around twenty bytes. Where the string.Empty will only hold around four or eight bytes. So though they mean the same thing, one is more efficient than the other.

However I believe you want an empty Constructor to do manipulation that may be more commonly handled by the StringBuilder. Some really nice usage between the two can be found here (Determine performance hit / usage).

Some additional information on the string can be found here. They are immutable thus the contents cannot be changed afterwards.

Example:

string first = "Greg "; // Creates string "first" in memory.
string last = "Arrigotti "; // Creates string "last" in memory.
string name = first + last; // Creates string "name" in memory.

As you edit one of these, it is simply creating a whole new string in memory. If you are looking at a way to potentially handler user data in a field where no middle name exist for instance, the empty string may contain valid usage.

Hopefully these point you in the proper direction.

Community
  • 1
  • 1
Greg
  • 11,302
  • 2
  • 48
  • 79
  • 5
    The string created form the parameterless constructor would be an empty string. It's the only logical possibility. *That is not a useless string instance*. It is an entirely sensible thing to use, and something that is used *all the time* by lots of people. it simply makes more sense to have an `Empty` field instead, or to use the literal, for those uses. *It is those alternatives* that make the empty constructor useless, not the fact that an empty string is inherently not useful. – Servy May 01 '14 at 14:57
  • That is not necessarily logical. If you don't supply a value to a constructor, it is just as likely to be stored as null (i.e. unspecified) as it is to be initialised to its default value. It also prevents you doing something silly like thinking you can change the value of a string. – NibblyPig May 02 '14 at 15:09
  • @NibblyPig There is no reference type that if you call `new` on it that would be stored as null. Thus `it is just as likely to be stored as null` seems unlikely. – mjwills Aug 03 '17 at 23:19
  • The reference isn't null, the underlying storage would be null. If you create a `new Customer()` the `Name` field would be `null`. The same with a string. Just because it is special and it lets you use it without doing `myString.Value` doesn't mean that it would be `""` by default. `String` is a class with properties and fields inside it, which 'logically' would be `null`. – NibblyPig Aug 04 '17 at 09:21
  • Problem is, this makes `String` not fit a generic `new()` prerequisite. Which is becoming a problem with nullability enforcement and generic methods... – Medinoc Dec 22 '22 at 09:24
4

Strings are immutable, therefore new String() has no purpose. What would you do with it?

NibblyPig
  • 51,118
  • 72
  • 200
  • 356
  • It could sensibly construct an empty string. It certainly would have a purpose, and there are plenty of things to do with it. The class's designer chose to go another route, but this route is certainly a valid alternative. – Servy May 01 '14 at 14:35
  • What would you do with your 'empty' string? Although it being empty is an assumption. – NibblyPig May 02 '14 at 12:28
  • You seriously can't imagine things that one might do with an empty string? Well, for starters, probably the most common thing to do with it is compare it to a string variable to answer the question of whether or not that string is empty. One can use it as a parameter of a method where a string is expected, but nothing needs to be printed, it can be the initial value of a string that may or may not be replaced with something else, etc. – Servy May 02 '14 at 13:52
  • No, I'm saying I can't imagine why you would want to *construct* a default string object with no parameter supplied. You can do your comparisons with `string.Empty`. – NibblyPig May 02 '14 at 14:53
  • The fact that there are alternate ways of constructing an empty string is exactly why there is no need to have an empty constructor as *an additional way*. **That** is the answer here. Your claim that it's just globally pointless is wrong. It's not pointless; it has lots of points. It's *redundant*, which is quite different. – Servy May 02 '14 at 14:56
  • It is pointless because `string.Empty` is not the same as what `new String()` would be or even `new String("")` is. `string.Empty` is preferred because a) you're not making a new string for every comparison, and b) `string.Empty` is localization independent. Perhaps you can give an example where `new String();` would be used? – NibblyPig May 02 '14 at 14:59
  • First off, that doesn't make it pointless, it makes it an inferior alternative, which is, again, different from being pointless. Additionally, **none of that explanation is in your answer**. You have explained nothing here, merely made a disproved assertion. – Servy May 02 '14 at 15:02
  • Unless you can come up with an example where you'd want to use `new String()` I stand by my answer, there is no point. It is also ambiguous as to whether a `new String()` would be `null` or `""` which is probably another reason it doesn't exist. – NibblyPig May 02 '14 at 15:07
  • I listed quite a few reasons earlier. Just because there's another way to do those things doesn't make it pointless. Would you *honestly* expect `new string()` to resolve to `null`? What makes you think that *constructing an instance of an object, using its constructor would result in no object being constructed*. No other class *ever* has that behavior. Invoking the constructor of a reference type *always* constructs an instance of that object. (The only possible exception being an out of memory error.) – Servy May 02 '14 at 15:21
  • `What would you do with it?` If `string` had a default constructor, it could be used as a generic type parameter for methods with `new()` constraint. That is one thing you could do with it. – mjwills Aug 03 '17 at 23:20
  • Lol this discussion is 3 years old, but what would you do with your new immutable string which may or may not be an empty string? I think it would be misleading so such creation is banned by the author. To address Servy's point even though it's been 3 years, if you create a new primitive type, it is assigned a default value like 0, but the same is not true for reference types. `string` is likely (but not necessarily, unless you decompile the source) going to wrap a `char` array, which may be initialised as `null`, or an empty array - who knows. We can't assume that it would be `""` – NibblyPig Aug 04 '17 at 09:14
  • Thanks for the feedback @NibblyPig – mjwills Nov 29 '17 at 04:13
4

As said before, strings are immutable and therefore if you manipulate a string you actually create a new one every time.

Example:

string s = "str"; // str was created in the memory.
s += "2"; // str2 was created in the memory.

Use StringBuilder when you want to manipulate string(that's why you wanted an empty ctor, right?)

Amir Popovich
  • 29,350
  • 9
  • 53
  • 99
4

Why indeed?

It would be completely logical and sensical to provide a parameterless constructor for the string type, yet it doesn't have one.

The reason is because the designers of that type thought it would be a much better idea to have string.Empty.

There could be a logical reason for having the ability to construct multiple empty strings that are different instances. I fail to see one off the top of my head, but that doesn't mean someone else can't see one.

There are some technical reasons behind why limiting the usage to string.Empty might be a good idea. First, all empty strings are considered equal, though not necessarily ReferenceEquals, so having multiple empty strings would seemingly make no sense. The second you say that "I have these two seemingly similar things, yet I've attached a different meaning to each" then perhaps you're trying to solve a problem with the wrong tool.

There's also some upshots of having a predefined string.Empty. Whenever you reference it, you're referencing the same object instance as every other place, and thus you don't have lots of empty (and identical) string objects in memory.

But could it be done? Sure.

So while everybody here has tried to justify that there should be no such constructor, I am saying that there could be such a constructor.

However, someone decided to design the type without one.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
2

Also there is already a defined constant for this: String.Empty

Carlo Bos
  • 3,105
  • 2
  • 16
  • 29
-1

int is a value type, and as such it must have a parameterless constructor. There is no consideration that can be made here.

object has no reason to have anything but a parameterless constructor. There is no data to give it. What parameters would you expect it to take? objects constructed with a parameterless constructor also have a purpose; they are used, for example, as objects to lock on. It is however a class, so it doesn't need to have a public parameterless constructor, however since it has no need for parameters, it's a question of whether you want instance of it to be constructed at all; Microsoft chose to make it concrete, rather than abstract.

string is a class, so it isn't required to have a parameterless constructor. The team building it simply never saw a need to have one. One could sensibly use such a constructor to create an empty string, but they choose to expose string.Empty (as well as an empty string literal) as a way of explicitly creating an empty string. Those options have improved clarity over a parameterless constructor.

Another pretty significant advantage of string.Empty and the empty literal string is that they are capable of re-using the same string instance. Since strings are immutable, the only way to observe the difference between two different references to empty strings is through the use of ReferenceEquals (or a lock on the instance). Because there is virtually never a need to go out of your way to have different references to an empty string, removing the parameterless constructor removes the possibility of an equivalent but poorer performing method of constructing an empty string. In the very unlikely event that it is important to construct a new string instance that is an empty string, an empty char array can be passed to the relevant constructor overload, so removing the parameterless constructor doesn't remove any functionality from the end user; it simply forces you to go out of your way to do something really unusual if you want to do something really unusual, which is the sign of good language design.

Servy
  • 202,030
  • 26
  • 332
  • 449
  • 1
    Design-decision wise, it is probably ambiguous to have a constructor, because would a `new String()` be null, or empty? You can't really tell, and neither is obvious. There's no reason to construct an empty string since `string.Empty` solves multiple issues with empty string comparisons such as localisation issues. Under the hood, `""` is not compiled the same as `string.Empty`. – NibblyPig May 02 '14 at 15:05
  • @SLC How would `new String()` possibly be `null`. It *couldn't* be `null` even if you *wanted* it to be. You're constructing an instance. There is no way for that to ever be `null`, and that *is* obvious. I discuss in my answer specifically why `string.Empty` is superior to a parameterless constructor. The point is that both are valid choices of how to solve the same problem, but one is superior to another. While the string literal is not exactly the same as `Empty`, they serve the same functional purpose. – Servy May 02 '14 at 15:13
  • 1
    A string represents a string of text though, it isn't actually the string itself since it's not a value type. `new String()` can't be null but the underlying value could be null or empty string depending on whether it is initialised or not. No reason you couldn't initialise a string with a null value of the string, or an empty string. You might want to create your string and give it a value later. The ambiguity is best resolved by not having a constructor. – NibblyPig May 02 '14 at 15:43
  • @SLC Strings are immutable. That is quite contrary to the design of creating an object only to give it a value later. The internal data structure of the string may well be `null`. That's fine, but the string itself would not be `null`, it would be an object instance. It is in fact entirely sensible for an empty string to be implemented, internally, as a `null` char array instead of an empty char array. I doubt it is, and I would imagine the later superior, and of course this is all academic as it's merely an implementation detail not relevant externally. – Servy May 02 '14 at 15:47
-3

Provided that you know that string is immuable, your question can be rephrased as the following:

why on earth can't I initiate a null object??

answer:

Because there is no null object :)

stackunderflow
  • 3,811
  • 5
  • 31
  • 43