Byla vydána verze 1.91.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Ministerstvo průmyslu a obchodu vyhlásilo druhou veřejnou soutěž v programu TWIST, který podporuje výzkum, vývoj a využití umělé inteligence v podnikání. Firmy mohou získat až 30 milionů korun na jeden projekt zaměřený na nové produkty či inovaci podnikových procesů. Návrhy projektů lze podávat od 31. října do 17. prosince 2025. Celková alokace výzvy činí 800 milionů korun.
Google v srpnu oznámil, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Iniciativa Keep Android Open se to snaží zvrátit. Podepsat lze otevřený dopis adresovaný Googlu nebo petici na Change.org.
Byla vydána nová verze 18 integrovaného vývojového prostředí (IDE) Qt Creator. S podporou Development Containers. Podrobný přehled novinek v changelogu.
Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).
Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
Pro moddery Minecraftu: Java edice Minecraftu bude bez obfuskace.
Národní identitní autorita, tedy NIA ID, MeG a eOP jsou nedostupné. Na nápravě se pracuje [𝕏].
Americký výrobce čipů Nvidia se stal první firmou na světě, jejíž tržní hodnota dosáhla pěti bilionů USD (104,5 bilionu Kč). Nvidia stojí v čele světového trhu s čipy pro umělou inteligenci (AI) a výrazně těží z prudkého růstu zájmu o tuto technologii. Nvidia již byla první firmou, která překonala hranici čtyř bilionů USD, a to letos v červenci.
Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).
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:
