You are not logged in.
Pages: 1
of course, SEA, share everything - sharing drives open source initiatives
And thanks
...Is it interesting now for anybody?
wonder, how element check in a set is implemented? is it performance wise/optimized? or switch use is a preferred way?
var
_set : set of byte; //has for example 20 elements
begin
if value in _set
then ...
so there wasn't fast TStringList implementation to share?
so var and const for records prevent param copying, what about static and dynamic arrays - const and var also prevent dublication? or only var (const only tu ensure read access)?
how to pass records as params without copying? decorate with the var or const?
strings and open arrays with the const, while static and dynamic arrays with the var
how to pass records as params without copying? decorate with the var or const?
strings and open arrays with the const, while static and dynamic arrays with the var
guess, that code is part of the fastcode library (correct if that's not so). By the way, is all the fastcode library code part of the enhanced RTL?
is this somehow related with the Enhanced RTL:
[Error] SysUtils.pas(5348): Undeclared identifier: 'LoadResStringTranslate'
[Error] SysUtils.pas(5348): Incompatible types
[Fatal Error] Test.dpr(168): Could not compile used unit 'SysUtils.pas'
seems to be related to the alignment value difference for the compiled Enhanced RTL and project (1 vs 8)
interesting. Just a though, that it would be nice to have an unbiased comparision of LVCL and KOL-MCK by the VCL coverage/interface congruence, features, performance/efficiency & etc. (benefits and weaknesses)
>The problem maybe is that both projects are little known
is this somehow related with the Enhanced RTL:
[Error] SysUtils.pas(5348): Undeclared identifier: 'LoadResStringTranslate'
[Error] SysUtils.pas(5348): Incompatible types
[Fatal Error] Test.dpr(168): Could not compile used unit 'SysUtils.pas'
when have turned use debug DCUs on for a project? maybe some Enhanced RTL instalation were skipped?
I follow the reason of moving hash to the buckets (index and hash in fHashs) in TDynArrayHashed, but how to you protect for the same hash problem? can't think up an elegant solution for the next index without generics in entries. Do you sort or fully iterate the fHashs?
dictionary implementation is actually quite simple, the only thing that stop me is lack of the idea/knowledge how to create appropriate backing (entries) array (in a form of TSynDictionary.Create(integer, string) for the key value pair (record) with integer keys and string values). Is any way to simulate such "generics" in Delphi prior 2009?
ab, is there any hope of movement in synopse version of dictionary direction?
As I read, there was (maybe still is?) memory leak problem with the TDictionary in Delphi 2009
sort of - hope I have managed intelligibly to convey an essence. Good ideas come out of nowhere, so others may have more or even better ones for the TSynDictionary
dynamic array (TDynArray) could be used as a dictionary, but it is much better use hashed dynamic array (TDynArrayHashed). Current state of those two out of the box doesn't encourage their usage for the dictionaries - Count is an example of additional wrapping type for the dedicated dictionary type (Count + TDynArrayHashed). If there would be question: "Is it posible and doible to use TDynArray* out of the box to simulate dictionary" answer by all means would be "Yes". Current state seems more like a sceleton for developer friendly/habitual usage, what Philnext and have noticed.
What I like in synopse, is theirs attitude - attitude towards efficiency. Maybe AntiDOT idea of instantiation, synopse efficiency and attitude with the simulated Delphi 2009 dictionary interface could be the way for the developer friendly and object-oriented complete functional dictionary implementation? that way without generics and subset of Delphi 2009 dictionary interface (count, keys, values & etc) efficient dictionary could be available before the Delphi 2009
I have seen TDynArray, but haven't used it - as I look TDynArrayHashed is much better candidate for the TDynDictionary. And interface wishes to resemble traditional ones more - maybe .NET?
And don't follow the Count issue? what's the problem to define dedicated class attribute Count for the TDynDictionary with entries and buckets ...
+1 vote for the dedicated TDynDictionary
I only could dream about AntiDOT implementation in synopse style
Of course every dictionary can be handled by DB, but personally separate notions of lightweight memory storage dictionary and all purpose heavier sibling DB table. Maybe that's the effect with beeing familiar with other language
meaning MyStuff( const myArray : array of integer )?
- Always use const for string or dynamic array parameters like in MyFunc(const aString: String) to avoid allocating a temporary string per each call;
good advice for recent Delphi, which tries to catch .NET/Java world, too bad for the Delphi 7 without ala s := _stringBuilder( s, 'Blabla', IntToStr( i ) ) or TTextWriter on steroids
- Avoid using string concatenation (s := s+'Blabla'+IntToStr(i)) , but rely on a buffered writing such as TStringBuilder available in latest versions of Delphi;
what about TStringBuilder for Delphi 7? or just use TTextWriter?
Can the TDynArray be summarized as the generic List< T > implementation for every type of T? I mean it is equially efficient as List< integer >, List< string >, List< MyCustomRecord > and List< TMyCustomClass > implementations for D6+ or there are some guides to follow for particular T type?
Lack of the generics for D7 (and static class attributes) is a very serious drawback in my eyes after C++/C#
Delphi 7 doesn't have dictionary type collection - maybe there are custom units for that? generics also are not available for the D7
found:
- delphi collections (http://www.warmachine.u-net.com/delphi_collections/)
- decal (http://sourceforge.net/projects/decal/)
and several variations, but users complain about poor performance :-/
thanks for the clarification - it is helpfull for the non-gurus of this field
should SynScaleMM be used for single or small number (up to 3-5) thread appications? what guidelines would be to choose right from FastMM/ScaleMM/SynScaleMM?
In near future I'll need to work with the TBitmap, TCanvas, TPen and TBrush type objects and such type objects I'll have many. I don't estimate requirement for the PNG, JPG formats (but you know how it happens), so should I use GDI+ for more optimized work with the graphics? or should I look into graphics library for that (they have TBitmap32 & etc)? or there is already optimized TBitmap version?
it would be nice to use everything from one source - memory manager, RTL, graphics, controls
LVCL also looks great and promising, but it provide only (minor?) subset of original VCL control (dropdowns, buttons, checkbox, forms/dialogs, panels) capabilities
Pages: 1