Waarom zou je dat willen? Waarom sla je niet gewoon de bestandslocatie op in een variabele? Lijkt me logischer dan alle plaatjes het programma insleuren.
Weaseling out of things is important to learn. It's what separates us from the animals... except the weasel. Homer Simpson
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Handig dat OiSyN altijd in de buurt is om minder slimme vragen te beantwoorden als je zelf een tijdje weg bent
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| class MyBinary
{
public:
MyBinary();
MyBinary(const unsigned char* p_Data, unsigned long p_Size);
MyBinary(const MyBinary &p_Binary);
void Assign(const unsigned char* p_Data, unsigned long p_Size);
void LoadFromFile(const MyString &p_FileName);
void SaveToFile(const MyString &p_FileName);
inline const unsigned char* Data() const { return m_Data; }
inline unsigned long Size() const { return m_Size; }
private:
unsigned char* m_Data;
unsigned long m_Size;
}; |
check m'n ondertitelOp zondag 24 maart 2002 23:08 schreef curry684 het volgende:
[..]
Handig dat OiSyN altijd in de buurt is om minder slimme vragen te beantwoorden als je zelf een tijdje weg bent
("Minder slimme vragen beantwoorder" paste niet 
)Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Mèèèèèèèp (zoemer
).oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
Verwijderd
Hier hebben we het al eerder over gehad, ik ga er maar niet verder op in..
)Misbruiken ? Is verder prima, maar dan merk ik wel even op dat een zelf-in-een-half-uurtje-gebakken binary-container-classje stukken minder flexibel, robuust, en gedocumenteerd is.
Okee, zal ik het ff goed 'articuleren' dan?Op maandag 25 maart 2002 14:58 schreef curry684 het volgende:
[..]
IPicture is alleen maar een interface en kan dus per definitie niets bevatten. Je moet dan een class hebben die IPicture correct implementeert (dwz. niet met E_NOTIMPL overal
* curry684 moet op dit soort dingen altijd even mierenneuken.
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
Ja, en wat dan nog? Je hoeft je container-class niet wereldwijd uit te brengen, hoor.Op maandag 25 maart 2002 15:10 schreef curry684 het volgende:
[..]
Bij jou misschien, bij mij niet
En de robuustheid van je class hangt af van je eigen skillz, waarin jij schijnbaar niet echt veel vertrouwen hebt.
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
je hebt gelijk dat dit in de MSDN staat... Maar OleLoadPicture pikt wel degelijk jpg's. Daarna kan je allerlei bewerkingen uitvoeren en het plaatje opslaan op disk (b.v.) als jpg,bmp enz. enz.Op maandag 25 maart 2002 14:50 schreef Xenophage het volgende:
[..]
Mèèèèèèèp (zoemer
Fout. IPicture kan ten eerste zelf helemaal nix laden. Daarvoor moet je OleLoadPicture gebruiken, en die pikt alleen BMP, ICO en WMF. Het is wel zo dat een IPicture een JPG kan bevatten (het is gewoon de representatie van een geheugenbitmap), maar dan moet je wel eerst een functie hebben die een JPG kan lezen. Dus.
Zie ook:
MSDN: OleLoadPicture
MSDN: IPicture
Verwijderd
Ik vind het gewoon onzin (en erg naïef) als Curry zegt dat 'ie in een half uur een betere blobbert dan std::string kan produceren.
.
Damn. Je hebt gelijk. Sorry, mijn fout. Maar met fout bedoelde ik dat wat jij zei fout was. Wat toch niet zo was, maar goed.Op maandag 25 maart 2002 15:15 schreef The End het volgende:
[..]
je hebt gelijk dat dit in de MSDN staat... Maar OleLoadPicture pikt wel degelijk jpg's. Daarna kan je allerlei bewerkingen uitvoeren en het plaatje opslaan op disk (b.v.) als jpg,bmp enz. enz.
O ja, niet fout dus... De vraag was welke variable hij ervoor kon gebruiken, niet met welke functie hij het kan laden in de variable.......
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
Verwijderd
Een slecht excuus om slecht te proggenOp maandag 25 maart 2002 15:14 schreef Xenophage het volgende:
Ja, en wat dan nog? Je hoeft je container-class niet wereldwijd uit te brengen, hoor.
.
Nou, Curry kennende...Op maandag 25 maart 2002 15:27 schreef Sneechy het volgende:
[..]
Ik vind het gewoon onzin (en erg naïef) als Curry zegt dat 'ie in een half uur een betere blobbert dan std::string kan produceren.
Hetzelfde geldt uiteraard voor jouw als je denkt dat Curry's classje dan echt robuuster wordt
Maarreh... zo moeilijk is het niet om een blobber te schrijven, dat heb je egwel in een half uur gefixt. En waarschijnlijk doet ie het ook. Zolang je er maar geen stress test op los laat
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
In dit geval biedt std::string precies wat de topicstarter nodig heeft.
Hier komt die flexibiliteit weer om de hoek. Als je std::string gebruikt is de kans stukken kleiner dat je zelf nog extra baksels moet gaan maken om weer net ff wat anders te bereiken. Mocht je ondanks std::string's flexibiliteit en interoperabiliteit met de rest van de standard library toch nog andere functionaliteit nodig hebben: deriven en wat extra's toevoegen.
.
Ik neem Stroustrup serieus wat de taal betreft, niet wat betreft de standard libs die imho code rommelig en onleesbaar maken. Uniformiteit en interoperabiliteit zijn voor mij 2 hele sluitende redenen om eigen implementaties te maken van standaard spul.Op maandag 25 maart 2002 18:03 schreef Sneechy het volgende:
Ik krijg echt het gevoel dat mensen hier meer Stroustrop moeten lezen
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Fascinerend
. Ik vind het erg interessant om te weten hoe het komt dat twee verder hele brave codertjes zo'n afkeer hebben gekregen tegen deze library.. Ik zelf kan me hier namelijk zo moeilijk in inleven, omdat ik de C++ standard library eigenlijk altijd erg mooi en elegant heb gevonden 
.1
2
3
4
5
6
7
8
9
10
11
12
| protected:
E *eback() const;
E *gptr() const;
E *egptr() const;
void gbump(int n);
void setg(E *gbeg, E *gnext, E *gend);
E *pbase() const;
E *pptr() const;
E *epptr() const;
void pbump(int n);
void setp(E *pbeg, E *pend);
virtual void imbue(const locale &loc); |
Heel intuitief allemaal (NOT)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
we hadden het er zojuist nog over dat je std::string kon subclassen als je extra functionaliteit wilde
hmmz, ik stop een 2d array van pixels liever niet in een std::vector <std::vector<int> >, al is het alleen maar om performanceoverwegingen.
)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik had al eerder aangegeven dat de benamingen van de STL ook niet helemaal mijn smaak zijn, maar ze zijn overkombaar.
) dat sommige compilers de STL expres vrij obscuur en onduidelijk maken omdat er toch in zekere zin een soort intellectual property op ligt. Aangezien je template-classes als source moet aanleveren is het moeilijk dit te bewaren. Op deze manier zou je het 'rippen' van de code kunnen beperken.Wie zegt dat rest van de standaard niet wordt gebruikt?
You've just proven my point
WAAAAAROM zijn ze dan niet private?!?!?
Nou, ik zei letterlijk: "Wat is het nadeel van non-standaard als je de rest van de zogenaamde standaard ook niet gebruikt?"
Gezien het feit dat vector voor zover ik weet een template is waar je iedere pointer in kunt frotten zie ik je probleem niet.
Ik ging onbewust ook uit van een string, omdat de members die je noemde vaak daarmee gebruikt worden. Als ik een vector<int> zie begrijp ik wel dat de value_type een int is.Op dinsdag 26 maart 2002 02:52 schreef curry684 het volgende:
You've just proven my point
Ch gaat namelijk helemaal niet over een char, da's alleen toevallig als je een string hebt... het is een template remember
Nou het verwijst niet direct naar een element. Het verwijst naar de locatie van een element. In C++ noemen we dat een pointer. Ik denk dat bij andere namen mensen eerder geneigd zijn bijv adressen van objecten mee te geven ipv iterators.
Wel interesant. Ik ben ff wat gaan zoeken, op usenet is iemand met precies dezelfde vraag:
Tuurlijk is het wel over te zetten. De vraag is of je bijvoorbeeld gemakkelijk een std::copy(curryIterator, curryEindIterator, stlInserter) kan doen.
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Verwijderd
Ik hoop dat je alleen het zelf implementeren bedoelt, want als je er zelf één verzint is het geen STL meer
.
Tsja. 't Is of typedefs of zoiets als (uit echte code)
1
2
| std::map< std::basic_string<std::iterator_traits<std::deque<char>::iterator>::value_type >,
std::basic_string<std::iterator_traits<std::deque<char>::iterator>::value_type > > |
STL heeft altijd size() in alle containers.
Dan heb je dan ook geen STL codeEn als we het dan toch over de functienamen hebben, het lijkt wel een sport om die zo cryptisch mogelijk te kiezen. Een stukje uit streambuf:
code:
jaaja... eback, gptr, egptr, imbue
STL zijn de CIA, Containers, Iterators & Algorithms.Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
dat bedoel ik helemaal niet, hoewel een sting bijvoorbeeld ook de functie length () heeft (die weer precies hetzelfde doet als size ()). Ik doelde meer op het feit dat ik het verwarrend vindt. Meestal hangt de naam van de functie af van watgene dat ie doet, zoals doeIets (). In dit geval wordt het dus vraagGrootteOp (), getSize () dus. En size is dan de variabele waarin de lengte staat (die er overigens niet toe doet)
ho, ik zeg niet dat ze er niet moeten zijn, aangezien je dan of (1) hele lange definities krijgt zoals je al aangaf, of (2) minder vrijheid hebt, om het zo maar even uit te drukken. Ze hadden het echter wel minder verwarrend kunnen maken (eerst en typedef, en daarna weer een nieuw type typedeffen dat precies hetzelfde is als die vorige, en daarvan weer een exact gelijke type creeeren)
fijn dat je de rest van me verhaal weghaalt
Maar ik denk dat jullie mij een beetje verkeerd begrijpen. Het doel van de STL vind ik zeker goed, het had van mij alleen wat intuitiever en duidelijker gemogen, en als ik in dezelfde tijd een alternatief kan gebruiken dan doe ik dat meestal (zie de printf vs. cout discussies
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
hmm interessant, dan werkt het dus nog beter dan ik dacht (dat, of jouw verbetering zoog gewoon[b]Op dinsdag 26 maart 2002 21:06 schreef curry684 een verhaal over heapmanagement]
Ergo de standaard NT-heapmanager is moeilijk te verslaan...
j/k)kheb helemaal geen zin meer in een discussie (alles is zo'n beetje al gezegd), dus * .oisyn weert verder ook deze thread* curry684 heeft nog weinig zin in het ontopic gedeelte van de discussie trouwens
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
:strip_exif()/u/11987/avatar%2520small.gif?f=community){kind=avatar}
/u/27299/hoofd.png?f=community)
:strip_icc():strip_exif()/u/31199/goticon.jpg?f=community)
:strip_exif()/u/7759/red_cat.gif?f=community)
/u/23727/symbol.png?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
/u/19474/avatar2015.png?f=community){kind=avatar}
:strip_exif()/u/3398/rh.gif?f=community)