As avea citeva sugestii pentru articolele pe care le vei scrie in viitor.

1. Incearca sa scrii cod care se compileaza. Iti lua maxim 5 minute sa testezi ce-ai scris acolo intr-un proiect nou indiferent ce mediu de dezvoltare foloseai.

2. Comentariile ar fi bine sa corespunda cu codul. De exemplu cind scrii "acesta e constructorul privat" vezi sa si fie.

3. Inainte de a folosi template-uri incearca sa intelegi ce sint ele si la ce-s bune. Ce faci tu acolo cu derivatul dintr-un template (care nici nu-i definit corect) n-are nici un sens.

4. Nu te mai imprieteni cu clasele din care derivezi. Esti sigur ca stii ce face "friend"?

5. Inainte de a alege sa povestesti lumii despre o tema, vezi daca nu cumva mai exista miliarde de alte explicatii pe net pentru aceeasi problema. Cu alte cuvinte, vezi daca ceea ce faci tu are valoare.

6. Tot la capitolul premeditare, intreaba-te daca ce povestesti tu e util. Poti sa explici cu ce e mai avantajos sa faci un singleton in loc sa faci o mina de functii (eventual intr-un namespace, daca vrei sa fii la moda)? Evident, excludem pentru moment avantajul major ca poti sa te dai mare ca ai folosit cuvintul "pattern".

PS: "Sper sa ignorati eventualele greseli de ortografie, sunt programator nu professor de romana" - limba romana e optionala doar cind n-o vorbesti. De unde-i ideea asta ca doar profesorii de romana trebuie sa stie unde se pun liniutele?

Mda, "articolul" asta este o adevarata insulta la adresa limbajului C++ . Pacat.

Aici e un articol de pe codeproject care explica mult mai corect si mai clar ceea ce incearca sa redea cu ajutorul unor vagi amintiri si slabe cunostinte autorul abominatiei de mai sus:

http://www.codeproject.com/cpp/singleton_template.asp

Sper sa fie de folos.

da inainte sa ma criticati a obsevat cineva ca ce e intre semnul mai mare si semnul mai mic se sterge pe forum? asa ca idee... credeam ca am rezolvat asta cand am facut sa fie cod sursa...

si codu e testat, am dat copy-paste da mia sters o parte din cod forumu (

asa ca chestie friend e folosit si in tutorialu de pe codeproject exact la fel... si da stiu ce face friend

in legatura cu "privat" , true sorry greseala mea

PS: faza cu profesoru de romana era o gluma.................

Mai devreme era o clasa LS_CSingleton pe-acolo. Vad ca ai corectat intre timp, da' chiar daca pusesei angle brackets si ti le-a mincat forumul (nu stiam de bug) tot nu se compila din cauza respectivului identificator.

Chiar daca se compila, ramin punctele 5 si 6, care-s cele mai importante. Link-ul dat de MariusG - de unde metoda pare imprumutata verbatim - sugereaza ca valoarea inca unui tutorial despre singletoni tinde la zero.

Despre punctul 6 ramin la parerea ca singletonii in general sint o timpenie pompoasa si o complicatie inutila a unui lucru banal, iar implementarea lor cu template-uri din care derivezi si cu care te imprietenesti e o abominatie.

da aia cu LS_ am vazut acum sorry, in legatura cu puncctele 5 si 6 ... stiu ca sunt o gramada de tutoriale despre singleton, da na trebuia sa fie unu sin romana nam stiut ce alt articol sa fac pt site...

mai nu cred k sunt o tampenie in unele cazuri sunt folositori, mie mi se par folositori, categoric sunt oameni calora li se par inutili acum daca il vei folosi sau nu e alegerea ta

da e un bug cu parantezele... cel putin la mine ieri mam chinuit putin siam crezut ca lam rezolvat (

Problema cu singletonii e ca incearca sa faca o clasa din ceva care nu-i o clasa. Faci o clasa cind ai nevoie sa reprezinti diverse instante ale obiectului aluia. Engine-ul grafic nu-i o clasa, sistemul de logging nu-i o clasa. Facutul claselor din orice e o boala grea care s-a dezvoltat din iubirea pentru OOP.

Este mult mai simplu si mai eficient sa reprezinti subsistemul ala unic - in cazul tau logger-ul - printr-un set de functii. Uiti de clase, bagi functiile in header si toti membrii care ar fi fost privati ii pui frumos in .cpp cu static in fata. Dezavantaje nu vad. Avantajele survin din forma codului rezultat (compara Logger::GetInstance()->Log() cu LogMessage()) si mai ales din faptul ca pe clientul subsistemului nu-l intereseaza matele respectivului subsistem.

C++ are problema aia ca se trage din C. La nivel de unitate de compilare, clientii unei clase vad toate matele ei. Schimbi ceva private, se recompileaza toti clientii care includ header-ul ala. Asta poate deveni nasol intr-un proiect mare si ai doua solutii:

1. te adincesti si mai tare in dogma OOP-ului si faci interfete virtuale
2. te tragi un pas inapoi si vezi ca oamenii faceau d-astea cu mult inainte de OOP si mergea mai bine si era mai simplu

Punctul 1 e o aberatie conceptuala si o alegere foarte proasta atunci cind trebuie sa pictezi toata lumea in 16.7 milisecunde.

Poate o sa zici ca logger-ul are unu-doi membri privati si nu se schimba niciodata. Din pacate, odata ce lumea descopera cuvintele astea magice - pattern, singleton, gang of four - aplica noul si stralucitorul concept peste tot. Renderul are mai mult de 2 membri si isi schimba matele toata ziua. O sa te trezesti intr-unul din urmatoarele scenarii:

1. schimbari minore cauzeaza recompilarea unor mari portiuni din proiect. Cum boala asta are si alte simptome, probabil ai o groaza de STL, template-uri si alte bunatati prin cod, deci compilarile dureaza mii de ani. Daca pui pe hirtie citi bani dai pe timpul cit programatorii se uita la text care defileaza in output window, innebunesti.

2. render-ul tau capata brusc o interfata virtuala. Dupa aia te intrebi de ce se misca PS3-ul ca un PC din 1995.

3. cineva vine cu solutia sa se puna #ifdef IMPLEMENTATION in jurul partii private din singleton-ul clasei Render. Totul e frumos cu exceptia faptului ca nu mai vezi nimic in debugger.

OOP e ciocanul ala care te face sa crezi ca orice e un cui. Don't buy the hype.

PS: o clasa care deriveaza dintr-un template care are clasa respectiva ca parametru e orice numai elegant nu cum zice ala acolo. Sa te faci friend cu clasa din care derivezi e o timpenie si contrazice orice s-a gindit vreodata despre OOP. Implementarea aia e groaznica indiferent daca ti se pare ca OOP e un panaceu sau nu.

PS2: sa repare cineva bug-ul cu ghilimelele si apostroafele escapate.

mai parerea mea e k loggeru e ok sa fie o clasa acu depinde si ce intelegi prin logger (ma refer la ce face) daca scrie si atat intradevar o functie e ok, daca face mai multe chestii mi se pare mai adecvat o clasa

in legatura cu singleton mie mi se pare folositor.
si categoric OOP nu este folositor tot timpul si sa folosesti anumite metode penru orice este o prostie

cu debuggerul da este adevarat nu mai vezi nimic (ma rog vezi mai greu)

in legatura cu friend... daca sti o metoda mai bune please share it with us

Care-i legatura intre numarul de functii ale unui modul si transformarea sa intr-o clasa sau nu? De ce ti se pare mai adecvat sa faci logger-ul ala o clasa    daca face mai multe chestii?

Cu debugger-ul vezi tot daca nu folosesti hack-ul ala cu #ifdef in jurul membrilor privati (daca folosesti nu vezi mai greu, pur si simplu nu vezi deloc).

De ce ti se par utili singletonii?

La cum am facut eu loggerul la engineu la care lucrez mi se pare mai util clasa decat functii

singletoni mi se par utili pentru faptul ca te obliga sa faci o singura instanta a unei clase si in unele cazuri mi se par utili

Si daca nu poti sa ai decit o instanta cu ce-i mai util sa folosesti o clasa decit niste functii (dezavantajele le-am povestit mai sus)? Te-am intrebat cu ce e mai destept cind e clasa si mi-ai zis ca ti se pare mai util pentru ca ti se pare mai util...

mai este mai util cu clasa poti ascunde niste date ce nu vrei sa le vada utilizatoru etc + ca urmeaza o ordine logica, setezi niste date o singura data (un trebie sa scri de fisierul in care vreu sa scri datele la fiecare apelare)

si oricum gandestete si din prisma cealalta ... daca nu era filositor nu-l inventa nimeni

Dimpotriva, cind faci variabile statice in logger.cpp nu ti le vede clientul subsistemului. Cind le pui intr-o clasa si le botezi "private" nu poti sa le accesezi din alte clase, dar de vazut le vede toata lumea. Nu-i vorba ca-i secret cum iti numesti tu variabilele, e vorba ca atunci cind le schimbi trebuie sa recompilezi tot ce foloseste clasa aia, desi interfata nu s-a modificat.

N-am inteles ce vrei sa spui cu scrisul variabilelor o singura data, fii mai explicit.



Sper foarte tare ca nu crezi ca se inventeaza numai lucruri bune si folositoare.

OK Dark, eu iti inteleg punctul de vedere .. dar pana la urma nu trebuie sa ducem totul la extrem. In cazul in care preferi sa lucrezi doar folosind OOP, trebuie sa recunosti ca Singleton e util (iar in C#, java si multe alte limbaje, nici n-ai cum sa lucrezi fara clase). Daca esti obisnuit cu programare fara clase, atunci ma intreb de ce cunosti atat de bine C++ - exista C, are doar functii si structuri, e rapid, e minunat (ironizez un pic - prefer de departe C++ si clasele, decat o gramada de functii grupate mai mult prin nume, ca in C, no destructors, no exceptions, no nothing).

Pentru logger, si eu fac un singleton (prefer sa am totul grupat frumos intr-o clasa, sa am un destructor care se apeleaza automat si dezaloca resursele etc.). In schimb am niste macro-uri, care arata ceva in genul acesta:

#define Log CSingleton::GetInstance()->Log

Sunt constient ca apare o mica penalizare la viteza, fata de apelul unei simple functii, dar nu imi trebuie logging ultra-rapid.

Metoda descrisa mai sus, cu derivarea dintr-un template, si clasa friend, mi se pare si mie cam aiuristica - prefer sa-mi definesc singleton-urile "manual".

Din fericire aici nu-i vorba de Java, C# si alte astfel de cuceriri ale tehnicii socialiste (off-topic, uite un rezumat foarte bun al penetrarii lui C# in game dev aici, la programmer's challenge de anu' asta de la GDC ).

In cazul in care vrei sa lucrezi doar OOP ai problema aia de care am zis mai sus, cum ca ai descoperit un ciocan si brusc totul in jur arata a cui. Un limbaj si o tehnica de programare ar trebui sa te ajute, nu sa devina o religie.

Nu sint obisnuit cu programarea fara clase. Sint obisnuit sa folosesc clase acolo unde se potrivesc. Asa cum vad eu lucrurile, conceptul de singleton se contrazice cam tare cu conceptul de clasa tocmai pentru ca nu poti sa ai mai multe obiecte d-alea de-odata.

Ce nu pricep eu: atita timp cit codul e mai simplu cu functii si-ti da mai putine dureri de cap in management-ul proiectului, de ce trebuie sa te complici cu o clasa? Ce-i asa de magic la clasa asta? Vi se pare ca-i vreun fel plasa de salvare, ca-i Lucrul Corect™, sau cum? De unde vine mirajul asta, ca-s tare curios sa inteleg? Da' de, trebuie sa manince si oameni de tipul asta o piine...

la mine e simplu, de obicei am doar un singleton (Engine), utilizez clasa pentru ca e mai sexy si in plus vreau sa am doar clase in engine simple as that.