Saturday, March 5, 2016

Digest for comp.lang.c++@googlegroups.com - 25 updates in 9 topics

Paavo Helde <myfirstname@osa.pri.ee>: Feb 28 06:53PM +0200

On 28.02.2016 15:27, JiiPee wrote:
> We all know the vector class does not have a function to delete extra
> memory from the vector.
 
You mean shrink_to_fit() is not guaranteed to work? I bet when it does
not then it has good reasons not to.
 
> So my first question is that why is it not
> there? :) Is there a good reason, as I think its many times needed.
 
For example? It most probably means an extra copy of the whole array for
no obvious benefit.
 
If one is working in tight environment where every byte is counted, then
one does not over-allocate arrays in the first place, so there will be
no need to shrink them. Instead, one would use e.g. reserve() to
allocate the correct amount beforehand.
 
> a move:
> vector<int> temp(a);
> a = std::move(temp);
 
That's basically just as good. The swap idiom just predates the C++11
move. And if you have C++11 then you will have shrink_to_fit() which
most probably does the same in a more direct way, so there is no need to
use move.
 
 
> becouse move will now make sure a is excatcly temp. Why we would like to
> copy stuff from a to temp (with swap) bce temp is not needed anyway ...
> kind of extra work? What is the reason behind swap here?
 
Swap was a workaround to *avoid* extra copy and extra work in pre-C+11
when there was no move.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 28 09:32PM +0100

On 28.02.2016 19:32, Juha Nieminen wrote:
>> there? :) Is there a good reason, as I think its many times needed.
 
> std::vector::shrink_to_fit() does exactly that, if the underlying
> memory management system supports reducing the size of an alloction.
 
No no.
 
shrink_to_fit can and will in general allocate a new buffer, when the
original capacity is way too large.
 
 
> (If the underlying memory management system does not support it, which
> is sometimes the case, then that function does nothing.)
 
No no.
 
 
> all systems support resizing of allocated blocks of memory (either
> larger or smaller). The only way was/is to allocate a new block and
> copy all the values there.
 
Yes, I agree. :)
 
 
Cheers!,
 
- Alf
David Brown <david.brown@hesbynett.no>: Feb 27 02:41PM +0100

On 27/02/16 05:19, Alf P. Steinbach wrote:
 
>> Hell, how about we get modules deployed and widely used?
 
> Good ideas all, I agree.
 
> And there is already experimental support for modules in Visual C++.
 
Unfortunately, I think they are significantly different from the
experimental modules in clang. I wish they would get this one sorted
out, so that we can have a single proper module feature for C++.
Dombo <dombo@disposable.invalid>: Feb 27 07:41PM +0100

Op 27-Feb-16 om 5:19 schreef Alf P. Steinbach:
>> from various perspectives including, but not limited to, freely
>> available, actively improved, proven viability in the marketplace and portable among
>> platforms.
 
Unfortunately those user interface kits are showing their age; they
don't take advantage of modern C++ features but instead choose to supply
their own string, container...etc classes and mechanisms. All of this
was understandable in the nineties before C++ was standardized but is
unforgivable in this day and age.
 
It would be nice to have a multi platform widely used GUI toolkit that
takes advantage of modern C++ and that smoothly interfaces with the
standard library.
 
[snip]
>> C# doesn't have it.
 
> C# is like NodeJS, just too many GUI toolkits now. But the main basic C#
> GUI stuff is Windows Forms. I believe Mono has Windows Forms support?
 
Development of WinForms has stopped well over a decade ago, nowadays WPF
is pretty much the way to go. Besides those two I don't know of any
other widely used GUI toolkit in the .NET world.
Juha Nieminen <nospam@thanks.invalid>: Feb 28 06:26PM

> Why people are insistent on trying to jam every possible library into
> the standard is beyond me.
 
That got me thinking: There are many things that do not really belong
into the C++ standard, but are nevertheless things that would be very
useful and people often request.
 
Perhaps a kind of compromise could work: A "secondary" specification
defined by the standard committee, of optional libraries. In other words,
libraries that a standard-conforming compiler is not forced to implement,
but if it does, then it has to implement it as specified (so that all
programs written to use said library will compile and work).
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
alexo <alelvb@inwind.it>: Feb 27 01:42PM +0100

> Where does it fail?
> How does it fail?
> What's it doing at the time?
 
 
The debugger doesn't stops on error. There is not a segfault or similar.
My program simply continues to send data and "hangs".
If I close it with xkill data transmission doesn't end.
alexo <alelvb@inwind.it>: Feb 27 01:38PM +0100

> Where does it fail?
> How does it fail?
> What's it doing at the time?
 
 
The debugger doesn' stops on error. There is not a segfault or similar.
My program simply continues to send data and "hangs".
If I close it with xkill transmission doesn't end. It continues to keep
data transfer to I don't know who.
alexo <alelvb@inwind.it>: Feb 27 07:14PM +0100

Il 27/02/2016 13:42, alexo ha scritto:
 
>> Have you made attempts at debugging?
 
yes
 
>> Where does it fail?
 
on the line that starts data transmission namely,
 
res = curl_easy_perform(curl);
 
>> How does it fail?
 
transmission starts and never ends. Even force closing of the program
wireless activity doesn't stop and always stays on, locking internet
communication.
 
 
 
 
 
code of the toy program follows:
in order to make it working you must fill in your username, password and
smtp server address for the outgoing mails.
 
 
here in the code:
 
curl_easy_setopt(curl, CURLOPT_USERNAME, " ");
curl_easy_setopt(curl, CURLOPT_PASSWORD, " ");
curl_easy_setopt(curl, CURLOPT_URL, " ");
 
 
 
/***************************************************************************
* _ _ ____ _
* Project ___| | | | _ \| |
* / __| | | | |_) | |
* | (__| |_| | _ <| |___
* \___|\___/|_| \_\_____|
*
* Copyright (C) 1998 - 2016, Daniel Stenberg, <daniel@haxx.se>, et al.
*
* This software is licensed as described in the file COPYING, which
* you should have received as part of this distribution. The terms
* are also available at https://curl.haxx.se/docs/copyright.html.
*
* You may opt to use, copy, modify, merge, publish, distribute and/or sell
* copies of the Software, and permit persons to whom the Software is
* furnished to do so, under the terms of the COPYING file.
*
* This software is distributed on an "AS IS" basis, WITHOUT WARRANTY
OF ANY
* KIND, either express or implied.
*
 
***************************************************************************/
 
/* <DESC>
* SMTP example showing how to send e-mails
* </DESC>
*/
 
#include <stdio.h>
#include <string.h>
 
#include <time.h>
#include <cstdlib>
 
#include <curl/curl.h>
 
/* This is a simple example showing how to send mail using libcurl's SMTP
* capabilities. For an example of using the multi interface please see
* smtp-multi.c.
*
* Note that this example requires libcurl 7.20.0 or above.
*/
 
#define FROM "<alelvb@inwind.it>"
#define TO "<alessandro.volturno@libero.it>"
//#define CC "<alelvb@inwind.it>"
 
char *current_date();
 
char *date = current_date();
 
static const char *payload_text[] = {
"To: " TO "\r\n",
"From: " /*FROM*/ "Stilottica\r\n",
//"Cc: " CC "Another example User\r\n",
"Subject: ordine lenti\r\n", // subject of tha message
"\r\n", /* empty line to divide headers from body, see RFC5322 */
"Ordine del ", //The body of the message starts here.
// more strings go here
date,
"\r\nA long text email can be very tedious to read."
"\r\n-- end of the message --",
NULL
};
 
struct upload_status {
int lines_read;
};
 
static size_t payload_source(void *ptr, size_t size, size_t nmemb, void
*userp)
{
struct upload_status *upload_ctx = (struct upload_status *)userp;
const char *data;
 
if((size == 0) || (nmemb == 0) || ((size*nmemb) < 1)) {
return 0;
}
 
data = payload_text[upload_ctx->lines_read];
 
if(data) {
size_t len = strlen(data);
memcpy(ptr, data, len);
upload_ctx->lines_read++;
 
return len;
}
 
return 0;
}
 
int main(void)
{
CURL *curl;
CURLcode res = CURLE_OK;
struct curl_slist *recipients = NULL;
struct upload_status upload_ctx;
 
upload_ctx.lines_read = 0;
 
curl = curl_easy_init();
 
if(curl) {
/* This is the URL for your mailserver */
curl_easy_setopt(curl, CURLOPT_USERNAME, " ");
curl_easy_setopt(curl, CURLOPT_PASSWORD, " ");
curl_easy_setopt(curl, CURLOPT_URL, " ");
 
 
/* Note that this option isn't strictly required, omitting it will
result
* in libcurl sending the MAIL FROM command with empty sender data. All
* autoresponses should have an empty reverse-path, and should be
directed
* to the address in the reverse-path which triggered them. Otherwise,
* they could cause an endless loop. See RFC 5321 Section 4.5.5 for
more
* details.
*/
curl_easy_setopt(curl, CURLOPT_MAIL_FROM, FROM);
 
/* Add two recipients, in this particular case they correspond to the
* To: and Cc: addressees in the header, but they could be any kind of
* recipient. */
recipients = curl_slist_append(recipients, TO);
//recipients = curl_slist_append(recipients, CC);
curl_easy_setopt(curl, CURLOPT_MAIL_RCPT, recipients);
 
/* We're using a callback function to specify the payload (the
headers and
* body of the message). You could just use the CURLOPT_READDATA
option to
* specify a FILE pointer to read from. */
curl_easy_setopt(curl, CURLOPT_READFUNCTION, payload_source);
curl_easy_setopt(curl, CURLOPT_READDATA, &upload_ctx);
curl_easy_setopt(curl, CURLOPT_UPLOAD, 1L);
 
/* Send the message */
res = curl_easy_perform(curl);
 
/* Check for errors */
 
if(res != CURLE_OK)
{
fprintf(stderr, "curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));
}
else
{
printf("message sent!");
}
 
/* Free the list of recipients */
curl_slist_free_all(recipients);
 
/* curl won't send the QUIT command until you call cleanup, so you
should
* be able to re-use this connection for additional messages (setting
* CURLOPT_MAIL_FROM and CURLOPT_MAIL_RCPT as required, and calling
* curl_easy_perform() again. It may not be a good idea to keep the
* connection open for a very long time though (more than a few minutes
* may result in the server timing out the connection), and you do
want to
* clean up in the end.
*/
curl_easy_cleanup(curl);
}
 
return (int)res;
}
 
char *current_date()
{
time_t rawtime;
struct tm *timeinfo = NULL;
 
char *buf = new char[35];
 
if(buf == NULL)
{
printf("string allocation error\n");
exit(1);
}
 
time(&rawtime);
 
if ((timeinfo = localtime(&rawtime)) == NULL)
{
printf("data generation error");
exit(1);
}
 
sprintf(buf,"%.2d/%.2d/%4d ore %.2d:%.2d",
timeinfo->tm_mday,
1 + timeinfo->tm_mon,
1900 + timeinfo->tm_year,
timeinfo->tm_hour,
timeinfo->tm_min
);
 
return buf;
}
alexo <alelvb@inwind.it>: Feb 27 07:22PM +0100

Il 27/02/2016 19:14, alexo ha scritto:
 
> curl_easy_setopt(curl, CURLOPT_USERNAME, " ");
> curl_easy_setopt(curl, CURLOPT_PASSWORD, " ");
> curl_easy_setopt(curl, CURLOPT_URL, " ");
 
I forgot to specify that it is not the code here reported that fails,
but the same code when I insert it in a callback function to be called
on button pressing.
 
any help is welcome and appreciated
 
thank you
alexo <alelvb@inwind.it>: Feb 27 06:44PM +0100

>> As JiiPee suggested, I've found a very powerful library named curl.
>> The one he suggested, mimetic, has a bug.
 
> Namely?
 
after ./configure
make fails due to errors in the source files
Paavo Helde <myfirstname@osa.pri.ee>: Feb 27 09:46PM +0200

On 27.02.2016 19:59, alexo wrote:
 
> when I insert this code in my program,
> This code being called by pressing a button on the GUI transmission goes
> forever.
 
Obviously your two programs differ in some sense, as one is working as
expected and the other does not. Obviously you have made changes when
pasting the code to your real program (otherwise you would have two
main() functions which would not compile).
 
You have to figure out what is the crucial difference. And no, posting
the code for the *working* program is not very helpful. Instead, you
should extract the minimal *non-working* program from your real app.
 
According to your claims the program is sending infinite amount of data.
However, the data is provided by your own callback function
(payload_source()), so you could easily put a breakpoint there and find
out how much and what data it is sending.
alexo <alelvb@inwind.it>: Feb 27 06:59PM +0100

> How does it "hang"?
> Why does it "hang"?
> What's it doing at the time of "hanging"?
 
This is the source code of the toy program. It is executed correctly
but for the login you obviously have to type in your username password
and smtp server address.
 
when I insert this code in my program,
This code being called by pressing a button on the GUI transmission goes
forever.
the line that fails is this:
 
 
res = curl_easy_perform(curl);
 
 
It starts the transmission of the data and should return.
This is not what happens. The funclion locks the wireless transmission
and after closing the software with xkill, data transmission still
continues, but no mail starts.
 
 
/***************************************************************************
* _ _ ____ _
* Project ___| | | | _ \| |
* / __| | | | |_) | |
* | (__| |_| | _ <| |___
* \___|\___/|_| \_\_____|
*
* Copyright (C) 1998 - 2016, Daniel Stenberg, <daniel@haxx.se>, et al.
*
* This software is licensed as described in the file COPYING, which
* you should have received as part of this distribution. The terms
* are also available at https://curl.haxx.se/docs/copyright.html.
*
* You may opt to use, copy, modify, merge, publish, distribute and/or sell
* copies of the Software, and permit persons to whom the Software is
* furnished to do so, under the terms of the COPYING file.
*
* This software is distributed on an "AS IS" basis, WITHOUT WARRANTY
OF ANY
* KIND, either express or implied.
*

***************************************************************************/
 
/* <DESC>
* SMTP example showing how to send e-mails
* </DESC>
*/
 
#include <stdio.h>
#include <string.h>
 
#include <time.h>
#include <cstdlib>
 
#include <curl/curl.h>
 
/* This is a simple example showing how to send mail using libcurl's SMTP
* capabilities. For an example of using the multi interface please see
* smtp-multi.c.
*
* Note that this example requires libcurl 7.20.0 or above.
*/
 
#define FROM "<alelvb@inwind.it>"
#define TO "<alessandro.volturno@libero.it>"
//#define CC "<alelvb@inwind.it>"
 
char *current_date();
 
char *date = current_date();
 
static const char *payload_text[] = {
"To: " TO "\r\n",
"From: " /*FROM*/ "Stilottica\r\n",
//"Cc: " CC "Another example User\r\n",
"Subject: ordine lenti\r\n", // subject of tha message
"\r\n", /* empty line to divide headers from body, see RFC5322 */
"Ordine del ", //The body of the message starts here.
// more strings go here
date,
"\r\nA long text email can be very tedious to read."
"\r\n-- end of the message --",
NULL
};
 
struct upload_status {
int lines_read;
};
 
static size_t payload_source(void *ptr, size_t size, size_t nmemb, void
*userp)
{
struct upload_status *upload_ctx = (struct upload_status *)userp;
const char *data;
 
if((size == 0) || (nmemb == 0) || ((size*nmemb) < 1)) {
return 0;
}
 
data = payload_text[upload_ctx->lines_read];
 
if(data) {
size_t len = strlen(data);
memcpy(ptr, data, len);
upload_ctx->lines_read++;
 
return len;
}
 
return 0;
}
 
int main(void)
{
CURL *curl;
CURLcode res = CURLE_OK;
struct curl_slist *recipients = NULL;
struct upload_status upload_ctx;
 
upload_ctx.lines_read = 0;
 
curl = curl_easy_init();
 
/* replace xxx with your credentials */
 
if(curl) {
/* This is the URL for your mailserver */
curl_easy_setopt(curl, CURLOPT_USERNAME, "xxxxxxxxx@xxxxxx.xx"); //
curl_easy_setopt(curl, CURLOPT_PASSWORD, "xxxxxxxx");
curl_easy_setopt(curl, CURLOPT_URL, "xxxxxxxx");
 
 
/* Note that this option isn't strictly required, omitting it will
result
* in libcurl sending the MAIL FROM command with empty sender data. All
* autoresponses should have an empty reverse-path, and should be
directed
* to the address in the reverse-path which triggered them. Otherwise,
* they could cause an endless loop. See RFC 5321 Section 4.5.5 for
more
* details.
*/
curl_easy_setopt(curl, CURLOPT_MAIL_FROM, FROM);
 
/* Add two recipients, in this particular case they correspond to the
* To: and Cc: addressees in the header, but they could be any kind of
* recipient. */
recipients = curl_slist_append(recipients, TO);
//recipients = curl_slist_append(recipients, CC);
curl_easy_setopt(curl, CURLOPT_MAIL_RCPT, recipients);
 
/* We're using a callback function to specify the payload (the
headers and
* body of the message). You could just use the CURLOPT_READDATA
option to
* specify a FILE pointer to read from. */
curl_easy_setopt(curl, CURLOPT_READFUNCTION, payload_source);
curl_easy_setopt(curl, CURLOPT_READDATA, &upload_ctx);
curl_easy_setopt(curl, CURLOPT_UPLOAD, 1L);
 
/* Send the message */
res = curl_easy_perform(curl);
 
/* Check for errors */
 
if(res != CURLE_OK)
{
fprintf(stderr, "curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));
}
else
{
printf("message sent!");
}
 
/* Free the list of recipients */
curl_slist_free_all(recipients);
 
/* curl won't send the QUIT command until you call cleanup, so you
should
* be able to re-use this connection for additional messages (setting
* CURLOPT_MAIL_FROM and CURLOPT_MAIL_RCPT as required, and calling
* curl_easy_perform() again. It may not be a good idea to keep the
* connection open for a very long time though (more than a few minutes
* may result in the server timing out the connection), and you do
want to
* clean up in the end.
*/
curl_easy_cleanup(curl);
}
 
return (int)res;
}
 
char *current_date()
{
time_t rawtime;
struct tm *timeinfo = NULL;
 
char *buf = new char[35];
 
if(buf == NULL)
{
printf("string allocation error\n");
exit(1);
}
 
time(&rawtime);
 
if ((timeinfo = localtime(&rawtime)) == NULL)
{
printf("data generation error");
exit(1);
}
 
sprintf(buf,"%.2d/%.2d/%4d ore %.2d:%.2d",
timeinfo->tm_mday,
1 + timeinfo->tm_mon,
1900 + timeinfo->tm_year,
timeinfo->tm_hour,
timeinfo->tm_min
);
 
return buf;
}
David Brown <david.brown@hesbynett.no>: Feb 27 02:37PM +0100

On 27/02/16 09:58, Allan Herriman wrote:
>> where they changed the bitfield endianness.)
 
> It happened to me on an 8051 C compiler in the '90s. The endianness of
> bitfields changed between one compiler version and the next.
 
Thanks - now I know of /two/ cases where compilers have changed bit
ordering!
 
> I learned a lesson, and have not used bitfields in C since then.
 
You are throwing out the baby with the bathwater. If you avoid using a
feature just because a small-time compiler writer for a brain-dead and
C-unfriendly processor made an inconvenient decision two decades ago,
you would have to give up programming altogether. Bitfields have
portability issues, but can be extremely useful - they are perfectly
safe to use once you understand them.
 
David Brown <david.brown@hesbynett.no>: Feb 27 04:34PM +0100

On 27/02/16 16:21, 嘱 Tiib wrote:
> defective tools and libraries and platforms. Getting the work done
> with such is part of skill. Without desire to acquire that skill it
> is impossible to make software.
 
Changing the bitfield order between versions is not really a "defect" as
such - it's a design decision, not a bug. When MS did it (and I guess
they count as "big-time"), they moved to little-endian ordering because
it was much more common for other tools on the x86 and other
little-endian processors. So it was a good decision, but it came as a
surprise to people who had upgrade compiler versions and found their
code changed functionality.
 
But yes, even "big-time" compilers have bugs. Some, like gcc and clang,
are very open about them - some others prefer to keep them secret until
you open a support case (I don't mean to imply that all closed-source
compiler manufacturers keep their bugs secret, as that would be far from
true). It seems there is little relationship between the cost of tools
and their quality. Certainly the last compiler bugs I have seen have
been in very expensive, big-name tools for a brain-dead microcontroller.
Those bugs turned up on simple, clear code - nothing complicated or
bleeding-edge. (I would prefer not to name the tools as I have only
helped out another developer here, rather than studying the tool in detail.)
Jerry Stuckle <jstucklex@attglobal.net>: Feb 27 06:21PM -0500

On 2/27/2016 5:47 PM, Paavo Helde wrote:
 
> Except that it is not dead. Nowadays this is called Embarcadero
> C++Builder and the last release according to Wikipedia was on 31 Aug.
> 2015 (C++Builder 10 Seattle (23)).
 
C++ Builder is a derivative of Turbo C++, but it is not Turbo C++, nor
is it owned by Borland any longer. It has changed significantly since
Borland owned it.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Paavo Helde <myfirstname@osa.pri.ee>: Feb 28 01:33AM +0200

On 28.02.2016 1:21, Jerry Stuckle wrote:
 
> C++ Builder is a derivative of Turbo C++, but it is not Turbo C++, nor
> is it owned by Borland any longer. It has changed significantly since
> Borland owned it.
 
So... and which part of this means "eventual failure of [Turbo C++]"?
 
Of course it has evolved significantly over the years, and there have
been name changes and sell-offs (to shake off some alleged bad
reputation or not, I don't know), but as far as I can see there is no
"eventual failure".
ram@zedat.fu-berlin.de (Stefan Ram): Feb 27 08:24PM

>>Could this be expressed type safe in C++11, without the need to deal
>>with pointers, new and delete for each line?
>You can declare the array under the scope of a template, e.g.:
 
The code compiled, but I can't read out the actual values.
 
The code commented out in the program below results in
linker errors:
 
#include <initializer_list>
#include <iostream>
#include <ostream>
 
enum class my { A_ADD };
 
template< typename T >struct entry{ int tag; T arg; };
 
::std::ostream & operator<<( ::std::ostream & out, ::my const & v )
{ out << "This is a my value.";
/* if( v == ::my::A_ADD )out << "It is ::my::A_ADD."; */
return out; }
 
::std::ostream & operator<<( ::std::ostream & out, ::entry< ::my >const & v )
{ out << "This is an entry with my enum."; return out; }
 
::std::ostream & operator<<( ::std::ostream & out, ::entry< bool >const & v )
{ out << "This is an entry with a bool."; return out; }
 
template< typename T >const entry< T >array[] ={ { 0, ::my::A_ADD },{ 1, false }};
 
int main()
{ /* ::std::cout << array< ::my >[ 0 ].tag<< '\n'; */
::std::cout << array< ::my >[ 0 ].arg<< '\n'; }
ram@zedat.fu-berlin.de (Stefan Ram): Feb 27 07:36PM

>Could this be expressed type safe in C++11, without the need to deal
>with pointers, new and delete for each line?
 
You can declare the array under the scope of a template, e.g.:
 
#include <initializer_list>
#include <iostream>
#include <ostream>
 
enum class my { A_ADD };
 
template< typename P >struct entry{ P Arg; };
 
::std::ostream & operator<<( ::std::ostream & out, ::entry< ::my >const & v )
{ out << "This is an entry with my enum."; return out; }
 
::std::ostream & operator<<( ::std::ostream & out, ::entry< bool >const & v )
{ out << "This is an entry with a bool."; return out; }
 
template< typename P >const entry< P >array[] ={ { ::my::A_ADD },{ false }};
 
int main()
{ ::std::cout << array< ::my >[ 0 ]<< '\n';
::std::cout << array< bool >[ 1 ]<< '\n'; }
 
This is an entry with my enum.
This is an entry with a bool.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 27 09:58PM +0100

On 27.02.2016 19:55, Marcel Mueller wrote:
> upper limit, since this is similar to a union.
 
> Could this be expressed type safe in C++11, without the need to deal
> with pointers, new and delete for each line?
 
Easy-peasy.
 
struct Op_entry
{
char const* name;
std::function<void()> parser_func;
};
 
// ... later
Op_entry e{ "Blah!", [=](){ Parser::assembleADD( Inst::A_ADD ); } };
 
Hope I got all the braces matched.
 
Cheers & hth.,
 
- Alf
Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 27 07:55PM +0100

Let's have a dispatch table of an assembler.
 
 
/// Entry of the OP code lookup table, POD, compatible with binary_search().
/// @tparam L maximum length of Name.
template <size_t L>
struct opEntry
{ char Name[L]; ///< OP code name
void (Parser::*Func)(int);///< Parser function to call, receives the
agrument below.
int Arg; ///< Arbitrary argument to the parser function.
};
 
/// Map with opcode tokens, must be ordered.
const Parser::opEntry<8> Parser::opcodeMap[] =
{ {"add", &Parser::assembleADD, Inst::A_ADD }
, {"and", &Parser::assembleADD, Inst::A_AND }
, {"asr", &Parser::assembleADD, Inst::A_ASR }
, {"bpkt", &Parser::assembleSIG, Inst::S_BREAK }
, {"bra", &Parser::assembleBRANCH, false }
//...
};
 
 
Each parser function takes an (optional) argument. The type is fixed to
int in this example. But this is not safe. Mostly the type is some enum.
But each function takes another argument type, and of course, the third
argument in the table must match the argument type of the function.
 
For type safe operation it would be nice to have a type like
 
 
template <size_t L, typename P>
struct opEntry
{ char Name[L]; ///< OP code name
void (Parser::*Func)(P);///< Parser function to call, receives the
agrument below.
P Arg; ///< Arbitrary argument to the parser function.
};
 
 
But this does not work since each line of Parser::opcodeMap[] has
another type P in general and all of these structures must fit into the
same storage. Of course, there is only a solution when sizeof(P) has an
upper limit, since this is similar to a union.
 
Could this be expressed type safe in C++11, without the need to deal
with pointers, new and delete for each line?
 
 
Marcel
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 27 05:53PM

On Fri, 2016-02-26, Haddock wrote:
> wanted to ask whether anybody out there working in this domain could
> give me a hint what to work on to get more into C++. What I thought
> of was writing a parser to parse CSV files or XML.
 
Both are good exercises (except just /parsing/ is not useful in
itself), but are you sure that's close to what you'd do in that
domain?
 
> Write something that generates optimized C++ code to parse
> something. But I'm not sure whether that's something good.
 
Write code which generates C++ source code? Not that interesting,
IMHO, especially since TMP is so trendy.
 
> Any ideas greatly appreciated.
 
Investigate more. I don't know anyone in that domain and never worked
there, so I don't know what they focus on. Could be almost anything.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Juha Nieminen <nospam@thanks.invalid>: Mar 03 02:43PM

>>I believe that the major usage of C nowadays is embedded software such
 
> I thought the major use of C nowadays was on the linux kernel because
> linus got a stick up his ass about C++.
 
Yeah. His argument against using C and abhorring C++ is, essentially,
that C automatically leads to good and efficient code, while C++
automatically leads to very inefficient and problematic code.
Because reasons. (Also, he still seems to live in the early 90's
in terms of what he knows about C++.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Juha Nieminen <nospam@thanks.invalid>: Mar 03 02:40PM

> I believe that the major usage of C nowadays is embedded software such as EMS (engine management systems) where dynamic allocation of
> memory is strictly forbidden. C++ will probably never be used in such environments.
 
You seem to be implying that it's impossible to write a C++ program
without dynamic memory allocation.
 
Is there an *actual* reason why C++ is forbidden, rather than a
completely false made-up one?
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Stuart Redmann <DerTopper@web.de>: Mar 05 11:03AM +0100

Ian Collins wrote:
> library headers that don't require run time (especially dynamic
> allocation) support should be identified in the standard. One of these
> days I'll follow this up.
 
Nice to hear. I will follow your efforts with interest.
 
Regards,
Stuart
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 05 09:04AM +0100

On 04.03.2016 22:09, Ian Collins wrote:
 
> constexpr int checkRange( int n ) {
> (n < 1000) ? true : throw 0; return n; }
 
> constexpr int f( int n ) { checkRange( n ); return n; }
 
This may possibly compile as C++17, even, I don't know, C++14. But not
C++11. Can't have more than one non-declaration statement (a.k.a.
"command" in BCPL), and that one must be a return statement. In C++11.
 
So, for compiler compatibility, which is generally a Goood Idea, I'd
write e.g.
 
constexpr auto range_checked( int const n )
-> int
{ return (n < 1000? n : throw 0); }
 
 
Cheers & hth.,
 
- Alf
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)