The programming thread.

pibbuR

Feeling ... lonely?
Joined
Nov 11, 2019
Messages
1,172
Location
Bergen@Norway
Now for the answers to the C/C++ question for approach 4.
  1. The reserved word "nullptr" for the C "NULL" pointer is C++, not C. "NULL" is legal in C++, but "nullptr" is recommended.
  2. C doesn't use namespaces, specifically, "std::max" is C++, not C
  3. Passing arguments to a function by reference ("void set_record(info& record, const wchar_t* buffer)", notice the & operator) is C++. References allow a function to change an argument, and may save time. Both C and C++ can use pointers for this, but only C++ have references.
I am surprised that he managed to compile the code. Well, many C compilers are actually C/C++ compilers, and most of C works in C++. But constructs like "std::max" should require the inclusion (import) of specific C++ headers (modules in C++ 20) like iostream. However, some compilers seem to include that by default.

pibbuR who aknowledges he may be wrong in things he write.
 
Last edited:
Joined
Nov 11, 2019
Messages
1,172
Location
Bergen@Norway

Redglyph

SasqWatch
Joined
Aug 29, 2020
Messages
5,761
Location
Good old Europe
Both C and C++ can use pointers for this, but only C++ have references
I agree. The C Programming Language (Kernighan & Ritchie) is the only valid C reference, and there was no argument about it. Maybe I misunderstood... 😉

More seriously, it's strange indeed, now that you mention it. It's true that C/C++ compilers are lenient about those things. Some C++ features might be creeping into the latest C standards, too.
 
Joined
Aug 29, 2020
Messages
5,761
Location
Good old Europe

Steven Peeler

Watchdog
Joined
Jun 27, 2007
Messages
92
Location
Dallas, TX
Now for the answers to the C/C++ question for approach 4.
I'm guessing that they just meant C style (no classes) and #3 is probably so slow since they are reading/writing a little at a time. Generally you want to read/write large chunks at a time and parse things in memory.
 
Joined
Jun 27, 2007
Messages
92
Location
Dallas, TX

Redglyph

SasqWatch
Joined
Aug 29, 2020
Messages
5,761
Location
Good old Europe
Approach 3 uses Unicode, that must certainly cost something when interpreting the data, and it doubles the transfers (at best).

EDIT: he's using wchar/wstring in some other approaches too, though, so the transfers must remain the same. He avoids the interpretation then forces the pointers to switch from char to wchar, so any special character in the file will probably end up as garbage, but since it's much faster, maybe it won't be noticeable. 😂

I hate having to deal with Unicode. Rust really pushes its use because of safety and it complicates things.
 
Last edited:
Joined
Aug 29, 2020
Messages
5,761
Location
Good old Europe

booboo

SasqWatch
Joined
Aug 23, 2007
Messages
1,892
Location
Cape Town, South Africa
Whoa, C++ discussion ;-) I teach programming with C++ - not a universally loved language, and each standard adds more esoteric stuff. I mostly stick with C++11 with a few bells and whistles from later standards. I'm going to be doing more machine learning research next year, and I will probably forego C++ in favour of Python, there is just so much support for Py* everything. Sadly I don't like Python...that space/tab based indentation is an abomination. And I still don't *think* in Python - so the Python idioms are not narural to me and I suspect my code looks like crap. But it's research code, so that doesn't matter (much) :) I have some colleagues who are always pimping Rust, but haven't gone done that rabbithole yet.
 
Joined
Aug 23, 2007
Messages
1,892
Location
Cape Town, South Africa

Redglyph

SasqWatch
Joined
Aug 29, 2020
Messages
5,761
Location
Good old Europe
Heads-up: it's a deep rabbithole. ;)

I didn't find Python's indentation natural either, coming for C++. I don't even notice it anymore, it has the advantage of being clear and not requiring semicolons. I really love the language because it's clear, concise, flexible and powerful, you can do a lot of things very quickly, but I would never use it for a big project because of the dynamic typing. It quickly becomes messy when working with others.

What is counter-nature when coming from C++ is embracing the iteration/generator concept and avoiding to use indices. The first time I saw something like this I thought the guy who wrote it was nuts: "for line in some_file.readlines()". What?? Then I understood that no, it didn't mean all lines were stored in memory. :D
 
Joined
Aug 29, 2020
Messages
5,761
Location
Good old Europe

pibbuR

Feeling ... lonely?
Joined
Nov 11, 2019
Messages
1,172
Location
Bergen@Norway
What is counter-nature when coming from C++ is embracing the iteration/generator concept and avoiding to use indices. The first time I saw something like this I thought the guy who wrote it was nuts: "for line in some_file.readlines()". What?? Then I understood that no, it didn't mean all lines were stored in memory. :D
Unless I misunderstand you, C++20 has got the
for(MyClass myObject:MyClassVector) which should be similar.

for(Pibbur pibbuR: pibbuRList)....
 
Joined
Nov 11, 2019
Messages
1,172
Location
Bergen@Norway

pibbuR

Feeling ... lonely?
Joined
Nov 11, 2019
Messages
1,172
Location
Bergen@Norway
Whoa, C++ discussion ;-) I teach programming with C++ - not a universally loved language, and each standard adds more esoteric stuff. I mostly stick with C++11 with a few bells and whistles from later standards.
I like C++ very much. C++ 20 adds a few good things, like the std::format() function and modules, but I admit not all of it makes much sense to me. It's also a bit frustrating that the language now allow so many different ways of doing the exactly same, like the the different ways, some of them quite cryptic, of defining templates.

I use smart pointers as much as I can, but some libraries demand ordinary pointers, which makes things more complicated. Qt is one example, at least I haven't found a good way use smart pointers there - there may be, but at the moment I'm not very good at C++ programming.

Well, C++ derives from C, and for C, making obfuscating code is kind of a sport (https://www.ioccc.org/). So....

import <PibbuR>;
 
Joined
Nov 11, 2019
Messages
1,172
Location
Bergen@Norway

Redglyph

SasqWatch
Joined
Aug 29, 2020
Messages
5,761
Location
Good old Europe
Unless I misunderstand you, C++20 has got the
for(MyClass myObject:MyClassVector) which should be similar.

for(Pibbur pibbuR: pibbuRList)....
I dropped out before that version. ;) But I saw that C++ got modern features like that, and delegates, maybe even closures, all very good for UI programming for example.

Not sure if asynchronous coroutines are part of the language yet. This allows for inexpensive, fine-grained parallelism to boost I/O-dependent code, by non preemptively switching between tasks on the same thread (or over a pool of threads). In clear, something that feels like multithreading but without necessarily using multithreading. Very handy for UI code too. Python has some support for it, though it's more barbaric(*) than Kotlin, C# and Rust.

One thing with Python is the huge environment it has to carry, because it comes with all those libraries and depends on them...

(*) in the modern sense, not meaning it's not compatible with ancient Greek...
 
Joined
Aug 29, 2020
Messages
5,761
Location
Good old Europe

booboo

SasqWatch
Joined
Aug 23, 2007
Messages
1,892
Location
Cape Town, South Africa
Ah C...those werer simpler times...and not simple too.... *p = crash. huh? One thing about Python (once you have waded through the backtrace) it's pretty clear why something broke (well, mostly). I also get very agitated when I can't see types - looking at the untyped declarations in python is twitch inducing. List? Dictionary? Something else? I'll get used to it :) It is a very useful language and I can see why it has taken off to the extent it has....
 
Joined
Aug 23, 2007
Messages
1,892
Location
Cape Town, South Africa

pibbuR

Feeling ... lonely?
Joined
Nov 11, 2019
Messages
1,172
Location
Bergen@Norway
Ah C...those werer simpler times...and not simple too.... *p = crash. huh?
Oh yes. I remember very well back in '92 when I was doing my master thesis in informatics. I was making an OS/2(!) program to track contours of structures in electron microscopic images from serial sections of cells. Around 10000 lines of code. Quite often, when making a tiny change of the code, the program would suddenly start to crash. The culprit was of course a dangling pointer to nowhere suddenly starting to mess with locations the OS would like to keep to itself. Took a long long time to find them.

Smart pointers shouldn't have that problem. Two questions, however:
  1. Are they always safe, in the sense that they will never cause problems like raw pointers can?
  2. Do they significantly affect performance, so on should avoid them in time critical parts (loops) of a program?
pibbuR who doesn't know, but assume that the net (and watchers in particular) do.

EDIT: Found an answer here: (https://stackoverflow.com/questions...art-pointers-compared-to-normal-pointers-in-c)

It's only when creating/destruction the pointers that performance becomes a factor, for shared pointers more than unique pointers. Dereferencing is not affected. So unless a program is constantly creating /destructing pointers, performance "penalty" should be insignificant.

PS. I miss OS/2. It had a very clean and consistent API, unlike Windows. IMNSHO. DS.
 
Last edited:
Joined
Nov 11, 2019
Messages
1,172
Location
Bergen@Norway

Redglyph

SasqWatch
Joined
Aug 29, 2020
Messages
5,761
Location
Good old Europe
Now we have nice tools like Valgrind to detect those problems.
Are they always safe, in the sense that they will never cause problems like raw pointers can?
I don't know much about C++ smart pointers, I've only used them in other languages (GC languages or Rust).

Off the top of my head I see the following risks:
  • leaks when there are loop references that prevent memory from being deallocated
  • the usual sharing and race conditions if they're read/written at different locations, especially with asynchronous code (I don't suppose they have built-in semaphores because of the overhead)
  • using the raw pointer when there's a chance the memory is deallocated (since you mentioned that some APIs only took raw pointers.)
 
Joined
Aug 29, 2020
Messages
5,761
Location
Good old Europe

khaight

Sentinel
Joined
Nov 30, 2009
Messages
410
Location
California
I've used C++ smart pointers fairly extensively. Redglyph hit the high points.
  • If A holds a smart pointer to B and B holds a smart pointer to A, it's possible to leak both objects. You can use weak pointers to help break the loop but that carries its own requirements (what do you do if the weak pointer is no good when you try to use it?). Basically smart pointers can't serve as a substitute for intelligently designing your data structures, their interrelationships, their life-cycle and their ownership model.
  • Exporting the raw pointer to other APIs that may keep using it after the smart pointer system has deleted the underlying object.
  • I've also seen issues with object destructors being invoked in unexpected thread contexts because the final smart pointer reference happened to be held by a temporary variable in some function that used it momentarily. When the destructor is heavyweight that can sometimes lead to unexpected consequences.
Asynchronous access in different threads usually isn't a problem, or at least not more of one due to the use of smart pointers. Modifying the underlying object requires synchronization whether you use smart pointers or not. Changing the object that a given smart pointer instance refers to isn't a problem, though, because the reference count is updated atomically.
 
Joined
Nov 30, 2009
Messages
410
Location
California
Top Bottom