[C++] with .... do constructie

[Verwijderd]

Delphi kent een with ... do constructie, zie het onderstaande voorbeeld.

with OrderDate do
if Month = 12 then
begin
Month := 1;
Year := Year + 1;
end
else
Month := Month + 1;

Dit is hetzelfde als:

if OrderDate.Month = 12 then

begin
OrderDate.Month := 1;
OrderDate.Year := OrderDate.Year + 1;
end
else
OrderDate.Month := OrderDate.Month + 1;

Kent C++ ook een dergelijke constructie? Want als ik with ... do letterlijk overneem in C++ werkt dit namelijk niet.

[marcusk]

Kent C++ ook een dergelijke constructie?

nee

[whoami]

Neen.
'k Vind dat trouwens geen mooie constructie en ik gebruik ze nauwelijks (nooit eigenlijk). Ik vind dat die constructie nogal tot wat verwarring kan leiden.
(Alhoewel dat die constructie wel een performance-winst opleverd).

[Reefer]

lijkt mij op een switch?

[whoami]

Reefer schreef op 02 september 2002 @ 14:20:
lijkt mij op een switch?

Neen, een switch is een 'selectie-statement'.
Een With-Do is heel iets anders.
bv:

code:

With Button1 do begin
  Text      := 'OK';
  OnClick := UpdateData;
end;

[MSalters]

Ja een class. In de functies van class COrderDate hoef je geen OrderDate.Month te gebruiken, als Month een data member van COrderDate is.
Dus

code:

COrderDate::telaat( )
{
  if (m_Month == 12 )
  {
    m_Month = 1;
    ++m_Year;
  }
  else
    ++m_Month;
}

member m_Month hoef je dus niet te prefixen; als je OrderData.telaat() aanroept weet de compiler dat functie telaat() OrderData.m_Month gebruikt.

[whoami]

MSalters schreef op 02 september 2002 @ 14:24:
Ja een class. In de functies van class COrderDate hoef je geen OrderDate.Month te gebruiken, als Month een data member van COrderDate is.
Dus

code:

COrderDate::telaat( )
{
  if (m_Month == 12 )
  {
    m_Month = 1;
    ++m_Year;
  }
  else
    ++m_Month;
}

member m_Month hoef je dus niet te prefixen; als je OrderData.telaat() aanroept weet de compiler dat functie telaat() OrderData.m_Month gebruikt.

Hmmmz... Dit is toch nog iets anders hoor... (Of ik interpreteer jouw reply verkeerd).
Met dat With/Do statement, kun je buiten de class de members van die class aanspreken zonder ze te prefixen.

Dus:

code:

With OrderData do begin
  teLaat()
end;

[johnwoo]

Visual Basic heeft ook een dergelijke constructie: With <object> ... End With
Deze is makkelijk bij het veelvuldig gebruik van het object (het scheelt typwerk), en levert inderdaad performance winst op: de member operator hoeft niet telkens gebruikt te worden (om deze reden is het in VB bijvoorbeeld ook goed om default properties te gebruiken, dus txtBlaat ipv txtBlaat.Text).

C++ beschikt dus niet over een dergelijke constructie... Als je meervoudige member operators in geneste structuren gebruikt kan je wel enigszins optimizen door alles behalve de laatste eenmalig uit te voeren en in een tijdelijke variabele te stoppen (scheelt alleen wanneer je veel members uit dezelfde struct gebruikt).

[Verwijderd]

(om deze reden is het in VB bijvoorbeeld ook goed om default properties te gebruiken, dus txtBlaat ipv txtBlaat.Text).

Neen. Juist niet. Hoe verder je je statements uitschrijft hoe beter. Als je de default properties gebruikt gaat het systeem bij elke aanroep kijken wat de default property is en daarna die waarde terug geven. Als je een statement helemaal uitschrijft vermijd je die lookup.

code:

Debug.Print oText.Text

is dus sneller dan:

code:

Debug.Print oText

Alhoewel het ongeveer 0.1 seconde op 200.000 calls scheelt. Maar toch.

[Soultaker]

Volgens mij hoeft er geen enkel prestatieverschil te zijn. De compiler zou zelf best kunnen afleiden dat wanneer meerdere keren de leden van eenzelfde structure/object aangesproken worden, het adres daarvan elke keer hetzelfde is. Ik weet niet in hoeverre dat gebeurt bij complexere expressies (a.b.c.d = x; bijvoorbeeld) maar zeker in het (simpele) geval van "object.methode()" of "object.attribuut = x" is er geen sprake van overhead. Uiteindelijk zijn ook de complexere expressies hier wel naar terug te leiden (met gebruikmaking van pointers), dus een gebrek is het niet.

Misschien kan iemand een voorbeeld stukje met gecompileerde code aanvoeren om het argument van performancewinst kracht bij te zetten?

Ik vond het in Pascal trouwens wel een handige constructie; maakt de code er vaak beknopter en duidelijker op.

[MSalters]

whoami schreef op 02 september 2002 @ 14:29:

[...]


Hmmmz... Dit is toch nog iets anders hoor... (Of ik interpreteer jouw reply verkeerd).
Met dat With/Do statement, kun je buiten de class de members van die class aanspreken zonder ze te prefixen.

Heiden! Op de brandstapel!
Members van m'n class molesteren buiten die class, hoe durf je ?

De with...do constructie wordt typisch gebruikt om een aantal wijzigingen in een class in een operatie uit te veoern. Blijkbaar is er dus een samenhang tussen die members. Die samenhang is in OO-development een zaak van de class implementatie, en moet dus binnen die class gehouden worden. Vanuit een OO-oogpunt is het dus goed dat de do...with constructie niet bestaat.

Dus:

code:

With OrderData do begin
  teLaat()
end;

smiley?

[whoami]

Soultaker schreef op 02 september 2002 @ 16:08:
Volgens mij hoeft er geen enkel prestatieverschil te zijn.

Misschien kan iemand een voorbeeld stukje met gecompileerde code aanvoeren om het argument van performancewinst kracht bij te zetten?

Ik vond het in Pascal trouwens wel een handige constructie; maakt de code er vaak beknopter en duidelijker op.

Uit de Delphi help:

f the interpretation of obj involves indexing arrays or dereferencing pointers, these actions are performed once, before statement is executed. This makes with statements efficient as well as concise.

Dit is natuurlijk nog altijd geen bewijs dat het with-statement performanter is...

[whoami]

MSalters schreef op 02 september 2002 @ 19:04:
[...]

Heiden! Op de brandstapel!
Members van m'n class molesteren buiten die class, hoe durf je ?

De with...do constructie wordt typisch gebruikt om een aantal wijzigingen in een class in een operatie uit te veoern. Blijkbaar is er dus een samenhang tussen die members. Die samenhang is in OO-development een zaak van de class implementatie, en moet dus binnen die class gehouden worden. Vanuit een OO-oogpunt is het dus goed dat de do...with constructie niet bestaat.

[...]

smiley?

Hoe bedoel je?
* whoami snapt het ff niet.

Het With statement zorgt er toch voor dat je bv ipv

code:

MijnObject.TeLaat();
MijnObject.NogEensTelaat();

kan schrijven als

code:

with MijnObject do begin
  TeLaat();
  NogEensTelaat();
end;

* whoami snapt je punt niet....

[Soultaker]

MSalters schreef op 02 september 2002 @ 19:04:
De with...do constructie wordt typisch gebruikt om een aantal wijzigingen in een class in een operatie uit te veoern. Blijkbaar is er dus een samenhang tussen die members. Die samenhang is in OO-development een zaak van de class implementatie, en moet dus binnen die class gehouden worden. Vanuit een OO-oogpunt is het dus goed dat de do...with constructie niet bestaat.

Hier snap ik niets van. Het is slechts een duidelijke korte schrijfwijze. Als ik bijvoorbeeld een bepaalde operatie wil uitvoeren, maakt het toch niet uit of ik:

code:

matrix.getRow(2).multiply(3);
matrix.getRow(2).subtract(v);
matrix.getRow(2).divide(matrix.getRow(2).length);
};

schrijf, of:

code:

with (matrix.getRow(2)) {
   multiply(3);
   subtract(v);
   divide(length);   
};

Het is slechts een notatieverschil. Het tweede is duidelijk compacter en niet minder helder. Er wordt geen encapsulatie gebroken (in feite wordt in beide gevallen precies hetzelfde uitgedrukt) of anderszins tegen OO beginselen in gehandeld.

Waar is het dan "vanuit OO oogpunt goed" dat de with-constructie niet in een taal als C (die toch al geen OO ondersteund, maar dit terzijde) zit?

edit:
Ah, what whoami dus ook al zei.

[MSalters]

whoami schreef op 02 september 2002 @ 19:59:
* whoami snapt het ff niet.

Het With statement zorgt er toch voor dat je bv ipv

code:

MijnObject.TeLaat();
MijnObject.NogEensTelaat();

kan schrijven als

code:

with MijnObject do begin
  TeLaat();
  NogEensTelaat();
end;

Ja, in deze vorm (methods aanroepen ipv data members veranderen) is do...with onschuldiger. Het punt is dat de with...do suggereert dat de instructries bij elkaar horen. Dat suggereert weer dat die groepering in een class hoort, mogelijk zelfs de MijnObject class.
Mijn punt was dus dat with...do z'n origine heeft in niet-OO talen en dat OO-talen een alternatief hebben (this-> weglaten in class methods)

[whoami]

In m'n voorbeeld is MijnObject een instance van een class (stel de TMijnObject class).
Ik wil de memberfuncties TeLaat en NogEensTelaat aanroepen, maar ipv de gebruikelijke notatie

code:

MijObject.Telaat();
MijnObject.NogEensTeLaat();

te gebruiken, gebruik ik het with-statement.
With Do suggereert toch helemaal niet dat de instructies bij elkaar horen?

Stel bijvoorbeeld volgende Delphi code:

code:

with Button1 do begin
  Caption      := 'Ok';
  Left            := 15;
  Top            := 20;
  Width        := 75;
end;

Hier ga je een aantal properties van die Button initialiseren.
Ik zie totaal het probleem niet (uit OO standpunt) als je dat nu zo schrijft of zo:

code:

Button1.Text := 'Ok';
Button1.Top  := 15;
...

[MSalters]

whoami schreef op 03 september 2002 @ 09:15:

Stel bijvoorbeeld volgende Delphi code:

code:

with Button1 do begin
  Caption      := 'Ok';
  Left            := 15;
  Top            := 20;
  Width        := 75;
end;

Hier ga je een aantalproperties van die Button initialiseren.
Ik zie totaal het probleem niet (uit OO standpunt) als je dat nu zo schrijft of zo:

code:

Button1.Text := 'Ok';
Button1.Top  := 15;
...

Het OO-equivalent daarvan in C++ is toch ook niet lang:

code:

OK_Button::OK_Button( ) :
    text( "Ok" ),
    top( 15 ),
    ...
{
}

Daarvoor heb je ook geen herhaling van de objectnaam. Wat jij laat zien is typische code van een niet-OO taal. C++ heeft equivalente schrijfwijzes binnen een class. Die zijn idd niet zo breed bruikbaar als with..do

De reden dat je dit soort code bij elkaar moet houden is vanwege de samenhang tussen al die properties. Een button met text "Cancel" moet breder zijn dan een button met text "Ok". vanuit een OO-standpunt moet je die twee dingen dus samen in een Button member wijzigen.

[whoami]

Hmmm.... Daarmee ga ik niet akkoord. Dat C++ equivalent is geen equivalent van de With/Do constructie imho, want daar doe je het binnen de class.

Met de With Do constructie roep je properties en memberfuncties aan buiten de class zelf.
M'n voorbeeld was misschien niet zo'n goed voorbeeld en je kunt idd properties enzo gaan initialiseren inde constructor (zoals het eigenlijk hoort).

Dat een button met de text cancel breder moet zijn dan een button met de text ok is een kwestie van smaak. Ik zie ze liever alletwee even breed.


Als jij een object hebt, waarvan je een aantal member-functies wilt aanroepen, dan doe je dat in C++ door iedere keer de objectnaam te schrijven, de '. operator' te gebruiken en de functienaam te schrijven.
In Delphi doe je dat ook zo, maar daar kun je gebruik maken van die With do. (Merk op dat je in die With/do constructie ook nog andere statements kunt gebruiken die niets met het object te maken hebben dat je specifieert in 'With'.

[Verwijderd]

Het grootste argument tegen with ... do is het breken van de (global) namespace. Deze construct gebruiken is vergelijkbaar met using namespace std; of iets dergelijks in je code zetten. Alle argumenten die gelden tegen het gebruik van "using namespace ...", gelden ook als argumenten tegen het gebruik van "with ... do".

[whoami]

Verwijderd schreef op 03 september 2002 @ 12:44:
Het grootste argument tegen with ... do is het breken van de (global) namespace. Deze construct gebruiken is vergelijkbaar met using namespace std; of iets dergelijks in je code zetten. Alle argumenten die gelden tegen het gebruik van "using namespace ...", gelden ook als argumenten tegen het gebruik van "with ... do".

Idd, en daarom gebruik ik hem dan ook niet. (Zoals ik al eerder aangaf).

[Soultaker]

Verwijderd schreef op 03 september 2002 @ 12:44:
Het grootste argument tegen with ... do is het breken van de (global) namespace. Deze construct gebruiken is vergelijkbaar met using namespace std; of iets dergelijks in je code zetten. Alle argumenten die gelden tegen het gebruik van "using namespace ...", gelden ook als argumenten tegen het gebruik van "with ... do".

Met het verschil dat with-constructies duidelijk gedefinieerd zijn (er ontstaat een nieuw code blok) waar "using namespace" overal in het bestand kan voorkomen (waardoor onduidelijk is op welk punt welke namespace in gebruik is). Daarbij zijn with-constructies doorgaans kort (een paar regels tot hooguit een scherm vol, weet ik uit mijn Pascal-verleden) waardoor de scope echt maar tijdelijk verplaatst wordt en op een veel minder ingrijpende manier dan met "using namespace" het geval is.

Mij lijkt de with-constructie vooral handig in combinatie met expressies die ik niet elke keer opnieuw wil evalueren, maar waarvoor ik ook geen tijdelijke variabele wil instantieren. Het is dan een alternatief voor:

code:

  Color color = getCurrentWindow()->getBackGroundColor();
  color->setRed = 123;
  color->setBlue = 45;
  color->setGreen = 67;

Naar mijn idee is de variant met with-.... dan wel erg duidelijk. Een fundamentele feature wordvoegt 't echter niet toe.

[MSalters]

Nog een puntje; in C++ kun je method calls best chainen:

code:

cout << "Hello"
        << ", world"
        << std::endl;

of

code:

MijnObject
  .Telaat()
  .NogEensTeLaat();

Gewoon *this returnen (by reference).

[whoami]

MSalters schreef op 03 september 2002 @ 15:49:
Nog een puntje; in C++ kun je method calls best chainen:

code:

cout << "Hello"
        << ", world"
        << std::endl;

of

code:

MijnObject
  .Telaat()
  .NogEensTeLaat();

Gewoon *this returnen (by reference).

In jouw eerste geval (cout) is '<<' toch een operator en geen method?

[curry684]

Een operator overload is per definitie een method.

Ter verduidelijking:

code:

const cout& cout::operator << (const char* p_String)
{
...

return *this;
}

[ Voor 0% gewijzigd door curry684 op 03-09-2002 16:54 . Reden: Verduidelijking ]

[Verwijderd]

Ik definieer io-ops zo:

code:

std::ostream& operator << (std::ostream&, const MyClass&);
std::istream& operator >> (std::istream&, MyClass&);

En dan is het zeker geen method. Als het wel methods waren zou dat betekenen dat classes "open" zijn, maw. dat je later cq. op een andere plek in je code nog methods (en data-members) aan een class definition kunt toevoegen. Dat breekt natuurlijkt met de hele ontwerpfilosofie van C++.

[curry684]

Nu is het mijn beurt om te roepen, want je laat nu 2 method-signatures zien en beweert dat dat geen methods zijn..... het enige verschil is dat jij 'm buiten de class globaal definieert (gatver imho ) maar dat maakt het niet minder een method...

Of is in jouw woordenboek een method per definitie een class-method?

[Verwijderd]

curry684 schreef op 04 september 2002 @ 12:05:
Nu is het mijn beurt om te roepen, want je laat nu 2 method-signatures zien en beweert dat dat geen methods zijn..... het enige verschil is dat jij 'm buiten de class globaal definieert (gatver imho ) maar dat maakt het niet minder een method...

Methods zijn voor mij nooit global, ze staan altijd in de namespace van de class waartoe ze behoren. Het verschil met jouw definitie is dat jij:
a) Een class/object definition probeert uit te breiden met een method (en dat kan niet).
b) Een method probeert toe te kennen aan een object (cout) en niet aan een class (kan ook niet).

Maw. jouw operator geeft een boel errors, maar doet zeker niet wat jij wilt.

Of is in jouw woordenboek een method per definitie een class-method?

Ja. Methods zijn functies die gerelateerd zijn aan een bepaald object of beter klasse van objecten.

[curry684]

Verwijderd schreef op 04 september 2002 @ 14:24:
Methods zijn voor mij nooit global, ze staan altijd in de namespace van de class waartoe ze behoren. Het verschil met jouw definitie is dat jij:
a) Een class/object definition probeert uit te breiden met een method (en dat kan niet).
b) Een method probeert toe te kennen aan een object (cout) en niet aan een class (kan ook niet).
Maw. jouw operator geeft een boel errors, maar doet zeker niet wat jij wilt.

Oh DAAR had je het over... sinds wanneer gaan we mierenneuken over voorbeelden ter verduidelijking? Ik klopte gewoon iets in dat het verhaal over operator overloads verduidelijkte voor whoami, maar ik zal de volgende keer weer 'MyClass' intypen ipv 'cout'...

Ja. Methods zijn functies die gerelateerd zijn aan een bepaald object of beter klasse van objecten.

En da is dus nie zo, zelfs Microsoft in deel 1 van cursus C# heeft het nog over 'global methods' als tegenhanger van class methods. Of hier in een recente .NET cursus van DNJ online de volgende passage:

"Every executable must have an entry point. In C++ this is either main() or WinMain(). The .NET Framework does allow you to have global methods, but of all the .NET languages only Managed C++ allows you to declare global methods. The other languages only allow methods to be declared as part of a class. You access a global method from outside of the assembly where it is defined by using an instance of the Module class for the module in which it is defined. When the compiler sees a main() or WinMain() method in your code it generates code to initialise the CRT and makes the method the entry point for the assembly."

Meer voorbeelden zijn er genoeg te vinden overigens.

[Zoijar]

In C++ heten het trouwens gewoon functions, en member functions. "method" is een java-isme hehe

[curry684]

Zoijar schreef op 04 september 2002 @ 15:57:
In C++ heten het trouwens gewoon functions, en member functions. "method" is een java-isme hehe

[.oisyn]

Zoijar schreef op 04 september 2002 @ 15:57:
In C++ heten het trouwens gewoon functions, en member functions. "method" is een java-isme hehe

onzin, methode is een OO term (nou ja eigenlijk meer een design term -> UML), net als attribuut, wat een membervar is

ikzelf noem het trouwens ook functions en memberfunctions

[Zoijar]

Ja weet ik toch Vond het alleen een leuk woord; en het valt me op dat voornamelijk de Java mensen over methoden spreken.

[.oisyn]

ja idd...

oh, en dan is er ook nog de term 'procedure'

[Verwijderd]

Dit lijkt W&L wel, het draait uit op definitiekwesties

Mijn definitie is trouwens best wel verdedigbaar, want in zuiver OO-design bestaat er niet zoiets als een "global method"; zuivere OO kent geen globals.

Daarom is in een pure OO-taal zelfs de main() niet global, iets wat leuk naar voren komt in de quote van curry684. (You shot yourself in the foot there )

[.oisyn]

de global namespace kun je in principe ook gewoon zien als een singleton zonder naam, dus waarom zou het niet passen in zuivere OO ?

[Verwijderd]

In zuivere OO hanteer je alleen objecten, en zijn alle objecten instances van eoa. class. Een namespace is per definitie geen class en is ook niet op een zelfde manier adresseerbaar; je kunt geen instance van een namespace creeeren.

[.oisyn]

vandaar dat ik ook zei 'singleton'

of is dat volgens jou ook geen OO concept?

[mbravenboer]

.oisyn: de global namespace kun je in principe ook gewoon zien als een singleton zonder naam

Wat een fantatische, amusante en formele benadering!

[.oisyn]

ja ik vond m wel creatief

maar even serieus, niet dan?
Of je 'm nou benaderd met of zonder naam boeit eigenlijk niet zoveel... dat is alleen een syntactisch iets

en stel ik heb dit stukje code:

C++:

namespace Printer
{
    int status;

    void print (const char *);
    void println (const char *);
    void lineFeed ();
}

(even niet letten op wat ik code, het gaat om het principe )

En vergelijk dit met een singleton met de naam Printer. Wat is dan het wezenlijke verschil?

[Verwijderd]

.oisyn schreef op 04 september 2002 @ 20:42:
maar even serieus, niet dan?
Of je 'm nou benaderd met of zonder naam boeit eigenlijk niet zoveel... dat is alleen een syntactisch iets

Ok, ff serieus Een singleton is een design-pattern, classes en objects zijn de fundamentele bouwstenen van OO; maw. je bouwt een singleton door te zorgen dat er maar een object van een bepaalde class geinstantieerd kan worden.

En vergelijk dit met een singleton met de naam Printer. Wat is dan het wezenlijke verschil?

Stel dat Printer een echte singleton is:

C++:

class SingletonPrinter {
public:
    static int status;
    static device_t device;
    static void print(const char *);
};

extern SingletonPrinter Printer;

...

typeof(Printer) p;
p.print("Je kunt een alias van een singleton maken, maar niet van een namespace");

Er bestaat dus wel degelijk semantisch verschil tussen een singleton en een namespace: een singleton heeft als object een type, een namespace niet. (Maar dat zei ik al met andere woorden.)

[ Voor 0% gewijzigd door Verwijderd op 05-09-2002 01:03 . Reden: code verduidelijkt ]

[.oisyn]

Wat is het verschil tussen een class met alleen statische functies/variabelen en een namespace? Je kunt geen van beiden instantieren. En een class is ook een namespace

(en je kunt van namespaces wel aliases maken )

de definitie van een singleton is a set containing a single member. De vraag is alleen of je een namespace kunt zien als een set. Een namespace heeft idd geen type... maar moet dat dan per se?

[Verwijderd]

.oisyn schreef op 05 september 2002 @ 01:03:
Wat is het verschil tussen een class met alleen statische functies/variabelen en een namespace?

Dat zeg ik toch? In zuivere OO is ook een singleton een object, het direct benaderen van statics is not-done. Om een echte singleton te maken moet je die class instantieeren.

en afgezien van het feit dat jouw voorbeeldcode niet werkt (ik neem aan dat het C++ is), kun je van namespaces wel aliases maken

Ik had te vroeg gepost, had de de typeof haakjes vergeten

edit:

.oisyn: de definitie van een singleton is a set containing a single member.

Dit is eigenlijk de definitie uit verzamelingenleer. In OO-termen zou je "set" moeten vertalen met "class" en "member" met "object".

[.oisyn]

! major edit alert !
Ik heb mijn vorige post nogal gewijzigd

en typeof is overigens een gcc iets volgens mij

[.oisyn]

Verwijderd schreef op 05 september 2002 @ 01:11:
.oisyn: de definitie van een singleton is a set containing a single member.

Dit is eigenlijk de definitie uit verzamelingenleer. In OO-termen zou je "set" moeten vertalen met "class" en "member" met "object".

mmja daar zat ik dus ook aan te denken toen ik die defnitie tegen kwam... ik ben het eigenlijk wel met je eens

[Verwijderd]

Ik ben blij dat we het in het major edit-slachtveld eens worden

typeof is idd. een gnu-extensie, ik wilde het voorbeeld zo mooi mogelijk maken en ging daarom de bonen in denk ik

[curry684]

Wat is het verschil tussen een class met alleen statische functies/variabelen en een namespace? Je kunt geen van beiden instantieren.

Een class met alleen statische functies kun je best instantieren... het is alleen een beetje pointless