Impedance, a measure of opposition to time-varying electric current in an electric circuit.
Not to be confused with impotence.
Verwijderd
[ Voor 5% gewijzigd door Verwijderd op 26-07-2009 03:44 ]
Mis ik iets?
Heb je nou wel of geen long long nodig? Dit vraagt echt om hele vervelende bugs over 3 jaar...
Soms wel en soms niet. Niet al mijn database velden zijn bigint (MySQL), sommige wel. Ik gebruik echter wel voor alle integer velden dezelfde functie.:
Mis ik iets?
Daar heb je typedefs voor. Vergeet trouwens niet dat je ook gewoon een ctor cast kunt gebruiken, dus int(foo()) ipv (int)foo(). Heb je hetzelfde effect als een aparte functie, maar dan zonder aparte functie
Misschien handig om erbij te zeggen welke compiler je gebruikt? ISO C++ zegt overigens niets over dergelijke warnings, een long long opslaan in een int zonder cast is gewoon well-formed.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
(en dat ie op z'n plaats is kan ik het alleen maar mee eens zijn - van mij had het ook wel een error mogen zijn, zoals in Java en C# het geval is)
[ Voor 42% gewijzigd door .oisyn op 26-07-2009 22:55 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
-niks-
En de TS vroeg zich af of hij dat niet voor specifieke situaties uit kan zetten. Wie doet hier moeilijk?:
waarom doen we allemaal zo ingewikkeld, het is een warning, niet een error
Overigens compileren wij zelf met warnings als errors, dus dan moet je er wel wat aan doen.Kan ook als je met een andere compiler aan de slag wil. #pragma is daar per definitie voor geschikt, omdat compilers dat gewoon mogen negeren.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Warnings zijn vies. Ze worden bovendien niet voor niets gegeven, en verdienen aandacht. ( Met de mogelijkheid om na er over nagedacht te hebben een cast te doen of een warning tijdelijk te disablen ):
waarom doen we allemaal zo ingewikkeld, het is een warning, niet een error
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| template<class T> class olaf_cast_t { olaf_cast_t(T t) : value(t) { } template<class U> operator U() const { return static_cast<U>(value); } T value; }; template<class T> olaf_cast_t<T> olaf_cast(T t) { return olaf_cast_t<T>(t); } long long foo(); float bar(); int main() { char c = olaf_cast(foo()); short s = olaf_cast(bar()); } |
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Sweet, maar wel een beetje eng:
C++:
Weg type duplication
Volgens mij heb ik hier wel eens weken naar gezocht; is dit niet een oplossing voor assignment van template return types in bijvoorbeeld expression templates? Ik roep maar wat, geen idee meer, maar het komt me zo bekend voor dit.
[ Voor 16% gewijzigd door Zoijar op 28-07-2009 15:16 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Het kon niet lang duren voordat zoiets gepost zou worden natuurlijk.:
Weg type duplication
[ Voor 3% gewijzigd door Olaf van der Spek op 28-07-2009 19:20 ]
, maar het is toch een expliciete cast zonder dat je hoeft te weten wat voor type je naartoe cast. Je kunt dus gewoon types wijzigen in je applicatie zonder dat je overal de casts moet gaan aanpassen. En tegelijkertijd blijft het duidelijk dat je wel aan het casten bent. En wat performance betreft zal het denk ik resulteren in identieke instructies. En met iets meer template magic zou je het eventueel nog kunnen limiteren aan bepaalde types, zodat je niet per ongeluk een base* naar een derived* cast.
[ Voor 20% gewijzigd door .oisyn op 28-07-2009 20:54 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
1
2
3
4
5
| long long getDBresult(); typedef int type1; type1 result = (type1)getDBresult(); long long longresult = getDBresult(); |
[ Voor 0% gewijzigd door Punkie op 29-07-2009 11:12 . Reden: typo ]
Wel duplicatie. Je moet type1 typen, ookal weet je dat de variabele waar je aan assignt ook van datzelfde type is.
Zoals ik eerder al zei, C++ verbiedt je helemaal niet om (zonder warning) een long double aan impliciet naar een char te converten. Het warninglevel van deze specifieke VC++ warning is level 4 (vrij hoog dus). Compilers als GCC En Comeau geven by default niet eens een warning. Dus, over welke type checking had je het ook alweer?
Nooit. 5.2.3/1.
[ Voor 55% gewijzigd door .oisyn op 29-07-2009 11:31 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Nee, het verschil met de template oplossing is dat de template oplossing nooit wijzigt, ookal verander je het type van de variabele. De typedef suggestie is geen volledige oplossing, omdat je niet per variabele een typedef gaat maken (dat is ononderhoudbaar), en dus ga je typen categoriseren. Als je later besluit dat een variabele naar een andere categorie moet (waardoor het type alias dus verandert, ook al blijft het daadwerkelijke type hetzelfde), dan zul je alsnog de casts moeten aanpassen.
You're arguing semantics. Ook al heb je gelijk, de topicstarter wil gewoon niet nog een keer dat type willen typen. Dan kun je wel zeggen dat dat geen type duplication heet, maar eigenlijk doet dat er niet zo heel veel toe
[ Voor 23% gewijzigd door .oisyn op 29-07-2009 11:43 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik geloof dat dat al was vastgesteld ja
[ Voor 27% gewijzigd door .oisyn op 29-07-2009 11:55 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Met deze dus dank aan mezelf voor het samenvatten voor Olaf.:
Ik geloof dat dat al was vastgesteld ja
Niet in C++03, maar wel in C99, en ook in C++0x die zo goed als final is (hoewel, je ziet wat er met concepts gebeurd is...). Maar praktisch iedere moderne C++ compiler ondersteunt long long, zoals je zelf ook al zegt een stukje verderop. Veel compilers hebben bovendien al meer C++0x extensies dan alleen de long long.
Nee. Nou bestaat C++99 niet
, maar de C++ standaard (die leunt op C90) heeft nooit iets gezegd over de grootte van een int, behalve dat hij minstens 16 bits is, groter-gelijk dan een short en kleiner-gelijk dan een long. C99 zegt geloof ik wel dat het typisch een machine word is. Overigens is Windows x64 een LLP64 platform, dus de int en zelfs de long blijven dan 32 bits. Onder linux, wat dacht ik LP64 is, is de int 32 bits maar de long wel 64 bits. Een 64 bits int zul je dus sowieso niet heel snel tegen komen (64 bit arithmetic instructies op AMD64 hebben ook een prefix nodig, ze zijn dus langer dan de 32 bits varianten - 64 bits ints vergroten dus alleen maar je binary footprint terwijl je die 32 extra bits vaak niet eens nodig hebt. En bovendien bestaat er dan geen 32 bits type meer)Nee, een long is een verkorte notatie van (signed) long int. Long en int zijn echter twee verschillende typen.
[ Voor 19% gewijzigd door .oisyn op 30-07-2009 00:37 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Is het tegenwoordig niet >= 32 bits (in C of in C++)? Dacht dat het ergens geupdate was.:
Nee. Nou bestaat C++99 niet
Linux x64 bedoel je neem ik aan? Linux draait op meer 64-bits platforms.
Ik dacht eigenlijk dat in 64-bits mode de default 64-bits arithmetic was.
[ Voor 10% gewijzigd door Olaf van der Spek op 30-07-2009 11:48 ]
Wikipedia: C++
Dat dacht ik dus ook, maar het is niet zo.
Short pointers zouden inderdaad best handig zijn als een app toch niet meer dan 4 gb nodig heeft.
Het gaat ook niet zozeer om memory usage maar meer om memory bandbreedte enzo. Caches zijn niet zo groot en als je pointers 2x zo klein zijn scheelt dat gewoon.Ik maak me meer zorgen over de geheugen latencies voor elke instructie dan de totale geheugen consumptie aangezien geheugen goedkoop is. Performance wordt bepaald door het aantal instructies dat je per seconde afwerkt niet de hoeveeldheid bytes die daarmee gemoeid zijn. PIO is zo 80s, SIMD en DMA is here
Inderdaad. Het type in de DB is natuurlijk ook gewoon int. Als ik een int en een long long access functie gebruikte, had ik ook geen probleem gehad. Maar ja, het nadeel daarvan is hetzelfde als de cast.
[ Voor 10% gewijzigd door Olaf van der Spek op 30-07-2009 11:46 ]
Niemand beweert hier zich zorgen te maken over de lengte van je opcodes. Ik had het over een (mogelijke) beweegreden van een compiler implementatie om een int op 32 bits te houden.
Geheugen wel, cache niet. Meer geheugen betekent een minder efficiente cache en dus hogere latencies.
Wel dus
. Instruction cache.C99 volgens mij, maar C++ leunt niet op C99, vandaar.
Ja idd, ik had het puur over x86
Nope.
Geen idee. Hetzelfde geldt voor short trouwens, wat eigenlijk short int is.
Waarschijnlijk omdat (voor het 64 bits tijdperk) een short altijd typisch 16 bits was en een long 32 bits, en een int afhing van van de CPU (16 of 32 bits)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik heb gewoon geindexed in een vector, omdat die gegarandeerd contiguous is. Van wat ik weet is een offset lookup net zo snel als een absolute. (uiteraard is het in CUDA weer een verhaal apart
)
[ Voor 5% gewijzigd door Zoijar op 31-07-2009 01:56 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ja maar dan zijn ze ook pas nodig bij de semantische analyse
. Dit kan bijv. niet in gcc:1
2
3
4
| struct S { typedef void * ptr; }; S s; typeof(s)::ptr myptr; // error typedef typeof(s)::ptr ptr; // error |
1
2
| typedef decltype(s) S2; S2::ptr ptr; |
1
2
3
4
5
6
7
| template<class T> struct S { void foo() { T::ptr i2; } }; |
. Aan de andere kant zou dat wel logisch zijn als ze decltype volledig willen supporten.
[ Voor 34% gewijzigd door .oisyn op 17-09-2009 17:56 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/6356/eliza.gif?f=community)
/u/145301/mo.png?f=community)
:strip_icc():strip_exif()/u/148505/31bb5b263ef71bb4d5751e9a89035105.jpeg.jpg?f=community)
:strip_exif()/u/29138/caffeine.gif?f=community)
/u/31525/boblight2-icon.png?f=community){kind=icon}
:strip_exif()/u/11775/SoulTaker.gif?f=community)
:strip_icc():strip_exif()/u/35767/images.jpg?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
/u/3813/100_8985_ICON2.JPG?f=community)
:strip_exif()/u/119637/logo.gif?f=community){kind=logo}
/u/12668/hydra.png?f=community)
:strip_exif()/u/72391/Pinky_and_the_Brain_-_Brain.gif?f=community)
:strip_icc():strip_exif()/u/126096/crop580e4f8566fec_cropped.jpeg?f=community)