Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

[We] use bad software and bad machines for the wrong things. -- R. W. Hamming


programming / comp.lang.c++ / latest

Re: Something that works with concepts that doesn't work witth real (thread)

comp.lang.c++

Posted: 5 Hours 9 Minutes ago by: David Brown

If these are paid publications, please do not post any kinds of links or information about getting them in ways that violate the publishers' copyrights. By all means post a link to the publishers' pages so that people can choose if th

Re: Something that works with concepts that doesn't work witth real (thread)

comp.lang.c++

Posted: 17 Hours 38 Minutes ago by: Paavo Helde

said the man on the highway when everybody else drove on the opposite direction...

Re: Something that works with concepts that doesn't work witth real (thread)

comp.lang.c++

Posted: 18 Hours 52 Minutes ago by: Bonita Montero

Take this: https://mega.nz/file/rpNCkDoI#U83BZ_3lYFcYIJrb9rOn-sRnZW9cH3K73NULq4GxMXs Password for the archive is "You are all crazy".

Re: Something that works with concepts that doesn't work witth real (thread)

comp.lang.c++

Posted: 19 Hours 25 Minutes ago by: Bonita Montero

LOL.

Re: Something that works with concepts that doesn't work witth real (thread)

comp.lang.c++

Posted: 19 Hours 25 Minutes ago by: Bonita Montero

You're ridiculous. Do you want some E-books as PDFs that make an introduction for the new C++20 features for experienced C++17 developers ? I've bought some on Leanpub and as they don't have any DRM I can share the PDFs.

Re: Something that works with concepts that doesn't work witth real (thread)

comp.lang.c++

Posted: 19 Hours 41 Minutes ago by: Bonita Montero

That's a matter of personal taste and there aren't any logical reasons for that.

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 20 Hours 38 Minutes ago by: Scott Lurndal

And it (x86) was running in 32-bit flat mode with paging enabled for the majority of systems (unix) where C mattered at the time. Full 32-bit pointers and 32-bit int. While this is true, it had little to do with x86, but rather the hu

Experts would agree that my reviewers are incorrect

comp.theory

Posted: 22 Hours 13 Minutes ago by: olcott

All of the recent discussions are simply disagreement with an easily verifiable fact. Any smart software engineer with a sufficient technical background can easily confirm that H(P,P)==0 is correct: Where H is a C function that correctl

Re: This code is effective for modest-sized numbers, but can you tell what it does? (thread)

comp.lang.c++

Posted: 1 Day ago by: Tim Rentsch

This sounds like you are offering an implicit argument that because your group does it all the time it follows that it's a good idea. I don't find such an argument convincing in any way. Such cases would still be caught if the signed/

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 1 Day ago by: Tim Rentsch

[...] I saw this essay several years ago (probably because someone posted a link to it in the newsgroup here). After seeing this comment I got a fresh copy and re-read it, perhaps a bit more carefully than my first reading. Even with

Re: Something that works with concepts that doesn't work witth real (thread)

comp.lang.c++

Posted: 1 Day 1 Hour ago by: Manfred

I have been looking into this "concepts" thing, but haven't used seriously yet. But I fully agree with your point that the name is horribly wrong. The feature really is "requirements of a template on its template arguments", for which a

Re: Something that works with concepts that doesn't work witth real (thread)

comp.lang.c++

Posted: 1 Day 2 Hours ago by: Alf P. Steinbach

In my opinion it's best to not talk about "r-value /object/", because objects can't be R-values or L-values: only /expressions/ are R-value or L-value. If you really intended to use `move` in the code, then this should best include

Re: Something that works with concepts that doesn't work witth real code (thread)

comp.lang.c++

Posted: 1 Day 3 Hours ago by: Malcolm McLean

Not all characters are equal, and a single line at the top of the program can remove complexity from the code, even if the single line is longer than the total of characters removed. However it's not usually recommended to use "using names

Re: Something that works with concepts that doesn't work witth real (thread)

comp.lang.c++

Posted: 1 Day 3 Hours ago by: Bonita Montero

Idiot.

Re: Something that works with concepts that doesn't work witth real code (thread)

comp.lang.c++

Posted: 1 Day 7 Hours ago by: Juha Nieminen

I love how you write "using namespace std;" in order to save yourself from writing "std::" in one single place in the example. Thus saving you a grand total of -16 characters to type. So you are needlessly making your example 16 charact

Re: Question for Olcott [ summing up where we are ] (thread)

comp.theory

Posted: 1 Day 9 Hours ago by: olcott

Since you always knew this: that you are a liar when you claimed that they are equivalent. to back that up. I don't think that we are getting anywhere. All of the recent discussions are simply disagreement with an easily verifiable fa

A thread-queue

comp.lang.c++

Posted: 1 Day 10 Hours ago by: Bonita Montero

#pragma once #include <deque> #include <mutex> #include <condition_variable> #include <utility> #include <concepts> #include <list> template<typename QueueType> concept thread_queue_concept std::same_as<QueueType, std::deque<typename Qu

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 1 Day 13 Hours ago by: Richard Damon

Actually, during the formative years of the inital versions of the standard, the segmented archicture of the x86 system was prevalent, which could well have 32 bit pointers that only could span a 64k range of addresses at a time, made

Something that works with concepts that doesn't work witth real code

comp.lang.c++

Posted: 1 Day 17 Hours ago by: Bonita Montero

If you have a function that gets an r-value object inside the function behaves like a normal l-value object if you don't cast it to a r-value reference again, usually by move()-ing. With concepts you can define some pseudo-parameters that u

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 1 Day 21 Hours ago by: Manfred

True, pointer differences are one of the problems here. Well, obviously it wouldn't be like "just any other array". However, I wouldn't call "dumbness" the possibility of using /some/ standard library features (like find()) with it.

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 2 Days 13 Hours ago by: Malcolm McLean

I've been saying the same thing for a long time. The root of the mistake was that sizeof returned a size_t. So you could support sizeof(massive_array). The cost of that was to inflict mixed mode integer arithemetic on the whole of the r

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 2 Days 15 Hours ago by: Alf P. Steinbach

That was (and for embedded possibly still is) in support of 16-bit systems. And that support is half-baked with the pointer difference type being signed, and therefore required to be at least 17 bits (not joking here). When you have an

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 2 Days 17 Hours ago by: Manfred

Your example about character sets is wrong, however I may agree that your argument about size distribution is often valid for application development - or rather most of it. But, as I wrote, this is part of the standard library, where e

Are my reviewers dishonest or technically incompetent ?

comp.ai.philosophy

Posted: 2 Days 18 Hours ago by: olcott

That H(P,P)==0 is easily verified as correct by reverse engineering what the behavior of the input to H(P,P) would be if we assume that H performs a pure x86 emulation of its input. The x86 source-code of P specifies everything that we n

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 2 Days 23 Hours ago by: Öö Tiib

Yes. Quite common are arrays that grow never to thousands of elements. However as our generic dynamic array (std::vector) is pointer and two sizes we can't reduce most of that actual waste. We can't get any benefit from going lower than

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 3 Days ago by: Malcolm McLean

Sizes don't have a linear distribution. Whilst it would be hard to work out exactly what the distribution of the sizes of arrays in programs is, it would likely be a log normal distribution or something similar. So whilst losing a bit halv

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 3 Days 6 Hours ago by: Öö Tiib

The history shows that either half of that range is enough or way too short.. So where 7 bit ASCII is not enough there usage of 16 bit UCS-2 can become obsolete decade later.

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 3 Days 6 Hours ago by: Jivanmukta

I cannot do that because in this case my regex woudn't match text: public $x;

Re: Vector Fractal Bloom... (thread)

comp.lang.c++

Posted: 3 Days 13 Hours ago by: Chris M. Thomasson

https://fractalforums.org/gallery/1612-210522234523.png

Halting problem undecidability and infinitely nested simulation (V5)

comp.ai.philosophy

Posted: 3 Days 15 Hours ago by: olcott

Halting problem undecidability and infinitely nested simulation (V5) This is an explanation of a key new insight into the halting problem provided in the language of software engineering. Technical computer science terms are explained us

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 3 Days 16 Hours ago by: Manfred

But your example is still valid: size_t(-1) + 1 yields the correct value because of unsigned wrapping, which is defined behaviour. For the rest, using an unsigned number as an index inside a string makes sense, especially in the standa

Re: H(P,P)==0 is proven to be correct thus refuting the halting (thread)

comp.ai.philosophy

Posted: 3 Days 20 Hours ago by: olcott

The assumption is that H(P,P) correctly emulates its input. You are required to show the execution trace of the input to H(P,P) under that assumption for one emulation and one nested emulation. The one that you provided for the emulation

Re: H(P,P)==0 is proven to be correct thus refuting the halting (thread)

comp.ai.philosophy

Posted: 3 Days 20 Hours ago by: Richard Damon

Well, I wopuld need to have the code for H to do that, since that is PART of P. It would begin as: machine stack stack machine assembly address address data code language ======== ========

Re: H(P,P)==0 is proven to be correct thus refuting the halting (thread)

comp.ai.philosophy

Posted: 3 Days 21 Hours ago by: olcott

You know that you are a liar so I challenge you to provide the execution trace that a pure single level nested emulation of the input to H(P,P) would be. Any failure to provide this basis for your damned lies will be considered direct a

Re: H(P,P)==0 is proven to be correct thus refuting the halting (thread)

comp.ai.philosophy

Posted: 3 Days 21 Hours ago by: Richard Damon

No, it is easy to verify that it does NOT. No execution path from P actually CALLS another copy of P, as your trace implies. Remember, an execution trace is supposed to show the sequence of instructions that a CPU would actually execu

H(P,P)==0 is proven to be correct thus refuting the halting problem

comp.ai.philosophy

Posted: 3 Days 22 Hours ago by: olcott

It is an easily verified fact that the execution trace provided by H(P,P) of the nested simulation of its input exactly matches the behavior of the correctly reverse-engineered nested execution trace would be. To reverse-engineer this e

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 4 Days 17 Hours ago by: Paavo Helde

You are right, if std::string::find() returned a signed integer -1 for no-find, this code would work just as fine. The only thing is that it doesn't work that way, it returns size_t(-1) which is typically 18446744073709551615ULL nowada

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 4 Days 19 Hours ago by: Christian Gollwitzer

And where exactly do you need mod "ridiculous number" here? WHy is that better than having a signed index variable, where negative values indicate invalid indices? Christian

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 4 Days 21 Hours ago by: Richard Damon

It doesn't require "Branching", it just requires a conditional skip of the load of the function address from the vtable. Yes, there are uses when you KNOW things about your code that the complier/language isn't allowed to assume. Like

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 4 Days 22 Hours ago by: Tony Oliver

It looks like you're encountering Catastrophic Backtracking, caused by the spacing requirement between the third and fourth sub-expressions being optional. I would suggest replacing (at least) the third instance of \s* with \s+

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 4 Days 22 Hours ago by: Paavo Helde

I agree in general, but I have found one use case. Suppose we have a string s which might or might not contain a separator like ':' and we want to either return the part after separator, or the whole string if there is no separator. Th

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 4 Days 23 Hours ago by: Öö Tiib

When 64 bit signed int overflows then there is either programming defect in calculations or design defect that the type is misused for something arcane. Mundane stuff fits into it and for arcane purposes we should use arbitrary precision

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days ago by: David Brown

That is absolutely a relevant issue, for some code. For a lot of other code, speed is not important. For Malcolm's example, the speed of the code that calculates the sizes and number of pixels is going to be irrelevant compared to the

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days ago by: David Brown

Sorry, I misunderstood. Yes, I agree - you don't want undefined behaviour in the final code. But you also don't want behaviour that is defined, but wrong for the code - as is often the case for unsigned integer overflow. Using signe

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 1 Hour ago by: Ben

But the bounds of the image won't correspond to the signed wrapping so this has to be coded and checked for anyway. As a general rule, general rules are too general to be considered rules.

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 1 Hour ago by: Malcolm McLean

You frequently generate co-ordinates that go outside of image bounds when working with images. It's easier to deal with this if the values to the top and left go negative instead of wrapping to high positive values. As a general rule, it

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 1 Hour ago by: Ben

The suggestion was to prefer a program to be undefined rather than fiddle about with well-defined but fancy modulo arithmetic (I am paraphrasing -- the context has been lost). It was not about UB in general. Yes, but would you avoid u

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 2 Hours ago by: David Brown

I see two advantages of UB. One is that if your code never leads to overflows (and that should usually be the case, once you have everything tested and debugged), it gives the compiler some extra optimisation opportunities. But the b

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 2 Hours ago by: Juha Nieminen

From the perspective of C++ (and C) in particular, the problem is that unless the CPU itself supports catching overflow (and underflow), the compiler would need to generate checking code for every single arithmetic operation made in the p

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 2 Hours ago by: Juha Nieminen

Being able to crash a program (that's not supposed to ever end) can be a vulnerability in itself. I don't think you can safeguard against every single exploit with language features. As with all such situations, the programmer ought to

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 2 Hours ago by: David Brown

That's the big question in regard to overflow (signed or unsigned). /Sometimes/ you actually want wrapping behaviour, but it's rare. Possible desirable behaviour include: 1. Halting the program with an error message. 2. Returning an e

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 2 Hours ago by: Ben

I found the suggestion (not from you) that UB is an advantage a very odd one. I would consider it too unpredictable to be any practical help. But here, why not just make all the sizes unsigned? You have to do some bounds checking sinc

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 3 Hours ago by: Malcolm McLean

Say we've got this code. int width = getinteger(): int height = getinteger(); int Npixels = width* height; There's a potential vulnerability there if Npixels wraps. An attacker might be able to construct an input file that causes the pro

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 4 Hours ago by: Juha Nieminen

I'm not entirely sure what the point of that would be. What exactly should happen in such a program if an unsigned arithmetic operation overflows or underflows? Should the program end? Should the code throw an exception? (What would you d

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 4 Hours ago by: Malcolm McLean

That's certainly another advantage. (I tried to point this out a few weeks ago and received in reply that I shouldn't be programming if I couldn't avoid arithmetical overflow!). The snag is that to use it, you have to be able to put the c

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 5 Hours ago by: Juha Nieminen

I think I get now what you are saying. A pointer-to-virtual-member doesn't have to point directly to the function itself (as normal function pointers do). Instead, it points to a memory location that has the actual memory address of the

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 5 Hours ago by: Andrey Tarasevich

Yes. In the context of this topic I'm (we are) talking about non-static member functions only, and pointers to such member functions. Virtual ones and non-virtual ones. By "regular" I simply mean the latter. But that is incorrect. La

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 5 Hours ago by: Juha Nieminen

I suppose the compiler could make *all* function pointers be of the same size (ie. eg. the size of two pointers), but with regular (free-floating) functions that would be rather useless. A single pointer is enough for those. If by "regul

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 9 Hours ago by: Chris M. Thomasson

Correct. For some damn reason this thread is making me think of an older quick and dirty OOP thing for C I did a while back: https://pastebin.com/raw/QPssvGJR

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 9 Hours ago by: Andrey Tarasevich

Yes, versus the cost of "two representations" approach, which involves rather ugly branching to two fundamentally different calling methods in every call. As for "more thunks", see below. Yes, it is dangerous. Yet, this is the kind o

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 11 Hours ago by: Richard Damon

At the cost of an addition layer of calling and more thunks. The question comes can it find a place to hide it. As you have mentioned, if the class the function is in isn't at the same base address as the class the pointer is based on

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 15 Hours ago by: Andrey Tarasevich

Again, virtuality of the target function has absolutely nothing to do with the matter. Mentioning it will only obfuscate the actual purpose of the upper word in the pointer. The offset stored in the upper word is generally needed every

Re: What's the following program's purpose ? (thread)

comp.lang.c++

Posted: 5 Days 15 Hours ago by: Vir Campestris

You now owe him the Reichsmarks. You can buy them for about GBP5 on eBay :P Andy

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 16 Hours ago by: Vir Campestris

OK thanks, I think I see. (That's thanks to Scott, Andrey and Juha FTAOD.) Andy

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 18 Hours ago by: Andrey Tarasevich

You keep describing GCC's implementation. I've already described this in great detail previously. You are just repeating my previous explanations. For what reason? Well, of course, if you follow GCC's approach, then yes, you need a bi

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 18 Hours ago by: Andrey Tarasevich

Well, that's a completely different claim. "Sometimes", huh... Firstly, as MSVC implementation demonstrates that the flag is not necessary at all. Secondly, quite possibly it is the case "sometimes". However, one might argue that if t

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 19 Hours ago by: Richard Damon

Look at an actual layout of a class Since struct A has a virtual function in it, the class needs a vtable, so the layout of A will be something like: struct A: VTable* vtbl = vtable_A; // this gets filled in by the constructor.

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 19 Hours ago by: Richard Damon

But not all processors have a LSB to use for that sort of flag. Some have instructions that can be at any address, because the instruction set has single byte opcodes (They could just force all functions to be at addresses with lower o

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 19 Hours ago by: Paavo Helde

Yes, that would be fine if the language provided such an unsigned type. Alas, in C and C++ there are no such unsigned arithmetic types. All we have got are some strange cyclic wrapover types, and the wrapover threshold is not even fixe

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 19 Hours ago by: Andrey Tarasevich

Not sure what this is supposed to illustrate. That pointers-to-member-functions implement "late binding" at the point of the call? Yes, that's true and that's banal. However, this still does not in any way mean that pointers-to-member

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 19 Hours ago by: Andrey Tarasevich

To put it into a more compact and concise form: Consider this little piece of code // Class `B` is a base class of `D` Derived *d = new D; Base *b = d; // Is `b` the same as `d` numerically? // Is (std::uintptr_t) b ==

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 20 Hours ago by: Andrey Tarasevich

That's incorrect in general. Again, using x86 as a counterexample: Implementations that use different representations for virtual vs. non-virtual member pointers (GCC, Clang) manage to stuff that extra information into the "original" m

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 20 Hours ago by: Andrey Tarasevich

I am. That's true. However, some implementations do use different internal pointer representations for pointers that happen to point to virtual functions, while some other implementations don't. It depends on the chosen approach. *

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 20 Hours ago by: Marcel Mueller

I am in doubt whether the constexpr evaluator will ever enter the code generation stage. Probably it is just an interpreter which operates directly on the internal execution trees. This will run some orders of magnitude slower. In most

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 20 Hours ago by: Richard Damon

Yes that sort of describes the problem. The pointer to member needs to be able to refer to a virtual function, or even a function that is a member of a virtual base class, and handling that sort of stuff is what forces the extra memory

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 21 Hours ago by: Tim Rentsch

I don't have answers for your questions, but I did play around with this a little bit, enough to offer some ideas for what they might be worth. Disclaimer: my version of gcc is almost certainly less advanced than yours, so that may have

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 5 Days 21 Hours ago by: Tim Rentsch

The short answer to this question is no. That seems obvious to me, but let me try to give a more complete explanation. When talking about floating point, the C standard uses the terms range and precision in relation to aspects of eleme

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 21 Hours ago by: Alf P. Steinbach

Just an example of what you're saying: #include <stdio.h> struct A { void foo() const { printf( "A::foo\n" ); } virtual void bar() const { printf( "A::bar\n" ); } }; struct B: A { void bar() const override { printf( "B:

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 5 Days 21 Hours ago by: Juha Nieminen

Without knowing how regex_search() is internally implemented, I suppose it's possible it's overflowing the stack if, for some reason, it's a recursive implementation and the input is so large that it causes a recursion that's too deep. I

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 21 Hours ago by: Alf P. Steinbach

I discovered that g++ diagnoses the `goto` as invalid in a `constexpr` function. Earlier I only compiled the code with MSVC, which accepted it. I.e. `goto` is apparently not appropriate in this context. Mea culpa. :( - Alf

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 5 Days 22 Hours ago by: Juha Nieminen

I'm not sure that's correct. When you have a pointer-to-member, in the location of the call the compiler doesn't know *which* member function it's pointing to. It only knows its signature, not its name. The class may have several differe

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 5 Days 22 Hours ago by: Juha Nieminen

There may indeed be a bit of confusion in concepts at play here. After all, there are three stages of compilation at which precision of a floating point literal plays a role: In the ascii representation of the value in the source code, th

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 23 Hours ago by: Alf P. Steinbach

That's a circular argument, starting with observing that this code is correct, and that the choice of signed or unsigned as type for all values in it doesn't matter technically, and concluding that that means that the choice couldn't m

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 5 Days 23 Hours ago by: Malcolm McLean

Most integers are inherently non-negative, usually because they count things or index things. So it's natural when using a language that allows both signed and unsigned types to think that "unsigned" is designed to cover this type of usage

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 6 Days ago by: David Brown

True, but the check is pretty harmless. (Note that in generated code, where efficiency is important, these kinds of checks will be optimised into a jump by the compiler.) Yes. I realise there are good points to the "goto" here. I

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 6 Days 2 Hours ago by: Alf P. Steinbach

The `goto` here * removes a needless check with `if` (desirable), and * reduces the scope of the loop variable (desirable), because * it expresses a state directly by execution position (desirable) instead of in the relation between t

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 6 Days 2 Hours ago by: David Brown

That is, at best, a very subjective viewpoint. Your code is different, and I am sure that to /your/ eyes it is more "self-describing" - but I doubt if it is significantly clearer for anyone else. (Stepping through the prime candidate

Re: Constexpr evaluation of heavy stuff (thread)

comp.lang.c++

Posted: 6 Days 5 Hours ago by: Alf P. Steinbach

Not what you're asking (which I think is important! but alas have no answer), but consider disregarding silly context independent herd opinion about what language and library features should and should not be used, and just use the fea

Constexpr evaluation of heavy stuff

comp.lang.c++

Posted: 6 Days 13 Hours ago by: Andrey Tarasevich

Hello Just for the sake of experiment I tried this #include <array> template <std::size_t N> constexpr auto collect_primes() { std::array<unsigned, N> primes = { 2, 3 }; std::size_t n_primes = 2; for (unsigned i

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 6 Days 14 Hours ago by: Andrey Tarasevich

The `p0 == p1` comparison does not really demonstrate anything, since both pointers are `0xDEADBEEF` at this point anyway. Yes, but that a consequence of the same process that turned `0` to `0xDEADBEEF` in the initialization. Such com

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 6 Days 18 Hours ago by: Chris M. Thomasson

Iirc, even if nullptr is defined to be something like 0xDEADBEEF, it will still work when compared to 0. So: void* p0 = nullptr; void* p1 = 0; p0 == p1 and (p0 == 0 && p1 == 0) is true.

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 6 Days 22 Hours ago by: Paavo Helde

Doesn't it just mean that in the program code, one can write the literal with more precision than needed, just in case the type may have more precision in another or future implementation? const double pi = 3.14159265358979323846264338

Re: What's the following program's purpose ? (thread)

comp.lang.c++

Posted: 6 Days 22 Hours ago by: Bonita Montero

You're a squealer. And I didn't post an answer but I contradicted some allegiations.

Re: What's the following program's purpose ? (thread)

comp.lang.c++

Posted: 6 Days 22 Hours ago by: Öö Tiib

You already posted the answer yourself yesterday stack overflow. https://stackoverflow.com/questions/72275588/reading-a-pdf-from-a-foreign-process

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 6 Days 22 Hours ago by: Tim Rentsch

That is one possibility, but I didn't mean just that. Here is the original context: long double value = 0.1; I'm not sure what C++ allows or doesn't allow for the value of the literal 0.1. For C, my understanding is that the curr

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 6 Days 23 Hours ago by: Tim Rentsch

My statement is not about what compilers do but only about what the respective standards allow.

What's the following program's purpose ?

comp.lang.c++

Posted: 7 Days 1 Hour ago by: Bonita Montero

What's the following program's purpose ? The winner gets one billion old Reichsmark ([*]). #include <Windows.h> #include <iostream> #include <vector> #include <charconv> #include <cstring> #include <vector> #include <stdexcept> #in

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 7 Days 1 Hour ago by: Manfred

I believe Tim was referring to the fact that the standard does not mandate for long double to have more precision than double.

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 7 Days 1 Hour ago by: Jivanmukta

The problem not occurs and my program runs fine if I set: ulimit -s unlimited.

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 7 Days 2 Hours ago by: Jivanmukta

The problem stack-oveflow occurs in different places in my code (during sequence of tests). There's a long list of #... 0x... in ... and SUMMARY. Tail: #248 0x59a22d in std::__detail::_Executor<__gnu_cxx::__normal_iterator<char co

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 7 Days 3 Hours ago by: Andrey Tarasevich

No, that's incorrect. This has nothing to do with virtual functions. On the contrary, pointers-to-virtual-functions are "easy": regular virtual call mechanism itself is already required to incorporate all necessary mechanics to proper

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 7 Days 4 Hours ago by: Juha Nieminen

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 7 Days 4 Hours ago by: Jivanmukta

I failed to reproduce problem in isolated test program. #include <string> #include <iostream> #include <fstream> #include <regex> using namespace std; int main() { ifstream in("test.txt" /* very big text file */, std::ifstream::in);

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 7 Days 8 Hours ago by: Juha Nieminen

If you have a reference or pointer to an object of type class A, and a member pointer to a member function of class A, which is virtual, if the actual object pointed to is of some derived type B which has its own specialization of that vi

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 7 Days 8 Hours ago by: Juha Nieminen

AFAIK no C/C++ compiler will second-guess the programmer and assume that the literal was meant to be a long double literal. If you specify a literal of type double, the compiler will assume you meant it (and will just convert it to double

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 7 Days 12 Hours ago by: Andrey Tarasevich

I provided an example sample in adjacent message in this thread. Pointer `pfb2` in that example will have non-zero offset stored in it.

Re: Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 7 Days 15 Hours ago by: Scott Lurndal

An offset is stored in the high bytes so that 'this' can be adjusted in the thunk (that sets the implicit first parameter 'this' when calling the function) when the function pointer refers to a virtual function implemented in a derived cl

Function pointer size (was Re: nullptr is not 0) (thread)

comp.lang.c++

Posted: 7 Days 16 Hours ago by: Vir Campestris

:O I just experimented. Yes, it's 16 bytes, while an ordinary function pointer is only 8 (Linux 64, g++). But the top 8 bytes always seem to be zero. When are they anything else? Because if they aren't there's no reason for the diffe

Re: Vector Fractal Bloom... (thread)

comp.lang.c++

Posted: 7 Days 18 Hours ago by: Chris M. Thomasson

Oh shit. I forgot about that! God damn it. Here is the anatomy: https://www.deviantart.com/fractallife247/art/Alien-Anatomy-528901181 Here is the face: https://www.deviantart.com/fractallife247/art/Take-us-to-your-Leader-bw-492587462

Re: Vector Fractal Bloom... (thread)

comp.lang.c++

Posted: 7 Days 22 Hours ago by: Tony Oliver

On a sign-in page? No.

Re: vector::operator[] problem in line which does not use (thread)

comp.lang.c++

Posted: 7 Days 23 Hours ago by: Jivanmukta

I changed IDE from VSCode to VSCodium. In VSCodium debugging works fine. The problem does not occur in VSCodium. Problem closed.

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 7 Days 23 Hours ago by: Ben

Yes, of course. Sorry for the noise. I was thinking about the more general case, not the case of a literal.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 8 Days ago by: Tim Rentsch

Because James is talking about what is said in the C++ standard, what "O(n)" means is the same as what is meant in the standard.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 8 Days ago by: Tim Rentsch

There's an important difference between what I said and saying Alf's (now missing) statement is an insult. I don't doubt that you feel insulted, but I still wouldn't say Alf's statement is an insult.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 8 Days ago by: Tim Rentsch

I don't know what kinds of statements you might have trouble understanding. My comment was only about James's statements, not about whether you understood them. Since I don't think his statements are meaningless I wouldn't call them m

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 1 Hour ago by: Tim Rentsch

But that doesn't change the problem of potential loss of precision, because the representation (and hence the particular value) of the constant 0.1 is chosen before that value is converted to long double. The constant 0.1, being of type

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 1 Hour ago by: Paavo Helde

Yes, and what happens when 0.1 is converted to long double (assuming long double is larger than double)? You will get a wrong value 0.100000000000000005551 instead of the intended more precise value 0.100000000000000000001

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 2 Hours ago by: Ben

7.4 Usual arithmetic conversions (1.2) — If either operand is of type long double, the other shall be converted to long double.

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 2 Hours ago by: Ben

In Nim, literals have iXX appended (3i16 for example). As is so often the case, there's a bunch of implicit conversions to make writing arithmetic expressions easier. Haskell does not do any implicit conversions, much to the consternat

Re: vector::operator[] problem in line which does not use (thread)

comp.lang.c++

Posted: 8 Days 4 Hours ago by: Jivanmukta

Reinstalling gdb and VSCode didn't help.

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 4 Hours ago by: Juha Nieminen

Does it support integers of different sizes (8-bit, 16-bit, 32-bit, 64-bit...)? If yes, how do you specify which type of integer you want? The standardization committee seems to have this weird attitude towards new reserved keywords, wh

Re: vector::operator[] problem in line which does not use (thread)

comp.lang.c++

Posted: 8 Days 5 Hours ago by: Jivanmukta

Possible. The problem does not occur when compiling from command line. But I need debugger anyway, because my program does not work correctly and I need to make it correct.

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 6 Hours ago by: Christian Gollwitzer

Yes, indeed, I was thinking about other languages with static typing (Python does have strong typing, but it's dynamic). For example, have a look at Nim: https://nim-lang.org/ It looks similar to Python, but it uses type inferencing to

Re: vector::operator[] problem in line which does not use (thread)

comp.lang.c++

Posted: 8 Days 6 Hours ago by: Jivanmukta

And here is code of get_next_line_with_tokenized(). Variable tokenized_lines is vector<string>. bool source_file::get_next_line_with_tokenized(string &line, string &tokenized_line) { line = tokenized_line = ""; if (get_next_line(line)

Re: vector::operator[] problem in line which does not use (thread)

comp.lang.c++

Posted: 8 Days 7 Hours ago by: Paavo Helde

} This line suggests this is some call made from gdb, not your program. Maybe VSCode is trying to evaluate something under your cursor (never used VSCode so not sure what it is capable of). Either that, or the program has corrupted its

Re: vector::operator[] problem in line which does not use vector (thread)

comp.lang.c++

Posted: 8 Days 7 Hours ago by: Jivanmukta

Here is code of get_next_line(). Variable source_lines is vector<string> but trace "inside get_next_line" is not displayed. bool source_file::get_next_line(string &line) { // get next source line (only PHP code) TRACE("inside get_nex

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 8 Hours ago by: Juha Nieminen

It's easy to make such mistakes, and not just in variable initialization, but also pretty much anywhere where a literal is used, like: x = y * 0.1; // If x and y are long double, precision is lost It's also a good reason to never us

Re: vector::operator[] problem in line which does not use (thread)

comp.lang.c++

Posted: 8 Days 8 Hours ago by: Alf P. Steinbach

If eyes fail, why not use an editor to search for the word "vector" in that avalanche of diagnostics? By the way, not what you're asking, but you can save yourself and maintainers a lot of work by passing by reference instead of passin

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 13 Hours ago by: Ben

I doubt CG was referring to Python since it does no type inference. He may be thinking of languages like Haskell that are strongly typed but include very effective type inference. Of course I don't think C++ can or should go down that

Re: vector::operator[] problem in line which does not use (thread)

comp.lang.c++

Posted: 8 Days 14 Hours ago by: Lynn McGuire

Need way more code. Lynn

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 14 Hours ago by: Ben

That's why I was agreeing with you. (You saw my "yes" I presume). I was disagreeing with this: "However even then you had to designate a declaration as a declaration by specifying at least a qualifier or a storage class specifier.

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 14 Hours ago by: Paavo Helde

You mean sloppy languages, not modern. At the same time, these sloppy languages are currently trying to move closer to strictly typed languages, as - surprise-surprise - sloppy code is not so easy to maintain. That's why you can now wr

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 15 Hours ago by: Andrey Tarasevich

Yes, but in both cases these are contextually forced to be interpreted as declarations. So, the point still stands: even in old C one had to introduce a variable before being able to use it. There was no ambiguity between declarations

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 15 Hours ago by: Ben

Not always. Yes, and (ironically, given the suggestion for "implicit auto" in C++) it was often auto that was used. We have auto today because of implicit int of old. You could at file scope. Yes, but you didn't need anything but

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 16 Hours ago by: Andrey Tarasevich

However even then you had to designate a declaration as a declaration by specifying at least a qualifier or a storage class specifier. You could say const x = 1; /* relies on "implicit int" */ but you could not just say x = 1;

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 16 Hours ago by: Christian Gollwitzer

OK I suspected something like this. However, if that means I'd have to write the ridiculously complex const auto x = of_type_<long double>( 0.1L ); instead of long double x = 0.1L; or even auto x = 0.1L; I'm questioning

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 16 Hours ago by: Manfred

It is meant to give a compile time error if the initializer expression has a different type than the variable to be initialized.

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 17 Hours ago by: Christian Gollwitzer

That's how I see it. 0.1 is a double constant and since 1/10 can't be represented exactly in binary (assuming binary floats), the value in "value" is not the closes approximation to 0.1 possible, which is 0.1L. Also you wouldn't get a

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 18 Hours ago by: Alf P. Steinbach

Re #5, I guess that the problem with long double value = 0.1; .... is that when `long double` doesn't have the same representation as `double`, one may get a less precise value than with long double value = 0.1L; Is that it

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 18 Hours ago by: Christian Gollwitzer

Thank you for the nice quiz. #5 and #11 are the only ones I could immediately see, because I'm doing numerical math in C++. I haven't tried compiling the other samples, but this will hopefully be instructive. Christian

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 19 Hours ago by: Andrey Tarasevich

It would make a lot of sense to explicitly label each question as C++ or C questions. Weird question... Standard itself does not directly permit `$` in identifiers, but implementations are allowed to be more permissive. "Problem"? D

Re: const and O(N^2), non-const, or mutable? (thread)

comp.lang.c++

Posted: 8 Days 19 Hours ago by: Juha Nieminen

Not if indexing is a linear-time operation. (There's a reason std::list and std::set don't provide indexing. (std::map kind of does, but it's not really the same thing.)) How does indexed access solve that problem any better?

vector::operator[] problem in line which does not use

comp.lang.c++

Posted: 8 Days 19 Hours ago by: Jivanmukta

/usr/include/c++/9/debug/vector:427: In function: std::__debug::vector<_Tp, _Allocator>::reference std::__debug::vector<_Tp, _Allocator>::operator[](std::__debug::vector<_Tp, _Allocator>::size_type) [with _Tp = std::__

Re: const and O(N^2), non-const, or mutable? (thread)

comp.lang.c++

Posted: 8 Days 20 Hours ago by: Malcolm McLean

The whole point of the C++ parser is that it's nice to use. It sits on top of a C JSON parser written by someone else. It's nicer to access an array via indexing than via an iterator. Also, JSON allows mixed type arrays, which causes prob

Re: const and O(N^2), non-const, or mutable? (thread)

comp.lang.c++

Posted: 8 Days 20 Hours ago by: Juha Nieminen

Does the user need to access the elements via indexing? Would a forward iterator be enough? (Or a two-way iterator if it's a doubly-linked list.) At a minimum provide an iterator so the user can efficiently traverse the list. (With the p

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 20 Hours ago by: Juha Nieminen

When I originally posed the problem, I had just 'char', but then someone pointed out that a mere 'char' could be signed or unsigned, which is true. My intent was for it to be signed, so I explicitly specify it as such. This is actually a

Re: C++ (and some C) quiz questions (thread)

comp.lang.c++

Posted: 8 Days 22 Hours ago by: Paavo Helde

I believe I got two wrong, #12 really surprised me and in #10 I misread "signed char" as "unsigned char". With #7 I have bitten myself in the past, repeatedly. I finally ended up with writing and using an equivalent of strerror() which

Re: const and O(N^2), non-const, or mutable? (thread)

comp.lang.c++

Posted: 9 Days ago by: Malcolm McLean

It would entail a complete refactor of code which works and does its job in shipped applications. The calling code cannot alter the array. It's a parser, not an object. (In fact it's quite easy to generate JSON from C++ structures, the h

Re: const and O(N^2), non-const, or mutable? (thread)

comp.lang.c++

Posted: 9 Days ago by: Bo Persson

How about an iterator interface instead of operator[] ? The iterator knows its current position and can be incremented cheaply.

Re: const and O(N^2), non-const, or mutable? (thread)

comp.lang.c++

Posted: 9 Days ago by: Juha Nieminen

Is the data being stored in a linked list non-negotiable? If it were stored in an array (or even a std::deque) it would solve the problem nicely (and make it efficient regardless of how the calling code wants to access the contents). If

const and O(N^2), non-const, or mutable?

comp.lang.c++

Posted: 9 Days 1 Hour ago by: Malcolm McLean

I've got a JSON parser. The JSON is turned into a linked list. Then there's a nice C++ interface built on top. Arrays can be accessed via an overloaded [] operator. Now Most of the time, callers are likely to iterate through an array from

C++ (and some C) quiz questions

comp.lang.c++

Posted: 9 Days 1 Hour ago by: Juha Nieminen

In another forum I have, over the years, come up with C++ (and C) quiz questions. Some of these may showcase the (perhaps needless) complexity of the language, but anyway. How many could you answer without looking it up? -----------------

Re: Vector Fractal Bloom... (thread)

comp.lang.c++

Posted: 9 Days 6 Hours ago by: Chris M. Thomasson

or some reason, you are not the only one who thinks that. Humm... Check this one out: http://siggrapharts.ning.com/photo/take-us-to-your-leader Can you see some sort of insect like face in there? Mantis like? I even rendered some of i

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 9 Days 7 Hours ago by: Juha Nieminen

One has to be quite careful with the wording used, though. "at most O(n)", "on average O(n)" and "amortized O(n)" can mean quite different things. Also things like "O(n) element comparisons" can insiduously hide the allowance of doing m

Re: How static objects are created using double-checked locking (thread)

comp.lang.c++

Posted: 9 Days 8 Hours ago by: Bonita Montero

That's not what I'm talking about.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 9 Days 9 Hours ago by: James Kuyper

On 5/15/22 21:30, Alf P. Steinbach wrote:

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 9 Days 11 Hours ago by: Alf P. Steinbach

You know that I have no trouble understanding the literal meaning. It's meaningless drivel, though. If you don't understand that, then any contribution you make here is just more noise. Your opinion of his preference in argumentati

Re: Available C++ Libraries FAQ (thread)

comp.lang.c++

Posted: 9 Days 14 Hours ago by: Chris M. Thomasson

I wonder how many of these are on vcpkg; never used it yet... https://vcpkg.io/en/index.html

Re: How static objects are created using double-checked locking (thread)

comp.lang.c++

Posted: 9 Days 17 Hours ago by: Chris M. Thomasson

[...] It's been a while since I have created a double checked lock. 20+ years ago. Iirc, it went something like: // pseudo code struct foo { }; foo& get_foo() { static atomic<foo*> lptr(nullptr); foo* ptr = lptr.load(memory_

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 9 Days 22 Hours ago by: Tim Rentsch

James's response is not meaningless. It is a bit sloppy in places in how it uses big-O notation, but it is not meaningless. If you have trouble understanding what he means I suggest asking a question. It's hard to see this comment as

Re: How static objects are created using double-checked locking (thread)

comp.lang.c++

Posted: 10 Days 2 Hours ago by: Bonita Montero

Sorry, I set the number of threads to 100, wich doesn't make sense because I only have 2 * 64 threads. So set the number of threads to the number of logical cores in the system.

How static objects are created using double-checked locking

comp.lang.c++

Posted: 10 Days 3 Hours ago by: Bonita Montero

Static objects inside functions are created atomically since C++11. The only efficient way to to that is double-checked locking. I asked myself if the mutex for the object-creations is shared among all threads, which I supposed to be likel

Available C++ Libraries FAQ

comp.lang.c++

Posted: 10 Days 14 Hours ago by: Nikki Locke

Available C++ Libraries FAQ URL: http://www.trumphurst.com/cpplibs/ This is a searchable list of libraries and utilities (both free and commercial) available to C++ programmers. If you know of a library which is not in the list, why not

Re: SDL_C++ error scope (thread)

comp.lang.c++

Posted: 10 Days 18 Hours ago by: Heitber_Andrés_Mont

https://drive.google.com/file/d/1fELZNaUeA5VjIQR6yiHQrD2Ams-esrdx/view?usp=sharing

Re: SDL_C++ error scope (thread)

comp.lang.c++

Posted: 10 Days 18 Hours ago by: Heitber_Andrés_Mont

#include <SDL2/SDL.h> #include <stdio.h> #include <stdlib.h> #if defined (_WIN32) || defined(_WIN64) #define WIN32_LEAN_AND_MEAN #include <windows.h> #endif // WIN32 #if defined(__APPLE__) && defined(__MACH__) #include <OpenGL

Re: PDEP / PEXT intrinsics (thread)

comp.lang.c++

Posted: 10 Days 18 Hours ago by: Bonita Montero

Now I modified it to an iterating version having more and more one -bits in the mask, beginning from the LSB, and the result is: the more ones you have the higher the latency. The numbers in Agner's table are the times for a zero mask and

PDEP / PEXT intrinsics

comp.lang.c++

Posted: 10 Days 22 Hours ago by: Bonita Montero

There are two instructions called PDEP and PEXT on x86, introduced with Intel Haswell, which scatter or gather certain bits of a source operand to a destination operand: https://www.felixcloutier.com/x86/pdep https://www.felixcloutier.c

Re: SDL_C++ error scope (thread)

comp.lang.c++

Posted: 11 Days 3 Hours ago by: Alf P. Steinbach

The code appears to have been jumbled by inadvertent editing, lines moved out of place; perhaps there are also lines outright missing now. Go back to source and find correct code. Cheers, - Alf

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 11 Days 3 Hours ago by: Alf P. Steinbach

That's a meaningless response. I guess by design. - Alf

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 11 Days 5 Hours ago by: Juha Nieminen

Did you even read what I wrote?

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 11 Days 7 Hours ago by: James Kuyper

It's not obvious what the actual problem is. If you could provide a simplified version of your program that demonstrates the failure, that would be a big help. Here's a systematic process for simplifying your code: 1. Start with a progr

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 11 Days 9 Hours ago by: James Kuyper

On 5/13/22 12:34, Alf P. Steinbach wrote:

SDL_C++ error scope

comp.lang.c++

Posted: 11 Days 9 Hours ago by: Heitber_Andrés_Mont

(lines 143 and 184) if there's someone who knows about sdl and opengl it would be useful to get your help: here's the code: #include <SDL2/SDL.h> #include <stdio.h> #include <stdlib.h> #if defined (_WIN32) || defined(_WIN64) #define

extremally stupid error

comp.lang.c++

Posted: 11 Days 11 Hours ago by: fir

write my compiler and i got some rutine RunFrame { DrawLine3d 20.0 30.0 40.0 100.0 0.0 400.0 0xaaaa77 DrawLine3d 22.0 30.0 43.0 130.0 0.0 400.0 0xaaaa77 DrawLine3d 29.0 30.0 42.0 130.0 0.0 400.0 0xaaaa77 } I got 3 routines that

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 11 Days 17 Hours ago by: Chris M. Thomasson

Flip a coin; heads left, tails right. Heads, try to pop from left. Tails, try to pop from right. Just joking around here, in a sense... ;^) Actually, back in the day with my threading work, I have subdivided a lock-free stack into re

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.theory

Posted: 11 Days 19 Hours ago by: olcott

Simply extend the definition of the member function. Maybe std::deque performs better at this?

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 11 Days 20 Hours ago by: Alf P. Steinbach

By that logic it can be described as O(n^2 ). And it's within the formal definition of big O notation. However, using it that way would be very misleading so it's not done; there is an understanding that the big O communicates somethin

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.lang.c++

Posted: 11 Days 20 Hours ago by: Paavo Helde

My only usage of std::deque is for various FIFO message buffers. This means elements are only ever pushed with push_back() and popped with pop_front(). Somehow I have a feeling your deque would not be up to the task.

Re: Implementing a two-way Turing Machine tape as an improvement to std::deque (thread)

comp.lang.c++

Posted: 11 Days 20 Hours ago by: Ben

This is not a deque. Test before you post!

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.theory

Posted: 11 Days 20 Hours ago by: Mr Flibble

Prove to me that you are not an idiot by explaining what happens if vector Left is empty, vector Right is non-empty and you call pop_front? Hint: as your design currently stands it will crash. /Flibble

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 11 Days 20 Hours ago by: Mr Flibble

And what happens if Left is empty, Right is non-empty and you call pop_front()? /Flibble

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.theory

Posted: 11 Days 20 Hours ago by: olcott

Prove that it doesn't.

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.theory

Posted: 11 Days 20 Hours ago by: olcott

// Tape_Type implements a two-way Turing machine tape. // Right contains Tape_Head >= 0 values (right expansion) // Left contains Tape_Head < 0 values (left expansion) // // Grows with Right.push_back() as Tape_Head increases above 0.

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.lang.c++

Posted: 11 Days 21 Hours ago by: olcott

Many are implemented class Tape_Type { public: typedef unsigned char tape_element; private: int Tape_Head = 0; // Can be negative std::vector<tape_element> Left; // Stores left expansion std::vector<tape_element>

Re: false sharing performance impact (thread)

comp.lang.c++

Posted: 11 Days 23 Hours ago by: Bonita Montero

clang-cl and clang++ under Windows also give descriptive typeid()-names. But for clang++ and g++ under Linux you must demangle the name yourself. This is the code: #include <iostream> #include <typeinfo> #if defined(__GNUC__) || defined(_

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 12 Days ago by: Jivanmukta

The problem occurs in regex.h file; at line const __ctype_type& __fctyp(use_facet<__ctype_type>(_M_locale)); I have segmentation fault. template<typename _Ch_type> struct regex_traits {

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 12 Days 2 Hours ago by: Jivanmukta

I meant regex_search() of course.

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 12 Days 2 Hours ago by: Juha Nieminen

I mean "-D_GLIBCXX_DEBUG"

Re: core dumped at regex_search() (thread)

comp.lang.c++

Posted: 12 Days 2 Hours ago by: Juha Nieminen

Are you sure it's regex_search that's the culprit and it's not just a symptom of a bug in your own code? (Out-of-bounds accesses and similar errors can have all kinds of weird effects, where the program doesn't crash or misbehave at the p

core dumped at regex_search()

comp.lang.c++

Posted: 12 Days 2 Hours ago by: Jivanmukta

I have a problem with regex_search function from standard regex library. I use gcc compiler in Ubuntu 20. I wrote PHP obfuscator in C++. Now I am testing my program with PHP source codes found in Internet. For example PHP project shoppi

Re: false sharing performance impact (thread)

comp.lang.c++

Posted: 12 Days 3 Hours ago by: Bonita Montero

#include <iostream> #include <typeinfo> using namespace std; int main() { auto fn = []<typename T>() -> double { return -1.0; }; using fn_t = decltype(fn); using deduced_member_t = decltype(&fn_t::template operator ()<int>); using m

Re: false sharing performance impact (thread)

comp.lang.c++

Posted: 12 Days 4 Hours ago by: Bonita Montero

BTW: how can I make bench_fn simpler ? I tried "double (bench_t::*)()" as a subtitute for decltype(&bench_t::template operator ()<true, atomic_type>) but it didn't work. I get a lot of type compiler errors in the definition of the array ben

false sharing performance impact

comp.lang.c++

Posted: 12 Days 4 Hours ago by: Bonita Montero

I've edited the en.wikipedia.org article about false sharing. The soucecode and the short paragraph below is mine. After writing the code for the Wikipedia-article I asked myself if false sharing is a noteworthy problem if the cacheline is

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 5 Hours ago by: tth

Not with any version of the C language.

Re: Implementing a two-way Turing Machine tape as an improvement to std::deque (thread)

comp.theory

Posted: 12 Days 5 Hours ago by: Mr Flibble

You are a fucking obtuse idiot, mate. /Flibble

Re: Implementing a two-way Turing Machine tape as an improvement to std::deque (thread)

comp.ai.philosophy

Posted: 12 Days 5 Hours ago by: Mr Flibble

You cannot implement all of std::deque's member functions meeting std::deque requirements using your chosen data structure of two std::vectors. /Flibble

Re: Vector Fractal Bloom... (thread)

comp.lang.c++

Posted: 12 Days 7 Hours ago by: Bonita Montero

That's an alien. I'll inform the agency.

Re: Implementing a two-way Turing Machine tape as an improvement to std::deque (thread)

comp.lang.c++

Posted: 12 Days 8 Hours ago by: Öö Tiib

That is opinion. Opinions are not useful as better std::deque. Writing better std::deque (than particular implementation) is matter of actually defining those member functions. It can't be done by arguing in Usenet that defining member

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 12 Days 9 Hours ago by: Öö Tiib

It is impossible goal to have generics that are optimal. Point of generics is to perform good enough, and reliably, not optimally. These were three random examples that can matter to performance followed with "etc." I did not profile

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 12 Days 10 Hours ago by: James Kuyper

On 5/12/2022 2:44 PM, Öö Tiib wrote:

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.theory

Posted: 12 Days 11 Hours ago by: olcott

It already has the same complexity. and better referential integrity.

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 11 Hours ago by: olcott

All these things can be added and we end up with a simple, faster, std:deque that has most the conventional overhead and complexity abolished. It just a matter of defining more member functions.

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.theory

Posted: 12 Days 11 Hours ago by: Mr Flibble

Not with your chosen data structure of two std::vectors it can't as it wouldn't meet the complexity and referential integrity requirements offered by std::deque. I have told you this three times now. /Flibble

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 11 Hours ago by: Mr Flibble

What you have does not offer what std::deque offers so is not equivalent to std::deque so can't be considered better than std::deque for the general case (I don't care about your specific use-case). /Flibble

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.theory

Posted: 12 Days 11 Hours ago by: olcott

That is a ridiculously stupid thing to say. It has the key most important functionality of a std:deque Double ended queue deque (usually pronounced like "deck") is an irregular acronym of double-ended queue. Double-ended queues are seq

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 12 Hours ago by: olcott

I could allow all elements to be popped from the front or the back too. Mine is much faster when you need far less than all elements.

Re: Implementing a two-way Turing Machine tape as an improvement to std::deque (thread)

comp.theory

Posted: 12 Days 12 Hours ago by: Ben

I've removed the philosophy group and comp.lang.c as this is C++. You will get critiques of the code on whatever basis people feel inclined to comment! You can't limit the comments to some particular context. It does not have any of

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: Mr Flibble

Then it is totally different to what std::deque offers: std::deque allows ALL elements to be either popped from the front or back. Try reading AND UNDERSTANDING what I wrote again. /Flibble

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: olcott

Mine words the same way and has the added benefit of contiguous storage. I don't think that this applies to the way that I implemented it. pop_front pops from the end of Left. pop_back pops from the end of Right. This is the key aspect

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: Mr Flibble

I see you are choosing to ignore my reply in the other thread. OK, I will repost why you are wrong here: * referential integrity and iterator invalidation are different things: when you add or remove elements to either end of a

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: olcott

It is faster then std::deque. I couldn't find what you mean by referential integrity it has too many different meanings. invalidating iterators seemed to be what you mean otherwise I have no idea.

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: olcott

Good catch. I just wrote that function as a simplification.

Re: Implementing a two-way Turing Machine tape as an improvement to std::deque (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: Richard Damon

Looks at what indexing with an index value of 0 does. Operator [] want to test index >= 0, not > 0

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: Mr Flibble

Because it doesn't meet the complexity and referential integrity requirements of std::deque. /Flibble

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: olcott

I didn't see any reason why it would not make a better std::deque.

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: Mr Flibble

It might be a more appropriate solution than std::deque for your specific use-case however it is NOT an improvement to std::deque for the general case -- see my reply in the other thread for why. /Flibble

Implementing a two-way Turing Machine tape as an improvement to

comp.ai.philosophy

Posted: 12 Days 14 Hours ago by: olcott

C/C++ people please critique this as the basis for an improvement to std::deque. It seems to have the key functionality of std::deque and does it much more simply while saving time and space. https://www.cplusplus.com/reference/deque/dequ

Re: Vector Fractal Bloom... (thread)

comp.lang.c++

Posted: 12 Days 17 Hours ago by: Chris M. Thomasson

Ahhh, SHIT! This was meant for sci.math. Sorry! ;^o

Vector Fractal Bloom...

comp.lang.c++

Posted: 12 Days 17 Hours ago by: Chris M. Thomasson

https://fractalforums.org/gallery/1612-120522191048.png

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 12 Days 20 Hours ago by: James Kuyper

On 5/12/2022 2:44 PM, Öö Tiib wrote:

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 12 Days 21 Hours ago by: Manfred

That would be Alf's proposal. Not my favorite, but sure part of the picture. This does not mean it shouldn't be its goal, right? It just has couple These two examples are a different matter: you can't have a std::deque without some

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 12 Days 21 Hours ago by: wij

What kind of library is supposed to be modified by application programmers? What library implementations should not keep complexity (including design complexity) to a minimum? Informationless. My opinion: The standard library is wha

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 13 Days ago by: Öö Tiib

Why the third, complex, alternative is missing? It is like that inter-list sequence splice causes next call to size() to be O(N) but after that one call to size() (or clear() or empty() that returned true) it turns subsequent calls to si

Re: Wouldn't it be nice ... (thread)

comp.lang.c++

Posted: 13 Days ago by: Bonita Montero

The former solution with a proxy-allocator had a problem with alloca-tions of n's >= 2 since each item allocated in a row would be aligned on a cacheline-boundary. Since the allocator-interface itself doesn't have a parameter to enforce a

Re: Wouldn't it be nice ... (thread)

comp.lang.c++

Posted: 13 Days 3 Hours ago by: Bonita Montero

I think this is the most universal solution for all containers: (I've stripped my personal allocator-concept) #pragma once #include <memory> #include <new> #include "allocator_concept.h" template<allocator_concept AllocatorBase> struct

Re: Wouldn't it be nice ... (thread)

comp.lang.c++

Posted: 13 Days 17 Hours ago by: Chris M. Thomasson

One little nit pick... They have to be aligned on a cacheline boundary, _and_ padded up to a multiple of a cache line.

Re: Wouldn't it be nice ... (thread)

comp.lang.c++

Posted: 13 Days 20 Hours ago by: Bonita Montero

I've deveoped some additional code. The program below shares a cacheline among the threads of a SMT-core. It fixes the threads with operating system dependent means on one core. It assumes a certain numbering of the hardware threads on th

Re: Wouldn't it be nice ... (thread)

comp.lang.c++

Posted: 13 Days 21 Hours ago by: Bonita Montero

I've changed the code in the article to a C++20-example that shows a measurable effect of false sharing.

Re: Wouldn't it be nice ... (thread)

comp.lang.c++

Posted: 14 Days 3 Hours ago by: Alf P. Steinbach

Thanks, learned the term "false sharing". https://en.wikipedia.org/wiki/False_sharing - Alf

Wouldn't it be nice ...

comp.lang.c++

Posted: 14 Days 7 Hours ago by: Bonita Montero

.... to have a map<> and unordered_map<> with an additional bool template parameter to specify, that the nodes of either structures are aligned on a cacheline-boundary so that you might not have false sharing among other datastructures on

Re: Validating that the implementation meets the spec for TM (thread)

comp.theory

Posted: 14 Days 10 Hours ago by: olcott

Not in the least little bit. Please wait until you see my full implementation before passing judgement. David's solution is optimal. My implementation of David's solution essentially redefines the whole notion of std::deque with std:v

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 14 Days 19 Hours ago by: Manfred

This last bit is true, but there is more to the story, which I think is important: we are not talking about some list implementation for a specific application - something that anyone could do for the task at hand. This discussion is ab

Re: This code is effective for modest-sized numbers, but can you tell (thread)

comp.lang.c++

Posted: 14 Days 19 Hours ago by: Paavo Helde

One can argue that it's using of mismatching types in a comparison which means non-zero programming effort. If the types used in a comparison are of different types and especially of different signedness, the programmer needs to know

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 14 Days 19 Hours ago by: James Kuyper

On 5/10/22 11:55, Muttley@dastardlyhq.com wrote:

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 14 Days 20 Hours ago by: Alf P. Steinbach

The always-O(n) size alternatives are not really practical, as I see it. The IMO only reasonable alternative, let's call it alternative 0: * A number-of-values operation (could just be .size) is supported, with cached but possibly unkn

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 14 Days 20 Hours ago by: Muttley

And then you end up with a container where size() returns an incorrect value. How is that a good thing?

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 14 Days 22 Hours ago by: Tim Rentsch

[some snipped context restored] You asked a question. My response is an effort just to provide a simple, factual answer. Nothing more than that.

Re: This code is effective for modest-sized numbers, but can you tell what it does? (thread)

comp.lang.c++

Posted: 14 Days 22 Hours ago by: Scott Lurndal

I beg to differ. We include -Wall and -Werror on all compiles (well over 2 million lines of C/C++). It is far too common for C programmers to use 'int' when the domain of the value doesn't include negative numbers.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 14 Days 22 Hours ago by: Scott Lurndal

I've always preferred xpdf over evince. I really don't like evince.

Re: This code is effective for modest-sized numbers, but can you tell what it does? (thread)

comp.lang.c++

Posted: 14 Days 22 Hours ago by: Tim Rentsch

IME these warnings from gcc give false positives too often to be used on every single compile. Of course it can be useful to turn them on now and then, to make sure nothing is askew, but trying to avoid them even in all the false positi

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 14 Days 22 Hours ago by: James Kuyper

Nobody has claimed that it can't know. They are saying that it can't find out without taking O(n) operations, somewhere. There's three main options being discussed: Current standard: l.splice(position, x, first, last) takes O(N) time bec

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 14 Days 22 Hours ago by: James Kuyper

Annoying. The Evince Document Viewer that I'm using does not find a match to "contiguous container" when there's a line break separating the two words. I thought the exclusion of std::vector seemed odd.

Proof that H(P,P)==0 is correct [ refuting the halting problem proofs

comp.ai.philosophy

Posted: 15 Days ago by: olcott

(a) Verify that the execution trace of P by H is correct by comparing this execution trace to the ax86 source-code of P. (b) Verify that this execution trace shows that P is stuck in infinitely nested simulation (a non-halting behavior).

Re: nullptr is not 0 (thread)

comp.lang.c++

Posted: 15 Days 7 Hours ago by: Andrey Tarasevich

Pointers to member functions do need to store extra information to properly handle contra-variant conversions and calls in multiple-inheritance contexts. The language specification permits you to forcefully `static_cast` pointers to me

Re: std::random_device and multithreading (thread)

comp.lang.c++

Posted: 15 Days 7 Hours ago by: Juha Nieminen

I meant to say that the *initialization* of a function-local static is guaranteed to be thread-safe. (*Using* it is rather obviously not. Nor how the initialization value is calculated, because that's up to the programmer.)

Re: std::random_device and multithreading (thread)

comp.lang.c++

Posted: 15 Days 7 Hours ago by: Juha Nieminen

I somehow have the impression that the principle is that when the programmer is not given a choice about whether something is shared or not, it will be guaranteed to be thread-safe or thread-local (if it is indeed shared). For example yo

Re: nullptr is not 0 (thread)

comp.lang.c++

Posted: 15 Days 7 Hours ago by: Juha Nieminen

Isn't that true only for pointers to virtual functions (due to how they have to work)? Pointers to regular member functions wouldn't need any extra info. I don't know if there's anything in the semantics of the language, or some standard

Re: nullptr is not 0 (thread)

comp.lang.c++

Posted: 15 Days 14 Hours ago by: Scott Lurndal

With g++ on linux, sizeof(member function pointer) returns 16 bytes.

Re: Wow ... (thread)

comp.lang.c++

Posted: 15 Days 15 Hours ago by: Chris M. Thomasson

Nice. For some reason it kind of reminds me of a region allocator I did a while back: https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ https://pastebin.com/raw/f37a23918

Re: nullptr is not 0 (thread)

comp.lang.c++

Posted: 15 Days 15 Hours ago by: Andrey Tarasevich

Er... what? Virtually every single implementation out there has member function pointers of size different from regular pointers. This is more than "likely", this is basically _guaranteed_. It is very difficult (if at all possible) to

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 15 Days 15 Hours ago by: wij

Because many questions in the thread looked odd to me, my guess is that they may be from people did not have actually written a List class. Is this the goal of C++ standard library? I think yes. But C++ standard library cannot be respo

Re: nullptr is not 0 (thread)

comp.lang.c++

Posted: 15 Days 16 Hours ago by: Vir Campestris

_Likely_ not even the same size? I've worked on architectures where they aren't - some of the '286 models, for example - but it's not common, and I certainly wouldn't call it likely. Andy

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 15 Days 16 Hours ago by: Bo Persson

But counting them makes the operation O(n), which is not what we want. std::list has splice with (first, last)-patameters to move nodes from one list to another. Very fast if you only have to adjust a few pointers. Very slow if you the

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 15 Days 17 Hours ago by: Malcolm McLean

Of course it can. In fact, since size() is constrained to be O(1) it must do. However if you insert a long section of another list, you pass the start and one past the end pointers. Because it is a linked list, there's no way of knowing ho

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 15 Days 19 Hours ago by: Scott Lurndal

When I create linked lists (in C or C++) and I need to keep a count of the number of elements in the list, I keep a size_t in the listhead that is incremented by the insert/remove functions. I'm not sure why std::list (or perhaps a deriv

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 15 Days 20 Hours ago by: Andrey Tarasevich

I think it's been explained rather clearly already: spending O(n) to "know" it is prohibitively expensive. That's, again, the crux of the issue: if we don't know "the size of whats being inserted", we don't want to spend O(n) to calcul

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 15 Days 20 Hours ago by: Muttley

So why are certain people claiming a std::list won't always know the size of whats being inserted into it?

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 15 Days 20 Hours ago by: Manfred

22.3.11.1p2: "A vector meets all of the requirements of a container and ..., and, for an element type other than bool, of a contiguous container (22.2.1)." That makes for the requirement of random access, except for vector<bool>, quite

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 15 Days 20 Hours ago by: James Kuyper

Yes, std::distance<> does precisely that for iterators which are not random-access iterators (23.4.2p5). For such iterators, it is an O(n) algorithm.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 15 Days 20 Hours ago by: James Kuyper

On 5/9/22 05:02, Muttley@dastardlyhq.com wrote:

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 15 Days 21 Hours ago by: Muttley

Not really because there's obviously some way of counting them even if its inefficient. Perhaps iterate through them. Clues in the name.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 15 Days 21 Hours ago by: Andrey Tarasevich

Well, the very crux of the issue is that you can't do that [efficiently] with `std::list<>`s iterators. Subtraction is available for random-access iterators only. And `std::list<>`s iterators are bidirectional, not random-access. Even

std::random_device and multithreading

comp.lang.c++

Posted: 15 Days 21 Hours ago by: Andrey Tarasevich

Hello There are quite a few questions on the Net about using `<random>` in multithreaded environment, but virtually everything I find talks about sharing `std::random_device`, `std::mt19937`, etc. objects between threads. My question is

Re: Virtual base constructor arguments and constructor delegation (thread)

comp.lang.c++

Posted: 15 Days 23 Hours ago by: Manfred

I take your word for it, but to me it seems that a compiler that does that is a poor one, it's not that compilers that don't are smart. After all, all of the information that is needed to not make the call is clearly available at compil

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 16 Days 2 Hours ago by: Bo Persson

No, it does not work for std::list, as each node is allocated separately. For splice to work the elements are not required to be stored sequentially, like in a std::vector. Do you begin to see the problem now?

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 16 Days 3 Hours ago by: Muttley

Last time I looked you could subtract one iterator from another and get a difference. I presume that applies to std::list though I almost never use this container.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 16 Days 7 Hours ago by: Andrey Tarasevich

No. Neither. In C++98 it was _suggested_ that `std::list<>::size()` should be an O(1) operation, but not required ("should" , not "shall" in "Note A" in 23.1/5). The choice was ultimately left to the implementation. The implementation

Re: nullptr is not 0 (thread)

comp.lang.c++

Posted: 16 Days 7 Hours ago by: Juha Nieminen

Member function pointers shouldn't really be thought of as normal pointers. They are rather different beasts, behave differently in many respects, and you can't even convert from member-function-pointer to regular-pointer and back safely

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 16 Days 7 Hours ago by: Juha Nieminen

You don't need to know the length of the lists, or the list segments, for splicing (nor does the algorithm which I mentioned). std::list::size() was an O(n) operation in C++98, which allowed all splicing operations to be O(1). Then they

Re: nullptr is not 0 (thread)

comp.lang.c++

Posted: 16 Days 8 Hours ago by: Bonita Montero

I think that it would be the best that this offset-pointer is would be (size_t)1 << sizeof(size_t) * CHAR_BIT - 1. So it's likely that when you try to access an undefined member with a nullptr-"offset" you will land in kernel-space and yo

Re: Virtual base constructor arguments and constructor delegation (thread)

comp.lang.c++

Posted: 16 Days 14 Hours ago by: Alf P. Steinbach

In a correct program the dummy constructor is never called at run-time. Still, unless the compiler is smart, it may/will emit a call instruction, guarded by some boolean. Then the linker needs a definition. And with a definition it's

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 16 Days 14 Hours ago by: James Kuyper

If I'm bothering to cite the words of the standard, you can safely assume that I'm talking about the case where all of the other requirements of the standard are also met. While O(n) size() has been mentioned elsewhere in this thread, as

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 16 Days 18 Hours ago by: Malcolm McLean

In C you use linked lists mainly because resizing arrays is a nuisance. You have to maintain the size separately, then the reallocation can fail and that has to be handled, and all the internal pointers become invalid. To create a linked

Re: nullptr is not 0 (thread)

comp.lang.c++

Posted: 16 Days 19 Hours ago by: Andrey Tarasevich

Yes, that's a rather well-known example. Yes, null pointer value for such pointers is not zero. You can also declare such variables with static storage duration and the compiler will have to ensure it is not zero at startup. And so on.

Re: Virtual base constructor arguments and constructor delegation (thread)

comp.lang.c++

Posted: 16 Days 19 Hours ago by: Manfred

What's wrong with: class Interpolation { protected: // struct Dummy_init {}; Interpolation( ); // decl only public: Interpolation( const int count ) { ignore = count; } }; and get rid of all // Interpolation( Dumm

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 16 Days 20 Hours ago by: Manfred

This has already been answered in thread, but I'll recall it here next to your point: As long as you need a O(1) .size() method, you can't. If you allow for a O(n) .size() method (or, probably even better, you remove the .size() method

Re: nullptr is not 0 (thread)

comp.lang.c++

Posted: 16 Days 22 Hours ago by: Alf P. Steinbach

Best think of a data member pointer as an offset in the object that contains the member. Cheers, - Alf

nullptr is not 0

comp.lang.c++

Posted: 16 Days 23 Hours ago by: Sam

This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this mess

Re: Virtual base constructor arguments and constructor delegation (thread)

comp.lang.c++

Posted: 16 Days 23 Hours ago by: Sam

This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this mess

Re: Virtual base constructor arguments and constructor delegation (thread)

comp.lang.c++

Posted: 17 Days 3 Hours ago by: Marcel Mueller

Strictly speaking PolarFileInterpolation (and descendants) only uses Interpolation. So inheritance does not exactly hit the nail on the head. But it simplifies interaction because the derived class can easily add some missing parts by

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 17 Days 6 Hours ago by: Alf P. Steinbach

Well, as I wrote (but snipped here) /a single call to `.size()`/ brings the object to a stable state where it can be shared for reading. Plus that correct multi-threading is the responsibility of client code, not of each class that the

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 17 Days 9 Hours ago by: Andrey Tarasevich

Nope. I did not make such a broad assumption as the one you presented under #1. I simply implied that `size()` should not belong to the family of container methods that can trigger a data race.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 17 Days 14 Hours ago by: James Kuyper

On 5/7/22 12:12, Muttley@dastardlyhq.com wrote:

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 17 Days 19 Hours ago by: Alf P. Steinbach

Right, a reasonable C++11 implementation is a `mutable optional<Size>`, where `Size` is `ptrdiff_t`. That as I see it erroneous conclusion appears to build on three invalid assumptions: Assumption 1. Any `const` object of a standard

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 17 Days 20 Hours ago by: Andrey Tarasevich

Lazy evaluation of `size()` is a viable technique that nevertheless has its own set of issues. It is an operation that is "logically const" but not "physically const", since it has to updated its "size is known" state. In a single-thre

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 17 Days 20 Hours ago by: Alf P. Steinbach

Dear, you're trolling.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 17 Days 20 Hours ago by: Andrey Tarasevich

`splice` has multiple overloaded versions. And the version being discussed here is the one that really matters: `splice` that takes a pair of iterators into another list. So, no, it is not given a list, it is given a range of iterators

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 17 Days 20 Hours ago by: Muttley

splice() is a list method, not a standalone function. Its given the list to insert into itself. It can just take its size and add it to its own size. I don't see the problem.

Re: Virtual base constructor arguments and constructor delegation (thread)

comp.lang.c++

Posted: 18 Days ago by: Alf P. Steinbach

Strange use of `public` and `protected`, where from a client code of view a `PolarFileInterpolation` is not an `Interpolation`. Huh. While the details you sketch may be impossible the general idea is not impossible. Just the idea

Virtual base constructor arguments and constructor delegation

comp.lang.c++

Posted: 18 Days 1 Hour ago by: Marcel Mueller

class Interpolation {public: Interpolation(int count); // ... } class PolarInterpolation : public virtual Interpolation {public: PolarInterpolation(int count) : Interpolation(2*count) {} // ... } class FileInterpolation : pr

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 18 Days 2 Hours ago by: Alf P. Steinbach

With O(1) splice it doesn't know how many nodes are inserted unless it's told, and two of the splice overload don't tell it. These are the two overloads numbered (3) in the cppreference list at <url: https://en.cppreference.com/w/cpp/co

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 18 Days 4 Hours ago by: Muttley

Why wouldn't it always know its size? Or are you suggesting it can occasionally insert and delete without updating its element count?

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 18 Days 16 Hours ago by: Malcolm McLean

Often when we splice a list, we will know the size of the portion to be spliced, because we have previously traversed it. You could provide an O(1) splice that takes the size as a parameter. But if you go down that route, the library becom

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 18 Days 16 Hours ago by: Alf P. Steinbach

No no no. A `std::list` with O(1) other list splice can in most cases of ordinary usage know its size, and it can keep track of whether it knows or this time needs to count. This is a near cost free optimization (relative to overhead o

Re: Intersting ... (thread)

comp.lang.c++

Posted: 18 Days 16 Hours ago by: Chris M. Thomasson

[...] Fwiw, here is a new one: https://youtu.be/yZbO0314gRo

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 18 Days 19 Hours ago by: Andrey Tarasevich

The quoted text actually makes an extremely good and logical point. This is exactly why we have such "red flag" functions as `std::distance` and `std::advance` in standard library: as deliberately conspicuous indicators of potentially

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 18 Days 20 Hours ago by: Ben

Seems odd. The paper appears to be motivated entirely by practical concerns and Howard Hinnart is not an academic. He does not even have a CS degree (that's not criticism, just a point against your idea that it espouses an academic ide

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 18 Days 22 Hours ago by: Scott Lurndal

The practical engineer would simply code a linked list and be done with it.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 19 Days ago by: Alf P. Steinbach

E.g. as Howard Hinnant put it some time before C++11, in an article at <url: https://howardhinnant.github.io/On_list_size.html>: ❝As the standard is written today, none of the containers are required to have an O(1) size(). I believe

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 19 Days 1 Hour ago by: Ben

I'm familiar with the trade-off in abstract (since it crops up every time one implements a list as was so common in days gone by), but I did not know there had been a fight about it in C++. Curious that you put it like that. There doe

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 19 Days 2 Hours ago by: Ben

It's not /trivially/ constant time since, as has been pointed out, the spliced sub-list list needs to be scanned for length. I don't see how it could be constant time unless std::list::size's constraint were to be relaxed. Not in the

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 19 Days 4 Hours ago by: Alf P. Steinbach

I guess you're unfamiliar with the history. The fight was about the guaranteed complexity of `.size()`. With O(1) complexity a splice has to count the number of spliced nice, which turns a simple O(1) link manipulation into O(n) counti

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 19 Days 6 Hours ago by: Juha Nieminen

That's exactly the operation I was talking about: Splicing a segment of a list into another list. Which is (quite trivially) an O(1) operation when you have the necessary iterators (which in the algorithm I mentioned you have, at that poi

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 19 Days 16 Hours ago by: Ben

How much of your post does the smiley apply to? I don't want to waste everyone's time...

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 19 Days 17 Hours ago by: Alf P. Steinbach

With the choice of potentially O(n) `.size()`, instead of the silly C++11 decision, all splicing overloads could be O(1) and `std::list` could have been useful for something. Since the word "now" was used, that was surely what was bein

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 19 Days 17 Hours ago by: Chris M. Thomasson

Yeah, I am being rather intrusive here. Sorry everybody. ;^o

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 20 Days ago by: Ben

Obviously, but that's surely not what the OP was talking about. That one could never have been, and will never be O(1).

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 20 Days 1 Hour ago by: Öö Tiib

But don't you see BM does not want to talk about it. He uses unaligned accesses only in his single threaded software.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 20 Days 1 Hour ago by: Öö Tiib

It has 6 overloads. Most are O(1) but one case where we transfer iterator range from other list to this list is linear in length of said range.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 20 Days 3 Hours ago by: Ben

It's O(1) in C++11, 14 and 20 (at least in the public drafts).

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 20 Days 6 Hours ago by: Juha Nieminen

When I was working at the university here I once had to implement (a rather complicated and advanced) algorithm (which had something to do with graph manipulation) which required a doubly-linked list. No other data container would have do

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 20 Days 6 Hours ago by: Paavo Helde

This looks like what a normal memory allocator does anyway. This looks like a typical pool allocator. No need to reinvent the wheel. (It uses about 400 megs of RAM for an average source file). But anyway I use 'list' extensively to ma

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 20 Days 6 Hours ago by: James Kuyper

On 5/4/22 18:17, red floyd wrote:

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 20 Days 7 Hours ago by: Bonita Montero

That's not what I'm talking about.

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 20 Days 8 Hours ago by: Chris M. Thomasson

Straddling a cache line can case false sharing...

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 20 Days 8 Hours ago by: Bonita Montero

I'm talking about unaligned accesses and not false sharing.

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 20 Days 11 Hours ago by: Chris M. Thomasson

Have you ever had to deal with a false sharing bug? The program works, but it's slow..... Slower than a snail hiking up a mountain of salt? Well, shit.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 20 Days 14 Hours ago by: red floyd

Items can, in fact, be moved. If you push_back() on a vector whose size() is the same as its capacity(), the vector needs to be reallocated, and the data may therefore move and be copied/moved.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 20 Days 14 Hours ago by: Stefan Ram

When one uses a vector of pointers to objects, the objects are not moved when the size of the vector changes. Such a vector then can be used like a list, but tests have often shown the vector to be faster.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 20 Days 15 Hours ago by: Frederick Virchanza

I'm currently writing a "pre-compiler" that processes a translation unit and give output that can go into a normal C++20 compiler. In order to make it as fast as possible, I overloaded global new and delete so that memory is allocated

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 1 Hour ago by: Paavo Helde

I have hard time finding any use case at all for std::list. I know there is a use case for holding dynamically created global objects alive and at the same memory address, but globals are evil anyway, regardless of how they are held.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 2 Hours ago by: Muttley

I rather gave up on boost. C++ since 2011 does pretty much does everything I need but it perhaps not in this case.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 2 Hours ago by: Muttley

I'm quite capable of writing a bitmap class but given I'm writing an image recognition algo I have enough on my plate without having to write basic data storage classes. Very nice.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 2 Hours ago by: Juha Nieminen

What "standard"? The C++ standard defines how std::vector<bool> works, so it's pretty much "standard" by definition. What's special about it is that in a few aspects it doesn't work in the same way as other standard library data contain

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 2 Hours ago by: Juha Nieminen

Using std::vector<bool> is fine. If you can use Boost, you may consider using boost::dynamic_bitset. It has many utilities that std::vector<bool> doesn't have (and is ostensibly more efficient).

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 2 Hours ago by: Juha Nieminen

I have hard time thinking of a less efficient way to store a bitmap (at least using standard library containers).

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 2 Hours ago by: wij wij

Nearly all in C++ standard library are not necessary for average programmers (the first C++ years may partly need), they are small utilities (you learn real 'programming' skill or those deep engineering/artificial concepts/rules?). Anyon

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 3 Hours ago by: Muttley

Indeed. Aside from using a list to store individual bits seems silly, I also need something that does direct indexing which list obviously doesn't do.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 6 Hours ago by: Andrea Venturoli

Yes I did and it served me well. Just don't expect it can play nicely wherever a "real" vector class would, but if it's enough for your use case, go ahead.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 15 Hours ago by: Malcolm McLean

I used one today. I have two lists of open paths, and I want to join paths which abut each other. With special rules when you have two or more choices about which path to join to which. So I used a matrix of bools set to true for joinable

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 17 Hours ago by: Stefan Ram

(Some recommend repeating everything important from the subject in the body.) Yes, I see it, for example in |std::vector<bool> bound_; // stores which arguments were bound Boost "format_class.hpp" |std::vector<bool> in_S_star(num

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 17 Hours ago by: Keith Thompson

[...] Strictly speaking, it does fully conform to the standard, since the standard defines it. It doesn't fully conform to the requirements for vector<foo>. (IMHO it might have been better to define a vector_bool type that's not a speci

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 18 Hours ago by: Bo Persson

The only gotcha is that vector<bool> doesn't *fully* conform to the standard. A container, and its iterators, should be able to return a reference to the elements. But, of course, you cannot return a (real) reference to a single bit.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 19 Hours ago by: Manfred

Well, not. The OP wants compact & fast. List is not it.

Re: "New C++ features in GCC 12" by Marek Polacek (thread)

comp.lang.c++

Posted: 21 Days 20 Hours ago by: Alf P. Steinbach

I gave up on the MinGW (64) sites years ago. Ruben something used to provide a relatively up to date compiler but as I recall he stopped doing that. And then it was a real hassle getting a good version (there was even someone, probably

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 20 Hours ago by: Jack Lemmon

How about using List? <https://www.cplusplus.com/reference/list/list/> Not fast but dynamic in nature and vector modifiers and iterators can be used.

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 20 Hours ago by: Muttley

Advising against it is not the same as promoting it :)

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 20 Hours ago by: Muttley

To be fair, if I was going to roll my own I'd just use a C u_char array wrapped in a class but I can't be bothered to write all the boilerplate construct,set,unset,copy etc code, hence I was hoping to use vector<bool> directly if its no

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 21 Hours ago by: Stefan Ram

Don't hesitate to use ::std::vector< bool >! You might like to hide it behind an interface or a custom class; that way you can switch easily to another implementation if need be. (If you don't use an interface, you can also switch

Re: Anyone ever used vector ? (thread)

comp.lang.c++

Posted: 21 Days 21 Hours ago by: Ben

I'd wrap a std::vector<unsigned int> in a class so you can implement whatever access you want to the bits cleanly.

Anyone ever used vector ?

comp.lang.c++

Posted: 21 Days 21 Hours ago by: Muttley

I need to store ~70K images in memory as B&W bitmaps so any chance of reducing memory usage is a bonus. I've never used vector<bool> because of all the warnings that it doesn't play nice with other parts of the STL. Anyone know any differen

Re: "New C++ features in GCC 12" by Marek Polacek (thread)

comp.lang.c++

Posted: 21 Days 21 Hours ago by: Jack Lemmon

Which one do you recommend for Windows 10 from this page? <https://www.mingw-w64.org/downloads/> GNU site is the most difficult site to get any info straight away!

"New C++ features in GCC 12" by Marek Polacek

comp.lang.c++

Posted: 22 Days 9 Hours ago by: Lynn McGuire

"New C++ features in GCC 12" by Marek Polacek https://developers.redhat.com/articles/2022/04/25/new-c-features-gcc-12# "Version 12.1 of the GNU Compiler Collection (GCC) is expected to be released in April 2022. Like every major GCC rel

Re: top_level_regex_token_iterator - Don't match between nested (thread)

comp.lang.c++

Posted: 22 Days 11 Hours ago by: Richard Damon

And, in particular, regular expressions do not handle "nested brackets" to an arbitrary depth, and not well for even a small fixed depth unless you assume that the string has matching brackets.

Re: top_level_regex_token_iterator - Don't match between nested brackets (thread)

comp.lang.c++

Posted: 23 Days 7 Hours ago by: Juha Nieminen

Note that regular expressions are not all-powerful. They can't be used as universal parsers for any syntax you want. What they can match is limited. (I haven't checked if they can be used for this task. I'm just noting that.) Unless you

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 23 Days 7 Hours ago by: Juha Nieminen

Such as? So what? There are many third-party libraries that require C++11 and won't work in C++98 code. There are many that require C++17. How is this different from requiring C++20? "Third party libraries can be compatible with" is

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 23 Days 11 Hours ago by: Ross A. Finlayson

Isn't it a , ..., disk mount? "Oracle" I think is a "disk mount". What I mean by that is, ..., pretty usual in organization. The "store", say, .... Vis-a-vis the "core" -, .... Excuse, I basically live in events instead of process.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 23 Days 11 Hours ago by: Ross A. Finlayson

Is there a way to module the language features, I guess that is typetraits, I think typetraits in template, is for auto and ..., why ranges is any superscalar after iter: I think iter is sequential. Adding other features, besides, is

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 23 Days 13 Hours ago by: Scott Lurndal

Been there, done that. To complicate it further, we had a single-system-image across 64 nodes, all of which shared memory with varying latencies, and we supported pthread shared mutexes and other internal synchronization mechanisms thank

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 23 Days 20 Hours ago by: Muttley

Threads and processes and different use cases. Tightly coupled data processing would be better using threads. OTOH something that eg has to act as a TCP user connection server such as sshd is better off with seperate processes. Of course

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 23 Days 20 Hours ago by: Bonita Montero

Futexes can be easily used across process-boundaries. They also have some mechanisms that when a process crashes whith an owned futex it gives up the ownership on the futex automaticallly. But almost never makes sense to parallelize with

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 23 Days 21 Hours ago by: Muttley

Using mutexes between seperate processes is extremely useful but I'm glad I'm not the person who had to implement it as the code must be rather hairy under the hood given the processes could be executing on physically seperate CPUs, not

Re: This code is effective for modest-sized numbers, but can you tell (thread)

comp.lang.c++

Posted: 24 Days 15 Hours ago by: Manfred

I wouldn't assume this. If I had to implement a reverse iterator I might have to do something like that, for example because the standard gives guarantees about "one past the end" pointers, but not about "one before the beginning". Bu

Re: Intersting ... (thread)

comp.lang.c++

Posted: 24 Days 15 Hours ago by: Manfred

I'd say you are right. This is intuitive, however, looking at the standard: 6.8.4 "A type mentioned in 6.8.2 and 6.8.3 is a cv-unqualified type. Each type which is a cv-unqualified object type or is void (6.8) has three corresponding c

Re: top_level_regex_token_iterator - Don't match between nested brackets (thread)

comp.lang.c

Posted: 24 Days 16 Hours ago by: Stefan Ram

Newsgroups: comp.lang.c++,comp.lang.c Followup-To: comp.lang.c Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> writes: #include <stdio.h> void sink( char const * const start, char const * const top ) { for( char const * p = star

top_level_regex_token_iterator - Don't match between nested brackets

comp.lang.c++

Posted: 24 Days 17 Hours ago by: Frederick Virchanza

std::string const str("dog, cat, fish, (frogs,toads), monkeys, elephants, (lizards, amphibians<true,1>), sharks"); I want to split it by commas to get: dog cat fish (frogs,toads) monkeys elephants (lizard

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 24 Days 18 Hours ago by: Bonita Montero

No, it is. Serializing your data strcutures into a shared memory segment, having no absolute pointers, is a mess.

Re: This code is effective for modest-sized numbers, but can you tell (thread)

comp.lang.c++

Posted: 24 Days 19 Hours ago by: Andrey Tarasevich

Well... yes and no. Reverse iterators are intended to encapsulate the "offset by 1" idiom. In indexing terms it is equivalent to for (std::size_t i = v.size(); i > 0; --i) { // Remember to work with v[i - 1] instead of v[i]

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 24 Days 19 Hours ago by: Scott Lurndal

It is neither complex nor costly. Certainly not "very". For those lucky enough to use POSIX, mmap() is very useful for such sharing (e.g. MAP_FIXED if one must use pointers instead of offsets) and allows easy checkpointing of the shared

Re: This code is effective for modest-sized numbers, but can you tell (thread)

comp.lang.c++

Posted: 24 Days 19 Hours ago by: Andrey Tarasevich

No, no, no. There is an error in the last one indeed. It was supposed to be this for (std::size_t i = v.size() - 1; i != -1; --i) { ... } This is the correct version. It is intended to illustrate the fact that unsigned i

Re: This code is effective for modest-sized numbers, but can you tell (thread)

comp.lang.c++

Posted: 24 Days 19 Hours ago by: Manfred

However, what you really should do is: using MyVector = std::vector<int>; ... for (MyVector::reverse_iterator it = v.rbegin(); v.rend() != it; ++it) { ... }

Re: This code is effective for modest-sized numbers, but can you tell (thread)

comp.lang.c++

Posted: 24 Days 19 Hours ago by: Manfred

Change the last one to: for (std::size_t i = v.size(); i != 0; --i) { ... }

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 24 Days 20 Hours ago by: Muttley

Just a standard binary tree IIRC but it was a long time ago and my memory is hazy.

Re: This code is effective for modest-sized numbers, but can you tell (thread)

comp.lang.c++

Posted: 24 Days 21 Hours ago by: Andrey Tarasevich

If one needs to iterate in reverse one uses for (std::size_t i = v.size(); i > 0; ) { --i; ... } or for (std::size_t i = v.size(); i-- > 0; ) { ... } or even plain for (std::size_t i = v.size(); i

Re: This code is effective for modest-sized numbers, but can you tell (thread)

comp.lang.c++

Posted: 25 Days 2 Hours ago by: Malcolm McLean

If you need to interate in reverse for (int i = (int) v.size()-1; i >= 0; i--) you can't substitute a size_t. You can do size_t i = v.size(); while(i--) so there's a workaround.

Re: Intersting ... (thread)

comp.lang.c++

Posted: 25 Days 3 Hours ago by: David Brown

It's not "on the dumb side" - that is a perfectly good suggestion. Yes, they would lead to observable behaviour. (I'm no expert here either, but they say the best way to get a correct answer on the internet is to post an incorrect one.

Re: Intersting ... (thread)

comp.lang.c++

Posted: 25 Days 7 Hours ago by: Chris M. Thomasson

lol! Reminds me of the following scene where the joyful crab gets smashed by a buggy compiler... ;^) https://youtu.be/-529AApvcAc?t0 The compiler being the ship in red... ;) I need more trust in the compiler for extremely sensitive

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 25 Days 7 Hours ago by: Bonita Montero

The problem with synchonizing separate processes is that you have to serialize shared data structures scattered across your address space into your shared memory segments. And you can't use normal pointers since the logical addresses at wh

Re: Intersting ... (thread)

comp.lang.c++

Posted: 25 Days 9 Hours ago by: james...@alumni.calt

On Friday, April 29, 2022 at 10:46:49 PM UTC-4, Chris M. Thomasson wrote:

Re: Intersting ... (thread)

comp.lang.c++

Posted: 25 Days 9 Hours ago by: Chris M. Thomasson

Humm... Perhaps I will code up a hazard pointer based impl of something simple, like a lock-free stack in pure C++11. Fwiw, I had one in some older asm code of mine well before C11 std threads: http://web.archive.org/web/2006021411234

Re: Intersting ... (thread)

comp.lang.c++

Posted: 25 Days 10 Hours ago by: Chris M. Thomasson

The std::memory_order_seq_cst fence is meant to sync with the membars in the algorithms that actually use the hazard pointers, not shown in my example code of how to actually load a hazard pointer. As long as the fence emits a seq_cst

Re: Intersting ... (thread)

comp.lang.c++

Posted: 25 Days 12 Hours ago by: Chris Vine

I suspect you are missing the point, and my recollection is we had a previous set of postings on this same code a few years ago. In the case of the exchange of postings to which you refer, a particular compiler violated the requirements

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 25 Days 13 Hours ago by: Tim Rentsch

There are at least four differences between (in particular) ranges and a third-party library. One, there are some ranges-induced changes in the non-library portion of the C++ standard. Perhaps not very many, but some. Third-party libra

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 25 Days 13 Hours ago by: Tim Rentsch

Just out of curiosity, what kind of tree were you asked to rebalance? Or did they not say what kind (in which case you would get to pick)?

Re: This code is effective for modest-sized numbers, but can you tell what it does? (thread)

comp.lang.c++

Posted: 25 Days 13 Hours ago by: Tim Rentsch

Does this mean that if the loop variable 'i' had been given type 'long long' then you would have no complaints?

Re: Intersting ... (thread)

comp.lang.c++

Posted: 25 Days 16 Hours ago by: red floyd

on the dumb side... I'm nowhere near the language or threading guru that you guys appear to be. Is it possible to have either of the following? std::atomic<T> volatile somevar; or std::atomic<volatile T> somevar; If so, would either a

Re: Intersting ... (thread)

comp.lang.c++

Posted: 25 Days 16 Hours ago by: Chris M. Thomasson

True. Wrt the link to comp.programming.threads I posted, it was GCC working with POSIX threads, so it is part of the POSIX system, so to speak. Read the posts by David Butenhof in said thread. It performed an optimization that could br

Re: Intersting ... (thread)

comp.lang.c++

Posted: 25 Days 16 Hours ago by: Chris M. Thomasson

Okay. You basically summed it all up in this post. I understand.

Re: Uniform initialization ambiguity (thread)

comp.lang.c++

Posted: 25 Days 16 Hours ago by: Juha Nieminen

You sure? I'd say that the uniform initialization causes more problems than initializer lists. Initializer lists are cool because you can initialize objects in the same way as you would a C style array, using a simple syntax. I see less

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 25 Days 18 Hours ago by: Bonita Montero

It's magnitudes more messy because you don't have a shared address space. Race conditions and deadlocks are no issue if you know how to deal with C++'s synchronization mechanisms. According to what you say you've _never_ written MT-code

Re: Uniform initialization ambiguity (thread)

comp.lang.c++

Posted: 25 Days 19 Hours ago by: Alf P. Steinbach

I think you meant `= delete` for compile time detection, not a run time error. Probably a thinko (that's like a typo, brain on auto-pilot). Cheers, - Alf

Re: Uniform initialization ambiguity (thread)

comp.lang.c++

Posted: 25 Days 21 Hours ago by: Andrey Tarasevich

Since one of the parameters is a reference, I should probably also add a link to http://eel.is/c++draft/over.ics.list#9 which essentially boils down to applying the same rankings to the initialization of the required temporary obje

Re: Uniform initialization ambiguity (thread)

comp.lang.c++

Posted: 25 Days 21 Hours ago by: Andrey Tarasevich

Well, the rules for "List-initialization sequence [over.ics.list]" are rather convoluted http://eel.is/c++draft/over.ics.list but one can figure out that the initialization of to `std::string` is classified as "a user-defined conv

Re: Uniform initialization ambiguity (thread)

comp.lang.c++

Posted: 25 Days 23 Hours ago by: Öö Tiib

The initializer_list was IMHO worst thing of C++11 by large margin. The identity conversion takes precedence over user-defined conversion. Result can be confusing. Note that you get int version called also with foobar({'a'}) silently.

Re: Intersting ... (thread)

comp.lang.c++

Posted: 26 Days ago by: David Brown

I haven't read it all, but it is an example of the misunderstandings people often have about what is and is not "observable behaviour" in C. Prior to C11, C had no threading model. The language - and the compiler - can assume that the

Re: Intersting ... (thread)

comp.lang.c++

Posted: 26 Days 1 Hour ago by: Manfred

I haven't read the post, but that's besides the point, I believe. As it has been pointed out more than once in this thread, it may well be very hard for a compiler to optimize or reorganize code around atomics, and, conversely, it may

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 26 Days 1 Hour ago by: Öö Tiib

OK. I use std::set ultra rarely preferring boost::intrusive::set like mentioned above but lets say OK. You mean on plane? Graham scan did not use centroid, instead it took point with lowest y coordinate that has anyway to be part of

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 26 Days 3 Hours ago by: Malcolm McLean

You do quite often need to keep data sorted rather than to sort it. So a balanced binary tree is your data structure of choice, and C++ makes it easy to use one (std::set). However it's also quite common for some process to produce an unso

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 3 Hours ago by: Muttley

Much nicer. Don't know what the bakery algorithm is, will have to google, but that is the kind of code I'd expect. Not the use-every-C++-feature-I-can-think -of wankery that Bonita comes up with.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 3 Hours ago by: Muttley

" to run as operating system threads in separate address spaces" Whats that supposed to mean?

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 3 Hours ago by: Muttley

Watch those goalposts move. "No one" being you. Its can be far less messy than multi threaded because you only need to worry about where the processes interact , not the entire code where all the threads may interact in wierd ways. I'

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 26 Days 4 Hours ago by: Öö Tiib

All data is expected to be sorted/indexed and in rather multiple ways in modern applications. However sorting itself is rather rarely needed in modern C++. We have too lot of ways to keep our data constantly sorted/indexed. Hash tables a

Uniform initialization ambiguity

comp.lang.c++

Posted: 26 Days 4 Hours ago by: Juha Nieminen

void foobar(const std::string&); void foobar(const std::vector<int>&); and you try to call it like: foobar({}); you'll rather obviously get a compiler error because the call is ambiguous. There's no way for the compiler to

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 6 Hours ago by: Juha Nieminen

I don't think you understand the point I was making. One of the most common complaints, also prominently presented in this thread, is that when a library, like the ranges library, is added to the standard, that means that people who need

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 26 Days 9 Hours ago by: Bonita Montero

Totally different story ...

Re: Intersting ... (thread)

comp.lang.c++

Posted: 26 Days 13 Hours ago by: Chris M. Thomasson

[OT]: Fwiw, I have been working on other things using C++: https://youtu.be/HwIkk9zENcg https://youtu.be/heEPwsraZm4 Btw, do you know of a good usenet group for working with music? MIDI and WAV?

Re: Intersting ... (thread)

comp.lang.c++

Posted: 26 Days 13 Hours ago by: Chris M. Thomasson

Yeah, fair enough. I expect the compiler system to give me two loads and a store wrt the SMR example. It cannot optimize out one of the loads. _____________________________________ void* ct_smr_load( std::atomic<void*>& hptr ){

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 13 Hours ago by: Chris M. Thomasson

https://pastebin.com/raw/xCBHY9qd

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 13 Hours ago by: Chris M. Thomasson

Check this one out I programmed many moons ago: https://vorbrodt.blog/2019/02/14/read-write-mutex/ It's very simple, and uses a bakery algorithm so its 100% fair.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 13 Hours ago by: Chris M. Thomasson

True. I remember working with robust mutexes back in the day. EOWNERDEAD, and the fun WAIT_ABANDONED state for windows... ;^)

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 26 Days 13 Hours ago by: Chris M. Thomasson

[...] One big problem is that it can lead to false-sharing. If threads, say A and B are working on their own data sets all padded to and aligned on cache lines, fine. Now, if they were not properly padded and aligned, thread B can inte

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 14 Hours ago by: Manfred

But in fact they do make the language more complicated and complex, simply because they get into the standard, and make it fatter and heavier. The argument about "if you don't want it you are free to ignore it" does not really apply onc

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 17 Hours ago by: Bonita Montero

RAC has no multi-process architecture since the RAC-processes arent shared on a single machine.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 18 Hours ago by: Scott Lurndal

And he/she/it should also read: https://www.thegeekdiary.com/oracle-12c-new-feature-multi-threaded-architecture-of-processes/

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 18 Hours ago by: Scott Lurndal

How much code in the Oracle RDBMS engine did you write[*]? Are you familiar with RAC (which used to be called OPS)? [*] I have experience writing code in the Oracle RDBMS[**], albeit a quarter century ago. [**] In C. All identifie

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 20 Hours ago by: red floyd

This seems relevant: https://i.pinimg.com/originals/6e/6c/1c/6e6c1c2990eb1bc352e29adb3cfef8ba.jpg

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 20 Hours ago by: Bonita Montero

That's sth. completely differen than having a single application spread over multiple processes. That's simply a mess to write and no one writes code like that today. You have never written an MT-application. That's magnitudes more conve

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 20 Hours ago by: Muttley

Huh? Where did I say there was? You seem to be arguing with yourself. Anyway, enough of this for today, I'm getting bored with your nonsense.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 20 Hours ago by: Muttley

How do you think a shell executes sub processes and communicates with them and/or pipes them together? Then there are shell co processes too. What do you think shared memory is? You can even have pthread mutexes mapped to it to use inte

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 20 Hours ago by: Bonita Montero

You don't completely understand what a readers writer lock does. No, absolutely not. There is no implementation of a readers writer lock that can stop readers from holding the lock an inefinite time. The code is easy to read for people

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 20 Hours ago by: Muttley

Yes, and? Perhaps you need to revisit what you wrote. Well of course they could, thats the whole point of a lock FFS! I'm not sure what you're arguing here. From the code you've shown on here its clear you're not capable of writing cl

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 20 Hours ago by: Bonita Montero

Even in most Unix application. fork()ing is outdated for at least 10 years. Having a shared address space is magnitudes more convenient and a lot faster. You have to read it. I'm an Oralce OCP DBA.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 20 Hours ago by: Bonita Montero

*facepalm* Please read this article: https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock Only relative priority since the current readers could theroretically hold the lock in read-state as long as they want. You don't understan

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 20 Hours ago by: Muttley

Not in unix they're not. Not really. You've heard of pipes, signals, shared memory, semaphores, sockets? I'd sooner deal with those than endless race conditions from multiple threads. I suggest you read it.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 20 Hours ago by: Muttley

Well yes, if they're currently reading. What would you suggest happens, the writer is allowed to write while the readers are reading and so you end up with a load of dirty reads? Not clever. Errr yeees. If a write lock is requested it s

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 20 Hours ago by: Bonita Montero

These places are rare today. Having complex iteraction between processes is very inconvenient for a software developer. Oracle has its own terms of what a process is and this is historically defined from times where Oracle wasn't multi

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 21 Hours ago by: Bonita Montero

That's impossible, readers can hold the lock in read-state as long as they want. The only way to give writers priority is to enqueue further readers. You're don't understand it so you can't say it's not elegant. It's usable as convenien

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 21 Hours ago by: Muttley

In some places, not all. As I said, use cases. Configurable. https://docs.oracle.com/en/database/oracle/oracle-database/21/refrn/background-p rocesses.html

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 21 Hours ago by: Muttley

Write locks should always take priority. I'd be surprised if shared_lock doesn't behave like that. For which definition of "elegant"?

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 21 Hours ago by: Bonita Montero

Multi-threading has superseeded fork()ed code. Even Oracle is completely multi-threaded today on Unices.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 21 Hours ago by: Bonita Montero

It behaves exactly like other shared locks, but once a writer has registered as wanting to have write-access all further readers are enqueued. No, working elegant code.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 21 Hours ago by: Muttley

No, just pointing out a glaring inconsistency. And that doesn't apply to multi process? No, its like complaining the STL implemented vector but for 11 years still hasn't bothered implementing list or queue.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 21 Hours ago by: Muttley

So what does your code do if there are still threads reading the data and another wants to write? Suddenly block the read threads and revoke their locks? Otherwise how do you solve the "all readers have relinquished ownership" problem?

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 21 Hours ago by: Muttley

1: No lock. 2: Write lock. 3: Read-write lock. Quite simple to understand really even for you.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 21 Hours ago by: Muttley

Says someone who clearly doesn't understand the pros and cons of multi process vs multi threading. Hint: They have different use cases. One of the main ones being if a child process crashes it doesn't take down the parent process so for m

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 26 Days 21 Hours ago by: Muttley

Yes, the functionality looks the same. When I went googling for this in C++ shared_locks never came up. I supposed because they use different terminology. Anyway, good to know its finally in there and I take back what I said.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 1 Hour ago by: Bonita Montero

This kind of shared lock is almost useless since it gives readers priority over writers so that the writer can proceed only if all readers have relinquished ownership. With my shared lock, all further readers are enqueued when a writer wa

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 1 Hour ago by: Bonita Montero

I know what RW-locks are and I've developed such a lock on my own (I've posted my implementation there that inherited glibc's spinning -algorithm). But that has nothing to do with the word "three level lock". fork() isn't necessaray, th

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 1 Hour ago by: Juha Nieminen

I find it a bit amusing how when a new C++ standard implements support for some new thing, people complain that it's becoming too large and too complex, and when the new C++ standard does *not* implement support for something, that's also

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 1 Hour ago by: Paavo Helde

And read-write locks have been in C++ standard since 2017: https://en.cppreference.com/w/cpp/thread/shared_mutex

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 27 Days 2 Hours ago by: Bonita Montero

#if defined(_WIN32) #include <Windows.h> #elif defined(__unix__) #include <sys/mman.h> #include <pthread.h> #endif #include <iostream> #include <string_view> #include <memory> #include <thread> #include <vector> #include <latch> #inclu

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 2 Hours ago by: William Ahern

I posted two sets of benchmarks, one for qsort-inline and another for qsort-extern. qsort-inline clearly has a substantially different performance profile, and that could only happen if the comparison callback itself was inlined into the

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 4 Hours ago by: Muttley

You are kidding me, right? You spout off about threading all the time and you don't know the fundamentals? Educate yourself: https://www.ibm.com/docs/en/aix/7.2?topic=programming-using-readwrite-locks Sure. Remind me, whats the win32

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 27 Days 4 Hours ago by: Juha Nieminen

My point is that the efficiency advantage of std::sort() would be there even if it doesn't get inlined into the calling code at all. Even if that instance of std::sort() would end up in a completely different compilation unit and doesn't

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 27 Days 4 Hours ago by: Öö Tiib

Are you sure that gcc option -flto is not meant for doing that kind of things during linking? I am not claiming that it is actually doing it with qsort but its documentation is stating it to apply interprocedural optimizations like inlin

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 6 Hours ago by: Juha Nieminen

Although, to be fair, sometimes the standard can be slightly vague and ambiguous, and different standard library implementors can have different interpretations and thus different implementations. Something like a year ago I made a bug r

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 6 Hours ago by: Juha Nieminen

The performance boost doesn't come from inlining. One single function call wouldn't make a difference when it comes to sorting. It doesn't matter if the std::sort() function gets inlined into the calling code or whether the compiler decid

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 27 Days 6 Hours ago by: Bonita Montero

#if defined(_WIN32) #include <Windows.h> #elif defined(__unix__) #include <sys/mman.h> #include <pthread.h> #endif #include <iostream> #include <string_view> #include <memory> #include <thread> #include <vector> #include <latch> #inclu

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 7 Hours ago by: Bonita Montero

No, the numbers aren't useless, they compare the C- and the C++-way to sort things. LOL, there's no C compiler which will do that. The qsort-function is just a static piece of code and nothing is inlined.

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 12 Hours ago by: William Ahern

Unsurprising that inlining can improve performance. Your raw numbers are useless, though, as you're comparing different algorithms (C++ header template vs libc), which shall be demonstrated below. Also, technically speaking your gripe is

Re: Why doesn't the compiler optimize this (thread)

comp.lang.c++

Posted: 27 Days 14 Hours ago by: Andrey Tarasevich

Obviously, because these compilers still cautiously implement support for lambda expressions _literally_ as mere syntactic sugar for local class declarations. They just don't care/don't dare to optimize the general approach. Lambda ex

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 27 Days 18 Hours ago by: Bonita Montero

That's not a problem with x86- and ARMv8-CPUs for a long time. Only crossing a page-boundary includes two privilege-checks.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 19 Hours ago by: Bonita Montero

#pragma once #include <iterator> #include <concepts> #include <compare> #include <cassert> #include <iterator> #include <algorithm> template<std::random_access_iterator RandomIt, typename Key, typename Pred> requires requires( Pred pred

Why doesn't the compiler optimize this

comp.lang.c++

Posted: 27 Days 19 Hours ago by: Bonita Montero

#include <iostream> using namespace std; int main() { int i = 0, j = 0; auto fn = [&]() { ++i, ++j; }; cout << sizeof fn << endl; } g++ 11.1.0, clang 13 and MSVC 2019 print "16", i.e. there are two pointers to i and j. But that's real

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 19 Hours ago by: Bonita Montero

What's "3 level locking" ? Description / URL ? Win32 kernel APIs are by far more elegant than this Posix- / SysV- / BSD-stuff. It's just the implementation that is rather slow.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 20 Hours ago by: Bonita Montero

C++ threading is a lot more convenient than operating system dependent threading. And you've to learn it only once and not in every OS-depen- dent way.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 20 Hours ago by: Muttley

In in interview once I was asked to write pseudo code for re-balancing a tree so it certainly does help!

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 20 Hours ago by: Scott Lurndal

They probably should have done it once, during training on data structures, along with building all the other standard structures (stack, list, tree (binary, general, red/black, etc)) from first principles (including table-based implemen

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 20 Hours ago by: Muttley

C++ threading isn't necessary given the vast majority of C++ programs are non portable anyway or if they are have a huge amount of #ifdefs already. If they're going to do threading they should do it properly or don't bother.

Re: Intersting ... (thread)

comp.lang.c++

Posted: 27 Days 21 Hours ago by: james...@alumni.calt

On Sunday, April 24, 2022 at 4:39:51 PM UTC-4, Chris M. Thomasson wrote:

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 21 Hours ago by: Muttley

Nothing to do with whether it goes wrong and all to do with whether they get used in code or interviews. If a company requires you to know Boost or Mongo-C it'll say so explicitely in the job spec. When they say "C++20 desired" what doe

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 21 Hours ago by: Muttley

Depends how many times they've done it before. I've lost count of the times I had to write a doubly linked list in C back in the day and I could almost do it with my eyes closed now. Thats why I said basic algorithms. I'm not suggestin

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 21 Hours ago by: James Kuyper

The committee isn't responsible for implementing the C++ standard library. Oddly enough, that's the responsibility of the implementor. While implementors can occasionally make idiotic mistakes, just like any other programmer, their work (

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 27 Days 21 Hours ago by: Bonita Montero

For 99% of what MT-synchronization nedds C++'s mutexes and condition variables are sufficient. The rest can be easily built with semaphores and atomics. So there's really no limit of the platform since C++ could supply additional synchroni

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days ago by: Malcolm McLean

With the third party library, the answer is either "yes" or "no". Sometimes employers want to find someone who has worked on exactly the same system that they are recruiting for. However that's pretty rare. Usually they realise that this r

Re: speed of unaligned accesses that cross page-boundaries (thread)

comp.lang.c++

Posted: 28 Days 4 Hours ago by: Chris M. Thomasson

Straddling a cache line is very bad... NO, try not to do it!

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 4 Hours ago by: Juha Nieminen

You know, because the situation is so much better when programs use third-party libraries (which the vast, vast majority of them do). Because, as we all know, there doesn't exist any third-party library that "will only ever be used bh 0.0

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 4 Hours ago by: Juha Nieminen

No. Most experienced programmers are pretty intelligent and smart, and most if not all of them make programming mistakes, even with the simplest of algorithms or tasks. Why do you think that testing (eg. unit testing) is such a huge deal

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 4 Hours ago by: Muttley

Indeed. Endless pointless syntax changes and API additions that will only ever be used by 0.0001% of the user base but have to be understood because some idiot will try and use them in production code (and get it wrong) that you'll have t

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 4 Hours ago by: Muttley

You seem to assume everyone apart from the C++ committee is an idiot and can't write basic algorithms correctly.

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 6 Hours ago by: Juha Nieminen

Ok, let me put it this way: The ranges library is just that: A library. It's not part of the language syntax itself. It's not making C++ "more complicated" because it's not changing the C++ language itself. It's simply an ancillary auxil

Re: Intersting ... (thread)

comp.lang.c++

Posted: 28 Days 8 Hours ago by: Chris M. Thomasson

If the compiler system decides to play games with my essential load and store sequences that still produce 100% correct results, so be it. Fine. Still scares me... These atomic's are _very_ sensitive. So, be careful compiler writers!

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 13 Hours ago by: Cholo Lennon

I had said it before in the forum, C++ is an awful monster (disclaimer: I started with it in 1990, and I am still using it at professional level). Right now I am really frustrated with the language direction, tons of new (complicated)

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 20 Hours ago by: James Kuyper

On 4/26/22 12:24, Muttley@dastardlyhq.com wrote:

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 20 Hours ago by: Muttley

Who asked for ranges? Presumably the committee will have a list of contacts. Or is it just another circle jerk?

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 20 Hours ago by: Manfred

That is certainly true (it's called lobbying in some contexts). The problem might be that some of the additions may have been asked for by some party that may be very influential, but whose priority may be something else than quality o

Re: getline() problem (thread)

comp.lang.c++

Posted: 28 Days 20 Hours ago by: James Kuyper

If it's compile-time undefined behavior, or run-time undefined behavior that will unavoidably occur some time after program start, yes, it can. In principle, yes. In practice, in many situations the effect will be must more limited. E

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 28 Days 21 Hours ago by: Malcolm McLean

I have a lot of functions which return points on piecewise Bezier curves. The points often need sorting by position on the curve. Typically we're talking about tens of points in maximum normal use.

Re: getline() problem (thread)

comp.lang.c++

Posted: 28 Days 21 Hours ago by: James Kuyper

You're confusing two different kinds of optimization. The first kind are the "as-if" optimizations. It's not true that such optimizations can't change the observable behavior, but that's close to being the correct description. For any giv

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 21 Hours ago by: James Kuyper

On 4/26/22 05:15, Muttley@dastardlyhq.com wrote:

Re: getline() problem (thread)

comp.lang.c++

Posted: 28 Days 21 Hours ago by: Stefan Ram

Probably it was meant that the line auto f { ::std::ifstream { file_str } }; should be changed to the line auto f { ::std::ifstream { file_str, ::std::ios::binary }}; . It's not clear whether this matters in this case; but i

Re: getline() problem (thread)

comp.lang.c++

Posted: 28 Days 22 Hours ago by: Manfred

Technically yes, it can. Others have already said that. That is why the very concept of Undefined Behaviour keeps raising questions. "Minor" is a qualitative and subjective attribute. Humans know that, machines don't. Compiler writers

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 22 Hours ago by: Manfred

Not as far as I have seen. As far as I recall, at that time t standard was substantially the standardese version of Bjarne's book TC++PL (or, more precisely, Bjarne's book was the English version of the standard). I have not heard suc

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 28 Days 22 Hours ago by: Bonita Montero

With ... auto cSort = []( vu_it begin, vu_it end ) { qsort( to_address( begin ), end - begin, sizeof(unsigned), []( void const *left, void const *right ) -> int { unsigned &l = *(unsigned *)left, &r = *(unsigned *

Re: getline() problem (thread)

comp.lang.c++

Posted: 28 Days 22 Hours ago by: Andrey Tarasevich

Absolutely! Or it can refuse to compile the program entirely. Still there are some ambiguities in the way it is described in the standard. On the one hand, it is clear that localized undefined behavior is permitted to "poison" the who

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 28 Days 22 Hours ago by: Scott Lurndal

Back in the day (70's and 80's) sorting was probably the most common activity on mainframe computers. Much effort went into efficient sorting mechanisms. Size definitely mattered when your dataset routinely exceeded the size of main m

Re: getline() problem (thread)

comp.lang.c++

Posted: 28 Days 23 Hours ago by: David Brown

Yes. But an implementation that does that is unlikely to be very popular! (You can have code in your program that, if executed, would have UB. The problem only comes when trying to execute it.) I think you are - as many people seem t

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 28 Days 23 Hours ago by: Malcolm McLean

"Brittle" means that the code contains subtle interdependencies between different parts, usually distant in "code space" (different modules, source files, called from different places in the program, a long way from each other in a graph

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 28 Days 23 Hours ago by: Öö Tiib

OK, good catch. Replaced with: return (*(unsigned *)left > *(unsigned *)right) - (*(unsigned *)left < *(unsigned *)right); Still similar results: <http://coliru.stacked-crooked.com/a/462b2889dc90f15c>

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 29 Days ago by: Bonita Montero

This doesn't work because the difference might be too large for an int.

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 29 Days ago by: Öö Tiib

What I'm supposed to do with your hand? Somehow I got different result. It can be because I replaced your bloat lambda that you used for C: unsigned &l = *(unsigned *)left, &r = *(unsigned *)right; return l < r ? -1 : l > r ? 1 : 0; Wi

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 29 Days 1 Hour ago by: Alf P. Steinbach

Let's say that you don't want to deal with some APL code you found, but you want whatever effect it has, in C++. Trying to implement APL yourself is an ungood way to go about it. Implementation whatever that code does, in a natural way

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 29 Days 1 Hour ago by: Juha Nieminen

So if you want the same functionality in your program it's preferable to implement it yourself, making it significantly less tested and thus less reliable, and probably even more "brittle" (whatever that means)? Also maintenance is probab

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 1 Hour ago by: Juha Nieminen

One rather interesting example of UB doing something quite unexpected is this code, when compiled with clang 13.0.0: //-------------------------------------------- #include <stdio.h> void f1(void) { for(int i = 0; i >= 0; i++) {

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 29 Days 2 Hours ago by: Bonita Montero

2: 229%, 4% 4: 414%, 5% 8: 394%, 6% 16: 419%, 9% 32: 473%, 13% 64: 511%, 28% 128: 465%, 39% 256: 502%, 53% 512: 430%, 66% 1024: 320%, 78% 2048: 233%, 88% 4096: 197%, 97% 8192: 176%, 57% Still 76% more trhoughput with 8192 elements. The i

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 29 Days 2 Hours ago by: Bonita Montero

Relative numbers are the correct way here.

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 3 Hours ago by: Malcolm McLean

Basically you want a severe warning, because the programmer might have deliberately caused the undefined behaviour because he knows what it will do on his platform. He might want to set the carry flag before jumping into an assembler rout

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 29 Days 3 Hours ago by: Alf P. Steinbach

That's too weak a sentiment. The Ranges library adds not just an new huge API but another large domain specific language which results in very brittle code, and huge complexity, that maintenance programmers must deal with. Then there'

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 29 Days 3 Hours ago by: Juha Nieminen

The same story repeats again and again. Back in the 90's the new C++ standard was criticized as being "too complicated", "too inefficient", "too bloated", yada yada. After a time most of these people stopped complaining. Then C++11 came

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 3 Hours ago by: Juha Nieminen

The more I think about it, the more ridiculous that becomes. If the compiler is allowed to do *anything* it wants when it encounters Undefined Behavior, doesn't that mean that it can, for example, compile the entire program into a single

Re: "Performance of C++20's Ranges" (thread)

comp.lang.c++

Posted: 29 Days 3 Hours ago by: Muttley

C++ used to be a svelt , clean language. Now its rapidly turning in Javas brother with new huge APIs that no one asked for being added such as this. If learning an API is more effort than writing code to do the same thing yourself then th

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 4 Hours ago by: Paavo Helde

Look at my prev post in this thread for code example how to use std::ios::binary.

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 29 Days 5 Hours ago by: Öö Tiib

Yes, but it gives relative results, not absolute. So however lot of times you run it the picture is still same. Indeed, discussing something with you is like wrestling with a pig, rather stupid idea. Quality of MS C compiler and library

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 5 Hours ago by: David Brown

UB "takes precedence" over /everything/ - it basically says there are no guarantees of anything. There was an attempt to distinguish between "bounded" and "unbounded" undefined behaviour in C (Annex L in the C11 standards), but AFAIK

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 29 Days 5 Hours ago by: Öö Tiib

I did nowhere claim otherwise, use std::sort by default. Read again? I said that the algorithm's performance (that happens to be topic of this thread) did not differ for > 1024 arrays. So you wrestle with straw-men you built yourself. W

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 5 Hours ago by: Jivanmukta

I don't understand you. I have binary flag zero_byte_found.

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 7 Hours ago by: Juha Nieminen

By the way, doesn't this break the rule that optimizations must not change the observable behavior of the program (other than by its execution time)? (Granted, I haven't actually checked that the standard actually mandates that "optimiza

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 29 Days 7 Hours ago by: Juha Nieminen

When it comes to sorting an array, there are no "sizes that matter". If you need to sort, say, an array of 8 elements (even if it's statically 8 and nothing else), by far the easiest way is to use std::sort(). Heck, even if the array has

Re: This code is effective for modest-sized numbers, but can you tell what it does? (thread)

comp.lang.c++

Posted: 29 Days 7 Hours ago by: Juha Nieminen

Yeah, it's not that much about the signedness, but about the size. After all, the program accepts a 'long long' value as input, so ostensibly the vector might have more than INT_MAX and even more than UINT_MAX elements (might not be the c

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 7 Hours ago by: Andrey Tarasevich

Look like I was wrong, and I take it back. Now, after rereading the corresponding portion of the specification I agree that it is fairly symmetrical with regard to text input and output. The transformations, like "optimizing out" space

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 8 Hours ago by: james...@alumni.calt

.... Please cite the text that restricts the transforms to the output functions.

"Performance of C++20's Ranges"

comp.lang.c++

Posted: 29 Days 8 Hours ago by: Cholo Lennon

Three Benchmarks of C++20 Ranges vs Standard Algorithms https://www.cppstories.com/2022/ranges-perf -- Cholo Lennon Bs.As. ARG

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 16 Hours ago by: Ben

ACK. I was going to say the same in way too many more words. AT seems to think that writing code targeted exclusively at POSIX systems is absurd.

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 16 Hours ago by: Andrey Tarasevich

True. I have to admit that I managed to forget about this treatment for `1A` character. However, practice shows that a lot more people run into "funky" unexpected EOF conditions when they attempt to `getchar()` an `FF` byte into a `si

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 17 Hours ago by: Andrey Tarasevich

Firstly, you need to work on your reading-&-comprehension-101, since the matter of POSIX is covered in the "elided screed". Secondly, "POSIX defined behavior" here matters as much at was covered by me, i.e. not much, if at all. So, I

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 17 Hours ago by: Paavo Helde

You still have not added the binary flag.

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 17 Hours ago by: Paavo Helde

It also translates 26 to EOF, leaving the rest of the file unread. This behavior comes as a surprise to many people and can be indeed called "funky".

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 17 Hours ago by: Scott Lurndal

Actually, that's POSIX defined behavior. Rest of screed elided.

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 17 Hours ago by: Paavo Helde

It was 13 in old Mac, and 10 since Mac OS X, as it is a genuine Unix. This only works if the text file has been produced on a platform with the same conventions as the currently running program. Nowadays files are routinely copied and

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 18 Hours ago by: Manfred

Well, the general rule is correctly a general rule as far as the C and C++ standard guarantees go. On Unix and Unix-like systems you may well have other guarantees in action, which are not as general as the C standard.

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 18 Hours ago by: Manfred

MS-Windows (and DOS before that) behave as you describe ('\n' is stored as '\r\n' on disk and converted back to '\n' upon read) - or, more properly, the MS C runtime does that. So, according to your quote above from the C standard that

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 18 Hours ago by: Andrey Tarasevich

Yes, and as I said previously, these transformations are allowed on the output side. It is true that a character buffer being written into a text stream might not compare equal to a character buffer later read from the same test stream

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 18 Hours ago by: Andrey Tarasevich

That's catastrophically incorrect on more than one level. This is the same fallacy that is often used by numerous "UB deniers", claiming that on their hardware/OS platform some forms of "undefined behavior" are supposedly "perfectly de

Re: I think references should have been const by default (thread)

comp.lang.c++

Posted: 29 Days 18 Hours ago by: Keith Thompson

[...] Do you *seriously* not see how that was offensive? Re-reading the thread, I now see that it was not you who originally called James a "preening fool". It was another participant who chose to insult James while James was making cor

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 19 Hours ago by: james...@alumni.calt

That might be true of a particular implementation, but in general, data read from a text stream might not compare equal to data previously written to that stream, unless "... the data consist only of printing characters and the control

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 19 Hours ago by: Andrey Tarasevich

"Ignoring these differences" comes with a price, like restrictions on absolute positioning. E.g. one's only allowed to `fseek` to 0 or to a position previously obtained from `ftell`. Arbitrary relative/absolute positioning is not suppo

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 19 Hours ago by: Andrey Tarasevich

No, it can't. All it does on the input side is translate the line endings to '\n', which it properly does. "Funky things" usually come as a consequence of unfounded expectations, like expecting to be able to use absolute positioning in

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 19 Hours ago by: Scott Lurndal

It was used by DEC systems, IBM and Burroughs systems (when communicating with teletypes and other non-line-printer output devices) even before 1974 when CP/M was developed, although generally not part of the file for the non-DEC systems

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 19 Hours ago by: Keith Thompson

[...] Versions of MacOS before version X (10) used CR as a line terminator. OS X, since it's Unix-based, uses LF.

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 19 Hours ago by: James Kuyper

On 4/25/22 11:56, Scott Lurndal wrote:

Re: Class declaration has name of namespace before name of class (thread)

comp.lang.c++

Posted: 29 Days 19 Hours ago by: James Kuyper

Stefen Ram found it: "class-specifier : class-head { member-specification opt } class-head : class-key attribute-specifier-seq opt class-head-name class-virt-specifier opt base-clause opt

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 20 Hours ago by: Jivanmukta

I have written: string m = ""; auto f { ::std::ifstream { file_str } }; if (f) { bool zero_byte_found = false; while (!f.eof()) { auto const byte { f.get() }; if (!byte) {

Re: Class declaration has name of namespace before name of class (thread)

comp.lang.c++

Posted: 29 Days 20 Hours ago by: Stefan Ram

Isn't this a class-head-name (n4849) with a nested-name-specifier?

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 20 Hours ago by: James Kuyper

On 4/25/22 11:54, Vir Campestris wrote:

Re: Class declaration has name of namespace before name of class (thread)

comp.lang.c++

Posted: 29 Days 20 Hours ago by: James Kuyper

On 4/25/22 11:55, Scott Lurndal wrote:

Re: g++ and linking (thread)

comp.lang.c++

Posted: 29 Days 20 Hours ago by: james...@alumni.calt

.... Yes, "a" program - a single program for which that is true is sufficient to meet that requirement. I think that the way 5.2.4.1 was written is indeed astonishingly lax. I can understand why people feel a need to interpret in a way

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 20 Hours ago by: Scott Lurndal

As a general rule, your general rule only applies to Windows. On Unix and Unix-like systems, there is no functional difference between text and binary.

Re: Class declaration has name of namespace before name of class (thread)

comp.lang.c++

Posted: 29 Days 20 Hours ago by: Scott Lurndal

The same rule that allows this constructor for a nested 'struct s_percpu' in 'class c_gic'. c_gic::s_percpu::s_percpu(uint32 corenum, const char *name, c_gic *gic) {} Similarly, if you have a class (or struct) nested in a namespace.

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 20 Hours ago by: Vir Campestris

Windows text files have 13,10 as a newline sequence, not just 10 as in Linux etc. This dates back to at least CP/M where the byte stream in the file exactly matched the one you would send to your CRT or printer, and a line feed really

Re: Inline functions and locals (thread)

comp.lang.c++

Posted: 29 Days 21 Hours ago by: james...@alumni.calt

Agreed. It is a huge difference. It is also a difference that is irrelevant to the point I was making. I was not talking about whether or not a developer could find out what the behavior was. I was only talking about whether or not the st

Re: This code is effective for modest-sized numbers, but can you tell (thread)

comp.lang.c++

Posted: 29 Days 21 Hours ago by: Vir Campestris

Some of us remember when int was only 16 bits... There's actually no guarantee that int and size_t are the same size, never mind the signed problem. for (int i = 0; is however traditional. I suspect at least in part because int is eas

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 29 Days 21 Hours ago by: Bonita Montero

But the benchmark shows the basic constraints of C's qsort().

Re: qsort() vs. std::sort (thread)

comp.lang.c++

Posted: 29 Days 21 Hours ago by: Bonita Montero

That doesn't matter here because we compare the performance of different algorithms for the same purpose. You're stupid.

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 21 Hours ago by: James Kuyper

The C++ standard says very little about the differences between text mode and binary mode, cross-referencing the C standard for such issues. The C standard says something important to this issue: "... Data read in from a text stream will

Re: Class declaration has name of namespace before name of class (thread)

comp.lang.c++

Posted: 29 Days 21 Hours ago by: James Kuyper

I can understand why it's useful - but I'm having trouble figuring out how to read the C++ grammar rules in such a way as to allow it. Can you identify the rules that allow you to use that syntax?

Re: I think references should have been const by default (thread)

comp.lang.c++

Posted: 29 Days 22 Hours ago by: Tim Rentsch

I don't know why you find my comment so objectionable. I was only reporting some observations of past events. I think the same statement applies, to a greater or lesser degree, to most people who post here regularly and who present the

Re: g++ and linking (thread)

comp.lang.c++

Posted: 29 Days 22 Hours ago by: Tim Rentsch

I think you're just wrong about that. Clearly the intended reading of section 5.2.4, and how essentially everyone else reads this section, is that 5.2.4.1 paragraph 1 gives minimum translation limits, and also requires all conforming im

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 23 Hours ago by: Stefan Ram

It might be possible to insert this at the start of the loop body: if( file.bad() ){ ::std::cerr << "file.bad()\n"; break; } else if( file.fail() && !file.eof() ) { ::std::cerr << "file.fail()\n"; break; } to get some kind of error

Re: getline() problem (thread)

comp.lang.c++

Posted: 29 Days 23 Hours ago by: Stefan Ram

....

539 recent articles found.

rocksolid light 0.7.2
clearneti2ptor