Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
14.7.2006 16:29
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
1. Klasický zásobník je samozřejmě rychlý, ale rekurzivní implementace na něj ukládá mnohonásobně víc dat, než je potřeba. Jeho velikost je navíc omezena a na některých platformách je to omezení dost výrazné. Navíc je to omezení, se kterým prostě nehnete.
2. Realokovat není (obecně) potřeba a není ani nutné alokovat obrovské pole předem. Zásobník totiž vůbec nemusí být realizován jako lineární pole.
3. Snadno nahlédneme, že paměťové nároky řešení s vlastním zásobníkem jsou už z principu nižší než paměťové nároky řešení pomocí rekurze. Navíc s tím rozdílem, že pokud dojde místo na systémovém zásobníku, máme smůlu; dojde-li místo v našem zásobníku, dá se s tím něco dělat.
Sečteno a podtrženo: než někoho nařknete, že o problematice nic neví, nebývá od věci ověřit, zda toho sám víte aspoň tolik co on. Vyhnete se tak zbytečné blamáži…
15.7.2006 00:37
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Zásobník totiž vůbec nemusí být realizován jako lineární pole.A třeba takový
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czstd::stack ani není. Protože bývá typicky implementován pomocí std::deque, nepotřebuje souvislý úsek paměti.
#include <stdio.h>
int q(int i) {
printf("%d\n", i);
q(i+1);
}
int main(int argc, char** argv) {
q(0);
}
a nez to spadlo, tak napocital do 523 722. A dost pochybuju, ze by se algoritmus pri razeni nekolika souboru v adresari nekdy dostal do srovnatelny hloubky
A dost pochybuju, ze by se algoritmus pri razeni nekolika souboru v adresari nekdy dostal do srovnatelny hloubkyHehe. Takto by programátor uvažovat neměl.
, ale pokud provedu jenom hrubej vypocet, tak v idealnim pripade (pokud by se mu podarilo pole rozdelit vzdy presne na pul) by se do tyto hloubky dostal az pri poli velkym 2**523722 = 10e19 polozek. ono se mu to sice pravdepodobne vetsinou nepodari rozdelit presne na pul, ale stejne by to melo stacit na hodne hodne hodne velky pole...
2. A co takhle spojový seznam z jednotlivých polí vhodně zvolené velikosti? Realokovat není potřeba nic, alokovat nemusím tak často, overhead na spojovací pointer je zanedbatelný. Jinak ani kdyby to byl opravdu čistý spojový seznam, nemáte pravdu, protože ten pointer má z podstaty věci přesně stejnou velikost jako návratová adresa (kterou tam pro změnu nutně potřebujete vy) - a pořád ušetřím nějaké ty lokální proměnné.
3. Ne. Opakuji, že při rozumné implementaci zásobníku není potřeba nic realokovat.
Ad P.S.: porovnejte si celkovou velikost lokálních proměnných a argumentů u vašeho testovacího prográmku a u implementace, o níž tu byla řeč. Pořád sice zbyde relativně velké číslo, ale jak už jsem řekl, existují i jiné platformy.
Mimochodem, netvrdím, že rekurze je vždy špatná. Jen zásadně nesouhladím s důvody, které pro její upřednostnění uvádíte.
počet prvků = počet tříděných prvků / 2, tedy např. pro třídění pole int indexované int bude mít stejnou velikost, jako tříděné pole, pro třídění řetězců bude zabírat zlomek paměti zabrané tříděným seznamem. Opravdu monstrózní paměťové nároky…
Gcc umí aspoň tail recursion, aspoň občas, když už ne obecně.) Hromada rekurzivních volání jsou jen skoky s přejmenováním parametrů. Jak je to u quicksortu, to se budu muset podívat – docela mě to zajímá a už byh si ho měl konečně taky jednou naimplementovat. Ale přesto mi přijde, že hromada lidí šmahem odsuzuje rekurzi proto, že nikdy neviděli kompilátor, který ji dokáže vyeliminovat. A přitom to může být tak pěkné (a bezpečné) goto s parametry...
btw, ked uz vykon (a pamat), radsej by som pouzil radix sort
14.7.2006 16:29
int (*compare)(FileInfo *, FileInfo *, bool);
switch( column )
{
case 0:
compare = &FileInfoList::compare_name;
break;
case 1:
compare = &FileInfoList::compare_ext;
break;
case 2:
compare = &FileInfoList::compare_size;
break;
case 3:
compare = &FileInfoList::compare_date;
break;
case 4:
compare = &FileInfoList::compare_attrs;
break;
case 5:
compare = &FileInfoList::compare_owner;
break;
default:
compare = &FileInfoList::compare_group;
break;
}
for( FileInfoList::size_type i = 0; i < list->count(); ++i )
{
if( i == nCentral ){
same.push_back( list->at(nCentral) );
continue;
}
compareRes = (*compare)( list->at(nCentral), list->at(i), ascending );
/* ... */
a taky porovnavani ascending bych nepsal do kazdy compare fci zvlast ale primo do sort, je to min prace. ale to uz byl jenom takovej kosmetickej detail ;)
14.7.2006 17:22
Jardík | skóre: 40
| blog: jarda_bloguje
14.7.2006 20:31
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Co mne nejak nenapada, ale neni switch jenom if () { } else if () { } else { } ?Obecně být nemusí. Pokud bude kompilátor dostatečné chytrý, může to v řadě případů optimalizovat. Bohužel nevím, jestli to GCC dělá (případně které verze).
Je pravda, že virtual call něco stojí, ale v případě poměrně primitivních mechanismů C++ a relativně složitých porovnávacích funkcí, která vidím v kódu, mi to přijde docela levné. A líp by se to četlo.
) problému, ale právě jsem se vrátil z...společenské události... ...a vůbec, budu se potřebovat pořádně vyspat.
Ovšem po čtení knihy Thinking Forth (ve které každá třetí věta obsahuje sloveso „factor out“ ) cestou domů ovšem působí takovýhle kód prostě jako rána palici do hlavy.
Nemluvě o tom, že už jsem asi hodně odvykl používání Windows, takže samotná myšlenka dělení jména souboru na jméno a příponu mi připadá poněkud nepatřičná…
2. Jeslti dobře vidím, porovnáváte timestampy tak, že je převedete struct time a ty pak složitě porovnáváte po složkách. Nebylo by praktičtější porovnat je rovnou nebo, bojíte-li se tolik o přenositelnost na obskurní platformy, použít difftime()?
14.7.2006 17:22
Jardík | skóre: 40
| blog: jarda_bloguje
isDots(), dostanete vždy -1.
class Comparator;
class CompareFileSize : Comparator; // atd
class FileListInfo {
public static COMPARE_BY_FILE_SIZE;
}
FileInfoList::sort (const Comparator &);
...
file_list->sort (FileListInfo->COMPARE_BY_FILE_SIZE);
file_list->sort (new MyCrazyComparator);
file_list->reverse;
public static COMPARE_BY_FILE_SIZE;asi něco chybí.
14.7.2006 17:57
Jardík | skóre: 40
| blog: jarda_bloguje
file_list->sort(new MyCrazyComparator);Typická ukázka ztracení pointeru (leda, že by pak ta fce na konci volala delete).
14.7.2006 17:59
Jardík | skóre: 40
| blog: jarda_bloguje
14.7.2006 18:32
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
14.7.2006 19:33
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
15.7.2006 08:54
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
14.7.2006 19:40
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
) ved ich nechajme, nech sa hraju )
FileInfoList má členskou funkci, která umí setřídit jinou instanci FileInfoList a pak další členskou funkci, která té první předá svou instanci. To je poněkud avantgardní řešení, ne?
void FileInfoList::sort( FileInfoList* list, int column, bool ascending )
{
…
}
void FileInfoList::sort( int column, bool ascending )
{
sort( this, column, ascending );
}
Zajímavé.
sort(), ale řekl bych, že to je ve srovnání s paměťovou náročností spíše vedlejší problém.
14.7.2006 22:23
Jardík | skóre: 40
| blog: jarda_bloguje
14.7.2006 22:24
Jardík | skóre: 40
| blog: jarda_bloguje
14.7.2006 23:23
Jardík | skóre: 40
| blog: jarda_bloguje
if( list->count() <= 1 ) return;
int (*compare)(FileInfo *, FileInfo *, bool);
switch( column )
{
case 0:
compare = FileInfoList::compare_name;
break;
case 1:
compare = FileInfoList::compare_ext;
break;
case 2:
compare = FileInfoList::compare_size;
break;
case 3:
compare = FileInfoList::compare_date;
break;
case 4:
compare = FileInfoList::compare_attrs;
break;
case 5:
compare = FileInfoList::compare_owner;
break;
default:
compare = FileInfoList::compare_group;
break;
}
#define MAX_LEVELS 1000
FileInfo *piv;
int beg[MAX_LEVELS], end[MAX_LEVELS];
int i=0, L, R, elements = (int)list->count();
beg[0] = 0;
end[0] = elements;
while(i>=0)
{
L = beg[i];
R = end[i] - 1;
if( L < R )
{
if( i == MAX_LEVELS - 1 ) return;
piv = list->at(L);
while( L < R )
{
while(compare(list->at(R),piv,ascending) >= 0 && L<R ) R--;
if(L<R) list->at(L++) = list->at(R);
while(compare(list->at(L),piv,ascending) <= 0 && L<R ) L++;
if(L<R) list->at(R--) = list->at(L);
}
list->at(L) = piv;
beg[i+1] = L+1;
end[i+1] = end[i];
end[i++] = L;
} else {
i--;
}
}
template<typename Item>
void qsort(Item* a, int left, int right, int (*less)(Item a, Item b)) {
int i = left;
int j = right;
Item pivot = a[(i+j)/2];
while(i <= j) {
while(less(a[i], pivot)) i++;
while(less(pivot, a[j])) j--;
if(i < j) {
Item temp = a[i];
a[i] = a[j];
a[j] = temp;
i++; j--;
} else
if(i == j) {
i++; j--;
}
}
if(left < j) qsort(a, left, j, less);
if(i < right) qsort(a, i, right, less);
}
less je funkce, ktera prima dva prvky pole a vraci nenulovou hodnotu, pokud je prvni mensi nez druhy (ma byt v poli pred druhym)
podle me ta posloupnost neni naprosto nahodna, ale je pravdepodobny, ze bude uz castecne serazena
Navíc nevím nic o tom, jak jsou data udržována a obnovována, takže jsem raději vynechal naprosto běžné situace typu přidání nebo přejmenování jednoho souboru.
Další (menší) zdroj neefektivity je i v tom, že se používá at() místo operátoru [], čímž se zbytečně pokaždé testují meze.
15.7.2006 01:07
bool compare_abc(const FileInfo* a, const FileInfo* b)
{
...
}
static bool (*compare_functions[]) = {
compare_abc,
compare_def,
...
}
inline void FileInfoList::sort() {
sort(begin(), end(), compare_functions[column]);
}
15.7.2006 00:24
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
static bool (*compare_functions[])(const FileInfo* a, const FileInfo* b) = {
static bool (*compare_functions[])(const FileInfo*, const FileInfo*) = {
15.7.2006 13:43
Jardík | skóre: 40
| blog: jarda_bloguje
class file_comparator {
protected:
bool ascending;
virtual bool less(const FileInfo* a, const FileInfo* b) = 0;
public:
file_comparator(bool asc) : ascending(asc) {}
virtual ~file_comparator() {}
bool operator () (const FileInfo* a, const FileInfo* b);
};
bool file_comparator::operator () (const FileInfo* a, const FileInfo* b)
{
if (b->isDots()) return false;
if (a->isDots()) return true;
if (a->isDir() && !b->isDir()) return true;
if (b->isDir() && !a->isDir()) return false;
return (ascending ? less(a,b) : less(b,a));
}
class file_comparator_name : public file_comparator {
protected:
virtual bool less(const FileInfo* a, const FileInfo* b);
public:
file_comparator_name(bool asc) : file_compararator(asc) {}
virtual ~file_comparator_name() {}
};
bool file_comparator_name::less(const FileInfo* a, const FileInfo* b)
{
// tady porovnáme jména
}
// a podobně pro další kritéria
void FileInfoList::sort(FileInfoList::column_t column, bool asc)
{
file_comparator* cmp;
switch(column) {
case col_name:
cmp = new file_comparator_name(asc); break;
// ...
default:
// cannot happen
// throw ...;
}
std::sort(begin(), end(), cmp);
delete cmp;
}
(určitě jsou tam chyby, psal jsem to z hlavy a nezkoušel přeložit)
nevraviac o tom, ze v pripade vektora ci double-linked-list je to operacia urcite menej narocna.
. a .. vypisovaly vždy na začátku, pak ostatní adresáře a pak teprve ostatní typy souborů. Tím by se i obracení seznamu trochu zkomplikovalo. Kdyby šlo o prosté otočení pořadí, vůbec nejjednodušší by bylo nepřerovnávat nic a pouze ten seznam v opačném pořadí vypisovat…
to by som radsej pouzil nejake filtre (v design pattern terminologii by to boli pravdepodobne dekoratory nad zoznamom), a/alebo miesto komparatora pouzit key-generator (hmm, asi tiez dekoratory, ale nad prvkami zoznami)
priklady key-generatory:
- pre kazdy sortovatelny prvok
- case sensitivity/insensitivity
- ignorovat/neignorovat non-word character na zaciatku retazca
- file extension
FileList head = FileList->search ('.', '..');
FileList tail = FileList->search (mask)->filter (head);
tail->filter (new OwnerOnlyFilter)->sort (new FileListNameKey);
....
Panel.show (head + tail);
teraz ma tak napadlo, ze vlastne chyba definicia chovania v pripade rovnosti kriteria (typu primarne podla mtime, potom size, potom reverzne name)
17.7.2006 10:27
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
typedef shared_ptr< FileInfo > FileInforPtr;
class RuntimeFileCmp {
public:
enum cmp_mode {default_mode, size_mode, name_mode, ext_mode, attrs_mode, owner_mode, group_mode, date_mode};
private:
cmp_mode mode_; //column
bool ascending_;
int FileInfoList::compare_size(const FileInforPtr &fi1, const FileInforPtr &fi2) const;
int FileInfoList::compare_name( const FileInforPtr &fi1, const FileInforPtr &fi2) const;
int FileInfoList::compare_ext( const FileInforPtr &fi1, const FileInforPtr &fi2) const ;
int FileInfoList::compare_attrs( const FileInforPtr &fi1, const FileInforPtr &fi2) const;
int FileInfoList::compare_owner( const FileInforPtr &fi1, const FileInforPtr &fi2) const;
int FileInfoList::compare_group( const FileInforPtr &fi1, const FileInforPtr &fi2) const;
int FileInfoList::compare_date( const FileInforPtr &fi1, const FileInforPtr &fi2)const;
public:
RuntimeFileCmp( cmp_mode m = default_mode, bool ascending = true ) : mode_( m ), ascending_( a )
{
}
void setComparisonMode( cmp_mode m = default_mode ){
mode_ = m;
}
cmp_mode getComparisonMode() const {
return mode_;
}
void setOrderingMode( bool a = true ){
ascending_ = a;
}
bool getOrderingMode() const {
return ascending_;
}
bool operator()( const FileInforPtr fi1, const FileInforPtr fi2 ) const
{
switch( mode_ )
{
case 0:
compareRes = compare_name( fi1, fi2 );
break;
case 1:
compareRes = compare_ext( fi1, fi2);
break;
case 2:
compareRes = compare_size( fi1, fi2 );
break;
case 3:
compareRes = compare_date( fi1, fi2 );
break;
case 4:
compareRes = compare_attrs( fi1, fi2 );
break;
case 5:
compareRes = compare_owner( fi1, fi2);
break;
default:
compareRes = compare_group( fi1, fi2);
break;
}
return compareRes > 0;
}
};
typedef std::set< FileInforPtr, RuntimeFileCmp > file_set_t; //kontejner XY
/////////////////////////////////////////////////////////////
//v kodu
RuntimeFileCmp<slo by to udelat i obecne> compareDate(RuntimeFileCmp::date_mode, false);
RuntimeFileCmp compareName(RuntimeFileCmp::name_mode, true);
file_set_t fileSetCompName( comapreName );
file_set_t fileSetCompDate( compareDate );
fileSetCompName a fileSetCompDate se sami seradi, kdyz budu chtit jiny zpusob, tak set priradim jinymu;
nebo pouzit komparator RuntimeFileCmp pro funkci std::sort, tj. data budou ve vektoru a ty vzdy seradim podle
toho jak vytvorim objekt k razeni, tj. RuntimeFileCmp.
Vse by se navic dalo parametrizovat. Je tu vyhoda oddelenych dat a algoritmu, navic, kdyz uz jsou napsany...
switch. Spíš bych volil řešení využívající polymorfismu, tj. něco podobného jako jsem navrhoval zde.
17.7.2006 19:36
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
17.7.2006 19:44
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
Tiskni
Sdílej:
