By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,368 Members | 1,544 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,368 IT Pros & Developers. It's quick & easy.

C program is standard C++ program?

P: n/a
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!!

Oct 22 '05 #1
Share this Question
Share on Google+
50 Replies


P: n/a
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

Oct 22 '05 #2

P: n/a
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
Oct 22 '05 #3

P: n/a
> 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
Oct 22 '05 #4

P: n/a
<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
Oct 22 '05 #5

P: n/a
st******@gmail.com wrote:
I want if "a C program is a standard C++ program, but not vice versa"
is a correct statement?

[snip]

int main()
{
char a[3] = "foo";
return 0;
}

It is legal in C, but not in C++.

Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

Oct 22 '05 #6

P: n/a
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
Oct 22 '05 #7

P: n/a
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.
Oct 22 '05 #8

P: n/a
"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

Oct 22 '05 #9

P: n/a
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.
Oct 22 '05 #10

P: n/a
"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

Oct 22 '05 #11

P: n/a
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).

Oct 22 '05 #12

P: n/a
"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

Oct 22 '05 #13

P: n/a
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.
Oct 22 '05 #14

P: n/a

<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.
Oct 22 '05 #15

P: n/a

"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.

Oct 22 '05 #16

P: n/a
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.
Oct 22 '05 #17

P: n/a
"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.
Oct 22 '05 #18

P: n/a
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.
Oct 22 '05 #19

P: n/a

"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.
Oct 22 '05 #20

P: n/a
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.
Oct 22 '05 #21

P: n/a
"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.
Oct 22 '05 #22

P: n/a

"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.
Oct 22 '05 #23

P: n/a
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.
Oct 22 '05 #24

P: n/a
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.

Oct 22 '05 #25

P: n/a

"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.

Oct 22 '05 #26

P: n/a
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++.

Oct 22 '05 #27

P: n/a
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.
Oct 22 '05 #28

P: n/a
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.
Oct 22 '05 #29

P: n/a

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
Oct 22 '05 #30

P: n/a
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".
Oct 22 '05 #31

P: n/a
"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

Oct 23 '05 #32

P: n/a
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 =----
Oct 23 '05 #33

P: n/a
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 =----
Oct 23 '05 #34

P: n/a
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.
Oct 23 '05 #35

P: n/a
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.
Oct 23 '05 #36

P: n/a
"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

Oct 24 '05 #37

P: n/a
"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
Oct 24 '05 #38

P: n/a
"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
Oct 24 '05 #39

P: n/a
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 =----
Oct 24 '05 #40

P: n/a
"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

Oct 24 '05 #41

P: n/a
"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

Oct 25 '05 #42

P: n/a
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)

Oct 25 '05 #43

P: n/a
>>> "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
Oct 25 '05 #44

P: n/a
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...)

Oct 25 '05 #45

P: n/a
"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

Oct 25 '05 #46

P: n/a
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 =----
Oct 25 '05 #47

P: n/a
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 =----
Oct 25 '05 #48

P: n/a
"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

Oct 26 '05 #49

P: n/a
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 =----
Oct 26 '05 #50

50 Replies

This discussion thread is closed

Replies have been disabled for this discussion.