On Mon, Oct 10, 2011 at 2:29 PM, Shiv Shankar Dayal
wrote:
> So, instead of a stack and a heap, you now have a stack and "something that
> looks
> exactly like a heap but we'll call it a stacky-thing" which will be used for
> all
> the
> allocations that would have gone on the heap.
>
> I think w
On Sat, Oct 08, 2011 at 11:13:31, Shiv Shankar Dayal wrote:
> Cc: gcc@gcc.gnu.org
> Subject: Re: Heapless C/C++
>
> I have not thought over it for more than three days. But here is the
> simple answer. You can implement two stacks in one. Keep normal stuff
> which is not alloc
> You are absolutely free to define heapless as helpless.
>
Not quite helpless. Though less of help is there. People have
offered their personal help.
--
Best regards,
Shiv Shankar Dayal
On Sat, Oct 8, 2011 at 8:32 PM, Shiv Shankar Dayal
wrote:
>> The proper places to change the semantics of the C and C++ languages are
>> the international ISO committees that defined them (ISO/IEC JTC1/SC22/WG14
>> and ISO/IEC JTC1/SC22/WG21 respectively.) An effective way to have
>> an impact is
Charles Wilson wrote:
The reason many real-time systems disallow use of the heap is because it
is well-known that heap management does not have a bounded-time
implementation. Usually during free()/delete, typical heap management
code often tries to coalesce freed blocks, or perform various othe
> The proper places to change the semantics of the C and C++ languages are
> the international ISO committees that defined them (ISO/IEC JTC1/SC22/WG14
> and ISO/IEC JTC1/SC22/WG21 respectively.) An effective way to have
> an impact is to approach those committees or your national body, either
> j
On Sat, Oct 8, 2011 at 8:16 PM, Shiv Shankar Dayal
wrote:
>> This is not a gcc issue. This is the wrong mailing list for language
>> design. Thanks.
>>
>> Ian
>>
>
> I know it is not a gcc issue. But respected Stallman redirected me
> here and he was not wrong because I wanted to change the beha
> This is not a gcc issue. This is the wrong mailing list for language
> design. Thanks.
>
> Ian
>
I know it is not a gcc issue. But respected Stallman redirected me
here and he was not wrong because I wanted to change the behavior of
C/C++. But now I see that there is no possibility of this as
On Sat, Oct 8, 2011 at 11:59 AM, Jonathan Wakely wrote:
> On 8 October 2011 17:37, Charles Wilson wrote:
>>
>> Not hopeless; but you have to treat C++ simply as a slightly more
>> expressive version of C, follow the same rules previously outlined just
>> as if you WERE using C, and avoid the STL..
Shiv Shankar Dayal writes:
> I know you people are very busy but please go through this. It is
> about Heapless C/C++.
This is not a gcc issue. This is the wrong mailing list for language
design. Thanks.
Ian
On 10/8/2011 12:59 PM, Jonathan Wakely wrote:
> On 8 October 2011 17:37, Charles Wilson wrote:
>>
>> Not hopeless; but you have to treat C++ simply as a slightly more
>> expressive version of C, follow the same rules previously outlined just
>> as if you WERE using C, and avoid the STL...
>
> If y
On Sat, Oct 8, 2011 at 10:29 PM, Jonathan Wakely wrote:
> On 8 October 2011 17:37, Charles Wilson wrote:
>>
>> Not hopeless; but you have to treat C++ simply as a slightly more
>> expressive version of C, follow the same rules previously outlined just
>> as if you WERE using C, and avoid the STL..
On 8 October 2011 17:37, Charles Wilson wrote:
>
> Not hopeless; but you have to treat C++ simply as a slightly more
> expressive version of C, follow the same rules previously outlined just
> as if you WERE using C, and avoid the STL...
If you're going to spout FUD about C++ at least use the righ
On 10/8/2011 6:05 AM, Jonathan Wakely wrote:
> If you're using RAII consistently and correctly then the problems
> associated with heap memory go away, so you don't need to avoid the
> heap. If you're not using RAII correctly, your proposal won't work
> anyway and you'll leak memory. So what's th
On Sat, 8 Oct 2011 15:24:19 +0530
Shiv Shankar Dayal wrote:
> Why I want a new language is that whole compatibility goes for a toss.
I'm not sure to understand the above sentence. I parse it that you don't care
about
backward compatibility. Then you don't need any kind of C dialect.
> It would
> If you're using RAII consistently and correctly then the problems
> associated with heap memory go away, so you don't need to avoid the
> heap. If you're not using RAII correctly, your proposal won't work
> anyway and you'll leak memory. So what's the point?
>
> Why is it better to do dynamic a
On Sat, Oct 8, 2011 at 3:35 PM, Jonathan Wakely wrote:
> On 8 October 2011 10:48, Shiv Shankar Dayal wrote:
>>> It sounds like all you're proposing is using the stack for dynamic
>>> allocation instead of the heap, then adding a compacting garbage
>>> collector. It's easier to just use the heap a
On 8 October 2011 10:48, Shiv Shankar Dayal wrote:
>> It sounds like all you're proposing is using the stack for dynamic
>> allocation instead of the heap, then adding a compacting garbage
>> collector. It's easier to just use the heap and make sure you don't
>> leak memory. It's not that hard.
>>
Why I want a new language is that whole compatibility goes for a toss.
It would become very difficult for user to discriminate when to allocate
on heap and when to use stack while using existing libraries. Hence,
I did not want to do a gcc plugin.
--
Best regards,
Shiv Shankar Dayal
> It sounds like all you're proposing is using the stack for dynamic
> allocation instead of the heap, then adding a compacting garbage
> collector. It's easier to just use the heap and make sure you don't
> leak memory. It's not that hard.
>
Yes. This is true that I want to use stack for dynamic
On Sat, 8 Oct 2011 12:09:29 +0530
Shiv Shankar Dayal wrote:
> Hi all,
>
> I know you people are very busy but please go through this. It is
> about Heapless C/C++.
>
> What is heapless C++?
> Heapless C++ is the concept in which you are forbidden to use heap of system.
On 8 October 2011 07:39, Shiv Shankar Dayal wrote:
>
> We will have to have some function like alloca() which will allocate
> memory on stack but this piece of
> memory must not be released when SP goes down the stack. A record of
> all allocated objects by this
> function has to be kept. Also, the
Hi,
I am sorry. I just hit reply.
-- Forwarded message --
From: Shiv Shankar Dayal
Date: Sat, Oct 8, 2011 at 2:46 PM
Subject: Re: Heapless C/C++
To: foxmuldrs...@yahoo.com
On Sat, Oct 8, 2011 at 2:40 PM, Rick Hodgin wrote:
>
> Shiv,
>
> You have a
On Sat, Oct 8, 2011 at 1:04 PM, Paolo Carlini wrote:
>> What is heapless C++?
>
> Hopeless
>
> (sorry couldn't resist ;)
>
> Paolo
>
Why?
--
Best regards,
Shiv Shankar Dayal
> What is heapless C++?
Hopeless
(sorry couldn't resist ;)
Paolo
Hi all,
I know you people are very busy but please go through this. It is
about Heapless C/C++.
What is heapless C++?
Heapless C++ is the concept in which you are forbidden to use heap of system.
Why heapless C++?
Because:
1. Stack is addressed by SP (stack pointer) which is a register of CPU
26 matches
Mail list logo
