Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #94192 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2016-09-28 09:35 -0700 |
| Last post | 2016-09-28 20:20 +0100 |
| Articles | 20 on this page of 135 — 24 participants |
Back to article view | Back to comp.lang.c
Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 09:35 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 09:39 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 09:46 -0700
Re: Is there any place to talk about language features? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-28 17:53 +0100
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-09-28 21:21 +0200
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-28 20:36 +0100
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 13:55 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:02 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-09-29 10:03 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:13 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-09-29 10:22 +1300
Re: Is there any place to talk about language features? Robert Latest <boblatest@yahoo.com> - 2016-10-03 08:47 +0000
Re: Is there any place to talk about language features? James Kuyper <jameskuyper@verizon.net> - 2016-10-03 07:44 -0400
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 04:56 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 13:18 +0100
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-10-03 12:43 -0500
Re: Is there any place to talk about language features? Ike Naar <ike@iceland.freeshell.org> - 2016-10-03 21:43 +0000
Re: Is there any place to talk about language features? John Gordon <gordon@panix.com> - 2016-10-03 22:28 +0000
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-03 04:51 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 13:10 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 05:48 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 14:03 +0100
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-03 14:24 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 07:07 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-03 19:16 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 07:16 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 07:45 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 07:57 -0700
Re: Is there any place to talk about language features? James Kuyper <jameskuyper@verizon.net> - 2016-10-03 08:21 -0400
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-03 05:31 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 06:43 -0700
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-03 15:08 +0200
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:22 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 15:16 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 16:08 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 16:57 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 14:19 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:50 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 17:03 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-29 01:08 +0100
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 17:33 -0700
Re: Is there any place to talk about language features? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-29 01:02 +0000
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-09-29 01:39 -0500
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-29 00:48 -0700
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-09-29 11:59 -0500
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 08:09 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 12:14 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 09:07 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 13:53 -0700
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-09-30 22:13 +0100
Re: Is there any place to talk about language features? raltbos@xs4all.nl (Richard Bos) - 2016-10-01 09:36 +0000
Re: Is there any place to talk about language features? Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-01 13:04 -0400
Re: Is there any place to talk about language features? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-30 14:20 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-30 22:30 +0100
Re: Is there any place to talk about language features? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-10-02 07:30 +0000
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 01:51 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 10:31 +0100
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 23:22 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 06:15 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 15:28 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 10:07 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 19:52 +0100
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-02 20:38 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-02 03:37 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-03 08:35 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-02 15:17 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-03 18:29 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 01:09 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-04 08:21 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 13:12 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 14:34 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-04 00:47 -0700
Re: Is there any place to talk about language features? Ike Naar <ike@iceland.freeshell.org> - 2016-10-04 07:49 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-04 07:50 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-04 08:57 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-04 10:42 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 15:47 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-04 20:58 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 18:14 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 02:15 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 22:44 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 03:12 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:38 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:50 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 16:25 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 21:19 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 18:11 +1300
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-10-06 06:38 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-06 00:36 -0700
Re: Is there any place to talk about language features? gwowen <gwowen@gmail.com> - 2016-10-06 07:33 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-06 09:00 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 00:32 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 05:05 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-07 08:13 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 00:20 -0700
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-10-07 17:01 +0100
Re: Is there any place to talk about language features? Les Cargill <lcargill99@comcast.com> - 2016-10-05 12:45 -0500
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 11:12 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 03:15 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 14:41 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 08:01 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 08:41 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 10:29 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 12:29 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 11:08 +0100
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 14:35 +0100
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 18:15 +0100
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 10:38 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 19:14 +0100
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 11:56 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 11:57 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-05 12:18 -0700
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-05 21:49 +0200
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 13:07 -0700
Re: Is there any place to talk about language features? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-05 16:23 -0400
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-06 14:26 +0200
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 13:56 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-06 14:17 +0100
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-06 15:53 +0200
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-06 09:12 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-06 11:28 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:31 +1300
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:32 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:43 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 16:05 +1300
Re: Is there any place to talk about language features? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-10-02 07:24 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-09-30 16:17 -0700
Re: Is there any place to talk about language features? raltbos@xs4all.nl (Richard Bos) - 2016-10-01 09:39 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-01 14:11 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-29 07:47 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-29 10:25 -0700
Re: Is there any place to talk about language features? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-28 12:59 -0400
Re: Is there any place to talk about language features? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-28 18:30 +0100
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 12:10 -0700
Re: Is there any place to talk about language features? James Harris <james.harris.1@gmail.com> - 2016-09-28 20:20 +0100
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-09-28 17:33 -0700 |
| Message-ID | <da4e1d81-2bea-4129-9c09-e0f4cd5c15d3@googlegroups.com> |
| In reply to | #94231 |
On Wednesday, September 28, 2016 at 9:08:52 PM UTC-3, Bart wrote:
> On 28/09/2016 22:50, Thiago Adams wrote:
> > On Wednesday, September 28, 2016 at 6:19:03 PM UTC-3, Keith Thompson wrote:
> >> Thiago Adams writes:
> >> [...]
> >>> The feature I am thinking about is "default initializers"
> >>>
> >>> Today we can do:
> >>>
> >>> struct Point { int x; int y; };
> >>> struct Point pt1 = { 1, 2 };
> >>>
> >>> and this is useful when the initialization change by instance basis.
> >>> But, for some types the initialization is the same or it have common
> >>> initiation part for all instances. To avoid specify the common
> >>> initialization everywhere the solution is create a macro.
> >>>
> >>> struct Z { int type; };
> >>> #define Z_INIT { 4 }
> >>>
> >>> struct Z z1 = Z_INIT;
> >>
> >> A minor point: this can be done without a macro:
> >>
> >> struct Z { int type; };
> >> const struct Z Z_INIT = { 4 };
> >> struct Z z1 = Z_INIT;
> >
> > This is very nice, but it also opens a new feature discussion. :)
> > I think I will mix everything here but..
> > When something is const in a type that means that it probably doesn't need to exist.
> >
> > I don't know if the compiler will generate this value at memory
> > const struct Z Z_INIT = { 4 };
> >
> >
> > For this, I think we need a way to add information on a type.
> > Let's say C already have one. It's sizeof, but the value of sizeof is set by the compiler.
> >
> > My first thought about this is:
> >
> > struct Z
> > {
> > inline int Type = 1; //or "" or function pointer
> > inline const char* Name = "Z";
> > inline struct Z Z_INIT = { 4 };
> > int type = Type;
> > };
> >
> > Here Type is something that exist only at compiler memory.
> > and then we could have a new kind of "sizeof" but to inquire about type values.
> >
> > struct Z z;
> > type_value(Type, z) ; //returns 1
> > type_value(Type, struct Z) ; //returns 1
> > type_value(Name, struct Z) ; //returns "Z"
> > type_value(Type, int) ; //compiler error
> >
> >
> > I don't think this would complicated too much the compiler.
> > So, the {default} is also something that is associated with a type, and like sizeof is compiler generated.
> >
> > struct Z
> > {
> > inline struct Z __magic_hidden__ = { /*default-initialization*/};
> > inline struct Z __magic_sizeof_hidden__ = 2; //compiler generates
> > }
> >
> > (struct Z){default} is similar of
> >
> > type_value(__magic_hidden__ , struct Z);
> >
> > and sizeof (Z) is similar of
> >
> > type_value(__magic_sizeof_hidden__ , struct Z);
> >
> > Also functions could be associated with types.
> >
> > struct Z
> > {
> > //this is NOT function inline, but variable inline
> > inline void (*Destructor )(struct Z*) = Z_Destructor; //doenst change sizeof
> > };
> >
> > struct Z z;
> > type_value(Destructor, z)(&z);
> >
> > or we could have some syntax sugar..
> >
> > _Call Destructor(&z);
>
> Is this stuff already in C++? If so, why not just use that?
>
I think C++ has a lot conceptual problems and they are trying to fix version after version. The language became too complex after C++11.
C still clean.
My experience is mostly in C++ and now I am moving do C. I have to learn the "C way" to do things and I will probably ask much more questions here. I don't want to transform C in C++.
I think the perfect language would be something that adds optionally a very strong type system in C.
The suggestion "default initializers" is not something on this line but I think is not too much different from that is already there with the initializers.
I started the C parser project to play with static analyzer ideas and with a better type system. I need in some way annotate information.
Something I would like to archive is the ability do analyze ownership at compile time.
C++ is doing some movement in this area too, using templates to annotate types.
If a have a pointer that owns something I need to annotate what is the "destroy" function that must me called.
typedef const char* _owns(String_Destroy) String;
int main()
{
String s;
//message: error s not destroyed
}
I also have been influenced by typescript.They have now static checks for null. This would be awesome to have in C with a static analyzer.(search for TypeScript 2.0 Non-Nullable Types)
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2016-09-29 01:02 +0000 |
| Message-ID | <nshp7i$722$1@news.albasani.net> |
| In reply to | #94232 |
On 2016-09-29, Thiago Adams <thiago.adams@gmail.com> wrote: > On Wednesday, September 28, 2016 at 9:08:52 PM UTC-3, Bart wrote: >> > _Call Destructor(&z); >> >> Is this stuff already in C++? If so, why not just use that? >> > > I think C++ has a lot conceptual problems and they are trying to fix > version after version. The language became too complex after C++11. > > C still clean. Let's keep it that way... -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2016-09-29 01:39 -0500 |
| Message-ID | <nsicve$s6j$1@news.albasani.net> |
| In reply to | #94233 |
On 9/28/2016 8:02 PM, Melzzzzz wrote: > On 2016-09-29, Thiago Adams <thiago.adams@gmail.com> wrote: >> On Wednesday, September 28, 2016 at 9:08:52 PM UTC-3, Bart wrote: > >>>> _Call Destructor(&z); >>> >>> Is this stuff already in C++? If so, why not just use that? >>> >> >> I think C++ has a lot conceptual problems and they are trying to fix >> version after version. The language became too complex after C++11. >> >> C still clean. > > Let's keep it that way... > FWIW: it is sometimes useful to distinguish between "the core thing" and "the thing with lots of extensions". a problem with C++ is that it doesn't really distinguish, so the language grows out of control. with C, it is much more of a thing to have the compilers and operating systems define a lot more of the language and its APIs. for example, in one certain environment one has: LPCSTR, LPCTSTR, LPCWSTR, ... BYTE, WORD, DWORD, ... and functions: GetProcAddress, VirtualAlloc, CreateFileMapping, ... another system might do stuff like "pcuchar", "pcwchar", ... and, an OS might export: dlsym, mmap, ... and in others, it is pretty much bare metal: one may or may not even get all the normal language features, but instead need to fallback to writing functions in assembler to implement some operations (if not provided by a utility library). one may then end up needing to do their shift operators, multiplication/division, ... using internal function calls which implement these features in software. so, probably sane to leave the core a little minimalist and vague, and then let implementations define how things are going to be. possibly nice would be if there were "profiles" to define rules and behavior for common ranges of targets. though, partly this is also to fight back against "language lawyering" on the part of compiler writers, by better nailing down what the "commonly expected observable behavior" should be (as opposed to "whatever the compiler writer finds most convenient"). different sets of rules would then be defined for different categories of targets (or for specific formats). this isn't to say that compiler writers can't optimize, but rather, that their optimizations should not change observable behavior relative to the rules that are specified for that target (even if the standard proper is a little more open, and allows interpretations which go against established behaviors, or in cases where a behavior is technically UB, but tended to behave in a certain way on the target, which the existing codebase tended to rely on). because, breaking existing code and expecting people to go rewrite their to follow the compiler writers' sensibilities isn't exactly ideal. or such...
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-29 00:48 -0700 |
| Message-ID | <3e7e20c2-c69d-4777-a98a-b7d212f546c9@googlegroups.com> |
| In reply to | #94235 |
On Thursday, September 29, 2016 at 7:39:51 AM UTC+1, BGB wrote: > On 9/28/2016 8:02 PM, Melzzzzz wrote: > > On 2016-09-29, Thiago Adams <thiago.adams@gmail.com> wrote: > >> On Wednesday, September 28, 2016 at 9:08:52 PM UTC-3, Bart wrote: > > > >>>> _Call Destructor(&z); > >>> > >>> Is this stuff already in C++? If so, why not just use that? > >>> > >> > >> I think C++ has a lot conceptual problems and they are trying to fix > >> version after version. The language became too complex after C++11. > >> > >> C still clean. > > > > Let's keep it that way... > > > > FWIW: it is sometimes useful to distinguish between "the core thing" and > "the thing with lots of extensions". > > a problem with C++ is that it doesn't really distinguish, so the > language grows out of control. > The problem as I see it with C++ is that each new feature creates difficulties or hard to answer questions, which necessitate another feature. For example how is a constructor to fail? The answer is to throw an exception. Then how is the stack to be unwound? By calling implicit destructors. But how do you make sure that your object is in a destructible state? By allowing memberwise initialisation before the constructor is actually executed. How do you make sure that the members can be initialised? With default constructors. But how do allow the default constructor to fail? It can't, you should make it "no throw". And so it goes on. Feature after feature, which in C you just don't need because we simply don't create opaque structures on the stack. We return a pointer to the object on the heap, and if the constructor fails, it is null. You lose the ability to construct on the stack (though you can always rewrite if necessary) and, a bit more annoyingly, you lose automatic destruction. But construction on the stack is a real benefit only for tiny, trivial structures which in C wouldn't usually be opaque anyway. So the only real loss is automatic destruction.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2016-09-29 11:59 -0500 |
| Message-ID | <nsjh9d$1ip$1@news.albasani.net> |
| In reply to | #94236 |
On 9/29/2016 2:48 AM, Malcolm McLean wrote:
> On Thursday, September 29, 2016 at 7:39:51 AM UTC+1, BGB wrote:
>> On 9/28/2016 8:02 PM, Melzzzzz wrote:
>>> On 2016-09-29, Thiago Adams <thiago.adams@gmail.com> wrote:
>>>> On Wednesday, September 28, 2016 at 9:08:52 PM UTC-3, Bart wrote:
>>>
>>>>>> _Call Destructor(&z);
>>>>>
>>>>> Is this stuff already in C++? If so, why not just use that?
>>>>>
>>>>
>>>> I think C++ has a lot conceptual problems and they are trying to fix
>>>> version after version. The language became too complex after C++11.
>>>>
>>>> C still clean.
>>>
>>> Let's keep it that way...
>>>
>>
>> FWIW: it is sometimes useful to distinguish between "the core thing" and
>> "the thing with lots of extensions".
>>
>> a problem with C++ is that it doesn't really distinguish, so the
>> language grows out of control.
>>
> The problem as I see it with C++ is that each new feature creates
> difficulties or hard to answer questions, which necessitate another
> feature.
> For example how is a constructor to fail? The answer is to throw
> an exception. Then how is the stack to be unwound? By calling
> implicit destructors. But how do you make sure that your object
> is in a destructible state? By allowing memberwise initialisation
> before the constructor is actually executed. How do you make sure
> that the members can be initialised? With default constructors.
> But how do allow the default constructor to fail? It can't, you
> should make it "no throw".
>
> And so it goes on. Feature after feature, which in C you just
> don't need because we simply don't create opaque structures on
> the stack. We return a pointer to the object on the heap, and
> if the constructor fails, it is null. You lose the ability to
> construct on the stack (though you can always rewrite if
> necessary) and, a bit more annoyingly, you lose automatic
> destruction. But construction on the stack is a real benefit only
> for tiny, trivial structures which in C wouldn't usually be
> opaque anyway. So the only real loss is automatic destruction.
>
yes, that too.
this is an issue which could theoretically come up with the struct type
in my script language, but my "solution" thus far has been to not really
address the issue.
its predecessor had a value-class type, which I have left out of this
one (too much complexity for a rarely used special case).
the struct type basically only has non-virtual methods, and does not
allow inheritance. it is passed by value, or may be passed using a
pointer or a reference. what it does have is a "reasonably" well-defined
layout in memory.
the class type supports "the usual stuff" (single inheritance and
interfaces), but is always heap allocated, and does not have a defined
in-memory layout. in current VM, the default case is struct like.
dynamic classes" may be implemented as a miniature B-Tree (had best
runtime properties for the use-case, vs hash, sorted-array, or AVL
trees, though was the most complicated option), though for small objects
(most common case) it uses sorted-array.
a secondary issue which has come up is that of needing a memory
allocator design which scales well over a wide range of heap sizes.
the current VM uses a strategy which works ok for 100s of MB up to a few
GB, but becomes rather inefficient with a physically-mapped space under
128 MB.
for smaller heaps (under 100MB), block-splitting linked-list allocators
are much more space-efficient, but become much less efficient as heaps
become larger (100s of MB or into the GB range).
the result is likely needing making this target-sensitive, ex:
x86-64: tune for large chunks using memory-cells (assume GB heaps);
x86/ARM: use smaller cell-chunks, linked-list for larger objects;
assume an MMU and heap-spaces ~ 200MB to 2GB.
ex: assume ARM with ~ 128 or 256 MB of RAM and virtual memory.
SuperH: use linked-list for pretty much everything over 256 bytes.
assume non-MMU and small DRAM spaces (heap = several MB).
for SH-4 targets with an MMU, physical addressing is still common.
example targets:
SH-2 | SH-2A running at 33MHz with 2MB RAM & 4MB of ROM.
SH-4 running at 233MHz with 8MB of RAM (execute from RAM).
not included is Cortex-M, which typically run off of internal SRAM (not
usually sufficient to make a VM viable, ex: 64kB to 256kB typical).
MSP-430 has both this issue, but generally much less space (RAM=256B to
2kB, ROM is also usually pretty small), and needing to deal with 16-bit
integers. running a VM is not viable.
but, yeah, UB or not, performance or not, would still prefer consistent
results from things like integer arithmetic (like, make it a rule that
compiler writers not break shifts, or at least give consistent behavior,
or macros/intrinsics which reliably give the desired behavior in cases
where correct operation of the code requires a certain behavior from the
shift operation), ...
aliasing behavior is its own set of issues.
might also like standardized features to deal with aligned/unaligned
loads/stores and memory endianess (vs programs needing to supply all
this themselves).
or such...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-01 08:09 +1300 |
| Message-ID | <e57rk4Fa94uU1@mid.individual.net> |
| In reply to | #94236 |
On 09/29/16 08:48 PM, Malcolm McLean wrote >> > The problem as I see it with C++ is that each new feature creates > difficulties or hard to answer questions, which necessitate another > feature. > For example how is a constructor to fail? The answer is to throw > an exception. Then how is the stack to be unwound? By calling > implicit destructors. But how do you make sure that your object > is in a destructible state? By allowing memberwise initialisation > before the constructor is actually executed. How do you make sure > that the members can be initialised? With default constructors. > But how do allow the default constructor to fail? It can't, you > should make it "no throw". > > And so it goes on. Feature after feature, which in C you just > don't need because we simply don't create opaque structures on > the stack. We return a pointer to the object on the heap, and > if the constructor fails, it is null. You lose the ability to > construct on the stack (though you can always rewrite if > necessary) and, a bit more annoyingly, you lose automatic > destruction. But construction on the stack is a real benefit only > for tiny, trivial structures which in C wouldn't usually be > opaque anyway. So the only real loss is automatic destruction. Which, given a problem such as "Resource X must be freed once all uses of it end". Such a problem is trivial to manage in C++ and far from trivial in C. It all comes down to where the complexity required to manage a task lies: in user code in C or in the language in C++. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-09-30 12:14 -0700 |
| Message-ID | <21af8abe-28fe-4447-b8a9-db1defa5a848@googlegroups.com> |
| In reply to | #94322 |
On Friday, September 30, 2016 at 4:10:05 PM UTC-3, Ian Collins wrote: ... > Which, given a problem such as "Resource X must be freed once all uses > of it end". Such a problem is trivial to manage in C++ and far from > trivial in C. Do you mean a shared resource? (shared_ptr?)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-01 09:07 +1300 |
| Message-ID | <e57uvtFa94uU2@mid.individual.net> |
| In reply to | #94323 |
On 10/ 1/16 08:14 AM, Thiago Adams wrote: > On Friday, September 30, 2016 at 4:10:05 PM UTC-3, Ian Collins wrote: > .... >> Which, given a problem such as "Resource X must be freed once all uses >> of it end". Such a problem is trivial to manage in C++ and far from >> trivial in C. > > Do you mean a shared resource? (shared_ptr?) That's one example, yes. It is usual practice in C++ to use objects to manage resources. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-09-30 13:53 -0700 |
| Message-ID | <e00dcebb-a6ef-48f7-97a1-20e43ff288bf@googlegroups.com> |
| In reply to | #94330 |
On Friday, September 30, 2016 at 5:07:33 PM UTC-3, Ian Collins wrote: > On 10/ 1/16 08:14 AM, Thiago Adams wrote: > > On Friday, September 30, 2016 at 4:10:05 PM UTC-3, Ian Collins wrote: > > .... > >> Which, given a problem such as "Resource X must be freed once all uses > >> of it end". Such a problem is trivial to manage in C++ and far from > >> trivial in C. > > > > Do you mean a shared resource? (shared_ptr?) > > That's one example, yes. It is usual practice in C++ to use objects to > manage resources. I find easy to create shared objects in C. Object * p1 = Create(); //ref counted 1 Object * p2 = NULL; p2 = Share(p1);//ref counted 2 Release(p1); //ref counted 1 Release(p2); //destroyed share_ptr in C++ is uses atomic counter. this is one place where C _Atomic would be useful.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-09-30 22:13 +0100 |
| Message-ID | <87shsht7k6.fsf@gmail.com> |
| In reply to | #94331 |
Thiago Adams <thiago.adams@gmail.com> writes: > On Friday, September 30, 2016 at 5:07:33 PM UTC-3, Ian Collins wrote: > I find easy to create shared objects in C. > > Object * p1 = Create(); //ref counted 1 > Object * p2 = NULL; > > p2 = Share(p1);//ref counted 2 > > Release(p1); //ref counted 1 > Release(p2); //destroyed Correctly releasing resources manually across all code paths is indeed easy. That's why C programs so rarely have memory leaks.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-10-01 09:36 +0000 |
| Message-ID | <57ef832b.96875@news.xs4all.nl> |
| In reply to | #94336 |
Gareth Owen <gwowen@gmail.com> wrote: > Thiago Adams <thiago.adams@gmail.com> writes: > > > On Friday, September 30, 2016 at 5:07:33 PM UTC-3, Ian Collins wrote: > > I find easy to create shared objects in C. > > > > Object * p1 = Create(); //ref counted 1 > > Object * p2 = NULL; > > > > p2 = Share(p1);//ref counted 2 > > > > Release(p1); //ref counted 1 > > Release(p2); //destroyed > > Correctly releasing resources manually across all code paths is indeed > easy. That's why C programs so rarely have memory leaks. It's easy when you do your bookkeeping, but there are a lot of sloppy programmers. When these same sloppy programmers switch from C to a slop-friendly language, they create fewer memory leaks, but a lot more bloat. Personally, I would advocate letting only careful programmers program in C, and push sloppy programmers in the direction of, say, Python, but the problem is that sloppy programmers generally don't understand that they're being sloppy. Richard
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-10-01 13:04 -0400 |
| Message-ID | <nsoqb6$2td$1@jstuckle.eternal-september.org> |
| In reply to | #94357 |
On 10/1/2016 5:36 AM, Richard Bos wrote: > Gareth Owen <gwowen@gmail.com> wrote: > >> Thiago Adams <thiago.adams@gmail.com> writes: >> >>> On Friday, September 30, 2016 at 5:07:33 PM UTC-3, Ian Collins wrote: >>> I find easy to create shared objects in C. >>> >>> Object * p1 = Create(); //ref counted 1 >>> Object * p2 = NULL; >>> >>> p2 = Share(p1);//ref counted 2 >>> >>> Release(p1); //ref counted 1 >>> Release(p2); //destroyed >> >> Correctly releasing resources manually across all code paths is indeed >> easy. That's why C programs so rarely have memory leaks. > > It's easy when you do your bookkeeping, but there are a lot of sloppy > programmers. When these same sloppy programmers switch from C to a > slop-friendly language, they create fewer memory leaks, but a lot more > bloat. > Personally, I would advocate letting only careful programmers program in > C, and push sloppy programmers in the direction of, say, Python, but the > problem is that sloppy programmers generally don't understand that > they're being sloppy. > > Richard > Richard, I agree with you 100% here. What also helps prevent memory leaks is a good design, so you can follow the lifetime of an object through the system. But so few people do designs. I've even had managers tell me "We don't have time to do a design." and "If my programmers aren't writing code, they're not being productive." But those same managers would think of building a 50 story building (or even a three bedroom house) without blueprints.... In case you're wondering, this is a pet peeve of mine :) -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-09-30 14:20 -0700 |
| Message-ID | <nsmkur$vs4$2@dont-email.me> |
| In reply to | #94331 |
On 9/30/2016 1:53 PM, Thiago Adams wrote: > On Friday, September 30, 2016 at 5:07:33 PM UTC-3, Ian Collins wrote: >> On 10/ 1/16 08:14 AM, Thiago Adams wrote: >>> On Friday, September 30, 2016 at 4:10:05 PM UTC-3, Ian Collins wrote: >>> .... >>>> Which, given a problem such as "Resource X must be freed once all uses >>>> of it end". Such a problem is trivial to manage in C++ and far from >>>> trivial in C. >>> >>> Do you mean a shared resource? (shared_ptr?) >> >> That's one example, yes. It is usual practice in C++ to use objects to >> manage resources. > > I find easy to create shared objects in C. > > Object * p1 = Create(); //ref counted 1 > Object * p2 = NULL; > > p2 = Share(p1);//ref counted 2 > > Release(p1); //ref counted 1 > Release(p2); //destroyed > > share_ptr in C++ is uses atomic counter. > this is one place where C _Atomic would be useful. FWIW, there are many other places where atomic ops and members are extremely useful.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-30 22:30 +0100 |
| Message-ID | <nsmlhh$2sk$1@dont-email.me> |
| In reply to | #94331 |
On 30/09/2016 21:53, Thiago Adams wrote: > On Friday, September 30, 2016 at 5:07:33 PM UTC-3, Ian Collins wrote: >> On 10/ 1/16 08:14 AM, Thiago Adams wrote: >>> On Friday, September 30, 2016 at 4:10:05 PM UTC-3, Ian Collins wrote: >>> .... >>>> Which, given a problem such as "Resource X must be freed once all uses >>>> of it end". Such a problem is trivial to manage in C++ and far from >>>> trivial in C. >>> >>> Do you mean a shared resource? (shared_ptr?) >> >> That's one example, yes. It is usual practice in C++ to use objects to >> manage resources. > > I find easy to create shared objects in C. > > Object * p1 = Create(); //ref counted 1 > Object * p2 = NULL; > > p2 = Share(p1);//ref counted 2 > > Release(p1); //ref counted 1 > Release(p2); //destroyed > > share_ptr in C++ is uses atomic counter. > this is one place where C _Atomic would be useful. > I started playing around with reference counting earlier this year (for some language project). It sounded easy to start with. It ended up being a nightmare. For a start, suppose Object is a structure that can contain other Object references (for tree and list building). So Release() now has to do a list or tree traversal to free everything properly. And you need dedicated Create and Release routines for each kind of object. Or, if you have an array of Objects, now you need to scan each array element and call Release on each (and the same for any miscellaneous instances of Object in any other data). If a regular struct contains any Object references, you can't just copy that struct to another. Then you have circular references, which either mean things cannot be freed, or, if you want to duplicate a structure, you end up in endless loops. It gets better. Suppose you want a pointer to a part of an Object (to pass to a function or to do the usual stuff with). Now you can't just create a pointer because you have to step the reference count. You can't use Share() because that's for a whole object. It starts to get very messy. -- Bart
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2016-10-02 07:30 +0000 |
| Message-ID | <slrnnv1dse.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #94330 |
On Fri, 2016-09-30, Ian Collins wrote: > On 10/ 1/16 08:14 AM, Thiago Adams wrote: >> On Friday, September 30, 2016 at 4:10:05 PM UTC-3, Ian Collins wrote: >> .... >>> Which, given a problem such as "Resource X must be freed once all uses >>> of it end". Such a problem is trivial to manage in C++ and far from >>> trivial in C. >> >> Do you mean a shared resource? (shared_ptr?) > > That's one example, yes. And far from the most common one. In C++ just as in C, you try to design things so that there's clear, single ownership. It's usually (but not always) possible. > It is usual practice in C++ to use objects to > manage resources. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-01 01:51 -0700 |
| Message-ID | <c7787c1f-f39c-499f-8d93-1caa13d4c005@googlegroups.com> |
| In reply to | #94322 |
On Friday, September 30, 2016 at 8:10:05 PM UTC+1, Ian Collins wrote: > On 09/29/16 08:48 PM, Malcolm McLean wrote > >> > > The problem as I see it with C++ is that each new feature creates > > difficulties or hard to answer questions, which necessitate another > > feature. > > For example how is a constructor to fail? The answer is to throw > > an exception. Then how is the stack to be unwound? By calling > > implicit destructors. But how do you make sure that your object > > is in a destructible state? By allowing memberwise initialisation > > before the constructor is actually executed. How do you make sure > > that the members can be initialised? With default constructors. > > But how do allow the default constructor to fail? It can't, you > > should make it "no throw". > > > > And so it goes on. Feature after feature, which in C you just > > don't need because we simply don't create opaque structures on > > the stack. We return a pointer to the object on the heap, and > > if the constructor fails, it is null. You lose the ability to > > construct on the stack (though you can always rewrite if > > necessary) and, a bit more annoyingly, you lose automatic > > destruction. But construction on the stack is a real benefit only > > for tiny, trivial structures which in C wouldn't usually be > > opaque anyway. So the only real loss is automatic destruction. > > Which, given a problem such as "Resource X must be freed once all uses > of it end". Such a problem is trivial to manage in C++ and far from > trivial in C. > > It all comes down to where the complexity required to manage a task > lies: in user code in C or in the language in C++. > In C we can use this pattern. a) Variables may not be declared in block scope, only function scope. (only really matters for pointer and handles, but make it all). b) Every pointer or handle is initialised to null. c) There is a label called "out_of_memory" (for a "Malcolm function, which can only fail on out of memory conditions and for no other reason) or "error_exit" (for a "Malcolm procedure" which does IO and can experience IO failure). d) out_of_memory or error_exit is jumped to on memory allocation or IO failure. e) code the error label destroys all resources, which will be null if not intialised. f) In the usual situation of an failure also meaning a failure in caller, an error return must be passed up. So normally if the function return a pointer it returns null, otherwise it returns -1 for out-of memory, or a lower negative for IO errors. Simple rules, not very complex or hard to follow. The only real point of difficulty is that when allocating a structure which itself contains pointers to be allocated, those pointers must immediately be set to null so the destructor logic doesn't free wild pointers.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-01 10:31 +0100 |
| Message-ID | <874m4w76v6.fsf@bsb.me.uk> |
| In reply to | #94355 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > In C we can use this pattern. > > a) Variables may not be declared in block scope, only function scope. > (only really matters for pointer and handles, but make it all). These are not how the terms are used in the C standard. What you call "function scope" is the outer-most block scope. (The standard uses the term function scope for something else.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-01 23:22 +1300 |
| Message-ID | <e59h3bFkp66U1@mid.individual.net> |
| In reply to | #94355 |
On 10/ 1/16 09:51 PM, Malcolm McLean wrote: > On Friday, September 30, 2016 at 8:10:05 PM UTC+1, Ian Collins wrote: >> On 09/29/16 08:48 PM, Malcolm McLean wrote >>>> >>> The problem as I see it with C++ is that each new feature creates >>> difficulties or hard to answer questions, which necessitate another >>> feature. >>> For example how is a constructor to fail? The answer is to throw >>> an exception. Then how is the stack to be unwound? By calling >>> implicit destructors. But how do you make sure that your object >>> is in a destructible state? By allowing memberwise initialisation >>> before the constructor is actually executed. How do you make sure >>> that the members can be initialised? With default constructors. >>> But how do allow the default constructor to fail? It can't, you >>> should make it "no throw". >>> >>> And so it goes on. Feature after feature, which in C you just >>> don't need because we simply don't create opaque structures on >>> the stack. We return a pointer to the object on the heap, and >>> if the constructor fails, it is null. You lose the ability to >>> construct on the stack (though you can always rewrite if >>> necessary) and, a bit more annoyingly, you lose automatic >>> destruction. But construction on the stack is a real benefit only >>> for tiny, trivial structures which in C wouldn't usually be >>> opaque anyway. So the only real loss is automatic destruction. >> >> Which, given a problem such as "Resource X must be freed once all uses >> of it end". Such a problem is trivial to manage in C++ and far from >> trivial in C. >> >> It all comes down to where the complexity required to manage a task >> lies: in user code in C or in the language in C++. >> > In C we can use this pattern. > > a) Variables may not be declared in block scope, only function scope. > (only really matters for pointer and handles, but make it all). > b) Every pointer or handle is initialised to null. > c) There is a label called "out_of_memory" (for a "Malcolm function, > which can only fail on out of memory conditions and for no other > reason) or "error_exit" (for a "Malcolm procedure" which does IO > and can experience IO failure). > d) out_of_memory or error_exit is jumped to on memory allocation > or IO failure. > e) code the error label destroys all resources, which will be null > if not intialised. > f) In the usual situation of an failure also meaning a failure in > caller, an error return must be passed up. So normally if the function > return a pointer it returns null, otherwise it returns -1 for > out-of memory, or a lower negative for IO errors. > > > Simple rules, not very complex or hard to follow. Simple but fallible rules for simple use cases of simple resources. Life gets way more interesting when those simple things become a little more complicated. > The only real point of difficulty is that when allocating a structure > which itself contains pointers to be allocated, those pointers must > immediately be set to null so the destructor logic doesn't free > wild pointers. You overlook the fact that many if not most resource allocation and release happens in different parts of a programme. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-01 06:15 -0700 |
| Message-ID | <a3ba260b-f6ab-4677-9073-c7c9866c7232@googlegroups.com> |
| In reply to | #94363 |
On Saturday, October 1, 2016 at 11:22:42 AM UTC+1, Ian Collins wrote: > On 10/ 1/16 09:51 PM, Malcolm McLean wrote: > > On Friday, September 30, 2016 at 8:10:05 PM UTC+1, Ian Collins wrote: > >> On 09/29/16 08:48 PM, Malcolm McLean wrote > >>>> > >>> The problem as I see it with C++ is that each new feature creates > >>> difficulties or hard to answer questions, which necessitate another > >>> feature. > >>> For example how is a constructor to fail? The answer is to throw > >>> an exception. Then how is the stack to be unwound? By calling > >>> implicit destructors. But how do you make sure that your object > >>> is in a destructible state? By allowing memberwise initialisation > >>> before the constructor is actually executed. How do you make sure > >>> that the members can be initialised? With default constructors. > >>> But how do allow the default constructor to fail? It can't, you > >>> should make it "no throw". > >>> > >>> And so it goes on. Feature after feature, which in C you just > >>> don't need because we simply don't create opaque structures on > >>> the stack. We return a pointer to the object on the heap, and > >>> if the constructor fails, it is null. You lose the ability to > >>> construct on the stack (though you can always rewrite if > >>> necessary) and, a bit more annoyingly, you lose automatic > >>> destruction. But construction on the stack is a real benefit only > >>> for tiny, trivial structures which in C wouldn't usually be > >>> opaque anyway. So the only real loss is automatic destruction. > >> > >> Which, given a problem such as "Resource X must be freed once all uses > >> of it end". Such a problem is trivial to manage in C++ and far from > >> trivial in C. > >> > >> It all comes down to where the complexity required to manage a task > >> lies: in user code in C or in the language in C++. > >> > > In C we can use this pattern. > > > > a) Variables may not be declared in block scope, only function scope. > > (only really matters for pointer and handles, but make it all). > > b) Every pointer or handle is initialised to null. > > c) There is a label called "out_of_memory" (for a "Malcolm function, > > which can only fail on out of memory conditions and for no other > > reason) or "error_exit" (for a "Malcolm procedure" which does IO > > and can experience IO failure). > > d) out_of_memory or error_exit is jumped to on memory allocation > > or IO failure. > > e) code the error label destroys all resources, which will be null > > if not intialised. > > f) In the usual situation of an failure also meaning a failure in > > caller, an error return must be passed up. So normally if the function > > return a pointer it returns null, otherwise it returns -1 for > > out-of memory, or a lower negative for IO errors. > > > > > > Simple rules, not very complex or hard to follow. > > Simple but fallible rules for simple use cases of simple resources. > Life gets way more interesting when those simple things become a little > more complicated. > > > The only real point of difficulty is that when allocating a structure > > which itself contains pointers to be allocated, those pointers must > > immediately be set to null so the destructor logic doesn't free > > wild pointers. > > You overlook the fact that many if not most resource allocation and > release happens in different parts of a programme. > There's also the structure pattern. A graph is created, then nodes and edges are added and deleted as the algorithm does its stuff. So obviously memory has to be allocated at the point a node is created and released at the point it is destroyed. But everything should be accessible from the root, and at every time it ought to be possible to destroy the entire structure by calling the destructor on the root. The trick is to use structured programming. Each "block" (which is similar to but not identical to a C curly braces block") has one point of entry and one point of exit. So creation and destruction are matched. A block either destroys all the resources it holds on exit, or passes them up to caller. If it passes them up to caller, it must be matched by a "destructor" function, which caller must call on his own exit (or pass them up to super-caller, and provide a destructor of his own, which then calls the destructor). Where it does get more difficult is where you have threads. Then it's no longer always possible for a resource to be in limited, known lifetime, because two or more functions might operate on it, not quite simultaneously, but in interleaved fashion.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-01 15:28 +0100 |
| Message-ID | <87k2ds5ekn.fsf@bsb.me.uk> |
| In reply to | #94366 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, October 1, 2016 at 11:22:42 AM UTC+1, Ian Collins wrote: <snip> >> You overlook the fact that many if not most resource allocation and >> release happens in different parts of a programme. >> > There's also the structure pattern. A graph is created, then nodes and > edges are added and deleted as the algorithm does its stuff. So > obviously memory has to be allocated at the point a node is created > and released at the point it is destroyed. But everything should > be accessible from the root, and at every time it ought to be > possible to destroy the entire structure by calling the destructor > on the root. > > The trick is to use structured programming. Each "block" (which is > similar to but not identical to a C curly braces block") has one > point of entry and one point of exit. So creation and destruction > are matched. A block either destroys all the resources it holds > on exit, or passes them up to caller. If it passes them up to caller, > it must be matched by a "destructor" function, which caller must > call on his own exit (or pass them up to super-caller, and provide > a destructor of his own, which then calls the destructor). This pattern does not always work. You can't always have nested creation and deletion like this. A Lisp implementation comes to mind as an example. (Actually it may be possible to enforce this at the expense of a great deal of copying but I'm not sure even that is possible.) > Where it does get more difficult is where you have threads. Then > it's no longer always possible for a resource to be in limited, > known lifetime, because two or more functions might operate on it, > not quite simultaneously, but in interleaved fashion. That too. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web