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

#85734

On Fri, 29 Jul 2022 12:03:12 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
>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.

You're in no position to be patronising my friend since you seem to be
unaware of basic char* use cases and how they work.

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

If you pass a char* there are no copies either. You ever heard of pointers?

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

Moving the stack pointer to allocate stack memory takes non zero time compared
to using a raw pointer which is already set.

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

#85739

Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> 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.

How exactly do you create "a std::string literal" that doesn't involve
creating a normal std::string object and giving it a C string literal,
which will cause it to allocate memory and (needlessly) copy the contents
of the C string literal into it (something we were trying to avoid here
in the first place)?

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

I doubt you can create a std::string object from a string_view without
incurring the exact same operations and penalties as if you were using
a char* literal (ie. allocating memory, needlessly copying the contents
of the string_view into it).

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

I'm not sure how common that is. And even if it is, you are still incurring
a penalty that doesn't exist for const char*'s (namely, conditionals that
the std::string code has to do in order to check what kind of storage
it's using, which it has to do in every single member function).

You were talking about "slowdowns", so let's talk about slowdowns.

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

#85740

On Friday, 29 July 2022 at 15:27:58 UTC+3, Juha Nieminen wrote:
> 
> You were talking about "slowdowns", so let's talk about slowdowns.

Yes lets consider:

#include <iostream>
#include <string>
#include <string_view>
using namespace std::literals;

int main() {
// we have fully compile time literals in language
constexpr auto first_name = "Bernhard"sv, last_name = "Shaw"sv;

// useful with (bit inconvenient semantics) in std::string operations
std::string full_name{first_name};
full_name += last_name;

// useful everywhere else
std::cout << first_name << last_name << " " <<  full_name << '\n';
} 

So why we need char* ?

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

#85742

On Fri, 29 Jul 2022 05:43:57 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Friday, 29 July 2022 at 15:27:58 UTC+3, Juha Nieminen wrote:
>> 
>> You were talking about "slowdowns", so let's talk about slowdowns.
>
>Yes lets consider:
>
>#include <iostream>
>#include <string>
>#include <string_view>
>using namespace std::literals;
>
>int main() {
>// we have fully compile time literals in language
>constexpr auto first_name = "Bernhard"sv, last_name = "Shaw"sv;
>
>// useful with (bit inconvenient semantics) in std::string operations
>std::string full_name{first_name};
>full_name += last_name;
>
>// useful everywhere else
>std::cout << first_name << last_name << " " <<  full_name << '\n';
>} 
>
>So why we need char* ?

argv, envp, network packets, navigating binary data (though that would more
likely be u_char*), pretty much every C API function that requires text etc.

If you don't want to deal with pointers perhaps you'd be happier using Java
or C#.

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

#85743

On Friday, 29 July 2022 at 17:14:22 UTC+3, Mut...@dastardlyhq.com wrote:
> On Fri, 29 Jul 2022 05:43:57 -0700 (PDT) 
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Friday, 29 July 2022 at 15:27:58 UTC+3, Juha Nieminen wrote: 
> >> 
> >> You were talking about "slowdowns", so let's talk about slowdowns. 
> > 
> >Yes lets consider: 
> > 
> >#include <iostream> 
> >#include <string> 
> >#include <string_view> 
> >using namespace std::literals; 
> > 
> >int main() { 
> >// we have fully compile time literals in language 
> >constexpr auto first_name = "Bernhard"sv, last_name = "Shaw"sv; 
> > 
> >// useful with (bit inconvenient semantics) in std::string operations 
> >std::string full_name{first_name}; 
> >full_name += last_name; 
> > 
> >// useful everywhere else 
> >std::cout << first_name << last_name << " " << full_name << '\n'; 
> >} 
> > 
> >So why we need char* ?
> argv, envp, network packets, navigating binary data (though that would more 
> likely be u_char*), pretty much every C API function that requires text etc. 

Every standard library template has methods to provide raw pointers if
some legacy API that needs those is used. That is in thin interface layer
with legacy API and everywhere else I can enjoy that my code can deal
with things that matter.    

> If you don't want to deal with pointers perhaps you'd be happier using Java 
> or C#.

It is kind of nineties, pre-standard view at C++ that I have any need to
deal with pointers. My C++ typically beats good C# or Java 2 to 5 times
regardless if it is compiled to native binary before or just in time. Those
languages have unneeded dynamic layers of indirection, compiler has
itself to figure all compile time processing opportunities OTOH that is
tricky with run-time reflection in language so those are doomed to lose
forever both in performance and memory usage.

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

#85744

On Fri, 29 Jul 2022 08:25:21 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Friday, 29 July 2022 at 17:14:22 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Fri, 29 Jul 2022 05:43:57 -0700 (PDT) 
>> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
>> >On Friday, 29 July 2022 at 15:27:58 UTC+3, Juha Nieminen wrote: 
>> >> 
>> >> You were talking about "slowdowns", so let's talk about slowdowns. 
>> > 
>> >Yes lets consider: 
>> > 
>> >#include <iostream> 
>> >#include <string> 
>> >#include <string_view> 
>> >using namespace std::literals; 
>> > 
>> >int main() { 
>> >// we have fully compile time literals in language 
>> >constexpr auto first_name = "Bernhard"sv, last_name = "Shaw"sv; 
>> > 
>> >// useful with (bit inconvenient semantics) in std::string operations 
>> >std::string full_name{first_name}; 
>> >full_name += last_name; 
>> > 
>> >// useful everywhere else 
>> >std::cout << first_name << last_name << " " << full_name << '\n'; 
>> >} 
>> > 
>> >So why we need char* ?
>> argv, envp, network packets, navigating binary data (though that would more 
>> likely be u_char*), pretty much every C API function that requires text etc. 
>
>
>Every standard library template has methods to provide raw pointers if
>some legacy API that needs those is used. That is in thin interface layer
>with legacy API and everywhere else I can enjoy that my code can deal
>with things that matter.    

Great idea, put a layer on top, that'll make things more efficient. Sometimes
things that matter include raw data (if you do systems or low level programming
which I suspect you don't) and good luck processing that efficiently in
std::string.

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

#85747

On Friday, 29 July 2022 at 18:48:55 UTC+3, Mut...@dastardlyhq.com wrote:
> On Fri, 29 Jul 2022 08:25:21 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Friday, 29 July 2022 at 17:14:22 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> On Fri, 29 Jul 2022 05:43:57 -0700 (PDT) 
> >> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >> >On Friday, 29 July 2022 at 15:27:58 UTC+3, Juha Nieminen wrote: 
> >> >> 
> >> >> You were talking about "slowdowns", so let's talk about slowdowns. 
> >> > 
> >> >Yes lets consider: 
> >> > 
> >> >#include <iostream> 
> >> >#include <string> 
> >> >#include <string_view> 
> >> >using namespace std::literals; 
> >> > 
> >> >int main() { 
> >> >// we have fully compile time literals in language 
> >> >constexpr auto first_name = "Bernhard"sv, last_name = "Shaw"sv; 
> >> > 
> >> >// useful with (bit inconvenient semantics) in std::string operations 
> >> >std::string full_name{first_name}; 
> >> >full_name += last_name; 
> >> > 
> >> >// useful everywhere else 
> >> >std::cout << first_name << last_name << " " << full_name << '\n'; 
> >> >} 
> >> > 
> >> >So why we need char* ? 
> >> argv, envp, network packets, navigating binary data (though that would more 
> >> likely be u_char*), pretty much every C API function that requires text etc. 
> > 
> > 
> >Every standard library template has methods to provide raw pointers if 
> >some legacy API that needs those is used. That is in thin interface layer 
> >with legacy API and everywhere else I can enjoy that my code can deal 
> >with things that matter.

> Great idea, put a layer on top, that'll make things more efficient. Sometimes 
> things that matter include raw data (if you do systems or low level programming 
> which I suspect you don't) and good luck processing that efficiently in 
> std::string.

You suspect wrongly. The effect of most library classes is just that
those compile to about same code what you would do in C, just look
easier to read.  The hand-written code is commonly less efficient, more
verbose, more error-prone, harder for compiler to optimize and maintainer
to fix.    

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

#85752

On Fri, 29 Jul 2022 13:12:55 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Friday, 29 July 2022 at 18:48:55 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Fri, 29 Jul 2022 08:25:21 -0700 (PDT)
>> Great idea, put a layer on top, that'll make things more efficient.
>Sometimes 
>> things that matter include raw data (if you do systems or low level
>programming 
>> which I suspect you don't) and good luck processing that efficiently in 
>> std::string.
>
>You suspect wrongly. The effect of most library classes is just that
>those compile to about same code what you would do in C, just look

If there's an interface layer there's a non zero time penalty for going through
it.

>easier to read.  The hand-written code is commonly less efficient, more
>verbose, more error-prone, harder for compiler to optimize and maintainer
>to fix.    

Really? Here's some code from a utility I wrote that reads network data into
a u_char frame buffer. Feel free to tell us how using std::string or similar
would improve the speed or make the code any more readable:

        switch((rlen = read(bpf_fd,frame_buffer,frame_buffsize)))
        {
        case 0:
                assert(0);
        case -1:
                perror("ERROR: read()");
                exit(1);
        }
        for(ptr=frame_buffer;
            ptr < frame_buffer + rlen;
            ptr += BPF_WORDALIGN(bhdr->bh_hdrlen + bhdr->bh_caplen))
        {
                bhdr = (struct bpf_hdr *)ptr;
                recv_pkt = (union un_recv_pkt *)(ptr + frame_hdr_len + bhdr->bh_
hdrlen);
                processPacket(rlen);
        }

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

#85753

On Saturday, 30 July 2022 at 12:28:45 UTC+3, Mut...@dastardlyhq.com wrote:
> On Fri, 29 Jul 2022 13:12:55 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Friday, 29 July 2022 at 18:48:55 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> On Fri, 29 Jul 2022 08:25:21 -0700 (PDT)
> >> Great idea, put a layer on top, that'll make things more efficient. 
> >Sometimes 
> >> things that matter include raw data (if you do systems or low level 
> >programming 
> >> which I suspect you don't) and good luck processing that efficiently in 
> >> std::string. 
> > 
> >You suspect wrongly. The effect of most library classes is just that 
> >those compile to about same code what you would do in C, just look
> 
> If there's an interface layer there's a non zero time penalty for going through 
> it.

On majority of cases with actual compilers that claim is incorrect.
Compilers inline function calls and optimize code not on narrow cases but
aggressively and massively. The libraries are typically written in manner to
support it. Naive code can use some construct that makes it hard for
compiler. Profilers have shown me plenty of that during decades. 

> >easier to read. The hand-written code is commonly less efficient, more 
> >verbose, more error-prone, harder for compiler to optimize and maintainer 
> >to fix.
> Really? Here's some code from a utility I wrote that reads network data into 
> a u_char frame buffer. Feel free to tell us how using std::string or similar 
> would improve the speed or make the code any more readable: 

Odd request. The std::string is meant for processing texts. If someone puts
some other data into it then they make their life harder, not easier.   

> 
> switch((rlen = read(bpf_fd,frame_buffer,frame_buffsize))) 
> { 
> case 0: 
> assert(0); 

That asserts that there are never end of file?

> case -1: 
> perror("ERROR: read()"); 
> exit(1); 

Any error ends the program? 

Further code assumes that all read packets fit to buffer. I don't have such code
What embedded device it is that dies down on usual situations? Speed or
readability matter only after it is useful.

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

#85756

On Sat, 30 Jul 2022 03:39:11 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Saturday, 30 July 2022 at 12:28:45 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Fri, 29 Jul 2022 13:12:55 -0700 (PDT)
>> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
>> >On Friday, 29 July 2022 at 18:48:55 UTC+3, Mut...@dastardlyhq.com wrote: 
>> >> On Fri, 29 Jul 2022 08:25:21 -0700 (PDT)
>> >> Great idea, put a layer on top, that'll make things more efficient. 
>> >Sometimes 
>> >> things that matter include raw data (if you do systems or low level 
>> >programming 
>> >> which I suspect you don't) and good luck processing that efficiently in 
>> >> std::string. 
>> > 
>> >You suspect wrongly. The effect of most library classes is just that 
>> >those compile to about same code what you would do in C, just look
>> 
>> If there's an interface layer there's a non zero time penalty for going
>through 
>> it.
>
>On majority of cases with actual compilers that claim is incorrect.
>Compilers inline function calls and optimize code not on narrow cases but
>aggressively and massively. The libraries are typically written in manner to
>support it. Naive code can use some construct that makes it hard for
>compiler. Profilers have shown me plenty of that during decades. 

Inlined functions still have code to be executed. You can't get an API
translation layer down to zero instructions if you're converting to complex 
types such as std::string.

>> >easier to read. The hand-written code is commonly less efficient, more 
>> >verbose, more error-prone, harder for compiler to optimize and maintainer 
>> >to fix.
>> Really? Here's some code from a utility I wrote that reads network data into 
>
>> a u_char frame buffer. Feel free to tell us how using std::string or similar 
>
>> would improve the speed or make the code any more readable: 
>
>Odd request. The std::string is meant for processing texts. If someone puts
>some other data into it then they make their life harder, not easier.   

Not something that occured to you when you were asking what the point of
char* was.

>
>> 
>> switch((rlen = read(bpf_fd,frame_buffer,frame_buffsize))) 
>> { 
>> case 0: 
>> assert(0); 
>
>That asserts that there are never end of file?

Its reading a berkeley packet filter intercepting UDP packets which has got to 
this point via select() first. If read() returns 0 at this point then something
is fucked inside the API or OS.

>> case -1: 
>> perror("ERROR: read()"); 
>> exit(1); 
>
>Any error ends the program? 

Yes, because it can't progress. Its a client, not a server.

>Further code assumes that all read packets fit to buffer. I don't have such
>code
>What embedded device it is that dies down on usual situations? Speed or
>readability matter only after it is useful.

Point proven I think.

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

#85761

On Saturday, 30 July 2022 at 17:23:52 UTC+3, Mut...@dastardlyhq.com wrote:
> On Sat, 30 Jul 2022 03:39:11 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Saturday, 30 July 2022 at 12:28:45 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> On Fri, 29 Jul 2022 13:12:55 -0700 (PDT) 
> >> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >> >On Friday, 29 July 2022 at 18:48:55 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> >> On Fri, 29 Jul 2022 08:25:21 -0700 (PDT) 
> >> >> Great idea, put a layer on top, that'll make things more efficient. 
> >> >Sometimes 
> >> >> things that matter include raw data (if you do systems or low level 
> >> >programming 
> >> >> which I suspect you don't) and good luck processing that efficiently in 
> >> >> std::string. 
> >> > 
> >> >You suspect wrongly. The effect of most library classes is just that 
> >> >those compile to about same code what you would do in C, just look 
> >> 
> >> If there's an interface layer there's a non zero time penalty for going 
> >through 
> >> it. 
> > 
> >On majority of cases with actual compilers that claim is incorrect. 
> >Compilers inline function calls and optimize code not on narrow cases but 
> >aggressively and massively. The libraries are typically written in manner to 
> >support it. Naive code can use some construct that makes it hard for 
> >compiler. Profilers have shown me plenty of that during decades.
> 
> Inlined functions still have code to be executed. You can't get an API 
> translation layer down to zero instructions if you're converting to complex 
> types such as std::string.

Why the code has to convert anything to std::string for to call legacy API
that takes char*? You were arguing with my claim that "Every standard
library template has methods to provide raw pointers if some legacy
API that needs those is used."  Those methods do not do anything complex
and so are typically inlined into just passing pointer to legacy API.   
Converting iterator to pointer is no operation as the address value
is same. 

> >> >easier to read. The hand-written code is commonly less efficient, more 
> >> >verbose, more error-prone, harder for compiler to optimize and maintainer 
> >> >to fix. 
> >> Really? Here's some code from a utility I wrote that reads network data into 
> > 
> >> a u_char frame buffer. Feel free to tell us how using std::string or similar 
> > 
> >> would improve the speed or make the code any more readable: 
> > 
> >Odd request. The std::string is meant for processing texts. If someone puts 
> >some other data into it then they make their life harder, not easier.
> Not something that occured to you when you were asking what the point of 
> char* was.

There is not only std::string. Standard library contains  std::array<char, N>,
std::vector<char> etc. I honestly don't use raw pointers much ... for more
than 15 years already.

> > 
> >> 
> >> switch((rlen = read(bpf_fd,frame_buffer,frame_buffsize))) 
> >> { 
> >> case 0: 
> >> assert(0); 
> > 
> >That asserts that there are never end of file?
> Its reading a berkeley packet filter intercepting UDP packets which has got to 
> this point via select() first. If read() returns 0 at this point then something 
> is fucked inside the API or OS.
> >> case -1: 
> >> perror("ERROR: read()"); 
> >> exit(1); 
> > 
> >Any error ends the program?
> Yes, because it can't progress. Its a client, not a server.
> >Further code assumes that all read packets fit to buffer. I don't have such 
> >code 
> >What embedded device it is that dies down on usual situations? Speed or 
> >readability matter only after it is useful.
> Point proven I think.

Some sub-part of some function I do not see usage for proves some point?

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

#85762

On Sat, 30 Jul 2022 19:07:58 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Saturday, 30 July 2022 at 17:23:52 UTC+3, Mut...@dastardlyhq.com wrote:
>> Inlined functions still have code to be executed. You can't get an API 
>> translation layer down to zero instructions if you're converting to complex 
>> types such as std::string.
>
>Why the code has to convert anything to std::string for to call legacy API
>that takes char*? You were arguing with my claim that "Every standard
>library template has methods to provide raw pointers if some legacy
>API that needs those is used."  Those methods do not do anything complex
>and so are typically inlined into just passing pointer to legacy API.   

So whats the point then?

>> >some other data into it then they make their life harder, not easier.
>> Not something that occured to you when you were asking what the point of 
>> char* was.
>
>There is not only std::string. Standard library contains  std::array<char, N>,
>std::vector<char> etc. I honestly don't use raw pointers much ... for more
>than 15 years already.

Because as I said, you obviously don't do system or low level programming.
Certainly you've never been anywhere near code for a device driver.

>> >readability matter only after it is useful.
>> Point proven I think.
>
>Some sub-part of some function I do not see usage for proves some point?

There was enough code to provide us with your amazing alternative to not using
pointers. After all, you don't need pointers, right?

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

#85763

On Sunday, 31 July 2022 at 10:22:22 UTC+3, Mut...@dastardlyhq.com wrote:
> On Sat, 30 Jul 2022 19:07:58 -0700 (PDT) 
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Saturday, 30 July 2022 at 17:23:52 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> Inlined functions still have code to be executed. You can't get an API 
> >> translation layer down to zero instructions if you're converting to complex 
> >> types such as std::string. 
> > 
> >Why the code has to convert anything to std::string for to call legacy API 
> >that takes char*? You were arguing with my claim that "Every standard 
> >library template has methods to provide raw pointers if some legacy 
> >API that needs those is used." Those methods do not do anything complex 
> >and so are typically inlined into just passing pointer to legacy API.

> So whats the point then?

Point is to remove possibility to do something stupid by typo. Raw pointer
can be used in lot of different roles and there are no role where all the
operations of it make sense. In C++ these operations don't compile. 
So it++ is internally doing different things for std::set and for std::array but
I don't need to think about those details. A std::array does not silently
decay to iterator of first element and that iterator does not implicitly
convert into pointer of base class sub-object ... so I don't need to worry
about those possibilities. For unfortunate legacy there is implicit 
constructor from char* to std::string. That may cause some illusions,
that usually do not matter. If these matter then use std::string_view. 

> >> >some other data into it then they make their life harder, not easier. 
> >> Not something that occured to you when you were asking what the point of 
> >> char* was. 
> > 
> >There is not only std::string. Standard library contains std::array<char, N>, 
> >std::vector<char> etc. I honestly don't use raw pointers much ... for more 
> >than 15 years already.
> Because as I said, you obviously don't do system or low level programming. 
> Certainly you've never been anywhere near code for a device driver.
> >> >readability matter only after it is useful. 
> >> Point proven I think. 
> > 
> >Some sub-part of some function I do not see usage for proves some point?
> There was enough code to provide us with your amazing alternative to not using 
> pointers. After all, you don't need pointers, right?

There was enough code to see that it is for something I don't sell. Raw pointers
I avoid, for rather long time. There are nothing amazing in it, just bit easier and
safer to  program.

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

#85765

On Sun, 31 Jul 2022 06:07:00 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Sunday, 31 July 2022 at 10:22:22 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Sat, 30 Jul 2022 19:07:58 -0700 (PDT) 
>> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
>> >On Saturday, 30 July 2022 at 17:23:52 UTC+3, Mut...@dastardlyhq.com wrote: 
>> >> Inlined functions still have code to be executed. You can't get an API 
>> >> translation layer down to zero instructions if you're converting to
>complex 
>> >> types such as std::string. 
>> > 
>> >Why the code has to convert anything to std::string for to call legacy API 
>> >that takes char*? You were arguing with my claim that "Every standard 
>> >library template has methods to provide raw pointers if some legacy 
>> >API that needs those is used." Those methods do not do anything complex 
>> >and so are typically inlined into just passing pointer to legacy API.
>
>> So whats the point then?
>
>Point is to remove possibility to do something stupid by typo. Raw pointer

Example?

>> >Some sub-part of some function I do not see usage for proves some point?
>> There was enough code to provide us with your amazing alternative to not
>using 
>> pointers. After all, you don't need pointers, right?
>
>There was enough code to see that it is for something I don't sell. Raw

You don't sell? What?

>pointers
>I avoid, for rather long time. There are nothing amazing in it, just bit
>easier and
>safer to  program.

You can't always avoid pointers unless you only do high level programming.

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

#85773

On Sunday, 31 July 2022 at 19:37:00 UTC+3, mut...@dastardlyhq.com wrote:
> On Sun, 31 Jul 2022 06:07:00 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Sunday, 31 July 2022 at 10:22:22 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> On Sat, 30 Jul 2022 19:07:58 -0700 (PDT) 
> >> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >> >On Saturday, 30 July 2022 at 17:23:52 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> >> Inlined functions still have code to be executed. You can't get an API 
> >> >> translation layer down to zero instructions if you're converting to 
> >complex 
> >> >> types such as std::string. 
> >> > 
> >> >Why the code has to convert anything to std::string for to call legacy API 
> >> >that takes char*? You were arguing with my claim that "Every standard 
> >> >library template has methods to provide raw pointers if some legacy 
> >> >API that needs those is used." Those methods do not do anything complex 
> >> >and so are typically inlined into just passing pointer to legacy API. 
> > 
> >> So whats the point then? 
> > 
> >Point is to remove possibility to do something stupid by typo. Raw pointer
> 
> Example?

Good programmer makes at least one typo in every 10 lines of code. Weak
programmer lot more. If you have ever tried to program something then you
have plenty of examples. Now if compiler does compile that typo then hopefully
unit test catches it. If unit tests lack the check then it goes to testers and
so on. Price of fixing it grows the farther it reaches and the longer it takes to
discover it. So when interface of type provides only operations that make sense,
then resulting program is less expensive, there are no differences in performance.  

> >> >Some sub-part of some function I do not see usage for proves some point? 
> >> There was enough code to provide us with your amazing alternative to not 
> >using 
> >> pointers. After all, you don't need pointers, right? 
> > 
> >There was enough code to see that it is for something I don't sell. Raw
> 
> You don't sell? What?

I sell software. Have had share in company for close to 30 years. Too sloppy
code causes more issues than opportunities to raise wealth. World is already
full to brim of weak code.

> >pointers 
> >I avoid, for rather long time. There are nothing amazing in it, just bit 
> >easier and 
> >safer to program.
> You can't always avoid pointers unless you only do high level programming.

True. Avoiding is hard at very low level for what standard library does not
contain good tools. Then we have to write such tools and so to deal with
pointers ourselves and better abstract these away ourselves. These are
usually pointers to volatile on such cases.

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

#85748

Öö Tiib <ootiib@hot.ee> wrote:
> On Friday, 29 July 2022 at 15:27:58 UTC+3, Juha Nieminen wrote:
>> 
>> You were talking about "slowdowns", so let's talk about slowdowns.
> 
> Yes lets consider:
> 
> #include <iostream>
> #include <string>
> #include <string_view>
> using namespace std::literals;
> 
> int main() {
> // we have fully compile time literals in language
> constexpr auto first_name = "Bernhard"sv, last_name = "Shaw"sv;

He said "std::string literal", not "std::string_view literal".

If he meant the latter then fine, but my response was made assuming he
meant what he wrote.

> So why we need char* ?

Sometimes having a pointer is more useful than having whatever
string_view is. Also, string_view is not yet universally supported, so
if you are eg. writing a library for others to use it might still be
a good idea to not demand it. char* is also useful when interfacing
with C libraries (or the C++ standard library functions that were
"inherited" from C, such as fopen().).

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

#85754

On Saturday, 30 July 2022 at 01:47:34 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote: 
> > On Friday, 29 July 2022 at 15:27:58 UTC+3, Juha Nieminen wrote: 
> >> 
> >> You were talking about "slowdowns", so let's talk about slowdowns. 
> > 
> > Yes lets consider: 
> > 
> > #include <iostream> 
> > #include <string> 
> > #include <string_view> 
> > using namespace std::literals; 
> > 
> > int main() { 
> > // we have fully compile time literals in language 
> > constexpr auto first_name = "Bernhard"sv, last_name = "Shaw"sv;
> He said "std::string literal", not "std::string_view literal". 
> 
> If he meant the latter then fine, but my response was made assuming he 
> meant what he wrote.

Fair enough. The std::string may be used in constant evaluation
in C++20 but only if it is destroyed by the end of that evaluation. So
no constexpr std::string literals are possible. 

> > So why we need char* ?
> 
> Sometimes having a pointer is more useful than having whatever 
> string_view is. Also, string_view is not yet universally supported, so 
> if you are eg. writing a library for others to use it might still be 
> a good idea to not demand it. char* is also useful when interfacing 
> with C libraries (or the C++ standard library functions that were 
> "inherited" from C, such as fopen().).

Yes, it was in boost around 2015 IIRC (from what it was taken to std)
but there are projects that have to use even older compilers. That
is still exception rather than rule.

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

#85738

On Friday, 29 July 2022 at 10:57:06 UTC+3, Juha Nieminen wrote:
> Paavo Helde <ees...@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.) 

In such cases the cost may be hidden from eye in C++ because of legacy
implicit conversion from char [const] * to std::string. If performance matters
then I suggest to use std::string_view that knows length, has no dynamic
allocations, does no implicit conversions or copies, can be constexpr. All
three issues removed and bonus. The code will look less elegant but will
usually beat both std::string and char* in performance. That was the
preposition that it matters. 

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

You can write overload that takes std::string_view when performance
matters. 

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

The std string is typically 32 bytes for cache friendliness and contains very
small strings consisting of up to 23 characters locally as small string
optimisation so it must be quite a case. But of course use 
std::array<char, 16> if that suits you better. That is orthogonal to char*.
 
> (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.)

Yes. Profile and when it matters do whatever. No silver bullets.

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

#85750

On 7/29/2022 9:56 AM, Juha Nieminen wrote:
> 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.

That, and below, is generally true for a generic dynamic container. 
However, std::string is not a generic container. It is a very specific 
and very optimized container of chars.
So, if you use a decent implementation of std the performance of 
std::string and char* is usually pretty close.
Then, of course there are always corner cases where char* is faster, as 
there are cases where knowing the length in advance is a deal breaker.
I'd regard these as the proverbial exceptions that confirm the rule (use 
std::string in C++ and char* in C, that is).

  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]

#85764

Manfred <noname@add.invalid> wrote:
> That, and below, is generally true for a generic dynamic container. 
> However, std::string is not a generic container. It is a very specific 
> and very optimized container of chars.
> So, if you use a decent implementation of std the performance of 
> std::string and char* is usually pretty close.

I don't know if you are referring to it, but many people seem to think that
"short string optimization" makes std::string pretty much as efficient
as an array of char (for strings that are short enough).

They fail to take into consideration that short string optimization
requires conditionals in almost all member functons that access the
string data. Conditionals are not free.

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

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

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

csiph-web