Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #85614 > unrolled thread

Differences between C and C++

Back to article view | Back to comp.lang.c++

Contents

  Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-07-25 13:14 +0000
    Re: Differences between C and C++ "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-07-25 16:18 +0200
    Re: Differences between C and C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-07-25 18:47 +0300
      Re: Differences between C and C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-07-25 19:49 +0300
        Re: Differences between C and C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-25 19:38 +0100
    Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-25 08:51 -0700
    Re: Differences between C and C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-25 17:14 +0100
      Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-25 16:19 +0000
        Re: Differences between C and C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-25 19:28 +0100
        Re: Differences between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-25 12:21 -0700
          Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-26 07:54 +0000
            Re: Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-07-26 08:00 +0000
              Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-26 08:09 +0000
                Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-26 02:42 -0700
                  Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-26 15:29 +0000
                    Re: Differences between C and C++ scott@slp53.sl.home (Scott Lurndal) - 2022-07-26 16:30 +0000
                    Re: Differences between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 11:59 -0700
                      Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-27 07:52 +0000
                        Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-27 01:56 -0700
                          Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-27 14:51 +0000
                            Re: Differences between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-27 11:11 -0700
      Re: Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-07-26 06:09 +0000
        Re: Differences between C and C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-27 17:33 +0100
    Re: Differences between C and C++ Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-07-25 17:45 +0100
    Re: Differences between C and C++ Paul N <gw7rib@aol.com> - 2022-07-27 10:09 -0700
      Re: Differences between C and C++ Bo Persson <bo@bo-persson.se> - 2022-07-27 19:28 +0200
        Re: Differences between C and C++ Paul N <gw7rib@aol.com> - 2022-07-27 11:43 -0700
          Re: Differences between C and C++ David Brown <david.brown@hesbynett.no> - 2022-07-29 18:04 +0200
            Re: Differences between C and C++ Richard Damon <Richard@Damon-Family.org> - 2022-07-29 18:47 -0400
              Re: Differences between C and C++ David Brown <david.brown@hesbynett.no> - 2022-07-30 14:08 +0200
        Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-28 08:03 +0000
          Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-28 01:57 -0700
            Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-28 09:04 +0000
      Re: Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-07-28 06:53 +0000
        Re: Differences between C and C++ Richard Damon <Richard@Damon-Family.org> - 2022-07-28 07:33 -0400
          Re: Differences between C and C++ Bo Persson <bo@bo-persson.se> - 2022-07-28 15:04 +0200
            Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-28 15:11 +0000
              Re: Differences between C and C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-07-28 20:03 +0300
                Re: Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-07-29 07:56 +0000
                  Re: Differences between C and C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-07-29 12:03 +0300
                    Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-29 09:28 +0000
                    Re: Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-07-29 12:27 +0000
                      Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-29 05:43 -0700
                        Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-29 14:14 +0000
                          Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-29 08:25 -0700
                            Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-29 15:48 +0000
                              Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-29 13:12 -0700
                                Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-30 09:28 +0000
                                  Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-30 03:39 -0700
                                    Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-30 14:23 +0000
                                      Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-30 19:07 -0700
                                        Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-31 07:22 +0000
                                          Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-31 06:07 -0700
                                            Re: Differences between C and C++ muttley@dastardlyhq.com - 2022-07-31 16:36 +0000
                                              Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-08-01 01:12 -0700
                        Re: Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-07-29 22:47 +0000
                          Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-30 03:48 -0700
                  Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-07-29 05:16 -0700
                  Re: Differences between C and C++ Manfred <noname@add.invalid> - 2022-07-30 02:14 +0200
                    Re: Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-07-31 14:39 +0000
                      Re: Differences between C and C++ "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2022-07-31 18:49 +0200
                        Re: Differences between C and C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-31 14:49 -0700
                          Re: Differences between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-31 17:03 -0700
                            Re: Differences between C and C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-01 00:16 -0700
                              Re: Differences between C and C++ Ike Naar <ike@sdf.org> - 2022-08-01 07:27 +0000
                              Re: Differences between C and C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-01 10:47 +0300
                          Re: Differences between C and C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-01 10:34 +0300
                          Re: Differences between C and C++ Manfred <noname@add.invalid> - 2022-08-03 01:20 +0200
                            Re: Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-03 07:59 +0000
                              Re: Differences between C and C++ Bo Persson <bo@bo-persson.se> - 2022-08-03 12:45 +0200
                                Re: Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-03 10:53 +0000
                                  Re: Differences between C and C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-03 03:58 -0700
                                  Re: Differences between C and C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-03 14:49 +0300
                                    Re: Differences between C and C++ Öö Tiib <ootiib@hot.ee> - 2022-08-03 23:31 -0700
                        Re: Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-01 11:29 +0000
                          Re: Differences between C and C++ Bo Persson <bo@bo-persson.se> - 2022-08-01 14:39 +0200
                            Re: Differences between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-02 05:43 +0000
                      Re: Differences between C and C++ Manfred <noname@add.invalid> - 2022-08-03 01:13 +0200
                        Re: Differences between C and C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-03 09:34 +0300
                Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-29 09:22 +0000
                  Re: Differences between C and C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-07-29 13:53 +0300
                    Re: Differences between C and C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-07-29 14:13 +0300
                    Re: Differences between C and C++ Muttley@dastardlyhq.com - 2022-07-29 14:11 +0000
          Re: Differences between C and C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-28 06:16 -0700

Page 1 of 5  [1] 2 3 4 5  Next page →

#85614 — Differences between C and C++

Some people often object if someone conflates C and C++, as if C++ were
just a pure superset of C, pointing out that they are, in fact, different
languages and, in some aspects, actually incompatible with each other.

That got me thinking: What are all the differences between the two
languages, in behavior and meaning, when it comes to their common syntax?
In other words, I'm not here talking about different keywords and different
syntax that compiles in one but not the other. I'm talking about code that
does compile as both C and C++, but will be interpreted or behave
differently depending on which (and this makes them incompatible).

Here are some of the things that come to mind. What other things are there?

1) A 'const' variable at the global scope will have external linkage by
default in C (unless explicitly made to have internal linkage with
'static'), but internal linkage by default in C++ (unless explicitly made
to have external linkage with 'extern').

2) The type of 'A' is int in C, but char in C++.

3) This one is really obscure: In C, this:

    int f(int (*)(), double (*)[3]);
    int f(int (*)(char *), double (*)[]);

is a valid function declaration, and equivalent to:

    int f(int (*)(char *), double (*)[3]);

(This one is so obscure that I'm certain the vast majority of C programmers,
even experienced ones, would be surprised it even compiles. However, the
example is directly from the C standard, so it's pretty legit.)

In C++ the two first lines declare two different functions, taking different
types of parameter. Calling one is not the same thing as calling the other.

[toc] | [next] | [standalone]

#85617

On 25 Jul 2022 15:14, Juha Nieminen wrote:
> Some people often object if someone conflates C and C++, as if C++ were
> just a pure superset of C, pointing out that they are, in fact, different
> languages and, in some aspects, actually incompatible with each other.
> 
> That got me thinking: What are all the differences between the two
> languages, in behavior and meaning, when it comes to their common syntax?
> In other words, I'm not here talking about different keywords and different
> syntax that compiles in one but not the other. I'm talking about code that
> does compile as both C and C++, but will be interpreted or behave
> differently depending on which (and this makes them incompatible).
> 
> Here are some of the things that come to mind. What other things are there?
> 
> 1) A 'const' variable at the global scope will have external linkage by
> default in C (unless explicitly made to have internal linkage with
> 'static'), but internal linkage by default in C++ (unless explicitly made
> to have external linkage with 'extern').
> 
> 2) The type of 'A' is int in C, but char in C++.
> 
> 3) This one is really obscure: In C, this:
> 
>      int f(int (*)(), double (*)[3]);
>      int f(int (*)(char *), double (*)[]);
> 
> is a valid function declaration, and equivalent to:
> 
>      int f(int (*)(char *), double (*)[3]);
> 
> (This one is so obscure that I'm certain the vast majority of C programmers,
> even experienced ones, would be surprised it even compiles. However, the
> example is directly from the C standard, so it's pretty legit.)
> 
> In C++ the two first lines declare two different functions, taking different
> types of parameter. Calling one is not the same thing as calling the other.

Yes, `void` argument list needed to say "no arguments" in C.

I guess the most crucial thing is that type punning via union is 
well-defined in C, but UB in C++.


- Alf

[toc] | [prev] | [next] | [standalone]

#85618

25.07.2022 16:14 Juha Nieminen kirjutas:
> Some people often object if someone conflates C and C++, as if C++ were
> just a pure superset of C, pointing out that they are, in fact, different
> languages and, in some aspects, actually incompatible with each other.
> 
> That got me thinking: What are all the differences between the two
> languages, in behavior and meaning, when it comes to their common syntax?
> In other words, I'm not here talking about different keywords and different
> syntax that compiles in one but not the other. I'm talking about code that
> does compile as both C and C++, but will be interpreted or behave
> differently depending on which (and this makes them incompatible).

This little program outputs 0 when compiled as C, and 1 when compiled as 
C++, at least with gcc 10.2. I'm not quite sure if this is meant to be 
that way.

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

int main() {

	double x = -0.5;
	int y = (int) 2*abs(x);
	printf("%d\n", y);
}

[toc] | [prev] | [next] | [standalone]

#85623

25.07.2022 18:47 Paavo Helde kirjutas:
> 25.07.2022 16:14 Juha Nieminen kirjutas:
>> Some people often object if someone conflates C and C++, as if C++ were
>> just a pure superset of C, pointing out that they are, in fact, different
>> languages and, in some aspects, actually incompatible with each other.
>>
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main() {
> 
>      double x = -0.5;
>      int y = (int) 2*abs(x);
>      printf("%d\n", y);
> }
> 

This example can be actually made a bit simpler, messing with ints is 
actually not needed. I think this is now similar to what I stomped on 
myself in real code.

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

int main() {

	double x = -0.5;
	double y = 2.0 * abs(x);
	printf("%g\n", y);
}

[toc] | [prev] | [next] | [standalone]

#85626

Paavo Helde <eesnimi@osa.pri.ee> writes:

> 25.07.2022 18:47 Paavo Helde kirjutas:
>> 25.07.2022 16:14 Juha Nieminen kirjutas:
>>> Some people often object if someone conflates C and C++, as if C++ were
>>> just a pure superset of C, pointing out that they are, in fact, different
>>> languages and, in some aspects, actually incompatible with each other.
>>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> int main() {
>>      double x = -0.5;
>>      int y = (int) 2*abs(x);
>>      printf("%d\n", y);
>> }
>
> This example can be actually made a bit simpler, messing with ints is
> actually not needed. I think this is now similar to what I stomped on
> myself in real code.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main() {
>
> 	double x = -0.5;
> 	double y = 2.0 * abs(x);
> 	printf("%g\n", y);
> }

I would have hoped for a warning about that!  gcc gives me one (two, in
fact) if I ask for the kitchen sink:

warning: using integer absolute value function ‘abs’ when argument is of floating-point type ‘double’ [-Wabsolute-value]
    7 |         double y = 2.0 * abs(x);
      |                          ^~~
warning: conversion from ‘double’ to ‘int’ may change value [-Wfloat-conversion]
    7 |         double y = 2.0 * abs(x);
      |                              ^

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#85619

On Monday, 25 July 2022 at 16:14:50 UTC+3, Juha Nieminen wrote:
> Some people often object if someone conflates C and C++, as if C++ were 
> just a pure superset of C, pointing out that they are, in fact, different 
> languages and, in some aspects, actually incompatible with each other. 
> 
> That got me thinking: What are all the differences between the two 
> languages, in behavior and meaning, when it comes to their common syntax? 
> In other words, I'm not here talking about different keywords and different 
> syntax that compiles in one but not the other. I'm talking about code that 
> does compile as both C and C++, but will be interpreted or behave 
> differently depending on which (and this makes them incompatible). 
> 
> Here are some of the things that come to mind. What other things are there? 
> 
> 1) A 'const' variable at the global scope will have external linkage by 
> default in C (unless explicitly made to have internal linkage with 
> 'static'), but internal linkage by default in C++ (unless explicitly made 
> to have external linkage with 'extern'). 
> 
> 2) The type of 'A' is int in C, but char in C++. 
> 
> 3) This one is really obscure: In C, this: 
> 
> int f(int (*)(), double (*)[3]); 
> int f(int (*)(char *), double (*)[]); 
> 
> is a valid function declaration, and equivalent to: 
> 
> int f(int (*)(char *), double (*)[3]); 
> 
> (This one is so obscure that I'm certain the vast majority of C programmers, 
> even experienced ones, would be surprised it even compiles. However, the 
> example is directly from the C standard, so it's pretty legit.) 
> 
> In C++ the two first lines declare two different functions, taking different 
> types of parameter. Calling one is not the same thing as calling the other.

There are not too lot of little things in C that differ from C++ like that:
* C++ has lot of keywords that C does not have or has as macro (bool) or
   typedef (wchar_t)
* logical expressions like 1 == 2 result with int (not bool)
* character literals like 'a' are of type int (not char)
* differences with const
* differences with inline
* differences with static
* C has VLAs 
* differences in enum type size requirements

Those differences can cause same code to compile to different behaviour 
in C and C++ silently but it is usually obscure, specially constructed code.  

[toc] | [prev] | [next] | [standalone]

#85620

Juha Nieminen <nospam@thanks.invalid> writes:

> Some people often object if someone conflates C and C++, as if C++ were
> just a pure superset of C, pointing out that they are, in fact, different
> languages and, in some aspects, actually incompatible with each other.
>
> That got me thinking: What are all the differences between the two
> languages, in behavior and meaning, when it comes to their common
> syntax?

Let's see...

"abc" is of type char * in C and of type const char * in C++.

Then there all the keyword differences.  For example, in C, new is an
ordinary ID and in C++ restrict is an ordinary ID.  There are quite a
few of these!

The rules for compatible pointer types are stronger in C++.  Basically,
you can only add a top-level const when passing arguments in C.

In C++ function declarations, () means (void), but in C it means an
old-style function with unspecified arguments.

In C, at file scope, int x[]; is a "tentative definition" (which will
resolve to int x[] = {0}; if there are no further declarations of x) but
in C++ it's just an error.

In C, f( (int[]){1} ), calls f with a temporary array (it's a "compound
literal"), but that's forbidden in C++.

Some things that are compound literals in C /are/ valid in C++.  For
example:

  struct s { int v; };
  ...
  f((struct s){1});

is ok in both, but add a pointer and you get the same difference as
above:

  g(&(struct s){1});  // ok in C, not ok in C++

And now I'm out of time...

> In other words, I'm not here talking about different keywords and different
> syntax that compiles in one but not the other. I'm talking about code that
> does compile as both C and C++, but will be interpreted or behave
> differently depending on which (and this makes them incompatible).
>
> Here are some of the things that come to mind. What other things are there?
>
> 1) A 'const' variable at the global scope will have external linkage by
> default in C (unless explicitly made to have internal linkage with
> 'static'), but internal linkage by default in C++ (unless explicitly made
> to have external linkage with 'extern').
>
> 2) The type of 'A' is int in C, but char in C++.
>
> 3) This one is really obscure: In C, this:
>
>     int f(int (*)(), double (*)[3]);
>     int f(int (*)(char *), double (*)[]);
>
> is a valid function declaration, and equivalent to:
>
>     int f(int (*)(char *), double (*)[3]);

Yes.  This is C's rules for "composite types" in action.

> (This one is so obscure that I'm certain the vast majority of C programmers,
> even experienced ones, would be surprised it even compiles. However, the
> example is directly from the C standard, so it's pretty legit.)
>
> In C++ the two first lines declare two different functions, taking different
> types of parameter. Calling one is not the same thing as calling the
> other.

However, you can, in fact call the second f with a double (*)[] argument
because of C++'s rules about similar types (at least I think those are
the rules that apply here).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#85621

On Mon, 25 Jul 2022 17:14:05 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>Juha Nieminen <nospam@thanks.invalid> writes:
>> That got me thinking: What are all the differences between the two
>> languages, in behavior and meaning, when it comes to their common
>> syntax?
>
>Let's see...
>
>"abc" is of type char * in C and of type const char * in C++.
>
>Then there all the keyword differences.  For example, in C, new is an
>ordinary ID and in C++ restrict is an ordinary ID.  There are quite a
>few of these!
>
>The rules for compatible pointer types are stronger in C++.  Basically,
>you can only add a top-level const when passing arguments in C.
>
>In C++ function declarations, () means (void), but in C it means an
>old-style function with unspecified arguments.
>
>In C, at file scope, int x[]; is a "tentative definition" (which will
>resolve to int x[] = {0}; if there are no further declarations of x) but
>in C++ it's just an error.
>
>In C, f( (int[]){1} ), calls f with a temporary array (it's a "compound
>literal"), but that's forbidden in C++.
>
>Some things that are compound literals in C /are/ valid in C++.  For
>example:
>
>  struct s { int v; };
>  ...
>  f((struct s){1});
>
>is ok in both, but add a pointer and you get the same difference as
>above:
>
>  g(&(struct s){1});  // ok in C, not ok in C++

IOW mostly contorted syntax that was probably never intended to be used but
happens to be legal due to the way the C parser works.

[toc] | [prev] | [next] | [standalone]

#85625

Muttley@dastardlyhq.com writes:

> On Mon, 25 Jul 2022 17:14:05 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
<cut>
>> Some things that are compound literals in C /are/ valid in C++.  For
>> example:
>>
>>  struct s { int v; };
>>  ...
>>  f((struct s){1});
>>
>>is ok in both, but add a pointer and you get the same difference as
>>above:
>>
>>  g(&(struct s){1});  // ok in C, not ok in C++
>
> IOW mostly contorted syntax that was probably never intended to be used but
> happens to be legal due to the way the C parser works.

Unlikely.  It can be handy to be able to pass a temporary object by
"reference" (technically by pointer value).  I very much doubt it was
never intended to be done.  The C standard defines the object's
lifetime in a way that makes it both safe and useful.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#85627

Muttley@dastardlyhq.com writes:
> On Mon, 25 Jul 2022 17:14:05 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
[...]
>>Some things that are compound literals in C /are/ valid in C++.  For
>>example:
>>
>>  struct s { int v; };
>>  ...
>>  f((struct s){1});
>>
>>is ok in both, but add a pointer and you get the same difference as
>>above:
>>
>>  g(&(struct s){1});  // ok in C, not ok in C++
>
> IOW mostly contorted syntax that was probably never intended to be used but
> happens to be legal due to the way the C parser works.

Not at all.

In C, `(struct s){1}` is a compound literal, and it's an lvalue so
applying `&` to it is perfectly valid.  There's nothing accidental about
it.

C++ doesn't have compound literals, but it has some other features (that
C doesn't) that make `f((struct s){1})` valid, but in C++ it's not an
lvalue, so `&(struct s){1}` is not valid.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#85643

On Mon, 25 Jul 2022 12:21:21 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>Muttley@dastardlyhq.com writes:
>> On Mon, 25 Jul 2022 17:14:05 +0100
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>[...]
>>>Some things that are compound literals in C /are/ valid in C++.  For
>>>example:
>>>
>>>  struct s { int v; };
>>>  ...
>>>  f((struct s){1});
>>>
>>>is ok in both, but add a pointer and you get the same difference as
>>>above:
>>>
>>>  g(&(struct s){1});  // ok in C, not ok in C++
>>
>> IOW mostly contorted syntax that was probably never intended to be used but
>> happens to be legal due to the way the C parser works.
>
>Not at all.
>
>In C, `(struct s){1}` is a compound literal, and it's an lvalue so
>applying `&` to it is perfectly valid.  There's nothing accidental about
>it.

I'm not saying the syntax was accidental, just the fact that this particular
construct also works. I've never yet seen anyone cast literal values to a 
struct in a function call.

>C++ doesn't have compound literals, but it has some other features (that
>C doesn't) that make `f((struct s){1})` valid, but in C++ it's not an
>lvalue, so `&(struct s){1}` is not valid.

Certainly doesn't work with Clang though you'd think if the same compiler
can do it in C mode it should do it in C++ mode if there are no side effects
of doing so.

[toc] | [prev] | [next] | [standalone]

#85645

Muttley@dastardlyhq.com wrote:
>>C++ doesn't have compound literals, but it has some other features (that
>>C doesn't) that make `f((struct s){1})` valid, but in C++ it's not an
>>lvalue, so `&(struct s){1}` is not valid.
> 
> Certainly doesn't work with Clang though you'd think if the same compiler
> can do it in C mode it should do it in C++ mode if there are no side effects
> of doing so.

If the C++ standard doesn't consider it valid, then the compiler shouldn't
consider it valid (C++) either, even if it just so happens to be valid C.

[toc] | [prev] | [next] | [standalone]

#85647

On Tue, 26 Jul 2022 08:00:25 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Muttley@dastardlyhq.com wrote:
>>>C++ doesn't have compound literals, but it has some other features (that
>>>C doesn't) that make `f((struct s){1})` valid, but in C++ it's not an
>>>lvalue, so `&(struct s){1}` is not valid.
>> 
>> Certainly doesn't work with Clang though you'd think if the same compiler
>> can do it in C mode it should do it in C++ mode if there are no side effects
>> of doing so.
>
>If the C++ standard doesn't consider it valid, then the compiler shouldn't
>consider it valid (C++) either, even if it just so happens to be valid C.

Is that specifically states its not valid or simply doesn't mention it.

Most C++ compilers will compile some C constructs which are not technically
legal in C++ such as non consts pointing to string literals, variable length
arrays and variadic macros.

[toc] | [prev] | [next] | [standalone]

#85652

On Tuesday, 26 July 2022 at 11:09:14 UTC+3, Mut...@dastardlyhq.com wrote:
> On Tue, 26 Jul 2022 08:00:25 -0000 (UTC) 
> Juha Nieminen <nos...@thanks.invalid> wrote: 
> >Mut...@dastardlyhq.com wrote: 
> >>>C++ doesn't have compound literals, but it has some other features (that 
> >>>C doesn't) that make `f((struct s){1})` valid, but in C++ it's not an 
> >>>lvalue, so `&(struct s){1}` is not valid. 
> >> 
> >> Certainly doesn't work with Clang though you'd think if the same compiler 
> >> can do it in C mode it should do it in C++ mode if there are no side effects 
> >> of doing so. 
> > 
> >If the C++ standard doesn't consider it valid, then the compiler shouldn't 
> >consider it valid (C++) either, even if it just so happens to be valid C.
> Is that specifically states its not valid or simply doesn't mention it. 
> 
> Most C++ compilers will compile some C constructs which are not technically 
> legal in C++ such as non consts pointing to string literals, variable length 
> arrays and variadic macros.

It is then clearly said in documentation of such compilers. Also most
compilers provide standard compliant mode (like -pedantic of gcc) that
issues warnings about extensions used in code (and standard mandates
nothing else). 

[toc] | [prev] | [next] | [standalone]

#85663

On Tue, 26 Jul 2022 02:42:09 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Tuesday, 26 July 2022 at 11:09:14 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Tue, 26 Jul 2022 08:00:25 -0000 (UTC) 
>> Juha Nieminen <nos...@thanks.invalid> wrote: 
>> >Mut...@dastardlyhq.com wrote: 
>> >>>C++ doesn't have compound literals, but it has some other features (that 
>> >>>C doesn't) that make `f((struct s){1})` valid, but in C++ it's not an 
>> >>>lvalue, so `&(struct s){1}` is not valid. 
>> >> 
>> >> Certainly doesn't work with Clang though you'd think if the same compiler 
>
>> >> can do it in C mode it should do it in C++ mode if there are no side
>effects 
>> >> of doing so. 
>> > 
>> >If the C++ standard doesn't consider it valid, then the compiler shouldn't 
>> >consider it valid (C++) either, even if it just so happens to be valid C.
>> Is that specifically states its not valid or simply doesn't mention it. 
>> 
>> Most C++ compilers will compile some C constructs which are not technically 
>> legal in C++ such as non consts pointing to string literals, variable length 
>
>> arrays and variadic macros.
>
>It is then clearly said in documentation of such compilers. Also most
>compilers provide standard compliant mode (like -pedantic of gcc) that
>issues warnings about extensions used in code (and standard mandates
>nothing else). 

And? Juha said:

"If the C++ standard doesn't consider it valid, then the compiler shouldn't
 consider it valid (C++) either"

Clearly plenty of compilers do consider non standard C++ valid.

[toc] | [prev] | [next] | [standalone]

#85666

Muttley@dastardlyhq.com writes:
>On Tue, 26 Jul 2022 02:42:09 -0700 (PDT)
>=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>>On Tuesday, 26 July 2022 at 11:09:14 UTC+3, Mut...@dastardlyhq.com wrote:
>>> On Tue, 26 Jul 2022 08:00:25 -0000 (UTC) 
>>> Juha Nieminen <nos...@thanks.invalid> wrote: 
>>> >Mut...@dastardlyhq.com wrote: 
>>> >>>C++ doesn't have compound literals, but it has some other features (that 
>>> >>>C doesn't) that make `f((struct s){1})` valid, but in C++ it's not an 
>>> >>>lvalue, so `&(struct s){1}` is not valid. 
>>> >> 
>>> >> Certainly doesn't work with Clang though you'd think if the same compiler 
>>
>>> >> can do it in C mode it should do it in C++ mode if there are no side
>>effects 
>>> >> of doing so. 
>>> > 
>>> >If the C++ standard doesn't consider it valid, then the compiler shouldn't 
>>> >consider it valid (C++) either, even if it just so happens to be valid C.
>>> Is that specifically states its not valid or simply doesn't mention it. 
>>> 
>>> Most C++ compilers will compile some C constructs which are not technically 
>>> legal in C++ such as non consts pointing to string literals, variable length 
>>
>>> arrays and variadic macros.
>>
>>It is then clearly said in documentation of such compilers. Also most
>>compilers provide standard compliant mode (like -pedantic of gcc) that
>>issues warnings about extensions used in code (and standard mandates
>>nothing else). 
>
>And? Juha said:
>
>"If the C++ standard doesn't consider it valid, then the compiler shouldn't
> consider it valid (C++) either"
>
>Clearly plenty of compilers do consider non standard C++ valid.
>

However, those compilers can be configured to reject non-standard C++
if the programmer requirements demand.   Any compiler is allowed to
accept additional features at their discretion.

[toc] | [prev] | [next] | [standalone]

#85667

Muttley@dastardlyhq.com writes:
> On Tue, 26 Jul 2022 02:42:09 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>>On Tuesday, 26 July 2022 at 11:09:14 UTC+3, Mut...@dastardlyhq.com wrote:
>>> On Tue, 26 Jul 2022 08:00:25 -0000 (UTC) 
>>> Juha Nieminen <nos...@thanks.invalid> wrote: 
>>> >Mut...@dastardlyhq.com wrote: 
>>> >>>C++ doesn't have compound literals, but it has some other features (that 
>>> >>>C doesn't) that make `f((struct s){1})` valid, but in C++ it's not an 
>>> >>>lvalue, so `&(struct s){1}` is not valid. 
>>> >> 
>>> >> Certainly doesn't work with Clang though you'd think if the same compiler 
>>
>>> >> can do it in C mode it should do it in C++ mode if there are no side
>>effects 
>>> >> of doing so. 
>>> > 
>>> >If the C++ standard doesn't consider it valid, then the compiler shouldn't 
>>> >consider it valid (C++) either, even if it just so happens to be valid C.
>>> Is that specifically states its not valid or simply doesn't mention it. 
>>> 
>>> Most C++ compilers will compile some C constructs which are not technically 
>>> legal in C++ such as non consts pointing to string literals, variable length 
>>
>>> arrays and variadic macros.
>>
>>It is then clearly said in documentation of such compilers. Also most
>>compilers provide standard compliant mode (like -pedantic of gcc) that
>>issues warnings about extensions used in code (and standard mandates
>>nothing else). 
>
> And? Juha said:
>
> "If the C++ standard doesn't consider it valid, then the compiler shouldn't
>  consider it valid (C++) either"
>
> Clearly plenty of compilers do consider non standard C++ valid.

Plenty of C++ compilers accept non standard C++ *in certain modes*.

The C++ standard requires certain errors to be diagnosed.  A C++
compiler that fails to diagnose, for example, an attempt to use a VLA
is not a conforming compiler.

Most C++ compilers are non-conforming by default, quietly accepting
extensions that are incompatible with the standard.  All conforming C++
compilers provide a way to issue all required diagnostics.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#85677

On Tue, 26 Jul 2022 11:59:21 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>Muttley@dastardlyhq.com writes:
>> On Tue, 26 Jul 2022 02:42:09 -0700 (PDT)
>> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>>>On Tuesday, 26 July 2022 at 11:09:14 UTC+3, Mut...@dastardlyhq.com wrote:
>>>> On Tue, 26 Jul 2022 08:00:25 -0000 (UTC) 
>>>> Juha Nieminen <nos...@thanks.invalid> wrote: 
>>>> >Mut...@dastardlyhq.com wrote: 
>>>> >>>C++ doesn't have compound literals, but it has some other features
>(that 
>>>> >>>C doesn't) that make `f((struct s){1})` valid, but in C++ it's not an 
>>>> >>>lvalue, so `&(struct s){1}` is not valid. 
>>>> >> 
>>>> >> Certainly doesn't work with Clang though you'd think if the same
>compiler 

:
:

>> And? Juha said:
>>
>> "If the C++ standard doesn't consider it valid, then the compiler shouldn't
>>  consider it valid (C++) either"
>>
>> Clearly plenty of compilers do consider non standard C++ valid.
>
>Plenty of C++ compilers accept non standard C++ *in certain modes*.
>
>The C++ standard requires certain errors to be diagnosed.  A C++
>compiler that fails to diagnose, for example, an attempt to use a VLA
>is not a conforming compiler.
>
>Most C++ compilers are non-conforming by default, quietly accepting
>extensions that are incompatible with the standard.  All conforming C++
>compilers provide a way to issue all required diagnostics.

I'm aware of all this. My point is why are some C semantics considered 
compilable (albeit with warnings) but the original example of &(struct s){1} 
isn't and causes an error even though its perfectly legal in C.

[toc] | [prev] | [next] | [standalone]

#85680

On Wednesday, 27 July 2022 at 10:52:22 UTC+3, Mut...@dastardlyhq.com wrote:
> On Tue, 26 Jul 2022 11:59:21 -0700 
> Keith Thompson <Keith.S.T...@gmail.com> wrote: 
> >Mut...@dastardlyhq.com writes: 
> >> On Tue, 26 Jul 2022 02:42:09 -0700 (PDT) 
> >> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >>>On Tuesday, 26 July 2022 at 11:09:14 UTC+3, Mut...@dastardlyhq.com wrote: 
> >>>> On Tue, 26 Jul 2022 08:00:25 -0000 (UTC) 
> >>>> Juha Nieminen <nos...@thanks.invalid> wrote: 
> >>>> >Mut...@dastardlyhq.com wrote: 
> >>>> >>>C++ doesn't have compound literals, but it has some other features 
> >(that 
> >>>> >>>C doesn't) that make `f((struct s){1})` valid, but in C++ it's not an 
> >>>> >>>lvalue, so `&(struct s){1}` is not valid. 
> >>>> >> 
> >>>> >> Certainly doesn't work with Clang though you'd think if the same 
> >compiler
> : 
> :
> >> And? Juha said: 
> >> 
> >> "If the C++ standard doesn't consider it valid, then the compiler shouldn't 
> >> consider it valid (C++) either" 
> >> 
> >> Clearly plenty of compilers do consider non standard C++ valid. 
> > 
> >Plenty of C++ compilers accept non standard C++ *in certain modes*. 
> > 
> >The C++ standard requires certain errors to be diagnosed. A C++ 
> >compiler that fails to diagnose, for example, an attempt to use a VLA 
> >is not a conforming compiler. 
> > 
> >Most C++ compilers are non-conforming by default, quietly accepting 
> >extensions that are incompatible with the standard. All conforming C++ 
> >compilers provide a way to issue all required diagnostics.
> I'm aware of all this. My point is why are some C semantics considered 
> compilable (albeit with warnings) but the original example of &(struct s){1} 
> isn't and causes an error even though its perfectly legal in C.

It is because while the compilers implemented extension of supporting
compound literals almost like in C, the result in those extensions is
temporary whose lifetime will last only to end of full-expression. Taking
address of temporary is illegal and so &(struct s){1} is illegal. 

Why they did not implement the semantics fully like in C is because they
used it like kind of alternative syntax sugar to list-initialization. Since
C++14 however they can not heap-allocate initializer-lists (and did not
do it even before C++14). So the compound literal extension is temporary
for ease of implementation. Some of compilers that do it are open source
so if you want you can perhaps implement more close to C extension
to those.
  

[toc] | [prev] | [next] | [standalone]

#85690

On Wed, 27 Jul 2022 01:56:23 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Wednesday, 27 July 2022 at 10:52:22 UTC+3, Mut...@dastardlyhq.com wrote:
>> >Most C++ compilers are non-conforming by default, quietly accepting 
>> >extensions that are incompatible with the standard. All conforming C++ 
>> >compilers provide a way to issue all required diagnostics.
>> I'm aware of all this. My point is why are some C semantics considered 
>> compilable (albeit with warnings) but the original example of &(struct s){1} 
>
>> isn't and causes an error even though its perfectly legal in C.
>
>It is because while the compilers implemented extension of supporting
>compound literals almost like in C, the result in those extensions is
>temporary whose lifetime will last only to end of full-expression. Taking

The expressions lifetime - and hence the temporary shouldn't end until the 
function being called returns. It should remain on the stack of the calling
function which is probably what happens in C.

>Why they did not implement the semantics fully like in C is because they
>used it like kind of alternative syntax sugar to list-initialization. Since
>C++14 however they can not heap-allocate initializer-lists (and did not
>do it even before C++14). So the compound literal extension is temporary
>for ease of implementation. Some of compilers that do it are open source
>so if you want you can perhaps implement more close to C extension
>to those.

Why? Since they're also already C compilers the code to do it already exists
inside them and is probably a case of setting an internal flag to call it.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web