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

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

Array allocated on stack or heap

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

Contents

  Array allocated on stack or heap Prashant Shah <pshah.mumbai@gmail.com> - 2017-03-16 22:58 -0700
    Re: Array allocated on stack or heap Barry Schwarz <schwarzb@dqel.com> - 2017-03-16 23:57 -0700
      Re: Array allocated on stack or heap Mark Storkamp <mstorkamp@yahoo.com> - 2017-03-17 12:44 -0500
        Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 11:26 -0700
          Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 20:38 +0100
            Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 16:08 -0400
              Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:03 +0100
                Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 20:54 -0400
    Re: Array allocated on stack or heap John Bode <jfbode1029@gmail.com> - 2017-03-17 12:15 -0700
      Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-17 20:22 +0100
      Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 20:45 +0100
        Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-17 12:59 -0700
        Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-17 21:01 +0100
          Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:12 +0100
            Re: Array allocated on stack or heap jameskuyper@verizon.net - 2017-03-17 16:25 -0700
              Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 17:08 -0700
                Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-17 17:37 -0700
            Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 12:30 +0100
              Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 12:12 +0000
                Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:52 +0100
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 16:51 +0000
                    Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 10:44 +0100
                      Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-20 12:01 +0000
                        Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-20 06:02 -0700
                          Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-20 14:54 +0100
                            Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-20 07:28 -0700
                              Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 16:43 +0100
                              Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-20 09:02 -0700
                                Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 10:11 +0100
                                  Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 02:48 -0700
                                    Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-21 08:19 -0700
                                  Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-21 08:17 -0700
                                    Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-21 09:06 -0700
                                    Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 17:32 +0100
                              Re: Array allocated on stack or heap Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:14 -0500
                                Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-25 16:05 -0700
                                  Re: Array allocated on stack or heap Les Cargill <lcargill99@comcast.com> - 2017-03-25 23:53 -0500
                                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-26 12:30 +0100
                                      Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-26 14:09 -0700
                                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-26 22:17 +0100
                                      Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-26 21:52 -0500
                                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-27 13:06 +0100
                                          Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-27 10:10 -0700
                                          Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 15:56 -0500
                                            Re: Array allocated on stack or heap bartc <bc@freeuk.com> - 2017-03-27 22:48 +0100
                                              Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 19:58 -0500
                          Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-20 14:56 +0100
                        Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 15:34 +0100
                          Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 09:28 -0700
                            Re: Array allocated on stack or heap bart4858@gmail.com - 2017-03-20 13:05 -0700
                              Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 13:53 -0700
                                Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 14:26 -0700
                                Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-20 22:24 +0000
                                  Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 15:44 -0700
                                    Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 02:44 -0700
                                  Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 11:15 +0100
                                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-21 11:12 +0000
                                      Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 04:23 -0700
                                      Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 13:13 +0000
                                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-21 13:38 +0000
                                          Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 15:33 +0100
                                            Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 07:38 -0700
                                          Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 07:35 -0700
                                            Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 15:09 +0000
                Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:05 +0000
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 13:27 +0000
                  Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:26 +0100
                    Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:34 +0000
                      Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:35 +0100
                  Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:36 +0000
                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 14:00 +0000
                      Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 19:00 +0000
                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 19:24 +0000
                          Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 08:45 +1300
                            Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-19 14:32 -0700
                              Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 16:16 +1300
                                Re: Array allocated on stack or heap Gareth Owen <gwowen@gmail.com> - 2017-03-20 18:58 +0000
                              Re: Array allocated on stack or heap raltbos@xs4all.nl (Richard Bos) - 2017-03-24 09:17 +0000
                          Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 20:50 +0000
                Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:10 +0100
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 13:38 +0000
                    Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:49 +0100
                      Re: Array allocated on stack or heap luser droog <luser.droog@gmail.com> - 2017-03-20 07:59 -0700
                Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-19 10:57 -0400
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 16:14 +0000
                    Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-19 15:53 -0400
                      Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 20:37 +0000
                        Re: Array allocated on stack or heap Jean-Marc Bourguet <jm@bourguet.org> - 2017-03-19 23:09 +0100
                          Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 22:38 +0000
                            Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-19 16:21 -0700
                            Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 16:18 +1300
                          Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 11:06 +0100
                    Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 11:00 +0100
                Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-19 08:53 -0700
        Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 16:11 -0400
        Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 13:35 -0700
          Re: Array allocated on stack or heap Chad <cdalten@gmail.com> - 2017-03-17 14:00 -0700
            Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 23:57 +0100
              Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-18 12:42 +1300
                Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:45 +0100
              Re: Array allocated on stack or heap Chad <cdalten@gmail.com> - 2017-03-18 14:17 -0700
                Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-19 19:21 +0100
                  Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-19 15:00 -0700
                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 22:16 +0000
                      Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-19 23:57 +0100
                        Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-19 16:15 -0700
                        Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 12:24 +0100
                      Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-20 13:24 +0000
              Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:21 +0100
        Re: Array allocated on stack or heap John Bode <jfbode1029@gmail.com> - 2017-03-17 14:30 -0700
          Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 23:59 +0100
          Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 21:02 -0400
          Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:26 +0100

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

#106671

On 21/03/17 14:38, BartC wrote:
> On 21/03/2017 13:13, Scott Lurndal wrote:
>> BartC <bc@freeuk.com> writes:
> 
>>> Which RISC processors have more than 16 64-bit registers? (To say
>>> nothing of the various MMX, XMM and YMM registers.)
>>
>> AArch64 has 32 64-bit GPRs.  It also has 32 128-bit SIMD
>> registers with aliases for 8-bit, 16-bit, 32-bit and 64-bit.
> 
> Ah yes, ARM, who seem to have moved the complexity of the instruction
> set into the version numbering schemes instead.
> 
> Apparently ARMV6 architecture is based on the ARM11 processor core.
> While there has been an ARM8 core, and there is now an ARMV8 architecture.
> 
> Of course there is no possibility of confusion!
> 

If you can make sense of Intel's chip numbering, then ARM's should be
easy.  ARMv6, ARMv7, ARMv8, etc., are ISA versions - the logical
processor from the programmer's viewpoint.  ARM7, ARM9, Cortex-M, etc.,
are the core designs that implement one of the ISA's.  It is not
particularly difficult - at least, not for a processor design that
covers so many generations of ISA and so many different cores.

<https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures>

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

#106674

On Tuesday, March 21, 2017 at 4:33:16 PM UTC+2, David Brown wrote:
> On 21/03/17 14:38, BartC wrote:
> > On 21/03/2017 13:13, Scott Lurndal wrote:
> >> BartC <bc@freeuk.com> writes:
> > 
> >>> Which RISC processors have more than 16 64-bit registers? (To say
> >>> nothing of the various MMX, XMM and YMM registers.)
> >>
> >> AArch64 has 32 64-bit GPRs.  It also has 32 128-bit SIMD
> >> registers with aliases for 8-bit, 16-bit, 32-bit and 64-bit.
> > 
> > Ah yes, ARM, who seem to have moved the complexity of the instruction
> > set into the version numbering schemes instead.
> > 
> > Apparently ARMV6 architecture is based on the ARM11 processor core.
> > While there has been an ARM8 core, and there is now an ARMV8 architecture.
> > 
> > Of course there is no possibility of confusion!
> > 
> 
> If you can make sense of Intel's chip numbering, then ARM's should be
> easy.  ARMv6, ARMv7, ARMv8, etc., are ISA versions - the logical
> processor from the programmer's viewpoint.  ARM7, ARM9, Cortex-M, etc.,


You would think that at least Cortex moniker guarantees ARMv7. Before you realize that ARM Cortex M0 is ARMv6T.

> are the core designs that implement one of the ISA's.  It is not
> particularly difficult - at least, not for a processor design that
> covers so many generations of ISA and so many different cores.
> 
> <https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures>

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

#106672

On Tuesday, March 21, 2017 at 3:39:06 PM UTC+2, Bart wrote:
> 
> Apparently ARMV6 architecture is based on the ARM11 processor core. 

Most people would say "ARM11 processor core is based on ARMv6 architecture".
But I already realized that you rarely say same things as most people.

> While there has been an ARM8 core, and there is now an ARMV8 architecture.

Don't forget ARM Cortex-A8 core (pretty poor design, BTW) and Apple A8 SOC. :-)
Co-incidentally cores in Apple A8 SOC implement architecture called ARMv8A.
Twice a day etc...

> 
> Of course there is no possibility of confusion!
> 
> -- 
> bartc

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

#106676

already5chosen@yahoo.com writes:
>On Tuesday, March 21, 2017 at 3:39:06 PM UTC+2, Bart wrote:
>> 
>> Apparently ARMV6 architecture is based on the ARM11 processor core. 
>
>Most people would say "ARM11 processor core is based on ARMv6 architecture".
>But I already realized that you rarely say same things as most people.
>
>> While there has been an ARM8 core, and there is now an ARMV8 architecture.
>
>Don't forget ARM Cortex-A8 core (pretty poor design, BTW) and Apple A8 SOC. :-)
>Co-incidentally cores in Apple A8 SOC implement architecture called ARMv8A.
>Twice a day etc...

 That is written as "ARMv8-A", and is known as a profile.

 ARMv8 is the ISA (and supporting architecture, e.g virtual memory, virtualization, et alia)

 The ISA has three profiles:
    ARMv8 - A  : The application profile
    ARMv8 - R  : The real-time profile
    ARMv8 - M  : The mobile profile

 Implementations of the ARMv8 architecture for servers implement the A profile.

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

#106485

BartC <bc@freeuk.com> writes:

> On 19/03/2017 11:30, David Brown wrote:
>> On 18/03/17 00:12, jacobnavia wrote:
>
>> These "weird, small circuits" are the dominant type of processor.  There
>> are vastly more small, limited microcontrollers around than x86 or PPC
>> processors.
>>
>> I am happy to agree that most C programmers will deal only with systems
>> that have a single simple stack (per thread).  I just like to make it
>> clear that this is not the only way C is implemented - there are very
>> common, real-world C implementations that have no stack or make minimal
>> use of a stack.  This is not just a hypothetical case, or very rare or
>> unusual devices.
>
> This has been discussed a few times but is it right that a language
> like C should be permanently crippled, so that it can continue to work
> on these tiny or oddball processors that can barely be termed
> computers. Or should it be split?

Can you see any disadvantages in having two closely related C-like
languages?

> That is, allow a streamlined version that is designed to work on what
> most people think of as a computer.
>
> Take the basic types for example:
>
> In Java, the types {byte, short, int, long} have widths {8, 16, 32, 64}.
>
> In C#, the types {sbyte, short, int, long} have widths {8, 16, 32, 64}.
>
> In Rust, they seem to be {i8, i16, i32, i64} (you can guess the widths).
>
> In Go, they are {int8, int16, int32, int64}.

What is the reason you don't use one of these rather than suggesting
that C be split in two?  All of them, one way or another, address many
of the other things about C that you so dislike.

<snip>
-- 
Ben.

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

#106487

On 19/03/2017 13:05, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> Take the basic types for example:
>>
>> In Java, the types {byte, short, int, long} have widths {8, 16, 32, 64}.
>>
>> In C#, the types {sbyte, short, int, long} have widths {8, 16, 32, 64}.
>>
>> In Rust, they seem to be {i8, i16, i32, i64} (you can guess the widths).
>>
>> In Go, they are {int8, int16, int32, int64}.
>
> What is the reason you don't use one of these rather than suggesting
> that C be split in two?  All of them, one way or another, address many
> of the other things about C that you so dislike.

Yes, loads.

Most aren't as lightweight as C.

They might not be as portable. Compilers for them aren't as ubiquitous. 
Distributed source code (at least, as I distribute source) might not be 
as easy to compile or run as C.

They tend not be used for the interfaces to OSes and libraries that I'm 
interested in. I wouldn't know how to interface to libraries in those 
languages from one of my languages or from assembly.

They might have loads of extra features (OOP for example) that I don't 
want. (Rust starts off OK but then you read about features that would 
make programming in it a nightmare.)

The generated code might not have the same potential for speed as C.

They are not as transparent or low-level as C.

etc.

I'm fine with the concept of what C does and what it's for, but there 
are loads of things that could have been done better. (Ie. bring it 
closer to my own equivalent language.)

The example of I gave of the basic types was one. In fact it's C, the 
lower level and more transparent language (and yes more primitive), that 
should have had these fixed sizes built-in, not have the more modern 
upstarts show it how it's done.)

-- 
bartc

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

#106488

On Sun, 19 Mar 2017 13:05:09 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> > In Java, the types {byte, short, int, long} have widths {8, 16, 32, 64}.
> >
> > In C#, the types {sbyte, short, int, long} have widths {8, 16, 32, 64}.
> >
> > In Rust, they seem to be {i8, i16, i32, i64} (you can guess the widths).
> >
> > In Go, they are {int8, int16, int32, int64}.
> 
> What is the reason you don't use one of these rather than suggesting
> that C be split in two?  All of them, one way or another, address many
> of the other things about C that you so dislike.

Perhaps for the same reason most people don't use a truck to fill the
refrigerator or to travel abroad. The C language is short and efficient enough
to be widely used on any hardware as opposed to LISP for example.

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

#106489

GOTHIER Nathan <nathan.gothier@gmail.com> writes:

> On Sun, 19 Mar 2017 13:05:09 +0000
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> > In Java, the types {byte, short, int, long} have widths {8, 16, 32, 64}.
>> >
>> > In C#, the types {sbyte, short, int, long} have widths {8, 16, 32, 64}.
>> >
>> > In Rust, they seem to be {i8, i16, i32, i64} (you can guess the widths).
>> >
>> > In Go, they are {int8, int16, int32, int64}.
>> 
>> What is the reason you don't use one of these rather than suggesting
>> that C be split in two?  All of them, one way or another, address many
>> of the other things about C that you so dislike.
>
> Perhaps for the same reason most people don't use a truck to fill the
> refrigerator or to travel abroad. The C language is short and efficient enough
> to be widely used on any hardware as opposed to LISP for example.

LISP was not in the list!

-- 
Ben.

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

#106491

On Sun, 19 Mar 2017 13:34:58 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> LISP was not in the list!

Is it forbidden to expose the LISP failure? :-P

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

#106490

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> BartC <bc@freeuk.com> writes:
>
>> On 19/03/2017 11:30, David Brown wrote:
>>> On 18/03/17 00:12, jacobnavia wrote:
>>
>>> These "weird, small circuits" are the dominant type of processor.  There
>>> are vastly more small, limited microcontrollers around than x86 or PPC
>>> processors.
>>>
>>> I am happy to agree that most C programmers will deal only with systems
>>> that have a single simple stack (per thread).  I just like to make it
>>> clear that this is not the only way C is implemented - there are very
>>> common, real-world C implementations that have no stack or make minimal
>>> use of a stack.  This is not just a hypothetical case, or very rare or
>>> unusual devices.
>>
>> This has been discussed a few times but is it right that a language
>> like C should be permanently crippled, so that it can continue to work
>> on these tiny or oddball processors that can barely be termed
>> computers. Or should it be split?
>
> Can you see any disadvantages in having two closely related C-like
> languages?

Nothing?

<snip>
-- 
Ben.

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

#106494

On 19/03/2017 13:36, Ben Bacarisse wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> BartC <bc@freeuk.com> writes:
=[>>
>> Can you see any disadvantages in having two closely related C-like
>> languages?
>
> Nothing?

I don't see any significant problems. If the split did arise, then I'm 
sure the two would be clearly distinguished.

-- 
bartc

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

#106503

BartC <bc@freeuk.com> writes:

> On 19/03/2017 13:36, Ben Bacarisse wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> BartC <bc@freeuk.com> writes:
> =[>>
>>> Can you see any disadvantages in having two closely related C-like
>>> languages?
>>
>> Nothing?
>
> I don't see any significant problems. If the split did arise, then I'm
> sure the two would be clearly distinguished.

I thought as much.

-- 
Ben.

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

#106506

On 19/03/2017 19:00, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 19/03/2017 13:36, Ben Bacarisse wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> BartC <bc@freeuk.com> writes:
>> =[>>
>>>> Can you see any disadvantages in having two closely related C-like
>>>> languages?
>>>
>>> Nothing?
>>
>> I don't see any significant problems. If the split did arise, then I'm
>> sure the two would be clearly distinguished.
>
> I thought as much.

I posted a cut-down reply. Obviously it wasn't enough.

We already have a number of languages, pre-C90, C90, C99, C11, plus 
various dialects and the use of assorted extensions, all called "C".

Plus there is the tendency to rely on specific compilers, compiler 
options, makefiles, configuration scripts and other local tools, and 
have those as an integral part of a project.

Such that it becomes impossible to extract just the "C" component and 
build that in a different environment. This is yet separate from the 
problems of running programs on different platforms and with different 
libraries.

So the disadvantages you mention already exist, in spades.

The idea of a split is to help improve the situation. But it should have 
been done long ago.


-- 
bartc

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

#106508

On 03/20/17 08:24 AM, BartC wrote:
> On 19/03/2017 19:00, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 19/03/2017 13:36, Ben Bacarisse wrote:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>
>>>>> BartC <bc@freeuk.com> writes:
>>> =[>>
>>>>> Can you see any disadvantages in having two closely related C-like
>>>>> languages?
>>>>
>>>> Nothing?
>>>
>>> I don't see any significant problems. If the split did arise, then I'm
>>> sure the two would be clearly distinguished.
>>
>> I thought as much.
>
> I posted a cut-down reply. Obviously it wasn't enough.
>
> We already have a number of languages, pre-C90, C90, C99, C11, plus
> various dialects and the use of assorted extensions, all called "C".

Why do some C programmers obsess over this?

You never hear a Java or Python programmer saying anything like that, 
they just use the latest.

-- 
Ian

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

#106517

Ian Collins <ian-news@hotmail.com> writes:
> On 03/20/17 08:24 AM, BartC wrote:
[...]
>> We already have a number of languages, pre-C90, C90, C99, C11, plus
>> various dialects and the use of assorted extensions, all called "C".
>
> Why do some C programmers obsess over this?
>
> You never hear a Java or Python programmer saying anything like that, 
> they just use the latest.

Actually I think the transition from Python 2 to Python 3 has taken
longer than it was expected to.

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

#106525

On 03/20/17 10:32 AM, Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> On 03/20/17 08:24 AM, BartC wrote:
> [...]
>>> We already have a number of languages, pre-C90, C90, C99, C11, plus
>>> various dialects and the use of assorted extensions, all called "C".
>>
>> Why do some C programmers obsess over this?
>>
>> You never hear a Java or Python programmer saying anything like that,
>> they just use the latest.
>
> Actually I think the transition from Python 2 to Python 3 has taken
> longer than it was expected to.

That's a good example of what happens when you *do* choose to break 
compatibility...

-- 
Ian

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

#106600

Ian Collins <ian-news@hotmail.com> writes:

> On 03/20/17 10:32 AM, Keith Thompson wrote:
>> Actually I think the transition from Python 2 to Python 3 has taken
>> longer than it was expected to.
>
> That's a good example of what happens when you *do* choose to break
> compatibility...

To the extent that if you're trying to learn [one of] the language[s],
exactly half of the online tutorials will be actively counterproductive

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

#106874

Keith Thompson <kst-u@mib.org> wrote:

> Ian Collins <ian-news@hotmail.com> writes:
> > On 03/20/17 08:24 AM, BartC wrote:
> [...]
> >> We already have a number of languages, pre-C90, C90, C99, C11, plus
> >> various dialects and the use of assorted extensions, all called "C".
> >
> > Why do some C programmers obsess over this?
> >
> > You never hear a Java or Python programmer saying anything like that, 
> > they just use the latest.
> 
> Actually I think the transition from Python 2 to Python 3 has taken
> longer than it was expected to.

Certainly the transition between PHP versions creates holes in websites.

Richard

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

#106516

BartC <bc@freeuk.com> writes:

> On 19/03/2017 19:00, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 19/03/2017 13:36, Ben Bacarisse wrote:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>
>>>>> BartC <bc@freeuk.com> writes:
>>> =[>>
>>>>> Can you see any disadvantages in having two closely related C-like
>>>>> languages?
>>>>
>>>> Nothing?
>>>
>>> I don't see any significant problems. If the split did arise, then I'm
>>> sure the two would be clearly distinguished.
>>
>> I thought as much.
>
> I posted a cut-down reply. Obviously it wasn't enough.

No, it was fine.  I was just confirming that your cutting this question
without comment meant you saw no significant problems.

<snip>
-- 
Ben.

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

#106486

On Sun, 19 Mar 2017 12:12:25 +0000
BartC <bc@freeuk.com> wrote:

> Take the basic types for example:
> 
> In Java, the types {byte, short, int, long} have widths {8, 16, 32, 64}.
> 
> In C#, the types {sbyte, short, int, long} have widths {8, 16, 32, 64}.
> 
> In Rust, they seem to be {i8, i16, i32, i64} (you can guess the widths).
> 
> In Go, they are {int8, int16, int32, int64}.
> 
> There's a common pattern. Now look at the types in C:
> 
>    {char, short, int, long, long long}
> 
> For a start, there are five instead of four! Now for the widths (not 
> checked, but you get the picture):
> 
>   { at least 8, but no longer than the width of short,
>     at least 16 but not longer than int,
>     at least 16 but not longer than long,
>     at least 32 but not longer than long long
>     at least 64}
> 
> Plus the fact that all types are signed, except for char which may be 
> signed OR unsigned, a fact you might not even know.
> 
> Anyone notice an obvious way that this mess could be tidied up?

I'm afraid only the Doctor Who could fix the C timeline. :o)

Can you just remind us how old is C compared to the other languages you considered?

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

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

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

csiph-web