Hi
We are rewriting the libc for the 64 bit version of lcc-win
and we have added a new field in the FILE structure:
char *FileName;
fopen() will save the file name and an accessor function
will return the file name given a FILE *.
Questions:
What would be the best name for this function?
char *fname(FILE *); // lower case, short, similar to other
// file functions
// clear name but maybe too long?
char *FileNameFromFileP(FILE *);
What problems could arise with this function? Why is not in the C API?
We are considering extending our file functions to handle
file attributes that many file systems support. We will have two
pointers that point to extended attributes and a "user" pointer,
i.e. a pointer that would be set by the user and would carry user
defined data that we would not touch. An accessor/setter function
would allow the user to set/retrieve data.
Note that the FILE structure is now a completely opaque structure.
No definition for FILE will be available to the user but
struct __FILE;
typedef struct __FILE FILE;
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Jun 27 '08
185  6850 
In article <lz************@stalkings.ghoti.net>,
Keith Thompson <ks***@mib.orgwrote:
>Traditionally on unix systems the empty string refers to the current
directory, and you can, on some systems and some filesystems, fopen()
it. However, this is such a special case that simply setting the
"special string" to something like "(empty)" would handle it.
>But "(empty)" is a valid file name.
Look back at the thread: "special string" refers to the stuff after
the null. The normal case is
/ f o o / b a r \0
If the filename is not known, you get (for example)
\0 . . s t d i n . . \0
Twink noted this would be ambiguous if the filename really was the empty
string, so I suggested that in that case you would get
\0 ( e m p t y ) \0
to distinguish it.
So it doesn't matter that "(empty)" is a possible file name.
-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963) ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <lz************@stalkings.ghoti.net>,
Keith Thompson <ks***@mib.orgwrote:
Traditionally on unix systems the empty string refers to the current
directory, and you can, on some systems and some filesystems, fopen()
it. However, this is such a special case that simply setting the
"special string" to something like "(empty)" would handle it.
But "(empty)" is a valid file name.
Look back at the thread: "special string" refers to the stuff after
the null. The normal case is
/ f o o / b a r \0
If the filename is not known, you get (for example)
\0 . . s t d i n . . \0
Twink noted this would be ambiguous if the filename really was the empty
string, so I suggested that in that case you would get
\0 ( e m p t y ) \0
to distinguish it.
So it doesn't matter that "(empty)" is a possible file name.
You're right, I didn't make the connection.
You'd need to guarantee that, if the function returns (a pointer to)
an empty string, the '\0' is actually followed by a string.
And I agree with your earlier comment that it's ugly. (I used a
similar trick a few years ago as part of my IOCCC entry.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Eric Sosman wrote:
Walter Roberson wrote:
I do not have my C89 hardcopy here to check against. I know
that there are various routines that are marked with wording
similar to "The implementation shall behave as if no library
routine calls <name>".
They are often in relation to modification of static duration objects.
I do not recall if malloc() is one of those routines ?
No, it is not. Lots of fopen() implementations, for
example, obtain I/O buffers from malloc().
Some even use malloc to obtain the FILE pointers.
--
Peter
In article <a4***************************@cache3.tilbu1.nb.ho me.nl>,
Serve Lau <ni***@qinqin.comwrote:
>Resource heavy software like commercial games do not use malloc, they often
implement their own memory manager. Adding the filename inside FILE now
introduces an obligatory malloc that wont be used.
And just what problem will this cause in practice?
The idea that "resource heavy" games might be significantly affected by
a few dozen malloc()ed bytes for each open file seems implausible, to
say the least.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard Tobin wrote:
In article <a4***************************@cache3.tilbu1.nb.ho me.nl>,
Serve Lau <ni***@qinqin.comwrote:
>Resource heavy software like commercial games do not use malloc, they often
implement their own memory manager. Adding the filename inside FILE now
introduces an obligatory malloc that wont be used.
And just what problem will this cause in practice?
The idea that "resource heavy" games might be significantly affected by
a few dozen malloc()ed bytes for each open file seems implausible, to
say the least.
-- Richard
That kind of software uses megabytes of memory easily, but they do
not open a lot of files, just a few configuration files, images
and such, never more than (say) 100 files opened at the same
time at most. With an average path length of say 100 we have
around 10K.
BIG DEAL!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On Fri, 27 Jun 2008 23:16:56 +0200, jacob navia wrote:
That kind of software uses megabytes of memory easily, but they do
not open a lot of files, just a few configuration files, images
and such, never more than (say) 100 files opened at the same
time at most. With an average path length of say 100 we have
around 10K.
BIG DEAL!
This kind of reckless squandering of memory causes BIG PROBLEMS. Don't
forget that a lot of C programming nowadays is done in embedded
environments where memory is scare. I've recently worked on programming a
coffee maker where the total available RAM was 16K. I definitely don't
want to have 10K wasted storing garbage I don't want.
Chris Peters wrote:
On Fri, 27 Jun 2008 23:16:56 +0200, jacob navia wrote:
>That kind of software uses megabytes of memory easily, but they do
not open a lot of files, just a few configuration files, images
and such, never more than (say) 100 files opened at the same
time at most. With an average path length of say 100 we have
around 10K.
BIG DEAL!
This kind of reckless squandering of memory causes BIG PROBLEMS. Don't
forget that a lot of C programming nowadays is done in embedded
environments where memory is scare. I've recently worked on programming a
coffee maker where the total available RAM was 16K. I definitely don't
want to have 10K wasted storing garbage I don't want.
In that case please do not open 100 files simultaneously!
That was for the 100 files case :-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Chris Peters said:
On Fri, 27 Jun 2008 23:16:56 +0200, jacob navia wrote:
>That kind of software uses megabytes of memory easily, but they do
not open a lot of files, just a few configuration files, images
and such, never more than (say) 100 files opened at the same
time at most. With an average path length of say 100 we have
around 10K.
BIG DEAL!
This kind of reckless squandering of memory causes BIG PROBLEMS. Don't
forget that a lot of C programming nowadays is done in embedded
environments where memory is scare. I've recently worked on programming a
coffee maker where the total available RAM was 16K. I definitely don't
want to have 10K wasted storing garbage I don't want.
Whilst I sympathise with the idea of economic memory usage, it's probably
fair to point out that Mr Navia is not even proposing a change to the
standard library, let alone that subset of it that embedded systems are
required to provide, but rather an extension for a Windows-only
implementation. I know that 10K is still 10K, but it's not such a great
percentage of available memory on a typical Windows system as it would be
on an embedded system.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
In article <pa****************************@spam.com>,
Chris Peters <no@spam.comwrote:
>This kind of reckless squandering of memory causes BIG PROBLEMS. Don't
forget that a lot of C programming nowadays is done in embedded
environments where memory is scare.
Is it impossible to retain context over a couple of articles? We were
addressing a claim about "resource heavy games".
Jacob is considering an addition to a general-purpose Windows C
compiler. The requirements of embedded environments are irrelevant.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
"jacob navia" <ja***@nospam.comschreef in bericht
news:g4**********@aioe.org...
Richard Tobin wrote:
>In article <a4***************************@cache3.tilbu1.nb.ho me.nl>,
Serve Lau <ni***@qinqin.comwrote:
>>Resource heavy software like commercial games do not use malloc, they
often implement their own memory manager. Adding the filename inside
FILE now introduces an obligatory malloc that wont be used.
And just what problem will this cause in practice?
The idea that "resource heavy" games might be significantly affected by
a few dozen malloc()ed bytes for each open file seems implausible, to
say the least.
-- Richard
That kind of software uses megabytes of memory easily, but they do
not open a lot of files, just a few configuration files, images
and such, never more than (say) 100 files opened at the same
time at most. With an average path length of say 100 we have
around 10K.
BIG DEAL!
its what microsoft said when creating vista. BIG DEAL everybody has 2GB
these days.
its what driver writers say. BIG DEAL
its what every writer of your service or daemon you currently have running
is saying. BIG DEAL.
every program in your taskbar. BIG DEAL.
every normal program running. BIG DEAL.
Everybody says it these days.
Also, on windows things gets converted to unicode whether you want it or
not.
CBFalconer schrieb:
All you have to do is mount the DJGPP system ls command.
What means that?
What is bad about ls?
Hans Schneider wrote:
CBFalconer schrieb:
>All you have to do is mount the DJGPP system ls command.
What means that?
It means mount the portion of the DJGPP system that includes the ls
command.
>
What is bad about ls?
Nothing. Why do you assume so?
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer skrev:
[...]
Nonsense. You open the file, saving the name you used. Another
process deletes the filename you used. You still have the file
open, but the name is worthless. The file still exists. You can
copy it elsewhere, or do all sorts of things to it. Under
Unix/Linux/Posix, but not Winders.
From C point-of-view, if the file is open, the behaviour of a remove()
call is implementation defined.
FYI, the implementation in this case is lcc-win.
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
jacob navia wrote:
Richard Tobin wrote:
>In article <a4***************************@cache3.tilbu1.nb.ho me.nl>,
Serve Lau <ni***@qinqin.comwrote:
>>Resource heavy software like commercial games do not use malloc, they
often implement their own memory manager. Adding the filename inside
FILE now introduces an obligatory malloc that wont be used.
And just what problem will this cause in practice?
The idea that "resource heavy" games might be significantly affected by
a few dozen malloc()ed bytes for each open file seems implausible, to
say the least.
-- Richard
That kind of software uses megabytes of memory easily, but they do
not open a lot of files, just a few configuration files, images
and such, never more than (say) 100 files opened at the same
time at most. With an average path length of say 100 we have
around 10K.
BIG DEAL!
Really? I'm in a gaming project, a remake of a classic turn-based WW2
strategy game.
Today we load the complete map of a scenario from a single file, BUT
ideas has been put forward, to generate the scenario map from some basic
image building blocks instead.
Also, there are thousands of icons, which are overlayed on the map, each
icon has multiple variants for different orientation, to give player a
sense of dynamics in movement of units.
The icon file has grown to >50 MB and is still growing, we will consider
moving this into a central repository... and splitting it into multiple
files, so that players don't have to download everything, when more
icons are added.
Depending on future design decisions, there might be WAY MORE than 100
files to open... our map database has today around 1000 full-scale maps.
When adding features like _fname(), there will be a cost, the main thing
might not even the extra bloat by mem usage, but that this trigger more
cache misses, worse branch prediction etc. etc.
This is QoI issues, and I'm sure you have a set of benchmarks to detect
such side-effects...
One of the reasons to use C, is for the programmer to decides for
themselves when bloat is acceptable, and when it is not.
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
In article <IM*********************@telenor.com>,
Tor Rustad <bw****@wvtqvm.vwwrote:
>The icon file has grown to >50 MB and is still growing, we will consider
moving this into a central repository... and splitting it into multiple
files, so that players don't have to download everything, when more
icons are added.
Depending on future design decisions, there might be WAY MORE than 100
files to open... our map database has today around 1000 full-scale maps.
Why would all the icon files be open at once? That seems like a
stupid design decision, and additional space for the filenames would
be the least of your problems.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
I may be misunderstanding the situation, but what's wrong with the
user getting the data from the struct himself?
i.e.:
FILE *fd = fopen(name,mode);
printf ("file name is %s\n", fd.FileName);
I also agree with Chris in that it would be wasting a lot of memory.
Richard Tobin wrote:
In article <IM*********************@telenor.com>,
Tor Rustad <bw****@wvtqvm.vwwrote:
>The icon file has grown to >50 MB and is still growing, we will consider
moving this into a central repository... and splitting it into multiple
files, so that players don't have to download everything, when more
icons are added.
Depending on future design decisions, there might be WAY MORE than 100
files to open... our map database has today around 1000 full-scale maps.
Why would all the icon files be open at once? That seems like a
stupid design decision, and additional space for the filenames would
be the least of your problems.
Your interpretation, appear more stupid. :) FYI, I said "files to open",
that don't mean all files would be open _at once_. Agreed?
Anyway, as an AI programmer, it's not my call how to design this, but if
it was my call....
I would look into using an embedded DB with B-trees locally, and in case
of missing icons, downloaded these from a central repository and then
insert the icons into the local DB.
Nevertheless, I have seen more than once, programmers using the
filesystem, instead of pulling in some DB API.
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
In article <b6**********************************@l64g2000hse. googlegroups.com>,
Nigel <ni***********@gmail.comwrote:
>I may be misunderstanding the situation, but what's wrong with the
user getting the data from the struct himself?
i.e.:
FILE *fd = fopen(name,mode);
printf ("file name is %s\n", fd.FileName);
You have declared fd as a FILE *, which is a pointer, but then
you then use direct structure dereferencing on that pointer
when you use fd.FileName . fd->FileName would be more likely to
compile.
--
"Prevention is the daughter of intelligence."
-- Sir Walter Raleigh
Walter Roberson wrote:
Nigel <ni***********@gmail.comwrote:
>I may be misunderstanding the situation, but what's wrong with
the user getting the data from the struct himself?
i.e.:
FILE *fd = fopen(name,mode);
printf ("file name is %s\n", fd.FileName);
You have declared fd as a FILE *, which is a pointer, but then
you then use direct structure dereferencing on that pointer
when you use fd.FileName . fd->FileName would be more likely to
compile.
Ignoring the fact that you have no business dereferencing a FILE*
pointer yourself, what ever gave you the idea that that structure
has a FileName field?
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer <cb********@yahoo.comwrites:
Walter Roberson wrote:
>Nigel <ni***********@gmail.comwrote:
>>I may be misunderstanding the situation, but what's wrong with
the user getting the data from the struct himself?
i.e.:
FILE *fd = fopen(name,mode);
printf ("file name is %s\n", fd.FileName);
You have declared fd as a FILE *, which is a pointer, but then
you then use direct structure dereferencing on that pointer
when you use fd.FileName . fd->FileName would be more likely to
compile.
Ignoring the fact that you have no business dereferencing a FILE*
pointer yourself, what ever gave you the idea that that structure
has a FileName field?
Walter didn't. Try reading before you offer your dubious "insight".
Nigel <ni***********@gmail.comwrites:
I may be misunderstanding the situation, but what's wrong with the
user getting the data from the struct himself?
i.e.:
FILE *fd = fopen(name,mode);
printf ("file name is %s\n", fd.FileName);
You mean fd->FileName.
If it's an extension in a specific implementation, that wouldn't be an
unreasonable way to do it, I suppose. Any code that refers to it is
going to be non-portable anyway.
If it were being proposed as an addition to the standard, though, I
wouldn't want to do it that way. It would place additional
constraints on implementations, specifically that type FILE must be a
struct (or union, but that would be silly). And it wouldn't fit in
well conceptually with everything else in <stdio.hthat takes FILE*
arguments and doesn't attempt to delve into the internals.
(To be clear, I don't think anybody has proposed adding this to the
standard.)
I also agree with Chris in that it would be wasting a lot of memory.
I don't think it would be much of a problem, other than on small
embedded systems that don't necessarily support fopen() anyway.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
In article <zr*********************@telenor.com>,
Tor Rustad <bw****@wvtqvm.vwwrote:
>Why would all the icon files be open at once? That seems like a
stupid design decision, and additional space for the filenames would
be the least of your problems.
>Your interpretation, appear more stupid. :) FYI, I said "files to open",
that don't mean all files would be open _at once_. Agreed?
Well, that would have been the natural interpretation, but in that
case what would the problem be with storing the file names? The
amount of space required corresponds to the number of simultaneously
open files, not the total number ever opened.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard Tobin wrote:
In article <zr*********************@telenor.com>,
Tor Rustad <bw****@wvtqvm.vwwrote:
>>Why would all the icon files be open at once? That seems like a
stupid design decision, and additional space for the filenames would
be the least of your problems.
>Your interpretation, appear more stupid. :) FYI, I said "files to open",
that don't mean all files would be open _at once_. Agreed?
Well, that would have been the natural interpretation, but in that
Instead of assuming others write something stupid, it's perhaps wise to
reconsider your own smartness first.
case what would the problem be with storing the file names? The
amount of space required corresponds to the number of simultaneously
open files, not the total number ever opened.
FYI, an implementation of the standard C library free(), may or may not
trigger a system call, which actually free the memory chunk allocated.
Even if a program burn memory like a pig, modern OS'es will typically
swap out unused memory pages anyway.
If the free() implementation is like you suggest, with an explicit
system call for every free() call. Then, programs opening many files,
might be slowed down by 1 extra system call per malloc(), and 1 extra
system call per free(). That can become a lot of context switches... for
no good reason at all.
The point is, bloated C compilers, are not very interesting to the
gaming community, which a while back, used lcc for quite a different reason.
--
Tor <echo bw****@wvtqvm.vw | tr i-za-h a-z>
Richard wrote:
CBFalconer <cb********@yahoo.comwrites:
>Walter Roberson wrote:
>>Nigel <ni***********@gmail.comwrote:
I may be misunderstanding the situation, but what's wrong with
the user getting the data from the struct himself?
i.e.:
FILE *fd = fopen(name,mode);
printf ("file name is %s\n", fd.FileName);
^^^^^^^^^^^
>>>
You have declared fd as a FILE *, which is a pointer, but then
you then use direct structure dereferencing on that pointer
when you use fd.FileName . fd->FileName would be more likely to
compile. ^^^^^^^^^^^ ^^^^^^^^^^^^
Ignoring the fact that you have no business dereferencing a FILE*
pointer yourself, what ever gave you the idea that that structure
has a FileName field?
Walter didn't. Try reading before you offer your dubious "insight".
Walter did. Note the underlined referances.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
In article <g4**********@pc-news.cogsci.ed.ac.uk ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <a4***************************@cache3.tilbu1.nb.ho me.nl>,
Serve Lau <ni***@qinqin.comwrote:
Resource heavy software like commercial games do not use malloc, they often
implement their own memory manager. Adding the filename inside FILE now
introduces an obligatory malloc that wont be used.
And just what problem will this cause in practice?
When malloc is in conflict with their own memory manager.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
CBFalconer wrote:
Richard wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Walter Roberson wrote:
Nigel <ni***********@gmail.comwrote:
I may be misunderstanding the situation, but what's wrong with
the user getting the data from the struct himself?
i.e.:
FILE *fd = fopen(name,mode);
printf ("file name is %s\n", fd.FileName);
^^^^^^^^^^^
>>>>
You have declared fd as a FILE *, which is a pointer, but then
you then use direct structure dereferencing on that pointer
when you use fd.FileName . fd->FileName would be more likely to
compile. ^^^^^^^^^^^ ^^^^^^^^^^^^
Ignoring the fact that you have no business dereferencing a FILE*
pointer yourself, what ever gave you the idea that that structure
has a FileName field?
Walter didn't. Try reading before you offer your dubious "insight".
Walter did. Note the underlined referances.
Note that "Nigel" was the one who first mentioned it. Walter Roberson
was just offering a correction.
Dik T. Winter wrote:
In article <g4**********@pc-news.cogsci.ed.ac.ukri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <a4***************************@cache3.tilbu1.nb.ho me.nl>,
Serve Lau <ni***@qinqin.comwrote:
>
Resource heavy software like commercial games do not use malloc, they often
implement their own memory manager. Adding the filename inside FILE now
introduces an obligatory malloc that wont be used.
>
And just what problem will this cause in practice?
When malloc is in conflict with their own memory manager.
Then they can't use lcc-win anyway since fopen calls malloc to
allocate the FILE structure.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
In article <Kb*********************@telenor.com>,
Tor Rustad <bw****@wvtqvm.vwwrote:
>Well, that would have been the natural interpretation, but in that
>Instead of assuming others write something stupid, it's perhaps wise to
reconsider your own smartness first.
I just couldn't see how your point made any sense otherwise.
>case what would the problem be with storing the file names? The
amount of space required corresponds to the number of simultaneously
open files, not the total number ever opened.
>FYI, an implementation of the standard C library free(), may or may not
trigger a system call, which actually free the memory chunk allocated.
Even if a program burn memory like a pig, modern OS'es will typically
swap out unused memory pages anyway.
I still don't understand your point. I know all that.
>If the free() implementation is like you suggest, with an explicit
system call for every free() call.
I haven't suggested anything like that at all. I doubt there are
any such implementations.
>Then, programs opening many files,
might be slowed down by 1 extra system call per malloc(), and 1 extra
system call per free(). That can become a lot of context switches... for
no good reason at all.
Such an implementation would be very inefficient. But presumably
Jacob's isn't such an implementation.
Just in case I'm still not clear, my point was that adding a malloc()
to fopen() (and a free() to fclose()) is not going to have a great cost
for large programs because it won't use much memory compared to that
already used, and won't take any significant time compared with the
overhead of opening a file.
>The point is, bloated C compilers, are not very interesting to the
gaming community, which a while back, used lcc for quite a different reason.
That might be *a* point, but the one I was addressing was much more
specific.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
In article <K3********@cwi.nl>, Dik T. Winter <Di********@cwi.nlwrote:
>When malloc is in conflict with their own memory manager.
Do they actually work in such a way that malloc() *conflicts* with
their memory manager, rather than just being independent of it?
-- Richard
--
Please remember to mention me / in tapes you leave behind.
CBFalconer <cb********@yahoo.comwrites:
Richard wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Walter Roberson wrote:
Nigel <ni***********@gmail.comwrote:
I may be misunderstanding the situation, but what's wrong with
the user getting the data from the struct himself?
i.e.:
FILE *fd = fopen(name,mode);
printf ("file name is %s\n", fd.FileName);
^^^^^^^^^^^
>>>>
You have declared fd as a FILE *, which is a pointer, but then
you then use direct structure dereferencing on that pointer
when you use fd.FileName . fd->FileName would be more likely to
compile. ^^^^^^^^^^^ ^^^^^^^^^^^^
Ignoring the fact that you have no business dereferencing a FILE*
pointer yourself, what ever gave you the idea that that structure
has a FileName field?
Walter didn't. Try reading before you offer your dubious "insight".
Walter did. Note the underlined referances.
Once more. Please read what you are replying to. Your contributions are
become more useless by the post. If you don't have anything to offer,
then keep quiet.
In article <g4**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
....
>Once more. Please read what you are replying to. Your contributions are
become more useless by the post. If you don't have anything to offer,
then keep quiet.
Excuse me. If the regs stopped posting useless/wrong stuff, all you'd
hear in here would be crickets.
And where would be the fun in that? I say: Keep it comin'!
Richard Tobin wrote:
In article <Kb*********************@telenor.com>,
Tor Rustad <bw****@wvtqvm.vwwrote:
>>Well, that would have been the natural interpretation, but in that
>Instead of assuming others write something stupid, it's perhaps wise to
reconsider your own smartness first.
I just couldn't see how your point made any sense otherwise.
In the message you responded to, I said:
"When adding features like _fname(), there will be a cost,
the main thing might not even the extra bloat by mem usage,
but that this trigger more cache misses, worse branch
prediction etc. etc."
To spell it out: my main consern was NOT the extra SPACE required, but
the TIME overhead. Regardless, I would add a benchmark with at least 10
000 files to open and read, considering only 100 files, was way too little.
>>case what would the problem be with storing the file names? The
amount of space required corresponds to the number of simultaneously
open files, not the total number ever opened.
>FYI, an implementation of the standard C library free(), may or may not
trigger a system call, which actually free the memory chunk allocated.
Even if a program burn memory like a pig, modern OS'es will typically
swap out unused memory pages anyway.
I still don't understand your point. I know all that.
IF you did, then please explain how this make sense:
"The amount of space required corresponds to the number of
simultaneously open files, not the total number ever opened."
FYI, assume that a program open X files, load the content of all X
files, then close X files.
At this point, the "simultaneously open files" are only 3. If free()
implementation has no explicit system call to free the space allocated,
the memory required by the program at this point, does _not_ correspond
to 3 files, but to
3 + X
files.
>If the free() implementation is like you suggest, with an explicit
system call for every free() call.
I haven't suggested anything like that at all. I doubt there are
any such implementations.
This statement
"The amount of space required corresponds to the number of
simultaneously open files, not the total number ever opened."
only made sense to me, IF you suggested exactly that. Unlike others, I
do assume that people are smart. :P
--
Tor <echo bw****@wvtqvm.vw | tr i-za-h a-z>
In article <Kp*********************@telenor.com>,
Tor Rustad <bw****@wvtqvm.vwwrote:
>IF you did, then please explain how this make sense:
"The amount of space required corresponds to the number of
simultaneously open files, not the total number ever opened."
FYI, assume that a program open X files, load the content of all X
files, then close X files.
This seems to be the very "all open at once" interpretation which you
said was stupid.
>At this point, the "simultaneously open files" are only 3. If free()
implementation has no explicit system call to free the space allocated,
the memory required by the program at this point, does _not_ correspond
to 3 files, but to
3 + X
files.
Ok, the maximum number of simultaneously open files. If you read the
files one after another (and close them as you go along), the memory
will be available to malloc() to reuse. You would only need memory
for all 3+X if all 3+X were simultaneously open at some time, which is
why I asked why you would have all the icon files open at once.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard Tobin wrote:
In article <Kp*********************@telenor.com>,
Tor Rustad <bw****@wvtqvm.vwwrote:
>IF you did, then please explain how this make sense:
"The amount of space required corresponds to the number of
simultaneously open files, not the total number ever opened."
FYI, assume that a program open X files, load the content of all X
files, then close X files.
This seems to be the very "all open at once" interpretation which you
said was stupid.
I said:
"Your interpretation, appear more stupid."
it was you who talked about _stupid_ design, I just made a relative
assertion. Do you understand the difference?
FYI, I have not said yet, whether I consider it a stupid design or not.
>At this point, the "simultaneously open files" are only 3. If free()
implementation has no explicit system call to free the space allocated,
the memory required by the program at this point, does _not_ correspond
to 3 files, but to
3 + X
files.
Ok, the maximum number of simultaneously open files.
???
I give up, you contradict yourself too much, is 3 + X equal to the total
number ever opened, or NOT?
You can't have it both ways, ref:
"The amount of space required corresponds to the number of
simultaneously open files, not the total number ever opened."
--
Tor <echo bw****@wvtqvm.vw | tr i-za-h a-z>
In article <eL*********************@telenor.com>,
Tor Rustad <bw****@wvtqvm.vwwrote:
>Ok, the maximum number of simultaneously open files.
???
I give up, you contradict yourself too much, is 3 + X equal to the total
number ever opened, or NOT?
You can't have it both ways, ref:
"The amount of space required corresponds to the number of
simultaneously open files, not the total number ever opened."
I'm sorry, I'm completely lost. Perhaps someone else (if anyone's
bothered to follow it) could resolve the point.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard wrote:
CBFalconer <cb********@yahoo.comwrites:
.... snip ...
>
>Walter did. Note the underlined referances.
Once more. Please read what you are replying to. Your
contributions are become more useless by the post. If you don't
have anything to offer, then keep quiet.
Well, with my change in news-servers resulting in a new troll-file,
you have so far escaped installation. No longer. You are now
properly classified with Twink and McCormack. Bye.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Richard |
last post by:
Hi All,
I am using Visual C++ .Net to create a windows forms application and I am
getting the following errors when I do a MessageBox::Show in my Form1.cpp
file:
Form1.cpp(19): error C2653:...
|
by: asad |
last post by:
Hello friends, i need some help in getting uploaded file name, i am uploading
2 files and i want to get only the filename of these 2 file not a full path
so pls tell me which function or technique...
|
by: ruju00 |
last post by:
I am getting an error in Login() method of the following class
FtpConnection
public class FtpConnection
{
public class FtpException : Exception
{
public FtpException(string message) :...
|
by: pukya78 |
last post by:
Hi,
I am trying to get the current file and the line number which is
getting executed. I used:
MessageBox.Show(New StackTrace(New
StackFrame(True)).GetFrame(0).GetFileLineNumber) which gives me...
|
by: iwdu15 |
last post by:
hi, how can i get the icon associated with a certain file type? thanks
--
-iwdu15
| | |
by: AshishMishra16 |
last post by:
HI friends,
I am using the Flex to upload files to server. I m getting all the details about the file, but I m not able to upload it to Server. Here is the code i m using for both flex & for...
|
by: sbettadpur |
last post by:
hello
i am calling .exe file through my php script.
i.e. using exec or system command, i am running exe file that exe file will create on txt file which contains who has logged into domain(i.e....
|
by: tshad |
last post by:
I have the following class in my VS 2008 project that has a namespace of
MyFunctions.
*********************************
Imports System
Imports System.Text.RegularExpressions
Namespace...
|
by: vikas251074 |
last post by:
I am not getting date value in spite of my good effort. This code was working in my last office where I work. Now I am trying to work at my home pc. but not getting date value. Any can help me why...
|
by: vikas251074 |
last post by:
I am getting error above in following code since few days giving tension day and night.
How can I solve this? I am facing since Oct.25. in line no. 362
After doing a lot of homework, I am...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
| | |
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
| | |
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
