 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
> Garbage collection is BAAAAD!!!
> Any implementation that permit you not to use that is GOOD.
Uh, not sure why you'd say this. You're looking at one implementation of
one garbage collector, and deducing from this that the entire concept is
bad? You *are* aware there are such things as real-time garbage
collectors, for example?
I can't imagine a GC that takes 15 minutes on anything that isn't paging
like mad. In which case the problems isn't the GC, but the paging, in
which case you should say "paging is baaaaad!" :-)
I mean, really, how can you imagine any decent GC would take more than
(say) three times the length of time it takes to read all physical memory?
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 wrote:
> Yeah, old GC algorithms used to do this. Research has been done,
> solutions have been found, etc.
Plus, a lot of the complaints about GC slowness are caused in part by
the GC not interacting with the paging system well. I.e., the OS isn't
prepared for programs that're going to do GC in particular patterns.
There are read-aheads on disk files. Why would you wait until the GC
hits the bad page before starting to read it in?
Of course, paging systems nowadays don't even know the physical layouts
of the disks, so it's generally hard to do things like select sectors on
the swap partition in a way that paging things back in will be fast.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp nous apporta ses lumieres en ce 2007/11/02 16:14:
> Alain <ele### [at] netscape net> wrote:
>> Using UTF16 encoding, any character is 2 BYTES long, for a grand total is 65536
>> possible characters, not all of them been printable.
>
> Wrong. UTF16-encoding results in either 2-byte or 4-byte characters,
> depending on the unicode value.
>
> Perhaps you are confusing it with UCS2?
>
I think that I missed the bit about 4 bytes UTF16 characters...
--
Alain
-------------------------------------------------
History, in general, only informs us of what bad government is.
Thomas Jefferson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New nous apporta ses lumieres en ce 2007/11/02 20:04:
> Alain wrote:
>> Garbage collection is BAAAAD!!!
>> Any implementation that permit you not to use that is GOOD.
>
> Uh, not sure why you'd say this. You're looking at one implementation of
> one garbage collector, and deducing from this that the entire concept is
> bad? You *are* aware there are such things as real-time garbage
> collectors, for example?
>
> I can't imagine a GC that takes 15 minutes on anything that isn't paging
> like mad. In which case the problems isn't the GC, but the paging, in
> which case you should say "paging is baaaaad!" :-)
>
> I mean, really, how can you imagine any decent GC would take more than
> (say) three times the length of time it takes to read all physical memory?
>
OK, it was a LONG time ago!
There was no paging, there could'nt be any paging, there was no HD to receive
anything. ALL of the data was in RAM. It was before HD where common on PC's.
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you know how to render a truly
photorealistic compact disc, and you're not going to tell anyone
(least of all a POV user ;) ).
-- Alex McLeod a.k.a. Giant Robot Messiah
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp nous apporta ses lumieres en ce 2007/11/02 17:10:
> Alain <ele### [at] netscapenet> wrote:
>>> And thus, like any decent variable-length encoding scheme, it tries to
>>> assign short codes to common symbols. (Although UTF-8 probably fails
>>> horribly for, say, Japanese text. I don't actually know...)
>> For Japanese and Chinese, it average around 3 bytes per characters. It's not so
>> bad after all, as each characters in those represent a whole word, some even
>> represent a whole phrase or some complexe concept.
>
> UTF16 is better because it uses 2 bytes for the vast majority of the most
> commonly used kanjis and other symbols used in Japanese.
>
But then, you don't have place for the Chinese ones, then you need Vietnamese,
Corean, Hindu, Sanskrit, Latin, Cyrilic, Arabic, Inuctituk, Math symbols,...
--
Alain
-------------------------------------------------
Make yourself a better person and know who you are before you try and know
someone else and expect them to know you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> > UTF16 is better because it uses 2 bytes for the vast majority of the most
> > commonly used kanjis and other symbols used in Japanese.
> >
> But then, you don't have place for the Chinese ones, then you need Vietnamese,
> Corean, Hindu, Sanskrit, Latin, Cyrilic, Arabic, Inuctituk, Math symbols,...
UTF16 can handle all those too, although some require 4 bytes.
I suppose Chinese might be more compact with UTF8 than with UTF16,
especially if you use lots of kanjis not in the 2-byte UTF16 range
(because those require 4 bytes with UTF16, while in UTF8, AFAIK, they
require only 3).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Invisible wrote:
>> (and AFAIK in plain C) you *must* expose all implementation details of
>> a type in order for anybody else to be able to touch it.
>
> Nah. Just use a forward-declared struct and pass pointers to it. You
> know, like fopen/fread/fwrite/fclose. Note those haven't changed since
> the first edition of K&R.
I have no concept of what you're talking about - but you're probably
right...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 wrote:
> Darren New wrote:
>> Invisible wrote:
>>> (and AFAIK in plain C) you *must* expose all implementation details
>>> of a type in order for anybody else to be able to touch it.
>>
>> Nah. Just use a forward-declared struct and pass pointers to it. You
>> know, like fopen/fread/fwrite/fclose. Note those haven't changed
>> since the first edition of K&R.
>
> I have no concept of what you're talking about - but you're probably
> right...
In C, you declare a pointer to a structure without defining the layout
of the structure. C allows this, because it assumes all pointers are the
same size and have a unified alignment requirement and can all live in
the same kinds of registers and things like that.
Then in your code file, you define the structure. Creating an object
involves allocating the structure and returning the opaque pointer to
it. Using the object requires passing the opaque pointer back in.
No implementation details are visible at all.
http://en.wikipedia.org/wiki/C_file_input/output
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> In C, you declare a pointer to a structure without defining the layout
> of the structure. C allows this, because it assumes all pointers are the
> same size and have a unified alignment requirement and can all live in
> the same kinds of registers and things like that.
>
> Then in your code file, you define the structure. Creating an object
> involves allocating the structure and returning the opaque pointer to
> it. Using the object requires passing the opaque pointer back in.
>
> No implementation details are visible at all.
good ol' abstract data types. I still enjoy Haskell's powerful algebraic
datatypes, higher-order functions, currying and concise coding a lot more.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> In C, you declare a pointer to a structure without defining the layout
> of the structure.
Ah, yes. I believe Borland's TurboPascal allows this too. (There's a
type just called "Pointer", which you then have to cast to something
else before you can use it.) Good luck with figuring out how big the
data structure in question is... (But then, presumably the module that
uses this thing will handle all creation and destruction.) Also fun, you
how cannot have an array of this thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
