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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#85698

Muttley@dastardlyhq.com writes:
> 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.

Because they're not also already C compilers.  A C and C++ compiler
might share the same backend and a lot of other infrastructure, but the
front ends are going to be separate.

-- 
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]

#85639

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> "abc" is of type char * in C and of type const char * in C++.

Actually "abc" is an array-of-char (or array-of-const-char in the latter
case). You can discern this by eg. printing what sizeof("12345") is
(quite a nice quiz question).

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

#85692

Juha Nieminen <nospam@thanks.invalid> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> "abc" is of type char * in C and of type const char * in C++.
>
> Actually "abc" is an array-of-char (or array-of-const-char in the latter
> case). You can discern this by eg. printing what sizeof("12345") is
> (quite a nice quiz question).

Yes, I should have added "converts to in most contexts" because that's
usually how the difference gets spotted.  To be clear, the string
literal above has type char[4] in C and const char[4] in C++.

-- 
Ben.

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

#85622

On Mon, 25 Jul 2022 13:14:35 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> 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.

One thing I don't think mentioned so far, for those who like
low-level twiddling of trivial types: in C, except for bit-fields all
objects are composed of contiguous sequences of one or more bytes,
which thereby comprise an array of bytes in C.  In C++ trivially
copyable or standard layout types (ie C-like types) are required to be
comprised of contiguous bytes, but these do not comprise an "array" of
bytes. Hence you can use pointer arithmetic to access and/or modify the
bytes of object entities in C, and this is a fairly common practice for
some low-level work, but not in C++ (save that in C++, when within a
C-like entity you can at least successively increment a byte pointer by
one because in C++ every object, including a byte, can be treated as an
array of size 1).

One other related point is that in C a pointer to any narrow character
type is exempt from the strict aliasing rules, whereas in C++ pointers
to signed char are excluded from the exemption.

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

#85693

On Monday, July 25, 2022 at 2:14:50 PM UTC+1, 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). 

As I understand it, the two languages have quite different philosophies. In BCPL there is a stated aim of eliminating hidden overhead. There seems nothing in the history of C to suggest that this aim was dropped, certainly B was developed on a very spartan machine. In contrast the aim in C++ is to try to hide the underlying details.

For example, in C, a = b + c is a straight-forward addition, though depending on the types it might be a floating-point addition or it might involve a hidden multiplication by a pointer size. In C++, a = b + c could be anything - for instance, it might concatenate two files to form a third one, involving thousands of disk accesses.

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

#85695

On 2022-07-27 at 19:09, Paul N wrote:
> On Monday, July 25, 2022 at 2:14:50 PM UTC+1, 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).
> 
> As I understand it, the two languages have quite different philosophies. In BCPL there is a stated aim of eliminating hidden overhead. There seems nothing in the history of C to suggest that this aim was dropped, certainly B was developed on a very spartan machine. In contrast the aim in C++ is to try to hide the underlying details.

Yes, we call that abstraction.  :-)

Bjarne uses an onion as his metafor. We don't want to see all the way to 
the core all the time.

> 
> For example, in C, a = b + c is a straight-forward addition, though depending on the types it might be a floating-point addition or it might involve a hidden multiplication by a pointer size. In C++, a = b + c could be anything - for instance, it might concatenate two files to form a third one, involving thousands of disk accesses.

I have never understood why this is a problem. In C you can write a = 
add(b, c) and it can do anything. How is that easier to see through than 
using the + operator?

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

#85699

On Wednesday, July 27, 2022 at 6:29:03 PM UTC+1, Bo Persson wrote:
> On 2022-07-27 at 19:09, Paul N wrote: 
> > On Monday, July 25, 2022 at 2:14:50 PM UTC+1, 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). 
> > 
> > As I understand it, the two languages have quite different philosophies. In BCPL there is a stated aim of eliminating hidden overhead. There seems nothing in the history of C to suggest that this aim was dropped, certainly B was developed on a very spartan machine. In contrast the aim in C++ is to try to hide the underlying details.
> Yes, we call that abstraction. :-) 
> 
> Bjarne uses an onion as his metafor. We don't want to see all the way to 
> the core all the time.
> > 
> > For example, in C, a = b + c is a straight-forward addition, though depending on the types it might be a floating-point addition or it might involve a hidden multiplication by a pointer size. In C++, a = b + c could be anything - for instance, it might concatenate two files to form a third one, involving thousands of disk accesses.
> I have never understood why this is a problem. In C you can write a = 
> add(b, c) and it can do anything. How is that easier to see through than 
> using the + operator?

As I understand it, the point is that in C you can see that a = add(b, c) is calling a function that may or may not be long-winded. And you can be fairly confident that something simple like a = b + c is something quick.

In C++ you get the advantage that you can simplify all sorts of stuff by over-loading operators. The downside (or trade-off) is that you can't tell at a glance whether something is quick or not, and it is a problem *if* you wrongly assume that it will be. It's a different language, with different trade-offs, some of which might be a problem.

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

#85745

On 27/07/2022 20:43, Paul N wrote:
> On Wednesday, July 27, 2022 at 6:29:03 PM UTC+1, Bo Persson wrote:
>> On 2022-07-27 at 19:09, Paul N wrote:
>>> On Monday, July 25, 2022 at 2:14:50 PM UTC+1, 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).
>>> 
>>> As I understand it, the two languages have quite different
>>> philosophies. In BCPL there is a stated aim of eliminating hidden
>>> overhead. There seems nothing in the history of C to suggest that
>>> this aim was dropped, certainly B was developed on a very spartan
>>> machine. In contrast the aim in C++ is to try to hide the
>>> underlying details.
>> Yes, we call that abstraction. :-)
>> 
>> Bjarne uses an onion as his metafor. We don't want to see all the
>> way to the core all the time.
>>> 
>>> For example, in C, a = b + c is a straight-forward addition,
>>> though depending on the types it might be a floating-point
>>> addition or it might involve a hidden multiplication by a pointer
>>> size. In C++, a = b + c could be anything - for instance, it
>>> might concatenate two files to form a third one, involving
>>> thousands of disk accesses.
>> I have never understood why this is a problem. In C you can write a
>> = add(b, c) and it can do anything. How is that easier to see
>> through than using the + operator?
> 
> As I understand it, the point is that in C you can see that a =
> add(b, c) is calling a function that may or may not be long-winded.
> And you can be fairly confident that something simple like a = b + c
> is something quick.

Try "a = b + c;" on an 8-bit AVR microcontroller, with "b" being a 
64-bit "long long int" and "c" being a "double".  The result will be 
very large and slow library calls.  Simple operators being "quick" in C, 
or that "it's obvious what object code you get in C" is often an 
unwarranted assumption.

> 
> In C++ you get the advantage that you can simplify all sorts of stuff
> by over-loading operators. The downside (or trade-off) is that you
> can't tell at a glance whether something is quick or not, and it is a
> problem *if* you wrongly assume that it will be. It's a different
> language, with different trade-offs, some of which might be a
> problem.

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

#85749

On 7/29/22 12:04 PM, David Brown wrote:
> On 27/07/2022 20:43, Paul N wrote:
>> On Wednesday, July 27, 2022 at 6:29:03 PM UTC+1, Bo Persson wrote:
>>> On 2022-07-27 at 19:09, Paul N wrote:
>>>> On Monday, July 25, 2022 at 2:14:50 PM UTC+1, 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).
>>>>
>>>> As I understand it, the two languages have quite different
>>>> philosophies. In BCPL there is a stated aim of eliminating hidden
>>>> overhead. There seems nothing in the history of C to suggest that
>>>> this aim was dropped, certainly B was developed on a very spartan
>>>> machine. In contrast the aim in C++ is to try to hide the
>>>> underlying details.
>>> Yes, we call that abstraction. :-)
>>>
>>> Bjarne uses an onion as his metafor. We don't want to see all the
>>> way to the core all the time.
>>>>
>>>> For example, in C, a = b + c is a straight-forward addition,
>>>> though depending on the types it might be a floating-point
>>>> addition or it might involve a hidden multiplication by a pointer
>>>> size. In C++, a = b + c could be anything - for instance, it
>>>> might concatenate two files to form a third one, involving
>>>> thousands of disk accesses.
>>> I have never understood why this is a problem. In C you can write a
>>> = add(b, c) and it can do anything. How is that easier to see
>>> through than using the + operator?
>>
>> As I understand it, the point is that in C you can see that a =
>> add(b, c) is calling a function that may or may not be long-winded.
>> And you can be fairly confident that something simple like a = b + c
>> is something quick.
> 
> Try "a = b + c;" on an 8-bit AVR microcontroller, with "b" being a 
> 64-bit "long long int" and "c" being a "double".  The result will be 
> very large and slow library calls.  Simple operators being "quick" in C, 
> or that "it's obvious what object code you get in C" is often an 
> unwarranted assumption.

It may be a large number of instructions, but not THAT large of a 
number, and unlikely to be slower that a "double" operation, which 
(well, maybe long double will be slower, it suppported as something 
different than double) is sort of a guideline for what is considered 
"quick" by that measure.

> 
>>
>> In C++ you get the advantage that you can simplify all sorts of stuff
>> by over-loading operators. The downside (or trade-off) is that you
>> can't tell at a glance whether something is quick or not, and it is a
>> problem *if* you wrongly assume that it will be. It's a different
>> language, with different trade-offs, some of which might be a
>> problem.
> 

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

#85755

On 30/07/2022 00:47, Richard Damon wrote:
> On 7/29/22 12:04 PM, David Brown wrote:
>> On 27/07/2022 20:43, Paul N wrote:
>>> On Wednesday, July 27, 2022 at 6:29:03 PM UTC+1, Bo Persson wrote:
>>>> On 2022-07-27 at 19:09, Paul N wrote:
>>>>> On Monday, July 25, 2022 at 2:14:50 PM UTC+1, 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).
>>>>>
>>>>> As I understand it, the two languages have quite different
>>>>> philosophies. In BCPL there is a stated aim of eliminating hidden
>>>>> overhead. There seems nothing in the history of C to suggest that
>>>>> this aim was dropped, certainly B was developed on a very spartan
>>>>> machine. In contrast the aim in C++ is to try to hide the
>>>>> underlying details.
>>>> Yes, we call that abstraction. :-)
>>>>
>>>> Bjarne uses an onion as his metafor. We don't want to see all the
>>>> way to the core all the time.
>>>>>
>>>>> For example, in C, a = b + c is a straight-forward addition,
>>>>> though depending on the types it might be a floating-point
>>>>> addition or it might involve a hidden multiplication by a pointer
>>>>> size. In C++, a = b + c could be anything - for instance, it
>>>>> might concatenate two files to form a third one, involving
>>>>> thousands of disk accesses.
>>>> I have never understood why this is a problem. In C you can write a
>>>> = add(b, c) and it can do anything. How is that easier to see
>>>> through than using the + operator?
>>>
>>> As I understand it, the point is that in C you can see that a =
>>> add(b, c) is calling a function that may or may not be long-winded.
>>> And you can be fairly confident that something simple like a = b + c
>>> is something quick.
>>
>> Try "a = b + c;" on an 8-bit AVR microcontroller, with "b" being a 
>> 64-bit "long long int" and "c" being a "double".  The result will be 
>> very large and slow library calls.  Simple operators being "quick" in 
>> C, or that "it's obvious what object code you get in C" is often an 
>> unwarranted assumption.
> 
> It may be a large number of instructions, but not THAT large of a 
> number, and unlikely to be slower that a "double" operation, which 
> (well, maybe long double will be slower, it suppported as something 
> different than double) is sort of a guideline for what is considered 
> "quick" by that measure.
> 

I don't have a modern AVR toolchain on this machine, but that one 
statement would require library code too large for a large proportion of 
AVR microcontrollers.  People used to PC programming consider anything 
measured in kilobytes to be negligible size - people working with 
microcontrollers with 8 or 16 KB code flash have a rather different 
viewpoint.  Similarly, an 8-bit register-to-register add instruction on 
an AVR takes 1 clock cycles.  No more, no less - no cache effects, or 
pipelining, or sequencing.  If you have a 20 MHz clock, it takes 50 ns. 
  But adding a 64-bit integer and a 64-bit floating point will take 
vastly longer, with huge variation - maybe something between 300 and 
1000 clock cycles.

Of course you don't use these types on such a microcontroller if you 
don't have need of them, and you have to accept the price.  The point is 
that the assumption some people have that C is simple, and that 
operators on fundamental types is always small, fast, and predictable, 
can be a wildly incorrect assumption.  It is wrong by several orders of 
magnitude in this case.

(The AVR is perhaps the most modern 8-bit microcontroller core in 
popular use, and new devices are released regularly.  It is the only 
8-bit target with full gcc support, AFAIK.  So this is not just a legacy 
or dinosaur core.)

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

#85713

On Wed, 27 Jul 2022 19:28:15 +0200
Bo Persson <bo@bo-persson.se> wrote:
>On 2022-07-27 at 19:09, Paul N wrote:
>> On Monday, July 25, 2022 at 2:14:50 PM UTC+1, 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).
>> 
>> As I understand it, the two languages have quite different philosophies. In
>BCPL there is a stated aim of eliminating hidden overhead. There seems nothing
>in the history of C to suggest that this aim was dropped, certainly B was
>developed on a very spartan machine. In contrast the aim in C++ is to try to
>hide the underlying details.
>
>Yes, we call that abstraction.  :-)
>
>Bjarne uses an onion as his metafor. We don't want to see all the way to 
>the core all the time.

Unfortunately C++ doesn't hide it well enough because you need to understand
whats happening all the way to the core or you'll end up with unexpected
results - eg implicit conversions, deep vs shallow copies.

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

#85715

On Thursday, 28 July 2022 at 11:03:33 UTC+3, Mut...@dastardlyhq.com wrote:
> On Wed, 27 Jul 2022 19:28:15 +0200 
> Bo Persson <b...@bo-persson.se> wrote: 
> >On 2022-07-27 at 19:09, Paul N wrote: 
> >> On Monday, July 25, 2022 at 2:14:50 PM UTC+1, 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). 
> >> 
> >> As I understand it, the two languages have quite different philosophies. In 
> >BCPL there is a stated aim of eliminating hidden overhead. There seems nothing 
> >in the history of C to suggest that this aim was dropped, certainly B was 
> >developed on a very spartan machine. In contrast the aim in C++ is to try to 
> >hide the underlying details. 
> > 
> >Yes, we call that abstraction. :-) 
> > 
> >Bjarne uses an onion as his metafor. We don't want to see all the way to 
> >the core all the time.
> 
> Unfortunately C++ doesn't hide it well enough because you need to understand 
> whats happening all the way to the core or you'll end up with unexpected 
> results - eg implicit conversions, deep vs shallow copies.

C++ does dictate nothing about paradigms and idioms we follow or ignore.
Any fundamental type or aggregate can be wrapped into class and all unsafe
operations or conversions can be made safe or not exposed in interface.
The standard library does it quite a lot. Unfortunately some programmers do
not understand difference between freedom and anarchy well enough, but
there is always freedom to not cooperate with them. 

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

#85716

On Thu, 28 Jul 2022 01:57:53 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Thursday, 28 July 2022 at 11:03:33 UTC+3, Mut...@dastardlyhq.com wrote:
>> Unfortunately C++ doesn't hide it well enough because you need to understand 
>
>> whats happening all the way to the core or you'll end up with unexpected 
>> results - eg implicit conversions, deep vs shallow copies.
>
>C++ does dictate nothing about paradigms and idioms we follow or ignore.
>Any fundamental type or aggregate can be wrapped into class and all unsafe
>operations or conversions can be made safe or not exposed in interface.
>The standard library does it quite a lot. Unfortunately some programmers do
>not understand difference between freedom and anarchy well enough, but
>there is always freedom to not cooperate with them. 

Sometimes the STL doesn't help itself. The disaster that was auto_ptr caught
out a lot of people since - quite reasonably - they expected something that
was in the STL to work well with STL containers.

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

#85712

Paul N <gw7rib@aol.com> wrote:
> For example, in C, a = b + c is a straight-forward addition, though depending on the types it might be a floating-point addition or it might involve a hidden multiplication by a pointer size. In C++, a = b + c could be anything - for instance, it might concatenate two files to form a third one, involving thousands of disk accesses.

If the types of a, b and c are the same as in the C code, then it cannot
"be anything". I'm not aware of operator overloading being possible for
basic types in C++.

As you say, even in C, if you don't know what the types are, you don't
know what operation that is actually doing. Could be pointer arithmetic
for all we know. Knowing the types is kind of crucial to understand
what's being done there.

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

#85718

On 7/28/22 2:53 AM, Juha Nieminen wrote:
> Paul N <gw7rib@aol.com> wrote:
>> For example, in C, a = b + c is a straight-forward addition, though depending on the types it might be a floating-point addition or it might involve a hidden multiplication by a pointer size. In C++, a = b + c could be anything - for instance, it might concatenate two files to form a third one, involving thousands of disk accesses.
> 
> If the types of a, b and c are the same as in the C code, then it cannot
> "be anything". I'm not aware of operator overloading being possible for
> basic types in C++.
> 
> As you say, even in C, if you don't know what the types are, you don't
> know what operation that is actually doing. Could be pointer arithmetic
> for all we know. Knowing the types is kind of crucial to understand
> what's being done there.

The difference is that in C, if you see in the code a + b, then you KNOW 
that a and b need to be primitive types and the operation will be just a 
couple of operations long (the WORSE it can be is a floating point 
addition).

In C++, we don't have that knowledge, and we need to think about what 
the types actually are and what that means for the code.

C allows you to more lightly skim code to see what it might be 
happening, C++ requires you to know a bit more about the code, but lets 
the code express higher level operations compactly.

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

#85719

On 2022-07-28 at 13:33, Richard Damon wrote:
> On 7/28/22 2:53 AM, Juha Nieminen wrote:
>> Paul N <gw7rib@aol.com> wrote:
>>> For example, in C, a = b + c is a straight-forward addition, though 
>>> depending on the types it might be a floating-point addition or it 
>>> might involve a hidden multiplication by a pointer size. In C++, a = 
>>> b + c could be anything - for instance, it might concatenate two 
>>> files to form a third one, involving thousands of disk accesses.
>>
>> If the types of a, b and c are the same as in the C code, then it cannot
>> "be anything". I'm not aware of operator overloading being possible for
>> basic types in C++.
>>
>> As you say, even in C, if you don't know what the types are, you don't
>> know what operation that is actually doing. Could be pointer arithmetic
>> for all we know. Knowing the types is kind of crucial to understand
>> what's being done there.
> 
> The difference is that in C, if you see in the code a + b, then you KNOW 
> that a and b need to be primitive types and the operation will be just a 
> couple of operations long (the WORSE it can be is a floating point 
> addition).
> 
> In C++, we don't have that knowledge, and we need to think about what 
> the types actually are and what that means for the code.

Yes, but if I have

std::string full_name = first_name + last_name;

I wouldn't expect a floating point addition.

> 
> C allows you to more lightly skim code to see what it might be 
> happening, C++ requires you to know a bit more about the code, but lets 
> the code express higher level operations compactly.

The abstraction part is that you shouldn't *have* to consider what 
happens down to the hardware level - not right now. Rather you should 
trust that the next level - which you wrote yesterday - works just as 
well as if you were to write it now.

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

#85722

On Thu, 28 Jul 2022 15:04:12 +0200
Bo Persson <bo@bo-persson.se> wrote:
>On 2022-07-28 at 13:33, Richard Damon wrote:
>> On 7/28/22 2:53 AM, Juha Nieminen wrote:
>>> Paul N <gw7rib@aol.com> wrote:
>>>> For example, in C, a = b + c is a straight-forward addition, though 
>>>> depending on the types it might be a floating-point addition or it 
>>>> might involve a hidden multiplication by a pointer size. In C++, a = 
>>>> b + c could be anything - for instance, it might concatenate two 
>>>> files to form a third one, involving thousands of disk accesses.
>>>
>>> If the types of a, b and c are the same as in the C code, then it cannot
>>> "be anything". I'm not aware of operator overloading being possible for
>>> basic types in C++.
>>>
>>> As you say, even in C, if you don't know what the types are, you don't
>>> know what operation that is actually doing. Could be pointer arithmetic
>>> for all we know. Knowing the types is kind of crucial to understand
>>> what's being done there.
>> 
>> The difference is that in C, if you see in the code a + b, then you KNOW 
>> that a and b need to be primitive types and the operation will be just a 
>> couple of operations long (the WORSE it can be is a floating point 
>> addition).
>> 
>> In C++, we don't have that knowledge, and we need to think about what 
>> the types actually are and what that means for the code.
>
>Yes, but if I have
>
>std::string full_name = first_name + last_name;
>
>I wouldn't expect a floating point addition.

Unfortunately even in C++ 2020 that won't compile unless first_name is a
string and won't work if its char* due to precendence rules. It would be nice 
if a solution was found so C++ did a silent conversion of char* in this sort of
situation instead of having to do std::string(first_name) which is ugly and
inefficient. Maybe something like:

std::string (s = "hello") + "world";

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

#85723

28.07.2022 18:11 Muttley@dastardlyhq.com kirjutas:
> On Thu, 28 Jul 2022 15:04:12 +0200
> Bo Persson <bo@bo-persson.se> wrote:
>
>> std::string full_name = first_name + last_name;
>>
>> I wouldn't expect a floating point addition.
> 
> Unfortunately even in C++ 2020 that won't compile unless first_name is a
> string and won't work if its char* due to precendence rules.

Why on earth are you using char* in a C++ program? The only thing they 
bring is problems and slowdowns (because string length needs to be 
re-calculated all the time).

#include <string>
using namespace std::string_literals;

int main() {
     auto first_name = "Bernhard"s, last_name = "Shaw"s;
     std::string full_name = first_name + last_name;
}

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

#85730

Paavo Helde <eesnimi@osa.pri.ee> wrote:
> Why on earth are you using char* in a C++ program? The only thing they 
> bring is problems and slowdowns (because string length needs to be 
> re-calculated all the time).

Incorrect. In many situations using char* "strings" is more efficient than
using std::string because of the elided dynamic memory allocation. Also,
not in all situations is the length of the string needed to be separately
calculated in order to operate with the string, as many operations do not
need to know the length in advance, and can just stop when they encounter
the null byte. (For example printing a char* string doesn't need to know
its length in advance. Many other operations likewise.)

If you have some function void foo(const std::string&), and you wanted
to call that function by giving it a string literal, how is that going
to be more (or even equally) efficient than if it were foo(const char*)?
The string literal would be needlessly copied into a dynamically
allocated memory block (and immediately deleted after the function returns).

There are also some situations where, for example, a class needs a small
string as a member variable (which maximum length, or even outright length,
is fixed and very small). Using a char array is usually much more efficient
for this than a std::string, and operating on this small string will be
more efficient with a char* than creating a std::string every time.
(If in this example the length of the string would vary and there are
tons of situations where the length is needed, you could simply add
a length member variable and use that. Still a lot more efficient than
using std::string because you are not dynamically allocating memory.)

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

#85732

29.07.2022 10:56 Juha Nieminen kirjutas:
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> Why on earth are you using char* in a C++ program? The only thing they
>> bring is problems and slowdowns (because string length needs to be
>> re-calculated all the time).
> 
> Incorrect. In many situations using char* "strings" is more efficient than
> using std::string because of the elided dynamic memory allocation. Also,
> not in all situations is the length of the string needed to be separately
> calculated in order to operate with the string, as many operations do not
> need to know the length in advance, and can just stop when they encounter
> the null byte. (For example printing a char* string doesn't need to know
> its length in advance. Many other operations likewise.)

Yes, in some situations char* strings can be more efficient. But these 
situations are pretty rare, and in order to outweigh the drawbacks the 
performance benefits must be pretty large. Plus, on that level of 
performance tuning, one needs to really know what one is doing, which Mr 
Muttley quite clearly does not.

> 
> If you have some function void foo(const std::string&), and you wanted
> to call that function by giving it a string literal, how is that going
> to be more (or even equally) efficient than if it were foo(const char*)?
> The string literal would be needlessly copied into a dynamically
> allocated memory block (and immediately deleted after the function returns).

First, if I have a std::string literal and pass it to foo(const 
std::string&), then there is no copies, just a reference is passed. If I 
have a char* literal, then there is indeed strlen+copy, that's what I 
was talking about. I think your example actually proves my point.

Second, for such functions it would be more appropriate to declare them 
as taking a std::string_view parameter. For a string_view, you can also 
pass either a std::string or a char* literal, and there will be no 
copies made, just an extra strlen() in case of char* literal.

> 
> There are also some situations where, for example, a class needs a small
> string as a member variable (which maximum length, or even outright length,
> is fixed and very small). Using a char array is usually much more efficient
> for this than a std::string, and operating on this small string will be
> more efficient with a char* than creating a std::string every time.
> (If in this example the length of the string would vary and there are
> tons of situations where the length is needed, you could simply add
> a length member variable and use that. Still a lot more efficient than
> using std::string because you are not dynamically allocating memory.)

Nowadays std::string is typically using small string optimization, 
meaning that for sufficiently short strings there is no dynamic 
allocation either.

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

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

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

csiph-web