játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5441
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2519

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2186
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] > 7 < [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [141]
Seeting - Törzstag | 2306 hsz       Online status #202021   2014.03.16 15:29 GMT+1 óra  
Kód:
char **words;
    int count = strSplit(data, words, ".");
    for (int i = 0; i < count; i++) {
        printf("%s\n", words[i]);
    }


Az strSplit() allokálja a words-t, mivel csak ő tudja, hogy mennyi helyre van szükség. Amit kapok:

error C4700: unitialized local variable 'words' used

Amit csinálok, gcc-ben 100% legális. A VC++ compiler meg panaszkodik. Miért?

Edit: Nevermind, elrontottam. A megoldás:

Módosítani ezt:
Kód:
int strSplit(const char* source, char ** out, char* delimeters)


Erre:

Kód:
int strSplit(const char* source, char **& out, char* delimeters)


Ugyanis másképpen nem módosulna a címérték.

Ezt a hozzászólást Seeting módosította (2014.03.16 15:39 GMT+1 óra, ---)
   
glezmen - Törzstag | 381 hsz       Online status #201920   2014.03.10 11:05 GMT+1 óra  
Idézet
M4 :
Én wxWidgets-et használtam. Szerintem egyszerű.
https://www.wxwidgets.org/



En is wxwidgets-szel kezdtem a GUIs fejlesztest, de mar az elejen sem igazan tetszett, aztan amikor egy verziovaltasnal lenyegeben lehetett kidobni az elozo kodot, akkor mondtam azt hogy eleg volt...
   
M4 - Tag | 187 hsz       Online status #201919   2014.03.10 10:44 GMT+1 óra  
Én wxWidgets-et használtam. Szerintem egyszerű.
https://www.wxwidgets.org/

   
glezmen - Törzstag | 381 hsz       Online status #201917   2014.03.10 10:38 GMT+1 óra  
Idézet
Eldor :
Qt: easy to use, hard to learn.



azert annyira nem hard, csak meg kell erteni a logikajat
   
Eldor - Tag | 162 hsz       Online status #201914   2014.03.09 23:13 GMT+1 óra  
Qt: easy to use, hard to learn.

   
Elodin - Tag | 172 hsz       Online status #201913   2014.03.09 23:09 GMT+1 óra  
Tudtok ajánlani valami easy to use lib-et, amivel lehet könnyen csili-vili GUI-t lehet elővarázsolni a semmiből Linux-ra, Windows-ra és Mac-re egyaránt?

   
Pretender - Törzstag | 2498 hsz       Online status #201867   2014.03.07 20:59 GMT+1 óra  
Én úgy tudom, hogy ilyen esetekben nem fog inlineosítani. Legalábbis a vc++ biztosan nem. De a többitől is logikátlanság lenne egy ilyen függvényt inlineosítani.
Tudom, ezzel nem segítettem túl sokat, nekem minden esetre vc++ alatt még nem volt ilyesmivel gondom.
Egyébként c++ban van többszörös öröklődés. Miért nem csinálsz egy olyan base classt, ami az eddigi(ek)nek is, meg a különleges típusnak is az őse? És akkor nem kell template quadtree.

   
Dookle - Tag | 478 hsz       Online status #201859   2014.03.07 19:29 GMT+1 óra  
Hi ! Írtam egy szép quadtree class-t.Nagyonszépen működik... Az egyetlen szépséghiba hogy bejött a képbe még egy "különleges tipus" ami nem ugyanabból az osztályból ered mint a többi elem a játékban. Ezért kénytelen leszek megcsinálni a quadtree-t templates-re , egy két template specializáció és a kód szép áttekinhető lesz.. A kérdés az hogy szerintetek mennyire megbízhatóak a rekurzív inline metódusok ?? Persze a compiler nem minden esetben fog inlineolni , de arra még sem lehet építeni hogy talán jó lesz talán nem... Ráadásul a kód crossplatform szóval minden c++ fordítón fordulnia kell...
STEVIE RAY VAUGHAN FOREVER !!!!!

http://pinkcatgames.ucoz.com/
   
Pretender - Törzstag | 2498 hsz       Online status #201498   2014.02.21 23:52 GMT+1 óra  
Az is ezt csinálja, csak figyelembe veszi a negatív értékeket is. Azt hiszem. Minden esetre teljesen jól működik, meg minden, csak hát akkor is... na!

@glezmen:
Ja, nem voltam elég pontos. De érted, hogy hogy értem...
Static_cast meg azért, hogy a fordító ne dobjon warningot. Merthogy warning treated as error. C-s castot meg ugyebár nem használunk c++ban

   
glezmen - Törzstag | 381 hsz       Online status #201497   2014.02.21 23:52 GMT+1 óra  
Idézet
Pretender :
Igen, én is rájöttem, hogy levágja. De pont ez-az. Ugye van néhány szám, amit nem tud ábrázolni, és valami olyasmi lesz az eredmény, amit versio írt. Így aztán egy intre vágás után 149 lesz belőle. Nyilván az egyszerű megoldás annyi, hogy cast előtt + 0.5f (nyilván pozitívakra, de én jelen esetben azzal dolgozok)



ez nem pontossag, hanem a kettes szamrendszerbeli szamabrazolas eredmenye.
Rakj bele olyan floatot amit kettes szamrendszerben pontosan lehet abrazolni, es meglesz az

amugy meg minek a static_cast?
   
ddbwo - Tag | 1625 hsz       Online status #201496   2014.02.21 23:51 GMT+1 óra  
Kód:
floor();
round();
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Pretender - Törzstag | 2498 hsz       Online status #201495   2014.02.21 22:50 GMT+1 óra  
Igen, én is rájöttem, hogy levágja. De pont ez-az. Ugye van néhány szám, amit nem tud ábrázolni, és valami olyasmi lesz az eredmény, amit versio írt. Így aztán egy intre vágás után 149 lesz belőle. Nyilván az egyszerű megoldás annyi, hogy cast előtt + 0.5f (nyilván pozitívakra, de én jelen esetben azzal dolgozok)

   
LugaidVandroiy - Törzstag | 504 hsz       Online status #201494   2014.02.21 22:46 GMT+1 óra  
Mivel semmi fele kerekites nem tortenik, levagja a tort reszt. Nincs itt baj a float pontossagaval.

   
versio - Tag | 659 hsz       Online status #201493   2014.02.21 22:39 GMT+1 óra  
szerintem levagja, mert a float azert ennyire nem rossz
149.9999999999999 lehet az eredmeny
   
Pretender - Törzstag | 2498 hsz       Online status #201492   2014.02.21 22:28 GMT+1 óra  
Hehe, imádom azért a float-pontosságot...
Kód:
uint32 base = 100;
uint32 percent = 150;
uint32 result = static_cast<uint32>(base * percent * 0.01f);

Eredmény: result = 149

   
Geri - Törzstag | 2186 hsz       Online status #201235   2014.02.15 22:13 GMT+1 óra  
key[(unsigned char)'Ű']=0;

   
M4 - Tag | 187 hsz       Online status #200944   2014.02.10 08:35 GMT+1 óra  
Javában csak fordításkor ellenőrzi, hogy a generikus típusokkal helyes-e a kód (ha nem helyes, nem fordul). Aztán törlődnek a típus paraméterek (type erasure). Futáskor pl. nem List<Srting> van, hanem csak List. Tehát a generikus osztályból csak egy (paraméternélküli) változat kell futáskor.

   
Pretender - Törzstag | 2498 hsz       Online status #200898   2014.02.08 15:44 GMT+1 óra  
Persze, teljesen máshogy működik a kettő. c++ban nem runtime, hanem compile time tudni kell a típusokat, és a templatet igazából csak "kifejti" az adott típusra (vagy valami ilyesmi )
Java esetén meg valóban runtime dől el a típus, és az adott függvényből egy létezik csak. Persze ez így nem pontos egyik sem, de valami ilyesmi. És így belegondolva, teljesen érthető, hogy a lenti kódrészlet miért működik úgy, ahogy.

   
__z - Tag | 69 hsz       Online status #200897   2014.02.08 14:58 GMT+1 óra  
Én még régebben olvastam valahol néhány cikket, hogy a hasonló szintaktika ellenére elvi különbségek vannak a c++ "template" és a c#/java "generics" között...

   
Pretender - Törzstag | 2498 hsz       Online status #200896   2014.02.08 14:19 GMT+1 óra  
Ja, annyi lehet a hátterében, hogy fordításidőben tényleg tudnia kell, hogy milyen függvényt fog meghívni. Javaban ez fejlettebb, ott ugye nem egy fordításidőben elkészített függvényt fog meghívni, mint a c++ template fgvek esetén. Így viszont teljesen jogos, hogy mindnenképpen a "legkisebb közös többszörös" elvét követi.

   
zeller - Törzstag | 464 hsz       Online status #200894   2014.02.08 11:37 GMT+1 óra  
esetleges extra alternativak winre:
http://stackoverflow.com/questions/413477/is-there-a-good-valgrind-substitute-for-windows

amugy ami a template-es kerdest illeti, sztem a reason behind the stuff is that template types are non polymorphic. Javaban van KOlbasz<? extends Gyulai> meg Roberto<? super Giorgo> de c++-ban nem lattam meg ilyet.

   
Pretender - Törzstag | 2498 hsz       Online status #200888   2014.02.08 08:50 GMT+1 óra  
Valgrind az linux-only szerintem, ez meg windowsos cucc. A valgrind egyébként jó lenne, a cégnél használtuk, vannak hozzá jópofa pluginek is.
Most ezt az AMD CodeAnalystet használom, ez sem olyan rossz, csak érteni kellene assembly nyelven is.

   
zeller - Törzstag | 464 hsz       Online status #200887   2014.02.08 08:07 GMT+1 óra  
A feladatkezelo altal szolgaltatott informacio teljesen invalid. valgrinddel nem tudod megnezni?

ha auto deklaracioval adsz tipust a ternaris operator kimenetenek, az mi lessz? ezt kerdeztem. de ha korabbi deklaracio, akkor ertelmetlen kerdes.

   
Pretender - Törzstag | 2498 hsz       Online status #200880   2014.02.07 16:44 GMT+1 óra  
@zeller: mi?

Tud valaki egy easy to use profilert? Főleg memóriára lennék most kíváncsi. A windowsos feladatkezelő azt mondja, hogy 80 megát eszik a cucc, de ezt nem tudom elhinni. Főleg, hogy 9-ről 20-ra ugrik néhány kb-nyi adat betöltése után. Meg szeretném mérni, hogy ténylegesen mennyi, mikor változik, stb.

   
zeller - Törzstag | 464 hsz       Online status #200873   2014.02.07 07:19 GMT+1 óra  
suscks. autoval mi lesz? compile error?

   
Pretender - Törzstag | 2498 hsz       Online status #200872   2014.02.07 00:46 GMT+1 óra  
Teljesen jogos egyébként, de nem gond, ifekkel kivédhető, csak így mennyivel szebb lett volna már...

   
Wolfee - Törzstag | 1336 hsz       Online status #200871   2014.02.06 23:29 GMT+1 óra  
Idézet
__z :
Pretender :
Asszem ez a ternáris operátor ("a.empty() ? b : a" ) miatt van, ahol a-nak és b-nek azonos típusúnak kell lennie, mivel a kifejezés egy bizonyos típusú értéket ad vissza, és pl.: függvényben sincs olyan, aminek egy feltételtől függően más típusú a visszatérési értéke (vagy ilyesmi)...


szo tru, kozos tipusra fogja kasztolni a felteteles kifejezes parametereit.
FZoli jóváhagyásával XD

   
__z - Tag | 69 hsz       Online status #200870   2014.02.06 23:10 GMT+1 óra  
Pretender :
Asszem ez a ternáris operátor ("a.empty() ? b : a" ) miatt van, ahol a-nak és b-nek azonos típusúnak kell lennie, mivel a kifejezés egy bizonyos típusú értéket ad vissza, és pl.: függvényben sincs olyan, aminek egy feltételtől függően más típusú a visszatérési értéke (vagy ilyesmi)...

Ezt a hozzászólást __z módosította (2014.02.06 23:19 GMT+1 óra, ---)

   
Pretender - Törzstag | 2498 hsz       Online status #200866   2014.02.06 21:03 GMT+1 óra  
Találtam egy furcsaságot, még nem teljesen értem, hogy miért is van így.
Kód:
struct A
{
};
struct B : public A
{
};
class C
{
public:
    template <typename T>
    void foo(const Array<T>& bigyo)
    {
    }
};

void alma()
{
    Array<A> a;
    Array<B> b;

    foo(a.empty() ? b : a);
}

Valahogy minden esetben a T típus A lesz, hiába üres a, és végül b-t adok át neki.

   
Eldor - Tag | 162 hsz       Online status #200706   2014.02.02 09:07 GMT+1 óra  
Lehet, itt nem az a probléma, de azért leírom hátha segít. Nem próbáltam ki.

A windows által használt fájlrendszerekben a kis- és nagybetűk között nincs különbség. Régebben jártam úgy, hogy létrehoztam egy Math.h headert, amit includeoltam ( #include "Math.h" ) és mégis a C könyvtárba beépített math.h headert találta meg. Lehet, hogy itt is ez a probléma.

Ha kizárható, akkor bocsi. Mélyebben nem jártam utána a dolognak, csak gondoltam leírtam, hátha segít.

Ezt a hozzászólást Eldor módosította (2014.02.02 10:36 GMT+1 óra, ---)

   
Elodin - Tag | 172 hsz       Online status #200705   2014.02.02 08:37 GMT+1 óra  
Egyszerűen nem bírom működésbe hozni.
Cseréltem az inculde-ok sorrendjét, hogy a Math.h legyen előbb, most már Undefined reference-eket dob a kódban.

Lehet a végén dobom a Code::Blocks/MinGW párost, és átváltok mégis Visual Studio-ra. A glew-el is sokkal többet szívtam, mint szerettem volna, mire működésre bírtam. Nem létezik, hogy minden egyes lib, amibe belefutok, ennyi szívást jelentsen.

   
__z - Tag | 69 hsz       Online status #200700   2014.02.02 01:27 GMT+1 óra  
Esetleg változtatni az include-ok sorrendjén?
Illetve előfordulhat, hogy mindkettőben define-olnak egy ugyanolyat, nekem a Boost meg az Allegro akadt össze ilyen módon (ha jól emlékszem).

   
Pretender - Törzstag | 2498 hsz       Online status #200689   2014.02.01 18:57 GMT+1 óra  
Próbálj meg egy preprocesszált filet megnézni. Akkor ugye feloldja a defineokat, stb. Simán lehet, hogy nem talál egy headert, csak nem arra panaszkodik, hanem érvénytelen behelyettesítés történik, ezáltal szintaktikai hibás lesz a header.

   
Elodin - Tag | 172 hsz       Online status #200688   2014.02.01 18:48 GMT+1 óra  
Bénáztam vele még egy kört, még mindig nem jó. El nem tudom képzelni, hogy miért a Math.h száll el.

   
ddbwo - Tag | 1625 hsz       Online status #200687   2014.02.01 18:20 GMT+1 óra  
az unix/mingw verziót letöltöttem megnézni, ami tökéletesen működik Code:Blocks MingW változat alatt, így nem tudom...
math.h val/nélkül, előtt, után, bármit csinálok, működik. windows alatt opengl mellett.

így is...
Kód:
#include <windows.h>
#include <stdio.h>
#include <gl/gl.h>
#include <gl/glu.h>
#include <math.h>
#include "Magick++.h"
#include <math.h>
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Elodin - Tag | 172 hsz       Online status #200674   2014.02.01 14:16 GMT+1 óra  
ImageMagicket próbáltam működésre bírni. Beállítottam az includeokat meg a libeket, és az eredmény ugyanez. Math.h dob errort. Kerestem neten, de nem találtam semmi okosságot. Bármi elképzelés, hogy mi állhat a probléma hátterében?

   
ivanicsm93 - Tag | 26 hsz       Online status #200591   2014.01.28 13:15 GMT+1 óra  
Igen, Xcode5

Megoldódott a probléma.
Amikor létrehoztam a main függvényben egy új példányt a Settings osztályból, NULL-t adtam kezdő értéknek. Utána átírtam erre: Settings *program = new Settings(); viszont így is hibát írt ki, mert hiányzott az alábbi kódrészlet:

Settings:: Settings(){

}

Settings::~Settings(){

}

Ezt a hozzászólást ivanicsm93 módosította (2014.02.02 19:59 GMT+1 óra, ---)

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #200590   2014.01.28 12:05 GMT+1 óra  
Idézet
syam :
XCode-nak tűnik.

Kösz Akkor azért nem láttam még
Dare to imagine!
http://www.insaneidea.hu
   
syam - Törzstag | 1491 hsz       Online status #200589   2014.01.28 11:45 GMT+1 óra  
XCode-nak tűnik.
alias aalberik
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #200588   2014.01.28 11:34 GMT+1 óra  
Idézet
ivanicsm93 :
Hello!

Segítséget szeretnék kérni. Elkezdtem tanulni az SDL2-t C++ -al.
Programoztam egy ablakot amiben egy .bmp képnek kellene megjelennie, de amikor futtatom felvillan egy fekete ablak és ezt a hibát(?) jelzi, ami a mellékelt képen látható.

Szerintetek mi lehet a gond?

Kép: http://kepfeltoltes.hu/view/140128/K_perny_fot__2014-01-28_-_1.57.06_www.kepfeltoltes.hu_.png

Ez milyen IDE btw?
Dare to imagine!
http://www.insaneidea.hu
   
glezmen - Törzstag | 381 hsz       Online status #200587   2014.01.28 08:45 GMT+1 óra  
Idézet
ivanicsm93 :
Hello!

Segítséget szeretnék kérni. Elkezdtem tanulni az SDL2-t C++ -al.
Programoztam egy ablakot amiben egy .bmp képnek kellene megjelennie, de amikor futtatom felvillan egy fekete ablak és ezt a hibát(?) jelzi, ami a mellékelt képen látható.

Szerintetek mi lehet a gond?

Kép: http://kepfeltoltes.hu/view/140128/K_perny_fot__2014-01-28_-_1.57.06_www.kepfeltoltes.hu_.png



ott van a kep aljan: a Screen pointered amire meghivod, NULL
de legkozelebb ha lehet ne screenshotokat rakj be a forraskodrol, mert ugy eleg nehez segiteni...
   
ivanicsm93 - Tag | 26 hsz       Online status #200584   2014.01.28 01:03 GMT+1 óra  
Hello!

Segítséget szeretnék kérni. Elkezdtem tanulni az SDL2-t C++ -al.
Programoztam egy ablakot amiben egy .bmp képnek kellene megjelennie, de amikor futtatom felvillan egy fekete ablak és ezt a hibát(?) jelzi, ami a mellékelt képen látható.

Szerintetek mi lehet a gond?

Kép: http://kepfeltoltes.hu/view/140128/K_perny_fot__2014-01-28_-_1.57.06_www.kepfeltoltes.hu_.png

   
__z - Tag | 69 hsz       Online status #200480   2014.01.22 07:50 GMT+1 óra  
Elodin :
Mostanában nem c++-oztam, de mintha a boost-ban lett volna ilyesmi...
(Asszem ez volt az.)

   
Geri - Törzstag | 2186 hsz       Online status #200474   2014.01.21 18:14 GMT+1 óra  
stdio

   
Elodin - Tag | 172 hsz       Online status #200470   2014.01.21 11:15 GMT+1 óra  
Ismer valaki vmi. jó lib-et fájlok/mappák kezelésére?

   
bolyzsolt - Törzstag | 607 hsz       Online status #199656   2013.12.01 10:26 GMT+1 óra  
Idézet
JagdTiger :
Hali, nem tudtam erre nem felfigyelni, de ez tudtommal
Kód:
x(String y);

nem move sematics, ez egy mezei érték szerinti paraméter átadás,
nem véletlenül erre gondoltál?
Kód:
x(String&& y);



Az első verzió valóban sima érték szerinti átadás, de pont arra van szükség, mivel a move semantics eggyel korábbi "fázisban" játszik csak. Azaz a függvény mindenképpen egy másolatot kap, de mivel a String osztálynak van move constructora, így ha netalántán rvalue-t kapna a függvény, akkor a fordító először létrehoz egy temporary String objektumot a move constructorral, majd ezt adja át a függvénynek. Amíg nem létezett move semantics, addig a fordító ilyen esetben mindig a copy constructort hívta meg, a C++11 óta azonban választhat a move és a copy közül.

Amit másodikként írtál, az pedig valóban egy rvalue-ra specializált függvény, de arra csak a String osztály move constructoránál és move assignment operátoránál van szükség.

Nem tudom, mennyire sikerült érthetően megfogalmaznom...

   
JagdTiger - Tag | 6 hsz       Online status #199652   2013.12.01 02:25 GMT+1 óra  
Hali, nem tudtam erre nem felfigyelni, de ez tudtommal
Kód:
x(String y);

nem move sematics, ez egy mezei érték szerinti paraméter átadás,
nem véletlenül erre gondoltál?
Kód:
x(String&& y);

   
bolyzsolt - Törzstag | 607 hsz       Online status #199521   2013.11.24 16:26 GMT+1 óra  
Idézet
glezmen :
Idézet
bolyzsolt :
valami oknál fogva nem lehet egy nagy méretű objektumot referenciaként átadni.



mi az az ok?


Mittomén, például ha egy másolatra van szükség. De nem ez volt a lényeg...
Úgy néz ki, visszacserélem a paramétereket const ref-ekre, mert ennek így tényleg nincs értelme. Ha úgyis csak olvasásra kell a paraméter, akkor a const ref teljesen jó, rvalue argumentumok esetén is. Előbb kellett volna gondolkozzak

   
glezmen - Törzstag | 381 hsz       Online status #199509   2013.11.23 22:36 GMT+1 óra  
Idézet
bolyzsolt :
valami oknál fogva nem lehet egy nagy méretű objektumot referenciaként átadni.



mi az az ok?
   
bolyzsolt - Törzstag | 607 hsz       Online status #199483   2013.11.23 19:04 GMT+1 óra  
Tegyük fel, hogy van egy (lehetőleg nagy) objektumunk, és nagyon sok olyan függvényünk, amiknek ezt az objektumot át kell adni paraméterként csak olvasásra. Továbbá nagyon fontos, hogy az esetek túlnyomó többségében rvalue-ként kapja meg az objektumot a függvény. (Konkrétan most egy string implementációról van szó.)

Amikor olvastam a move semantics-ról, akkor ész nélkül átírtam minden
Kód:
x(const String &y);
formájú függvényt
Kód:
x(String y);
formájúra, mondván hogy megírtam a String-hez a move konstruktort és a move assignment operatort, majd a fordító szépen észreveszi az rvalue-kat és akkor tök gyors lesz.

De igazából most esett le, hogy ez így nem jó, mert a POD típusú osztályváltozók így most másolódnak, magyarul az ilyen osztályváltozók darabszámától függően lineárisan lassítottam a kódon. Ellenben const referenciaként átadva nem kell másolgatni semmit sem. Tehát a move semantics nem csodafegyver, ha paraméterekről van szó, sőt igazából csak ott van értelme ilyen esetben, ahol valami oknál fogva nem lehet egy nagy méretű objektumot referenciaként átadni.

Ezt jól látom, vagy valami kimaradt a gondolatmenetből?

Ezt a hozzászólást bolyzsolt módosította (2013.11.23 19:10 GMT+1 óra, ---)

   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] > 7 < [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [141]