[C++.NET] (Simpel) Vraagje over Console::Write

[Verwijderd]

Na lang zoeken op MSDN en niets te vinden hoop ik dat jullie mij kunnen helpen.
In veel programmas (zelfs op MSDN) kom je de methode Write, als volgt aangeroepen, tegen.

Console::Write(S",");

Wat is nu het essentiele verschil met

Console::Write(",");

Een bronvermelding over dit onderwerp zou enorm geapprecieerd zijn

[whoami]

Uit de .NET SDK:

The Managed Extensions include a new string literal with the 'S' prefix.

Example

code:

// mcpp_string2.cpp
// compile with: /clr
#using <mscorlib.dll>
using System::String;
int main() {
   String *s1 = S"a common language runtime string literal";
};

An S string literal has type System::String* and has better performance in managed code than C++ string literals. Moreover, all instances of identical S string literals always point to the same object, which is not true for String* objects that are constructed from C++ string literals.

[Vampier]

code:

#using <mscorlib.dll>

using namespace System;

int main(){

String *bla=S"hallo";
String *bla2=S"hallo";

if (bla2==bla){Console::Write("ok");}

}

Op deze manier kun je dus ook makelijk strings met elkaar vergelijken en hoef je geen bla->CompareTo(bla2) methode toe te passen. (omdat een string niet meer als een pointer behandeld wordt?)

[.oisyn]

Vampier: je beseft toch wel dat wat je daar doet fout is he? (het zal wel true opleveren, maar niet omdat de ene string inhoudelijk gelijk is aan de ander)

[MSalters]

Ben ik nou gek, of is die gelijkheidsrelatie nou het enige doel van S"hallo" ?

all instances of identical S string literals always point to the same object

dus de pointers bla en bla2 wijzen allebei naar hetzelfde object?

[.oisyn]

Wat bedoel je precies? Wat Vampier iig bedoelt is dat System::String de == operator heeft geimplementeerd, maar dat is natuurlijk niet degene die wordt aangeroepen als je pointers vergelijkt. Het doel van de S voor de string literal is dat dat Strings object bij het starten van de applicatie al wordt geinstantieerd, wat performance ten goede komt

[MSalters]

Nee, precies, maar als je twee pointers vergelijkt die met dezelfde waarde zijn geinitialiseerd, dan komt daar hetzelfde uit.
Wat ik denk dat er ongeveer gebeurt met S"hallo" is dat aan het begin van het programma er precies een gc object System::String __Shallo wordt aangemaakt, met dus een use count 1 .Daarna zorgen de assigments dat bla en bla2 naar diezelfde __Shallo wijzen (waarna de use count dus 3 is).

Dit verschilt van char const* bla = "hallo"; char const* bla2 = "hallo"; omdat er geen garantie is dat er precies een unieke char const[6] is met waarde "hallo". Een compiler mag er zoveel introduceren als gewenst, en dus ook op verschillende adressen.

[Vampier]

ik ben redelijk nieuw in c++.net (cursusje aan het volgen) en wat hier boven staat gaat me eerlijkgezegd iets te ver. Het viel me gewoon op dat er met die S wel een vergelijking getrokken kon worden en zonder de S er gewoon snoeihard gekeken werd naar de pointer.

[MSalters]

Mijn opinie is dat er MET S"" ook naar de pointer wordt gekeken, maar dat S"" literals uniek zijn. Dus S"AB" == S"AB", altijd.

[.oisyn]

Vampier, dat is ook zo, maar het blijven pointers. Als je de == operator van String wilt gebruiken moet je ze dus derefencen. Oftewel: *str1 == *str2

Natuurlijk, als het constanten zijn die hard in de source gespecificeerd zijn dan krijgen 2 strings die gelijk zijn ook altijd dezelfde pointer naar de String toegewezen. Maar je kunt niet verwachten dat als je str1 hebt gespecificeerd in code en str2 uitleest uit een bestand oid, dat ze dan niet naar hetzelfde object wijzen, dus daar zal str1 == str2 altijd false opleveren, ook al zijn ze inhoudelijk gelijk.

^{Sorry als dit een wazig verhaal blijkt, ik heb een pil op}

[curry684]

.oisyn schreef op 27 maart 2004 @ 02:32:
Vampier, dat is ook zo, maar het blijven pointers. Als je de == operator van String wilt gebruiken moet je ze dus derefencen. Oftewel: *str1 == *str2

Natuurlijk, als het constanten zijn die hard in de source gespecificeerd zijn dan krijgen 2 strings die gelijk zijn ook altijd dezelfde pointer naar de String toegewezen. Maar je kunt niet verwachten dat als je str1 hebt gespecificeerd in code en str2 uitleest uit een bestand oid, dat ze dan niet naar hetzelfde object wijzen, dus daar zal str1 == str2 altijd false opleveren, ook al zijn ze inhoudelijk gelijk.

Indien String echter intern een hashtabel hanteert om unieke strings te identificeren kun je juist wel altijd een simpele pointercomparison doen om equality te checken Deze techniek is echter sinds een paar jaar relatief irrelevant omdat de processortechniek met enorme datacaches de potentiele winst hier compleet heeft genihiliseerd en je door de (dure) hashing juist trager wordt ermee. Aannames in deze lijken me dus fataal

[.oisyn]

Ik heb nog nooit een implementatie gezien die dat doet, en het lijkt me ook een beetje overdreven. Dat zou betekenen dat voor elke operatie op een string die een string aanpast (of eigenlijk: een nieuwe string maakt uit een andere string) elke keer opnieuw gehashed moet worden. Leuk als je met lange strings bezig bent (> 10.000 chars)...

[curry684]

.oisyn schreef op 29 maart 2004 @ 15:25:
Ik heb nog nooit een implementatie gezien die dat doet, en het lijkt me ook een beetje overdreven. Dat zou betekenen dat voor elke operatie op een string die een string aanpast (of eigenlijk: een nieuwe string maakt uit een andere string) elke keer opnieuw gehashed moet worden. Leuk als je met lange strings bezig bent (> 10.000 chars)...

Reken mee in geval van een filesystem met een directory met 1000 files met gemiddeld een filename van 64 karakters.

String als hashtabel: gemiddelde performancehit van 1 keer 32 karakters hashen en 500 pointer comparisons.
String als string: gemiddelde performancehit van 500 * 32 karakters = 16000 karakters byte-by-byte vergelijken.

Ik weet wel welke van de 2 zonder cache sneller is Vanzelfsprekend is dit geen handige implementatie voor modifiable strings, en dus zul je deze variant alleen gebruiken voor lookup/indexing tables en andere relatief 'statische' data, en een normale variant blijven gebruiken voor andere string-operaties.

[MSalters]

curry684 schreef op 29 maart 2004 @ 15:32:
[...]

Reken mee in geval van een filesystem met een directory met 1000 files met gemiddeld een filename van 64 karakters.

String als hashtabel: gemiddelde performancehit van 1 keer 32 karakters hashen en 500 pointer comparisons.
String als string: gemiddelde performancehit van 500 * 32 karakters = 16000 karakters byte-by-byte vergelijken.

Huh? std::set< >, en je hebt ²log (500) + ²log (500/26) + ²log ( 500/(26*26) ) + ... ~= 14 vergelijkingen nodig, aangenomen dat de letterfrequenties een uniforme 1/26 zijn. Zonder naar de tweede letter te kijken kun je dan al 500*25/26 = 480 strings skippen. String ongelijkheid is meestal snel.

Ik weet wel welke van de 2 zonder cache sneller is Vanzelfsprekend is dit geen handige implementatie voor modifiable strings, en dus zul je deze variant alleen gebruiken voor lookup/indexing tables en andere relatief 'statische' data, en een normale variant blijven gebruiken voor andere string-operaties.

[.oisyn]

curry684 schreef op 29 maart 2004 @ 15:32:

Bliep, we hebben het niet over een filesystem, maar over een implementatie van een runtime.
Een bestandsnaam bestaat niet uit veel karakters, en bovendien wordt ie niet vaak gewijzigd. Over een System::String in .net kun je die aanname niet doen (die waren fataal, weetjenog? )

Verder ben ik het eens met MSalters, ten eerste zijn er al niet 500 string comparisons nodig, en ten tweede vergelijk je nooit de complete strings (in het ergste geval is alleen steeds het laatste teken verschillend, maar dan nog werk je niet met 500 string comparisons in totaal, dan ben je gewoon stom bezig)

[curry684]

Net zoals std::string weet jij niet vantevoren hoe System::String 'ooit' gaat functioneren. Dus vandaar: aannames zijn fataal

En vanzelfsprekend is er met een B-search veel winst te behalen, maar niet in bijvoorbeeld een linked list van elementen. Het is allemaal afhankelijk van de randvoorwaarden van de situatie, alhoewel ik zelf al zei dat tegenwoordig zelfs de zeldzame situaties waarin een hash-based string implementatie nuttig zou kunnen zijn die winst nihil tot negatief is met dank aan data caches.

[whoami]

curry684 schreef op 29 maart 2004 @ 23:57:

En vanzelfsprekend is er met een B-search veel winst te behalen, maar niet in bijvoorbeeld een linked list van elementen.

Ff. mierenneuken.
Als j B - tree niet goed gebalanceerd is, dan kan het eventraag gaan als met een linked list.
Maar als je linked list geimplementeerd is als een skip-list, dan kan het zoeken daarin even snel zijn als in een goed gebalanceerde B-tree.