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

Groups > comp.lang.c > #163577 > unrolled thread

"C Is The Greenest Programming Language" by: Chris Lott

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

Contents

  "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-22 16:19 -0600
    Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-22 14:58 -0800
      Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-23 07:10 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-23 13:12 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-24 10:54 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 12:01 +0100
              Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-24 13:58 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-23 13:23 -0800
    Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-22 18:25 -0500
      Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-23 07:21 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Thiago Adams <thiago.adams@gmail.com> - 2021-11-23 04:50 -0800
        Re: "C Is The Greenest Programming Language" by: Chris Lott Guillaume <message@bottle.org> - 2021-11-23 17:56 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-24 10:55 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-23 19:00 -0600
          Re: "C Is The Greenest Programming Language" by: Chris Lott scott@slp53.sl.home (Scott Lurndal) - 2021-11-24 16:04 +0000
      Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 11:43 +0100
    Re: "C Is The Greenest Programming Language" by: Chris Lott om@iki.fi (Otto J. Makela) - 2021-11-23 14:17 +0200
      Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-23 16:53 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott om@iki.fi (Otto J. Makela) - 2021-11-24 11:40 +0200
          Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-24 15:49 +0000
      Re: "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-23 19:01 -0600
        Re: "C Is The Greenest Programming Language" by: Chris Lott om@iki.fi (Otto J. Makela) - 2021-11-24 11:33 +0200
          Re: "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-24 15:28 -0600
    Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-23 14:39 +0100
      Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-23 16:55 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 12:28 -0500
          Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-23 19:05 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 13:41 -0500
              Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-23 19:53 +0100
                Re: "C Is The Greenest Programming Language" by: Chris Lott Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-11-23 16:31 -0800
                Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 21:27 -0500
                  Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-24 18:32 +0100
                    Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-24 12:54 -0500
                      Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-24 20:52 +0100
                        Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-24 15:13 -0500
                          Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-25 19:13 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-11-23 16:25 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-24 15:48 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-24 11:54 -0500
              Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-25 11:19 +0000
                Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-25 11:46 +0000
                  Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-25 15:57 +0000
                Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-25 07:04 -0500
                  Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-25 15:59 +0000
                  Re: "C Is The Greenest Programming Language" by: Chris Lott Thiago Adams <thiago.adams@gmail.com> - 2021-11-26 03:37 -0800
    Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-23 16:03 +0100
      Re: "C Is The Greenest Programming Language" by: Chris Lott gazelle@shell.xmission.com (Kenny McCormack) - 2021-11-23 15:50 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 17:51 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-23 17:00 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 12:36 -0500
            Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 19:24 +0100
              Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 13:50 -0500
                Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 20:02 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-23 20:59 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-23 20:50 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott Ian Collins <ian-news@hotmail.com> - 2021-11-24 11:18 +1300
                Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-23 22:58 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 23:46 +0100
                Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-24 13:59 +0000
                  Re: "C Is The Greenest Programming Language" by: Chris Lott antispam@math.uni.wroc.pl - 2021-12-11 13:25 +0000
                    Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-12-11 14:54 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-25 12:12 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 23:35 +0100
              Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-24 15:30 +0100
                Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-24 14:43 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-23 20:29 +0100
      Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-23 16:14 +0000
      Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 11:56 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-24 10:14 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-24 19:55 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 21:13 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 21:11 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 21:17 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-24 20:42 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 23:25 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott antispam@math.uni.wroc.pl - 2021-12-11 14:07 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-12-11 18:46 +0000
                [OT] Lisp.  Was: "C Is The Greenest Programming Language" by: Chris Lott Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-11 20:11 +0000
                  Re: "C Is The Greenest Programming Language" Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-13 17:59 -0800
                    Re: "C Is The Greenest Programming Language" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-14 03:18 +0000
                      Re: "C Is The Greenest Programming Language" Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-16 10:57 -0800
                        Re: "C Is The Greenest Programming Language" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-16 22:03 +0000
                          Re: "C Is The Greenest Programming Language" Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-20 02:40 -0800
                            Re: "C Is The Greenest Programming Language" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-20 12:05 +0000
    Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-24 14:12 -0800
      Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-25 12:00 +0100
    Re: "C Is The Greenest Programming Language" by: Chris Lott Paavo Helde <eesnimi@osa.pri.ee> - 2021-12-05 22:51 +0200
      Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-05 19:20 -0800
        Re: "C Is The Greenest Programming Language" by: Chris Lott Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-06 01:52 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-06 12:19 -0800
            Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-06 12:27 -0800
      Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-12-06 12:28 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott Paavo Helde <eesnimi@osa.pri.ee> - 2021-12-06 13:40 +0200
      Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-06 16:21 +0100

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

#163632

On 11/23/2021 6:17 AM, Otto J. Makela wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> 
>> "C Is The Greenest Programming Language" by: Chris Lott
>>     https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
> 
> Perhaps one contributing factor is that not so much development is any
> longer done using C or C++, and the programs that are run (and still
> being developed) were originally created in the era when CPU power was
> much lower than these days, so code optimization was more important.

I write C++ and Fortran code just about every day for our software products.

Lynn

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

#163636

Lynn McGuire <lynnmcguire5@gmail.com> wrote:

> On 11/23/2021 6:17 AM, Otto J. Makela wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>> "C Is The Greenest Programming Language" by: Chris Lott
>>>     https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>> Perhaps one contributing factor is that not so much development
>> is any longer done using C or C++, and the programs that are run
>> (and still being developed) were originally created in the era
>> when CPU power was much lower than these days, so code
>> optimization was more important.
>
> I write C++ and Fortran code just about every day for our software
> products.

Do you consider this to be a common situation?
-- 
   /* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
  /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
 /* Mail: Mechelininkatu 26 B 27,  FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

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

#163663

On 11/24/2021 3:33 AM, Otto J. Makela wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> 
>> On 11/23/2021 6:17 AM, Otto J. Makela wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>>> "C Is The Greenest Programming Language" by: Chris Lott
>>>>      https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>>> Perhaps one contributing factor is that not so much development
>>> is any longer done using C or C++, and the programs that are run
>>> (and still being developed) were originally created in the era
>>> when CPU power was much lower than these days, so code
>>> optimization was more important.
>>
>> I write C++ and Fortran code just about every day for our software
>> products.
> 
> Do you consider this to be a common situation?

I really have no idea.

Lynn

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

#163593

Am 22.11.2021 um 23:19 schrieb Lynn McGuire:
> "C Is The Greenest Programming Language" by: Chris Lott
>     https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
> 
> "Have you ever wondered if there is a correlation between a computer’s 
> energy consumption and the choice of programming languages? Well, a 
> group Portuguese university researchers did and set out to quantify it. 
> Their 2017 research paper entitled Energy Efficiency across Programming 
> Languages / How Do Energy, Time, and Memory Relate?  may have escaped 
> your attention, as it did ours."
>     https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf
> 
> "Abstract: This paper presents a study of the runtime, memory usage and 
> energy consumption of twenty seven well-known soft- ware languages. We 
> monitor the performance of such lan- guages using ten different 
> programming problems, expressed in each of the languages. Our results 
> show interesting find- ings, such as, slower/faster languages consuming 
> less/more energy, and how memory usage influences energy consump- tion. 
> We show how to use our results to provide software engineers support to 
> decide which language to use when energy efficiency is a concern."

Developing in C is a magnitude more effort than in C++, and if you've
the right programming-style you get the same code speed like in C. And
sometimes you're even faster in C++ and in C you'd shoot yourself in
your head instead of implementing the complexity you can handle in C++
in minutes.

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

#163605

On Tue, 23 Nov 2021 14:39:08 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Developing in C is a magnitude more effort than in C++, and if you've

That depends on the problem. If you're writing code that needs to store a
lot of structured data then C wouldn't be your first choice of language. But
if you're writing something that simply interfaces with system calls then 
there's probably not much if any extra effort in using C over C++.

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

#163608

On 11/23/21 11:55 AM, DozingDog@thekennel.co wrote:
> On Tue, 23 Nov 2021 14:39:08 +0100
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Developing in C is a magnitude more effort than in C++, and if you've
> 
> That depends on the problem. If you're writing code that needs to store a
> lot of structured data then C wouldn't be your first choice of language. But
> if you're writing something that simply interfaces with system calls then
> there's probably not much if any extra effort in using C over C++.
> 

I would disagree. With a decent compiler, C code can generate close to 
assembly level optimizations for most problems. (Maybe it doesn't have 
good support for defining Multiple Datapath Single Instruction 
sequences, but a GOOD compiler maybe be able to detect and generate this).

ANYTHING in terms of data-structures that another language can generate, 
you can generate in C.

The big disadvantage is that YOU as the programmer need to deal with a 
lot of the issues rather than to compiler doing things for you, but that 
is exactly why you can do things possibly more efficiently then the 
compiler. You could have always generated the same algorithm that the 
compiler did.

The one point where the compiler can do better is if there is a piece 
like instruction sequencing to optimize performance, but that is where 
the C language gives the implementation the freedom to adjust things to 
allow for that.

The C language, with the common extensions, give you the power to do as 
well as any other language.

Now, if you want to talk of the efficiency of WRITING the code, (as 
opposed to executing it) all this power it gives you is a negative, 
which seems to be what you are talking about.

If we want to talk 'Greenness', we need to define the development/usage 
life cycle of the code.

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

#163611

> ANYTHING in terms of data-structures that another language can generate, 
> you can generate in C.

With a lot of effort compared to C++.

> The big disadvantage is that YOU as the programmer need to deal with a 
> lot of the issues rather than to compiler doing things for you, but that 
> is exactly why you can do things possibly more efficiently then the 
> compiler. You could have always generated the same algorithm that the 
> compiler did.

Why shoul one use sth. different than std::vector<>, std::string,
std::unordered_map<> ... ? There are no opportunities to make the
same more efficient.

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

#163613

On 11/23/21 1:05 PM, Bonita Montero wrote:
>> ANYTHING in terms of data-structures that another language can 
>> generate, you can generate in C.
> 
> With a lot of effort compared to C++.
> 
>> The big disadvantage is that YOU as the programmer need to deal with a 
>> lot of the issues rather than to compiler doing things for you, but 
>> that is exactly why you can do things possibly more efficiently then 
>> the compiler. You could have always generated the same algorithm that 
>> the compiler did.
> 
> Why shoul one use sth. different than std::vector<>, std::string,
> std::unordered_map<> ... ? There are no opportunities to make the
> same more efficient.
> 

Except where there are.

For instance, I regularly use a variant of std:string that the char 
const* constructor checks if the input is from 'read only' memory, and 
if it is reuses that data instead of making a copy, at least until in 
wants to change it. This saves me a LOT of memory in embedded systems 
where most of my 'string' data is constant, but some spedific cases need 
to dynamically compute the string.

The C++ standard library is very good code for the general case. There 
can be cases where specific application requirements make alternative 
better.

As I said, the fundamental issue is the trade off of final execution 
efficiency for efficiency in writing the code.

C++ keeps a lot of the efficiencies of C, and adds some significant 
'power' to the expresiveness. But sometimes implementing the C++ 
features directly in C while needing more coding by the programmer can 
make some things more efficient.

For example, rather than letting the C++ class system implicitly handle 
the 'vtable' for a class, there are tricks you can do to make some 
operation more efficient in C with an explicit vtable (at the expense of 
it adding all the explicit code). Things like changing the 'type' of a 
structure to that of another compatible type with just a change of the 
vtable pointer.

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

#163616

Am 23.11.2021 um 19:41 schrieb Richard Damon:

> For instance, I regularly use a variant of std:string that the char 
> const* constructor checks if the input is from 'read only' memory, and 
> if it is reuses that data instead of making a copy, at least until in 
> wants to change it. ...

Then use string_view.

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

#163629

On Tuesday, 23 November 2021 at 18:53:16 UTC, Bonita Montero wrote:
> Am 23.11.2021 um 19:41 schrieb Richard Damon: 
> 
> > For instance, I regularly use a variant of std:string that the char 
> > const* constructor checks if the input is from 'read only' memory, and 
> > if it is reuses that data instead of making a copy, at least until in
> > wants to change it. ... 
> 
> Then use string_view.
>
Herb Sutter did a video on C++ a while back, where he discussed how to
write "Employee::SetName" in C++. As he said, it's a crime if there is no
easy answer. But in fact there is no easy answer.
In real programming you'd write SetName(std::string const &name), or
maybe SetName(const char *name). But that's not optimal, and it creates
problems with throwable exceptions. 
But messing about with string_views, move semantics, and the like adds
complexity to your program. And the program is unlikely to fail because
your string handling isn't fast enough.

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

#163633

On 11/23/21 1:53 PM, Bonita Montero wrote:
> Am 23.11.2021 um 19:41 schrieb Richard Damon:
> 
>> For instance, I regularly use a variant of std:string that the char 
>> const* constructor checks if the input is from 'read only' memory, and 
>> if it is reuses that data instead of making a copy, at least until in 
>> wants to change it. ...
> 
> Then use string_view.
> 

Doesn't work.

I have a lot of long lived object that store a string with a 'name' of 
the object.

Most are created with a fixed compile time name that I pass as a const 
char* string to a read only literal.

A few cases need to dynaically create a name based on specific usages, 
so these need that name stored as a dynamic value, but that memory wants 
to be reclaimed if/when the long lived object does go away.

string_view doesn't help here, as when I create the few dynamic names, 
there is no place to keep that char array that is holding the name.

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

#163653

Am 24.11.2021 um 03:27 schrieb Richard Damon:
> On 11/23/21 1:53 PM, Bonita Montero wrote:
>> Am 23.11.2021 um 19:41 schrieb Richard Damon:
>>
>>> For instance, I regularly use a variant of std:string that the char 
>>> const* constructor checks if the input is from 'read only' memory, 
>>> and if it is reuses that data instead of making a copy, at least 
>>> until in wants to change it. ...
>>
>> Then use string_view.
>>
> 
> Doesn't work.
> 
> I have a lot of long lived object that store a string with a 'name' of 
> the object.
> 
> Most are created with a fixed compile time name that I pass as a const 
> char* string to a read only literal.
> 
> A few cases need to dynaically create a name based on specific usages, 
> so these need that name stored as a dynamic value, but that memory wants 
> to be reclaimed if/when the long lived object does go away.
> 
> string_view doesn't help here, as when I create the few dynamic names, 
> there is no place to keep that char array that is holding the name.

A class having a variant<string_view, string> member and an interface
to get or modify that string ? F.e. you could add a modify-interface
that does a copy-on-write modification of the string_view state,
chaning it into a string-state ?

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

#163654

On 11/24/21 12:32 PM, Bonita Montero wrote:
> Am 24.11.2021 um 03:27 schrieb Richard Damon:
>> On 11/23/21 1:53 PM, Bonita Montero wrote:
>>> Am 23.11.2021 um 19:41 schrieb Richard Damon:
>>>
>>>> For instance, I regularly use a variant of std:string that the char 
>>>> const* constructor checks if the input is from 'read only' memory, 
>>>> and if it is reuses that data instead of making a copy, at least 
>>>> until in wants to change it. ...
>>>
>>> Then use string_view.
>>>
>>
>> Doesn't work.
>>
>> I have a lot of long lived object that store a string with a 'name' of 
>> the object.
>>
>> Most are created with a fixed compile time name that I pass as a const 
>> char* string to a read only literal.
>>
>> A few cases need to dynaically create a name based on specific usages, 
>> so these need that name stored as a dynamic value, but that memory 
>> wants to be reclaimed if/when the long lived object does go away.
>>
>> string_view doesn't help here, as when I create the few dynamic names, 
>> there is no place to keep that char array that is holding the name.
> 
> A class having a variant<string_view, string> member and an interface
> to get or modify that string ? F.e. you could add a modify-interface
> that does a copy-on-write modification of the string_view state,
> chaning it into a string-state ?
> 

Your getting very heavy now.

It was much simpler to just implement the version of string I wanted, 
which kept a pointer to the data, and an allocation size.

When constructed from a char const* value, it checked if this pointer 
was to the read only block of memory, and if so didn't copy that string, 
but just kept the original pointer, with an allocated size of 0 (to make 
it easy to see if it was a read only string or a writable).

If your use case doesn't fit what the library supports well, you can 
make you own.

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

#163657

>> A class having a variant<string_view, string> member and an interface
>> to get or modify that string ? F.e. you could add a modify-interface
>> that does a copy-on-write modification of the string_view state,
>> chaning it into a string-state ?

> Your getting very heavy now.

Ok, developing a variant-string-class with all constructors,
methods and operators would be complex. But having s simple
variant<string, string_view> is easy.

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

#163660

On 11/24/21 2:52 PM, Bonita Montero wrote:
>>> A class having a variant<string_view, string> member and an interface
>>> to get or modify that string ? F.e. you could add a modify-interface
>>> that does a copy-on-write modification of the string_view state,
>>> chaning it into a string-state ?
> 
>> Your getting very heavy now.
> 
> Ok, developing a variant-string-class with all constructors,
> methods and operators would be complex. But having s simple
> variant<string, string_view> is easy.

Building a variant<string, string_view> may be easy but would be a HOG.

My variant-string class implement all the functionality I needed, and 
none of the stuff I wanted, and saved a LOT of memory as the standard 
string class include a LOT of virtual functions to do things I don't 
need, and my implementation isn't smart enough to do the whole program 
recompile to trim out unneeded virtual functions.

For 1 day of work I saves about 25% of my programs size becuase I could 
drop all the locale support that I didn't need.

The first cut string version was to fix a program to big error for an 
embedded system because std::string pulled in WAY too much code just to 
exist.

The second cut added the const char* string optimization to save a lot 
of ram.

Situation awareness is key here.

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

#163676

> My variant-string class implement all the functionality I needed, and 
> none of the stuff I wanted, and saved a LOT of memory as the standard 
> string class include a LOT of virtual functions to do things I don't 
> need, ...

basic_string<> doesn't include virtual functions and if basic_string<>
would use virtual functions, they would take only one VMT-pointer per
object.

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

#163628

On Tuesday, 23 November 2021 at 18:05:14 UTC, Bonita Montero wrote:
> > ANYTHING in terms of data-structures that another language can generate, 
> > you can generate in C.
> With a lot of effort compared to C++.
> > The big disadvantage is that YOU as the programmer need to deal with a 
> > lot of the issues rather than to compiler doing things for you, but that 
> > is exactly why you can do things possibly more efficiently then the 
> > compiler. You could have always generated the same algorithm that the 
> > compiler did.
> Why shoul one use sth. different than std::vector<>, std::string, 
> std::unordered_map<> ... ? There are no opportunities to make the 
> same more efficient.
>
You don't implement C++ in C. Instead of an std::string, you use a fixed
buffer. That means you'll have problems if the string exceeds buffer length,
but often that's not really a worry - C++ is giving you security it's nice to
have, but you don't actually need.

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

#163649

On Tue, 23 Nov 2021 12:28:12 -0500
Richard Damon <Richard@Damon-Family.org> wrote:
>On 11/23/21 11:55 AM, DozingDog@thekennel.co wrote:
>> On Tue, 23 Nov 2021 14:39:08 +0100
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Developing in C is a magnitude more effort than in C++, and if you've
>> 
>> That depends on the problem. If you're writing code that needs to store a
>> lot of structured data then C wouldn't be your first choice of language. But
>> if you're writing something that simply interfaces with system calls then
>> there's probably not much if any extra effort in using C over C++.
>> 
>
>I would disagree. With a decent compiler, C code can generate close to 
>assembly level optimizations for most problems. (Maybe it doesn't have 

So can a C++ compiler and with modern additions such constexpr C++ can optimise
in ways that C simply can't.

>ANYTHING in terms of data-structures that another language can generate, 
>you can generate in C.

True, but you have to re-invent the wheel each time because frankly the level
of complex data structure library support in the standard library in C is 
woeful. Eg the hsearch() and bsearch() functionality are frankly rubbish (only
1 tree/hash per process!) and Berkeley DB is a PITA to use.

>The big disadvantage is that YOU as the programmer need to deal with a 
>lot of the issues rather than to compiler doing things for you, but that 
>is exactly why you can do things possibly more efficiently then the 
>compiler. You could have always generated the same algorithm that the 
>compiler did.

I doubt I could for example write a RB tree system better than that implemented
in the C++ STL. It has 30 years of refining behind it.

>Now, if you want to talk of the efficiency of WRITING the code, (as 
>opposed to executing it) all this power it gives you is a negative, 
>which seems to be what you are talking about.

Indeed, but your argument that C always produces more efficient code than C++
probably hasn't been true for 20 years.

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

#163652

On 11/24/21 10:48 AM, DozingDog@thekennel.co wrote:
> On Tue, 23 Nov 2021 12:28:12 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>> On 11/23/21 11:55 AM, DozingDog@thekennel.co wrote:
>>> On Tue, 23 Nov 2021 14:39:08 +0100
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Developing in C is a magnitude more effort than in C++, and if you've
>>>
>>> That depends on the problem. If you're writing code that needs to store a
>>> lot of structured data then C wouldn't be your first choice of language. But
>>> if you're writing something that simply interfaces with system calls then
>>> there's probably not much if any extra effort in using C over C++.
>>>
>>
>> I would disagree. With a decent compiler, C code can generate close to
>> assembly level optimizations for most problems. (Maybe it doesn't have
> 
> So can a C++ compiler and with modern additions such constexpr C++ can optimise
> in ways that C simply can't.
> 
>> ANYTHING in terms of data-structures that another language can generate,
>> you can generate in C.
> 
> True, but you have to re-invent the wheel each time because frankly the level
> of complex data structure library support in the standard library in C is
> woeful. Eg the hsearch() and bsearch() functionality are frankly rubbish (only
> 1 tree/hash per process!) and Berkeley DB is a PITA to use.

Right, I never said it was the BEST way, especially if you include 
programmer productivity.

If your goal is ABSOLUTELY TOP CPU EFFICIENCY, then 'standard libraries' 
become just optional (use only if it IS the best for YOUR job).

Yes, this might mean 3 years of programming to say a millisecond of 
execution, but it still puts the hand crafted code ahead of the higher 
level langauge in RAW efficiency.

> 
>> The big disadvantage is that YOU as the programmer need to deal with a
>> lot of the issues rather than to compiler doing things for you, but that
>> is exactly why you can do things possibly more efficiently then the
>> compiler. You could have always generated the same algorithm that the
>> compiler did.
> 
> I doubt I could for example write a RB tree system better than that implemented
> in the C++ STL. It has 30 years of refining behind it.

So you can directly implement that algorithm in C. yes, it gets messier, 
but you CAN do it.

And, yes, it also means you need to research (or look at implementations 
and 'borrow') the best methods. Lots of programmer effort to get the 
greenest code.

> 
>> Now, if you want to talk of the efficiency of WRITING the code, (as
>> opposed to executing it) all this power it gives you is a negative,
>> which seems to be what you are talking about.
> 
> Indeed, but your argument that C always produces more efficient code than C++
> probably hasn't been true for 20 years.
> 

FLAW: Not ALWAYS, but CAN, big difference.

Yes, C++ idioms can generate complex code faster than C, and allows 
things to be put into libraries that C can't readily do, and thus an 
expert can right the library and 'lend' that expertise to an ordinary 
code by them using the library. A custom coded C version can do just as 
well, because you can express the same instruction sequences in C as 
were generated in C++, you just need to be or explicit about it.

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

#163668

On Wed, 24 Nov 2021 11:54:50 -0500
Richard Damon <Richard@Damon-Family.org> wrote:
>On 11/24/21 10:48 AM, DozingDog@thekennel.co wrote:
>> I doubt I could for example write a RB tree system better than that
>implemented
>> in the C++ STL. It has 30 years of refining behind it.
>
>So you can directly implement that algorithm in C. yes, it gets messier, 
>but you CAN do it.

But there's no guarantee that it would be any faster.

>> Indeed, but your argument that C always produces more efficient code than C++
>
>> probably hasn't been true for 20 years.
>> 
>
>FLAW: Not ALWAYS, but CAN, big difference.
>
>Yes, C++ idioms can generate complex code faster than C, and allows 
>things to be put into libraries that C can't readily do, and thus an 
>expert can right the library and 'lend' that expertise to an ordinary 
>code by them using the library. A custom coded C version can do just as 
>well, because you can express the same instruction sequences in C as 
>were generated in C++, you just need to be or explicit about it.

Not always. eg:

#include <iostream>

constexpr int func(int cnt)
{
        int val = 1;
        while(--cnt) val *= 2;
        return val;
}


int main()
{
        constexpr int val = func(10);
        std::cout << val << std::endl;
        return 0;
}


In C++14 and onwards func() will literally be run by the compiler at compile
time and the result hard coded into the binary. No C compiler can do that not
because the language couldn't do it in theory, but because its never been 
specified in the standard.

[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