[alg] Slechtste programmeervoorbeelden deel 4

[YopY]

De ontwikkeling van Java ligt ook al lang niet meer in de taal zelf, maar meer in de (wel open source) projecten die eromheen draaien. Een trits van de features die Roy-t opnoemt zijn ook gewoon syntactische suiker voor dingen die al aanwezig zijn in Java - allemaal dingen die in de compiler ingebouwd worden.

Java zal ook een stille dood sterven, ben ik bang. Gelukkig is .NET (in de basis) niet zo'n grote overstap. Je zult echter wel de ontwikkelingen die C# in die tijd wél ondergaan heeft moeten leren (linq, properties, dat soort dingen).

Ik heb nog steeds wel het idee dat Java meer 'enterprise-y' is - d'r zijn meer Echt Grote applicaties en dergelijke mee gemaakt dan .NET. Kan ik mis hebben natuurlijk.

Mede omdat er jaren terug zoveel investeringen daarin gedaan zijn zal Java nog gedurende lange tijd zijn eigen niche innemen.

[Verwijderd]

Gamebuster schreef op maandag 08 november 2010 @ 15:34:
[...]

Lekker consequent. Broncode? Taal?

Java: (Slordige code ik weet het )

code:

        long start;
        long end;
        
        for(int testcount = 0; testcount < 5; testcount++) {
            start = System.currentTimeMillis();
            for(int i = 0; i < 100000; i++) {
            StringBuilder sb = new StringBuilder();
                sb.append("Test1");
                sb.append("Test2");
                sb.append("Test3");
                sb.append("Test4");
                sb.append("Test5");
                
                sb.append("Test6");
                sb.append("Test7");
                sb.append("Test8");
                sb.append("Test9");
                sb.append("Test10");
                
                sb.append("Test11");
                sb.append("Test12");
                sb.append("Test13");
                sb.append("Test14");
                sb.append("Test15");
                
                sb.append("Test16");
                sb.append("Test17");
                sb.append("Test18");
                sb.append("Test19");
                sb.append("Test20");
                
                sb.append("Test21");
                sb.append("Test22");
                sb.append("Test23");
                sb.append("Test24");
                sb.append("Test25");
                
                sb.append("Test26");
                sb.append("Test27");
                sb.append("Test28");
                sb.append("Test29");
                sb.append("Test30");
                sb.toString();
            }
            end = System.currentTimeMillis();
            System.out.println("StringBuilder: " + (end - start) + "ms");
        }
        //buffer
        for(int testcount = 0; testcount < 5; testcount++) {
            start = System.currentTimeMillis();
            for(int i = 0; i < 100000; i++) {
                StringBuffer sb = new StringBuffer();
                sb.append("Test1");
                sb.append("Test2");
                sb.append("Test3");
                sb.append("Test4");
                sb.append("Test5");
                
                sb.append("Test6");
                sb.append("Test7");
                sb.append("Test8");
                sb.append("Test9");
                sb.append("Test10");
                
                sb.append("Test11");
                sb.append("Test12");
                sb.append("Test13");
                sb.append("Test14");
                sb.append("Test15");
                
                sb.append("Test16");
                sb.append("Test17");
                sb.append("Test18");
                sb.append("Test19");
                sb.append("Test20");
                
                sb.append("Test21");
                sb.append("Test22");
                sb.append("Test23");
                sb.append("Test24");
                sb.append("Test25");
                
                sb.append("Test26");
                sb.append("Test27");
                sb.append("Test28");
                sb.append("Test29");
                sb.append("Test30");
                sb.toString();
            }
            end = System.currentTimeMillis();
            System.out.println("StringBuffer: " + (end - start) + "ms");
        }
        //concat
        
        for(int testcount = 0; testcount < 5; testcount++) {
            start = System.currentTimeMillis();
            for(int i = 0; i < 100000; i++) {
                String s = new String();
                s = "Test1";
                s += "Test2";
                s += "Test3";
                s += "Test4";
                s += "Test5";
                
                s += "Test6";
                s += "Test7";
                s += "Test8";
                s += "Test9";
                s += "Test10";
                
                s += "Test11";
                s += "Test12";
                s += "Test13";
                s += "Test14";
                s += "Test15";
                
                s += "Test16";
                s += "Test17";
                s += "Test18";
                s += "Test19";
                s += "Test20";
                
                s += "Test21";
                s += "Test22";
                s += "Test23";
                s += "Test24";
                s += "Test25";
                
                s += "Test26";
                s += "Test27";
                s += "Test28";
                s += "Test29";
                s += "Test30";
            }
            end = System.currentTimeMillis();
            System.out.println("Concat: " + (end - start) + "ms");
        }

[Janoz]

Om echt fatsoenlijk te kunnen testen lijkt het me handiger wanneer je ook wat System.gc() sprokkelt. Daarnaast zijn regel 98 en 99 natuurlijk een beetje dubbelop.

[Hydra]

YopY schreef op maandag 08 november 2010 @ 16:28:
Java zal ook een stille dood sterven, ben ik bang. Gelukkig is .NET (in de basis) niet zo'n grote overstap. Je zult echter wel de ontwikkelingen die C# in die tijd wél ondergaan heeft moeten leren (linq, properties, dat soort dingen).

Ik heb nog steeds wel het idee dat Java meer 'enterprise-y' is - d'r zijn meer Echt Grote applicaties en dergelijke mee gemaakt dan .NET. Kan ik mis hebben natuurlijk.

Mede omdat er jaren terug zoveel investeringen daarin gedaan zijn zal Java nog gedurende lange tijd zijn eigen niche innemen.

No way. Vrijwel alle grote projecten waar ik de laatste 8 jaar opgezeten heb zijn Java gebaseerd. Ik denk dat Java pas zal uitsterven lang nadat Cobol uitgestorven is

[Davio]

Niet alleen slordige code, ook onbetrouwbaar.

Eigenlijk moet je elke verschillende run na een koude reboot doen. En dan 100x per run en dan het gemiddelde nemen of zo.

[Janoz]

Met Hydra. Als ik in de enterprise business om mij heen kijk dan is het vooral Java wat de klok slaat. Oracle == Java, Google == Java, IBM == Java, SAP == Java. Zolang er nog non windows servers draaien in enterprise omgevingen zal de Java backend niet snel door .NET vervangen worden.

[Sebazzz]

Of er moet een verdomd goede officiële én gratis .NET runtime voor non-Windows servers komen van MS.

[.oisyn]

Wat me stug lijkt, ze hebben daar vrij weinig aan (de ROI voor mensen die .Net gaan inzetten op non-MS platforms is natuurlijk nihil). Ze verdienen natuurlijk voornamelijk aan Windows licenties, niet aan Visual Studio licenties

[ Voor 26% gewijzigd door .oisyn op 08-11-2010 16:56 ]

[MBV]

Hydra schreef op maandag 08 november 2010 @ 16:44:
[...]


No way. Vrijwel alle grote projecten waar ik de laatste 8 jaar opgezeten heb zijn Java gebaseerd. Ik denk dat Java pas zal uitsterven lang nadat Cobol uitgestorven is

Ik betwijfel dat. Java-code wordt vaak na 5 jaar al gezien als legacy, terwijl dat initieel bij Cobol veel langer duurde (bron: geen idee, een presentatie van een paper op VVSS 2009). Als je zo snel al je code wilt vervangen stap je ook sneller over op een ander platform.
Ook is de overstap van Java-code naar pak-em-beet .NET een stuk milder dan van COBOL-spaghetti naar OOD, de COBOL-spaghetti zal eerder gebruikt blijven worden met het motto 'if it ain't broke, don't fix it'.

[ Voor 15% gewijzigd door MBV op 08-11-2010 18:10 ]

[Alex)]

.NET is anders aardig groeiende in de enterprise wereld... ik kom tegenwoordig steeds vaker klanten met een "Microsoft, tenzij"-beleid voor al hun software. Ook overheid.

[YellowOnline]

Styxxy schreef op maandag 01 november 2010 @ 22:02:
Ik ben net een mooie tegen gekomen in PHP...

PHP:

<?php

function worteltrekken($getal) 
{ 
    $resultaat = $getal / $getal; 
    return $resultaat; 
}

Nogal laat, maar ROFL

Alex) schreef op maandag 08 november 2010 @ 18:07:
.NET is anders aardig groeiende in de enterprise wereld... ik kom tegenwoordig steeds vaker klanten met een "Microsoft, tenzij"-beleid voor al hun software. Ook overheid.

Wij gooien alles Java (e.a.) buiten en gaan vanaf 2010 enkel nog binnen het .NET framework devven.

[418O2]

Alex) schreef op maandag 08 november 2010 @ 18:07:
.NET is anders aardig groeiende in de enterprise wereld... ik kom tegenwoordig steeds vaker klanten met een "Microsoft, tenzij"-beleid voor al hun software. Ook overheid.

Ik ook.

.Net biedt wel een hoop tools waardoor je sneller kan ontwikkelen. Maar de die-hard Java mannen zullen wel nooit accepteren dat .Net ook bestaansrecht heeft en groeit.

[Verwijderd]

Janoz schreef op maandag 08 november 2010 @ 16:43:
Om echt fatsoenlijk te kunnen testen lijkt het me handiger wanneer je ook wat System.gc() sprokkelt. Daarnaast zijn regel 98 en 99 natuurlijk een beetje dubbelop.

met gc tussen de tests door krijg ik nog steeds ongeveer dezelfde testwaarde. Regel 98 en 99 is dubbel op ja, maar maakt verder weinig verschil.

Davio schreef op maandag 08 november 2010 @ 16:45:
Niet alleen slordige code, ook onbetrouwbaar.

Eigenlijk moet je elke verschillende run na een koude reboot doen. En dan 100x per run en dan het gemiddelde nemen of zo.

Dat is me iets te veel moeite voor een simpel testje

[Janoz]

418O2 schreef op maandag 08 november 2010 @ 18:19:
.Net biedt wel een hoop tools waardoor je sneller kan ontwikkelen. Maar de die-hard Java mannen zullen wel nooit accepteren dat .Net ook bestaansrecht heeft en groeit.

.Net heeft zeker bestaandsrecht en is ook zeker niet minderwaardig oid. Ik ageer meer tegen de onwetendheid dan tegen .Net. Neem bijvoorbeeld de opmerking '.Net biedt een hoop tools'. Alsof alle java devvers nog allemaal collectief in vi aan het kloppen zijn .

[Verwijderd]

Het moet ook zijn ".NET biedt betere tools".

[Gamebuster]

Verwijderd schreef op maandag 08 november 2010 @ 16:28:
[...]


Java: (Slordige code ik weet het )
*code*

Is het niet beter als je de tests apart doet ipv alle3 achter elkaar?

Verwijderd schreef op maandag 08 november 2010 @ 19:44:
Het moet ook zijn ".NET biedt betere tools".

Wat is er mis met Netbeans IDE? -behalve dat het niet de snelste IDE is die er is

[ Voor 35% gewijzigd door Gamebuster op 08-11-2010 19:54 ]

[dev10]

Gamebuster schreef op maandag 08 november 2010 @ 19:52:
Wat is er mis met Netbeans IDE? -behalve dat het niet de snelste IDE is die er is

Nog nooit echt met Visual Studio gewerkt zeker?

[Matis]

dev10 schreef op maandag 08 november 2010 @ 19:58:
Nog nooit echt met Visual Studio gewerkt zeker?

Doel je daarmee op de snelheid van VS of het gebruikersgemak.

Je kunt jouw reactie op twee manieren uitleggen

[Janoz]

Verwijderd schreef op maandag 08 november 2010 @ 19:44:
Het moet ook zijn ".NET biedt betere tools".

Noem voor de grap eens wat voorbeelden. En als je daar mee bezig bent, noem gelijk ook de 'betere' alternatieven voor bijvoorbeeld Maven, Hudson en Sonar.

[roy-t]

Janoz schreef op maandag 08 november 2010 @ 15:55:
Maar werd/wordt dat ook vanuit de sourcecode gegenereerd? (Daar doelde ik eigenlijk meer op)

In Visual Basic 6 iig al wel

YopY schreef op maandag 08 november 2010 @ 16:28:
De ontwikkeling van Java ligt ook al lang niet meer in de taal zelf, maar meer in de (wel open source) projecten die eromheen draaien. Een trits van de features die Roy-t opnoemt zijn ook gewoon syntactische suiker voor dingen die al aanwezig zijn in Java - allemaal dingen die in de compiler ingebouwd worden.

Java zal ook een stille dood sterven, ben ik bang. Gelukkig is .NET (in de basis) niet zo'n grote overstap. Je zult echter wel de ontwikkelingen die C# in die tijd wél ondergaan heeft moeten leren (linq, properties, dat soort dingen).

Ik heb nog steeds wel het idee dat Java meer 'enterprise-y' is - d'r zijn meer Echt Grote applicaties en dergelijke mee gemaakt dan .NET. Kan ik mis hebben natuurlijk.

Mede omdat er jaren terug zoveel investeringen daarin gedaan zijn zal Java nog gedurende lange tijd zijn eigen niche innemen.

Veel tools zijn compleet enterprise gericht, zoals de high-end varianten van Visual Studio, TFS e.d. Misschien komt het omdat we beide van uit andere perspectieven kijken. Ik kijk vanaf de .NET kant en vond .NET meer enterprisey (ken veel bedrijven die er wat mee doen). Maar jij kijkt vanaf de JAVA kant en ziet het precies andersom . Grappig eigenlijk.

(semi related http://msdn.microsoft.com/en-us/library/ff647095.aspx )

Waar ik me wel aan stoor de laatste tijd bij MSDN is dat ik telkens even moet wachten omdat ik ingelogd wordt.

Ook is VS2010 net iets minder snel als VS2008, wat ik toch wel erg jammer vind. (Ik ben pas een week over, dus ik 'voel de pijn' nog echt. Ondanks dat VS2010 toch net weer een stukje overzichterlijker is, ook lijkt builden iets sneller, maar als je een exception krijgt duurt het net wat lang voordat je weer terug in VS2010 bent met de debug-stepper op de juiste regel.)

Ahja, er is veel te zeggen voor beide platformen, maar eigenlijk moet een sterke groep (Oracle eigenlijk) gewoon weer dik gaan pushen met JAVA zodat het weer op de rails komt en dingen zoals properties er in komen (even catch-up spelen met .NET) om daarna weer innovatief te zijn!

[Gamebuster]

dev10 schreef op maandag 08 november 2010 @ 19:58:
[...]


Nog nooit echt met Visual Studio gewerkt zeker?

Goed geraden

Ik draai Mac OS X. Visual Studio is dus sowieso geen optie. Ik werk liever met software dat platform onafhankelijk is; als ik een OS zat ben kan ik verder gaan met een ander OS zonder al mijn software te moeten missen. Netbeans is wat traag, maar werkt wel op ieder platform. Voor mijn C++ "experimentjes" gebruik ik afwisselend Xcode en netbeans; Xcode voelt een stuk soepeler aan, maar vind netbeans prettiger. De rest (PHP, Java, Javascript) doe ik in Netbeans IDE.

offtopic:
Ik vind Windows overigens maar een vervelend OS. Ik heb er jaren mee gewerkt, maar sinds ik een keer een tijdje Ubuntu draaide wilde ik nooit meer terug. Uiteindelijk een Macbook Pro gekocht i.c.m. Mac OS X voor het gebruikersgemak en nettere UI in combinatie met de betrouwbaarheid/stabiliteit van Ubuntu.

Misschien IDE discussies voortzetten in De Devschuur Coffee Corner?

[ Voor 6% gewijzigd door Gamebuster op 08-11-2010 20:35 ]

[boe2]

Gamebuster schreef op maandag 08 november 2010 @ 20:32:
[...]
Heb een Apple. Ik werk liever met software dat platform onafhankelijk is;

Je werkt graag platformonafhankelijk dus je hebt een apple, wat

[Gamebuster]

Boeboe schreef op maandag 08 november 2010 @ 20:35:
[...]


Je werkt graag platformonafhankelijk dus je hebt een apple, wat

Ik zei niet "ik werk graag platform onafhankelijk dus ik heb een apple", ik zei "ik heb een Apple [punt] Ik draai graag platform onafhankelijke software".

Daarnaast, hoezo is de Apple computer niet platform onafhankelijk? Ik kan er Mac OS X opzetten, Ik kan er Windows opzetten en ik kan er Linux opzetten. Wat is het probleem?

offtopic:
Overigens, we gaan erg offtopic. De Devschuur Coffee Corner lijkt me een betere plek om verder te gaan.

[ Voor 13% gewijzigd door Gamebuster op 08-11-2010 20:42 ]

[Davio]

Verwijderd schreef op maandag 08 november 2010 @ 19:25:
[...]


met gc tussen de tests door krijg ik nog steeds ongeveer dezelfde testwaarde. Regel 98 en 99 is dubbel op ja, maar maakt verder weinig verschil.


[...]


Dat is me iets te veel moeite voor een simpel testje

Ik gebruik trouwens zelf altijd System.Diagnostics.Stopwatch voor dat soort testjes in plaats van 2x de systeemtijd ophalen, lijkt voor dit soort gevalletjes bedoeld te zijn: http://msdn.microsoft.com...iagnostics.stopwatch.aspx

[Gamebuster]

Davio schreef op maandag 08 november 2010 @ 21:02:
[...]

Ik gebruik trouwens zelf altijd System.Diagnostics.Stopwatch voor dat soort testjes in plaats van 2x de systeemtijd ophalen, lijkt voor dit soort gevalletjes bedoeld te zijn: http://msdn.microsoft.com...iagnostics.stopwatch.aspx

Het is Java, geen C#.

[Phyxion]

Gamebuster schreef op maandag 08 november 2010 @ 19:52:
[...]

Is het niet beter als je de tests apart doet ipv alle3 achter elkaar?


[...]

Wat is er mis met Netbeans IDE? -behalve dat het niet de snelste IDE is die er is

Je kan beter opnoemen wat er niet mis is met NetBeans, alhoewel ik daar ook zo snel even niks van weet.

[Gamebuster]

Phyxion schreef op maandag 08 november 2010 @ 21:15:
[...]

Je kan beter opnoemen wat er niet mis is met NetBeans, alhoewel ik daar ook zo snel even niks van weet.

Owke.

De meest handige feature, naast dat de syntax highlighter gewoon prima werkt en het vele talen ondersteund, is de ondersteuning van Javadoc-popups terwijl je code aanroept:



Je eigen geschreven Javadoc-comments worden zo netjes weergegeven. Werkt ook in C/C++, PHP en Javascript. Ook heeft het ingebouwde documentatie voor alle PHP- en Javascript functies en geeft het bij Javascript ook nog eens informatie over de compatibiliteit binnen de browsers, al is de informatie niet altijd up-to-date:

[Haan]

Davio schreef op maandag 08 november 2010 @ 21:02:
[...]

Ik gebruik trouwens zelf altijd System.Diagnostics.Stopwatch voor dat soort testjes in plaats van 2x de systeemtijd ophalen, lijkt voor dit soort gevalletjes bedoeld te zijn: http://msdn.microsoft.com...iagnostics.stopwatch.aspx

Werkt altijd wel lekker ja. Daarom ook maar even de string concat test omgebouwd:

C#:

class Program
{
    private const int Count = 100000;
    private const string ShortString = "append";

    private const string LongString =
        @"Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam";

    static void Main(string[] args)
    {
        // sb short string
        for (int n = 0; n < 5; n++)
        {
            var sw = Stopwatch.StartNew();
            string shortSb = UseStringBuilder(ShortString);

            sw.Stop();
            Console.WriteLine("StringBuilder short string execution time: {0} milliseconds", sw.ElapsedMilliseconds);
        }

        // sb longer string
        for (int n = 0; n < 5; n++)
        {
            var sw = Stopwatch.StartNew();
            string longSb = UseStringBuilder(LongString);
            sw.Stop();
            Console.WriteLine("StringBuilder long string execution time: {0} milliseconds", sw.ElapsedMilliseconds);
        }

        // no sb short string
        for (int n = 0; n < 5; n++)
        {
            var sw = Stopwatch.StartNew();
            string shortSb = NoStringBuilder(ShortString);
            sw.Stop();
            Console.WriteLine("No StringBuilder short string execution time: {0} milliseconds", sw.ElapsedMilliseconds);
        }

        // no sb longer string
        for (int n = 0; n < 5; n++)
        {
            var sw = Stopwatch.StartNew();
            string longSb = NoStringBuilder(LongString);
            sw.Stop();
            Console.WriteLine("No StringBuilder long string execution time: {0} milliseconds", sw.ElapsedMilliseconds);
        }

        Console.ReadKey();
    }

    static string UseStringBuilder(string appendString)
    {
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < Count; i++)
        {
            sb.Append(appendString);
        }
        return sb.ToString();
    }

    static string NoStringBuilder(string appendString)
    {
        string result = string.Empty;
        for (int i = 0; i < Count; i++)
        {
            result += appendString;
        }
        return result;
    }
}

Output:

StringBuilder short string execution time: 2 milliseconds
StringBuilder short string execution time: 1 milliseconds
StringBuilder short string execution time: 1 milliseconds
StringBuilder short string execution time: 2 milliseconds
StringBuilder short string execution time: 1 milliseconds
StringBuilder long string execution time: 42 milliseconds
StringBuilder long string execution time: 46 milliseconds
StringBuilder long string execution time: 45 milliseconds
StringBuilder long string execution time: 41 milliseconds
StringBuilder long string execution time: 47 milliseconds
No StringBuilder short string execution time: 20373 milliseconds
No StringBuilder short string execution time: 19948 milliseconds
No StringBuilder short string execution time: 20047 milliseconds
No StringBuilder short string execution time: 20701 milliseconds
No StringBuilder short string execution time: 20469 milliseconds

Dat is een behoorlijk shocking verschil in performance! De eerste keer had ik de Count nog een factor tien groter en leek het of m'n programma was vastgelopen. De long versie van de NoStringBuilder ook maar afgekapt, die gaf na aantal minuten nog steeds geen output.

[.oisyn]

Sorry hoor, maar 20 seconden om 100.000 korte strings te concatenaten? No fucking way, daar is meer aan de hand. Toevallig een debug build?

In PHP:

PHP:

$count = 100000;
$str = "append";

$s = "";
$t = -microtime(1);
for ($i = 0; $i < $count; $i++)
{
    $s .= $str;
}
$t += microtime(1);

echo $t, " seconds";

0.0251491069794 seconds

[ Voor 52% gewijzigd door .oisyn op 08-11-2010 22:25 ]

[Haan]

.oisyn schreef op maandag 08 november 2010 @ 22:21:
Sorry hoor, maar 20 seconden om 100.000 korte strings te concatenaten? No fucking way, daar is meer aan de hand. Toevallig een debug build?

In PHP:

PHP:

$count = 100000;
$str = "append";

$s = "";
$t = -microtime(1);
for ($i = 0; $i < $count; $i++)
{
    $s .= $str;
}
$t += microtime(1);

echo $t, " seconds";

[...]

Release build, executable los gerund (dus niet vanuit VS). Op een Core i5 750 processor, dus daar ligt het ook niet aan Volledige code staat hier boven, dus voel je vrij om het zelf te testen
Maar onderschat niet de overhead die je krijgt bij het 10000 keer aanmaken van een steeds groter wordende string. Zoals al werd gezegd is een string in PHP mutable en dat maakt nogal uit in performance.

[ Voor 13% gewijzigd door Haan op 08-11-2010 22:40 ]

[Gamebuster]

.oisyn schreef op maandag 08 november 2010 @ 22:21:
Sorry hoor, maar 20 seconden om 100.000 korte strings te concatenaten? No fucking way, daar is meer aan de hand. Toevallig een debug build?

In PHP:

PHP:

$count = 100000;
$str = "append";

$s = "";
$t = -microtime(1);
for ($i = 0; $i < $count; $i++)
{
    $s .= $str;
}
$t += microtime(1);

echo $t, " seconds";

[...]

Hee dat is compact gebruik van microtime. Nooit aan gedacht. Die onthoud ik

[Verwijderd]

dit komt vast heel noob over, maar..

Haan schreef op maandag 08 november 2010 @ 21:57:

C#:

    private const string LongString =
        @"Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam";

wtf doet die @ daar?

[Haan]

Verwijderd schreef op maandag 08 november 2010 @ 22:40:
dit komt vast heel noob over, maar..

[...]

wtf doet die @ daar?

Verbatim string: http://msdn.microsoft.com...ry/ms228362(v=VS.90).aspx

[ Voor 9% gewijzigd door Haan op 08-11-2010 22:43 ]

[Matis]

Haan schreef op maandag 08 november 2010 @ 22:37:
Release build, executable los gerund (dus niet vanuit VS). Op een Core i5 750 processor, dus daar ligt het ook niet aan Volledige code staat hier boven, dus voel je vrij om het zelf te testen
Maar onderschat niet de overhead die je krijgt bij het 10000 keer aanmaken van een steeds groter wordende string. Zoals al werd gezegd is een string in PHP mutable en dat maakt nogal uit in performance.

De string is een constant, dus eenvoudig voor de compiler en 6 karakters breed. Dus dat is maximaal 7 bytes. Doe je dat 100.000 keer concatineren, dan krijg je een stunning 700KB, ik mag hopen dat dat sneller kan dan 20 seconde.

[P-Storm]

Ik was bezig met een code in java, en zat telkens te kijken waarom het niet klopte

Java:

long lastTime = system.nanotime;//halve seconde geleden
long Now = system.nanotime();

if ((now-lastTime)/10^6 > 20) //20 miliseconde
{ 
//doe iets
}

Duurde even voordat ik er achter kwam, in vb.net kreeg ik dit probleem niet.
Dat zal me leren nog om half 3 te programmeren.

spoiler:

10^6 != 1000000, het is een xor operatie waar 12 uitkomt )

[dtech]

Alex) schreef op zaterdag 06 november 2010 @ 21:02:
Ook in .NET is een string immutable. Daarom is er ook in .NET een StringBuilder, en is String.Format() beter dan stringetjes concatenaten.

Ik weet niet hoe het in Java zit, maar in C# maakt het niet uit aangezien die intern gewoon de concatjes omzet in een stringbuilder. Wel wordt er per scope een aparte stringbuilder aangemaakt dus het kan ietsje sneller zijn.

Haan schreef op maandag 08 november 2010 @ 21:57:
[...]

Met edge-case testen zoals hierboven kun je natuurlijk aantonen dat het wel kan schelen, maar die use-cases zijn natuurlijk niet erg realistisch.

Vergeet ook niet dat 20000msec voor 100000 strings nog steeds maar 0,2 msec per string is...

Enige use-case waarbij het verschil echt merkbaar zou kunnen zijn is als je een groot aantal via een loop toevoegt, precies wat hierboven gedaan wordt. In de rest van de gevallen prefereer ik leesbaarheid boven snelheid.

Kan iemand bijv. even onderstaand code testen? (Ik zit nu niet op een PC met Visual Studio)

(oo en grotendeels gekopieerd van Haan natuurlijk )

code:

class Program 
{ 
    private const int Count = 100000; 
    private const string ShortString = "append"; 


    static void Main(string[] args) 
    { 
        // Concat
        for (int n = 0; n < 5; n++) 
        { 
            var sw = Stopwatch.StartNew(); 
            for(int i=0; i < Count; i++){
                string shortSb = concatTest(ShortString); 
            }
            sw.Stop(); 
            Console.WriteLine("Concat execution time: {0} milliseconds", sw.ElapsedMilliseconds); 
        } 

        // StringBuilder
        for (int n = 0; n < 5; n++) 
        { 
            var sw = Stopwatch.StartNew(); 
            for(int i=0; i < Count; i++){
                string shortSb = SBTest(ShortString); 
            }
            sw.Stop(); 
            Console.WriteLine("StringBuilder execution time: {0} milliseconds", sw.ElapsedMilliseconds); 
        } 

        // Format
        for (int n = 0; n < 5; n++) 
        { 
            var sw = Stopwatch.StartNew(); 
            for(int i=0; i < Count; i++){
                string shortSb = FormatTest(ShortString); 
            }
            sw.Stop(); 
            Console.WriteLine("String.Format() execution time: {0} milliseconds", sw.ElapsedMilliseconds); 
        } 
        Console.ReadKey(); 
    } 

    static string SBTest(const string appendString) 
    { 
        StringBuilder sb = new StringBuilder("bladiebla"); 
        sb.Append(appendString); 
        sb.Append(5);
        return sb.ToString(); 
    } 

    static string ConcatTest(const string appendString) 
    { 
        string result = "bladiebla"
        result += appendString;
        result += (5).toString();
        return result; 
    } 
    static string FormatTest(const string appendString) 
    { 
         return String.Format("bladiebla%s%i", appendString, 5);
    } 
}

[dtech]

Kijk hier is een heel artikel geschreven over het verschil.

Stringbuilder is inderdaad sneller dan Concat, maar het scheelt zo'n 10%

Vind zijn conclusie wel mooi:

Concatenate (+) is best at concatenating.
StringBuilder is best when you need to building.
Format is best at formatting.

En absoluut mee eens:

Most of the time on today’s modern hardware, a micro-second optimization at the sake of readability will net you nothing because it won’t be your bottleneck. Code for readability, choose the best tool for the job which will usually be the most readable and maintainable as well.

Ook nog een interessante (zij het ietwat simpel) testje hier

Zolang je dus minder dan 10 strings concat maakt het niet zoveel uit, pas als je echt duizenden strings gaat concatten zoals Haan dat deed merk je het echt; Als je dat echter doet in je code is het waarschijnlijk wel op beter manieren te optimaliseren dan door StringBuilder te gebruiken.

[Davio]

Daaraan toegevoegd moet je je als je met zoiets (het aan elkaar plakken van talloze strings) bezig bent afvragen of er geen library functie is die je beter kunt gebruiken.

Bijvoorbeeld met het inlezen van een file in C# zou je de StreamReader functie ReadToEnd kunnen gebruiken in plaats van elke keer een ReadLine tot de EOF.

[CoolGamer]

Achteraf heb je zulk soort plekken waar het zoveel performance kost zo gevonden m.b.v. een profiler.

Er is zelfs een aparte profiler warning voor opgenomen voor het concatten van strings in VS2010.

[.oisyn]

Matis schreef op maandag 08 november 2010 @ 22:43:
[...]

De string is een constant, dus eenvoudig voor de compiler en 6 karakters breed. Dus dat is maximaal 7 bytes. Doe je dat 100.000 keer concatineren, dan krijg je een stunning 700KB, ik mag hopen dat dat sneller kan dan 20 seconde.

Nope. Die char arrays (want daar gaat het uiteindelijk om) kunnen niet groeien, die moeten steeds worden bijgemaakt met een grotere lengte. Als jij een string concat, dan maakt ie een nieuwe char array. En je hebt een garbage collector, dus die arrays worden niet direct opgeruimd. Als de GC nooit zou runnen, dan heb je (in dit voorbeeld) 6 + 12 + 18 + 24 + ... + 600000 bytes aan geheugen nodig. Met string-lengte 'm' en aantal iteraties 'n' heb je in totaal m * (1 + 2 + ... + n) = 1/2m(n² + n) aan geheugen nodig. Ergo, het algoritme schaalt kwadratisch in geheugen: O(n²).

Overigens, kwa tijd schaalt het algoritme ook kwadratisch. Zoveel geheugen als je in totaal alloceert, zoveel bytes kopiëer je ook. Daarom duurt een test met 100.000 iteraties meer dan 100x langer dan een met 10.000 iteraties. En dit verklaart ook meteen het probleem. In C++ zie je dat ook duidelijk (waar een string tegelijkertijd een stringbuilder is - ze zijn mutable):

C++:

std::string test1()
{
    std::string str = "append";
    std::string r;
    for (int i = 0; i < COUNT; i++)
        r += str;
    return r;
}

std::string test2()
{
    std::string str = "append";
    std::string r;
    for (int i = 0; i < COUNT; i++)
        r = r + str;
    return r;
}

Met COUNT = 100.000 kom ik vrijwel op hetzelfde resultaat als de test in C# van Haan

[Matis]

Dat zou dus betekenen dat het concateneren van de string in het tweede en tevens trage voorbeeld van Haan

(1/2) * 6 * ((100 000^2) - 100 000) = 29 999 700 000 = ~30GB

aan data transacties in het geheugen kost. Dat komt (in het geval van die 20 secondes) ongeveer uit op 1,5GB/s. Dan is het zich niet eens zo'n hele gekke score

[RayNbow]

Gamebuster schreef op maandag 08 november 2010 @ 21:28:
[...]

Owke.

De meest handige feature, naast dat de syntax highlighter gewoon prima werkt en het vele talen ondersteund, is de ondersteuning van Javadoc-popups terwijl je code aanroept:

[afbeelding]

Maar is dat een reden om Netbeans te gebruiken? Eclipse heeft het ook:

[RomeoJ]

RayNbow schreef op dinsdag 09 november 2010 @ 08:15:
Maar is dat een reden om Netbeans te gebruiken?

Vind ik ook een aparte reden om voor Netbeans te gaan, als hij nou had gezegd dat Netbeans out-of-the-box met een zeer leuke GUI-builder komt, dan ben ik het met hem eens.

Om de discussie voor te zijn, in Eclipse heb je ook een aantal GUI-builders als plugins beschikbaar, en het is de aard van Eclipse om standaard zonder teveel poespas geleverd te worden, in tegenstelling tot Netbeans (imo).

P.S. we dwalen een beetje af in dit topic, kunnen deze reacties op concat vs. builders en Eclipse vs. Netbeans niet beter gemerged worden met "De Devschuur Coffee Corner"?

[ Voor 17% gewijzigd door RomeoJ op 09-11-2010 09:17 ]

[dev10]

Matis schreef op maandag 08 november 2010 @ 20:00:
[...]

Doel je daarmee op de snelheid van VS of het gebruikersgemak.

Je kunt jouw reactie op twee manieren uitleggen

Beide.

Ik draai Mac OS X.

Ik ook. En ik werk ook met Netbeans voor PHP. En op m'n werk werk ik met Windows Vista en Netbeans. Netbeans werkt op zich wel prima, maar ik krijg bij sommige dingen het gevoel dat het het net niet is. En zelfs met 4GB RAM is Netbeans soms niet vooruit te branden.

Voor Ruby on Rails gebruik ik trouwens gewoon TextMate en Terminal.app onder OS X.

Voor school moet ik regelmatig werken met Visual Studio, maar dat werkt sneller en vaak ook beter.

Voor degene die zich dan afvragen waarom ik niet overstap naar Visual Studio met VS.php: ik heb niet heel veel zin om 1600 + 100 euro uit te geven aan Visual Studio en VS.php voor een ontwikkelomgeving in Windows als ik alleen VS.php zou gebruiken.

[Devilly]

Voor degene die zich dan afvragen waarom ik niet overstap naar Visual Studio met VS.php: ik heb niet heel veel zin om 1600 + 100 euro uit te geven aan Visual Studio en VS.php voor een ontwikkelomgeving in Windows als ik alleen VS.php zou gebruiken.

Bedoel je http://www.jcxsoftware.com/shop.php? In dat geval citeer ik even een tekstje van die pagina:

You don't need to own Visual Studio to use VS.Php.
VS.Php includes the Visual Studio shell for free.

[CodeCaster]

Lachen. Huilen. Gooien met monitoren. Ik doe het allemaal elke dag wel eens. Dat laatste vandaag nog het meest.

SQL:

select foo, description, foo2, foo3
            from foo
                where (foo in (select foo2_1 from foo where foo = @foo) 
                    or foo in (select foo2_2 from foo where foo = @foo)     
                    or foo in (select foo2_3 from foo where foo = @foo)
                    or foo in (select foo2_4 from foo where foo = @foo)     
                    or foo in (select foo2_5 from foo where foo = @foo)
                    or foo in (select foo2_6 from foo where foo = @foo)     
                    or foo in (select foo2_7 from foo where foo = @foo)
                    or foo in (select foo2_8 from foo where foo = @foo)     
                    or foo in (select foo2_9 from foo where foo = @foo)
                    or foo in (select foo2_10 from foo where foo = @foo)) 
            order by foo

* CodeCaster gaat even op A1 de tekst "Normaliseren kun je leren" afdrukken.

[Woy]

CodeCaster schreef op dinsdag 09 november 2010 @ 13:12:
Lachen. Huilen. Gooien met monitoren. Ik doe het allemaal elke dag wel eens. Dat laatste vandaag nog het meest.

SQL:

select foo, description, foo2, foo3
            from foo
                where (foo in (select foo2_1 from foo where foo = @foo) 
                    or foo in (select foo2_2 from foo where foo = @foo)     
                    or foo in (select foo2_3 from foo where foo = @foo)
                    or foo in (select foo2_4 from foo where foo = @foo)     
                    or foo in (select foo2_5 from foo where foo = @foo)
                    or foo in (select foo2_6 from foo where foo = @foo)     
                    or foo in (select foo2_7 from foo where foo = @foo)
                    or foo in (select foo2_8 from foo where foo = @foo)     
                    or foo in (select foo2_9 from foo where foo = @foo)
                    or foo in (select foo2_10 from foo where foo = @foo)) 
            order by foo

* CodeCaster gaat even op A1 de tekst "Normaliseren kun je leren" afdrukken.

Inderdaad, dat kun je toch beter met een UNION oplossen

[Gamebuster]

dev10 schreef op dinsdag 09 november 2010 @ 10:49:
[...]
En zelfs met 4GB RAM is Netbeans soms niet vooruit te branden.

RayNbow schreef op dinsdag 09 november 2010 @ 08:15:
[...]

Maar is dat een reden om Netbeans te gebruiken? Eclipse heeft het ook:
[afbeelding]

zie: Gamebuster in "De Devschuur Coffee Corner"

[ Voor 83% gewijzigd door Gamebuster op 09-11-2010 16:52 ]

[Gorion3]

Dit compiled gewoon in C/C++

code:

Class FooA;
Class FooB : FooA;

FooB CastToFooB(FooA obj)
{
    return (FooB)obj;
}

Natuurlijk is dit op te lossen door een static_cast te gebruiken (dan geeft de compiler wel netjes een error)

[CodeCaster]

Nu ben ik verre van een C++-guru, maar ik zie daar geen fout in?

Je krijgt dan toch een instantie van een FooB met alle FooA-eigenschappen die obj heeft en de overige (in de klasse FooB gedefiniëerde members) op hun defaultwaarde?

[ Voor 58% gewijzigd door CodeCaster op 09-11-2010 18:10 ]

[Woy]

Gorion3 schreef op dinsdag 09 november 2010 @ 17:39:
Dit compiled gewoon in C/C++

code:

Class FooA;
Class FooB : FooA;

FooB CastToFooB(FooA obj)
{
    return (FooB)obj;
}

Natuurlijk is dit op te lossen door een static_cast te gebruiken (dan geeft de compiler wel netjes een error)

Ik neem aan dat dat niet in C compiled, aangezien die geen classes ondersteunt

Verder zie ik niet in waarom het in C++ niet zou moeten compilen?
Ik zag even over het hoofd dat je obj by-value doorgeeft, en niet als een pointer. Dan is het inderdaad wel vreemd dat er niet een warning o.i.d. optreed. Als is het natuurlijk sowieso handiger om geen c style casts te gebruiken voor dit soort dingen.

CodeCaster schreef op dinsdag 09 november 2010 @ 18:06:
Je krijgt dan toch een instantie van een FooB met alle FooA-eigenschappen die obj heeft en de overige (in de klasse FooB gedefiniëerde members) op hun defaultwaarde?

Maar er is natuurlijk geen enkele garantie dat de FooB instantie ook goed geïnitialiseerd is.

[ Voor 93% gewijzigd door Woy op 09-11-2010 18:13 ]

[.oisyn]

Euh nee, dat compilet niet (en dan heb ik het uiteraard niet over de syntax errors, zoals Class met een hoofdletter en vergeten accolades). Als het wel compilet dan bugt je compiler. Je construct een FooB uit een FooA, maar FooB heeft geen ctor die een FooA accepteert, en FooA heeft geen conversion operator naar FooB. De static_cast gaat je trouwens ook niet helpen, aangezien het te casten type geen ref of pointer is waardoor dat sowieso al de enige cast is die je kan bedoelen. Dus als je compiler hier geen error geeft dan zou hij dat met een static_cast ook niet moeten doen.

Mijn vermoeden is dat er eigenlijk dit bedoeld werd:

C++:

class FooA { };
class FooB : FooA { };

FooB* CastToFooB(FooA* obj)
{
    return (FooB*)obj;
}

En ja, dat compilet. De compiler ziet de C-style cast hier als een reinterpret_cast. Destemeer reden om altijd de uitgebreidere cast operators te gebruiken in C++.

[ Voor 82% gewijzigd door .oisyn op 09-11-2010 18:31 ]

[Verwijderd]

Gamebuster schreef op maandag 08 november 2010 @ 21:28:
[...]

Owke.

De meest handige feature, naast dat de syntax highlighter gewoon prima werkt en het vele talen ondersteund, is de ondersteuning van Javadoc-popups terwijl je code aanroept:

[afbeelding]

Je eigen geschreven Javadoc-comments worden zo netjes weergegeven. Werkt ook in C/C++, PHP en Javascript. Ook heeft het ingebouwde documentatie voor alle PHP- en Javascript functies en geeft het bij Javascript ook nog eens informatie over de compatibiliteit binnen de browsers, al is de informatie niet altijd up-to-date:

[afbeelding]

Late reactie maar..

Dat lijkt mij vooral géén voordeel. Op die manier zie je dus vrijwel niks meer van de rest van je code. Ik druk veel liever ff op F1 en dan zie ik al dat en meer, zonder dat het de codeview van Visual Studio vult.

[boe2]

CodeCaster schreef op dinsdag 09 november 2010 @ 18:06:
Nu ben ik verre van een C++-guru, maar ik zie daar geen fout in?

Je krijgt dan toch een instantie van een FooB met alle FooA-eigenschappen die obj heeft en de overige (in de klasse FooB gedefiniëerde members) op hun defaultwaarde?

Het lijkt me logisch dat je FooB naar FooA kan casten, maar niet omgekeerd

[Gorion3]

.oisyn schreef op dinsdag 09 november 2010 @ 18:26:
Euh nee, dat compilet niet (en dan heb ik het uiteraard niet over de syntax errors, zoals Class met een hoofdletter en vergeten accolades). Als het wel compilet dan bugt je compiler. Je construct een FooB uit een FooA, maar FooB heeft geen ctor die een FooA accepteert, en FooA heeft geen conversion operator naar FooB. De static_cast gaat je trouwens ook niet helpen, aangezien het te casten type geen ref of pointer is waardoor dat sowieso al de enige cast is die je kan bedoelen. Dus als je compiler hier geen error geeft dan zou hij dat met een static_cast ook niet moeten doen.

Mijn vermoeden is dat er eigenlijk dit bedoeld werd:

C++:

class FooA { };
class FooB : FooA { };

FooB* CastToFooB(FooA* obj)
{
    return (FooB*)obj;
}

En ja, dat compilet. De compiler ziet de C-style cast hier als een reinterpret_cast. Destemeer reden om altijd de uitgebreidere cast operators te gebruiken in C++.

Dankje oisyn om die code helemaal goed er uit te laten zien

[Alex)]

Verwijderd schreef op dinsdag 09 november 2010 @ 18:42:
[...]

Late reactie maar..

Dat lijkt mij vooral géén voordeel. Op die manier zie je dus vrijwel niks meer van de rest van je code. Ik druk veel liever ff op F1 en dan zie ik al dat en meer, zonder dat het de codeview van Visual Studio vult.

Het lijkt me dat dat alleen maar verschijnt wanneer je ergens bent waar dat nuttig is, bijvoorbeeld bij het intypen van een method call. De IntelliSense van ReSharper (die soortgelijke functionaliteiten biedt) verschijnt ook alleen wanneer dat nuttig is.

[.Gertjan.]

Boeboe schreef op dinsdag 09 november 2010 @ 18:46:
[...]


Het lijkt me logisch dat je FooB naar FooA kan casten, maar niet omgekeerd

Als die FooA ooit een FooB is geweest mag dat gewoon hoor. In .net heb je bijvoorbeeld een arraylist (tenminste ik dacht dat dat de naam van dat ding was, toen er nog geen List<T> was was dat een van de manieren om een array structuur te maken waarbij je de lengte niet vast hoefde te zetten), daar gaat alles standaard in als object (de interne objecten zijn dus van type object), maar als je het er uit haalt kun je gewoon weer terug casten. is maar goed ook anders zou het hele casting principe niet werken als je dus niet meer terug kon naar je originele type.

De compiler vindt het meestal allemaal wel goed, pas bij runtime loop je tegen problemen aan.

C#:

class FooA { }
class FooB : FooA { }

class Test {
   void Test() {
      FooA fooA1 = new FooA();
      FooB fooB1 = new FooB();
      FooA fooB1AsA = (FooA)fooB1; //Dit mag
      FooB fooB2 = (FooB)fooB1AsA; //Dit mag ook, fooB1AsA is onderwater nog steeds een FooB
      FooB fooB3 = (FooB)fooA1; //Dit mag niet, want FooA mist waarschijnlijk zaken die nodig zijn om een FooB te worden, dit zal runtime crashen

   }
}

Overigens zal de compiler bovenstaande code dus gewoon accepteren, de compiler kan over het algemeen niet zien of een cast die je doet geldig is (misschien dat een slimme compiler het binnen de functie kan zien, maar over het algemeen is het vrij lastig te bepalen of de cast uiteindelijk zal lukken en zie je het dus pas @ runtime).

[ Voor 57% gewijzigd door .Gertjan. op 10-11-2010 07:32 . Reden: Code toegevoegd ]

[CMG]

.Gertjan. schreef op woensdag 10 november 2010 @ 05:49:
[...]

Als die FooA ooit een FooB is geweest mag dat gewoon hoor. In .net heb je bijvoorbeeld een arraylist (tenminste ik dacht dat dat de naam van dat ding was, toen er nog geen List<T> was was dat een van de manieren om een array structuur te maken waarbij je de lengte niet vast hoefde te zetten), daar gaat alles standaard in als object (de interne objecten zijn dus van type object), maar als je het er uit haalt kun je gewoon weer terug casten. is maar goed ook anders zou het hele casting principe niet werken als je dus niet meer terug kon naar je originele type.

Dat is niet helemaal waar; je hebt Widening en Narrowing conversions, bij Narrowing kan je data verliezen waardoor je niet meer terug kan als je dat zou willen.

http://msdn.microsoft.com/en-us/library/k1e94s7e(VS.80).aspx

[.Gertjan.]

CMG schreef op woensdag 10 november 2010 @ 07:41:
[...]


Dat is niet helemaal waar; je hebt Widening en Narrowing conversions, bij Narrowing kan je data verliezen waardoor je niet meer terug kan als je dat zou willen.

http://msdn.microsoft.com/en-us/library/k1e94s7e(VS.80).aspx

Mmm, daar zit wat in, maar voor zover ik kan zien is dat enkel voor de "base" types in het framework zoals integers en floats. Daar is het wel logisch, daar cast je namelijk ook naar een ander type object (daarom noemt men het conversion). Long erft voor zover ik weet namelijk niet van integer (of omgekeerd).

Was het overigens niet zo dat je bij .NET een methode in je object kon opnemen waarmee je van/naar ieder type kon casten met je class?

[Alex)]

.Gertjan. schreef op woensdag 10 november 2010 @ 07:53:
[...]

Was het overigens niet zo dat je bij .NET een methode in je object kon opnemen waarmee je van/naar ieder type kon casten met je class?

IConvertible misschien?

[.oisyn]

.Gertjan. schreef op woensdag 10 november 2010 @ 05:49:
[...]

Als die FooA ooit een FooB is geweest mag dat gewoon hoor.

Jij praat nu waarschijnlijk over .Net, waarin je "FooA" en "FooB" ziet als ref types. In C++ zijn het echter value types (er staat geen * of & achter), en dus 'slice' je het FooA gedeelte uit FooB als je een FooB naar FooA cast. Je construct dus een nieuw object, met louter de FooA-eigenschappen van FooB.

C++:

struct FooA { int i; };
struct FooB : FooA { int j; };

int main()
{
    FooB b;
    FooA a = b; // copy
    FooA& a2 = b; // reference

    std::cout << "b @ " << &b << std::endl;
    std::cout << "a @ " << &a << std::endl;
    std::cout << "a2 @ " << &a2 << std::endl;
}

Zoals je ziet, 'a' staat op een heel ander geheugenadres als 'b', terwijl 'a2' op hetzelfde geheugenadres als 'b' staat. 'a' is dan ook gewoon een kopie. En je kunt nooit meer terug naar FooB vanuit 'a'.

Overigens, als je het hebt over ref types dan klopt je opmerking ook neit helemaal. Je zegt "als die FooA ooit een FooB is geweest", maar als je een FooA reference naar een FooB hebt dan is het nog steeds een FooB, het houdt dus nooit op een FooB te zijn, ookal cast je.

[ Voor 45% gewijzigd door .oisyn op 10-11-2010 11:27 ]

[.Gertjan.]

.oisyn schreef op woensdag 10 november 2010 @ 11:20:
[...]

Jij praat nu waarschijnlijk over .Net, waarin je "FooA" en "FooB" ziet als ref types. In C++ zijn het echter value types (er staat geen * of & achter), en dus 'slice' je het FooA gedeelte uit FooB als je een FooB naar FooA cast. Je construct dus een nieuw object, met louter de FooA-eigenschappen van FooB.

C++:

struct FooA { int i; };
struct FooB : FooA { int j; };

int main()
{
    FooB b;
    FooA a = b; // copy
    FooA& a2 = b; // reference

    std::cout << "b @ " << &b << std::endl;
    std::cout << "a @ " << &a << std::endl;
    std::cout << "a2 @ " << &a2 << std::endl;
}

Zoals je ziet, 'a' staat op een heel ander geheugenadres als 'b', terwijl 'a2' op hetzelfde geheugenadres als 'b' staat. 'a' is dan ook gewoon een kopie. En je kunt nooit meer terug naar FooB vanuit 'a'.

Mmmm, C++, nooit echt een held in geweest, je verhaal klinkt wel logisch. Mijn verhaal ging inderdaad over .NET (ik vermoed overigens dat Java dit ook zo zal doen als .NET). Misschien moet ik weer eens in mijn C++ boeken duiken, references en pointers blijven lastig als je ze niet/nooit gebruikt

Overigens, als je het hebt over ref types dan klopt je opmerking ook neit helemaal. Je zegt "als die FooA ooit een FooB is geweest", maar als je een FooA reference naar een FooB hebt dan is het nog steeds een FooB, het houdt dus nooit op een FooB te zijn, ookal cast je.

Klopt, onderwater is het nooit een FooA geworden, qua code zou je dat misschien wel kunnen vermoeden, maar inderdaad je hebt gelijk

[Woy]

.oisyn schreef op dinsdag 09 november 2010 @ 18:26:
Mijn vermoeden is dat er eigenlijk dit bedoeld werd:

C++:

class FooA { };
class FooB : FooA { };

FooB* CastToFooB(FooA* obj)
{
    return (FooB*)obj;
}

En ja, dat compilet. De compiler ziet de C-style cast hier als een reinterpret_cast. Destemeer reden om altijd de uitgebreidere cast operators te gebruiken in C++.

Maar daar zie ik dan het probleem niet van, mits obj ook daadwerkelijk naar een FooB verwijst. Natuurlijk is het beter om de C++ cast operators te gebruiken, maar hier gaat toch in principe niks mis?

[H!GHGuY]

Woy schreef op woensdag 10 november 2010 @ 12:44:
[...]

Maar daar zie ik dan het probleem niet van, mits obj ook daadwerkelijk naar een FooB verwijst. Natuurlijk is het beter om de C++ cast operators te gebruiken, maar hier gaat toch in principe niks mis?

Bash:

Segmentation violation.

Oops?

[.oisyn]

Woy schreef op woensdag 10 november 2010 @ 12:44:
[...]

Maar daar zie ik dan het probleem niet van, mits obj ook daadwerkelijk naar een FooB verwijst. Natuurlijk is het beter om de C++ cast operators te gebruiken, maar hier gaat toch in principe niks mis?

Euh ja, mijn code klopte ook niet helemaal. Ik bedoelde eigenlijk dit:

C++:

class FooA { }; 
class FooB { }; 

FooB* CastToFooB(FooA* obj) 
{ 
    return (FooB*)obj; 
}

Ergo, FooA en FooB zijn niet gerelateerd. Dit compilet prima, omdat hier een reinterpret_cast gebruikt wordt. Zou je een expliciete static_cast gebruiken, dan krijg je een compile error, precies zoals Gorion3 eerder beschreef

.Gertjan. schreef op woensdag 10 november 2010 @ 12:40:
[...]

Mmmm, C++, nooit echt een held in geweest, je verhaal klinkt wel logisch. Mijn verhaal ging inderdaad over .NET (ik vermoed overigens dat Java dit ook zo zal doen als .NET). Misschien moet ik weer eens in mijn C++ boeken duiken, references en pointers blijven lastig als je ze niet/nooit gebruikt

Eigenlijk gebruik je ze altijd, een variabele van een reference type in .Net is eigenlijk gewoon een pointer naar zo'n object

[ Voor 27% gewijzigd door .oisyn op 10-11-2010 12:59 ]

[Woy]

H!GHGuY schreef op woensdag 10 november 2010 @ 12:52:
[...]

Bash:

Segmentation violation.

Oops?

Hoezo zou je een Segmentation violation krijgen? Een FooA* kan perfect naar een FooB instance wijzen.

[Dido]

Mag ik er nog eentje tussendoor gooien die me zwaar frustreerde?
De taal waarin het geschreven was zullen de meesten niet herkennen, maar in (pseudo)C# kwam het neer op

C#:

public int price
 {
  get { return quantity * _price; }
  set { _price = value; }
}

Uit dezelfde pastasalade kwam de nog mysterieuzere property "language".
Die functioneerde ongeveer als volgt:

C#:

string language = "DUT";
MyClass.language = language;
language = MyClass.language;

Drie keer raden wat language nu was? 851. Jawel. Hoewel, het exacte nummer weet ik niet meer.

[Verwijderd]

En de code waarin het origineel geschreven was? Je maakt me nieuwsgierig

[Dido]

Verwijderd schreef op donderdag 11 november 2010 @ 22:41:
En de code waarin het origineel geschreven was? Je maakt me nieuwsgierig

Ik zou het even op moeten zoeken, maar dat ziet er dan ongeveer zo uit:

code:

DEFINE_PTY Price GET(GETPRICE) DET(*AUTO #CSPRC)
PTYROUTINE GETPRICE
DEFINE_MAP FOR(*OUTPUT) CLASS(#CSPRC) NAME(#PTY)
CHANGE FIELD(#STD_PRC) TO(#CSPRC * #QUANT)
SET COMPONENT(#PTY) VALUE(#STD_PRC)
ENDROUTINE

En ja, dat kan tegenwoordig ook allemaal een hoop netter.

[yade]

We zijn een interessante op het spoor. Een project dat ik heb overgeërfd van een collega die is vertrokken heb ik in een week tijd van een paar unit tests voorzien.

Een unit test die test of een DTO naar XML omzetting het gewenste resultaat oplevert slaagt op de ontwikkel-machines prima.

Echter, op de build server slaagt die test niet. Wat is het geval? Een getal wat erin gaat als 10.000 ingaat komt op de build server in de XML terug als 100.000.

Doodeng, maar straks lachen we er vast om. Als we de code morgen te pakken hebben zal ik het gefingeerd posten ter lering en vermaak.

[ Voor 4% gewijzigd door yade op 12-11-2010 01:27 ]

[.Gertjan.]

Dido schreef op donderdag 11 november 2010 @ 22:33:
Mag ik er nog eentje tussendoor gooien die me zwaar frustreerde?
De taal waarin het geschreven was zullen de meesten niet herkennen, maar in (pseudo)C# kwam het neer op

C#:

public int price
 {
  get { return quantity * _price; }
  set { _price = value; }
}

Uit dezelfde pastasalade kwam de nog mysterieuzere property "language".
Die functioneerde ongeveer als volgt:

C#:

string language = "DUT";
MyClass.language = language;
language = MyClass.language;

Drie keer raden wat language nu was? 851. Jawel. Hoewel, het exacte nummer weet ik niet meer.

Dat is dus het gevaar van properties waar (foute) logica in is gezet. Het is niet ongebruikelijk om wat logica in je property te hebben, maar dit zorgt voor onverwacht gedrag. Moet er niet aan denken als dit in een API zou zitten.

Krijgt vast mooie resultaten als je bijvoorbeeld een korting wilt berekenen Gaat goed als er slechts 1 product is, maar als er meerdere zijn..

C#:

article.price = article.price * 0.9;

Brrrrr.... Van dat soort mensen moeten ze de licentie invorderen

Het feit dat logica mogelijk is in properties is overigens wel erg fijn, maar je moet het dus wel correct gebruiken. Wat ik vaak in property code doe is bijvoorbeeld een object/lijst initialiseren als deze er nog niet is.

C#:

private List<MyClass> _items;
public List<MyClass> Items {
  get {
    if(_items == null) { _items = new List<MyClass>(); }
    return _items;
 }
}

Daar is op zich weinig mis mee lijkt me, maar bovenstaand voorbeeld... Vaak is dat soort code een slecht voorteken...

[Verwijderd]

Alex) schreef op dinsdag 09 november 2010 @ 23:02:
[...]

Het lijkt me dat dat alleen maar verschijnt wanneer je ergens bent waar dat nuttig is, bijvoorbeeld bij het intypen van een method call. De IntelliSense van ReSharper (die soortgelijke functionaliteiten biedt) verschijnt ook alleen wanneer dat nuttig is.

Dat klopt, maar als die method één is die ik daarboven gemaakt heb, wil ik toch kunnen zien wat die method aan code doet. Ook wil ik graag weten wat de code is die ik al in mijn methode heb staan (vooral als ik andermans werk aanpas) aan variabelen die ik bij die methode nodig heb. Ik gebruik dan ook geen ReSharper, wat ik alleen maar verwarrend vind werken

[roy-t]

yade schreef op vrijdag 12 november 2010 @ 01:26:
We zijn een interessante op het spoor. Een project dat ik heb overgeërfd van een collega die is vertrokken heb ik in een week tijd van een paar unit tests voorzien.

Een unit test die test of een DTO naar XML omzetting het gewenste resultaat oplevert slaagt op de ontwikkel-machines prima.

Echter, op de build server slaagt die test niet. Wat is het geval? Een getal wat erin gaat als 10.000 ingaat komt op de build server in de XML terug als 100.000.

Doodeng, maar straks lachen we er vast om. Als we de code morgen te pakken hebben zal ik het gefingeerd posten ter lering en vermaak.

Het eerste waar ik aan moet denken is dat er niet naar een invariant culture geserialiseerd wordt, misschien is dat een handige tip?

[dev10]

Kom net nog een leuke tegen:

PHP:

function getDutchDay($daynum)
{
    switch($daynum)
    {
    case '1':
        return 'Maandag';
        break;
    case '2':   
        return 'Dinsdag';
        break;
    case '3':   
        return 'Woensdag';
    case '4':
        return 'Donderdag';
    case '5':
        return 'Vrijdag';
        break;
    case '6':
        return 'Zaterdag';
        break;
    case '0':
        return 'Zondag';
        break;
    }
}

function getDutchMonth($monthnum)
{
    switch($monthnum)
    {
        case '1':
            return 'Januari';
            break;
        case '2':   
            return 'Februari';
            break;
        case '3':   
            return 'Maart';
        case '4':
            return 'April';
        case '5':
            return 'Mei';
            break;
        case '6':
            return 'Juni';
            break;
        case '7':
            return 'Juli';
            break;
        case '8':
            return 'Augustus';
            break;
        case '9':
            return 'September';
            break;
        case '10':
            return 'Oktober';
            break;
        case '11':
            return 'November';
            break;
        case '12':
            return 'December';
            break;
    }
}

[!null]

Whaha, wat een labiel figuur heeft dat geschreven. De ene keer wel een break, de andere keer niet. Niet dat die breaks nodig zijn.

[Matis]

!null schreef op vrijdag 12 november 2010 @ 11:19:
Whaha, wat een labiel figuur heeft dat geschreven. De ene keer wel een break, de andere keer niet. Niet dat die breaks nodig zijn.

Hij had natuurlijk ook :

PHP:

/* Linux */
setlocale(LC_ALL, 'nl_NL');
/* Windows */
setlocale(LC_ALL, 'nld_nld');

Kunnen doen (Of LC_TIME als alleen de datum en tijd op zijn Nederlands moet).

Daarbij komt nog dat wij in Nederland de maanden en dagen niet met een hoofdletter schrijven, iets wat ze in het Engels wel doen.

[ Voor 19% gewijzigd door Matis op 12-11-2010 11:28 ]

[Noxious]

Hmm meestal doe ik bij zoiets een $return = "Maandag";, heeft dat de voorkeur boven direct returnen zoals in dit geval? Een directe return lijkt me wel sneller in theorie...

[Cartman!]

Waarom zou je het eerst willen assignen dan? Ik return t ook direct als daar een mogelijkheid toe is.

[yade]

roy-t schreef op vrijdag 12 november 2010 @ 08:50:
[...]


Het eerste waar ik aan moet denken is dat er niet naar een invariant culture geserialiseerd wordt, misschien is dat een handige tip?

Dat klopt bijna.

C#:

var foo = Decimal.Parse("10,0");

Dat gaat dus niet goed.

C#:

decimal foo = 10.0m;

Is de oplossing.

[Noxious]

Dunno, zoals ik al aangeef; ik vind het netter staan maar weet niet of dat gebruikelijk is

[HuHu]

Cartman! schreef op vrijdag 12 november 2010 @ 11:29:
Waarom zou je het eerst willen assignen dan? Ik return t ook direct als daar een mogelijkheid toe is.

Er zijn heel veel discussies over "Single-Entry, Single-Exit" methoden. Dus als je zin hebt, dan kun je wat lezen... .

[alex3305]

!null schreef op vrijdag 12 november 2010 @ 11:19:
Whaha, wat een labiel figuur heeft dat geschreven. De ene keer wel een break, de andere keer niet. Niet dat die breaks nodig zijn.

En wat te denken dat getallen in die switch als strings worden behandeld .

[HuHu]

alex3305 schreef op vrijdag 12 november 2010 @ 11:39:
[...]

En wat te denken dat getallen in die switch als strings worden behandeld .

Die $daynum is ook al raar, want in PHP heb je twee verschillende implementaties:

N	ISO-8601 numeric representation of the day of the week (added in PHP 5.1.0)
	1 (for Monday) through 7 (for Sunday)

w	Numeric representation of the day of the week
	0 (for Sunday) through 6 (for Saturday)

Het lijkt erop dat deze functie de laatste representatie wil hebben, maar in PHP kun je nergens vanuit gaan. Zondag kan dus zowel 0 als 7 zijn .

[!null]

Even voor de duidelijkheid, ik dacht dat ik niet eens hoefde te benoemen dat die hele functie onzin was.

[dev10]

HuHu schreef op vrijdag 12 november 2010 @ 11:53:
[...]
Het lijkt erop dat deze functie de laatste representatie wil hebben, maar in PHP kun je nergens vanuit gaan. Zondag kan dus zowel 0 als 7 zijn .

Daar lijkt het inderdaad op, maar ik kan het niet terugvinden waarom hier voor gekozen is. Oorspronkelijke programmeur is weg, er is geen ontwerp, er was geen documentatie en er zijn nog wat meer vreemde dingen.

[Davio]

dev10 schreef op vrijdag 12 november 2010 @ 12:07:
[...]


Daar lijkt het inderdaad op, maar ik kan het niet terugvinden waarom hier voor gekozen is. Oorspronkelijke programmeur is weg, er is geen ontwerp, er was geen documentatie en er zijn nog wat meer vreemde dingen.

Heeft waarschijnlijk te maken met de punten die je daarna noemt.

[MBV]

helaas is dat bij de bedrijven waar ik tot nu toe heb gewerkt niet zo'n duidelijk oorzakelijk verband. Meer dat de programmeurs moeten vechten om nog iets van documentatie te mogen maken waar management vooral onmogelijke deadlines wil halen

[ReenL]

@HuHu:

Fixed?

PHP:

$daysOfWeek = array('Zo', 'Ma', 'Di', 'Wo', 'Do', 'Vr', 'Za', 'Zo');
echo $daysOfWeek[data('N')];
echo $daysOfWeek[data('w')];
echo 'Een week heeft '.count($daysOfWeek).' dagen.'; // :)

[.oisyn]

dagen en maanden schrijf je niet met een hoofdletter in het Nederlands

[Sebazzz]

Dagen en maanden als string genereren doe je niet zelf, maar laat je door je framework doen of door de API van je OS.

[Miyamoto]

Sebazzz schreef op vrijdag 12 november 2010 @ 14:57:
Dagen en maanden als string genereren doe je niet zelf, maar laat je door je framework doen of door de API van je OS.

PHP Manual: setlocale
Returns the new current locale, or FALSE if the locale functionality is not implemented on your platform

Misschien was er dus geen keus. Moet eerlijk bekennen dat ik deze functie ook niet kende en het dus ook op de manier van ReenL doe.

[.oisyn]

Met rooot. Ben het dan ook niet met Sebazzz' stelling eens. Sowieso alleen al het feit dat de localenaam verschilt tussen linux en windows doet mij al ervoor huiveren om 'm te gebruiken. Wat moet je dan doen voor robuuste code, OS detectie oid? En wat als de locale gewoonweg niet geïnstalleerd is? Of als je op geen van beide OS'en runt? En het is niet alsof men in de toekomst ineens besluit om de namen te wijzigen ofzo.

Wat voornamelijk van belang is is dat je je tijden door het OS laat berekenen (wat is de tijd/dag/datum op 4 februari 2012 om 2:24 UTC in GMT+6)

[ Voor 14% gewijzigd door .oisyn op 12-11-2010 15:28 ]

[Sebazzz]

.oisyn schreef op vrijdag 12 november 2010 @ 15:26:
Sowieso alleen al het feit dat de localenaam verschilt tussen linux en windows doet mij al ervoor huiveren om 'm te gebruiken. Wat moet je dan doen voor robuuste code, OS detectie oid? En wat als de locale gewoonweg niet geïnstalleerd is? Of als je op geen van beide OS'en runt?

Library gebruiken die dat afvangt en checkt?

En het is niet alsof men in de toekomst ineens besluit om de namen te wijzigen ofzo.

Nee, maar wat wel zo is, is dat je je niet altijd kan limiteren tot een aantal cultures.

[Verwijderd]

Dido schreef op vrijdag 12 november 2010 @ 01:13:
[...]

Ik zou het even op moeten zoeken, maar dat ziet er dan ongeveer zo uit:

code:

DEFINE_PTY Price GET(GETPRICE) DET(*AUTO #CSPRC)
PTYROUTINE GETPRICE
DEFINE_MAP FOR(*OUTPUT) CLASS(#CSPRC) NAME(#PTY)
CHANGE FIELD(#STD_PRC) TO(#CSPRC * #QUANT)
SET COMPONENT(#PTY) VALUE(#STD_PRC)
ENDROUTINE

En ja, dat kan tegenwoordig ook allemaal een hoop netter.

Na googlen schijnt het Lansa te zijn? Nog nooit van gehoord(A)
Maar als ik het goed begrijp define je een soort method GETPRICE?
Als dat goed is dan lijkt het me wel een goed leesbare taal hoor.

[.oisyn]

Sebazzz schreef op vrijdag 12 november 2010 @ 15:45:
[...]
Library gebruiken die dat afvangt en checkt?

Da's een optie idd, maar die library heeft dan óf een eigen implementatie, óf je kunt ook niet op die library bouwen (want als je OS support mist en de lib heeft geen eigen implementatie dan kan de library ook niets). Eigenlijk heb je dus sowieso een library nodig die een eigen implementatie heeft. Dan kun je die ook wel zelf implementeren, gezien de complexiteit ervan (of eigenlijk het gebrek eraan).

Nee, maar wat wel zo is, is dat je je niet altijd kan limiteren tot een aantal cultures.

Oh, dus jij wil zeggen dat jouw app/website louter uit datums bestaat zodat je verder geen vertaalbureau nodig hebt en puur gebruik kan maken van de locales van het OS?

[Lye]

Spuit 11 en ben nog niet helemaal wakker...

[ Voor 84% gewijzigd door Lye op 12-11-2010 16:45 ]

[HuHu]

.oisyn schreef op vrijdag 12 november 2010 @ 16:37:
[...]

Da's een optie idd, maar die library heeft dan óf een eigen implementatie, óf je kunt ook niet op die library bouwen (want als je OS support mist en de lib heeft geen eigen implementatie dan kan de library ook niets). Eigenlijk heb je dus sowieso een library nodig die een eigen implementatie heeft. Dan kun je die ook wel zelf implementeren, gezien de complexiteit ervan (of eigenlijk het gebrek eraan).


[...]

Oh, dus jij wil zeggen dat jouw app/website louter uit datums bestaat zodat je verder geen vertaalbureau nodig hebt en puur gebruik kan maken van de locales van het OS?

Nu ken ik niet zo heel veel details van PHP libraries, maar het Zend Framework beschikt daar over. Alle dagen en maanden (en nog veel meer) zijn vertaald in alle talen van de wereld.

[Gamebuster]

.oisyn schreef op vrijdag 12 november 2010 @ 16:37:
Oh, dus jij wil zeggen dat jouw app/website louter uit datums bestaat zodat je verder geen vertaalbureau nodig hebt en puur gebruik kan maken van de locales van het OS?

Gewoon de datum door Google Translate API gooien

[Gamebuster]

http://chat.onzin.com/popup.js.php?popups=4

Een leuk script die ik een tijd geleden had geschreven voor een chat toen ik nog niet zo handig was met Javascript en PHP
Ik schat dat het zo'n 2-3 jaar oud is.

kwam 'm toevallig net tegen. Onderdeel van mijn eerst werkende chat.

PHP:

<?php 
$a=0;
while($a<$_GET['popups']) {
?>
var allow_delete_popup<?php echo $a;?>=true;
function chatpopup<?php echo $a;?>(title,msg,posatmouse) {
    if(!title) {
        if(allow_delete_popup<?php echo $a;?>==true) {
            document.getElementById('popup<?php echo $a;?>').style.display='none';
        }
    } else {
        document.getElementById('popup<?php echo $a;?>').innerHTML='<table cellspacing="0" cellpadding="0" border="0" style="background:#000;"><tr><td onmousedown="start_move<?php echo $a;?>();" style="font-weight:bold;color:#fff;padding:0px 1px;">'+title+'</td><td style="text-align:right;padding-right:3px;"><a href="javascript:allow_delete_popup<?php echo $a;?>=true;chatpopup<?php echo $a;?>();" style="color:red;font-weight:bold;font-family:courier new;text-decoration:none;">X</a></td></tr><tr><td colspan="2" style="padding:2px;background:#ffc;">'+msg+'</td></tr></table>';
        //document.getElementById('popup<?php echo $a;?>').innerHTML=msg;
        document.getElementById('popup<?php echo $a;?>').style.display='block';
        if(posatmouse==1 || (popupposX<?php echo $a;?>==0 && popupposY<?php echo $a;?>==0)) {
            popupposX<?php echo $a;?>=MouseX+20;
            popupposY<?php echo $a;?>=MouseY+20;
        }
        document.getElementById('popup<?php echo $a;?>').style.left=popupposX<?php echo $a;?>+'px';
        document.getElementById('popup<?php echo $a;?>').style.top=popupposY<?php echo $a;?>+'px';
    }
}

var popupmoving<?php echo $a;?>=false;
var popupposX<?php echo $a;?>=0;
var popupposY<?php echo $a;?>=0;
var mousestartposX<?php echo $a;?>=0;
var mousestartposY<?php echo $a;?>=0;
function start_move<?php echo $a;?>() {
    mousestartposX<?php echo $a;?>=MouseX;
    mousestartposY<?php echo $a;?>=MouseY;
    popupstartposX<?php echo $a;?>=popupposX<?php echo $a;?>;
    popupstartposY<?php echo $a;?>=popupposY<?php echo $a;?>;
    popupmoving<?php echo $a;?>=true;
}


function move_popup<?php echo $a;?>() {
    if(popupmoving<?php echo $a;?>==false) {return;}
    popupposX<?php echo $a;?>=popupstartposX<?php echo $a;?>+MouseX-mousestartposX<?php echo $a;?>;
    popupposY<?php echo $a;?>=popupstartposY<?php echo $a;?>+MouseY-mousestartposY<?php echo $a;?>;
    if(popupposX<?php echo $a;?><0) {
        popupposX<?php echo $a;?>=0;
    }
    if(popupposY<?php echo $a;?><0) {
        popupposY<?php echo $a;?>=0;
    }
    document.getElementById('popup<?php echo $a;?>').style.zIndex=2;
    document.getElementById('popup<?php echo $a;?>').style.left=popupposX<?php echo $a;?>+'px';
    document.getElementById('popup<?php echo $a;?>').style.top=popupposY<?php echo $a;?>+'px';
}
<?php 
$a+=1;
}
?>
function stop_move() {
<?php
$a=0;
while($a<$_GET['popups']) {
?>
    document.getElementById('popup<?php echo $a;?>').style.zIndex=1;
    popupmoving<?php echo $a;?>=false;
<?php
$a+=1;
}
?>
}

function move_popups() {
<?php
$a=0;
while($a<$_GET['popups']) {
?>
    move_popup<?php echo $a;?>();
<?php
$a+=1;
}
?>
}

[ Voor 104% gewijzigd door Gamebuster op 12-11-2010 18:34 ]

[Dido]

Verwijderd schreef op vrijdag 12 november 2010 @ 16:35:
Na googlen schijnt het Lansa te zijn? Nog nooit van gehoord(A)
Maar als ik het goed begrijp define je een soort method GETPRICE?
Als dat goed is dan lijkt het me wel een goed leesbare taal hoor.

Het is inderdaad Lansa. Van oorsprong een 4gl rpg-generator, doet nu onder windows ook C++.
De gedefinieerde routine is een getter of setter voor de property, maar lijkt in alles op een gedefinieerde method (behalve dan dat er maar 1 input en 1 output parameter mogen zijn in een getter, en alleen 1 input in een setter).

Het kan ook leesbaarder, hoor, tegenwoordig. Een voorbeeldje van een property-routine die wel iets zinnigs doet (in mijn ogen dan)

code:

Define_com class(#prim_kcol<#gncctrlc #om10>) name(#pSubCtl) style(collection) 
Define_pty SubCtl get(getSubCtl)
Ptyroutine getSubCtl
 Define_map for(*input) class(#om10) name(#key)
 Define_map for(*output) class(#gncctrlc) name(#pty)
 If (#pSubCtl<#key> *is *null)
  set_ref com(#pSubCtl<#key>) to(*create_from #key)
  #pSubCtl<#key>.construct()
 Endif
 #pty <= #pSubCtl<#key>
Endroutine

De leesbaarheid staat of valt een beetje met de laatste programmeur die eraan gezeten heeft. Sommigen progarmmeren nog alsof ze op de iSeries op 17 regels zitten te krassen, terwijl het ondertussen steeds meer op een VB of C# begint te lijken als je wilt. Alleen wat meer verbose (maar dat kan ik als cobol-klopper ook wel weer waarderen )

(OK, deze hele post is off-topic. Sorry daarvoor )