Wednesday, September 20, 2017

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

Daniel <danielaparker@gmail.com>: Sep 19 07:21PM -0700

I need to be able to initialize a basic_string to a constant in a generic fashion, where the constant is restricted to ascii characters, e.g.
 
#include <string>
#include <vector>
#include <iostream>
 
template <class CharT>
struct A
{
const std::vector<std::basic_string<CharT>> v =
{
std::basic_string<CharT>{'t','r','u','e'},
std::basic_string<CharT>{'f','a','l','s','e'}
};
};
 
int main()
{
A<char> a;
A<wchar_t> b;
 
std::cout << a.v[0] << std::endl;
std::wcout << b.v[1] << std::endl;
}
 
However, I also want to support a compiler that doesn't support a basic_string<CharT> std::initializer_list<CharT> constructor. Any suggestion for a simple workaround that only requires a pre C++ 11 string constructor?
 
Thanks,
Daniel
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 20 08:36AM +0200

On 9/20/2017 4:21 AM, Daniel wrote:
> basic_string<CharT> std::initializer_list<CharT> constructor. Any
> suggestion for a simple workaround that only requires a pre C++ 11
> string constructor?
 
For pre-C++11 (C++03 and C++98) the T in std::basic_string<T> is in
practice either `char` or `wchar_t` – because it's too much work to
specialize `std::character_traits` for any other type, and without such
specialization std::basic_string<T> is very limited, useless.
 
So, I suggest you use a macro to define pairs of literals:
 
#define DEF_LITERAL( name, lit ) \
char const* const bytestr_name = lit; \
wchar_t const* const widestr_name = L # lit; \
template< class Ch ) Ch const* name(); \
char const* name<char>() { return bytestr_name; } \
wchar_t const* name<char>() { return widestr_name; }
 
Then use like
 
DEF_LITERAL( baluba, "Real baluba!" )
 
void foo()
{
wstring s = baluba<wchar_t>();
}
 
Disclaimer: code not seen by compiler.
 
 
Cheers & hth.,
 
- Alf
Daniel <danielaparker@gmail.com>: Sep 20 09:50AM -0700

On Wednesday, September 20, 2017 at 2:36:38 AM UTC-4, Alf P. Steinbach wrote:
> wstring s = baluba<wchar_t>();
> }
 
> Disclaimer: code not seen by compiler.
 
Silly compiler should have known what you meant, but this one works:
 
#define DEF_LITERAL( name, lit ) \
template< class Ch > Ch const*const name(); \
template<> char const * const name<char>() { return lit; } \
template<> wchar_t const*const name<wchar_t>() { return L ## lit; }
 
DEF_LITERAL(baluba, "Real baluba!")
 
int main()
{
std::cout << baluba<char>() << std::endl;
std::wcout << baluba<wchar_t>() << std::endl;
}
 
Thanks,
Daniel
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 20 09:22PM +0200

On 9/20/2017 6:50 PM, Daniel wrote:
> std::cout << baluba<char>() << std::endl;
> std::wcout << baluba<wchar_t>() << std::endl;
> }
 
Oh, yes.
 
Note that (for undisclosed reasons) I'm unfortunately often stupid these
days, like the above # . So, I forgot to discuss issues of separate
compilation and inlining in header. Hopefully others here will chime in.
 
 
Cheers!,
 
- Alf
Daniel <danielaparker@gmail.com>: Sep 20 01:43PM -0700

On Wednesday, September 20, 2017 at 3:22:57 PM UTC-4, Alf P. Steinbach wrote:
> compilation and inlining in header. Hopefully others here will chime in.
 
> Cheers!,
 
> - Alf
 
The linker thought to mention that, changed to
 
namespace detail {
#define DEF_LITERAL( name, lit ) \
template< class Ch > Ch const*const name(); \
template<> inline char const * const name<char>() { return lit; } \
template<> inline wchar_t const*const name<wchar_t>() { return L ## lit; }
 
Daniel
Ryan Bird <rlbird22@gmail.com>: Sep 19 09:27PM -0700

> If this is true then why the "T * const" may be stored in STL containers ?
> Please write me why references cannot be stored in STL containers.
 
> thanks for help
 
References are not reassignable. However, std::reference_wrapper was made to allow reassignable references.
 
http://en.cppreference.com/w/cpp/utility/functional/reference_wrapper
http://www.cplusplus.com/reference/functional/reference_wrapper/
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 20 08:54AM +0200

On 9/19/2017 7:19 PM, Mr Flibble wrote:
 
>> thanks for help
 
> You won't get very far trying to use std::vector with "T* const" or any
> other const value_type.
 
Oh, I didn't notice that `const`. :( You're very right about that.
 
The relevant error message from Visual C++ is very informative:
 
"error C2338: The C++ Standard forbids containers of const elements
because allocator<const T> is ill-formed."
 
E.g. this pair of overloads in `std::allocator`,
 
pointer address( reference x ) const;
const_pointer address( const_reference x ) const;
 
would have the same signature when `reference` is defined as e.g. `int
const&`. And one can't define overloads with the same signature. That's
the "ill-formed" in the Visual C++ error message.
 
 
Cheers!,
 
- Alf
porparek@gmail.com: Sep 20 09:16AM -0700

On Wednesday, September 20, 2017 at 8:54:25 AM UTC+2, Alf P. Steinbach wrote:
> the "ill-formed" in the Visual C++ error message.
 
> Cheers!,
 
> - Alf
 
Great thanks for reply.
On gcc-7.2.0 the following code compiles and runs with no errors:
std::list<int*const> l;
l.push_back(new int(99));
for ( int* i : l )
std::cout << *i;
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 20 06:51PM +0100

> l.push_back(new int(99));
> for ( int* i : l )
> std::cout << *i;
 
Just because it works for a subset of operations on a subset of
container types doesn't mean it works for a different subset of
operations on a different subset of container types.
 
/Flibble
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 20 09:01AM -0400

I wrote some information about this on the comp.lang.c group:
 
https://groups.google.com/d/msg/comp.lang.c/g2SQtKLb5tA/GttChkh0AQAJ
 
Here is the content copied:
 
-----[ Begin ]-----
As the design stage of CAlive progresses, I can see light at the end
of the tunnel. Still much to do, but there is a goal in sight, a
series of steps to get there. There are very few details left to
work out for a 32-bit 80386+ implementation of its design. After
that, it's on to coding and debugging the RDC framework CAlive will
use for its creation.
 
CAlive could be generating production binary code by the end of 2019
in its own new RDC framework, with other languages following quickly
thereafter.
 
If I were prone to celebrating milestones, I might do that about now.
 
I'm so excited about CAlive. It's what I've always wanted in a
programming language. Powerful base abilities. Fully extensible.
The ability to fully incorporate edit-and-continue at all stages
(I call it "LiveCode"), and the ability to have a known relationship
between a developer and the IDE environment it's being run in,
allowing for the new concept of an inquiry which suspends to the
debugger to ask what to do when something unexpected happens,
rather than just stopping with an error.
 
May the Lord guide me forward on this project. May I give Him my
best, so that all of you can benefit from my labor.
 
Thank you,
Rick C. Hodgin
 
-----
As a reminder, CAlive is a language design for a C-like language that
adds the basic class and exception handling. It's built inside the
RDC framework, which is something like a base set of abilities driven
by a database that allows compilers to be written within it.
 
RDC exposes a core set of necessary processing abilities that a
language needs to parse command line options, read in data files,
and translate raw source code through a series of stages ultimately
into binary code.
 
The CAlive language is essentially just a database plugged in to
RDC which guides its operation during compilation. As such, there
is no true CAlive compiler as a native, stand-alone thing. It is
only using RDC with a CAlive database enabling it to compile CAlive
source code. And similarly, other databases can be created which
guide RDC to compile other source code.
 
From the user's perspective, CAlive will be of the traditional form:
 
calive myfile.ca
 
This will invoke the RDC framework via the calive.exe program which
contains its own database. It loads RDC and passes the database to
it. RDC reads the database and basically takes over processing from
that point forward. It parses the command line, loads any data files
that are indicated, and begins the steps within the database which
instruct it to process code through line-by-line, section-by-section
from source code, through to object code, with a linker ability for
multiple target forms, though the stages involved are entirely free-
flow, dependent upon what the database guides it toward.
 
RDC will also be able to natively intermix languages from a single
source file when their databases are present (when the indicated
languages have been coded and designed). It will work like this:
 
// By default, the compiler uses whatever language it was
// invoked with. For calive.exe, it will use CAlive code.
// To use other libraries, use a form with _ and then the
// language name. Languages used can also be nested as
// needed.
 
_lisp {
// Lisp code here
}
 
_fortran {
// Fortran code here
}
 
_java {
// Java code here
}
 
The code within each block is compiled by the appropriate language
database, and since RDC resolves everything down to fundamental data
types internally, data exchange between languages will be possible
at all points.
-----[ End ]-----
 
Somebody stated that targeting an obsolete 32-bit architecture
didn't seem to make much sense. My reply speaks of part of the
long-term plan I have for this project. I'm not just creating
a new programming language or new compiler framework, but it is
a desire to create an entire hardware and software stack devoted
to the Lord, meaning we acknowledge Him as the source of our
skills and abilities, and we acknowledge Him as the head and Lord
of our lives, and we then reach out to other people teaching them
the same thing He first taught us, that His love in giving is for
us to do for others when we have the opportunity:
 
-----[ Begin ]-----
I am creating a new hardware architecture called Arxoda. It's based
on the 80386 design extended out to 40-bits, but with a much larger
register set. It employs something I call a WEX (Window register
extensions).
 
WEX indicates which set of base 80386 register encodings are used
in conjunction with the WEX setting to access that register group
within the larger register set to process data:
 
 
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/core/wex_register_mapping.png
 
 
The overall architecture design is here:
 
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/core
 
I also have a simplified Arxoda design I call Arxita, which I'll
design and implement first. It is basically a 5-stage pipeline
80386, based on my original Oppie-2 design, using the same opera-
tional environment, but without protected mode, paging, and no 16-
bit support. It will introduce a simplified floating point engine,
and basically be a 32-bit protected mode core that uses a different
opcode encoding with some new instructions that will ultimately be
found in Arxoda:
 
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxita
 
-----
My goals are not just 32-bit 80386, but are in progress toward usable
code in today's operating systems on today's processors, purposeful
code toward my own operating system running on Arxita, with the final
goal being running native code on my own 40-bit Arxoda CPU, with a
full hardware and software stack given over to God, lifting (meaning
acknowledging) Him in the design, and then giving it out to mankind
for general use.
 
My goals are to honor God with the skills He's given me, and to give
the people around me real tools they can take, alter, extend, adding
their own special and unique abilities atop.
-----[ End ]-----
 
Someone else replied that I was using a C++ compiler to compile my
CAlive code, and that it didn't make sense for me to post about it
in a C group. I replied that CAlive is basically C with the basic
class added, and exceptions, and some new things. I also indicated
that I eventually intend to have a fully compliant C90 and C99
implementation that CAlive will be able to compile with.
 
-----[ Begin ]-----
CAlive is being written in a form that CAlive will later natively
compile itself. It is my goal to have CAlive bootstrap itself.
 
CAlive is beyond C, so I have no choice but to compile it in a C++
compiler, but even so I don't use much C++. In fact, I use almost
none of it right now except tighter type checking and relaxes syntax
allowances.
 
CAlive will eventually support a 100% native implementation of C90
and C99 with -c90 and -c99 switches, and I may simply create a C90
and C99 database which doesn't require the switches, and allows for
_c90 and _c99 blocks to be used within.
 
Providing that support is not my first goal, but everything about
the design is being coded with that end goal in mind. My current
target timeframe for supporting those features in around 2021.
-----[ End ]-----
 
Somebody else replied that it makes no sense for me to need a C++
compiler to compile CAlive, because if CAlive is less than C++,
then by definition C++ is greater than CAlive because it contains
the full subset of its abilities.
 
While that is not true because CAlive adds many new things I have
not seen in any other language, even the C/C++ components it does
have are not the issue.
 
My goal with CAlive is to eventually have it boostrap itself, so
I am writing code that is close to C with some C++ extensions.
In addition, the framework I'm writing the compiler in (called RDC)
is of such a design that all of the LibSF languages created in RDC
will be able to have a certain range of debugging abilities that
make it desirable for developers. In fact, my goal is to have the
best developer and debugger environment of any language, and to do
so at the C/C++ level, though with RDC it will be down to anything
that can be compiled into machine code level, including assembly.
 
-----[ Begin ]-----
Everyone can use C++. Nobody has to use CAlive. You are free to
compare them side-by-side and choose the compiler you want. You're
free to not even consider CAlive for anything. Nobody's forcing you
to use it or consider it. However, it will be (James 4:15 "Lord
willing") be a tool available to you at some point.
 
Per my vision: For performance and speed, you'll want a more mature
compiler (at least in the beginning). But for ease of development,
you will not find a faster development system than RDC, and subsequently
CAlive and other languages being written in RDC. In fact, if you have
the right developer code installed, you'll even be able to tweak the
compiler while you're compiling a program program, to literally step
through the compilation process and find out where it's failing and fix
the error, or to rewrite your code when you see why it's being
interpreted that way. You can also add new features on-the-fly, test
them in the debugger, be able to debug both the source code to be
compiled, and the way in which they are compiled.
-----[ End ]-----
 
My goals with CAlive are to honor God with the skills He first gave
me, and to give you a powerful tool for software development. I
would welcome your help in moving forward in this way. Please feel
free to contact me if you are interested.
 
The CAlive Google Group:
https://groups.google.com/forum/#!forum/caliveprogramminglanguage
 
Thank you,
Rick C. Hodgin
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 20 08:39AM +0200

On 9/19/2017 9:54 PM, Scott Lurndal wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>> my answer in stl/ref thread didn't show up, so, testing (sorry).
 
> propagation delay is inherent in Usenet.
 
Yes, thank you for that observation, so that people don't post test
messages like this needlessly.
 
In this case articles posted via Eternal September showed up in Google
Groups but not in the feed from Eternal September, which can not be
explained via propagation delay. Evidently there was some problem with
the E.S. servers, because the feedback option over there failed via
timeout. I mailed the contact there and now it's OK.
 
:)
 
- Alf
scott@slp53.sl.home (Scott Lurndal): Sep 20 12:32PM

>explained via propagation delay. Evidently there was some problem with
>the E.S. servers, because the feedback option over there failed via
>timeout. I mailed the contact there and now it's OK.
 
Most news server-side software is split into two pieces - one
that handles posts & propagation and one that handles reading. The
two aren't necessarily in sync, the reader side also needs to wait
for propagation from the posting side (which sends to all peers).
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 20 08:44AM -0400

On 9/19/2017 2:35 PM, Alf P. Steinbach wrote:
> my answer in stl/ref thread didn't show up, so, testing (sorry).
 
If you're using eternal september, they have periodic issues.
 
Double-check with Google Groups if something seems odd.
 
Thank you,
Rick C. Hodgin
woodbrian77@gmail.com: Sep 19 06:43PM -0700

> code here:
> https://github.com/Ebenezer-group/onwards
 
> are open source.
 
I want to make a correction to that: Some of the code
generated by the C++ Middleware Writer is open source.
Users decide whether to make it closed or open source.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
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)