473,320 Members | 1,887 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Extremely pedantic, but however...


Is it not inefficient to have allowed "free" to accept a null pointer? Would
it not have been better to disallow it, and to provide an auxiliary function
for times when its wanted:

#define FREE_SAFE(p) ( (void)( (p) && free((p)) ) )

--

Frederick Gotham
Oct 21 '06 #1
22 1656

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:W1*******************@news.indigo.ie...
>
Is it not inefficient to have allowed "free" to accept a null pointer?
Would
it not have been better to disallow it, and to provide an auxiliary
function
for times when its wanted:

#define FREE_SAFE(p) ( (void)( (p) && free((p)) ) )
In the olden days freeing a null pointer would crash your computer.
The overhead is probably so trivial that the convenience is worth it.
Plus malloc() is allowed to return null if a region of zero size is
requested. So it is not necessarily illegitimate to free null.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Oct 21 '06 #2
Frederick Gotham wrote:
Is it not inefficient to have allowed "free" to accept a null pointer?
Only in C. Programmers in other languages generally don't care about an
insignificant extra comparison. (free() itself is hardly cheap on most
implementations.)
Would it not have been better to disallow it, and to provide an auxiliary
function for times when its wanted:
Define "better". C already catches a lot of flak for having standard
functions that do not check their arguments (or in some cases cannot check
their arguments). The comparatively small cost of ensuring free(NULL)
doesn't crash is worth it (note that in the general case free() does not
have observable side effects, so making free(NULL) a no-op does not decrease
reliability).

S.
Oct 21 '06 #3
Skarmander posted:
>Is it not inefficient to have allowed "free" to accept a null pointer?

Only in C. Programmers in other languages generally don't care about an
insignificant extra comparison. (free() itself is hardly cheap on most
implementations.)

I'm not talking about programmers, I'm talking about computers running
programs. If it takes 20 nanoseconds for a particular machine to check if a
pointer is null, then the execution time of your algorithm is extended by
20 nanoseconds for each time you call "free" (if every one of these null
checks is redundan). Those 20 nanoseconds could have been reclaimed if
"free" didn't check for null pointers.

Whether a particular human being (aka programmer, in this context)
considers 20 nanoseconds to be negligible is irrelevant to my query.

>Would it not have been better to disallow it, and to provide an
auxiliary function for times when its wanted:

Define "better".

More efficient. Runs faster. Uses less resources.

C already catches a lot of flak for having standard
functions that do not check their arguments (or in some cases cannot
check their arguments).

Depends who you ask. I congratulate C for its efficiency. If you want your
hand to be held, you could get a wrapper library:

size_t strlen_HOLD_MY_HAND(char const *const p)
{
if (p) return strlen(p);

return 0;
}

The comparatively small cost of ensuring
free(NULL) doesn't crash is worth it (note that in the general case
free() does not have observable side effects, so making free(NULL) a
no-op does not decrease reliability).

If you want the feature of being able to invoke "free" upon a null pointer,
then all it takes is something simple like:

#define FREE_SAFE(p) do { void *const q = p; if(q) free(q); } while (0);

This way, you can use "free" whenever a null check would be redundant,
saving 20 nanoseconds in execution time.

--

Frederick Gotham
Oct 21 '06 #4
Frederick Gotham wrote:
>
.... snip ...
>
If you want the feature of being able to invoke "free" upon a null
pointer, then all it takes is something simple like:

#define FREE_SAFE(p) do { void *const q = p; if(q) free(q); } while (0);

This way, you can use "free" whenever a null check would be
redundant, saving 20 nanoseconds in execution time.
Ridiculous. All you are doing is applying the same test twice.
The following is the code used in my nmalloc package (A #define
converts nfree to free under the appropriate conditions). Note
that nothing is done when ptr is NULL, apart from the ability to
hook in user code. The DBG* lines are null in the release
version. The hook mechanism also allows the user to catch any
free(NULL) calls. See:

<http://cbfalconer.home.att.net/download/>

void nfree(void *ptr)
{
memblockp m;

if (hookptr[free_HK]) hookptr[free_HK](0, ptr);

if (ptr) {
m = MEMBLKp(ptr);
DBGPRTF("free(%p)", ptr); SHOWBLKF(m, "");
if (ISFREE(m) || /* bad, refreeing block */
FOULED(m) ) { /* block is fouled */
badcallabort("free", 4, m);
return; /* he can trap this SIGABRT */
}
dofree(m);
#if DEBUGF
DBGEOLN;
#endif
}
else if (hookptr[free_null_HK])
hookptr[free_null_HK](0, NULL);
} /* nfree */

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

Oct 21 '06 #5
Frederick Gotham wrote:
Skarmander posted:
>>Is it not inefficient to have allowed "free" to accept a null pointer?
Only in C. Programmers in other languages generally don't care about an
insignificant extra comparison. (free() itself is hardly cheap on most
implementations.)


I'm not talking about programmers, I'm talking about computers running
programs.
So am I.
If it takes 20 nanoseconds for a particular machine to check if a
pointer is null, then the execution time of your algorithm is extended by
20 nanoseconds for each time you call "free" (if every one of these null
checks is redundan). Those 20 nanoseconds could have been reclaimed if
"free" didn't check for null pointers.
And free() is going to take up much more than 20 nanoseconds, most likely an
order of magnitude more.
Whether a particular human being (aka programmer, in this context)
considers 20 nanoseconds to be negligible is irrelevant to my query.
Then your use of "inefficient" is peculiar, since efficiency never
exclusively depends on absolute execution time. If that were the case, you
should focus on making your programs much more efficient by not using
dynamic memory allocation at all, obviating any concerns about free().
>>Would it not have been better to disallow it, and to provide an
auxiliary function for times when its wanted:
Define "better".


More efficient. Runs faster. Uses less resources.
Your idea of better programs is limited.
>C already catches a lot of flak for having standard
functions that do not check their arguments (or in some cases cannot
check their arguments).

Depends who you ask. I congratulate C for its efficiency. If you want your
hand to be held, you could get a wrapper library:

size_t strlen_HOLD_MY_HAND(char const *const p)
{
if (p) return strlen(p);

return 0;
}
This has nothing to do with hand-holding. If you're writing a program where
you need either the length of a string or 0 if there is no string, this
function is exactly what you want. If you're writing a program where you
need the length of a string, calling strlen() with a null pointer is an
error, since that's not a string.

For free() it was decided that calling it with a null pointer is not an
error, that "no memory" is a valid argument, and that freeing "no memory" is
a no-op. This makes sense, since malloc() may return "no memory". Again, I
maintain that the cost one pays for having these semantics, rather than more
intricate ones that allow for a slightly simpler implementation, is
insignificant.
>The comparatively small cost of ensuring
free(NULL) doesn't crash is worth it (note that in the general case
free() does not have observable side effects, so making free(NULL) a
no-op does not decrease reliability).


If you want the feature of being able to invoke "free" upon a null pointer,
then all it takes is something simple like:

#define FREE_SAFE(p) do { void *const q = p; if(q) free(q); } while (0);

This way, you can use "free" whenever a null check would be redundant,
saving 20 nanoseconds in execution time.
That does not address my point, which is that nobody ever benefits enough
from those 20 nanoseconds to warrant changing the semantics of free().
Programmers who are actually concerned with omitting redundant null checks
should invest in their compiler, which is far more likely to pay off.

A check for NULL in strlen() could be significant. My bold assertion is that
a check for NULL in free() never is.

S.
Oct 21 '06 #6
Frederick Gotham wrote:
Skarmander posted:

>>>Is it not inefficient to have allowed "free" to accept a null pointer?

Only in C. Programmers in other languages generally don't care about an
insignificant extra comparison. (free() itself is hardly cheap on most
implementations.)

I'm not talking about programmers, I'm talking about computers running
programs. If it takes 20 nanoseconds for a particular machine to check if a
pointer is null, then the execution time of your algorithm is extended by
20 nanoseconds for each time you call "free" (if every one of these null
checks is redundan). Those 20 nanoseconds could have been reclaimed if
"free" didn't check for null pointers.

Whether a particular human being (aka programmer, in this context)
considers 20 nanoseconds to be negligible is irrelevant to my query.
20 nanoseconds?

At 2GHZ a test for NULL takes 0.5 nano seconds with nanoseconds being
1e-9 seconds

OK, anyway this is for the principle you say. Suppose your program makes
1e4 frees/second. That extra test will accumulate to

0.5e-9*1e4 --0.5e-5 seconds, i.e. to make a difference of 1 second
your program should run for 2e5 seconds, i.e. 55.55 hours, or 2.31 days.

Non stop.

And then you would just see a difference of 1 second, all this doing
10 000 calls to free() in each second.

This program
#include <stdlib.h>
#include <stdio.h>
#define MAXTRIES 1000000*10
int main(void)
{
char *a;

for (int i=0; i<MAXTRIES;i++) {
a = malloc(123456);
free(a);
}
}

takes 3.484 seconds, i.e. 10 million calls to malloc/free
take 3.484 seconds, one of them takes 0,0000003484 seconds
in a 2 year old PC running at 2GHZ.

If you do 10 000 malloc/free per second you are using
0,003484 seconds on those calls. In 200 000 seconds
your program has spent 11.61 MINUTES in malloc/free, and from
those 11.62 MINUTES you spend 1 second more in that test for
NULL.
Oct 21 '06 #7

Frederick Gotham wrote:
Is it not inefficient to have allowed "free" to accept a null pointer?
The test takes one or two instructions. The rest of the code for
free() is at least ten times more instructions, most of them slow
memory-reference instructions.

In addition, since you can only free() something that has been
malloc()ed, and only free() it once, those two test instructions only
get run if you've also malloced() something. So you have to add the
overhead of malloc() when considering this issue. malloc(), depending
on the exact implementation, runs from 50 to 500 instructions.

So two extra fast instructions out of 70 to 520 not so fast ones isnt
much of a burden.

And that's only for programs that do nothing but malloc() and free().

I would not worry about it.

Oct 21 '06 #8
Frederick Gotham wrote:
Is it not inefficient to have allowed "free" to accept a null pointer?
Terribly inefficient. Even worse is the fact that free()
is a function, thus incurring the overhead of marshalling the
argument, transferring control (possibly disrupting pipelines
and instruction caches), remembering a return address, maybe
saving some registers and/or doing a window turn with possible
stack spill, and then unwinding the whole thing when free()'s
business has been done. Pure overhead! Horrible to contemplate!
free() should have been an operator, as in That Other Language.
*Then* we'd finally get some efficiency!

All right, class, let's turn the page. Next, we'll talk
about all the time printf() wastes interpreting format strings.
Who wants to go first?

--
Eric Sosman
es*****@acm-dot-org.invalid
Oct 21 '06 #9
On Sat, 21 Oct 2006 09:44:20 GMT, in comp.lang.c , Frederick Gotham
<fg*******@SPAM.comwrote:
>Skarmander posted:
>Define "better".

More efficient.
define more efficient... :-)
>Runs faster. Uses less resources.
Fast, small, cheap. Perm two of three...
>
If you want the feature of being able to invoke "free" upon a null pointer,
then all it takes is something simple like:

#define FREE_SAFE(p) do { void *const q = p; if(q) free(q); } while (0);

This way, you can use "free" whenever a null check would be redundant,
saving 20 nanoseconds in execution time.
At the cost of getting the compiler to create an extra object, perform
a test and insert a loop. This may cost more in terms of time, and
resources, than the original free.

I assume youre aware of the Three Laws of Optimisation?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Oct 21 '06 #10
At 2GHZ a test for NULL takes 0.5 nano seconds with nanoseconds being
1e-9 seconds
A test is a single instruction. Then a non executed branch is another
instruction. The mips is the most recent CPU I can think of that has
an integrated cmp/branch instruction.

The CPU is (most likely) super scaller so these instructions are
executing in parallel.

I think that having to fetch 2 more instructions, branch prediction,
convert to internal RISC format (if this is an x86 taget) is going to
have a larger performance impact than actual execution

This program
#include <stdlib.h>
#include <stdio.h>
#define MAXTRIES 1000000*10
int main(void)
{
char *a;

for (int i=0; i<MAXTRIES;i++) {
a = malloc(123456);
free(a);
}
}
What about the performance of the following code ?
The branch prediction inside of free isn't going to be that great.

#include <stdlib.h>
#include <stdio.h>
#define MAXTRIES 1000000*10/2
int main(void)
{
char *a;

for (int i=0; i<MAXTRIES;i++) {
a = malloc(123456);
free(a);
free(NULL);
}
}


Frederick Gotham wrote:
Skarmander posted:

>>Is it not inefficient to have allowed "free" to accept a null pointer?

Only in C. Programmers in other languages generally don't care about an
insignificant extra comparison. (free() itself is hardly cheap on most
implementations.)


I'm not talking about programmers, I'm talking about computers running
programs. If it takes 20 nanoseconds for a particular machine to check if a
pointer is null, then the execution time of your algorithm is extended by
20 nanoseconds for each time you call "free" (if every one of these null
checks is redundan). Those 20 nanoseconds could have been reclaimed if
"free" didn't check for null pointers.

Whether a particular human being (aka programmer, in this context)
considers 20 nanoseconds to be negligible is irrelevant to my query.

20 nanoseconds?

At 2GHZ a test for NULL takes 0.5 nano seconds with nanoseconds being
1e-9 seconds

OK, anyway this is for the principle you say. Suppose your program makes
1e4 frees/second. That extra test will accumulate to

0.5e-9*1e4 --0.5e-5 seconds, i.e. to make a difference of 1 second
your program should run for 2e5 seconds, i.e. 55.55 hours, or 2.31 days.

Non stop.

And then you would just see a difference of 1 second, all this doing
10 000 calls to free() in each second.

This program
#include <stdlib.h>
#include <stdio.h>
#define MAXTRIES 1000000*10
int main(void)
{
char *a;

for (int i=0; i<MAXTRIES;i++) {
a = malloc(123456);
free(a);
}
}

takes 3.484 seconds, i.e. 10 million calls to malloc/free
take 3.484 seconds, one of them takes 0,0000003484 seconds
in a 2 year old PC running at 2GHZ.

If you do 10 000 malloc/free per second you are using
0,003484 seconds on those calls. In 200 000 seconds
your program has spent 11.61 MINUTES in malloc/free, and from
those 11.62 MINUTES you spend 1 second more in that test for
NULL.
Oct 21 '06 #11
Frederick Gotham wrote:
Is it not inefficient to have allowed "free" to accept a null pointer?
No. In a balanced malloc/free design, free takes about 30 clocks
minimum to completely execute. So the additional if() test (1 clock
maybe?) is just too trivial to matter. In non-balanced malloc/free
designs, indeed you can make the free() faster, but you've paid the
comparatively bigger penalty for the malloc (maybe 75 clocks?) instead
anyways.
[...] Would
it not have been better to disallow it, and to provide an auxiliary function
for times when its wanted:

#define FREE_SAFE(p) ( (void)( (p) && free((p)) ) )
This is worse, because it distributes the checking throughout your
code, rather than centralizing it inside the library. (I.e., your code
footprint increases).

This is besides the fact that since its a macro, p might be an
expression with side effects that you are evaluating twice.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Oct 21 '06 #12
Samuel Stearley wrote:
>>At 2GHZ a test for NULL takes 0.5 nano seconds with nanoseconds being
1e-9 seconds


A test is a single instruction. Then a non executed branch is another
instruction. The mips is the most recent CPU I can think of that has
an integrated cmp/branch instruction.

The CPU is (most likely) super scaller so these instructions are
executing in parallel.

I think that having to fetch 2 more instructions, branch prediction,
convert to internal RISC format (if this is an x86 taget) is going to
have a larger performance impact than actual execution
>>This program
#include <stdlib.h>
#include <stdio.h>
#define MAXTRIES 1000000*10
int main(void)
{
char *a;

for (int i=0; i<MAXTRIES;i++) {
a = malloc(123456);
free(a);
}
}


What about the performance of the following code ?
The branch prediction inside of free isn't going to be that great.

#include <stdlib.h>
#include <stdio.h>
#define MAXTRIES 1000000*10/2
int main(void)
{
char *a;

for (int i=0; i<MAXTRIES;i++) {
a = malloc(123456);
free(a);
free(NULL);
}
}
It goes up from 3.484 to 3.687. But if I change the program to do
#include <stdlib.h>
#include <stdio.h>
static void fn(void *p)
{
}

#define MAXTRIES 1000000*10
int main(void)
{
char *a;

for (int i=0; i<MAXTRIES;i++) {
a = malloc(123456);
free(a);
fn(NULL);
}
}

The time stays the same... within measurements error.

This means that the overhead of calling a
function 10 million times is what is increasing the time here, and the
difference between calling an empty function and calling malloc
with NULL is zero

probably it just make a return after it sees NULL, that's all.
Oct 21 '06 #13
CBFalconer posted:
>This way, you can use "free" whenever a null check would be
redundant, saving 20 nanoseconds in execution time.

Ridiculous. All you are doing is applying the same test twice.

I don't understand you.

The hypothetical "free" would not check for null.

The hypothetical "FREE_SAFE" would check for null once.

--

Frederick Gotham
Oct 21 '06 #14
On Sat, 21 Oct 2006 08:40:22 GMT, Frederick Gotham
<fg*******@SPAM.comwrote:
>
Is it not inefficient to have allowed "free" to accept a null pointer? Would
it not have been better to disallow it, and to provide an auxiliary function
for times when its wanted:

#define FREE_SAFE(p) ( (void)( (p) && free((p)) ) )

--

Frederick Gotham

Invoking your FREE_SAFE macro above with an argument of malloc(10000)
generates a nice memory leak.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Oct 21 '06 #15

"Eric Sosman" <es*****@acm-dot-org.invalidwrote in message
news:z9******************************@comcast.com. ..
Frederick Gotham wrote:
>Is it not inefficient to have allowed "free" to accept a null pointer?

Terribly inefficient. Even worse is the fact that free()
is a function, thus incurring the overhead of marshalling the
argument, transferring control (possibly disrupting pipelines
and instruction caches), remembering a return address, maybe
saving some registers and/or doing a window turn with possible
stack spill, and then unwinding the whole thing when free()'s
business has been done. Pure overhead! Horrible to contemplate!
free() should have been an operator, as in That Other Language.
*Then* we'd finally get some efficiency!

All right, class, let's turn the page. Next, we'll talk
about all the time printf() wastes interpreting format strings.
Who wants to go first?
I waste an hour every time I have to lay eyes on the page in K&R with
fprintf specifiers. EC
Oct 21 '06 #16
# If it takes 20 nanoseconds for a particular machine to check if a
# pointer is null, then the execution time of your algorithm is extended by
# 20 nanoseconds for each time you call "free" (if every one of these null
# checks is redundan). Those 20 nanoseconds could have been reclaimed if
# "free" didn't check for null pointers.

This is the same argument as to why Fortran didn't have
zero trip DO loops. See also, etc etc etc.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
OOOOOOOOOO! NAVY SEALS!
Oct 22 '06 #17
Frederick Gotham wrote:
CBFalconer posted:
>>This way, you can use "free" whenever a null check would be
redundant, saving 20 nanoseconds in execution time.

Ridiculous. All you are doing is applying the same test twice.

I don't understand you.

The hypothetical "free" would not check for null.

The hypothetical "FREE_SAFE" would check for null once.
Are you just trolling? I posted an example of a free that checked
for NULL, and you just snipped it. Every free must do this to meet
the standards requirements.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Oct 22 '06 #18
CBFalconer <cb********@yahoo.comwrites:
Frederick Gotham wrote:
>CBFalconer posted:
>>>This way, you can use "free" whenever a null check would be
redundant, saving 20 nanoseconds in execution time.

Ridiculous. All you are doing is applying the same test twice.

I don't understand you.

The hypothetical "free" would not check for null.

The hypothetical "FREE_SAFE" would check for null once.

Are you just trolling? I posted an example of a free that checked
for NULL, and you just snipped it. Every free must do this to meet
the standards requirements.
He did say "hypothetical". The point of this thread is his suggestion
that free() would be more efficent if it *didn't* check for a null
pointer argument; the FREE_SAFE macro would do the check, and be more
or less equivalent to the real-world free(). Obviously this would not
conform to the actual standard.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Oct 22 '06 #19
No he's not trolling.
He's saying that his 'FREE_SAFE' macro does not result in the NULL
check twice because the 'free' that its calling is a hypothetical free
that lacks such a check.

CBFalconer wrote:
Frederick Gotham wrote:
CBFalconer posted:
>This way, you can use "free" whenever a null check would be
redundant, saving 20 nanoseconds in execution time.

Ridiculous. All you are doing is applying the same test twice.
I don't understand you.

The hypothetical "free" would not check for null.

The hypothetical "FREE_SAFE" would check for null once.

Are you just trolling? I posted an example of a free that checked
for NULL, and you just snipped it. Every free must do this to meet
the standards requirements.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Oct 22 '06 #20
ozbear posted:
Invoking your FREE_SAFE macro above with an argument of malloc(10000)
generates a nice memory leak.

I realise that. The macro name is written in ALL CAPS though, so the
programmer is made aware of the dangers.

Alternative forms would be:

inline void safe_free(void *const p)
{
if (p) free(p);
}

Or, the non-thread-safe:

void *p_SAFE_FREE;

#define SAFE_FREE(p) (\
\
(p_SAFE_FREE = (p)), \
\
((void)(p_SAFE_FREE && free(p_SAFE_FREE))) )

int main()
{
SAFE_FREE( malloc(p_SAFE_FREE) );
}

(I don't know how my compiler is parsing that, but it's complaing about a
conversion from size_t to void* -- I'd say its something to do with the &&.

Or, the non-expression one:

#define SAFE_FREE(p) do{void*const q=(p);q && free(q);}while(0)

--

Frederick Gotham
Oct 22 '06 #21
In article <Ua*******************@news.indigo.ieFrederick Gotham <fg*******@SPAM.comwrites:
....
void *p_SAFE_FREE;
....
SAFE_FREE( malloc(p_SAFE_FREE) );
....
(I don't know how my compiler is parsing that, but it's complaing about a
conversion from size_t to void* -- I'd say its something to do with the &&.
I think the complaint is the other way around. What is the type of the
argument of malloc?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Oct 23 '06 #22
Dik T. Winter posted:
void *p_SAFE_FREE;
...
SAFE_FREE( malloc(p_SAFE_FREE) );
...
(I don't know how my compiler is parsing that, but it's complaing
about a conversion from size_t to void* -- I'd say its something to do
with the &&.

I think the complaint is the other way around. What is the type of the
argument of malloc?

Wups! Obviously I should have written something like:

SAFE_FREE( malloc(512) );

--

Frederick Gotham
Oct 23 '06 #23

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

83
by: D. Dante Lorenso | last post by:
Trying to use the 'search' in the docs section of PostgreSQL.org is extremely SLOW. Considering this is a website for a database and databases are supposed to be good for indexing content, I'd...
1
by: Alan Searle | last post by:
I have a VBA function which scans directories and reads the filenames (of the contents) out into a table. Mostly this works fine but one of my clients is having a problem and I suspect it is...
14
by: Steve McLellan | last post by:
Hi, Sorry to repost, but this is becoming aggravating, and causing me a lot of wasted time. I've got a reasonably large mixed C++ project, and after a number of builds (but not a constant...
2
by: news.microsoft.com | last post by:
I have an extremely odd cookie problem and had many programmers in the group looked at it but still with no solution. The following is the synptom: I have a user control ( for inputting user...
6
by: DCC-700 | last post by:
I am running VB for ASP.Net in VS.Net 2003 and am experiencing extremely slow response in the ide at times and the debugger. Below is additional detail on the problem. Any thoughts are much...
5
by: jacob navia | last post by:
Due to popular demand (specially from Mr Heathfield), I have introduced a -pedantic compiler flag, that will be as the -ansic option but stricter. This flag will make _stdcall
2
by: Mack | last post by:
Hi Guys, I am working on Linux C++ using Gcc3.4.6 to make files and make project run. When i make(compile file) it says pedantic errors so what error is this exactly?? I think this error is...
8
by: Simon Klein | last post by:
Hi, I've got a problem. I wrote a Program with a Signalhandler Routine. If i use the compile flags "-ansi -pedantic -Wall", "(void) signal(SIGCHLD,Handler)" catches the first signal but ignores...
15
by: new to c | last post by:
Hi! I write this code cos.c #include <math.h> #include <stdio.h> int main(void) { double c;
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.