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

#110321

Jerry Stuckle <jstucklex@attglobal.net> Wrote in message:
> 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
> ==================
> 

So ummm I should learn both and decide what is more useful?
-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

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

#110326

On 5/18/2017 2:33 PM, Vassilis Spiliopoulos wrote:
> 
> So ummm I should learn both and decide what is more useful?
> 

There is no "more useful".  Each language has its advantages and
disadvantages.  Some projects will work better in C, some in C++ (and
some in an entirely different language).

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

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

#110344

On Thu, 18 May 2017 21:33:48 +0300 (GMT+03:00)
Vassilis Spiliopoulos <vassilis@vask1lux.de> wrote:

> So ummm I should learn both and decide what is more useful?

No, just learn real programming (your d*ck with your knife) in C and let C++
cheerleaders wasting their time to adapt their buggy code to generic programming
with the STL.

If you want to be true programmer you have to embrace difficulties learning from
them and building your own portfolio of solutions called "skills". If you don't
want to solve problems you shouldn't be a programmer but a code user like a lot
a pretending C++ programmers. Using a machine gun won't make you a true hunter.

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

#110346

On Thursday, May 18, 2017 at 8:26:25 PM UTC-3, GOTHIER Nathan wrote:
> On Thu, 18 May 2017 21:33:48 +0300 (GMT+03:00)
> Vassilis Spiliopoulos  wrote:
> 
> > So ummm I should learn both and decide what is more useful?
> 
> No, just learn real programming (your d*ck with your knife) in C and let C++
> cheerleaders wasting their time to adapt their buggy code to generic programming
> with the STL.
> 
> If you want to be true programmer you have to embrace difficulties learning from
> them and building your own portfolio of solutions called "skills". If you don't
> want to solve problems you shouldn't be a programmer but a code user like a lot
> a pretending C++ programmers. Using a machine gun won't make you a true hunter.



I don´t use reference counter.
What was trying to compare is two lines of "inline code"  versus a function that is almost the same for 
each type. (C++ makes easy to create just one template)

Type* p = malloc(sizeof * p);
if (p)
{
  *p = TYPE_INIT;
}

Type_Destroy(p);
free(p);

versus:

Type* p = Type_Create();

Type_Delete(p);

One advantage of Type_Create is 
if a have memory leak I can  check in 
debug using a counter.

static int Type_Instances = 0;

Type* Type_Create()
{
 ...
 Type_Instances++;
}

void Type_Delete(Type* p)
{
 Type_Instances--;
}

At the end of program
ASSERT(Type_Instances == 0);

Without to find-replace each malloc for Type*.
The disadvantage is to write many times the same code
_Create and Delete changing only the type.

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

#110315

On Thursday, May 18, 2017 at 12:09:00 PM UTC-3, Richard Heathfield wrote:
> 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?

This is the pattern I use in C:

typedef struct Node
{ 
   String Name;
};
#define NODE_INIT {STRING_INIT}

//Init is when I use  C++ or C < C99

//With C99 I could use
//#define NODE_INIT (Node) {STRING_INIT}
//*p = NODE_INIT;

void Node_Init(Node* p)
{  
  Node temp = NODE_INIT;
  *p = temp;
}

void Node_Destroy(Node* p)
{
  String_Destroy(&p->Name);
}


void Node_Swap(Node* a, Node* b)
{
  Node temp = *a;
  *a = *b; 
  *b = temp;
}

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


void Node_Delete(Node* p)
{
  if (p)
  {
     Node_Destroy(p);    
     free(p);
  }
}

Basically, the repeated code is Create, Delete and Swap.
I see some advantages of using Create instead of two lines.
For instance, let's say I have some leak. I can create a counter
in Create and Delete for each type or a global one.
(Of course I don't this all the time, but sometimes is useful)

Beside this, I also have repeated code for containers.

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

#110337

On Thu, 18 May 2017 07:45:49 -0700 (PDT)
Thiago Adams <thiago.adams@gmail.com> wrote:

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

I'm afraid you're blinded by your C++ approach which prevent you to do the
right thing in C.

It's not that difficult to write a generic structure in C that can be managed
by a constructor/destructor with a reference counter and pointers. That's what
is done by the STL but it's not the best way to manage any specific problem
without similarities.

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

#110368

On 5/19/2017 1:39 AM, GOTHIER Nathan wrote:
> On Thu, 18 May 2017 07:45:49 -0700 (PDT)
> Thiago Adams <thiago.adams@gmail.com> wrote:
>
>> I have some difficulties with C that I don't have with C++.
>
> I'm afraid you're blinded by your C++ approach which prevent you to do the
> right thing in C.
>
> It's not that difficult to write a generic structure in C that can be managed
> by a constructor/destructor with a reference counter and pointers. That's what
> is done by the STL but it's not the best way to manage any specific problem
> without similarities.
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
Thank you everyone for your help.I signed up for C Associate Programmer 
course at the C++ Institute.

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

#110369

On 19/05/17 13:27, Vassilis Spiliopoulos wrote:
> On 5/19/2017 1:39 AM, GOTHIER Nathan wrote:
>> On Thu, 18 May 2017 07:45:49 -0700 (PDT)
>> Thiago Adams <thiago.adams@gmail.com> wrote:
>>
>>> I have some difficulties with C that I don't have with C++.
>>
>> I'm afraid you're blinded by your C++ approach which prevent you to do
>> the
>> right thing in C.
>>
>> It's not that difficult to write a generic structure in C that can be
>> managed
>> by a constructor/destructor with a reference counter and pointers.
>> That's what
>> is done by the STL but it's not the best way to manage any specific
>> problem
>> without similarities.
>>
>> ---
>> This email has been checked for viruses by AVG.
>> http://www.avg.com
>>
> Thank you everyone for your help.I signed up for C Associate Programmer
> course at the C++ Institute.

So rather than deciding between learning C from C programmers, or
learning C++ from C++ programmers, you compromised on learning C from
C++ programmers?

Well, good luck anyway.

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

#110371

On 19/05/17 12:41, David Brown wrote:
> On 19/05/17 13:27, Vassilis Spiliopoulos wrote:
>> On 5/19/2017 1:39 AM, GOTHIER Nathan wrote:
>>> On Thu, 18 May 2017 07:45:49 -0700 (PDT)
>>> Thiago Adams <thiago.adams@gmail.com> wrote:
>>>
>>>> I have some difficulties with C that I don't have with C++.
>>>
>>> I'm afraid you're blinded by your C++ approach which prevent you to do
>>> the
>>> right thing in C.
>>>
>>> It's not that difficult to write a generic structure in C that can be
>>> managed
>>> by a constructor/destructor with a reference counter and pointers.
>>> That's what
>>> is done by the STL but it's not the best way to manage any specific
>>> problem
>>> without similarities.
>>>
>>> ---
>>> This email has been checked for viruses by AVG.
>>> http://www.avg.com
>>>
>> Thank you everyone for your help.I signed up for C Associate Programmer
>> course at the C++ Institute.
>
> So rather than deciding between learning C from C programmers, or
> learning C++ from C++ programmers, you compromised on learning C from
> C++ programmers?

It beats the hell out of learning C++ from C programmers!

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

#110391

David Brown <david.brown@hesbynett.no> writes:
> On 19/05/17 13:27, Vassilis Spiliopoulos wrote:
[...]
>> Thank you everyone for your help.I signed up for C Associate Programmer
>> course at the C++ Institute.
>
> So rather than deciding between learning C from C programmers, or
> learning C++ from C++ programmers, you compromised on learning C from
> C++ programmers?

I'm not sure I'd read too much into the fact that the organization is
called the "C++ Institute".  It's entirely possible that the course is a
perfectly good one.

But that's not the way I'd bet.  Here's some discussion about a
different course offered by the same organization:
https://www.quora.com/Are-C++-certificates-offered-by-CPP-Institute-worth-it

Vassilis: Are you referring to this course?
https://www.netacad.com/courses/cla-programming-c/

I presume it's not possible to see the contents of the course without
paying for it, so I can't offer a direct opinion on how good it is
(and I had never heard of the "C++ Institute" until a few minutes ago).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#110372

On Fri, 19 May 2017 14:27:32 +0300
Vassilis Spiliopoulos <vassilis@vask1lux.de> wrote:

> Thank you everyone for your help.I signed up for C Associate Programmer 
> course at the C++ Institute.

Good luck in debugging bad C practices with C++ monkeys... you'll learn to
write good C from a lot of broken code. :o)

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

#110296

On 5/18/2017 9:20 AM, GOTHIER Nathan wrote:
> 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.
> 

That is correct.  And the string functions, I/O functions (printf(),
etc.) and lots of other functions are defined in the C standard.  All
standard C implementations are required to provide them.

But you don't have to use STL, just like you don't have to use the
standard C libraries.

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

Which is exactly why you should use STL.

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

Nope, but they don't do *only* limited hardware, and quite a bit of
limited hardware does support floating point numbers.  Plus all I know
of support string functions.

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

So, you aren't forced to use it.  You can write your own version of
every function in the C library.

Personally, I'd rather make more productive use of my time than to
repeatedly reinvent the wheel.  The same is true for programmers on any
project I manage.

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

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

#110301

On Thursday, May 18, 2017 at 4:33:15 PM UTC+1, Jerry Stuckle wrote:
> 
> So, you aren't forced to use it.  You can write your own version of
> every function in the C library.
> 
> Personally, I'd rather make more productive use of my time than to
> repeatedly reinvent the wheel.  The same is true for programmers on any
> project I manage.
> 
If you ask a programmer for milk in your coffee he'll go and set up a
dairy farm.

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

#110303

On Thursday, May 18, 2017 at 10:33:15 AM UTC-5, Jerry Stuckle wrote:
> Nope, but they don't do *only* limited hardware, and quite a bit of
> limited hardware does support floating point numbers.  Plus all I know
> of support string functions.

Zero-terminated strings are an okay choice for read-only strings, but not
really for code that needs to actively manipulate strings.  Doing any kind
of string manipulation requires keeping track of the length, and if one is
keeping track of the length the terminating zero is just a wasted byte.

There are times when floating-point can be useful, but for many kinds of
applications on smaller systems, the time required for an implementer to
provide floating-point support could likely be better spent on other things
like efficient computations of the form int8*int16/int8, int8*int16>>8,
etc. along with variations that support rounding.

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

#110305

On Thursday, May 18, 2017 at 4:48:53 PM UTC+1, supe...@casperkitty.com wrote:
> On Thursday, May 18, 2017 at 10:33:15 AM UTC-5, Jerry Stuckle wrote:
> > Nope, but they don't do *only* limited hardware, and quite a bit of
> > limited hardware does support floating point numbers.  Plus all I know
> > of support string functions.
> 
> Zero-terminated strings are an okay choice for read-only strings, but not
> really for code that needs to actively manipulate strings.  Doing any kind
> of string manipulation requires keeping track of the length, and if one is
> keeping track of the length the terminating zero is just a wasted byte.
> 
Depends what you are doing. Strings have to mean something, and if
scanning the string for the nul byte to get the length is going to make the
difference, how many strings do you have in your program and how were they
generated? (As a bioinformatician of course one possible answer is "genetic
data")

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

#110317

On Thursday, May 18, 2017 at 11:02:48 AM UTC-5, Malcolm McLean wrote:
> On Thursday, May 18, 2017 at 4:48:53 PM UTC+1, supercat wrote:
> > Zero-terminated strings are an okay choice for read-only strings, but not
> > really for code that needs to actively manipulate strings.  Doing any kind
> > of string manipulation requires keeping track of the length, and if one is
> > keeping track of the length the terminating zero is just a wasted byte.
> > 
> Depends what you are doing. Strings have to mean something, and if
> scanning the string for the nul byte to get the length is going to make the
> difference, how many strings do you have in your program and how were they
> generated? (As a bioinformatician of course one possible answer is "genetic
> data")

General-purpose code to safely append data to a string buffer (a rather
common operation) needs to know three things: (1) where the buffer is;
(2) how long a string is; (3) how big the buffer is.  Zero-terminated
strings allow #2 to be derived from #1, slowly, and do nothing to assist
with #3.  Prefixed strings, by contrast, make it possible to have use
multiple string representations including a structure like e.g.

     struct STRING_DESCRIPTOR {
       char header_byte; // Will be e.g. 255 for string descriptor
       char descriptor_subtype;
       char *data;
       size_t length, size; };

and then have code which expects a string look at the header byte and
either use the data following it (if it isn't 255) or else interpret
its address as a STRING_DESCRIPTOR* and use the data indicated thereby.
Such an approach would make it possible to have a function like sprintf
automatically sense the size of its destination and, depending upon the
descriptor_subtype, do things like realloc() the destination storage as
needed.

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

#110327

On 5/18/2017 11:48 AM, supercat@casperkitty.com wrote:
> On Thursday, May 18, 2017 at 10:33:15 AM UTC-5, Jerry Stuckle wrote:
>> Nope, but they don't do *only* limited hardware, and quite a bit of
>> limited hardware does support floating point numbers.  Plus all I know
>> of support string functions.
> 
> Zero-terminated strings are an okay choice for read-only strings, but not
> really for code that needs to actively manipulate strings.  Doing any kind
> of string manipulation requires keeping track of the length, and if one is
> keeping track of the length the terminating zero is just a wasted byte.
>

If you want to use the string libraries, you will use null-terminated
strings.  No separate length field (more than one byte if the string is
> 255 characters) needed, and no need to ensure the length field is
always synchronized with the actual string.

And the string libraries work as well as anything for manipulating
strings, even without a length field.

But I might suggest you switch to PASCAL.  It keeps track of the length
of strings (and most implementations require at least two bytes per
string for the length field).

> There are times when floating-point can be useful, but for many kinds of
> applications on smaller systems, the time required for an implementer to
> provide floating-point support could likely be better spent on other things
> like efficient computations of the form int8*int16/int8, int8*int16>>8,
> etc. along with variations that support rounding.
> 

If the compiler supports the C standard, it will include floating point
support (either in hardware or software).  If it doesn't, it's not
standards compliant.

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

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

#110333

On Thursday, May 18, 2017 at 2:35:48 PM UTC-5, Jerry Stuckle wrote:
> On 5/18/2017 11:48 AM, supercat wrote:
> If you want to use the string libraries, you will use null-terminated
> strings.  No separate length field (more than one byte if the string is
> > 255 characters) needed, and no need to ensure the length field is
> always synchronized with the actual string.

On 1980s Macintosh C compilers, a string literal starting with "\p"
would be preceded by a length byte.  An absolutely essential extension
when writing Macintosh applications, since the OS functions all expected
pointers to length-prefixed strings.

Functions which needed to operate on strings longer than 256 bytes generally
used handles to objects which the OS could relocate as needed so as to avoid
fragmentation.

> And the string libraries work as well as anything for manipulating
> strings, even without a length field.

They're pretty terrible for most purposes.  If one wants to concatenate
two strings and doesn't knows the lengths, memcpy() will be faster and in
pretty much every way better than strcat().  If one doesn't know the
lengths, but somehow knows that the destination is big enough, strcat()
might be usable I suppose, but using strlen on strings whose length isn't
known, ensuring that adequate space exists, and then using memcpy, seems
like a better approach than giving the strings to strcat and hoping nothing
blows up.

> But I might suggest you switch to PASCAL.  It keeps track of the length
> of strings (and most implementations require at least two bytes per
> string for the length field).

There are some things 1980s C could do better than 1980s Pascal, but many
others where Pascal was better.

> > There are times when floating-point can be useful, but for many kinds of
> > applications on smaller systems, the time required for an implementer to
> > provide floating-point support could likely be better spent on other things
> > like efficient computations of the form int8*int16/int8, int8*int16>>8,
> > etc. along with variations that support rounding.
> > 
> 
> If the compiler supports the C standard, it will include floating point
> support (either in hardware or software).  If it doesn't, it's not
> standards compliant.

True, because the Standard imposes requirements that make some
implementations less suitable for their intended purpose than they
otherwise would be.  Given that the Standard doesn't require that a
freestanding implementation be capable of *any* observable behavior,
requiring that such implementations pass floating-point variadic
arguments using a type with a 40+-bit significant doesn't seem very
helpful.

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

#110335

On 5/18/2017 5:01 PM, supercat@casperkitty.com wrote:
> On Thursday, May 18, 2017 at 2:35:48 PM UTC-5, Jerry Stuckle wrote:
>> On 5/18/2017 11:48 AM, supercat wrote:
>> If you want to use the string libraries, you will use null-terminated
>> strings.  No separate length field (more than one byte if the string is
>>> 255 characters) needed, and no need to ensure the length field is
>> always synchronized with the actual string.
> 
> On 1980s Macintosh C compilers, a string literal starting with "\p"
> would be preceded by a length byte.  An absolutely essential extension
> when writing Macintosh applications, since the OS functions all expected
> pointers to length-prefixed strings.
>

So, who cares what non-compliant compilers did?  A properly designed C
library would handle the specific OS requirement without breaking
conformance.

> Functions which needed to operate on strings longer than 256 bytes generally
> used handles to objects which the OS could relocate as needed so as to avoid
> fragmentation.
> 

See above.

>> And the string libraries work as well as anything for manipulating
>> strings, even without a length field.
> 
> They're pretty terrible for most purposes.  If one wants to concatenate
> two strings and doesn't knows the lengths, memcpy() will be faster and in
> pretty much every way better than strcat().  If one doesn't know the
> lengths, but somehow knows that the destination is big enough, strcat()
> might be usable I suppose, but using strlen on strings whose length isn't
> known, ensuring that adequate space exists, and then using memcpy, seems
> like a better approach than giving the strings to strcat and hoping nothing
> blows up.
> 

C is not a great language for handling strings.  But adding a length to
the string wouldn't make it any better.

And memcpy does not add the trailing null character.

>> But I might suggest you switch to PASCAL.  It keeps track of the length
>> of strings (and most implementations require at least two bytes per
>> string for the length field).
> 
> There are some things 1980s C could do better than 1980s Pascal, but many
> others where Pascal was better.
> 

So, I would suggest you program in PASCAL.

>>> There are times when floating-point can be useful, but for many kinds of
>>> applications on smaller systems, the time required for an implementer to
>>> provide floating-point support could likely be better spent on other things
>>> like efficient computations of the form int8*int16/int8, int8*int16>>8,
>>> etc. along with variations that support rounding.
>>>
>>
>> If the compiler supports the C standard, it will include floating point
>> support (either in hardware or software).  If it doesn't, it's not
>> standards compliant.
> 
> True, because the Standard imposes requirements that make some
> implementations less suitable for their intended purpose than they
> otherwise would be.  Given that the Standard doesn't require that a
> freestanding implementation be capable of *any* observable behavior,
> requiring that such implementations pass floating-point variadic
> arguments using a type with a 40+-bit significant doesn't seem very
> helpful.
> 

The standard never defines HOW an operation is performed.  Just WHAT the
operation is.

We all know you don't like C.  So why don't you find a language you do
like and stop wasting bandwidth bitching about C?  No one here cares.

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

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

#110339

On Thursday, May 18, 2017 at 4:38:19 PM UTC-5, Jerry Stuckle wrote:
> On 5/18/2017 5:01 PM, supercat wrote:
> > On 1980s Macintosh C compilers, a string literal starting with "\p"
> > would be preceded by a length byte.  An absolutely essential extension
> > when writing Macintosh applications, since the OS functions all expected
> > pointers to length-prefixed strings.
> 
> So, who cares what non-compliant compilers did?  A properly designed C
> library would handle the specific OS requirement without breaking
> conformance.

The Standard allows compilers to add additional backslash escapes as an
extension.  The implementation came with bundled libraries for file I/O,
but and I think its OS interface libraries included some functions that
would convert C strings to Pascal strings and then perform an OS request
(e.g. to render a string onto a GrafPort using its current selected font)
but calling a function which would copy a C string to a separate buffer
and then pass that to the OS was slower than simply using Pascal strings
when communicating with OS code that needed them.

> > Functions which needed to operate on strings longer than 256 bytes generally
> > used handles to objects which the OS could relocate as needed so as to avoid
> > fragmentation.
> 
> See above.

Using OS-managed handles made it possible to grow and shrink large strings
without fragmentation killing everything, at least if there weren't too many
immovable objects fragmenting the free store.  While code could use malloc,
realloc, and free, application performance would often be better if programs
used the system's relocatable memory handles instead when practical.

> > They're pretty terrible for most purposes.  If one wants to concatenate
> > two strings and doesn't knows the lengths, memcpy() will be faster and in
> > pretty much every way better than strcat().  If one doesn't know the
> > lengths, but somehow knows that the destination is big enough, strcat()
> > might be usable I suppose, but using strlen on strings whose length isn't
> > known, ensuring that adequate space exists, and then using memcpy, seems
> > like a better approach than giving the strings to strcat and hoping nothing
> > blows up.
> > 
> 
> C is not a great language for handling strings.  But adding a length to
> the string wouldn't make it any better.

Allowing the byte identified by a "string pointer" to indicate whether the
pointer identifies:

  A string of a given length that precisely fills its buffer

  An empty buffer of a given size

  A buffer of a given size which is not completely full, and has the number
  of slack bytes stored at the end.

  A string descriptor which starts with a couple bytes describing what it
  is, along with a pointer to the buffer, its size, the length of string
  therein, and optional information allowing the buffer to be resized.

would make it possible to have a function like "strcat" whose first argument
can be a fixed-size buffer, a descriptor of a fixed-size block of storage,
or a descriptor for a resizable block of storage, and whose second argument
could be any kind of string or string descriptor, without having to pass it
anything except two string pointers.  A string buffer would have to be
initialized prior to use, but that would only require storing 1-5 bytes to
it, depending upon length.

The biggest obstacle to using such strings is the lack of any decent way
to include string literals in-line within C code.  If the language supported
static compound literals and a construct like:

   (constExpr ? (void*)&staticCompoundLiteral1 : (void*)&staticCompoundLiteral2)

would only generate one of them, code could be written more cleanly using
prefixed strings than C strings.

> And memcpy does not add the trailing null character.

It will copy any trailing null character which is present in the original if
the null byte is included in the size.

> We all know you don't like C.  So why don't you find a language you do
> like and stop wasting bandwidth bitching about C?  No one here cares.

Low-level C is the best language for embedded systems.  Today's compiler
writers, however, prefer to process a different language which is less
suitable for such purposes.

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

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

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

csiph-web