Thursday, January 12, 2017

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

red floyd <dont.bother@its.invalid>: Jan 12 10:10AM -0800

On 1/11/2017 10:06 AM, Scott Lurndal wrote:
 
> pre-compiled headers (called a Module Interface Definition). One
> big source file defining all the modules, the public and private
> module interfaces, composite types and global variables.
 
Dude, you were at Burroughs (later Unisys)? I interviewed there
back in '84!!!
scott@slp53.sl.home (Scott Lurndal): Jan 12 06:13PM

>> module interfaces, composite types and global variables.
 
>Dude, you were at Burroughs (later Unisys)? I interviewed there
>back in '84!!!
 
Indeed. In the Pasadena MCP group working on Omega (what became MCP/VS 2.0);
started in '83.
red floyd <dont.bother@its.invalid>: Jan 12 10:15AM -0800

On 1/12/2017 10:13 AM, Scott Lurndal wrote:
>> back in '84!!!
 
> Indeed. In the Pasadena MCP group working on Omega (what became MCP/VS 2.0);
> started in '83.
 
No kidding? That's where I interviewed! As a side note, IIRC, SPRITE
looked a heck of a lot like Modula-2.
scott@slp53.sl.home (Scott Lurndal): Jan 12 06:22PM

>> started in '83.
 
>No kidding? That's where I interviewed! As a side note, IIRC, SPRITE
>looked a heck of a lot like Modula-2.
 
Yes, the language designers were influenced by Algol and Modula.
 
07963000$SET CONTENTS "PROC: show_known_ssps"
07964000% ---------------------------------------------------------
07965000% | |
07966000 show_known_ssps
07967000% | |
07968000% ---------------------------------------------------------
07969000
07970000PROC( ssp_time VALUE SSP_TIME );
07971000SHARES
07972000 CONST loader_storage, %108
07973000 CONST mcp_identification,
07974000 VAR message_storage,
07975000 CONST pointer_reference_table,
07976000 VAR queue_storage;
07977000
07978000CONST
07979000 no_firmware STRING (9) OF HEX = "080347000";
07980000
07981000VAR
07982000 base_ptr DAT_POINTER,
07983000 ch_ptr PTR TO CHANNEL_TABLE_ENTRY,
07984000 keyboard_message STRING (30) OF HEX :=
07985000
07986000% PROC # <n> - SSP ON CC/UU
07987000
07988000 "244" + "C7B" + "AF0" + "C60" + "387" + "087" + "800" + "000",
07989000
07990000 procno PACKED STRUC
07991000 CASE BOOLEAN
07992000 IS true:
07993000 as_int DINT1
07994000 OR false:
07995000 as_hex HEX2
07996000 ESAC
07997000 CURTS := [true, processor_number],
07998000 search_done BOOLEAN;
07999000
08000000
08001000
08002000 keyboard_message[8::2] := procno.as_hex;
08003000 base_ptr := ioat_ptrs.first_element;
08004000 search_done := false;
08005000
08006000 DO
08007000 FIND ioat_ptr OVER base_ptr..ioat_ptrs.last_element
08008000 INTO ioat_ptrs.base @
08009000 WHERE ioat_ptr@.primary_hardware_type = shared_system_processor
08010000 THEN
08011000 message_iosta := ioat_ptr @.device_status_number;
08012000 ch_ptr := ptr( channel_table_ptrs.base @
08013000 [ioat_ptr @.primary_channel_number] );
08014000
08014000
08015000 IF ^ch_ptr @.flags.good_firmware_file
08016000 THEN
08017000 keyboard_message[22::9] := no_firmware;
08018000 ELSE
08019000 keyboard_message[22::3] := fill_string( "0" );
08020000 FI;
08021000
08022000 kbout_mod.kbospr( keyboard_message );
08023000
08024000 IF load_flag = cold_start %108
08025000 THEN %108
08026000 q1.ioat_address_in_dat := ioat_ptr;
08027000 q1.virtual_opcode_variants := vop_ssp_set_time;
08028000 q1.copy_desc := mcp.copy_desc( system_initialization,
08029000 data_page );
08030000 mcp.move_repeat( mcp.offset_ptr( ssp_time ),
08031000 q1.relative_buffer_addresses );
08032000 q1.relative_buffer_end_addr +:= SSP_TIME.SIZE;
08033000 q1.mcp_generated_io := true;
08034000 q1.ignore_unrecovered_error := true;
08035000
08036000 io_mod.initiate_mcp_io; % Set the time
08037000
08038000 FI; %108
08039000 base_ptr := ptr_add( ioat_ptr, 1 );
08040000 ELSE
08041000 search_done := true;
08042000 DNIF;
08043000
08044000 OD UNTIL search_done;
08045000
08046000CORP;
 
constructs like the FIND statement were mapped to one of the search
instructions.
 
http://vseries.lurndal.org/doku.php?id=instructions:sea
http://vseries.lurndal.org/doku.php?id=instructions:slt
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 12 10:25AM -0800

On Tuesday, January 10, 2017 at 3:05:30 PM UTC-5, Lynn McGuire wrote:
> "Visual C++ - Microsoft Pushes C++ into the Future"
> https://msdn.microsoft.com/en-us/magazine/mt694085.aspx
 
I remember when Visual Studio 98 came out. I was mostly a DOS user
back then. I used Windows 3.x and later, but for most of my development
I was using The SemWare Editor, DOS 6.22, and Microsoft MASM 6.11d, and
Microsoft C++ 6.1.
 
When I began looking at Visual Studio 98 I was still thinking of the
standard development model: code, compile, link, test, exit, back to
code, compile again, link again, test again, repeat.
 
But, one day I accidentally made a change to source code in the debug
window and pressed F10 to single-step continue. It said "Applying
changes..." and then single-stepped.
 
I sat there ... with my jaw hanging open. I didn't know what had just
happened. I said out loud, "What?" And then I began to try it again
and I realized what it was doing.
 
And that was when I was introduced to what has since become my most
valuable debugging tool. I hold edit-and-continue to be the absolute
highest possible tool a person can possess (beyond the common/standard
debugging abilities like watch, inspect memory, break, step, manually
change variables, etc.).
 
Visual Studio is my tool of choice for development SOLELY for that
reason. And when I get CAlive completed, it will have a very robust
version of that feature.
 
I wanted to share this because Visual Studio often times gets a bad
rap. I do not advise anyone using any Visual Studios between 2010
and 2015, as Microsoft really went off track for a while. 2015
brought them mostly back, and 2017 looks to be similar (though I
have not done much with it yet as it's still clunky in RC state).
 
Visual Studio is a very powerful tool. It can increase your
productivity so much. And if you get a Windows VM running in a
Linux environment, you can use VS in the Windows VM with a network
drive mapped to your Linux partition, and you're able to develop
your Linux apps using Visual Studio, flip to the terminal window
and compile and run. And with Visual Studio 2015's code analyzer
feature, it will find a lot more bugs that have never shown up
in your code.
 
A very powerful tool.
 
Best regards,
Rick C. Hodgin
scott@slp53.sl.home (Scott Lurndal): Jan 12 06:29PM

>feature, it will find a lot more bugs that have never shown up
>in your code.
 
>A very powerful tool.
 
There are a dozen native IDE's available for linux with all the
same features as VS. But none of them are as useful than VIM+Make+GDB.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 12 10:51AM -0800

On Thursday, January 12, 2017 at 1:29:46 PM UTC-5, Scott Lurndal wrote:
 
> >A very powerful tool.
 
> There are a dozen native IDE's available for linux with all the
> same features as VS. But none of them are as useful than VIM+Make+GDB.
 
That, my friend, is a viscous rumor stared by aliens.
 
Best regards,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 12 10:55AM -0800

On Thursday, January 12, 2017 at 1:29:46 PM UTC-5, Scott Lurndal wrote:
 
> >A very powerful tool.
 
> There are a dozen native IDE's available for linux with all the
> same features as VS. But none of them are as useful than VIM+Make+GDB.
 
Actually, I've never found one. The closest I've found is Sun Studio
for Solaris. But since Oracle is closing up all the sources, it's not
a viable target any longer.
 
Show me a Linux-based toolkit that has edit-and-continue and the same
type of refactoring abilities Visual Studio has with some of the
plugins / extensions available and I'll try it.
 
Best regards,
Rick C. Hodgin
Ian Collins <ian-news@hotmail.com>: Jan 13 08:21AM +1300

On 01/13/17 07:29 AM, Scott Lurndal wrote:
 
>> A very powerful tool.
 
> There are a dozen native IDE's available for linux with all the
> same features as VS.
 
Oh I wish there were... Then I could convince the bulk of my current
team to migrate off Windows.
 
> But none of them are as useful than VIM+Make+GDB.
 
Spoken like a true Luddite!
 
--
Ian
Cholo Lennon <chololennon@hotmail.com>: Jan 12 04:45PM -0300

On 01/12/2017 03:29 PM, Scott Lurndal wrote:
 
>> A very powerful tool.
 
> There are a dozen native IDE's available for linux with all the
> same features as VS. But none of them are as useful than VIM+Make+GDB.
 
Well, AFAIK nobody has the awesome "edit and continue" feature except VS
(which IMHO has the best debugger out there).
 
 
--
Cholo Lennon
Bs.As.
ARG
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 12 11:55AM -0800

On Thursday, January 12, 2017 at 2:45:48 PM UTC-5, Cholo Lennon wrote:
> > same features as VS. But none of them are as useful than VIM+Make+GDB.
 
> Well, AFAIK nobody has the awesome "edit and continue" feature except VS
> (which IMHO has the best debugger out there).
 
There was an effort spear-headed by Apple a few years back to get
"fix-and-continue" working in their toolchain + gdb. As I understand
it, they completed it and got it working fairly decently (though not
bug free).
 
I do not use Apple products so I have no idea where it is today. I've
just seen forum posts from time to time dating back to the 2000s.
 
Best regards,
Rick C. Hodgin
legalize+jeeves@mail.xmission.com (Richard): Jan 12 09:13PM

[Please do not mail me a copy of your followup]
 
Ian Collins <ian-news@hotmail.com> spake the secret code
 
>On 01/13/17 07:29 AM, Scott Lurndal wrote:
>> There are a dozen native IDE's available for linux with all the
>> same features as VS.
 
Clearly you don't use VS for anything more fancy than typing.
 
There is only one IDE that comes even close to VS productivity and
that is CLion.
 
>> But none of them are as useful than VIM+Make+GDB.
 
Yes, you are using an IDE for typing. They do much more than that.
 
Oh, and gdb is absolutely horrible. It hasn't changed in 20+ years
since I first used it. The VS debugger crushes gdb.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 12 07:10PM

On 11/01/2017 18:17, JiiPee wrote:
> but other ways. What would be the best way for the function to report
> about "dividing by zero" case? How would you do it?
 
> I kind of agree with Bjarne here.... do you?
 
The correct thing to do in C++ is to throw an exception derived from
std::logic_error as dividing by zero is undefined in mathematics and a
bug in code.
 
/Flibble
Gareth Owen <gwowen@gmail.com>: Jan 12 07:12PM


>> Blessed are you, undefined behavior.
 
> Word salad.
 
> /Flibble
 
Game recognise game
Gareth Owen <gwowen@gmail.com>: Jan 12 07:17PM


> The correct thing to do in C++ is to throw an exception derived from
> std::logic_error as dividing by zero is undefined in mathematics and a
> bug in code.
 
I agree.
 
My personal choice would be std::invalid_argument or std::domain_error.
JiiPee <no@notvalid.com>: Jan 12 07:17PM

This is a bit relating to my previous post, because this is the problem
am having in my project.
 
class MyArray
 
{
 
public:
 
int get(int index) {
 
}
 
private:
 
int array[10];
 
};
 
 
Now I can get an array element:
 
MyArray arr;
 
int second = arr.get(1); // return the second element
 
But I want this to be as fast operation as possible. The problem is that
this inline code seems to do it something like (after adding inline code
into place):
 
MyArray arr;
 
int index{1};
 
int second = array[index];
 
, where array is arr's array. But it has this extra temporary variable
int index{1}; . So how can I get rid of that temporary?
 
I know I can do:
 
class MyArray
 
{
 
public:
 
int* getArray() {
 
return array;
 
}
 
private:
 
int array[10];
 
};
 
 
and call it:
 
MyArray arr;
 
int second = arr.getArray()[1];
 
but that gets a bit ugly... (and this is what I am currently actually doing)
JiiPee <no@notvalid.com>: Jan 12 05:22PM

I though inline function is placed in the place of calling and without
creating the temporary function parameters. But seems like inline
always(?) creates the function parameters?
 
I tested like this:
 
class Foo
{
public:
Foo* x;
void setX(Foo val) {
x = new Foo;
*x = val;
}
};
 
int main() {
 
Foo a, b;
 
a.setX(b);
 
}
 
When I debug this I can see that the temporary function argument "Foo
val" is created and b assigned into it. And after that is does the copy
operation "*x = val;" as well. I was hoping inlining would pass the
creation of "val" but it does not. Is this always the case that the
function parameters are always created when calllling an inline function?
 
I was hoping the compiler to generate a code something like (after
placing inline code into main()):
 
Foo a, b;
 
Foo::x = new Foo;
*Foo::x = b;
 
... so it would have passed the copy-contruction call which is kind of
needless here. Why the compiler does not do that? How about if I have
"int" parameters, will it also create those temporary function parameters?
scott@slp53.sl.home (Scott Lurndal): Jan 12 05:44PM

>I though inline function is placed in the place of calling and without
>creating the temporary function parameters. But seems like inline
>always(?) creates the function parameters?
 
Did you compile it with a sufficient level of optimization?
 
gcc won't optimize those out unless you specify -O2 or -O3.
JiiPee <no@notvalid.com>: Jan 12 05:49PM

On 12/01/2017 17:44, Scott Lurndal wrote:
>> always(?) creates the function parameters?
 
> Did you compile it with a sufficient level of optimization?
 
> gcc won't optimize those out unless you specify -O2 or -O3.
 
 
Well this is Visual Studio 2015, with default setting. I compiled a
release version. I need to change its settings? I though its set to
optimize..?
JiiPee <no@notvalid.com>: Jan 12 05:55PM

On 12/01/2017 17:49, Stefan Ram wrote:
> but I'd
> say the »inline substitution« of f(int x){g(x);} into f(2)
> is {int x=2;g(x);}.
 
 
oh, so the inline does not take off that x-variable. hmm, in most of my
inline needs I would prefer:
 
{g(2);} as a result... because I looop millions times per second an array in a loop, so that temporary would slow down that loop.
 
inline void set(int index, int value) {
myValues[index] = value;
}
 
I would need this to be made:
set(2, 866) ->
myValues[2] = 866;
red floyd <dont.bother@its.invalid>: Jan 12 10:18AM -0800

On 1/12/2017 9:55 AM, JiiPee wrote:
 
> I would need this to be made:
> set(2, 866) ->
> myValues[2] = 866;
 
Pass by const ref?
 
void Foo::setX(const Foo& val) {
// ...
}
JiiPee <no@notvalid.com>: Jan 12 06:25PM

On 12/01/2017 18:18, red floyd wrote:
 
> void Foo::setX(const Foo& val) {
> // ...
> }
 
yes in this case. But how would you use array indexes without need to
copy indexes? I know we can get a reference to the array, but if we want
to use an index:
 
 
Foo a;
 
a.set(i); // ---> set an array value with index i.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 12 05:49PM

>I though inline function is placed in the place of calling and without
>creating the temporary function parameters. But seems like inline
>always(?) creates the function parameters?
 
The inline specifier indicates to the implementation that
inline substitution of the function body at the point of
call is to be preferred to the usual function call mechanism.
7.1.6p2
 
»Inline substitution« is not defined by the standard, but I'd
say the »inline substitution« of f(int x){g(x);} into f(2)
is {int x=2;g(x);}. Then, further (possibly, implementation
dependent) optimizations might apply.
"Chris M. Thomasson" <invalid@invalid.invalid>: Jan 11 04:15PM -0800

On 1/11/2017 2:50 PM, Chris M. Thomasson wrote:
> ct_complex_compare(
> ct_complex const& c0,
 
> ct_complex c1,
^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
Umm, that should be (ct_complex const& c1):
________________________________________
bool
ct_complex_compare(
ct_complex const& c0,
ct_complex const& c1,
ct_float epsilon
) {
ct_complex d = c1 - c0;
return std::abs(d) < epsilon;
}
________________________________________
 
Sorry about that nonsense.
 
 
Lynn McGuire <lynnmcguire5@gmail.com>: Jan 11 05:44PM -0600

"C++ Status at the end of 2016"
http://www.bfilipek.com/2016/12/c-status-at-end-of-2016.html
 
Looks like there will be a C++17.
 
And I am working in Fortran 77 today.
 
Lynn
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)