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

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

Some ideas about c?

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

Contents

  Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-17 23:23 +0300
    Re: Some ideas about c? Ian Collins <ian-news@hotmail.com> - 2017-05-18 08:40 +1200
    Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-17 23:00 +0200
      Re: Some ideas about c? supercat@casperkitty.com - 2017-05-17 14:59 -0700
        Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 00:08 +0200
          Re: Some ideas about c? supercat@casperkitty.com - 2017-05-17 22:09 -0700
            Re: Some ideas about c? Ian Collins <ian-news@hotmail.com> - 2017-05-18 18:22 +1200
            Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 12:36 +0200
              Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 03:53 -0700
                Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 14:24 +0200
                  Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 08:37 -0400
                    Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 05:47 -0700
                    Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 15:20 +0200
                      Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 06:28 -0700
                      Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-18 13:56 +0000
                        Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 16:30 +0200
                          Re: Some ideas about c? Thiago Adams <thiago.adams@gmail.com> - 2017-05-18 07:45 -0700
                            Re: Some ideas about c? Richard Heathfield <rjh@cpax.org.uk> - 2017-05-18 16:08 +0100
                              Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 08:15 -0700
                                Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 11:46 -0400
                                  Re: Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-18 21:33 +0300
                                    Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 15:29 -0400
                                    Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-19 01:23 +0200
                                      Re: Some ideas about c? Thiago Adams <thiago.adams@gmail.com> - 2017-05-18 18:12 -0700
                              Re: Some ideas about c? Thiago Adams <thiago.adams@gmail.com> - 2017-05-18 10:08 -0700
                            Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-19 00:39 +0200
                              Re: Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-19 14:27 +0300
                                Re: Some ideas about c? David Brown <david.brown@hesbynett.no> - 2017-05-19 13:41 +0200
                                  Re: Some ideas about c? Richard Heathfield <rjh@cpax.org.uk> - 2017-05-19 13:04 +0100
                                  Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 10:00 -0700
                                Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-19 14:14 +0200
                      Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 11:33 -0400
                        Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 08:47 -0700
                        Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 08:48 -0700
                          Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 09:02 -0700
                            Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 10:52 -0700
                          Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 15:35 -0400
                            Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 14:01 -0700
                              Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 17:38 -0400
                                Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 15:54 -0700
                                  Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 22:17 -0400
                  Re: Some ideas about c? John Bode <jfbode1029@gmail.com> - 2017-05-18 08:06 -0700
                    Re: Some ideas about c? John Bode <jfbode1029@gmail.com> - 2017-05-18 09:17 -0700
    Re: Some ideas about c? fir <profesor.fir@gmail.com> - 2017-05-17 14:34 -0700
      Re: Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-18 16:16 +0300
    Re: Some ideas about c? Cholo Lennon <chololennon@hotmail.com> - 2017-05-18 10:26 -0300
    Re: Some ideas about c? John Bode <jfbode1029@gmail.com> - 2017-05-18 07:36 -0700
      Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-18 18:23 +0000
        Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-18 21:51 +0100
          Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 12:38 +0000
            Re: Some ideas about c? supercat@casperkitty.com - 2017-05-19 07:44 -0700
              Re: Some ideas about c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 16:45 +0100
                Re: Some ideas about c? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-19 21:59 -0700
              Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 10:06 -0700
                Re: Some ideas about c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 18:18 +0100
                  Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 11:59 -0700
                    Re: Some ideas about c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 21:05 +0100
            Re: Some ideas about c? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-19 12:42 -0400
              Re: Some ideas about c? Richard Heathfield <rjh@cpax.org.uk> - 2017-05-19 17:54 +0100
              Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 18:52 +0100
            Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 18:51 +0100
              Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 18:55 +0000
                Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 19:58 +0100
                Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 12:12 -0700
              Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 12:01 -0700
      Re: Some ideas about c? Ian Collins <ian-news@hotmail.com> - 2017-05-19 08:22 +1200
        Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-18 21:53 +0100
        Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 12:36 +0000
          Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 18:54 +0100
            Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 18:58 +0000
              Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 12:18 -0700

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

#110231 — Some ideas about c?

Well I am a newbie yet I have not decided yet if I should start c or c++
Please tell me your ideas

---
This email has been checked for viruses by AVG.
http://www.avg.com

[toc] | [next] | [standalone]

#110232

On 05/18/17 08:23 AM, Vassilis Spiliopoulos wrote:
> Well I am a newbie yet I have not decided yet if I should start c or c++

In part it depends what you want to do.  If you are just learning, learn 
both so you can form your own opinions.

-- 
Ian

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

#110233

On Wed, 17 May 2017 23:23:15 +0300
Vassilis Spiliopoulos <vassilis@vask1lux.de> wrote:

> Well I am a newbie yet I have not decided yet if I should start c or c++
> Please tell me your ideas

Nobody write true C++ programs since nobody really master C++.

Just compare how bloated C++ (~1300 pages by ~50 lines) is Vs C (~700 pages
by ~45 lines).

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

The C++ language ripped off the C language with the addition of bad concepts
like Apple ripped off free BSD code to sell PC and phones to retards including
its BadOS.

Really nobody should ruine his entire life to master C++.

Just quickly learn C and be creative! ;-)

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

#110241

On Wednesday, May 17, 2017 at 4:03:25 PM UTC-5, GOTHIER Nathan wrote:
> Just compare how bloated C++ (~1300 pages by ~50 lines) is Vs C (~700 pages
> by ~45 lines).

Compare either of those to a 1974 C reference manual (31 pages)

   https://www.bell-labs.com/usr/dmr/www/cman.pdf

Although there have been a few useful changes since then, I'm not sure that
the language has become 50 times as useful as the 1974 version.

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

#110242

On Wed, 17 May 2017 14:59:35 -0700 (PDT)
supercat@casperkitty.com wrote:

> On Wednesday, May 17, 2017 at 4:03:25 PM UTC-5, GOTHIER Nathan wrote:
> > Just compare how bloated C++ (~1300 pages by ~50 lines) is Vs C (~700 pages
> > by ~45 lines).
> 
> Compare either of those to a 1974 C reference manual (31 pages)
> 
>    https://www.bell-labs.com/usr/dmr/www/cman.pdf
> 
> Although there have been a few useful changes since then, I'm not sure that
> the language has become 50 times as useful as the 1974 version.

The C Reference Manual by Dennis RITCHIE doesn't include the C Standard Library
definition. I'm pretty sure even these days some people think the C language is
more than 20 times as useful as the 1974 version thanks to the library like
some people think the C++ language is more than twice as useful as C thanks to
the STL.

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

#110256

On Wednesday, May 17, 2017 at 5:12:04 PM UTC-5, GOTHIER Nathan wrote:
> The C Reference Manual by Dennis RITCHIE doesn't include the C Standard Library
> definition. I'm pretty sure even these days some people think the C language is
> more than 20 times as useful as the 1974 version thanks to the library like
> some people think the C++ language is more than twice as useful as C thanks to
> the STL.

Parts of the standard libraries are useful, but many parts are just plain
horribly designed.  Further, there are many application fields where only
small portions of the standard libraries get used at all, and relatively
few parts would be indispensable.  Having sets of common libraries is
helpful, but trying to have a one-size-fits-all approach that ignores
features that are available on many systems and needed for many applications
(e.g. character-at-a-time console input) is not particularly helpful.

A key feature of the 1974 C which set it apart from other languages of
the time was that given access to just a few OS primitives or abilities,
almost everything in the Standard library could be accomplished entirely
in C code.  Nowadays some compiler writers have an attitude that programmers
shouldn't expect to be able to use memory as one type and then recycle it
for use as another without using malloc/free or other such functions, but
reading K&R it would seem one of the things Ritchie was really proud of was
that his language allowed programmers to do precisely that (I've not seen
a Pascal book describe how to do such a thing in Pascal, for example).

IMHO, C would be much better if it were somewhat better subdivided into a
core language with a variety of optional features.  Many features should be
expected in almost any quality implementation, but implementations that are
subject to extreme resource constraints or other such considerations would
not be required to support them all.  Failure to acknowledge features that
are supported by many but not all implementations fragments the language far
more than would recognition that there should be more than two kinds of
implementation.

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

#110257

On 05/18/17 05:09 PM, supercat@casperkitty.com wrote:
> On Wednesday, May 17, 2017 at 5:12:04 PM UTC-5, GOTHIER Nathan wrote:
>> The C Reference Manual by Dennis RITCHIE doesn't include the C Standard Library
>> definition. I'm pretty sure even these days some people think the C language is
>> more than 20 times as useful as the 1974 version thanks to the library like
>> some people think the C++ language is more than twice as useful as C thanks to
>> the STL.
>
> Parts of the standard libraries are useful, but many parts are just plain
> horribly designed.

That's because they weren't designed, they evolved :)

-- 
Ian

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

#110263

On Wed, 17 May 2017 22:09:36 -0700 (PDT)
supercat@casperkitty.com wrote:

> Parts of the standard libraries are useful, but many parts are just plain
> horribly designed.  Further, there are many application fields where only
> small portions of the standard libraries get used at all, and relatively
> few parts would be indispensable.  Having sets of common libraries is
> helpful, but trying to have a one-size-fits-all approach that ignores
> features that are available on many systems and needed for many applications
> (e.g. character-at-a-time console input) is not particularly helpful.

That's even worse with the generic programming paradigm pushed by the STL.
Generic programming aims at being universal but lacks the effiency of a well
designed solution. Once more, the programmer is forced to adapt his approach to
fit the generic logic without any added value.


> A key feature of the 1974 C which set it apart from other languages of
> the time was that given access to just a few OS primitives or abilities,
> almost everything in the Standard library could be accomplished entirely
> in C code.  Nowadays some compiler writers have an attitude that programmers
> shouldn't expect to be able to use memory as one type and then recycle it
> for use as another without using malloc/free or other such functions, but
> reading K&R it would seem one of the things Ritchie was really proud of was
> that his language allowed programmers to do precisely that (I've not seen
> a Pascal book describe how to do such a thing in Pascal, for example).

Indeed. I assume that's why C provides the linkage notion bound to the a scope
in the hope that programmers could reuse every piece of memory.


> IMHO, C would be much better if it were somewhat better subdivided into a
> core language with a variety of optional features.  Many features should be
> expected in almost any quality implementation, but implementations that are
> subject to extreme resource constraints or other such considerations would
> not be required to support them all.  Failure to acknowledge features that
> are supported by many but not all implementations fragments the language far
> more than would recognition that there should be more than two kinds of
> implementation.

Although a standard library give a powerful impulse to the adoption of regular
features, however its extension is problematic.

In my eyes, the C standard shouldn't include a standard library in order to
concentrate all the effort on the true language definition. I would prefer the
C standard library to be a side project with a modular approach such as
different parts of the library can optionally be implemented and extended over
the time with a global scheme in mind.

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

#110264

On Thursday, May 18, 2017 at 11:40:00 AM UTC+1, GOTHIER Nathan wrote:
>
> That's even worse with the generic programming paradigm pushed by the STL.
> Generic programming aims at being universal but lacks the effiency of a well
> designed solution. Once more, the programmer is forced to adapt his approach to
> fit the generic logic without any added value.
>
Templates are  efficient.
The problem is that when a type is templated, you don't know what symbols
ans operations the type needs to support. This isn't such a problem with STL -
once you know you need a default constructor and a copy constructor and
a move constructor for heavyweight objects, you know. But when non-standard
library programmers create their own generics, it becomes a big problem.
> 
> In my eyes, the C standard shouldn't include a standard library in order to
> concentrate all the effort on the true language definition. I would prefer the
> C standard library to be a side project with a modular approach such as
> different parts of the library can optionally be implemented and extended over
> the time with a global scheme in mind.
>
The malloc family of functions are special. A pure function may need to call
malloc and free. Any other subroutines can be supplied or folded into the
main function.
But really you want standard math functions and a few standard string handling
functions, the first because they are a pain to write, the second because otherwise
everyone has their own version of strcpy() which accepts parameters in a different
order or copies to and from dynamic memory or takes a length parameter. Any
of those things you can build a case for, but it's best to stick to a standard.

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

#110265

On Thu, 18 May 2017 03:53:29 -0700 (PDT)
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:

> Templates are  efficient.
> The problem is that when a type is templated, you don't know what symbols
> ans operations the type needs to support. This isn't such a problem with STL -
> once you know you need a default constructor and a copy constructor and
> a move constructor for heavyweight objects, you know. But when non-standard
> library programmers create their own generics, it becomes a big problem.

Templates are as efficient as a generic logic can be but a specifically
designed interface is way more efficient. It's like pretending a general
purpose circuit such as a microprocessor is the only way to process all kind of
data but why do so many people buy graphic cards?

The only reason for the STL to be is to lower the bar for unskilled
programmers. 


> The malloc family of functions are special. A pure function may need to call
> malloc and free. Any other subroutines can be supplied or folded into the
> main function.
> But really you want standard math functions and a few standard string handling
> functions, the first because they are a pain to write, the second because otherwise
> everyone has their own version of strcpy() which accepts parameters in a different
> order or copies to and from dynamic memory or takes a length parameter. Any
> of those things you can build a case for, but it's best to stick to a standard.

I doubt that all C programmers need float, complex type or even string utilities.

Once more, if it's difficult to write it doesn't mean it needs to be standard
but only you need a library to avoid the pain.

Do we need GTK+ to be included in the C standard? I don't think so.

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

#110266

On 5/18/2017 8:24 AM, GOTHIER Nathan wrote:
> On Thu, 18 May 2017 03:53:29 -0700 (PDT)
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> 
>> Templates are  efficient.
>> The problem is that when a type is templated, you don't know what symbols
>> ans operations the type needs to support. This isn't such a problem with STL -
>> once you know you need a default constructor and a copy constructor and
>> a move constructor for heavyweight objects, you know. But when non-standard
>> library programmers create their own generics, it becomes a big problem.
> 
> Templates are as efficient as a generic logic can be but a specifically
> designed interface is way more efficient. It's like pretending a general
> purpose circuit such as a microprocessor is the only way to process all kind of
> data but why do so many people buy graphic cards?
> 
> The only reason for the STL to be is to lower the bar for unskilled
> programmers. 
>

No, STL is like any other library - including the standard C libraries.
It is there so that people don't have to keep rewriting the same code
over and over again.

You could also code a more optimized version of printf() every time you
need to output something.  Or more efficient versions of malloc() and
free() for your specific memory allocation needs.  But do you?

> 
>> The malloc family of functions are special. A pure function may need to call
>> malloc and free. Any other subroutines can be supplied or folded into the
>> main function.
>> But really you want standard math functions and a few standard string handling
>> functions, the first because they are a pain to write, the second because otherwise
>> everyone has their own version of strcpy() which accepts parameters in a different
>> order or copies to and from dynamic memory or takes a length parameter. Any
>> of those things you can build a case for, but it's best to stick to a standard.
> 
> I doubt that all C programmers need float, complex type or even string utilities.
> 

I would say every serious C programmer needs floating point numbers and
string utilities at some point.  Complex type, not so much.

> Once more, if it's difficult to write it doesn't mean it needs to be standard
> but only you need a library to avoid the pain.
> 
> Do we need GTK+ to be included in the C standard? I don't think so.
> 

There are lots of special purpose libraries I find handy but don't need
to necessarily be part of the standard.  IMHO GTK+ falls into that category.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#110269

On Thursday, May 18, 2017 at 1:37:34 PM UTC+1, Jerry Stuckle wrote:
> 
> I would say every serious C programmer needs floating point numbers and
> string utilities at some point.  Complex type, not so much.
> 
I usually test out a new graphics system by writing a Mandelbrot set browser
for it. But the only complex numbers I use for real are in Fourier transforms,
where you an't actually store them as complex, at least not easily, because
of the way the transform shuffles data for you.
>
> > Do we need GTK+ to be included in the C standard? I don't think so.
> > 
> 
> There are lots of special purpose libraries I find handy but don't need
> to necessarily be part of the standard.  IMHO GTK+ falls into that category.
> 
GTK+ is like Baby X. A general purpose library for writing graphical user
interfaces. But to include it a) blows up the size of the C standard and
b) triggers UI wars with the major manufacturers seeing your standard as
a threat to their brand equity in their own operating systems.

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

#110275

On Thu, 18 May 2017 08:37:41 -0400
Jerry Stuckle <jstucklex@attglobal.net> wrote:

> No, STL is like any other library - including the standard C libraries.
> It is there so that people don't have to keep rewriting the same code
> over and over again.

Wrong. The STL is by definition standard, thus any C++ implementation is forced
to provide the STL that's why C++ is so much bloated.

 
> You could also code a more optimized version of printf() every time you
> need to output something.  Or more efficient versions of malloc() and
> free() for your specific memory allocation needs.  But do you?

Whenever I use printf() or any kind of predefined function, it is only because
it fit my requirements. If I need a better elaborated function, I write my own.


> I would say every serious C programmer needs floating point numbers and
> string utilities at some point.  Complex type, not so much.

Do you suggest C programmers on limited hardware aren't serious? ...


> There are lots of special purpose libraries I find handy but don't need
> to necessarily be part of the standard.  IMHO GTK+ falls into that category.

IMHO the C standard library too.

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

#110277

On Thursday, May 18, 2017 at 2:24:08 PM UTC+1, GOTHIER Nathan wrote:
> 
> > I would say every serious C programmer needs floating point numbers and
> > string utilities at some point.  Complex type, not so much.
> 
> Do you suggest C programmers on limited hardware aren't serious? ...
> 
> 
"Serious" is a bad word. A program can be extremely simple, just controlling an
led or a thermostat, but still serious. The thermostat might be attached to a
medical device which needs to be kept at the exact temperature if the
patient is to survive.

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

#110278

GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>On Thu, 18 May 2017 08:37:41 -0400
>Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>> No, STL is like any other library - including the standard C libraries.
>> It is there so that people don't have to keep rewriting the same code
>> over and over again.
>
>Wrong. The STL is by definition standard, thus any C++ implementation is forced
>to provide the STL that's why C++ is so much bloated.

We get it.   You hate C++.   Give the rest of us a break
and keep it to yourself.

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

#110283

On Thu, 18 May 2017 13:56:00 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> We get it.   You hate C++.   Give the rest of us a break
> and keep it to yourself.

Wrong. You're a C++ cheerleader but feel frustrated that the STL can't
solve automagically your incompetence. I can garantee you C too.

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

#110287

On Thursday, May 18, 2017 at 11:33:10 AM UTC-3, GOTHIER Nathan wrote:
> On Thu, 18 May 2017 13:56:00 GMT
> (Scott Lurndal) wrote:
> 
> > We get it.   You hate C++.   Give the rest of us a break
> > and keep it to yourself.
> 
> Wrong. You're a C++ cheerleader but feel frustrated that the STL can't
> solve automagically your incompetence. I can garantee you C too.

I have some difficulties with C that I don't have with C++.

Sample:

typedef struct Node
{
 ...
} Node;

I do by hand a function called Node_Destroy used it 
to free any resource from Node. (destructor)
And Node_Delete(p) that call Node_Destroy and then free(p);

The problem is that I need to create the same function 
again and again for each type. The same for Swap.
In C++ this can be resolved by template and overriding.

Destroy(Node*p)
Destroy(Other*p) 

template<class T>
void Delete(T*p)
{
 Destroy(p); 
 free(p);
}
The same happens for containers.


What do you do?

"inline code by hand" can solve the problem

Node *p ;
...
Node_Destroy(p);
free(p);


The same for Create:

Node * p = Node_Create();

"inline code by hand"

Node* p = malloc(sizeof * p);
if (p)
{
  *p = NODE_INIT;
}

So the problem is do a lot of lines or write the same code again and again.

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

#110290

On 18/05/17 15:45, Thiago Adams wrote:
> On Thursday, May 18, 2017 at 11:33:10 AM UTC-3, GOTHIER Nathan wrote:
>> On Thu, 18 May 2017 13:56:00 GMT
>> (Scott Lurndal) wrote:
>>
>>> We get it.   You hate C++.   Give the rest of us a break
>>> and keep it to yourself.
>>
>> Wrong. You're a C++ cheerleader but feel frustrated that the STL can't
>> solve automagically your incompetence. I can garantee you C too.
>
> I have some difficulties with C that I don't have with C++.
>
> Sample:
>
> typedef struct Node
> {
>  ...
> } Node;
>
> I do by hand a function called Node_Destroy used it
> to free any resource from Node. (destructor)
> And Node_Delete(p) that call Node_Destroy and then free(p);

If Node_Destroy() has to release resources that are specific to Node, 
you have to write that Node-specific releasing code /somewhere/. And if 
it doesn't, why have it in the first place?

> The problem is that I need to create the same function
> again and again for each type.

If it's the same function, use the same function. If it's not the same 
function, the differences have to be programmed /somewhere/.

> The same for Swap.
> In C++ this can be resolved by template and overriding.
>
> Destroy(Node*p)
> Destroy(Other*p)
>
> template<class T>
> void Delete(T*p)
> {
>  Destroy(p);
>  free(p);
> }
> The same happens for containers.

Yes, but Destroy(p) is a NOP. That is, you haven't shown code for it, so 
what are we to assume about it but that it's empty?

> What do you do?
>
> "inline code by hand" can solve the problem
>
> Node *p ;
> ...
> Node_Destroy(p);
> free(p);
>
>
> The same for Create:
>
> Node * p = Node_Create();
>
> "inline code by hand"
>
> Node* p = malloc(sizeof * p);
> if (p)
> {
>   *p = NODE_INIT;
> }
>
> So the problem is do a lot of lines or write the same code again and again.

You have to write the code somewhere. The overhead of writing a malloc 
call and brace pair in a "constructor" is very often trivial in 
comparison to the effort involved in writing a typical initialisation 
block, so this smacks of premature (and pointless) optimisation.

By the way, for some people at least, typing "boilerplate" code can be a 
relaxing way to keep the fingers occupied while one is thinking about 
what to put between the braces.

Molehill, thy name is Everest.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#110291

On Thursday, May 18, 2017 at 4:09:00 PM UTC+1, Richard Heathfield wrote:
>
> Yes, but Destroy(p) is a NOP. That is, you haven't shown code for it, so 
> what are we to assume about it but that it's empty?
> 
In C++ you normally use stl "containers" for non-scalar members, which
95% of the time means std::vectors, but can also be things like unique_ptrs
if you need to build a graph. (The unique_ptr is like a C pointer which "owns"
a memory allocation). When the object's lifetime ends, it is automatically
destroyed. But the code is in the C++ standard library, you rarely have to
write a destructor by yourself.

In fact virtually all the complexity of C++ comes down to automatic destructors.
It's the one thing C can't imitate with a bit of different syntax and boilerplate
code.

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

#110299

On 5/18/2017 11:15 AM, Malcolm McLean wrote:
> On Thursday, May 18, 2017 at 4:09:00 PM UTC+1, Richard Heathfield wrote:
>>
>> Yes, but Destroy(p) is a NOP. That is, you haven't shown code for it, so 
>> what are we to assume about it but that it's empty?
>>
> In C++ you normally use stl "containers" for non-scalar members, which
> 95% of the time means std::vectors, but can also be things like unique_ptrs
> if you need to build a graph. (The unique_ptr is like a C pointer which "owns"
> a memory allocation). When the object's lifetime ends, it is automatically
> destroyed. But the code is in the C++ standard library, you rarely have to
> write a destructor by yourself.
> 
> In fact virtually all the complexity of C++ comes down to automatic destructors.
> It's the one thing C can't imitate with a bit of different syntax and boilerplate
> code.
> 

This is one of the things I like about C++.  For instance, right now I'm
using collection classes like std::vector.  This is a self-sizing array
and elements can be accessed with standard array notation.  I'm also
using std::map, which is like vector except the index can be anything -
not just an integer.

Within them I have struct equivalents which contain string data.  String
lengths can vary anywhere from a few characters (or a null string) to
hundreds of characters - the strings are read in, so there's no
predicting the length.  Rather than use char[2000] for every message and
waste huge amounts of memory, in C I would dynamically allocate the
lengths I need.

But then I have to ensure all of that is cleaned up when it is no longer
needed.  This is exactly the type of operation which leads to memory
leaks.  In C++, it's automatic.  If I delete an element of the vector or
map, all memory associated with it is deleted automatically.  And if I
delete the entire vector or map, all elements are deleted automatically.

Now all of this automated processing does have its downsides - it is
slower than the equivalent in C.  The generated code is also larger.
These two reasons alone make C a better solution in many instances than
C++, and why I still write a fair amount of C code.  OTOH, the code is
cleaner with fewer lines, and therefor less prone to errors.

But both languages have their advantages and disadvantages, and both
languages have their uses.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

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

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

csiph-web