I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
In a C++ program, we can use standard C libraries. However, we cannot
use C++ libraries inside C program.
Please advise. thanks!!
50  2027  st******@gmail.com wrote: I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
No.
void template()
{
}
int main()
{
template();
}
is a valid C, but invalid C++. Check your favorite textbook (you do
have one, don't you?) or google for more informations on C and C++
incompatibilities.
In a C++ program, we can use standard C libraries. However, we cannot
use C++ libraries inside C program.
It depends on what you call a "C++ library".
extern "C"
{
void f();
}
Is this a "C++ library"? If yes, then a C program can use some C++
libraries. Your question is too vague.
Jonathan
In comp.lang.c++ st******@gmail.com wrote: I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
In most cases, yes, but there are a few cases where this is not true.
For example, if a C program declares identifiers that are now C++
keywords but that are not C keywords. TC++PL has a section on this
topic.
In a C++ program, we can use standard C libraries. However, we cannot
use C++ libraries inside C program.
True.
--
Marcus Kwok
> In comp.lang.c++ st******@gmail.com wrote: In a C++ program, we can use standard C libraries. However, we cannot
use C++ libraries inside C program.
In comp.lang.c++ Marcus Kwok <ri******@gehennom.net> wrote: True.
After reading Jonathan's post, I will amend this to mean the standard
C++ libraries, e.g., the STL.
--
Marcus Kwok
<st******@gmail.com> schrieb im Newsbeitrag
news:11**********************@g14g2000cwa.googlegr oups.com... I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
No. Not every C program is also a valid C++ program. "new", "class" or
"template" to name only a few, are valid identifiers in C, but they are
reserved words in C++. So any C program using one of these identifiers is
not a valid C++ program. Also
void foo();
int main() { foo(1); }
is legal in C, but not in C++
In a C++ program, we can use standard C libraries. However, we cannot
use C++ libraries inside C program.
Just that you can use C libraries in C++ does not imply that C is a subset
of C++. You can also use Pascal or Fortran libraries in C++, but that is no
reason to think that every Pascal or Fortran program is also a C++ program.
Heinz st******@gmail.com a écrit : I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
No, it's not
http://david.tribble.com/text/cdiffs.htm
Unfortunately, this link seems to be down at the moment.
Maybe, more information here :
david at tribble dot com
In a C++ program, we can use standard C libraries. However, we cannot
use C++ libraries inside C program.
Correct.
--
C is a sharp tool st******@gmail.com wrote: I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
It is a grossly erroneous statement. C and C++ are different languages.
There are countless C programs that are not C++ programs.
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:F8****************@newsread3.news.atl.earthli nk.net st******@gmail.com wrote: I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
It is a grossly erroneous statement. C and C++ are different
languages. There are countless C programs that are not C++ programs.
"C++ was developed from the C programming language and, with few exceptions,
retains C as a subset."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., p. 8.
--
John Carson
John Carson wrote: "Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:F8****************@newsread3.news.atl.earthli nk.net
st******@gmail.com wrote:
I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
It is a grossly erroneous statement. C and C++ are different
languages. There are countless C programs that are not C++ programs.
"C++ was developed from the C programming language and, with few
exceptions, retains C as a subset."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., p. 8.
This may have been the intent; however, Martin's statement still is
true as C++ semantics differ from C89 in many points.
C99 introduced enough additional non-trivial differences which cannot
be easily overcome. The C standard does not make any claim w.r.t. C++
compatibility, even though there may be a rationale saying exactly
that. I do not own the C++ standard, so I cannot say anything from
this point of view.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
"Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:3r************@individual.net John Carson wrote: "Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:F8****************@newsread3.news.atl.earthli nk.net
st******@gmail.com wrote:
I want if "a C program is a standard C++ program, but not vice
versa" is a correct statement?
It is a grossly erroneous statement. C and C++ are different
languages. There are countless C programs that are not C++
programs.
"C++ was developed from the C programming language and, with few
exceptions, retains C as a subset."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., p. 8.
This may have been the intent; however, Martin's statement still is
true as C++ semantics differ from C89 in many points.
The statement that "C++ ... with few exceptions retains C as a subset" is
not a statement of intent but a description of the relationship between the
two languages, albeit one that seems to be directed at C89. I quote again:
"With minor exceptions, C++ is a superset of C. Most differences stem from
C++'s greater emphasis on type checking. Well-written C programs tend to be
C++ programs as well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.
C99 introduced enough additional non-trivial differences which cannot
be easily overcome.
That does indeed add to the incompatibility, though there are efforts
underway to bring the two languages closer together, particularly by adding
C99 stuff to C++.
The C standard does not make any claim w.r.t. C++
compatibility, even though there may be a rationale saying exactly
that. I do not own the C++ standard, so I cannot say anything from
this point of view.
Section 1.1/2 of the C++ standard:
"C++ is a general purpose programming language based on the C programming
language as described in ISO/IEC 9899:1990 Programming languages - C (1.2).
In addition to the facilities provided by C, C ++ provides additional data
types, classes, templates, exceptions, namespaces, inline functions,
operator overloading, function name overloading, references, free store
management operators, and additional library facilities."
Annex C (appropriately enough) of the C++ standard deals with the
relationship between C and C++, noting the areas of incompatibility.
--
John Carson
John Carson wrote: "Well-written C programs tend to be C++ programs as well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.
I tend to disagree. In C, dynamic memory is usually allocated with malloc or
other functions that return a pointer to void. That pointer gets converted
implicitly into the target type in C, and a cast should be avoided in a
"well-written C program". However, in C++, it doesn't compile without a
cast. Dynamic memory is something that is used quite often, so I'd say that
most well-written C programs are not C++ programs and would need lots of
changes (in all places where dynamic memory is allocated).
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:dj*************@news.t-online.com John Carson wrote:
"Well-written C programs tend to be C++ programs as well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.
I tend to disagree. In C, dynamic memory is usually allocated with
malloc or other functions that return a pointer to void. That pointer
gets converted implicitly into the target type in C, and a cast
should be avoided in a "well-written C program". However, in C++, it
doesn't compile without a cast. Dynamic memory is something that is
used quite often, so I'd say that most well-written C programs are
not C++ programs and would need lots of changes (in all places where
dynamic memory is allocated).
Your point is covered in the preceding sentence: "Most differences stem from
C++'s greater emphasis on type checking." But I guess that this preceding
sentence somewhat gives the lie to the one that follows, so strictly
speaking you are probably right that "most well-written C programs are not
C++ programs".
I am more sceptical about your claim that they would need "lots of changes".
Well written C programs will hide most of the malloc calls inside
initialization functions --- manual equivalents of constructors --- and the
number of these shouldn't be very large.
--
John Carson
John Carson wrote: "Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:3r************@individual.net
John Carson wrote:
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:F8****************@newsread3.news.atl.earthli nk.net
st******@gmail.com wrote:
> I want if "a C program is a standard C++ program, but not vice
> versa" is a correct statement?
It is a grossly erroneous statement. C and C++ are different
languages. There are countless C programs that are not C++
programs.
"C++ was developed from the C programming language and, with few
exceptions, retains C as a subset."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., p. 8.
This may have been the intent; however, Martin's statement still is
true as C++ semantics differ from C89 in many points.
The statement that "C++ ... with few exceptions retains C as a subset" is
not a statement of intent but a description of the relationship between the
two languages, albeit one that seems to be directed at C89. I quote again:
"With minor exceptions, C++ is a superset of C. Most differences stem from
C++'s greater emphasis on type checking. Well-written C programs tend to be
C++ programs as well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.
Hmmm, my C code tends to look quite different from my C++ code.
Things I find quite acceptable in C are not acceptable in C++
where better solutions to address certain problems exist.
Apart from the different semantics of void* and ambiguities w.r.t.
overloaded functions, there are better ways to perform explicit
type conversions in C++ than the good old C-style cast. C99 introduced enough additional non-trivial differences which cannot
be easily overcome.
That does indeed add to the incompatibility, though there are efforts
underway to bring the two languages closer together, particularly by adding
C99 stuff to C++.
Yes, AFAIR there were a couple of good articles by B.Stroustrup in CUJ
about the areas where this is easily possible and where in his opinion,
either C++ or C should change semantics. They may still be available
online. The C standard does not make any claim w.r.t. C++
compatibility, even though there may be a rationale saying exactly
that. I do not own the C++ standard, so I cannot say anything from
this point of view.
Section 1.1/2 of the C++ standard:
"C++ is a general purpose programming language based on the C programming
language as described in ISO/IEC 9899:1990 Programming languages - C (1.2).
In addition to the facilities provided by C, C ++ provides additional data
types, classes, templates, exceptions, namespaces, inline functions,
operator overloading, function name overloading, references, free store
management operators, and additional library facilities."
Annex C (appropriately enough) of the C++ standard deals with the
relationship between C and C++, noting the areas of incompatibility.
Thank you for the information :-)
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
<st******@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com... I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
In a C++ program, we can use standard C libraries.
No we can't
extern "C"{
void strcpy(char* restrict , const char* restrict);
}
Standard C++ compiler should spit error.
Only non standard C++ compiler with appropriate
extensions can use standard C libraries.
However, we cannot use C++ libraries inside C program.
Yes we can
extern "C" void myfunc(int){ MyClass o; } // defines C function
// that can be called from C
Greetings, Bane.
"Branimir Maksimovic" <bm***@eunet.yu> wrote in message
news:dj**********@news.eunet.yu...
<st******@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
In a C++ program, we can use standard C libraries.
No we can't
extern "C"{
void strcpy(char* restrict , const char* restrict);
void strcpy(char* restrict to, const char* restrict from); }
Standard C++ compiler should spit error.
Worse, if there are no variables it can interpret "restrict" as parameter
name
instead of type qualifier :)
Only non standard C++ compiler with appropriate
extensions can use standard C libraries.
Michael Mair <Mi**********@invalid.invalid> writes: John Carson wrote:
[...] The statement that "C++ ... with few exceptions retains C as a
subset" is not a statement of intent but a description of the
relationship between the two languages, albeit one that seems to be
directed at C89. I quote again: "With minor exceptions, C++ is a
superset of C. Most differences stem from C++'s greater emphasis on
type checking. Well-written C programs tend to be C++ programs as
well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.
Hmmm, my C code tends to look quite different from my C++ code.
Things I find quite acceptable in C are not acceptable in C++
where better solutions to address certain problems exist.
Apart from the different semantics of void* and ambiguities w.r.t.
overloaded functions, there are better ways to perform explicit
type conversions in C++ than the good old C-style cast.
Stroustrup's statement is that well-written C programs tend to be C++
programs, not that well-written C programs tend to be *well-written*
C++ programs.
The former statement is basically true apart from the issue of casting
the result of malloc(). The latter is not.
--
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.
"Branimir Maksimovic" <bm***@eunet.yu> writes: <st******@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
In a C++ program, we can use standard C libraries.
No we can't
extern "C"{
void strcpy(char* restrict , const char* restrict);
}
Standard C++ compiler should spit error.
Only non standard C++ compiler with appropriate
extensions can use standard C libraries.
Presumably a header intended to be used by both C and C++ compilers
could have
#ifdef __cplusplus
#define restrict
#endif
--
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.
John Carson wrote: "With minor exceptions, C++ is a superset of C. Most differences stem from
C++'s greater emphasis on type checking. Well-written C programs tend to be
C++ programs as well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.
This is an example of why one should *not* cite Stroustrup as an
authority on this issue. He is obviously an authority on C++, but the
fact is that well-written C programs tend to be uncompilable as C++.
Best C practice is often illegal in C++. Remember that BS has a horse
in this race.
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... "Branimir Maksimovic" <bm***@eunet.yu> writes: <st******@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
In a C++ program, we can use standard C libraries.
No we can't
extern "C"{
void strcpy(char* restrict , const char* restrict);
}
Standard C++ compiler should spit error.
Only non standard C++ compiler with appropriate
extensions can use standard C libraries.
Presumably a header intended to be used by both C and C++ compilers
could have
#ifdef __cplusplus
#define restrict
#endif
This can be dangerous. restrict type qualifier has specific meaning to C
compiler,
and does not mean anything to C++ compiler, so C++ calling C function with
such parameter can lead to undefined behavior,
therefore it is better to live that as it is.
Greetings, Bane.
Martin Ambuhl <ma*****@earthlink.net> writes: John Carson wrote: "With minor exceptions, C++ is a superset of C. Most differences stem from
C++'s greater emphasis on type checking. Well-written C programs tend to be
C++ programs as well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.
This is an example of why one should *not* cite Stroustrup as an
authority on this issue. He is obviously an authority on C++, but the
fact is that well-written C programs tend to be uncompilable as
C++. Best C practice is often illegal in C++. Remember that BS has a
horse in this race.
The obvious exception to Stroustrup's statement is casting the result
of malloc() (and realloc()). A well-written C program is likely to
call malloc() and assign the result, without a cast, to a pointer
object of a type other than void*; this is illegal in C++.
Are there other significant exceptions? Let's limit the discussion to
well-written C90 programs.
For example, C++ has several additional keywords, but most C programs
aren't going to happen to use them as identifiers; they provide a
counterexample to any claim that C is a strict subset of C++, but not
to Stroustrup's statement.
Character literals are of type char in C++ and of type int in C, but
I've never seen any programs that depend on this difference other than
ones specifically written to demonstrate it.
So, did you have anything in mind other than casting malloc() that
would cause a typical well-written C program not to be valid C++?
--
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.
"Branimir Maksimovic" <bm***@eunet.yu> writes: "Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
[...] Presumably a header intended to be used by both C and C++ compilers
could have
#ifdef __cplusplus
#define restrict
#endif
This can be dangerous. restrict type qualifier has specific meaning to C
compiler,
and does not mean anything to C++ compiler, so C++ calling C function with
such parameter can lead to undefined behavior,
therefore it is better to live that as it is.
C99 6.7.3p7 says:
An object that is accessed through a restrict-qualified pointer
has a special association with that pointer. This association,
defined in 6.7.3.1 below, requires that all accesses to that
object use, directly or indirectly, the value of that particular
pointer. The intended use of the restrict qualifier (like the
register storage class) is to promote optimization, and deleting
all instances of the qualifier from all preprocessing translation
units composing a conforming program does not change its meaning
(i.e., observable behavior).
Though I suppose there might be problems if "restrict" is removed from
the caller but not from the implementation of the function.
--
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.
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... "Branimir Maksimovic" <bm***@eunet.yu> writes: "Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
[...] Presumably a header intended to be used by both C and C++ compilers
could have
#ifdef __cplusplus
#define restrict
#endif
This can be dangerous. restrict type qualifier has specific meaning to C
compiler,
and does not mean anything to C++ compiler, so C++ calling C function
with
such parameter can lead to undefined behavior,
therefore it is better to live that as it is.
C99 6.7.3p7 says:
An object that is accessed through a restrict-qualified pointer
has a special association with that pointer. This association,
defined in 6.7.3.1 below, requires that all accesses to that
object use, directly or indirectly, the value of that particular
pointer. The intended use of the restrict qualifier (like the
register storage class) is to promote optimization, and deleting
all instances of the qualifier from all preprocessing translation
units composing a conforming program does not change its meaning
(i.e., observable behavior).
Though I suppose there might be problems if "restrict" is removed from
the caller but not from the implementation of the function.
For the sake of compatibility and good behavior of code it would
be better to remove "restrict" from all C standard library functions.
Greetings, Bane.
In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> wrote:
[snippage] Are there other significant exceptions? Let's limit the discussion to
well-written C90 programs.
[snippage]So, did you have anything in mind other than casting malloc() that
would cause a typical well-written C program not to be valid C++?
One might argue whether this is "well-written", but I have had
C vs C++ scope issues bite, in real C code that someone attempted
to include part of in a C++ program.
The example I like to use is:
% cat t.c
#include <stdio.h>
struct A { int x[1]; };
int main(void) {
struct B { struct A { int x[1000]; } b; } var;
printf("sizeof(struct A) = %lu\n",
(unsigned long)sizeof(struct A));
return 0;
}
% ln t.c t.c++
% cc -o t t.c
% ./t
sizeof(struct A) = 4000
% cc -o t t.c++
% ./t
sizeof(struct A) = 4
%
This is not the same as the original example (which was of course
much more complicated), but it does demonstrate that C and C++ are
wildly different languages. :-)
(OK, one might also argue that it is not "typical" either. It is
true that collisions on structure names are relatively rare, and
it is probably even more rare to have them matter in this way.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Branimir Maksimovic wrote: For the sake of compatibility and good behavior of code it would
be better to remove "restrict" from all C standard library functions.
For the sake of compatibility and good behavior of code it would
be better to insist that C++ incorporate "restrict" and use it for all
C++ standard library functions where it is appropriate. But C++
chauvinists who believe in bloated languages and obfuscated code will
differ.
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:BS*****************@newsread3.news.atl.earthl ink.net... Branimir Maksimovic wrote:
For the sake of compatibility and good behavior of code it would
be better to remove "restrict" from all C standard library functions.
For the sake of compatibility and good behavior of code it would
be better to insist that C++ incorporate "restrict" and use it for all
C++ standard library functions where it is appropriate. But C++
chauvinists who believe in bloated languages and obfuscated code will
differ.
Agreed!
Greetings, Bane.
On 2005-10-22, Keith Thompson <ks***@mib.org> wrote: John Carson wrote: "With minor exceptions, C++ is a superset of C. Most differences stem from
C++'s greater emphasis on type checking. Well-written C programs tend to be
C++ programs as well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.
[...]
For example, C++ has several additional keywords, but most C programs
aren't going to happen to use them as identifiers; [...]
That reminds me of the Unix functions mktemp()/mkstemp(), which take a
template string argument from which they build a unique file name. Most
Unix manual pages, as well as the POSIX/UNIX standards themselves (which
are ignorant of C++), call the prototypes parameter declaration
``template'' (a C++ keyword):
int mkstemp(char *template);
.... which may be the reason why I've run into problems by calling the
character array I passed to mkstemp() ``template'' in C++ code as well
:-)
``new'' and ``class'' are also identifiers I would expect to see in many
C programs written by people unaware of C++ (or by c.l.c. citizens who
use them deliberately to introduce incompatibilities because they
dislike the whole compatibility debate so much), but I agree that it's a
minor problem when porting C programs to C++.
Martin Ambuhl wrote: Branimir Maksimovic wrote:
For the sake of compatibility and good behavior of code it would
be better to remove "restrict" from all C standard library functions.
For the sake of compatibility and good behavior of code it would
be better to insist that C++ incorporate "restrict" and use it for all
C++ standard library functions where it is appropriate. But C++
chauvinists who believe in bloated languages and obfuscated code will
differ.
Several of the more popular implementations of C++ do implement a form
of restrict as an extension, in a different way for each compiler. I
fail to see, though, how this solves the bloat and obfuscation problem.
Keith Thompson wrote: Michael Mair <Mi**********@invalid.invalid> writes:
John Carson wrote:
[...]
The statement that "C++ ... with few exceptions retains C as a
subset" is not a statement of intent but a description of the
relationship between the two languages, albeit one that seems to be
directed at C89. I quote again: "With minor exceptions, C++ is a
superset of C. Most differences stem from C++'s greater emphasis on
type checking. Well-written C programs tend to be C++ programs as
well."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., Appendix B,
Compatibility, p. 816.
Hmmm, my C code tends to look quite different from my C++ code.
Things I find quite acceptable in C are not acceptable in C++
where better solutions to address certain problems exist.
Apart from the different semantics of void* and ambiguities w.r.t.
overloaded functions, there are better ways to perform explicit
type conversions in C++ than the good old C-style cast.
Stroustrup's statement is that well-written C programs tend to be C++
programs, not that well-written C programs tend to be *well-written*
C++ programs.
The former statement is basically true apart from the issue of casting
the result of malloc(). The latter is not.
I see. Thanks for the pointer (no pun intended).
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
In article <dj***********@otis.netspace.net.au>, "John Carson" <jc****************@netspace.net.au> writes: "Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:F8****************@newsread3.news.atl.earthli nk.net
It is a grossly erroneous statement. C and C++ are different
languages. There are countless C programs that are not C++ programs.
"C++ was developed from the C programming language and, with few exceptions,
retains C as a subset."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., p. 8.
If you'd bothered to check, you'd see that this has been introduced
as an argument in this debate countless times (pretty much every time
the question has been raised), and someone has invariably pointed out
that it is in no way a satisfactory argument that C and C++ are not
different languages.
There are certainly those, including Stroustrop, who feel that C++ is
"mostly" a superset of C (whatever that might mean). And there are
many of us who do not. Appeals to authority in this case carry no
weight with us, unless that authority is ISO.
--
Michael Wojcik mi************@microfocus.com
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote: "Branimir Maksimovic" <bm***@eunet.yu> writes: "Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
[...] Presumably a header intended to be used by both C and C++ compilers
could have
#ifdef __cplusplus
#define restrict
#endif
This can be dangerous. restrict type qualifier has specific meaning to C
compiler,
and does not mean anything to C++ compiler, so C++ calling C function with
such parameter can lead to undefined behavior,
therefore it is better to live that as it is.
C99 6.7.3p7 says:
An object that is accessed through a restrict-qualified pointer
has a special association with that pointer. This association,
defined in 6.7.3.1 below, requires that all accesses to that
object use, directly or indirectly, the value of that particular
pointer. The intended use of the restrict qualifier (like the
register storage class) is to promote optimization, and deleting
all instances of the qualifier from all preprocessing translation
units composing a conforming program does not change its meaning
(i.e., observable behavior).
Though I suppose there might be problems if "restrict" is removed from
the caller but not from the implementation of the function.
I assume you mean "if 'restrict' is removed from the function prototype,
but not from the implementation of the function".
If your code had defined behavior when both the prototype and the
implementation used "restrict", then it still has defined behavior when
"restrict" is removed from the prototype.
However, there is the danger that you write code that you _believe_ has
defined behavior because the prototype had no "restrict", but has indeed
undefined behavior because the implementation used "restrict".
"Michael Wojcik" <mw*****@newsguy.com> wrote in message
news:dj*********@news1.newsguy.com In article <dj***********@otis.netspace.net.au>, "John Carson"
<jc****************@netspace.net.au> writes: "Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:F8****************@newsread3.news.atl.earthli nk.net
It is a grossly erroneous statement. C and C++ are different
languages. There are countless C programs that are not C++
programs.
"C++ was developed from the C programming language and, with few
exceptions, retains C as a subset."
Bjarne Stroustrup, The C++ Programming Language, 3rd ed., p. 8.
If you'd bothered to check, you'd see that this has been introduced
as an argument in this debate countless times (pretty much every time
the question has been raised), and someone has invariably pointed out
that it is in no way a satisfactory argument that C and C++ are not
different languages.
Of course they are two different languages. Who is disputing it?
There are certainly those, including Stroustrop, who feel that C++ is
"mostly" a superset of C (whatever that might mean). And there are
many of us who do not. Appeals to authority in this case carry no
weight with us, unless that authority is ISO.
The question of whether C++ is "mostly" a superset of C turns on two
matters:
1. Knowledge of the specification of the two languages and hence of the
departures from a strict subset-superset relationship.
2. Judgement of the significance of these departures from a strict
subset-superset relationship.
On 1., I feel on safe grounds in appealing to Stroustrup's authority and any
suggestion that his position is based on an erroneous understanding of the
language specifications is plainly silly.
On 2., it is a matter of judgement and a standards body like ISO is never
going to have anything authoritative to say about it. I believe Stroustrup's
judgement carries a lot of weight. It is plainly not authoritative in a
standards sense, but it is nevertheless at least as worthy of consideration
as any other opinion that one might read in a post to this forum.
--
John Carson
On Sat, 22 Oct 2005 18:02:30 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote: Character literals are of type char in C++ and of type int in C, but
I've never seen any programs that depend on this difference other than
ones specifically written to demonstrate it.
I've seen real-world cases where it made a difference. I fail to
recall the exact example, tho I've a feeling it was I/O related
(something to do with reading sizeof 'a' characters?)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Sun, 23 Oct 2005 10:51:15 +1000, in comp.lang.c , "John Carson"
<jc****************@netspace.net.au> wrote: The question of whether C++ is "mostly" a superset of C turns on two
matters:
1. Knowledge of the specification of the two languages and hence of the
departures from a strict subset-superset relationship.
2. Judgement of the significance of these departures from a strict
subset-superset relationship.
you missed out:
3) The occurence of commonly-used C code which is illegal in C++.
On 1., I feel on safe grounds in appealing to Stroustrup's authority and any
suggestion that his position is based on an erroneous understanding of the
language specifications is plainly silly.
And /I/ feel on safe grounds appealing to the authority of the many
experts in CLC, who disagree with Bjarne on this point. No disrespect
to him, but last time I heard, he was a) not impartial in this debate
and b) not a C expert.
But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Mark McIntyre <ma**********@spamcop.net> writes:
[...] But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.
(referring to C and C++)
I agree. On the other hand, there are rare real-world circumstances
in which it can make sense to program in the *intersection* of the two
languages. Code written in this sub-language can look very similar to
well-written C code, with the most significant difference being
casting the result of malloc().
P.J. Plauger, who produces libraries intended to be used either from C
or from C++, is the only person I know of who really has a good reason
to do this (which isn't to say there aren't others).
--
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.
Keith Thompson wrote: Mark McIntyre <ma**********@spamcop.net> writes:
[...]
But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.
(referring to C and C++)
I agree. On the other hand, there are rare real-world circumstances
in which it can make sense to program in the *intersection* of the two
languages. Code written in this sub-language can look very similar to
well-written C code, with the most significant difference being
casting the result of malloc().
P.J. Plauger, who produces libraries intended to be used either from C
or from C++, is the only person I know of who really has a good reason
to do this (which isn't to say there aren't others).
There are *many* libraries designed to be used either from C or from
C++. Generally they are written in straight C, and the compiled C object
files of the library are linked together with compiled object files of
the user, which could be in any language.
The only part that has to be compiled by both a C compiler and a C++
compiler is the header file, and C++ provides specific constructs to
allow such a thing:
#ifdef __cplusplus
extern "C" {
#endif
/* ... */
#ifdef __cplusplus
}
#endif
This has no effect on a C compiler, which by convention does not define
the __cplusplus macro, but signals to a C++ compiler that the
identifiers declared within are to be linked with a C object file.
--
Simon.
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:oa********************************@4ax.com On Sun, 23 Oct 2005 10:51:15 +1000, in comp.lang.c , "John Carson"
<jc****************@netspace.net.au> wrote:
The question of whether C++ is "mostly" a superset of C turns on two
matters:
1. Knowledge of the specification of the two languages and hence of
the departures from a strict subset-superset relationship.
2. Judgement of the significance of these departures from a strict
subset-superset relationship.
you missed out:
3) The occurence of commonly-used C code which is illegal in C++.
No, it is covered by 1. and 2. If C code is illegal in C++, then that is a
violation of the subset-superset relationship as per 1. How common/important
this is falls under 2.
On 1., I feel on safe grounds in appealing to Stroustrup's authority
and any suggestion that his position is based on an erroneous
understanding of the language specifications is plainly silly.
And /I/ feel on safe grounds appealing to the authority of the many
experts in CLC, who disagree with Bjarne on this point. No disrespect
to him, but last time I heard, he was a) not impartial in this debate
and b) not a C expert.
I will grant you a) but not b). I think Stroustrup knows every last detail
about what C code is not legal C++ code.
But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.
The whole issue of backward compatibility is one of great importance and
heavily influenced the design of C++. And since C continues to be used,
compatibility issues remain of relevance. Largely for this reason, the new
incompatibilities introduced by C99 have caused a lot of debate on whether
C++ should change in order to incorporate many of the changes to C.
--
John Carson
"Simon Biber" <ne**@ralmin.cc> wrote in message
news:43***********************@news.optusnet.com.a u... P.J. Plauger, who produces libraries intended to be used either from C
or from C++, is the only person I know of who really has a good reason
to do this (which isn't to say there aren't others).
There are *many* libraries designed to be used either from C or from C++.
Generally they are written in straight C, and the compiled C object files
of the library are linked together with compiled object files of the user,
which could be in any language.
Right, but in our case we have reason to write C code that also
*compiles* as C++ code. And for that reason, we care about the
largest common subset of the two languages.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
"John Carson" <jc****************@netspace.net.au> wrote in message
news:dj***********@otis.netspace.net.au... But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.
Thanks.
The whole issue of backward compatibility is one of great importance and
heavily influenced the design of C++. And since C continues to be used,
compatibility issues remain of relevance. Largely for this reason, the new
incompatibilities introduced by C99 have caused a lot of debate on whether
C++ should change in order to incorporate many of the changes to C.
And C++ is indeed changing, at least in sensible ways. With TR1,
C++ has picked up *all* the C99 library changes. The language
has picked up all the preprocessor changes, and the evolution
subcommittee has triaged the remaining additions to the language.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
On Mon, 24 Oct 2005 20:53:07 +1000, in comp.lang.c , "John Carson"
<jc****************@netspace.net.au> wrote: "Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:oa********************************@4ax.com And /I/ feel on safe grounds appealing to the authority of the many
experts in CLC, who disagree with Bjarne on this point. No disrespect
to him, but last time I heard, he was a) not impartial in this debate
and b) not a C expert.
I will grant you a) but not b). I think Stroustrup knows every last detail
about what C code is not legal C++ code.
I sincerely doubt that. There's probably no human alive who knows
*every last detail*, and I bet you a pound that Bjarne would be the
first to say that he's not The One.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:do********************************@4ax.com On Mon, 24 Oct 2005 20:53:07 +1000, in comp.lang.c , "John Carson"
<jc****************@netspace.net.au> wrote:
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:oa********************************@4ax.com
And /I/ feel on safe grounds appealing to the authority of the many
experts in CLC, who disagree with Bjarne on this point. No
disrespect to him, but last time I heard, he was a) not impartial
in this debate and b) not a C expert.
I will grant you a) but not b). I think Stroustrup knows every last
detail about what C code is not legal C++ code.
I sincerely doubt that. There's probably no human alive who knows
*every last detail*, and I bet you a pound that Bjarne would be the
first to say that he's not The One.
They are listed in Annex C of the C++ standard. If you think they have
missed one, I am sure the C++ standards committee would be grateful to have
it drawn to their attention.
The more substantial point in the context of this discussion is that a lack
of technical expertise in C on Stroustrup's part is *not* the explanation
for any disagreement between him and others on the relationship between C
and C++.
--
John Carson
"P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:lY********************@giganews.com "John Carson" <jc****************@netspace.net.au> wrote in message
news:dj***********@otis.netspace.net.au...
But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.
Thanks.
Just to remove any doubt...John Carson did not write the passage beginning
with "But its a futile debate..." The passage is a quote from Mark McIntyre.
--
John Carson
In article <dj***********@otis.netspace.net.au>,
John Carson <jc****************@netspace.net.au> wrote: "P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:lY********************@giganews.com "John Carson" <jc****************@netspace.net.au> wrote in message
news:dj***********@otis.netspace.net.au...
But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer.
Thanks.
Just to remove any doubt...John Carson did not write the passage beginning
with "But its a futile debate..." The passage is a quote from Mark McIntyre.
Just to remove any doubt... Kenny McCormack did not write any of the
passages above. They are all quotes from various other people.
(Yes, John, we all understand multi-level quoting)
>>> "John Carson" <jc****************@netspace.net.au> wrote in message news:dj***********@otis.netspace.net.au...
> But its a futile debate - whether they're sub or supersets of each
> other is irrelevant, they're functionalyl quite different languages
> and anyone who treats either one as a subset of the other is a Bad
> Programmer.
"P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:lY********************@giganews.com Thanks.
In article <dj***********@otis.netspace.net.au>,
John Carson <jc****************@netspace.net.au> wrote:Just to remove any doubt...John Carson did not write the passage beginning
with "But its a futile debate..." The passage is a quote from Mark McIntyre.
In comp.lang.c++ Kenny McCormack <ga*****@yin.interaccess.com> wrote: Just to remove any doubt... Kenny McCormack did not write any of the
passages above. They are all quotes from various other people.
(Yes, John, we all understand multi-level quoting)
The problem is that the attribution was snipped.
--
Marcus Kwok
In article <dj**********@news-int.gatech.edu>,
.... The problem is that the attribution was snipped.
There was no problem. John was just being a d*ck.
(As am I...)
"Kenny McCormack" <ga*****@yin.interaccess.com> wrote in message
news:dj**********@yin.interaccess.com In article <dj**********@news-int.gatech.edu>,
... The problem is that the attribution was snipped.
There was no problem. John was just being a d*ck.
(As am I...)
The problem was as Marcus Kwok stated: the attribution was snipped (just as
you have snipped the attribution of his statement). Multiple indentation, by
itself, does not suffice to identify the author.
I won't dignify the rest of your post with comment.
--
John Carson
On Tue, 25 Oct 2005 09:04:44 +1000, in comp.lang.c , "John Carson"
<jc****************@netspace.net.au> wrote: "Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:do********************************@4ax.com
I sincerely doubt that. There's probably no human alive who knows
*every last detail*, and I bet you a pound that Bjarne would be the
first to say that he's not The One.
They are listed in Annex C of the C++ standard.
Annex C (which is informative by the way, meaning its not part of the
Standard itself, and should not be considered as 'gospel') lists the
differences between C and C++, as of C89. Perhaps there's been a TC to
update that section, but otherwise its incorrect.
And I don't think that any unbiassed observer could read that section
and still claim that C was a subset of C++.
The more substantial point in the context of this discussion is that a lack
of technical expertise in C on Stroustrup's part is *not* the explanation
for any disagreement between him and others on the relationship between C
and C++.
If any C++ guru seriously thinks that C is substantively a subset of
C++, he's mistaken, irrespective of pedigree. A casual read through
Annex C lists a host of incompatibilities which are in common usage.
However given that the quote has been consistently misquoted out of
context, this is pointless discussing further. Perhaps you'd like to
take this to alt.flames?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Wed, 26 Oct 2005 01:16:30 +1000, in comp.lang.c , "John Carson"
<jc****************@netspace.net.au> wrote: The problem was as Marcus Kwok stated: the attribution was snipped (just as
you have snipped the attribution of his statement). Multiple indentation, by
itself, does not suffice to identify the author.
I suspect nobody particularly cared, since what was written was both
correct and noncontrovertial.
Save your ire for times when you're misattributed something offensive
or just plain wrong.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:3k********************************@4ax.com On Wed, 26 Oct 2005 01:16:30 +1000, in comp.lang.c , "John Carson"
<jc****************@netspace.net.au> wrote:
The problem was as Marcus Kwok stated: the attribution was snipped
(just as you have snipped the attribution of his statement).
Multiple indentation, by itself, does not suffice to identify the
author.
I suspect nobody particularly cared, since what was written was both
correct and noncontrovertial.
You are within your rights to claim that
"But its a futile debate - whether they're sub or supersets of each
other is irrelevant, they're functionalyl quite different languages
and anyone who treats either one as a subset of the other is a Bad
Programmer."
is correct. It is remarkable to me that you claim it is not controversial
(unless we are to read subset to mean exact subset, which noone
has been claiming and hence has not been part of the debate, futile or
otherwise).
Save your ire for times when you're misattributed something offensive
or just plain wrong.
P.J. Plauger's response to your comment was to say "Thanks". He may have
meant it. On a second reading, I thought that his intent may have been
ironic based on another of his posts saying:
"Right, but in our case we have reason to write C code that also
*compiles* as C++ code. And for that reason, we care about the
largest common subset of the two languages."
In other words, he may have taken you (or, much worse, me) to have described
him as a Bad Programmer, hence my concern for the accuracy of the
attribution.
This will be my last reply (and I am refraining from responding to your
other post). I agree with you (though for different reasons) that this has
become pointless.
--
John Carson
On Wed, 26 Oct 2005 11:33:54 +1000, in comp.lang.c , "John Carson"
<jc****************@netspace.net.au> wrote: It is remarkable to me that you claim it is not controversial
I can't help what you find remarkable, I'm afraid...
P.J. Plauger's response to your comment was to say "Thanks". He may have
meant it. On a second reading, I thought that his intent may have been
ironic
PJ's company programs to a subset of both C *and* C++, as they need
code that compiles on both platforms.....
based on another of his posts saying:
"Right, but in our case we have reason to write C code that also
*compiles* as C++ code. And for that reason, we care about the
largest common subset of the two languages."
.... as this post makes plain. This is a different animal entirely.
In other words, he may have taken you (or, much worse, me) to have described
him as a Bad Programmer,
I very much doubt it.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =---- This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Pie |
last post by:
I like to have my program (running on my home machine)
email me (wherever I am) whenever it reaches a certain mile-stone
(finishes a phase of the simulation or runs into an interesting
path in the...
|
by: christopher diggins |
last post by:
I am wondering if any can point me to any open-source library with program
objects for C++ like there is in Java? I would like to be able to write
things like
MyProgram1 >> MyProgram2 >>...
|
by: strutsng |
last post by:
I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?
In a C++ program, we can use standard C libraries. However, we cannot
use C++ libraries inside C...
|
by: Raghavendra R A V, CSS India |
last post by:
hie..
Do any one knows how to write a C program without using the
conditional statements if, for, while, do, switch, goto and even
condotional statements ? It would be a great help for me if...
|
by: findmadhav |
last post by:
I need a program in C (something like a TSR) which will automatically
press the function key F6, say about every 5 seconds. Can anyone
provide me with an exe of such a program?
Thanks in advance.
| | |
by: robinsonreyna |
last post by:
Hi everyone
Is it possible to write a program which do not have a
main() function. The program should compile and run. Please give
sample code to do this.
|
by: Francine.Neary |
last post by:
I am learning C, having fun with strings & pointers at the moment!
The following program is my solution to an exercise to take an input,
strip the first word, and output the rest. It works fine...
|
by: Vince C. |
last post by:
Hi all.
I've installed Bloodshed Dev-C++ on a Windows 2000 SP4 machine. I'm using
MinGW 3.4.2.
I'd like to temporarily disable standard functions to write to stderr, i.e.
for instance...
|
by: Knute Johnson |
last post by:
I'm trying to write a C wrapper to run a Java program. I need to
distribute a CD with the Java runtime, my application and a C startup
program. I've put the C wrapper program, my java app and the...
|
by: Banfa |
last post by:
Posted by Banfa
The previous tutorial discussed what programming is, what we are trying to achieve, the answer being a list of instructions constituting a valid program. Now we will discuss how...
|
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: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
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: 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...
|
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 ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
