Miljane, sto se managed c++ tice, dovoljno je da on postoji ;)
Ne moram da pravim nikakve dll-ove niti mi je to sad jednostavno posto nit
radim u windows-u niti imam instaliran visual studio ali quick search
mi daje sledece:
Citat:
One question that comes up from time to time in the C++ newsgroups is that functions or constants that exist in a C++/CLI class library are not accessible in a C# or VB.NET project.
The reason for this is nearly always that that constants or functions are defined outside of a class scope.
Consider the following - perfectly valid - C++/CLI:
namespace Bla
{
const int CONST = 42;
int func(void)
{
return CONST;
}
};
You can use CONST and func in other C++/CLI code.
What you can’t do is to use those symbols in other .NET languages. The reason is that those languages do not have a concept of things existing outside of a class or struct scope.
In other words, even though the CLR supports it, languages other than C++/CLI do not support free standing functions, variables and constants.
Tako da tvoja tvrdnja ne stoji.
Sto se tice gc-a ne mogu da vidim nikakvu vezu sa free f-jama i gc-om.
Bilo kako da je sam gc uradjen f-ja bilo free bilo ne free je kod i nista drugo.
E sad ako cli generise kod koji notifikuje gc kad god neka f-ja izlazi
opet ne vidim razliku izmedju member i free f-je.
Konceptualno izmedju static member, member i free f-je nema apsolutno
nikakve razlike osim sto se member poziva na drugi nacin i sto ima podrazumevan
prvi parametar.
Inace sama member f-ja se ni po cemu ne mora razlikovati od non member f-je.
Ne znam, sto hoces da kazes sa ovim primerima ali tu nikako ne moze
biti neke razlike u tom smislu.
Citat:
Ja to nisam rekao, sta vise ja se skoro necu preorijentisati sa imperativnog programiranja (I like my state ) i uopste ga ne smatram zastarelim
Kako nisi rekao, sta sam ja onda citirao ;)
Nema veze bre sad je terminologija uskladjena, kad si rekao imperativno verovatno si mislio na proceduralno
. Sto se tice OO i f-onalno, naravno da se sad prave
hibridi. No OO deo price ide u paketu sa imperativnim programiranjem ;) pa tako
u tom o'haskelu nalazis monadic objects, a monade su u haskelu nacin da zavrapujes
imperativni u f-onalni kod ;) E sad sa cistim f-onalnim kodom ne mozes daleko dogurati
posto tu ne mozes imati IO ;) O tome ti pricam i mislim da se tu kapiramo.
Na kraju moram da dam demonstraciju zasto mi je muka od member f-ja
i tog forsiranja da sev ide u klasu.
Prvo citat:
Citat:
In the presence of multiple dispatch, the traditional idea of methods as being defined in classes and contained in objects becomes less appealing--each collide-with method there is attached to two different classes, not one. Hence, the special syntax for method invocation generally disappears, so that method invocation looks exactly like ordinary function invocation, and methods are grouped not in classes but in generic functions.
E sad da napravim kranje glup ali ilustrativan primer manjkavosti c++-a i jave.
Code:
// 1. programer pravi interfejs i implementira u klasama D1 i D2
class Base{
public:
virtual int val()const=0;
virtual ~Base(){}
};
class D1:public Base{
public:
int val()const{ return 5; }
};
class D2:public Base{
public:
int val()const{ return 6; }
};
// drugi programer dobija zadatak da napravi cudnu
// f-ju sabiranja dve izvedene klase i integera ali pod uslovom
// da ne sme da dira postojeci kod
// idealan slucaj je da jednostavno definise operacije kako idu
int operator+(D1& l,D1& r)
{
return l.val() + r.val();
}
int operator+(D2& l,D2& r)
{
return l.val() - r.val();
}
int operator+(D1& l,D2& r)
{
return l.val() * r.val();
}
int operator+(D2& l,D1& r)
{
return l.val() / r.val();
}
int operator+(Base& l ,int r)
{
return l.val() + r;
}
int operator+(int l, Base& r)
{
return l - r.val();
}
// medjutim, nazalost sa obzirom da jezici
// kao sto su java i c++ privileguju samo jedan parametar
// i vezuju free f-je za klase, samo gore napisano nije dovoljno.
// u slucaju jave nas programer mora praviti nepotrebnu klasu sa statickim
// metodima u sebi,a u slucaju c++ dovoljno je da
// odradi isto to ali ne mora da pravi nepotrebnu klasu.
// da su OO principi zasnovani na free f-jama umesto metodima ovo
// ispod bi bilo nepotrebno,
// (cast OO jezicima koji su tako uradjeni)
// i zbog toga se vracamo na proceduralno programiranje
int operator+(Base& l, Base& r)
{
int rc = l.val()+r.val();
// ne kastujem u referencu da bih izbegao exception-e
if(D1* ld1 = dynamic_cast<D1*>(&l))
if(D1* rd1 = dynamic_cast<D1*>(&r))
return *ld1 + *rd1;
else if(D2* rd2 = dynamic_cast<D2*>(&r))
return *ld1 + *rd2;
else return rc;
else if(D2* ld2 = dynamic_cast<D2*>(&l))
if(D1* rd1 = dynamic_cast<D1*>(&r))
return *ld2 + *rd1;
else if(D2* rd2 = dynamic_cast<D2*>(&r))
return *ld2 + *rd2;
else return rc;
else return rc;
}
int main()
{
D1 a;
D2 b;
Base &ba = a, &bb = b;
int c = ba+bb, d = a+ba; // itd
}
// e kad me nije mrzelo ovo da kucam ;)
Dakle da bi nas programer 2 to odradio elegantno on mora da menja
kompletnu hijerarhiju klasa, tj da dodaje member f-je ili ako vise volite
metode ili message itd i da radi double dispatch.
Code:
// 1. programer pravi interfejs i implementira u klasama D1 i D2
// 2. programer mora da menja interfejs kompletne hijerarhije
// da bi dodao f-onalnost
class D1;
class D2;
class Base{
public:
virtual int val()const=0;
int operator+(int i){ return val()+i; }
virtual int operator+(Base&)=0;
virtual int dispatch(D1&)=0;
virtual int dispatch(D2&)=0;
virtual ~Base(){}
};
// e ovo ne moze u javi ;) prvi parametar ne pripada klasi
// pa mora free f-ja
int operator+(int l, Base& r)
{
return l - r.val();
}
class D1:public Base{
public:
int val()const{ return 5; }
int operator+(Base& b){ return b.dispatch(*this); }
int operator+(D1& d){ return d.val()+val(); }
int operator+(D2& d);
int dispatch(D1& d){ return val()+d.val(); }
int dispatch(D2& d);
};
class D2:public Base{
public:
int val()const{ return 6; }
int operator+(Base& b){ return b.dispatch(*this); }
int operator+(D1& d){ return d.val()/val(); }
int operator+(D2& d){ return d.val()-val(); }
int dispatch(D1& d){ return val()/d.val(); }
int dispatch(D2& d){ return val() - d.val(); }
};
int D1::operator+(D2& d){ return d.val()*val(); }
int D1::dispatch(D2& d){ return val()*d.val(); }
int main()
{
D1 a;
D2 b;
Base &ba = a, &bb = b;
int c = ba+bb, d = a+ba; // itd
int e = a+b;
}
E sad to je dispatch na dva parametra, zamislite sad da treba na tri ;)
E onda ne preostaje nista drugo negao kao u c-u sto se pravi
OO tako da se iz OO pravi OO tj da se formiraju tabele
pointera i da se trazi presek kombinacije ;)
Pozdrav!
Re: Nedostaci objektno orjenitisane metodologije, i ima li ih uopšte?
). Mene najvise samo brine sto ce buduci bagovi biti monstruozni, jedino sto nas je do sada spasavalo od sampiona u multithreadingu je to sto multithreading nije bio jednostavan pa sampioni cesto nisu mogli ni da pokrenu thread, sa PP podrskom i mogucnoscu da raspale milion threadova jednim izrazom, sampioni ce dobiti novu dimenziju postojanja. 
