Friday, September 29, 2017

Digest for comp.lang.c++@googlegroups.com - 12 updates in 5 topics

Joseph Hesse <joeh@gmail.com>: Sep 29 10:37AM -0500

I am surprised that the following compiles with g++.
 
void f(int x)
{
int a[x];
}
 
I thought that the size of such an array had to be known at compile time
and couldn't be created at run time? Is this a new feature?
Thank you,
Joe
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 29 11:42AM -0400

On 9/29/2017 11:37 AM, Joseph Hesse wrote:
> and couldn't be created at run time? Is this a new feature?
> Thank you,
> Joe
 
GCC has allowed VLA's in C++ for a while:
 
https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
 
--
Thank you, | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA/C, Debi, RDC, CAlive, ES/2, VJr, VFrP, Logician, C90/99
Hardware:
Aroxda Desktop CPU -- 40-bit multi-core 80386 with many extensions
Arxita Embedded CPU -- Low power, low pin count 80386 w/128 registers
Arlina Compute FPGA -- Scalable compute cores, large GPIO pin count
red floyd <dont.bother@its.invalid>: Sep 29 01:46PM -0700

On 9/29/2017 10:12 AM, Stefan Ram wrote:
 
> This might be a compiler-specific extension.
 
> Maybe you would like to try:
 
> -std=c++14 -pedantic -pedantic-errors
 
Isn't that a C99-ism?
bitrex <bitrex@de.lete.earthlink.net>: Sep 29 06:15PM -0400

On 09/29/2017 01:12 PM, Stefan Ram wrote:
 
> This might be a compiler-specific extension.
 
> Maybe you would like to try:
 
> -std=c++14 -pedantic -pedantic-errors
 
It compiles OK with -std=C++98 for all versions of gcc for x86-64 over
4.4.7; the -pedantic flag gives the warning "ISO C++ forbids variable
length arrays." Clang 3.0 and above for x86-64 it also compiles but
warns "variable length arrays are a C99 feature, accepted as extension"
with -std=C++98 -pedantic; with -std=C++14 -pedantic for clang 3.5 and
above it just reports "variable length arrays are a C99 feature"
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 29 09:44AM -0400

I was hoping to get some feedback on a feature I'm adding to CAlive.
It's called parameter redirects. It's designed to allow incoming
parameters to be auto-assigned to other variables (before the first
local line of function code is run), and to assign a single input
value to multiple targets, including type conversion.
 

https://groups.google.com/d/msg/caliveprogramminglanguage/Bgx4v4xLhXc/6cXeHw2FAwAJ
 
Example:
 
my_function(1, 2, 3, 4);
 
void my_function(int a, int b, to max, total, int c)
{
int i = 5; // By the time this line of code is
// run, max and total are already set
// to the value of the 3rd parameter
 
int max, total;
 
// Right now:
// a = 1
// b = 2
// max = 3, total = 3
// c = 4
// i = 5
}
 
It derives the target type by the name in use, and CAlive auto-
performs conversions where they're defined, and standard casts
where they're not defined.
 
To create new types from a single input parameter, use the syntax:
 
void my_function(int a, int b, to {int max, int total}, int c)
{
int i = 5;
 
// Right now:
// a = 1
// b = 2
// max = 3, total = 3
// c = 4
// i = 5
}
 
Please advise any notes or comments. Thank you in advance.
 
--
Thank you, | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA/C, Debi, RDC, CAlive, ES/2, VJr, VFrP, Logician, C90/99
Hardware:
Aroxda Desktop CPU -- 40-bit multi-core 80386 with many extensions
Arxita Embedded CPU -- Low power, low pin count 80386 w/128 registers
Arlina Compute FPGA -- Scalable compute cores, large GPIO pin count
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Sep 29 12:24PM -0700

On 9/29/2017 6:44 AM, Rick C. Hodgin wrote:
> parameters to be auto-assigned to other variables (before the first
> local line of function code is run), and to assign a single input
> value to multiple targets, including type conversion.
[...]
 
Damn it Jim... Create a little compiler that others can use wrt playing
around with CAlive. Make it relatively easy to install. If you keep
adding new features, the damn thing might never get into a solid state.
 
Perhaps, you should create an online CAlive compiler. I can go to your
site, type in my program, hit compile and see output.
red floyd <dont.bother@its.invalid>: Sep 29 01:47PM -0700

On 9/29/2017 12:24 PM, Chris M. Thomasson wrote:
> adding new features, the damn thing might never get into a solid state.
 
> Perhaps, you should create an online CAlive compiler. I can go to your
> site, type in my program, hit compile and see output.
 
But it won't allow constants that equal 666. It's his "Christian"
compiler/language.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 29 01:59PM -0700

On Friday, September 29, 2017 at 4:47:47 PM UTC-4, red floyd wrote:
> But it won't allow constants that equal 666. It's his "Christian"
> compiler/language.
 
When I worked at a place that had production lines, I created a
desktop app which shows our production lines and their working
unit numbers using a large display, and the values would cycle
through repeatedly from 000 to 999 and then repeat. It typically
took a few days to cycle.
 
I actually coded the display, which showed the current item being
processed on a very large flat screen monitor, to show "66_" when
they were on 666.
 
Management let it stand. :-) It was that way all the time I was
there. People would always laugh when that number came around.
 
Thank you,
Rick C. Hodgin
bitrex <bitrex@de.lete.earthlink.net>: Sep 29 03:26PM -0400

I have the following code using boost::varaint and boost::flyweight.
This wrapper class is used to wrap either an "image bitmap" which is
loaded from a file and key-value flyweighted (so the same data isn't
loaded from storage into memory repeatedly), or a "buffer bitmap" which
is just an internally-generated "scratchpad" that likely won't have much
repetition.
 
The problem is the segment with the user-defined conversion to
"APIBitmapType*" - I added the temporary instead of returning the result
of applying the visitor directly because the API I'm handing that off
too kept segfaulting when functions taking a particular template type
were called on the conversion. Stepping thru the debugger shows that the
variant returns the address of the appropriate bitmap object just fine,
but on the next line with the return the pointer value immediately
changes to null prior to being returned.
 
Frustratingly, this code was working OK before until I started making
some tidy-up changes to the header file structure that this class was
originally in; I didn't change the code itself at all. Can't figure out
what I did to break it...
 
template <typename APIBitmapType>
class BitmapWrapper {
typedef boost::flyweights::flyweight<boost::flyweights::key_value<
const char*, file_bitmap_t<APIBitmapType>>> file_bitmap_flyweight_t;
 
typedef boost::variant<buffer_bitmap_t<APIBitmapType>,
file_bitmap_t> bitmap_variant_t;
 
public:
template <typename... Args,
typename = decltype(
buffer_bitmap_t<APIBitmapType>(std::declval<Args>()...))>
explicit BitmapWrapper(Args&&... args)
: _bitmap(std::make_shared<bitmap_variant_t>(

buffer_bitmap_t<APIBitmapType>(std::forward<Args>(args)...))) {}
 
explicit BitmapWrapper(const char* filename)
: _bitmap(std::make_shared<bitmap_variant_t>(
file_bitmap_flyweight_t(filename))) {}
 
APIBitmapType* operator&() const
{
return boost::apply_visitor(bitmap_visitor<APIBitmapType>(),
*_bitmap);
}
 
operator APIBitmapType*() const {
auto test = boost::apply_visitor(bitmap_visitor<APIBitmapType>(),
*_bitmap);
return test;
}
 
private:
std::shared_ptr<bitmap_variant_t> _bitmap;
};
 
 
 
 
template <typename APIBitmapType>
class bitmap_visitor : public boost::static_visitor<APIBitmapType*>
{
typedef
boost::flyweights::flyweight<boost::flyweights::key_value<const char*,
file_bitmap_t<APIBitmapType>>>
file_bitmap_flyweight_t;
 
public:
APIBitmapType* operator()(const file_bitmap_flyweight_t& bitmap) const
{
return bitmap.get().get();
}
 
APIBitmapType* operator()(const buffer_bitmap_t<APIBitmapType>&
bitmap) const
{
return bitmap.get();
}
};
ram@zedat.fu-berlin.de (Stefan Ram): Sep 29 05:12PM

>{
> int a[x];
>}
 
This might be a compiler-specific extension.
 
Maybe you would like to try:
 
-std=c++14 -pedantic -pedantic-errors
 
.
"Öö Tiib" <ootiib@hot.ee>: Sep 28 11:25PM -0700

On Friday, 29 September 2017 00:38:00 UTC+3, Chris M. Thomasson wrote:
> >> for he loved spamming usenet.
 
> > It's an incorrect assumption to think these message are spam.
 
> Bait?
 
His madness. The invisible pink unicorns are magical because how else
those can be invisible and pink at same time?
red floyd <dont.bother@its.invalid>: Sep 29 09:10AM -0700

On 9/28/2017 11:25 PM, Öö Tiib wrote:
 
>> Bait?
 
> His madness. The invisible pink unicorns are magical because how else
> those can be invisible and pink at same time?
 
Heresy!! All know that the IPU is phony, while the FSM is real!!!
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)