473,883 Members | 1,663 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

why still use C?

no this is no trollposting and please don't get it wrong but iam very
curious why people still use C instead of other languages especially C++.

i heard people say C++ is slower than C but i can't believe that. in pieces
of the application where speed really matters you can still use "normal"
functions or even static methods which is basically the same.

in C there arent the simplest things present like constants, each struct and
enum have to be prefixed with "struct" and "enum". iam sure there is much
more.

i don't get it why people program in C and faking OOP features(functi on
pointers in structs..) instead of using C++. are they simply masochists or
is there a logical reason?

i feel C has to benefit against C++.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
--
comp.lang.c.mod erated - moderation address: cl**@plethora.n et
Nov 13 '05
687 23872
xarax wrote:
Actually, casting the result of malloc() is *good*
programming practice, because it verifies that you
are assigning the result to the pointer-type that
you expect of the target variable.
fubar = (Gronk *) malloc(whatever _size_you_want) ;
This verifies that "fubar" is declared as a
pointer type to whatever Gronk is.


It allows the compiler to suppress a possibly vital diagnostic. In any
event, if fubar isn't a Gronk *, then you're bound to find out fairly soon,
because lots of other stuff isn't going to compile.

What do you think of this code?

#include <stdio.h>

int main(void)
{
int i;
double d = (double)3.14;
i = (int)6;
(int)printf("%d %f\n", (int)i, (double)d);
return (int)0;
}

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #271
Jirka Klaue wrote:
Sidney Cadot wrote:
...
/* don't include stdlib.h */
int main(void)
{
char *x = malloc(100);
return 0;
}

This version is legal C as well, so a compiler is free to not issue a
warning.


It is not legal C. C99 requires a valid prototype and C89 does not
allow the assignment of int to char *. A diagnostic is *required*.


I stand corrected.

Could anybody point me to the last C89 draft standard that is publicly
available on the web? I have "n869.pdf" sitting on my HD for C99 which
is pretty useful and I would also like a similar document for C89.

If only to prevent silly mistakes like this.

Best regards,

Sidney Cadot

Nov 13 '05 #272
CBFalconer wrote:
[[ casting malloc() results ]]
Why is it considered "bad practice"? I know it is frowned upon
sometimes, but I fail to see the rationale for that.

One advantage of casting malloc() results is that, like you say,
one has a fighting chance of getting a clean (error/warning-less)
compile using C++ in addition to getting a clean compile in C.

It can hide errors that the compiler could otherwise pick up. It
prevents controlling the type of that object in only one place,
and having all other code slaved to that.
Could you provide examples? I'm sure there are, but it's a lot easier to
discuss this over an example for me.
Casts are fundamentally evil things, and very often serve only to
conceal errors.
'fundamentally evil things' ... that's a bit harsh isn't it?

It would make an interesting exercise to write low-level C code (e.g.,
kernels or device drivers), without casts. Are you suggesting this is
practical?
I have yet to see a C++ compiler that does not have a C mode, and
there is no problem linking C++ code with C code when the headers
are properly designed.


Sure, but I want to write C code, but sometimes compile the program with
a C++ compiler to use the extra checks as required by a C++ compiler,
for flagging potential problems - is that so strange?

Best regards,

Sidney Cadot

Nov 13 '05 #273
Irrwahn Grausewitz wrote:
Implicit conversions to/from pointer-to-void from/to any other
pointer-to-<type> are explicitly permitted in C.
I think that is a mistake, and I am not going to drop casts that are not
needed just because the standard allows me to.


If you think that C99 6.3.2.3 is a mistake, you should submit a DR or a
proposal to the standards comittee. ;-)


Perhaps I should do that! And hopefully I could convince them to retract
support for those butt-ugly // comments as well :-)
I feel my code looks prettier with malloc() casts. We couldn't disagree more on this aspect, but it's a style question and
therefore IMHO not /that/ important.
Yes.
2. Casting malloc's return value may hide the (admittedly simple to fix)
error of not providing a proper prototype for malloc.


If this is the case, I seriously doubt the quality of the compiler:

/* don't include stdlib.h */
int main(void)
{
char *x = (char *)malloc(100);
return 0;
}

warning: implicit declaration of function `malloc'
result: undefined behaviour; malloc now returns int, but with the cast
you told the compiler: shut up, even if otherwise it would be
so kind to issue another warning (see below).


Undefined behavior: for sure, but we're discussing compile-time behavior
now.

My point is that a decent modern compiler will warn on the implicit
declaration of malloc() anyway, with an appropriate warning level.
The standard doesn't require the compiler to issue a warning of course
(never does), but I think, the year being AD2003 and all, that a
good-quality compiler should issue a warning whether the (char *) cast
is there or not.


You rely upon the fact that an integer is wide enough to hold a pointer
value. This holds true for some implementations . It invokes undefined
behaviour on others and is therefore dangerous and completely
unportable.


Exactly. For clearness: I'm not advocating leaving out the "#include
<stdlib.h>" here; we're discussing the compile-time consequences of
forgetting this, when casting or not casting the result of a malloc().
/* don't include stdlib.h */
int main(void)
{
char *x = malloc(100);
return 0;
}

warning: implicit declaration of function `malloc'
warning: initialization makes pointer from integer without a cast
result: undefined behaviour

This version is legal C as well,

Not really.


So it was brought to my attention. I'm talking C89 here (in C99 you will
get an error anyway for lack of a prototype); what I meant to say is
that this is compilable under C89, possible without a warning. What I
didn't realize is that this will emit a required diagnostic
(pointer-to-int conversion).
It invokes undefined behaviour, so a compiler is free to not issue a
warning. So the only thing that is lost when including the (char *) cast
is that a compiler that would balk at program #2 might not balk at
program #1.


Additionally you lost the chance of having well defined behaviour and
portability. Congratulations :^]


Again, I'm not advocating leaving out #include <stdlib.h> ; we're just
comparing compile-time behavior for different malloc() handling.
I think that's a bad-quality compiler, and I think the
advantage of code that is both legal C and legal C++ outweighs the fact
that some bad compiler would fail to see the problem in program #1.


So in your opinion a decent compiler should automagically know that the
return type of malloc is void *, without being told by a prototype.


No, that's not what I said. My opinion is this: A decent C89 compiler
should be able to warn on non-prototyped functions being used, even
though C89 allows it.
I'm not aware of what implementations you have used so far, but I bet
all of them are bad-quality compilers according to your definition.
.... You misunderstood my definition. All compilers I've used are able to
warn on non-prototyped function usage.
[snipped a small bit...]
It is probably feasible to make e.g. Pascal
programs pass C compilers, but you end up with something that is neither
well written Pascal nor well written C.


Making a caricature of my position surely doesn't help much :-)


Caricatures have the advantage of exposing certain aspects by hyperbole.
In one sense they are /defined/ that way. :o)


Chapter and verse? :-)
Here's another one:
A perfectely valid Spanish sentence can also be a perfectly valid
Portugese sentence, but with a different meaning. The fact that both
are somewhat close related languages doens't make them compatible.
....Now suppose you have a machine that understands Spanish, and a
machine that understands Portugese. Both machines warn on incorrect
syntax and grammer in their respectively understood languages. Let's
also assume (to make the metaphor a bit more realistic) that Portugese
descends from Spanish, adding a few grammatic constructs, and that most
Spanish sentences (except from contrived examples) are also correct
Portugese (though not the other way round). Finally, let's assume
Portugese is a lot stricter concerning grammatical constructs; some
sentences that are legal Spanish but often lead to problems are
incorrect in Portugese.

Now we have a valid metaphor. I'm advocating that, if you try to write
problem-free Spanish, using both machines instead of just the Spanish
one can be of help.
If one prefers C++ over C for certain reasons, why not write C++ in the
first place, instead of breeding a chimera that's neither idiomatic C
nor idiomatic C++.
I would kindly refer you to my reply to Cody's questions of 5 october. I
prefer C for many reasons, but I also recognise that C++ aims to fix
some problems in C. I'm aiming for the 'best of both worlds' approach.
Having one's C program compilable by a C++-compiler also helps, since
this can sometimes flag potential problems in the C code that are not
noticed by a C compiler.

Can you please eloborate on this?


Example:

#include <stdio.h>
#include <assert.h>
#include <stdlib.h>

enum EType {
a,b,c
};

void f(enum EType x)
{
switch(x)
{
case a: printf("a\n"); break;
case b: printf("b\n"); break;
case c: printf("c\n"); break;
default: printf("yikes!\ n"); exit(1); break;
}
}

int main(void)
{
f(b);
f(1); /* uncasted call */
return 0;
}

This is a perfectly legal C program as far as I can tell, and it's
illegal in C++ due to the attempt to implicitly casting 1 to EType.

I think C++ is right to flag this as erroneous, and require a cast.


Hm, "right" depends of ones POV in this case. The C standard does not
require a diagnostic, so it is wrong? I don't think so.


It's not wrong from the C standard's point-of-view, but then I feel the
C standard is wrong in this respect. The rationale for allowing implicit
int-to-enum conversion at the time was undoubtedly the desire to not
break existing code, but as far as I am concerned the time has come to
leave this behind for new code.
AFAIK now it is possible to write code that compiles fine, but has
different semantics when compiled as C or C++ respectively.


Sure it is possible. I am, however, advocating writing code that
complies with the intersection of C and C++, and works as intended. You
are coming perilously close to putting up a strawman here.

Am I? Then please tell me where the common subset of C and C++ is
defined, so I have something to make my code comply to, just in case I
want to code the same way you do; is it different for C89 compared to
C99? Please give a reference.


What's so strange about the concept of the intersection of two related
languages for which standards exists? Now I'm quite willing to explain
what an intersection is and to provide pointers to the relevant
standards, but you will first have to explain to me what's so hard to
understand :-)
Now who was how close to putting up a strawman? ;-P
I think you were (I'm trying hard to avoid it), but I am happy to see
that we can resolve this without erecting, much less burning, any straw
men.
Regards, and have a nice weekend.


You too. I mean, what could be more fun than arguing coding style on
Saturday evening!

Sidney Cadot

Nov 13 '05 #274
"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote in message
news:Pi******** *************** ************@un ix42.andrew.cmu .edu...
Actually, casting the result of malloc() is *good*
programming practice, because it verifies that you
are assigning the result to the pointer-type that
you expect of the target variable.
That's just silly.


I don't mind your having your own style, but I do bridle at your
cavalier dismissal of a different one. You're just being parochial
and short sighted (if you enjoy name calling).
You, as the programmer, already *know* the type
of the target object, correct?
Not for long. Over time, there can be drift between the type of the
object you're trying to allocate and the type of the pointer object
where you want to store the address of the allocation. Once you get
in the habit of maintaining code that's decades old, you learn
where best to take out insurance. (Hint: insurance against a failure
to include <stdlib.h> is pretty short term, by comparison.)
And besides, well-written (i.e.,
idiomatic for c.l.c) malloc calls don't require *any* type information,
correct *or* incorrect -- it lets the compiler handle all the type
information by itself.
I agree you don't have to write the cast -- we did that intentionally,
for backward compatibility, when we added void * to Standard C. I
disagree that omitting the cast automatically makes for well written
code. That's just one idiom, not always the best one in all
circumstances.
Which of the following is most likely to
do the right thing, given that the type of 'p' might be hard to
remember?

extern Gronk *p;

p = (Gronk *) malloc(sizeof (Gronk));
p = (Gronk *) malloc(sizeof *p);
p = malloc(sizeof (Gronk));
p = malloc(sizeof *p);
(Hint: the last one.)
None of the above. I strongly prefer:

p = (Gronk *) malloc(N * sizeof (Gronk));

even when N is an explicit 1. (Though I do eliminate the sizeof
when the type is demonstrably a char type.)
fubar = (Gronk *) malloc(whatever _size_you_want) ;


Where 'whatever_size_ you_want' is an integral multiple of
sizeof *fubar, sure.


Sure? How can you be sure when reviewing the code after some
other maintainer has fiddled with the declaration of Gronk?
How much searching will it take you to become sure again? And
what if you decide to just trust that the size is properly
constrained?
But in that case, why bother with the
cast?
To spend less time hunting bugs during maintenance?
This verifies that "fubar" is declared as a
pointer type to whatever Gronk is. If the
type of "fubar" is not (Gronk *), then the
compiler will complain about the pointer conversion.
The explicit cast clearly documents your intention
and allows the compiler to verify it.


True, but IMO not nearly as strong an argument as the "clarity,
brevity, and <stdlib.h> warning" arguments given by proponents
of the idiomatic (non-cast) style.


Fine, that's just YO. Doesn't make everybody else silly.
OTOH, without the explicit cast, the compiler
will happily assign the (void*) result to fubar and
you won't know that you did something wrong. (Perhaps
you are assigning the result to the wrong variable?)


Do you commonly write code in which two pointers to different
types are in scope at the same time?


Yep, all the time.
Unless you write compilers
for a living (which IMVLE often have pointers to symbol tables and
other things co-existing), I can't think of any context in which

Foo *my_foo;
Bar *my_bar;

my_bar = malloc(sizeof *my_foo);

could ever happen as a legitimate typo/error. And even if it
*did* happen, it's a fairly easy bug to find, especially now that
the code is made less cluttered by the removal of all those
spurious casts. Or did you have some other context in mind?


Glad you think so. I'm a firm believer in natural selection.
Finding burps like this at compile time is far more preferable
than tracking down runtime errors.

2 cents worth. Your mileage may vary.


MMDIV, as they say. You write a program with malloc casting that
you think will lose clarity or robustness by their removal, and I will
personally re-write the malloc-casting code to become clearer without
loss of robustness.


Feel free. FWIW, I used your style for over 20 years, including a decade
after I added void * to my compiler. Then one day, about ten years ago,
I sat down and added casts to every blessed malloc call in my living code
base. And I've never been sorry. A more curious person might wonder why.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 13 '05 #275
"Irrwahn Grausewitz" <ir*******@free net.de> wrote in message
news:v1******** *************** *********@4ax.c om...
1. You don't need the cast in C. If you have to cast (e.g. to shut up
a compiler warning) you most probably try to do something dangerous.
There are circumstances where it is really needed of course, mostly in
low-level programming, and reading binary data formats.


The special cases are the reason why I said "most probably" and not
"certainly" . However, low-level code is unlikely to be pure portable
ISO-C anyway.


Gee, I just counted a couple of hundred casts in our C code, which runs
on a dozen or more platforms. I'd estimate that only a few per cent of
them could safely be removed, including the malloc ones. I agree that
casts can be dangerous, so I only write them when I think they serve
a good purpose. In the cases I just counted, almost all are needed to
*ensure* portability. Go figure.
Casting is bad
if you just do it to shut down a compiler warning (I've assisted with
programming practicals at university, for novices this seems to be the
#1 reason to use casts), so you really have to understand what you're doing.


We both agree on this.


I'd like to agree, but we also add casts to our code to silence compiler
warnings that are silly. (Why do some compilers complain about -x, where
x is unsigned, but say nothing about 0-x?) Our customers do *not* want
warning messages from our code, no matter how much we assure them that
we know what we're doing.
Implicit conversions to/from pointer-to-void from/to any other
pointer-to-<type> are explicitly permitted in C.


I think that is a mistake, and I am not going to drop casts that are not
needed just because the standard allows me to.


If you think that C99 6.3.2.3 is a mistake, you should submit a DR or a
proposal to the standards comittee. ;-)


You may not like it, but it *was* intentional.
.....

One has to weigh freedom against restriction. ;-)
If one prefers C++ over C for certain reasons, why not write C++ in the
first place, instead of breeding a chimera that's neither idiomatic C
nor idiomatic C++.
Because it's idiomatic common subset, and superior for both purposes?
.....
AFAIK now it is possible to write code that compiles fine, but has
different semantics when compiled as C or C++ respectively.


Sure it is possible. I am, however, advocating writing code that
complies with the intersection of C and C++, and works as intended. You
are coming perilously close to putting up a strawman here.


Am I? Then please tell me where the common subset of C and C++ is
defined, so I have something to make my code comply to, just in case I
want to code the same way you do; is it different for C89 compared to
C99? Please give a reference. Now who was how close to putting up a
strawman? ;-P


You are. You don't want to code in the common subset, don't. If you want
to learn how to write code that works the same way when compiled as C89,
C99, and C++, it ain't that hard. I feel no obligation to help educate
you, however.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 13 '05 #276
Sidney Cadot wrote:
CBFalconer wrote:
> [[ casting malloc() results ]]
Why is it considered "bad practice"? I know it is frowned upon
sometimes, but I fail to see the rationale for that.

One advantage of casting malloc() results is that, like you say,
one has a fighting chance of getting a clean (error/warning-less)
compile using C++ in addition to getting a clean compile in C.

It can hide errors that the compiler could otherwise pick up. It
prevents controlling the type of that object in only one place,
and having all other code slaved to that.


Could you provide examples? I'm sure there are, but it's a lot easier to
discuss this over an example for me.


typedef struct foo {
....
} foo, *foop;
.....
foop barp;
.....
barp = malloc(count * sizeof *barp)

(which you can handle slighly differently if you don't approve of
typedefing structures.) At any rate, I can control what a foo (and
a foop) is in just one place, without needing to alter any other
code. I can also hide that definition in one module and export
only the foop type by slight changes in the declaration method.
Again, the rest of the code does not change.
Casts are fundamentally evil things, and very often serve only to
conceal errors.
'fundamentally evil things' ... that's a bit harsh isn't it?

It would make an interesting exercise to write low-level C code (e.g.,
kernels or device drivers), without casts. Are you suggesting this is
practical?


Certainly there are places where casts are needed. But they
should never be used without a clear understanding of their
purpose. "shutting up compiler complaints" is not a valid
reason. Code written without casts is much more likely to be
bugfree.
I have yet to see a C++ compiler that does not have a C mode, and
there is no problem linking C++ code with C code when the headers
are properly designed.


Sure, but I want to write C code, but sometimes compile the program with
a C++ compiler to use the extra checks as required by a C++ compiler,
for flagging potential problems - is that so strange?


That is what lint, pclint, splint (nee lclint) are for. splint is
also free. They are all much more picky than some nebulous C++
compiler, which is written for a different standard.

Please do not strip attributions for quoted material. I think you
stripped yourself in this case, but am not sure.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

Nov 13 '05 #277
"xarax" <xa***@email.co m> wrote:
"Sidney Cadot" <si****@jigsaw. nl> wrote in message
news:bm******* ***@news.tudelf t.nl...
Hi Irrwahn,
>>> [[casting malloc() result to target type]]
>>
>>Why is it considered "bad practice"? I know it is frowned upon
>>sometimes, but I fail to see the rationale for that.
>
>
> 1. You don't need the cast in C. If you have to cast (e.g. to shut up
> a compiler warning) you most probably try to do something dangerous.
/snip/

Actually, casting the result of malloc() is *good*
programming practice, because it verifies that you
are assigning the result to the pointer-type that
you expect of the target variable.


And it's unnecessary, can hide errors and reduces the maintainability of
the code.
fubar = (Gronk *) malloc(whatever _size_you_want) ;
This verifies that "fubar" is declared as a
pointer type to whatever Gronk is.
But what tells you that Gronk * is the correct type for fubar to have?
And if you change the type of foobar you have to go through your code
and change the malloc calls. Why tell the Compiler something it already
knows? BTW: whatever_size_y ou_want seems to neither be related to
sizeof(Gronk) nor to sizeof *fubar.

IMO

fubar = malloc( desired_number * sizeof *fubar );

is much clearer.
If the
type of "fubar" is not (Gronk *), then the
compiler will complain about the pointer conversion.
The explicit cast clearly documents your intention
and allows the compiler to verify it.
That's a small benefit compared to the tradeoffs.
OTOH, without the explicit cast, the compiler
will happily assign the (void*) result to fubar and
you won't know that you did something wrong. (Perhaps
you are assigning the result to the wrong variable?)
Finding burps like this at compile time is far more preferable
than tracking down runtime errors.
Well, consequently you should cast _any_ assignment then. What a mess.
2 cents worth. Your mileage may vary.


My 2ct:
A compiler is not a suitable weapon against lapse of reason. ;-)

Regards
--
Irrwahn
(ir*******@free net.de)
Nov 13 '05 #278
On Sat, 18 Oct 2003 09:27:07 +0000 (UTC), th*@cs.ucr.edu wrote:
C and C++ have a relatively large semantic intersection, i.e., set of
programs to which C and C++ attach identical behavior.
The one does not follow from the other.
It's my
impession that the intersecton includes the majority of actual C
programs.


#define true (1/(sizeof 'a' - 1))
--
#include <standard.discl aimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list
Nov 13 '05 #279
CBFalconer wrote:
Sidney Cadot wrote:
CBFalconer wrote:
> [[ casting malloc() results ]]
Why is it considered "bad practice"? I know it is frowned upon
sometimes , but I fail to see the rationale for that.

One advantage of casting malloc() results is that, like you say,
one has a fighting chance of getting a clean (error/warning-less)
compile using C++ in addition to getting a clean compile in C.

It can hide errors that the compiler could otherwise pick up. It
prevents controlling the type of that object in only one place,
and having all other code slaved to that.


Could you provide examples? I'm sure there are, but it's a lot easier to
discuss this over an example for me.

typedef struct foo {
....
} foo, *foop;
....
foop barp;
....
barp = malloc(count * sizeof *barp)

(which you can handle slighly differently if you don't approve of
typedefing structures.) At any rate, I can control what a foo (and
a foop) is in just one place, without needing to alter any other
code. I can also hide that definition in one module and export
only the foop type by slight changes in the declaration method.
Again, the rest of the code does not change.


How does all this keep you from writing this:

{
foop barp;
barp = (foop)malloc(co unt * sizeof *barp);
}

Only a name change of foop would be a slight hassle I think? I don't
quite see what changing the definition of the foo struct has to do with
casting the malloc result.
Casts are fundamentally evil things, and very often serve only to
conceal errors.


'fundamentall y evil things' ... that's a bit harsh isn't it?

It would make an interesting exercise to write low-level C code (e.g.,
kernels or device drivers), without casts. Are you suggesting this is
practical?

Certainly there are places where casts are needed. But they
should never be used without a clear understanding of their
purpose. "shutting up compiler complaints" is not a valid
reason.


I agree insofar as that a compiler warning is an indication (symptom) of
an actual or potential problem, and that you should take care to solve
the problem instead of just curing the symptom.

As to whether "shutting up compiler complaints" is not a valid reason,
ever, I would hesitate to make this a dogma.
Code written without casts is much more likely to be bugfree.
Sure, but that's also in large part because the type of code that really
*needs* casts tends to solve complicated problems.
I have yet to see a C++ compiler that does not have a C mode, and
there is no problem linking C++ code with C code when the headers
are properly designed.


Sure, but I want to write C code, but sometimes compile the program with
a C++ compiler to use the extra checks as required by a C++ compiler,
for flagging potential problems - is that so strange?


That is what lint, pclint, splint (nee lclint) are for. splint is
also free. They are all much more picky than some nebulous C++
compiler, which is written for a different standard.


What's so nebulous about a C++ compiler? These pick up some of my
mistakes that a C compiler misses, it works for me. I'm sure the *lints
are nice tools as well. Have heard some good and bad things about them,
must try for myself one of these days.

As long as they have a flag for not complaining about malloc result
casts ... ;-)
Please do not strip attributions for quoted material. I think you
stripped yourself in this case, but am not sure.


Sorry about that.

Best regards,

Sidney Cadot

Nov 13 '05 #280

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

Similar topics

3
11266
by: William C. White | last post by:
Does anyone know of a way to use PHP /w Authorize.net AIM without using cURL? Our website is hosted on a shared drive and the webhost company doesn't installed additional software (such as cURL) on the server because of that. Our site will have an SSL certificate next week, so I would like to use AIM instead of SIM, however, I don't know how to send data via POST over https and recieve data from the Authorize.net server over an https...
2
5865
by: Albert Ahtenberg | last post by:
Hello, I don't know if it is only me but I was sure that header("Location:url") redirects the browser instantly to URL, or at least stops the execution of the code. But appearantely it continues to execute the code until the browser send his reply to the header instruction. So an exit(); after each redirection won't hurt at all
3
23053
by: James | last post by:
Hi, I have a form with 2 fields. 'A' 'B' The user completes one of the fields and the form is submitted. On the results page I want to run a query, but this will change subject to which field is completed.
0
8508
by: Ollivier Robert | last post by:
Hello, I'm trying to link PHP with Oracle 9.2.0/OCI8 with gcc 3.2.3 on a Solaris9 system. The link succeeds but everytime I try to run php, I get a SEGV from inside the libcnltsh.so library. 354 roberto@ausone:Build/php-4.3.2> ldd /opt/php4/bin/php libsablot.so.0 => /usr/local/lib/libsablot.so.0 libstdc++.so.5 => /usr/local/lib/libstdc++.so.5 libm.so.1 => /usr/lib/libm.so.1
1
8621
by: Richard Galli | last post by:
I want viewers to compare state laws on a single subject. Imagine a three-column table with a drop-down box on the top. A viewer selects a state from the list, and that state's text fills the column below. The viewer can select states from the drop down lists above the other two columns as well. If the viewer selects only one, only one column fills. If the viewer selects two states, two columns fill. Etc. I could, if appropriate, have...
4
18317
by: Albert Ahtenberg | last post by:
Hello, I have two questions. 1. When the user presses the back button and returns to a form he filled the form is reseted. How do I leave there the values he inserted? 2. When the user comes back to a page where he had a submitted POST data the browser keeps telling that the data has expired and asks if repost. How to avoid that? I tried registering all POST and GET vars as SESSION vars but
1
6890
by: inderjit S Gabrie | last post by:
Hi all Here is the scenerio ...is it possibly to do this... i am getting valid course dates output on to a web which i have designed ....all is okay so far , look at the following web url http://www.mis.gla.ac.uk/biquery/training/ but each of the courses held have maximum of 8 people that could be
2
31461
by: Jack | last post by:
Hi All, What is the PHP equivilent of Oracle bind variables in a SQL statement, e.g. select x from y where z=:parameter Which in asp/jsp would be followed by some statements to bind a value to :parameter I dont like the idea of making the SQL statement on the fly without binding parameters as I dont want a highly polluted SQL cache.
3
23617
by: Sandwick | last post by:
I am trying to change the size of a drawing so they are all 3x3. the script below is what i was trying to use to cut it in half ... I get errors. I can display the normal picture but not the results of the picture half the size. The PHP I have installed support 1.62 or higher. And all I would like to do is take and image and make it fit a 3x3. Any suggestions to where I should read or look would be appreciated.
0
9791
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 effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10742
jinu1996
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10410
tracyyun
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 protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9571
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7970
isladogs
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 presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7122
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5797
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 last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5990
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4609
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 we have to send another system

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.