Prawie 3MB do zarezerwoania. Jakiego modelu użyć? Nie bardzo mi się chce bawić segmentami i dzielić to. Jest jakiś sposób? (jak na razie doprowadzam do wywalenia IDE Borlanda :) )
0
0
nie wiem czy dobrze Cie rozumiem ale polecam HUGE , z LARGE mialem juz takie przeboje kiedys a dzis sprzet mamy szybszy wiec te kilka milisekund Cie nie zbawi przy allokacji :)
0
Chcesz w borlandzie pod dosem zarezerwowac 3MB - albo ja czegos o tym srodowisku nie wiem albo to niemozliwe :-)
0
Chcesz w borlandzie pod dosem zarezerwowac 3MB - albo ja czegos o tym srodowisku nie wiem albo to niemozliwe :-)
Ano rzeczywiście [wstyd] Max. 1 MB. Że też o tym nie pomyślałem. To głupie ograniczenie DOSa.
Ale to rozwiązuje mój problem :) Ładowanie bitmapy za każdym razem do pamięci karty graficznej :)
Dzięki za uświadomienie.
0
To ile w końcu można w BC zarezerwować pamięci na stosie ( zmienne lokalne ) , a ile na stercie ( new , malloc ) ??? W BC przy takim zapisie :
[code]struct BIG
{
long t[10000];
};
int main()
{
struct BIG *ptrs[1000];
for(int i=0;i!!!!!!!
0
Hmm nawet nie 1MB tylko 640kB - rozmiar programu :P
0
Tym razem ja czegoś nie rozumiem. Twierdzicie, że pod DOSem nie można zarezerwować więcej, niż 1MB pamięci RAM??? Mam nadzieję, że nie o to Wam chodziło, bo byłby to blamaż :-P ;-).
http://www.ctyme.com/intr/rb-4765.htm
http://www.ctyme.com/intr/rb-4768.htm
Jak będzie problem z użyciem, do dać znać. Napiszę przykład.
0
Ja już cholera nic nie rozumiem . W BC pod DOSa w opcjach :
Options->Compiler->Code generation
model ustawiłem na Large - 1MB for code , 1MB for static data
rozumiem , że code to chodzi o program ( exec )
a static data to wszystkie zmienne w programie , zarówno dynamiczne ( new , malloc - sterta ) jak i lokalne ( stos ) . Mam racje ??
Skoro tak , to czemu przy takim kodzie :
[code]struct BIG
{
char tab[100][100];
};
int main()
{
struct BIG *ptrs[10000];
for(int i=0;i!!!
0
Marooned: w dosie mozna obłsugiwac nawet 256MB ale to wymaga sztuczek typu XMS i EMS lub przestawienia kompa na PMODE.
//No i ja właśnie wykorzystałem XMS, ale nie nazwałbym tego 'sztuczką' - Marooned
0
Marooned: w dosie mozna obłsugiwac nawet 256MB ale to wymaga sztuczek typu XMS i EMS lub przestawienia kompa na PMODE.
Ale co zrobić , żeby po prostu mieć na zmienne lokalne i dynamiczne chociaż te 640 kb ??
0
ehhh kiedys juz o tym pisalem ale malo kto zauwazyl pewnie,
wiec powtorka : NIE UZYWAJCIE MODELU LARGE BO TAM JEST BUG,
jest to zwiazane z "nietypowym" wskaźnikiem = 24 bity w m.large,
powiem tylko tyle bo sie spiesze : kompilator allokuje pamiec ale blad jes przy if(bufor==NULL) prawdopodobnie sprawdza tylko 16 bitow a pozostale 8 po prostu olewa, wiem ze zaraz pojawia sie tutaj kpiny ale tak jest, zmien model na HUGE lub wywal sprawdzanie wskaznika(NULL)
a wszystko powinno byc ok(polecam HUGE dla bebieczenstwa),mozna zalozyc taka sytuacje ze mniej znaczace 16 bitow rzeczywscie = 0x0 , ale caly adres to np : 00000001 00000000 00000000 i tu jest pies pogrzebany ,przynajmiej we wszystkich borlandach od 3,1 w dol.
Cala sytuacja doprowadzila mnie jakis czas temu do rozstrojenia nerwowego
Pozdrawaim Algor
EDIT:
Ten bug moze nie "wyskoczyc" ale im wiecej porownojem jak w/w przykladzie z petla tym wieksze prawdopodobienstwo ze poprawny wskaznik kompilator uzna za NULL
0
Powiem ci szczerze algor , że mnie to chyba też za niedługo doprowadzi do choroby psychicznej ...
Po dokładnym zbadaniu sprawy dochodze do następujących obserwacji :
wg tego co napisałeś , kompilator olewa 8 z 24 bitów , ale czemu ma olewać pierwsze 8 a nie ostatnie ?? Przecież to nie logiczne , te 24 bity zapisane by były ciurkiem od adresu wskaźnika . więc przeczytał by pierwsze 16 a ostatnie 8 by olał zakładając ,że myślałby że jest to wskaźnik 2 bitowy . Ale racja , mogłoby dojść do sytuacji , w której zarezerwowany by został np taki adrese :
0x000012
w tym momencie kompilator gdyby myślał , że wsk jest 2 bitowy zwrocilby blad .
Ale jednak wg mnie nie jest tak jak mówisz , sprawdzałem rozmiary wskaźników dla wszystkich modeli pamięci i okazało się , że dla wszystkich modeli oprócz LArge i Huge wskaźnik zajmuje 2 bajty a w modelach Large i Hude zajmuje 4 bajty . Teraz rozumiem , w tych mniejszych modelach nie można zaalokować więcej niż 64 kb bo po prostu wskaźnik tego nie przechowa . Ale co do tych 2 największych modeli to są już jaja . Sprawdzałem wszystko na Huge :
po raz kolejny pozwole sobie wkleić kod , teraz troszeczke przerobiony ( prosze moderatorów o wyrozumiałość )
[code]struct BIG
{
char tab[100][100];
};
int main()
{
struct BIG *ptrs[100];
for(int i=0;i!!!!
0
Powiedz mi jedno: dlaczego tak usilnie próbujesz ominąć ten błąd (czy jak to nazwać), skoro możesz wykorzystać XMS (linki podałem wyżej)?
0
Wygląda na to , że komp i tak olewa że wsk są 4 bajtowe i pewnie i tak rezerwuje tylko 64 kb , bo jak widać wartości ich są podobne , zwłaszcza gdy założymy , że komp oleje najmniej znaczące 16 bitów . Po prostu [CIACH!] można dostać . Myśle , że to Borland na siłe wprowadził wskaźniki 4 bajtowe w tych modelach pamięci , a to jednak i tak nie zmienia faktu , że jest to kompilator 16-bitowy !!! Chyba w kompilatorze 16-bitowym , nie da się zarezerwować więcej niż te 64 kb :(((( .
Yhh wczoraj widocznie wyrazilem sie troche nieprecyzyjnie dzis mam wiecej czasu wiec wytlumacze dokladniej jednak jestem teraz na wakacjach i nie mam dostepu do literatury na ktorej chetnie bym sie posilkowal teraz.
no wiec :
Pod bc31 MOZNA ZALOKOWAC wiecej niz 64kb pamieci , w wielu programach to przerabialem , moge ci wyslac moja aplikacje bazodanowa ktora zajmuje jakies 130kb (exek) i to juz jest wystarczajacym dowodem , niestety wiaze sie to z tak zwanym stronicowaniem pamieci (niech ktos mnie poprawi jak uzywam zlego slowa) , po prostu np>:kompilator obsluguje 2 bloki pamieci po 64kb jest to mozliwe o ile dobrze pamietam w modelu large+,jednak wg mnie architektura wskaznika jest nastepujaca (tak podaje literatura) :
LARGE 8 bitow - adres bloku , 16 bitow adres poszczegolnej komorki;
HUGE 16 bitow - adres bloku , 16 jw;
Za kilka dni bede w domu i moge wam zacytowac Shildta lub Zalewskiego;
Natomiast pies pogrzebany jest albo w definicji NULL albo w arytmetyce wskaznikowej BORLANDA (raczej to drugie.Jest to fakt praktycznie "odkryty" przeze mnie osobiscie poniewaz nigdzie , naprawde nigdzie nie znalazlem wzmianki o tym bugu , jednak wielu programistow mowilo mi wtedy (jak bylem w biedzie) zebym nie meczyl sie w modelu Large bo cos z nim jest nie tak.
Bezsensowne jest tez sprawdaznie rozmiaru wskaznika operatorem sizeof() , czemu ? najpierw trzeba zdac sobie po co to narzedzie istnieje w C ? a wiec jak juz wszyscy na pewno wiedza po to zeby zapewnic przenosnosc kodu a w zasadzie oile miejsca ma zrezerwowac w pamieci oraz przydatny jest tez przy indeksowaniu, liczeniu bajtow np w pliku.
Z racji tego ze wskazniki 24 bitowe uzywane w modelu large nie sa wbudowanym typem bc , kompilator przechowuje je w 32 bitach ale i tak korzysta tylko z 24 , to zjawisko mozna czesto zaobserwowac np w DJGPP przy uzyciu sizeof() na strukturze o ilus tam polach roznego typu,
najczesciej jak zliczymy wszystkie pola to daja one inna liczbe niz operator sizeof() , operator zawsze pokarze nam liczbe wieksza ktora jest potrzebna do "przechowania" zmiennej (nie pamietam ale chyba zawsze jest podzielna przez 32)
Jakie sa wyjscia z tej sytuacji ?
albo poprawic borlanda i zdefiniowac wlasny NULL
albo uzyc model HUGE w tedy wszystkie problemy powinny zniknac
Pozdrawiam Algor
ps.:
nie mam tu kompilatora , ale moze wieczorem cos zcigne to napisze kodzik ktory alokuje "troszke" pamieci
0
Marooned :
Niestety nic nie rozumiem z tego na co wskazują te linki , które podałeś :( , przykład byłby bardzo mile widziany , ale najlepiej by było gdyby bez żadnego kombinowania operator new po prostu przydzielał więcej pamięci .
algor :
Pod bc31 MOZNA ZALOKOWAC wiecej niz 64kb pamieci , w wielu programach to przerabialem , moge ci wyslac moja aplikacje bazodanowa ktora zajmuje jakies 130kb (exek) i to juz jest wystarczajacym dowodem , niestety wiaze sie to z tak zwanym stronicowaniem pamieci (niech ktos mnie poprawi jak uzywam zlego slowa) , po prostu np>:kompilator obsluguje 2 bloki pamieci po 64kb jest to mozliwe o ile dobrze pamietam w modelu large+,jednak wg mnie architektura wskaznika jest nastepujaca (tak podaje literatura) :
Jeśli chodzi o rozmiar execa , to nie ma problemu , 2 moje gry zajmowały koło 150 kb i nic nie musiałem robić , żeby mogły tyle zajmować . Chodzi mi tylko i wyłącznie o rozmiar pamięci jaką można zaalokować na stercie , czyli za pomoca operatoró new i malloc .
Z racji tego ze wskazniki 24 bitowe uzywane w modelu large nie sa wbudowanym typem bc , kompilator przechowuje je w 32 bitach ale i tak korzysta tylko z 24 , to zjawisko mozna czesto zaobserwowac np w DJGPP przy uzyciu sizeof() na strukturze o ilus tam polach roznego typu,
najczesciej jak zliczymy wszystkie pola to daja one inna liczbe niz operator sizeof() , operator zawsze pokarze nam liczbe wieksza ktora jest potrzebna do "przechowania" zmiennej (nie pamietam ale chyba zawsze jest podzielna przez 32)
tu masz racje , ale po pierwsze nie wszytskie kompilatory tak robią i nie zawsze , po drugie rozmiar obiektu musi być albo wielokrotnością albo potęgą dwójki , nie pamiętam dobrze .
A co do tego że kompilator korzysta z 3 a nie z 4 bajtów , to i tak nie robi to różnicy , jak widziałeś wyniki z mojego programu , to wynik przed 6 , to :
0x00000000 , co oznacza , ze WSZYSTKIE bajty są wyzerowane .
Jakie sa wyjscia z tej sytuacji ?
albo poprawic borlanda i zdefiniowac wlasny NULL
co do poprawiania wskaźnika null to i tak nic nie zmieni , jak pisałem wcześniej wszystkie 32 bity w wskaźniku są równe 0 , bez względu na to czy new zwróci NULL czy nie , to i tak wskaźnikom przypisywana jest wartość 0x00000000 , więc dupa zbita , bo na nic nam taki wskaźnik .
albo uzyc model HUGE w tedy wszystkie problemy powinny zniknac
Cały czas korzystam z modelu HUGE , napisałem to przed wynikami .
Bardzo bym sie cieszył gdybyś wkleił tu jakiś działający kod , który może zaalokować więcej niż te cholerne 64 kb , bardzo jest mi to potrzebne . Pozdrawiam i dzięki za zainteresowanie .
0
Marooned :
Niestety nic nie rozumiem z tego na co wskazują te linki , które podałeś :( , przykład byłby bardzo mile widziany , ale najlepiej by było gdyby bez żadnego kombinowania operator new po prostu przydzielał więcej pamięci .
Myślę, że to powinno rozwiać wszelkie wątpliwości:
http://4programmers.net/view_faq.php?id=364.
0
Algor : Już wiem co było nie tak . Wcześniej uruchamiałem program przez BC ( CTRL+F9 ) i wtedy zawsze rezerwował max 64 kb . A okazało się , że jak sie uruchomi ten sam program przez wc , command.com lub eksploatora to wszystko jest ok !! Teraz rezerwuje te 600 kb bez problemu :) . Używam modelu Huge i wszystkie wskaźniki są 4 bajtowe . Dzięki za zainteresowanie .
0
yhh juz sam zglupialem ...
dzis zallokowalem sobie 500Gb i kompilator nawet nie pisnal...
bug na bugu...
:-8
0
yhh juz sam zglupialem ...
dzis zallokowalem sobie 500Gb i kompilator nawet nie pisnal...
bug na bugu...
:-8
WOW
Chyba 500 mb a nie 500 gb !! ??? Ale w takim razie musiało to trwać conajmniej kilkadziesiąt sekund przy bardzo szybkim sprzęcie . Jesteś pewien ?? Jak tak to podaj dokładny kod i opis tego w jakim środowisku uruchamiałeś program .
//mb, to chyba mili bity, z tego, co znam standard zapisu takich rzeczy. :-)
A jeśli to miałby być Mega bity, to jest to ok. 64MB - nie tak dużo - Marooned
//leniwy programista nie ma czasu na Shifty i Caps Looki , dla niego mb==MB ;) .pzdr
0
Oczywiscie chodzi mi i GigaByte dla jasnosci :
#include
#include
#include
#include
int main(void)
{
char far *buf;
unsigned long int size,i;
printf("Far heap = %lu bytes\n", farcoreleft());
printf("How many bytes do you wants allocate ? : >");
scanf("%lu",&size);
buf = (char far *)farmalloc(size);
printf("Far heap = %lu bytes\n", farcoreleft());
if(buf==NULL)
{
printf("Error !.\n");
return 1;
}
for(i=0;i!!!!
0
buf = farmalloc(50000000000L); // ~50GB
przydzial tych 50Gb w ogóle nie trwal(chyba) nie zauwazylem roznicy miedzy 100 bytes a 50GB :)
Jasne. A jak chciałbyś zapisać tak dużą liczbę w typie long? :)
Jeżeli zarezerwował to co najwyżej:
2755359744 czyli ok. 2,5 GB A na pewno nie zarezerwował tyle, bo DOS nie ma ograniczenia nawet z XMS :)
0
Jasne. A jak chciałbyś zapisać tak dużą liczbę w typie long? :)
Jeżeli zarezerwował to co najwyżej:
2755359744 czyli ok. 2,5 GB A na pewno nie zarezerwował tyle, bo DOS nie ma ograniczenia nawet z XMS :)
W sumie to masz racje ale tutaj chodzilo mi o to , ze sprawdzanie tego warunku zawsze dawalo wg kompilatora wynik negatywny(czyli ze ok)
bez roznicy jaka liczbe bajtow rezerwowalem.
Ale jesli chodzi o szczegoly to ty tez walneles byka.Widziales kiedys wskaznik ujemny ??? :). oczywiscie wskazniki dalekie sa niczym innym jak liczba unsigned long wiec jej zakres to nie 2,5GB tylko ~5GB :)