Tuesday, March 14, 2017

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

Real Troll <real.troll@trolls.com>: Mar 14 05:40PM -0400

<https://blogs.msdn.microsoft.com/dotnet/2017/03/09/new-features-in-c-7-0/>
Mike Copeland <mrc2323@cox.net>: Mar 14 02:05PM -0700

Is there a way to "prepend" objects into a std::vector? That is, I'd
like to "push_front" instead of "push_back".
In the code below, I parse a CSV line with an unknown number of
fields. I want to normalize the number of objects in the target vector,
to assure it has 3 objects. Each "fill" object will have a value of
"0". For example>
 
std::vector<string> parseArray;
{ parse CSV line }
while(parseArray.size() < 3) { prepend "0" object }
 
Perhaps there's another container which will work: any thoughts? TIA
 
 
 
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 14 10:23PM +0100

On 14-Mar-17 10:05 PM, Mike Copeland wrote:
> { parse CSV line }
> while(parseArray.size() < 3) { prepend "0" object }
 
> Perhaps there's another container which will work: any thoughts? TIA
 
Along the lines of
 
int const n_fill_objects = 3 - (int)parseArray.size();
if( n_fill_objects > 0 )
{
vector<string> fillers( n_fill_objects, "0" );
parseArray.insert( parseArray.begin(), fillers.begin(),
fillers.end() );
}
 
There are various ways to optimize this depending on the typical data
you have.
 
But probably it doesn't need any optimization.
 
---
 
For documentation, see
 
<url: http://en.cppreference.com/w/cpp/container/vector/insert>
 
 
Cheers & hth.,
 
- Alf
Paavo Helde <myfirstname@osa.pri.ee>: Mar 14 11:36PM +0200

On 14.03.2017 23:05, Mike Copeland wrote:
 
> std::vector<string> parseArray;
> { parse CSV line }
> while(parseArray.size() < 3) { prepend "0" object }
 
while (parseArray.size() < 3) {
parseArray.insert(parseArray.begin(), "0");
}
 
(Note: this is kosher only for small values of 3 ;-)
Ramine <toto@toto.net>: Mar 14 04:49PM -0400

Hello.....
 
About the Ticket Spinlock with a proportional back-off
 
I have just ported my Ticket Spinlock with a proportional back-off
that i have enhanced to On Time RTOS-32 real-time OS , and let me tell
you that it is efficient, because it really scale better and it reduces
better the cache-coherence traffic and it really reduces efficiently the
waiting time for the lock to be available.. that's really good.
 
 
Thank you,
Amine Moulay Ramdane.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 14 08:45PM +0100

I received this:
 
 
> Thank you for using Microsoft Connect!
 
> Regards,
 
> the Microsoft Connect Team
 
At first I wondered where the Report-a-Problem tool this mail is talking
about, was in Visual Studio; I couldn't find it.
 
But I finally did, and could see that my bug report had not been
migrated: it was not in the list of internal compiler errors.
 
Using the link to my original report so thoughtfully provided by
Microsoft, with a view towards copying it over to the new bug database,
I found that I had to LOG IN in order to see it. That indicates that
others can't see it either, without logging in. How's that for
transparency and open discussion.
 
This smells like old Microsoft where it was just plain impossible to
report a bug unless you were a paying MSDN member or an MVP. I've been
both, plus of course working for Microsoft-oriented companies, so I know
how it was when it worked. But for the regular jack, which I've also
been, you were sent on a wild goose chase down a labyrinth of forms, and
when you finally had managed to find the right one and had filled in its
inane fields, and clicked Submit, you were greeted by an error page. In
defense of Microsoft, Google has also used that approach, so it's not
like Microsoft is a worst among companies. It's just that at the time,
and apparently now again, they're not very good.
 
How can you say this is a buggy product? Look, we have far fewer bug
reports than with any other product! - Well, my take it on it: after
downloading VS 2017, and opening the first project, and asking it to
build, it crashed. That's the very /first/ thing it did. Crash. The bug
report in question is about an umpteenth' crash after that. Just that
this particular crash was easily reproduced and hence, I reported it.
 
 
Hope this helps someone,
 
- Alf
Ramine <toto@toto.net>: Mar 14 03:39PM -0400

Hello,
 
 
About real-time coding for real-time systems...
 
I am a white arab, and i am a computer programmer and i have a diploma
in Microelectronics and informatics and i have also studied and
succeeded one year of mathematics at university level, and i am
an experienced programmer in parallel programming and synchronization
algorithms and i have invented many synchronization algorithms.
 
You know that real-time coding for real-time systems must be taken
with care, so i have decided that i will bring the following to
do real-time coding:
 
1- A Ticket Spinlock with a proportional back-off for real-time systems
 
2- A thread-safe FIFO queue and a FIFO queue for real-time systems
 
3- A thread-safe LIFO Stack and a LIFO Stack for real-time systems
 
4- A Threadpool for real-time systems.
 
 
And as you have noticed i have already brought to you my C++ and Delphi
MemPool for real-time systems, here they are:
 
https://sites.google.com/site/aminer68/c-mempool-for-real-time-systems
 
and
 
https://sites.google.com/site/aminer68/mempool-for-realtime-systems
 
 
The above will be implemented for QNX and for On Time RTOS-32 real-time
OSs and i will implement them with C++ and Delphi(Object Pascal)
 
 
Thank you,
Amine Moulay Ramdane.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 14 08:06AM -0700

On Monday, March 13, 2017 at 11:21:58 PM UTC-4, Rick C. Hodgin wrote:
> }
 
> // No longer static, runs with a proper context from here down
> }
 
Within this context, provided you weren't calling a virtual function,
this would be legal:
 
void myFunction(void)
{
xyz* x = NULL;
 
x->abc(5, 0, 0);
}
 
The symbol x would identify the class, which then called its known
static location in source code with itself as a parameter. If it's
NULL, then it would enter the static block and could be established
there.
 
The only reason you'd need x is for the members. Or, in the case
of a virtual function, for the explicit vtable lookup. But it's
even arguable in those cases that you wouldn't need it, because
you could use the type to reference a global virtual member
function address table, which then still references the correct
target with a NULL parameter, allowing the static {..} block to
be entered, where the correct this context is established.
 
The compiler would not be aware of potential run-time errors, but
the developer would. So long as all of the discrimination was
handled properly, it would not be in error in any case. And where
it was, it would signal a runtime fault (in C++, or an inquiry in
CAlive).
 
-----
I don't see any issues with this change in design (in terms of
working correct, though I realize it would change established
practices and protocols in C++ software development).
 
Do you?
 
Thank you,
Rick C. Hodgin
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 14 04:10PM +0100

On 14-Mar-17 4:06 PM, Rick C. Hodgin wrote:
 
[snip]
>> }
 
>> // No longer static, runs with a proper context from here down
>> }
 
[snip]
> working correct, though I realize it would change established
> practices and protocols in C++ software development).
 
> Do you?
 
What are some examples where this scheme has some advantage?
 
 
Cheers!
 
- Alf
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 14 08:42AM -0700

On Tuesday, March 14, 2017 at 11:10:24 AM UTC-4, Alf P. Steinbach wrote:
> > practices and protocols in C++ software development).
 
> > Do you?
 
> What are some examples where this scheme has some advantage?
 
I gave two above (callbacks from OS services which derive the
specific instance based on information passed as parameters in
the callback).
 
I see the straight-forward redefinition of the this member to be
flexible, assignable. I see the static {..} block as being a very
positive feature (as CAlive also adds angel classes which are
short-duration classes which instantiate and de-instantiate auto-
matically in context, and could be used to support dynamic features
on static calls when no instance could be identified).
 
I see the ability to make dynamic and static functions essentially
the same for all internal function calls, more closely mimicking
what is actually seen in the physical ABI.
 
It makes everything more solid in the system, which reflects more
accurately what it really is in terms of the underlying mechanics,
(classes are logical constructs relating to physical implementations),
but it also makes it more flexible because things like an on-the-fly
change of the this member would be possible:
 
xyz* p1 = new xyz(15); // Create with a value of 15
xyz* p2 = new xyz(10); // Create with a value of 10
 
p1->some_function(p2);
 
void xyz::some_function(xyz* p2)
{
if (p2->value < value)
this = p2;
 
// Now, the entire reference to this instance is the min
// of the two parameters, without having to assign to a
// separate function pointer and then being required to
// use that on every reference.
}
 
-----
The only issue I see would be in legacy code interfaces. The missing
parameter on static callbacks from pre-existing functions that are
not aware they're calling a class member function statically, those
would need fixups.
 
In those legacy cases, the compiler could auto-create a marshalling
function which handles adding the extra parameter until the API
designer can create a version which auto-adds the extra NULL
parameter for the class member function static callback.
 
Add the keyword "static":
 
CreateThread(..., static &threadHandler, ...);
^^^^^^
In those legacy cases, the compiler would then auto-inject the marshal
function which is the OS API callback target, which then directs to
the correct function with the expected parameter.
 
In future releases, the OS API would be updated and we'd use the new
function static class callback function, which is called directly:
 
CreateThreadSC(..., &threadHandler, ...);
 
The new function would acknowledge its callback is a static class,
and would auto-inject the extra NULL parameter for the class instance
of the static callback. This would then signal code to enter the
static {..} block to derive the runtime context.
 
Thank you,
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 14 05:01PM

On 14/03/2017 04:07, Ian Collins wrote:
> {
> static_cast<X*>(nullptr)->f();
> }
 
I thought there was a general consensus within the group to not reply to
the fucktard Hodgin's C++ related posts until he promises to stop
spamming the group with his bullshit religious posts?
 
/Flibble
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 14 10:35AM -0700

On Tuesday, March 14, 2017 at 1:01:10 PM UTC-4, Mr Flibble wrote:
> I thought there was a general consensus within the group to not reply
> to the .. Hodgin's C++ related posts until he promises to stop
> spamming the group with his .. religious posts?
 
Not everyone's so petty and childish, Leigh. Which of these "honorable
men" would you be most like?
 
Star Trek TNG -- Worf receiving discommendation
https://www.youtube.com/watch?v=5c2etjMl3WM
 
Thank you,
Rick C. Hodgin
Bonita Montero <Bonita.Montero@gmail.com>: Mar 14 04:13PM +0100

> One sentence with 16 lines.
> I am impressed. Is that how you write your code, too?
 
Ramine is manic.
 
--
http://facebook.com/bonita.montero/
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 14 04:06PM +0100

On 14-Mar-17 3:46 PM, Alf P. Steinbach wrote:
> after move.
> {} // (which is why it can't use fast
> `realloc`)
 
The first is correct but the second, the "which is why", was typed
automatically by my fingers, without consulting me!
 
The `realloc` problem is more subtle.
 
 
Cheers!,
 
- 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)