C++ Programming

[Wheels-Of-Fire]

C++11 was a long time in development and it was a major advance. C++14 tidied up a few things that C++11 still didn’t get quite right. Anything since then does indeed look like it was done just for the sake of it.

I haven’t got any books that cover the final release of C++20 but the bits I have seen all add extra complication, modules instead of #include is a case in point.

[Wheels-Of-Fire]

It is the stated aim of the C++ committee to bring out a new version every 3 years and they have done since C++11, whether they have anything worth releasing or not 😂

[Ed P]

That explains EVERYTHING!

[Wheels-Of-Fire]

I have found a reason why the end() iterator points to one past the end of a sequence, it seems to be entirely so I can write code like this.

while (begin != end)

{ *begin = val;

++begin;}

The begin/end range is known as a “left inclusive interval” so it includes the element denoted by begin but not the one denoted by end.

The above while loop will read all the elements in the range but not the one past the end. If end() pointed to the last element then that element would not be read.

[Ed P]

Is that counter-intuitive behaviour due to the use of a pre-iterator rather than a post iterator e,g begin++ rather than ++begin.

Give me good old C any day!

[Wheels-Of-Fire]

It would work the same either way. The difference between the pre and post increment is that if you stick the ++ in front then the increment will occur before any other operations in an expression that its in.

[Wheels-Of-Fire]

The C++ Primer book recommends always using the pre increment form to avoid unexpected results, unless you really DO know what the post increment will do in an expression. As a stand alone operation it don’t matter 😁

[Wheels-Of-Fire]

I have been looking at some of the things that container types provide, this time in the “probably don’t need to know” category.

Containers provide a number of TYPE members that are designed for generic programming without regard for your particular system, they will be defined to match your environment.

An example is difference_type below:

 

#include <iostream>
#include <vector>

using namespace std;

int main()
{
vector<int> test{ 1,2,3,4 };

vector<int>::difference_type value = std::distance(test.begin(),test.end()) ;
cout << value << endl;

vector<int>::difference_type value1 = test.end() – test.begin();
cout << value1;
}

This outputs 4 twice.

[Wheels-Of-Fire]

Oh yeh, the type of value and value1 ends up being ptrdiff_t.

[Ed P]

I think in your specific example, that a post increment is more predictable as then everything within the ‘while group’ is processed. Imo to omit the last element is a potential cause of error as the last element pointed at by *begin has no value. As you said it all depends on context, but ‘while’ loops always need extra care especially if you are iterating through pointers or an array.

[Wheels-Of-Fire]

Ah thats the thing, the last element pointed to by begin will indeed be one off the end but because begin will be equal to end we do not attempt to assign a value to it.

[Wheels-Of-Fire]

Here is some real working code wot I just wrote:

#include<iostream>
#include<vector>

using namespace std;

int main()
{
vector<int> test{ 1,2,3,4 };

vector<int>::iterator begin = test.begin();
vector<int>::iterator end = test.end();

while (begin != end)
{
cout << *begin << endl;
++begin;
}
}

Prints the numbers 1-4 and does not attempt to print a fifth element. Instead of specifying the iterator type I could have just bunged in “auto” but seeing as I have been looking at container member types I thought I would do it long hand.

[Ed P]

Wheels-Of-Fire wrote:

Ah thats the thing, the last element pointed to by begin will indeed be one off the end but because begin will be equal to end we do not attempt to assign a value to it.

Fair point.

[Wheels-Of-Fire]

Just came accross an interesting function thats not in any of my books.

system() let’s you issue commands to your systems command processor so system(“CHCP 850”) will set your console code page to CP 850 and system( “DATE”) will display the date.

In fact you can issue any command  that you could in a command prompt window.

[Wheels-Of-Fire]

And on a related note, the Visual Studio Console Window now supports ANSI control codes so cout << char(27) << “[4;31m Hello”; prints Hello in underlined red text.

Its a bit pointless at the moment though because the standard CMD window still does not, your .EXE file will just print the control codes.

Apparently its part of the Linux subsystem support.

[Ed P]

Wheels-Of-Fire wrote:

And on a related note, the Visual Studio Console Window now supports ANSI control codes so cout << char(27) << “[4;31m Hello”; prints Hello in underlined red text.

I suspect that it goes all the way back to Dos/Unix days.

Incidentally iirc things like code pages etc used to go in the header files, rather than being hard coded into the source file.

[Wheels-Of-Fire]

Yes you would probably put things like system() calls in a header file so that if you changed anything then only that file would need to be recompiled.

The ANSI thing is new in Windows, apparently it was widely used on UNIX systems but you had to load the ANSI.SYS driver to make it work on DOS and it never really caught on, Windows didn’t bother supporting it at all until last month.

The Windows Terminal program also supports ANSI codes now and there is talk of merging its code with the Windows console code.

Again its all to do with enhanced Linux support. If you use a Windows machine to remotely connect to a Linux machine then you may get sent ANSI control codes. Apparently 😁

[Wheels-Of-Fire]

Not really C++ but if you fancy having a go with the new Windows Terminal then type it into the search bar and download it from the Windows store.

The Terminal window opens with Power Shell running but you can type CMD.EXE to launch that if you like.

[Wheels-Of-Fire]

I was wrong about the safeness of using “new” within a class.

If you create a pointer to a class type within a class then when the class goes out of scope then the pointer is implicitly destroyed and the destructor for the object it pointed to is called to destroy that as well.

However, the built in types do not have destructors so if you create a pointer to a built in type, an int say, and you fail to delete it before the class goes out of scope, then the pointer will still be implicitly destroyed but the object it pointed to will not. This leaves an object in memory with no pointer referring to it and so no way to delete it.

The solution to the problem is to use a “smart” pointer. A smart pointer is a class object so it has a destructor that destroys the objects it points to when it goes out of scope ( well a unique pointer does, a shared pointer keeps a reference count to its object and only deletes it when the count goes to zero).

[Ed P]

Wheels-Of-Fire wrote:

The solution to the problem is to use a “smart” pointer. A smart pointer is a class object so it has a destructor that destroys the objects it points to when it goes out of scope

Nice but will it work with (say) memory allocated to hold a large object or structure that has been allocated with alloc,  calloc, malloc etc?

[Author]

Posts