Forumite Members › General Topics › Tech › Makers & Builders › Programming/Code tips › C++ Programming
- This topic has 258 replies, 5 voices, and was last updated 2 years, 12 months ago by
Wheels-Of-Fire.
-
AuthorPosts
-
November 2, 2020 at 5:13 pm #63159
I forgot to correct your assertion that C++ managed compiled bytecode is not analogous to p-code. Microsoft does not call it p-code they call it bytecode, but it is in fact managed by the Common Language Runtime. See M$ article
This M$ document explains how it works. In my view the principle of using the M$ CLR is not a lot different from the Java or Python runtime machines both of which run in a managed environment. It isn’t old school bare metal C++ unmanaged code that when compiled runs directly on the CPU.
“The Managed Code running under a Common Language Runtime cannot be accessed outside the runtime environment as well as cannot call directly from outside the runtime environment.”
November 2, 2020 at 7:15 pm #63162Visual Studio C++/CLI is indeed used to generate managed code for the .NET framework and it does use intermediate code.
But I am NOT using it 😆
C++/CLI is a seperate component provided with Visual Studio. I am using Visual C++, also provided with VS,and it produces neat, standalone, executable, binary’s, straight from source code.
As it happens VC++ also includes a C complier that is now C99 compliant so you can use that instead if you like.
November 4, 2020 at 10:07 am #63193Hmm. If you want to get REALLY close to the metal with VC++ then have a look at the link below.
https://docs.microsoft.com/en-us/cpp/assembler/inline/inline-assembler-overview?view=msvc-160
Just found that while I was looking for something else, as is usual when looking for anything in the Visual Studio Doc’s 🤨
November 8, 2020 at 9:56 pm #63378Just found another couple of interesting member functions that apply to library container classes.
As I have mentioned before, all the container types, except Array, can be expanded at will and, as their elements have to be contiguous in memory, if you expand a container then all its elements need to be moved to a new, larger, block of memory. You can’t just tack a new element on the end of the existing elements because that memory may well be in use buy something else.
Except sometimes you can 😁.
As I have mentioned before, when you first create a container, like a Vector or String, C++ only allocates enough memory to hold its initial list of elements, after all you may never expand the container. After you expand a container once, and its elements need to be moved, C++ will allocate a new memory block that is bigger than required for the new element, how much bigger is implementation dependent but it gives some spare capacity so the elements will not need to be moved again when you next add an element. This is where the member functions I just read about come in handy.
The <capacity> function returns the number of elements you can add before they will all need to be moved again.
The <reserve> function allows you to allocate extra space in advance, so if you know how big your container is likely to get then you can allocate that much space in advance and save all the copying time.
The <shrink_to_fit> function does what it says on the tin, it deallocates unused space.
None of the above is necessary for your program to work but it may well make it faster.
November 8, 2020 at 10:15 pm #63380Another advantage to preallocating enough space is that if you only ever add elements to the end using <push_back> then any pointers or references you have to existing elements will not be invalidated by having them moved around in memory. If you insert an element somewhere in the middle then any pointers or references after the insertion point will still become invalid.
November 9, 2020 at 7:32 am #63388Not too surprising really as it is analogous to the old assembler level ‘push’ and ‘pop’ stack commands.
November 9, 2020 at 12:13 pm #63396Here we go again.
I am well used to using subscripting to obtain a substring from a container, it is more or less the same as Atari BASIC except that with BASIC you supply a starting element and an ending element but with C++ you supply a starting element and a length. However, now I am being told to avoid subscripting if I can because it is not guaranteed to be safe, it is possible to supply a substring that goes off the ends of a container.
C++ provides a pair of iterators for container types called .begin and .end
When a container is first created .begin will point to the first element and .end will point to 1 past the last. These are iterators so they can be incremented or decremented to get the previous or next element but neither of them can be set to point to outside a container. The .end iterator cannot be set to point to before .begin and .begin cannot be set to point to after .end so they are safe.
You can also dereference an iterator to get the value of the element it points to.
I am still reading about iterators because there is more to them but at the moment it just seems like more complication 🙄
November 9, 2020 at 12:15 pm #63398I meant to say it is possible to supply a subscript that goes off the ends of a container.
November 9, 2020 at 2:17 pm #63406Many of the complications in C++ are to ensure ‘safe’ code, and avoid unsafe code that results in ‘read beyond’ situations.
Have you finished grappling with the differences between the old ANSI strings and Unicode Strings?
November 9, 2020 at 4:55 pm #63415My book doesn’t really cover Unicode except to say that C++ supports the wchar_t type which is a 2 byte Unicode character and that C++ 11 also supports char16_t and char32_t (doesn’t say what they may be). The link below gives some idea of why a primer book may not cover Unicode much.
November 9, 2020 at 7:00 pm #63426Yep, it is a bitch, but Windows uses it!
Imo the real problems came when there was a need to convert ANSI to or from Unicode. I’d guess it is less of a problem now, but it used to be a real B if libraries/DLLs required and emitted ANSI. :wacko:
November 9, 2020 at 8:06 pm #63430https://docs.microsoft.com/en-us/cpp/cpp/char-wchar-t-char16-t-char32-t?view=msvc-160
The above link gives the current take on what Unicode types Visual C++ supports but, regardless of that, Windows its self and its API’s still only support UTF-16LE which is the same as C++ wchar_t.
November 10, 2020 at 7:10 am #63439It was the need to convert from the ‘wide’ character to the old ANSI ‘byte’ character that used to cause problems. Iirc it used to be mainly in the graphics dlls that such conversions were required.
November 10, 2020 at 11:54 am #63449I just read about what container type iterators are most useful for.
Container type classes contain very few or zero functions that work on their contents, things like sort or find are not defined in the class. Instead, C++ provides the <algorithm> std library that provides a set of generic functions that work with all types.
In order to make the functions generic they take the iterators supplied by container classes as their arguments.
So now its clear as mud, I am going to have to read that section again 😁
November 11, 2020 at 7:42 pm #63488So now we move on from sequential containers to associative containers. Map’s, Set’s, Key/Value pairs and hash functions.
Except I think “I” don’t 😁
I think I am just going to skim that chapter again and come back to it when/if I find a need for such things.
November 11, 2020 at 8:31 pm #63490Unless you are in a development team producing ‘Enterprise’ code, you probably will never use 50% of C++ templates etc. :negative:
November 13, 2020 at 8:43 pm #63544Having skipped associative containers I now get to dynamic memory allocation.
We start with pointers to objects that are dynamically allocated on the system heap using the “new” operator. Dynamic objects do not have a name so they must be referred to by a pointer that is created at the same time as the object. Dynamic objects are never destroyed automatically so their memory must be released using the “delete” operator which takes a pointer as its argument.
There are two potential problems with this setup, one is bad and the other is worse 😁.
A program may forget to delete a dynamic object when it is finished with it so the object will continue to occupy memory until the program terminates.
The worse problem comes if you create a pointer to a dynamic object within a function but forget to delete it before the function ends, In this case the pointer will be destroyed when it goes out of focus but the object it points to will not.
C++ does not know how many built in pointers may point to a dynamic object so it cannot delete them automatically but if the last pointer that points to a dynamic object is deleted then there is NO WAY to refer to the unnamed object so it cannot be deleted !
I am now going to read about Smart pointers which apparently get around this problem 😃
November 14, 2020 at 10:03 pm #63564So then, smart pointers.
The concept is simple but their application becomes very complex very fast, like all things in C++ it would seem 🤨
The smart pointer class, provided in the std library, creates smart pointers to dynamically assigned objects and it keeps a reference count of all other smart pointers that point to the same object. The smart pointer class has a destructor so when the reference count to a dynamic object reaches zero it can delete the object as well as the last pointer to it.
If you create a smart pointer to a dynamic object from within a function, using the New operator, then the object will be deleted when the function ends because its pointer will have gone out of scope. If you want to keep the object then the function needs to return a smart pointer to it.
So far so simple but the smart pointer class only has destructors for built in types so if you use your own types, like a class, then you have to provide your own destructor that overrides the default one. On top of that you can have standard pointers that point to smart pointers and they do not add to the reference count for an object so a smart pointer can still delete a dynamic object and leave a standard pointer dangling.
It gets worse but i’ve had enough for now 🙄
November 14, 2020 at 10:34 pm #63566I like green
Just trying bbcodes 😁
December 12, 2020 at 5:50 pm #64551Well would you believe it ?
The support website http://www.stroustrup.com/programming for the book “Programming Principles And Practice” is finally in the process of being updated ! They have got as far as producing an updated listing for the bug riddled “std_lib_facilities.h” file so I copy and pasted it in to Visual Studio and finally got to work on the graphics classes in chapter 12.
Below is a link to the compiled result, I hope 🙂
https://1drv.ms/u/s!ApY7Ke0brhrm9HcBx0umtXjBIx6p?e=jJQwot
d
-
AuthorPosts
- You must be logged in to reply to this topic.
