------=_Part_85_8294786.1391006488631
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

29 2014 =D0=B3., 18:03:33 UTC+4 Matthew Fioravante :
>
> Most modern technology including C++ is still built ontop of C. This is=
=20
> not likely to change for a long time, if ever.
>

There is slow motion:
GCC is migrating to C++ http://gcc.gnu.org/wiki/cxx-conversion
MSVC Runtime is migrating to C++=20
http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-17-Meet-James-McN=
ellis-Register-for-GoingNative-2013

This post might belong in a C forum, but I wanted to ask. What do you think=
=20
> C could change to make the world better for C++ and/or other languages an=
d=20
> technologies?
>

The best thing which C could do to make the world better - is to merge into=
=20
C++ and stop divergence. Refer Bjarne Stroustrup paper on this topic -=20
http://isocpp.org/files/papers/N3628.pdf
=20

> Here are 2 ideas:
>
> 1) Extend the memory interface with alloc_expand();
>

It is good addition, but there is nothing "C-ish" about alloc_expand, it=20
can be added into C++ directly, without long process of adding it to C ISO=
=20
and then referring to it from new C++ ISO.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_85_8294786.1391006488631
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">29 2014&nbsp;=D0=B3., 18:03:33 UTC+4 Matthew Fioravante :<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Most mode=
rn technology including C++ is still built ontop of C. This is not likely t=
o change for a long time, if ever.</div></div></blockquote><div><br>There i=
s slow motion:<br>GCC is migrating to C++ http://gcc.gnu.org/wiki/cxx-conve=
rsion<br>MSVC Runtime is migrating to C++ http://channel9.msdn.com/Shows/C9=
-GoingNative/GoingNative-17-Meet-James-McNellis-Register-for-GoingNative-20=
13<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">This post might belong in a C forum, but I wanted to ask. What do you th=
ink C could change to make the world better for C++ and/or other languages =
and technologies?<div></div></div></blockquote><div><br>The best thing whic=
h C could do to make the world better - is to merge into C++ and stop diver=
gence. Refer Bjarne Stroustrup paper on this topic - http://isocpp.org/file=
s/papers/N3628.pdf<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>Here are 2 ideas:</div><div><br></div>1) Extend=
 the memory interface with&nbsp;<span style=3D"font-size:13px">alloc_expand=
();</span></div></blockquote><div><br>It is good addition, but there is not=
hing "C-ish" about <span style=3D"font-size:13px">alloc_expand, it can be a=
dded into C++ directly, without long process of </span>adding it to C ISO a=
nd then referring to it from new C++ ISO.</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_85_8294786.1391006488631--

.

On 2014-01-29 09:03, Matthew Fioravante wrote:
> I'd love to see the C standard adopt a variant the following function in
> their malloc() API.
>
> //Tries to resize p in place to newlen bytes. If successful, returns p,
> otherwise returns NULL and the memory pointed to by p is unmodifed. Returns
> NULL if p is NULL.
> void* alloc_expand(void* p, size_t newlen);
>
> Why? Because we should be able to take advantage of this memory
> optimization for contiguous memory layout data structures  such as
> std::vector and std::string. A dynamic array is the most fundamental data
> structure in any language. Contiguous memory layout is key for performance
> on modern hardware.

Given that containers may implement memory growth optimizations (e.g.
allocate 50% more memory any time growth is needed), I wonder if it
wouldn't be better to instead have:

size_t alloc_expand(void* p, size_t desired_len, size_t alignment = 0)

....which would make the allocation as large as possible up to
desired_len (being a whole multiple of alignment) and return the new
size of the buffer. This would allow implementations to speculatively
request storage for several additional elements when *right now* they
only really need one, in order to reserve as much overhead as possible
while still allowing the fast-path to be used if less than the desired
overhead is available.

(The use of alignment is to ensure that the new size is a multiple of
the element size without wasted bytes. If 0, a default value is used,
probably word size, possibly defined by the allocator implementation.
Note that it is assumed that the caller knows the size of its existing
buffer.)

I could further imagine adding, or having an alternate implementation
that takes, a 'minimum size' parameter such that the resize would "fail"
(i.e. return the existing size of p) if the buffer size cannot be
expanded to at least the minimum size.

> With realloc(), we do the following:
>
>     1. Resize in place if we can, or
>     2. malloc() a new buffer
>     3. memcpy() the contents to the new buffer
>     4. free() the old buffer
>     5. return the new buffer
>
> It is step 3 that breaks C++ as objects need to use their move/copy
> constructors to safely be relocated. By providing a primitive that only
> performs step 1, we impose the rest of this realloc algorthm onto the
> caller, allowing them to replace step 3 as needed. With this approach,
> there is no need to pollute code bases with std::is_relocatable() type
> traits or artificially limit the realloc() optimization to trivially
> copyable types.

Wouldn't you still want to use memcpy as an optimization where possible?
I'd strongly suspect a large block memcpy is more efficient than
performing a move of individual objects (assuming the compiler doesn't
optimize down to a large-block memcpy anyway).

> While my alloc_expand() has limited usefulness for C itself,

Really? I bet it would be more useful than you imply :-).

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_0_1391012248686
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Allicating and copying 200 characters pales in comparison to the cost of a =
system call associated with open(). And of the trip to the disk it brings. =
This is premature optimization.

Plus there would have to be some platform that supported it in their low le=
vel API; I'm not aware of any that do.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "Matthew Fioravante" <fmatthew5876@gmail.com>
To: <std-proposals@isocpp.org>
Subject: [std-proposals] Ideas for C: What could C and systems level APIs d=
o for C++ and higher level languages?
Date: Wed, Jan 29, 2014 6:03 AM

Most modern technology including C++ is still built ontop of C. This is not=
 likely to change for a long time, if ever. While C is a solid foundation, =
there are a few warts. These gaps in the C API force all of the higher leve=
l constructs to perform workarounds, to the detriment of software interface=
s and performance.

This post might belong in a C forum, but I wanted to ask. What do you think=
 C could change to make the world better for C++ and/or other languages and=
 technologies?

Here are 2 ideas:

1) Extend the memory interface with alloc_expand();
I'd love to see the C standard adopt a variant the following function in th=
eir malloc() API.

//Tries to resize p in place to newlen bytes. If successful, returns p, oth=
erwise returns NULL and the memory pointed to by p is unmodifed. Returns NU=
LL if p is NULL.
void* alloc_expand(void* p, size_t newlen);

Why? Because we should be able to take advantage of this memory optimizatio=
n for contiguous memory layout data structures  such as std::vector and std=
::string. A dynamic array is the most fundamental data structure in any lan=
guage. Contiguous memory layout is key for performance on modern hardware.

There have been several proposals and discussions about having some form of=
 realloc() in the standard.=20

Facebook even went as far as to define their own folly::IsRelocatable type =
trait to be able to tag types that are safe to memcopied with realloc(). Th=
ey have also benchmarked and shown that realloc() is a very useful optimiza=
tion for dynamicly resizing array.=20

https://github.com/facebook/folly/blob/master/folly/FBVector.h
https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md

The D language also supports this optimization on their built in array type=
.. They even go as far as to ban objects with internal pointers to ensure ev=
ery object can be relocated. I'm assuming this is so that they can take adv=
antage of realloc() and memcpy().

In my opinion, this is completely misguided and absolutely the wrong way to=
 go. The problem is not that we should support realloc(). The problem is th=
at the realloc() interface is fundamentally broken. I'd like to write a pro=
posal about this in more detail, but suffice to say, I think realloc() is a=
 complete non-starter and we need a more elementary primitive for this oper=
ation.

With realloc(), we do the following:
Resize in place if we can, ormalloc() a new buffermemcpy() the contents to =
the new bufferfree() the old bufferreturn the new buffer
It is step 3 that breaks C++ as objects need to use their move/copy constru=
ctors to safely be relocated. By providing a primitive that only performs s=
tep 1, we impose the rest of this realloc algorthm onto the caller, allowin=
g them to replace step 3 as needed. With this approach, there is no need to=
 pollute code bases with std::is_relocatable() type traits or artificially =
limit the realloc() optimization to trivially copyable types.

So why do I say this support should be in C? Because like it or not C is st=
ill the low level foundation underneath C++ and many different technologies=
.. While my alloc_expand() has limited usefulness for C itself, it has manif=
old applications for C++ and other higher level languages built on top of C=
..

There is another major practical reason that having this feature in C would=
 be of great benefit to everyone. Most of the memory allocation libraries s=
uch as jemalloc(), dlmalloc(), tcmalloc(), and friends are written to the C=
 interface. The simple reason being that writing to the C interface automat=
ically gives you support in both C and C++. Adding alloc_expand() to the C =
specification would encourage everyone writing a memory allocator to suppor=
t the primitive and guarantee support to C++ and all other higher level con=
structs built ontop this simple C interface.

Any implementation that supports realloc() can easily add alloc_expand(). F=
or a memory allocation strategy where resizing in place does not make sense=
, alloc_expand() can always return NULL.

2) First class support for non-null terminated strings

I'm a huge fan of string_view. I can't wait for this style of string proces=
sing to be the norm.=20

Why I like string_view:
std::string interfaces have serious performance issues with creating tempor=
aries for all kinds of operations which require memory allocations. std::st=
ring is also "infectious", once one of your strings is a std::string everyt=
hing that touches its tends to want to become a std::string as well.Null te=
rmination sucks too. Multiple layers of const char* interfaces often requir=
e redundant strlen() computations as the most common interfaces only accept=
 a const char* and not a length. Remembering to null terminate character ar=
rays is a specific skill that must be trained with discipline. Doing operat=
ions on the end of the string such as removing a suffix are now linear time=
..

Quick question. How do you write a File class which uses string_view to ope=
n a file on unix?

bool File::open(sting_view fname, File::Flags flags) {
std::string sfilename =3D fname; //<-Do a memory allocation and copy the wh=
ole filename just because we need a null terminator
int posix_flags =3D File::_flags_to_posix(flags);
_fd =3D ::open(sfilename.c_str(), posix_flags); //<-Likely the first thing =
this does is call strlen(), and then proceed to do the file opening.
return _fd >=3D 0;
}

Not only is this less efficient, its also painful to have to go through the=
se contortions. More code means more bugs, especially for beginners. Now we=
 have to allocate memory [O(1) + C] (<- constant time, but the constant is =
large) and then make a useless copy O(N), the open() call itself will likel=
y call strlen() O(N).

I also found this interesting bit on the zeromq page:
http://zguide.zeromq.org/page:all#A-Minor-Note-on-Strings

Specifically this code:
static char *s_recv (void *socket) {    char buffer [256];    int size =3D =
zmq_recv (socket, buffer, 255, 0);    if (size =3D=3D -1)        return NUL=
L;    if (size > 255)        size =3D 255;    buffer [size] =3D 0;    retur=
n strdup (buffer);}


I don't know about you, but that code makes me want to run away and hide. T=
hat's a lot of contortions (with possible off by 1 errors) just to deal wit=
h the fact that C forces you to use null terminated strings. The worse bein=
g that instead of just returning a pointer to the buffer already managed by=
 zmq, we have to allocate a string and impose memory management on the call=
er.

These are the kinds of contortions library implementors are forced to deal =
with when working with C APIs. When string_view becomes the defacto standar=
d for a "const reference to a variable length string", the library implemen=
tors will be forced to do these null and non-null conversions.

So what would be nice is to augment the set of string functions with new fu=
nctions which take a pointer and a length. Making non-null terminated strin=
gs viable in the C world. This would optimally require support from the C s=
tandard as well as other common standards such as POSIX. Support in the C s=
tandard would then encourage support in other C libraries, enhancing intero=
perability all around.

Some examples:

char* strdup_l(const char* s, size_t len);
FILE* fopen_l(const char* filename, size_t len, const char* mode, size_t ml=
en);
int open_l(const char* pathname, size_t len, int flags, mode_t mode);
DIR* opendir_l(const char* pathname, size_t len);
void* dlopen_l(const char* filename, size_t len, int flag);

------------------------------

What do you think C could do to help C++ and other high level languages and=
 technologies built ontop of C?




--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_0_1391012248686
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>Allic=
ating and copying 200 characters pales in comparison to the cost of a syste=
m call associated with open(). And of the trip to the disk it brings. This =
is premature optimization.</div><div><br></div><div>Plus there would have t=
o be some platform that supported it in their low level API; I'm not aware =
of any that do.</div><div><br></div><div>Sent from a touchscreen. Please ex=
cuse the brevity and tpyos.</div><br><div id=3D"htc_header">----- Reply mes=
sage -----<br>From: &quot;Matthew Fioravante&quot; &lt;fmatthew5876@gmail.c=
om&gt;<br>To: &lt;std-proposals@isocpp.org&gt;<br>Subject: [std-proposals] =
Ideas for C: What could C and systems level APIs do for C++ and higher leve=
l languages?<br>Date: Wed, Jan 29, 2014 6:03 AM</div></div><br><div dir=3D"=
ltr"><div>Most modern technology including C++ is still built ontop of C. T=
his is not likely to change for a long time, if ever. While C is a solid fo=
undation, there are a few warts. These gaps in the C API force all of the h=
igher level constructs to perform workarounds, to the detriment of software=
 interfaces and performance.</div><div><br></div><div>This post might belon=
g in a C forum, but I wanted to ask. What do you think C could change to ma=
ke the world better for C++ and/or other languages and technologies?</div><=
div><br></div><div>Here are 2 ideas:</div><div><br></div>1) Extend the memo=
ry interface with&nbsp;<span style=3D"font-size: 13px;">alloc_expand();</sp=
an><div><div><br></div><div>I'd love to see the C standard adopt a variant =
the following function in their malloc() API.</div><div><br></div><div>//Tr=
ies to resize p in place to newlen bytes. If successful, returns p, otherwi=
se returns NULL and the memory pointed to by p is unmodifed. Returns NULL i=
f p is NULL.</div><div>void* alloc_expand(void* p, size_t newlen);</div><di=
v><br></div><div>Why? Because we should be able to take advantage of this m=
emory optimization for contiguous memory layout data structures &nbsp;such =
as std::vector and std::string. A dynamic array is the most fundamental dat=
a structure in any language. Contiguous memory layout is key for performanc=
e on modern hardware.</div><div><br></div><div>There have been several prop=
osals and discussions about having some form of realloc() in the standard.&=
nbsp;</div><div><br></div><div>Facebook even went as far as to define their=
 own folly::IsRelocatable type trait to be able to tag types that are safe =
to memcopied with realloc(). They have also benchmarked and shown that real=
loc() is a very useful optimization for dynamicly resizing array.&nbsp;</di=
v></div><div><br></div><div><a href=3D"https://github.com/facebook/folly/bl=
ob/master/folly/FBVector.h">https://github.com/facebook/folly/blob/master/f=
olly/FBVector.h</a><br></div><div><a href=3D"https://github.com/facebook/fo=
lly/blob/master/folly/docs/FBVector.md">https://github.com/facebook/folly/b=
lob/master/folly/docs/FBVector.md</a><br></div><div><br></div><div>The D la=
nguage also supports this optimization on their built in array type. They e=
ven go as far as to ban objects with internal pointers to ensure every obje=
ct can be relocated. I'm assuming this is so that they can take advantage o=
f realloc() and memcpy().</div><div><br></div><div>In my opinion, this is c=
ompletely misguided and absolutely the wrong way to go. The problem is not =
that we should support realloc(). The problem is that the realloc() interfa=
ce is fundamentally broken. I'd like to write a proposal about this in more=
 detail, but suffice to say, I think realloc() is a complete non-starter an=
d we need a more elementary primitive for this operation.</div><div><br></d=
iv><div>With realloc(), we do the following:</div><div><ol><li><span style=
=3D"line-height: normal;">Resize in place if we can, or</span></li><li><spa=
n style=3D"line-height: normal;">malloc() a new buffer</span></li><li><span=
 style=3D"line-height: normal;">memcpy() the contents to the new buffer</sp=
an></li><li><span style=3D"line-height: normal;">free() the old buffer</spa=
n></li><li><span style=3D"line-height: normal;">return the new buffer</span=
></li></ol></div><div>It is step 3 that breaks C++ as objects need to use t=
heir move/copy constructors to safely be relocated. By providing a primitiv=
e that only performs step 1, we impose the rest of this realloc algorthm on=
to the caller, allowing them to replace step 3 as needed. With this approac=
h, there is no need to pollute code bases with std::is_relocatable() type t=
raits or artificially limit the realloc() optimization to trivially copyabl=
e types.</div><div><br></div><div>So why do I say this support should be in=
 C? Because like it or not C is still the low level foundation underneath C=
++ and many different technologies. While my alloc_expand() has limited use=
fulness for C itself, it has manifold applications for C++ and other higher=
 level languages built on top of C.</div><div><br></div><div>There is anoth=
er major practical reason that having this feature in C would be of great b=
enefit to everyone. Most of the memory allocation libraries such as jemallo=
c(), dlmalloc(), tcmalloc(), and friends are written to the C interface. Th=
e simple reason being that writing to the C interface automatically gives y=
ou support in both C and C++. Adding alloc_expand() to the C specification =
would encourage everyone writing a memory allocator to support the primitiv=
e and guarantee support to C++ and all other higher level constructs built =
ontop this simple C interface.</div><div><br></div><div>Any implementation =
that supports realloc() can easily add alloc_expand(). For a memory allocat=
ion strategy where resizing in place does not make sense, alloc_expand() ca=
n always return NULL.</div><div><br></div><div>2) First class support for n=
on-null terminated strings</div><div><br></div><div>I'm a huge fan of strin=
g_view. I can't wait for this style of string processing to be the norm.&nb=
sp;</div><div><br></div><div>Why I like string_view:</div><div><ul><li><spa=
n style=3D"font-size: 13px;">std::string interfaces have serious performanc=
e issues with creating temporaries for all kinds of operations which requir=
e memory allocations. std::string is also "infectious", once one of your st=
rings is a std::string everything that touches its tends to want to become =
a std::string as well.</span></li><li><span style=3D"font-size: 13px;">Null=
 termination sucks too. Multiple layers of const char* interfaces often req=
uire redundant strlen() computations as the most common interfaces only acc=
ept a const char* and not a length. Remembering to null terminate character=
 arrays is a specific skill that must be trained with discipline. Doing ope=
rations on the end of the string such as removing a suffix are now linear t=
ime.</span></li></ul></div><div><br></div><div>Quick question. How do you w=
rite a File class which uses string_view to open a file on unix?</div><div>=
<br></div><div>bool File::open(sting_view fname, File::Flags flags) {</div>=
<div>&nbsp; std::string sfilename =3D fname; //&lt;-Do a memory allocation =
and copy the whole filename just because we need a null terminator</div><di=
v>&nbsp; int posix_flags =3D File::_flags_to_posix(flags);</div><div>&nbsp;=
 _fd =3D ::open(sfilename.c_str(), posix_flags); //&lt;-Likely the first th=
ing this does is call strlen(), and then proceed to do the file opening.</d=
iv><div>&nbsp; return _fd &gt;=3D 0;<br>}</div><div><br></div><div>Not only=
 is this less efficient, its also painful to have to go through these conto=
rtions. More code means more bugs, especially for beginners. Now we have to=
 allocate memory [O(1) + C] (&lt;- constant time, but the constant is large=
) and then make a useless copy O(N), the open() call itself will likely cal=
l strlen() O(N).</div><div><br></div><div>I also found this interesting bit=
 on the zeromq page:</div><div><a href=3D"http://zguide.zeromq.org/page:all=
#A-Minor-Note-on-Strings">http://zguide.zeromq.org/page:all#A-Minor-Note-on=
-Strings</a><br></div><div><br></div><div>Specifically this code:</div><div=
><span style=3D"font-family: 'Andale Mono', 'Courier New', Courier, monospa=
ce; line-height: 16px; background-color: rgb(238, 238, 238); color: rgb(0, =
128, 0);"><strong>static</strong></span><span style=3D"color: rgb(0, 0, 0);=
 font-family: 'Andale Mono', 'Courier New', Courier, monospace; line-height=
: 16px; background-color: rgb(238, 238, 238);">&nbsp;</span><span style=3D"=
font-family: 'Andale Mono', 'Courier New', Courier, monospace; line-height:=
 16px; background-color: rgb(238, 238, 238); color: rgb(176, 0, 64);">char<=
/span><span style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono', 'Cour=
ier New', Courier, monospace; line-height: 16px; background-color: rgb(238,=
 238, 238);">&nbsp;</span><span style=3D"font-family: 'Andale Mono', 'Couri=
er New', Courier, monospace; line-height: 16px; background-color: rgb(238, =
238, 238); color: rgb(102, 102, 102);">*</span><br style=3D"color: rgb(0, 0=
, 0); font-family: 'Andale Mono', 'Courier New', Courier, monospace; line-h=
eight: 16px; background-color: rgb(238, 238, 238);"><span style=3D"font-fam=
ily: 'Andale Mono', 'Courier New', Courier, monospace; line-height: 16px; b=
ackground-color: rgb(238, 238, 238); color: rgb(0, 0, 255);">s_recv</span><=
span style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono', 'Courier New=
', Courier, monospace; line-height: 16px; background-color: rgb(238, 238, 2=
38);">&nbsp;(</span><span style=3D"font-family: 'Andale Mono', 'Courier New=
', Courier, monospace; line-height: 16px; background-color: rgb(238, 238, 2=
38); color: rgb(176, 0, 64);">void</span><span style=3D"color: rgb(0, 0, 0)=
; font-family: 'Andale Mono', 'Courier New', Courier, monospace; line-heigh=
t: 16px; background-color: rgb(238, 238, 238);">&nbsp;</span><span style=3D=
"font-family: 'Andale Mono', 'Courier New', Courier, monospace; line-height=
: 16px; background-color: rgb(238, 238, 238); color: rgb(102, 102, 102);">*=
</span><span style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono', 'Cou=
rier New', Courier, monospace; line-height: 16px; background-color: rgb(238=
, 238, 238);">socket) {</span><br style=3D"color: rgb(0, 0, 0); font-family=
: 'Andale Mono', 'Courier New', Courier, monospace; line-height: 16px; back=
ground-color: rgb(238, 238, 238);"><tt style=3D"font-family: 'Andale Mono',=
 'Courier New', Courier, monospace; color: rgb(0, 0, 0); line-height: 16px;=
 background-color: rgb(238, 238, 238);"><span style=3D"white-space: pre-wra=
p;">    </span></tt><span style=3D"font-family: 'Andale Mono', 'Courier New=
', Courier, monospace; line-height: 16px; background-color: rgb(238, 238, 2=
38); color: rgb(176, 0, 64);">char</span><span style=3D"color: rgb(0, 0, 0)=
; font-family: 'Andale Mono', 'Courier New', Courier, monospace; line-heigh=
t: 16px; background-color: rgb(238, 238, 238);">&nbsp;buffer&nbsp;</span><s=
pan style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono', 'Courier New'=
, Courier, monospace; line-height: 16px; background-color: rgb(238, 238, 23=
8); white-space: pre-wrap;">[</span><span style=3D"font-family: 'Andale Mon=
o', 'Courier New', Courier, monospace; line-height: 16px; background-color:=
 rgb(238, 238, 238); color: rgb(102, 102, 102);">256</span><span style=3D"c=
olor: rgb(0, 0, 0); font-family: 'Andale Mono', 'Courier New', Courier, mon=
ospace; line-height: 16px; background-color: rgb(238, 238, 238); white-spac=
e: pre-wrap;">]</span><span style=3D"color: rgb(0, 0, 0); font-family: 'And=
ale Mono', 'Courier New', Courier, monospace; line-height: 16px; background=
-color: rgb(238, 238, 238);">;</span><br style=3D"color: rgb(0, 0, 0); font=
-family: 'Andale Mono', 'Courier New', Courier, monospace; line-height: 16p=
x; background-color: rgb(238, 238, 238);"><tt style=3D"font-family: 'Andale=
 Mono', 'Courier New', Courier, monospace; color: rgb(0, 0, 0); line-height=
: 16px; background-color: rgb(238, 238, 238);"><span style=3D"white-space: =
pre-wrap;">    </span></tt><span style=3D"font-family: 'Andale Mono', 'Cour=
ier New', Courier, monospace; line-height: 16px; background-color: rgb(238,=
 238, 238); color: rgb(176, 0, 64);">int</span><span style=3D"color: rgb(0,=
 0, 0); font-family: 'Andale Mono', 'Courier New', Courier, monospace; line=
-height: 16px; background-color: rgb(238, 238, 238);">&nbsp;size&nbsp;</spa=
n><span style=3D"font-family: 'Andale Mono', 'Courier New', Courier, monosp=
ace; line-height: 16px; background-color: rgb(238, 238, 238); color: rgb(10=
2, 102, 102);">=3D</span><span style=3D"color: rgb(0, 0, 0); font-family: '=
Andale Mono', 'Courier New', Courier, monospace; line-height: 16px; backgro=
und-color: rgb(238, 238, 238);">&nbsp;zmq_recv (socket, buffer,&nbsp;</span=
><span style=3D"font-family: 'Andale Mono', 'Courier New', Courier, monospa=
ce; line-height: 16px; background-color: rgb(238, 238, 238); color: rgb(102=
, 102, 102);">255</span><span style=3D"color: rgb(0, 0, 0); font-family: 'A=
ndale Mono', 'Courier New', Courier, monospace; line-height: 16px; backgrou=
nd-color: rgb(238, 238, 238);">,&nbsp;</span><span style=3D"font-family: 'A=
ndale Mono', 'Courier New', Courier, monospace; line-height: 16px; backgrou=
nd-color: rgb(238, 238, 238); color: rgb(102, 102, 102);">0</span><span sty=
le=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono', 'Courier New', Couri=
er, monospace; line-height: 16px; background-color: rgb(238, 238, 238);">);=
</span><br style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono', 'Couri=
er New', Courier, monospace; line-height: 16px; background-color: rgb(238, =
238, 238);"><tt style=3D"font-family: 'Andale Mono', 'Courier New', Courier=
, monospace; color: rgb(0, 0, 0); line-height: 16px; background-color: rgb(=
238, 238, 238);"><span style=3D"white-space: pre-wrap;">    </span></tt><sp=
an style=3D"font-family: 'Andale Mono', 'Courier New', Courier, monospace; =
line-height: 16px; background-color: rgb(238, 238, 238); color: rgb(0, 128,=
 0);"><strong>if</strong></span><span style=3D"color: rgb(0, 0, 0); font-fa=
mily: 'Andale Mono', 'Courier New', Courier, monospace; line-height: 16px; =
background-color: rgb(238, 238, 238);">&nbsp;(size&nbsp;</span><span style=
=3D"font-family: 'Andale Mono', 'Courier New', Courier, monospace; line-hei=
ght: 16px; background-color: rgb(238, 238, 238); color: rgb(102, 102, 102);=
">=3D=3D</span><span style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mon=
o', 'Courier New', Courier, monospace; line-height: 16px; background-color:=
 rgb(238, 238, 238);">&nbsp;</span><span style=3D"font-family: 'Andale Mono=
', 'Courier New', Courier, monospace; line-height: 16px; background-color: =
rgb(238, 238, 238); color: rgb(102, 102, 102);">-</span><span style=3D"font=
-family: 'Andale Mono', 'Courier New', Courier, monospace; line-height: 16p=
x; background-color: rgb(238, 238, 238); color: rgb(102, 102, 102);">1</spa=
n><span style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono', 'Courier =
New', Courier, monospace; line-height: 16px; background-color: rgb(238, 238=
, 238);">)</span><br style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mon=
o', 'Courier New', Courier, monospace; line-height: 16px; background-color:=
 rgb(238, 238, 238);"><tt style=3D"font-family: 'Andale Mono', 'Courier New=
', Courier, monospace; color: rgb(0, 0, 0); line-height: 16px; background-c=
olor: rgb(238, 238, 238);"><span style=3D"white-space: pre-wrap;">        <=
/span></tt><span style=3D"font-family: 'Andale Mono', 'Courier New', Courie=
r, monospace; line-height: 16px; background-color: rgb(238, 238, 238); colo=
r: rgb(0, 128, 0);"><strong>return</strong></span><span style=3D"color: rgb=
(0, 0, 0); font-family: 'Andale Mono', 'Courier New', Courier, monospace; l=
ine-height: 16px; background-color: rgb(238, 238, 238);">&nbsp;</span><span=
 style=3D"font-family: 'Andale Mono', 'Courier New', Courier, monospace; li=
ne-height: 16px; background-color: rgb(238, 238, 238); color: rgb(0, 128, 0=
);">NULL</span><span style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mon=
o', 'Courier New', Courier, monospace; line-height: 16px; background-color:=
 rgb(238, 238, 238);">;</span><br style=3D"color: rgb(0, 0, 0); font-family=
: 'Andale Mono', 'Courier New', Courier, monospace; line-height: 16px; back=
ground-color: rgb(238, 238, 238);"><tt style=3D"font-family: 'Andale Mono',=
 'Courier New', Courier, monospace; color: rgb(0, 0, 0); line-height: 16px;=
 background-color: rgb(238, 238, 238);"><span style=3D"white-space: pre-wra=
p;">    </span></tt><span style=3D"font-family: 'Andale Mono', 'Courier New=
', Courier, monospace; line-height: 16px; background-color: rgb(238, 238, 2=
38); color: rgb(0, 128, 0);"><strong>if</strong></span><span style=3D"color=
: rgb(0, 0, 0); font-family: 'Andale Mono', 'Courier New', Courier, monospa=
ce; line-height: 16px; background-color: rgb(238, 238, 238);">&nbsp;(size&n=
bsp;</span><span style=3D"font-family: 'Andale Mono', 'Courier New', Courie=
r, monospace; line-height: 16px; background-color: rgb(238, 238, 238); colo=
r: rgb(102, 102, 102);">&gt;</span><span style=3D"color: rgb(0, 0, 0); font=
-family: 'Andale Mono', 'Courier New', Courier, monospace; line-height: 16p=
x; background-color: rgb(238, 238, 238);">&nbsp;</span><span style=3D"font-=
family: 'Andale Mono', 'Courier New', Courier, monospace; line-height: 16px=
; background-color: rgb(238, 238, 238); color: rgb(102, 102, 102);">255</sp=
an><span style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono', 'Courier=
 New', Courier, monospace; line-height: 16px; background-color: rgb(238, 23=
8, 238);">)</span><br style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mo=
no', 'Courier New', Courier, monospace; line-height: 16px; background-color=
: rgb(238, 238, 238);"><tt style=3D"font-family: 'Andale Mono', 'Courier Ne=
w', Courier, monospace; color: rgb(0, 0, 0); line-height: 16px; background-=
color: rgb(238, 238, 238);"><span style=3D"white-space: pre-wrap;">        =
</span></tt><span style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono',=
 'Courier New', Courier, monospace; line-height: 16px; background-color: rg=
b(238, 238, 238);">size&nbsp;</span><span style=3D"font-family: 'Andale Mon=
o', 'Courier New', Courier, monospace; line-height: 16px; background-color:=
 rgb(238, 238, 238); color: rgb(102, 102, 102);">=3D</span><span style=3D"c=
olor: rgb(0, 0, 0); font-family: 'Andale Mono', 'Courier New', Courier, mon=
ospace; line-height: 16px; background-color: rgb(238, 238, 238);">&nbsp;</s=
pan><span style=3D"font-family: 'Andale Mono', 'Courier New', Courier, mono=
space; line-height: 16px; background-color: rgb(238, 238, 238); color: rgb(=
102, 102, 102);">255</span><span style=3D"color: rgb(0, 0, 0); font-family:=
 'Andale Mono', 'Courier New', Courier, monospace; line-height: 16px; backg=
round-color: rgb(238, 238, 238);">;</span><br style=3D"color: rgb(0, 0, 0);=
 font-family: 'Andale Mono', 'Courier New', Courier, monospace; line-height=
: 16px; background-color: rgb(238, 238, 238);"><tt style=3D"font-family: 'A=
ndale Mono', 'Courier New', Courier, monospace; color: rgb(0, 0, 0); line-h=
eight: 16px; background-color: rgb(238, 238, 238);"><span style=3D"white-sp=
ace: pre-wrap;">    </span></tt><span style=3D"color: rgb(0, 0, 0); font-fa=
mily: 'Andale Mono', 'Courier New', Courier, monospace; line-height: 16px; =
background-color: rgb(238, 238, 238);">buffer&nbsp;</span><span style=3D"co=
lor: rgb(0, 0, 0); font-family: 'Andale Mono', 'Courier New', Courier, mono=
space; line-height: 16px; background-color: rgb(238, 238, 238); white-space=
: pre-wrap;">[</span><span style=3D"color: rgb(0, 0, 0); font-family: 'Anda=
le Mono', 'Courier New', Courier, monospace; line-height: 16px; background-=
color: rgb(238, 238, 238);">size</span><span style=3D"color: rgb(0, 0, 0); =
font-family: 'Andale Mono', 'Courier New', Courier, monospace; line-height:=
 16px; background-color: rgb(238, 238, 238); white-space: pre-wrap;">]</spa=
n><span style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono', 'Courier =
New', Courier, monospace; line-height: 16px; background-color: rgb(238, 238=
, 238);">&nbsp;</span><span style=3D"font-family: 'Andale Mono', 'Courier N=
ew', Courier, monospace; line-height: 16px; background-color: rgb(238, 238,=
 238); color: rgb(102, 102, 102);">=3D</span><span style=3D"color: rgb(0, 0=
, 0); font-family: 'Andale Mono', 'Courier New', Courier, monospace; line-h=
eight: 16px; background-color: rgb(238, 238, 238);">&nbsp;</span><span styl=
e=3D"font-family: 'Andale Mono', 'Courier New', Courier, monospace; line-he=
ight: 16px; background-color: rgb(238, 238, 238); color: rgb(102, 102, 102)=
;">0</span><span style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono', =
'Courier New', Courier, monospace; line-height: 16px; background-color: rgb=
(238, 238, 238);">;</span><br style=3D"color: rgb(0, 0, 0); font-family: 'A=
ndale Mono', 'Courier New', Courier, monospace; line-height: 16px; backgrou=
nd-color: rgb(238, 238, 238);"><tt style=3D"font-family: 'Andale Mono', 'Co=
urier New', Courier, monospace; color: rgb(0, 0, 0); line-height: 16px; bac=
kground-color: rgb(238, 238, 238);"><span style=3D"white-space: pre-wrap;">=
    </span></tt><span style=3D"font-family: 'Andale Mono', 'Courier New', C=
ourier, monospace; line-height: 16px; background-color: rgb(238, 238, 238);=
 color: rgb(0, 128, 0);"><strong>return</strong></span><span style=3D"color=
: rgb(0, 0, 0); font-family: 'Andale Mono', 'Courier New', Courier, monospa=
ce; line-height: 16px; background-color: rgb(238, 238, 238);">&nbsp;strdup =
(buffer);</span><br style=3D"color: rgb(0, 0, 0); font-family: 'Andale Mono=
', 'Courier New', Courier, monospace; line-height: 16px; background-color: =
rgb(238, 238, 238);"><span style=3D"color: rgb(0, 0, 0); font-family: 'Anda=
le Mono', 'Courier New', Courier, monospace; line-height: 16px; background-=
color: rgb(238, 238, 238);">}</span><br></div><div><span style=3D"color: rg=
b(0, 0, 0); font-family: 'Andale Mono', 'Courier New', Courier, monospace; =
line-height: 16px; background-color: rgb(238, 238, 238);"><br></span></div>=
<div>I don't know about you, but that code makes me want to run away and hi=
de. That's a lot of contortions (with possible off by 1 errors) just to dea=
l with the fact that C forces you to use null terminated strings. The worse=
 being that instead of just returning a pointer to the buffer already manag=
ed by zmq, we have to allocate a string and impose memory management on the=
 caller.</div><div><br></div><div>These are the kinds of contortions librar=
y implementors are forced to deal with when working with C APIs. When strin=
g_view becomes the defacto standard for a "const reference to a variable le=
ngth string", the library implementors will be forced to do these null and =
non-null conversions.<br></div><div><br></div><div>So what would be nice is=
 to augment the set of string functions with new functions which take a poi=
nter and a length. Making non-null terminated strings viable in the C world=
.. This would optimally require support from the C standard as well as other=
 common standards such as POSIX. Support in the C standard would then encou=
rage support in other C libraries, enhancing interoperability all around.</=
div><div><br></div><div>Some examples:</div><div><br></div><div>char* strdu=
p_l(const char* s, size_t len);</div><div>FILE* fopen_l(const char* filenam=
e, size_t len, const char* mode, size_t mlen);</div><div>int open_l(const c=
har* pathname, size_t len, int flags, mode_t mode);</div><div>DIR* opendir_=
l(const char* pathname, size_t len);</div><div>void* dlopen_l(const char* f=
ilename, size_t len, int flag);</div><div><br></div><div>------------------=
------------</div><div><br></div><div>What do you think C could do to help =
C++ and other high level languages and technologies built ontop of C?</div>=
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_0_1391012248686--


.

------=_Part_5427_15164405.1391024865659
Content-Type: text/plain; charset=UTF-8

There has been some attempts by certain people to greatly augment the
currently anemic C memory allocation APIs.  In particular, see the
try_realloc and batch_alloc families of proposed functions.  The
batch_alloc interfaces allow allocating large chunks of address space
without requiring the memory to be committed, useful for large dynamic
containers on systems with large address space (64-bit systems) and the
try_realloc is a convenient way to allow efficient resizing of memory
without doing a copy implicitly (so you can try to efficiently resize
container storage for non-POD types and then only do the more expensive
allocate-and-copy loop if that attempt fails).

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1527.pdf
http://mallocv2.wordpress.com/the-c-proposal-text/the-old-c-proposal-text/

I don't know what the status is.  I don't believe it got accepted for C11,
but I could be wrong.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5427_15164405.1391024865659
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There has been some attempts by certain people to greatly =
augment the currently anemic C memory allocation APIs. &nbsp;In particular,=
 see the try_realloc and batch_alloc families of proposed functions. &nbsp;=
The batch_alloc interfaces allow allocating large chunks of address space w=
ithout requiring the memory to be committed, useful for large dynamic conta=
iners on systems with large address space (64-bit systems) and the try_real=
loc is a convenient way to allow efficient resizing of memory without doing=
 a copy implicitly (so you can try to efficiently resize container storage =
for non-POD types and then only do the more expensive allocate-and-copy loo=
p if that attempt fails).<div><br></div><div>http://www.open-std.org/jtc1/s=
c22/wg14/www/docs/n1527.pdf<br></div><div>http://mallocv2.wordpress.com/the=
-c-proposal-text/the-old-c-proposal-text/<br></div><div><br></div><div>I do=
n't know what the status is. &nbsp;I don't believe it got accepted for C11,=
 but I could be wrong.</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5427_15164405.1391024865659--

.

------=_Part_316_4642538.1391050996094
Content-Type: text/plain; charset=UTF-8


One of the things that bothers me about the C/C++ debate, is that to my
mind, C is useful for creating interfaces that everybody can use from other
languages (albeit with difficulty)

That is one of the reasons I assume C has been so popular and useful.

C++ on the other hand creates potentially much more useable interfaces,
but really only useable from C++.

Then from time to time (it feels like) C++ ends up inheriting a load
of ugly interfaces from C or duplicating them such no other language can
use them..And there becomes several ways to do the same thing.

I don't know if this is a real or perceived problem, but it would be nice
to feel that we build things such that there it leaves a low level C only
library, and people would from other languages would use that, with a C++
library that builds on those foundations. It would feel even nicer if even
those abstractions were useful in other languages.

I know that isn't a realistic view. It's the component model / ABI problem
or something, I don't know.

But right now I perceive C gets lots of ugly interfaces that
aren't pleasant but at least useful by anyone and C++ duplicates those to
create nicer interfaces that aren't usable by anyone and inherits half the
C interfaces in a bad way later on.

They don't feel layered. Maybe the string conversion functions we are
talking about in another thread are an example of this. I don't know.

And it's templates, templates, templates everywhere for everything which
after all these years I still don't feel entirely good about.

Please don't take all of this too literally, it's a feeling more than a
thought

Is there any truth to any of this this or remedy / improvement for it.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_316_4642538.1391050996094
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>One of the things that bothers me abou=
t the C/C++ debate, is that to my mind, C is useful for creating&nbsp;inter=
faces that everybody can use from other languages&nbsp;(albeit with difficu=
lty)</div><div><br></div><div>That is one of the reasons I assume C has bee=
n so popular and useful.</div><div><br></div><div>C++&nbsp;on the other han=
d creates potentially much more useable interfaces, but&nbsp;really only us=
eable from C++.</div><div><br></div><div>Then from time to time (it feels l=
ike) C++ ends up inheriting a load of&nbsp;ugly interfaces from C or duplic=
ating them such&nbsp;no other language can use them..And there becomes seve=
ral ways to do the same thing.</div><div><br></div><div>I don't know if thi=
s is a real or perceived problem, but it would be nice to feel&nbsp;that we=
 build things such that there it leaves&nbsp;a low level C only library,&nb=
sp;and people would from other languages&nbsp;would use that, with&nbsp;a C=
++ library that builds on those foundations. It would feel even nicer if ev=
en those abstractions were useful in other languages.</div><div><br></div><=
div>I know that isn't a&nbsp;realistic view. It's the component model / ABI=
 problem or something, I don't know.</div><div><br></div><div>But right now=
 I&nbsp;perceive&nbsp;C gets lots of ugly interfaces that aren't&nbsp;pleas=
ant but at least useful by anyone and&nbsp;C++ duplicates those to create n=
icer interfaces that aren't usable by anyone and inherits half the C interf=
aces in a bad way later on.</div><div><br></div><div><div>They don't feel l=
ayered. Maybe the string conversion functions we are talking about in anoth=
er thread are an example of this. I don't know.</div></div><div><br></div><=
div>And it's templates, templates, templates&nbsp;everywhere for everything=
 which after all these years I still don't feel entirely good about.</div><=
div><br></div><div>Please don't take all of this too literally, it's a feel=
ing more than a thought</div><div><br></div><div>Is there any truth to any =
of this this or remedy / improvement for it.</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_316_4642538.1391050996094--

.

------=_Part_43_1471881.1392217166845
Content-Type: text/plain; charset=UTF-8



On Wednesday, January 29, 2014 3:03:33 PM UTC+1, Matthew Fioravante wrote:
>
> The D language also supports this optimization on their built in array
> type. They even go as far as to ban objects with internal pointers to
> ensure every object can be relocated. I'm assuming this is so that they can
> take advantage of realloc() and memcpy().
>
> This is a minor point, but from "The D Programming Language", I got the
impression that the primary motivation for this is supporting destructive
move without any user-added support: when moving an object, just memcpy it
to the new place and don't destruct the original.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_43_1471881.1392217166845
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, January 29, 2014 3:03:33 PM UTC+1, M=
atthew Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>The D language also supports this optimization on their bui=
lt in array type. They even go as far as to ban objects with internal point=
ers to ensure every object can be relocated. I'm assuming this is so that t=
hey can take advantage of realloc() and memcpy().<br></div><div><br></div><=
/div></blockquote><div>This is a minor point, but from "The D Programming L=
anguage", I got the impression that the primary motivation for this is supp=
orting destructive move without any user-added support: when moving an obje=
ct, just memcpy it to the new place and don't destruct the original.&nbsp;<=
/div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_43_1471881.1392217166845--

.

------=_Part_369_5265357.1392961549006
Content-Type: text/plain; charset=UTF-8


On Wednesday, January 29, 2014 6:03:33 AM UTC-8, Matthew Fioravante wrote:
>
> This post might belong in a C forum, but I wanted to ask. What do you
> think C could change to make the world better for C++ and/or other
> languages and technologies?
>

Later versions of C could make something between C99's variable-length
array craziness and C++'s total lack thereof, so that C++ could adopt it.
I'm sick and tired of having to use alloca in C++ when it could be a lot
cleaner, like in the extension that GCC and clang already have (and I can't
use because MSVC doesn't have).

Variable-length arrays should just be stack allocations and
constructor/destructor calls, and nothing more.  None of the weird
parameter passing stuff that C99 had.  sizeof should just be a compiler
error rather than be a special runtime-computed case.  I suppose that it
*could* return the size of Type*, but that would be very error-prone.

Melissa

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_369_5265357.1392961549006
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Wednesday, January 29, 2014 6:03:33 AM UTC-8, Matth=
ew Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">This post might belong in a C forum, but I wanted to ask. What do =
you think C could change to make the world better for C++ and/or other lang=
uages and technologies?</div></blockquote><div><br>Later versions of C coul=
d make something between C99's variable-length array craziness and C++'s to=
tal lack thereof, so that C++ could adopt it.&nbsp; I'm sick and tired of h=
aving to use alloca in C++ when it could be a lot cleaner, like in the exte=
nsion that GCC and clang already have (and I can't use because MSVC doesn't=
 have).<br><br>Variable-length arrays should just be stack allocations and =
constructor/destructor calls, and nothing more.&nbsp; None of the weird par=
ameter passing stuff that C99 had.&nbsp; sizeof should just be a compiler e=
rror rather than be a special runtime-computed case.&nbsp; I suppose that i=
t *could* return the size of Type*, but that would be very error-prone.<br>=
<br>Melissa<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_369_5265357.1392961549006--

.