could you show me a quote that says so

in fact i am right. look at section 11.4 paragraphs 1, 3, and 4

paragraph 1 Members of a class are data members, member functions (11.4.1), nested types, enumerators, and member templates (13.7.2) and specializations thereof. paragraph 3 A member function is a member that is a function. paragraph 4 A data member or member function may be declared static in its member-declaration, in which case it is a static member (see 11.4.8) (a static data member (11.4.8.2) or static member function (11.4.8.1), respectively) of the class. Any other data member or member function is a non-static member (a non-static data member or non-static member function (11.4.2), respectively).

it is at 13.9.1 paragraph 3

no i meant the quote you mentioned. it is at 13.9.1 paragraph 3 of the C++20 standard

btw 3.22 3.23 and 3.24 of the C++17 standard are all definitions of the word "signature"

paragraph 1 Members of a class are data members, member functions (11.4.1), nested types, enumerators, and member templates (13.7.2) and specializations thereof. paragraph 3 A member function is a member that is a function. paragraph 4 A data member or member function may be declared static in its member-declaration, in which case it is a static member (see 11.4.8) (a static data member (11.4.8.2) or static member function (11.4.8.1), respectively) of the class. Any other data member or member function is a non-static member (a non-static data member or non-static member function (11.4.2), respectively).

and the parts i mentioned here still exist at 12.2 (same paragraph numbers)

i believe those are the same given section 11.4 is titled "Class members" and 11.4.1 is titled "Member functions"

12.2 and 12.2.1

no i think i was right. static member functions are a subset of member functions 11.4.8.1 Static member functions [class.static.mfct] 1 [Note: The rules described in 11.4.1 apply to static member functions. — end note] the rules in 11.4.1 are about class member functions the rules special to non-static member functions are in 11.4.2

12.2.3.1 (same paragraph number)

it doesn't imply a non-static member function. that is why 11.4.2 is a separate section from 11.4.1

12.2.2 12.2.1

/get cbook

it doesn't have to be. 1) that is the definition of the word signature in the context of class member functions. it is not the definition of a class member function, that is provided by the previously mentioned sections. i interpret it as signature of X::fn() class X { static void fn(); } <class member function> fn (name), empty/void (parameter-type list), X (class of which the function is a member), none (cv-qualifiers), none (ref-qualifiers), none (trailing requires clause) 2) there is no mention of signature of static member functions separately 3) there is no mention of signature of even normal static functions, do we interpret that as static functions don't have a signature? i would much rather take [defns.signature] because it is perfectly applicable to static functions static func(int a); has the signature <function> func (name), int a (parameter type list), global namespace (surrounding namespace)

i would say [defns.signature.member] implies that the word static is irrelevant in determining the signature of a class member function

not that class member functions are non-static by default

;-; C++17 or 20? use the tags pls

okay

Why to use this- vector<int> *a = new vector<int>() when vector<int> a should be enough?

yes i found it

Why to use this- vector<int> *a = new vector<int>() when vector<int> a should be enough?

you should never use that in modern C++

you should never use that in modern C++

I don't but seen people doing so !

you should never use that in modern C++

BTW any difference b/w them?

the section says it describes the organisation of clause 17 through clause 32 and Annex D. 16.4.2 (in C++20) i went into one of the chapters you can clearly see that member functions include static member functions too, for example 20.10.3.2 Member functions [pointer.traits.functions] static pointer pointer_traits::pointer_to(see below r); static constexpr pointer pointer_traits<T*>::pointer_to(see below r) noexcept;

i see no reason to believe that. 1) i have already provided my interpretation of the definition of the word signature (both for class member functions and ordinary functions) which show no sign of contradiction. 2) 11.4.1 is called "Class members", which i believe can be rewritten as "Members of a class" which leads to the paragraphs mentioned before leaving no distinction between member functions and class member functions. 3) as i said, 16.4.1.4 describes how the rest of the library clauses are organised. if static members are part of "Member function" and not part of "Class member function", and they are clearly mentioned in the detailed library clauses, why are they not mentioned separately in 16.4.1.4. i already provided an example for that. here is another example template<class Promise> struct coroutine_handle : coroutine_handle<> { // 17.12.3.1, construct/reset using coroutine_handle<>::coroutine_handle; static coroutine_handle from_promise(Promise&); coroutine_handle& operator=(nullptr_t) noexcept; // 17.12.3.2, export/import static constexpr coroutine_handle from_address(void* addr); // 17.12.3.5, promise access Promise& promise() const; }; } in 17.12.3 [coroutine.handle]

clearly this is not true

24.6.1.2 Class template empty_view [range.empty.view] namespace std::ranges { template<class T> requires is_object_v<T> class empty_view : public view_interface<empty_view<T>> { public: static constexpr T* begin() noexcept { return nullptr; } static constexpr T* end() noexcept { return nullptr; } static constexpr T* data() noexcept { return nullptr; } static constexpr size_t size() noexcept { return 0; } static constexpr bool empty() noexcept { return true; } }; } here is another, the static functions are clearly observers

24.6.1.2 Class template empty_view [range.empty.view] namespace std::ranges { template<class T> requires is_object_v<T> class empty_view : public view_interface<empty_view<T>> { public: static constexpr T* begin() noexcept { return nullptr; } static constexpr T* end() noexcept { return nullptr; } static constexpr T* data() noexcept { return nullptr; } static constexpr size_t size() noexcept { return 0; } static constexpr bool empty() noexcept { return true; } }; } here is another, the static functions are clearly observers

holy crap

holy crap

;-;

1) why is it wrong? yes i did (function). can you provide an alternative signature for static functions? in fact can you provide an alternative signature for static member functions? 2) paragraph 1 of Class Members "The member-specification in a class definition declares the full set of members of the class". clearly Class Members and Members of the class can be used interchangably. 3) (2.1) — constructor(s) and destructor (2.2) — copying, moving & assignment functions (2.3) — comparison functions (2.4) — modifier functions (2.5) — observer functions (2.6) — operators and other non-member functions this is the order in which the descriptions of class member functions in the library clauses are organised, obviously the library clauses themselves are relevant

okay

1. you didn't provide a signature. for example, i did static func(int a); <function> func (name), int a (parameter type list), global namespace (surrounding namespace) class X { static void fn(); } <class member function> fn (name), empty/void (parameter-type list), X (class of which the function is a member), none (cv-qualifiers), none (ref-qualifiers), none (trailing requires clause) this is based on my interpretation that function refers to both static and non-static function and class member function refers to both static and non-static member function. if you decide that at least the second one is not true, there is no way for you to provide a signature for static member functions. this alone is a contradiction i believe. 2. i'm arguing that Class Members and Members of a class are same, members are either data members or function members. so Class member function and member function are indistinguishable. 3. this is how class member functions are organised. my argument is that static member functions are part of class member functions, so they don't need separate mention. this proves my point further i went ahead and checked [coroutine.handle], since the constructors, export/import etc are explicitly commented there. 17.12.3.1 Construct/reset [coroutine.handle.con], 17.12.3.2 Export/import [coroutine.handle.export.import]. doesn't mention static functions separately i believe you are talking about 20.10.9.2 Static member functions [allocator.traits.members], but that library clause doesn't even have any other types of functions for me to verify that constructor/copy/comparison/modifier/observer etc are separate.

BTW any difference b/w them?

read up on RAII

You still discuss the topic about instantiation of static non-template member functions of class templates?

I don't but seen people doing so !

This is a bad practice

You still discuss the topic about instantiation of static non-template member functions of class templates?

no, discussion is whether the phrases "class member function" and "member function" are the same thing as per the standard

I don't think that every smart pointes makes sense I mean there is no reasonable issue to store a vector in std::unique_ptr I can think of Shared and weak pointer could be used to store a vector for some cases, but these smart pointers have very limited use cases in C++

Between different processes?

Ok, you should be right I have no skills in interprocess programming

How am I having a memory leak here?

95% sure that it's string related but don't understand how and why

"Mentions adding a static before a member function makes it a static member function. And the second quote excludes cv and reference qualifiers. This clearly forces the signature of a static member function." clearly, you want to modify the signature of a "member function" to create the signature of a "static member function". what is the signature of a "member function" then? given that you don't believe "member function" and "class member function" are the same. cppreference is a wiki. wikis can have mistakes. further, i believe the redirect exists simply because the static member function section of the wiki is extremely small. also, even that redirection text uses the terms "class member function" and "member function" interchangeably 3) i agree about modifier and observer function parts. i was the one who mentioned that static functions are observers in empty_view, it was not specified in the standard. i think that section is defective. "Descriptions of class member functions follow the order (as appropriate):" clearly most of the sections don't follow the style they mention. further (2.6) — operators and other non-member functions "description of class member functions" should definitely not contain "other non-member functions"

95% sure that it's string related but don't understand how and why

the string even doesn't allocate memory in this case because of small string optimization

btw, is it correct to put _CrtDumpMemoryLeaks(); at the end of the main? I'm experimenting with pointers and destructor while working on list so I have to be 100% sure that it's called at the end

It's weird because regarding to Microsoft Docs if you defined macro _CRTDBG_MAP_ALLOC then it should show the file and the line where the leaked memory were allocated

Please am sorry Am new in the group how can I catch up

Like this Detected memory leaks! Dumping objects -> c:\users\username\documents\projects\leaktest\leaktest.cpp(20) : {18} normal block at 0x00780E80, 64 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD Object dump complete.

Please am sorry Am new in the group how can I catch up

What catch up?

What catch up?

I thought the group was fr teaching

Like this Detected memory leaks! Dumping objects -> c:\users\username\documents\projects\leaktest\leaktest.cpp(20) : {18} normal block at 0x00780E80, 64 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD Object dump complete.

Maybe because I'm compiling a project

I thought the group was fr teaching

You just ask what you do not understand in C/C++, we answer

Maybe because I'm compiling a project

What?

You just ask what you do not understand in C/C++, we answer

Read the rules before asking

I'm literally right clicking on the top and compiling

So what?

I want to assign a vector to another vector but not copy but instead move. vector<int> a; //inserting some elements into a vector<int> b; //inserting some elements into b will this work to rather assign b to a : b = a;

https://docs.microsoft.com/en-us/visualstudio/debugger/finding-memory-leaks-using-the-crt-library?view=vs-2019 Regarding to docs you should use this function only when you exit the program Not somewhere in between I think this is because it just tracks all allocations and if memory wasn't deallocated, the function considers the memory leaked

I want to assign a vector to another vector but not copy but instead move. vector<int> a; //inserting some elements into a vector<int> b; //inserting some elements into b will this work to rather assign b to a : b = a;

std::vector<int> a{1, 2, 3}; std::vector<int> b{std::move(a)}; b.push_back(4); b.size(); // 4 a.size(); // 0

vector<int> a; //inserting some elements into a And does vector<int> b = a; perform something else?

vector<int> a; //inserting some elements into a And does vector<int> b = a; perform something else?

It copies all the elements of a to b

1. signature and definition are not the same thing [Note 1 to entry: Signatures are used as a basis for name mangling and linking. — end note] if it was, there would be no need to have the definitions for the word signature separately 2. this is a bruh level comment. please read beyond sentence 2 (i added sentence 4 later) cppreference is a wiki. wikis can have mistakes. further, i believe the redirect exists simply because the static member function section of the wiki is extremely small. also, even that redirection text uses the terms "class member function" and "member function" interchangeably 3. i said that about empty_view only. i gave multiple examples. sure, but i guess the wording of "Descriptions of class member functions follow the order (as appropriate):" should be more like "Descriptions of class member functions and non-member functions follow the order (as appropriate):"

std::vector<int> a{1, 2, 3}; std::vector<int> b{std::move(a)}; b.push_back(4); b.size(); // 4 a.size(); // 0

Ok so a gets assigned to NULL after doing std::move()? I guess, this is inner implementation to prevent the vector a from getting into invalid state.

Ok so a gets assigned to NULL after doing std::move()? I guess, this is inner implementation to prevent the vector a from getting into invalid state.

Nothing is assigned to NULL, where do you even see pointers there?

Can you link to somewhere which explains whether it copies or moves? I forget these.

Can you link to somewhere which explains whether it copies or moves? I forget these.

Effective Modern C++ book

Effective Modern C++ book

Is there any name for this topic?

Move semantics

it is not called like that in the book probably

I don;t remember now

sure I'll check that

Nothing is assigned to NULL, where do you even see pointers there?

I think I read somewhere that after some variable gets moved like c = move(d), then d gets into some invalid state. Although, I'm not sure. tho.

Ok so a gets assigned to NULL after doing std::move()? I guess, this is inner implementation to prevent the vector a from getting into invalid state.

All standard classes guarantee to leave object with a valid state after move operation, not std::move It's done for being able to call destructors on objects which "data" were moved from

All standard classes guarantee to leave object with a valid state after move operation, not std::move It's done for being able to call destructors on objects which "data" were moved from

Move operation is move constructor or move assignment operator, for example

Don't the above 2 statements contradict, he said that since a is a vector, it will be left to some valid state. You said a will be left in some invalid state. Or did I miss something?

You just ask what you do not understand in C/C++, we answer

Ok Am sorry I wanted to learn I don't knw anything about it

Don't the above 2 statements contradict, he said that since a is a vector, it will be left to some valid state. You said a will be left in some invalid state. Or did I miss something?

I'm not as smart as Mα∂ɦµ Probably what (s)he saying is true

All standard classes guarantee to leave object with a valid state after move operation, not std::move It's done for being able to call destructors on objects which "data" were moved from

So, after std::move on vector a, can't i do a.push_back(element) as she said that I can't perform any operation on it?

ok, got that.

1) i) the Appendix A (grammar summary) doesn't mention the word signature once. ii) the signature definitions for function and class member function don't include the return type. if that doesn't separate them from grammar, idk what will 2) sure i will. editing an entire page will be a huge task. but i will try. 3) the only contradiction i had was when i misquoted the standard. i accepted that immediately. you just hand waved the fact that you cannot produce the function signature based on your definition.

> This is the stupidest comment I have seen in this group given how many of them I have come across here. Really?