Hi,
I remember from somewhere reading that inlining constructors is a
'BadThing', but now can't seem to find the original source. I can't
however thing of a reason why it would be for simple constructors...
any thoughts
Mike
21  2002 
On May 24, 1:52 pm, Michael Hull <mikehul...@googlemail.comwrote:
Hi,
I remember from somewhere reading that inlining constructors is a
'BadThing', but now can't seem to find the original source. I can't
however thing of a reason why it would be for simple constructors...
any thoughts
Mike
Hi,
For simple constructors of classes having implicit data types as their
data members only it is ok to have inline constructors but even it is
not getting derived.
But for heavy classes (classes with many user defined data types as
data members) inlining constructors is a bad thing and it becomes even
more worse if the class is inherited from some other class.
When you will look at the number of lines in the constructor you will
feel it should be allowed, but an object construction results in
calling so many constructor calls (of all composed objects and of all
base classes and their composed objects).
Please correct me if i am wrong.
Vineet
Vineet Chawla wrote :
On May 24, 1:52 pm, Michael Hull <mikehul...@googlemail.comwrote:
>Hi,
I remember from somewhere reading that inlining constructors is a
'BadThing', but now can't seem to find the original source. I can't
however thing of a reason why it would be for simple constructors...
any thoughts
Mike
Hi,
For simple constructors of classes having implicit data types as their
data members only it is ok to have inline constructors but even it is
not getting derived.
But for heavy classes (classes with many user defined data types as
data members) inlining constructors is a bad thing and it becomes even
more worse if the class is inherited from some other class.
When you will look at the number of lines in the constructor you will
feel it should be allowed, but an object construction results in
calling so many constructor calls (of all composed objects and of all
base classes and their composed objects).
You're describing WHEN it is bad, but not WHY it is bad, so this is not
helping. I can think of several reasons: inlining large functions
causes massive code bloat, thus increasing the size of your executable
and probably decreasing performance. Another reason might be that the
larger the constructor is, the more dependencies (on average) it has on
the rest of the code, causing you to rebuild large parts of your
application for even small changes that don't have to do anything with
the users of the constructor in question.
However, these reasons all apply to regular functions as well, and the
threadstarter was explicitely talking about constructors. Besides that,
keep in mind that 'inline' is only a hint to the compiler - a good
compiler will make his own judgements on whether to inline a function
or not, no matter if the constructor/function was actually defined as
being inline, so the first argument is pretty moot.
So to conclude, I have no idea why inlining constructors in particular
is a Bad Thing.
- Sylvester
Sylvester Hesp wrote:
Besides that,
keep in mind that 'inline' is only a hint to the compiler
It's not *only* a hint. It does more than that (specifically
related to linking).
Juha Nieminen wrote:
Sylvester Hesp wrote:
>Besides that,
keep in mind that 'inline' is only a hint to the compiler
It's not *only* a hint. It does more than that (specifically
related to linking).
Yes I might've been a bit unclear. I wasn't talking about the inline
keyword in general, I was talking about the actual process of function
inlining by the compiler.
- Sylvester
On May 25, 4:07 am, Sylvester Hesp <s.hes...@SPAMoisyn.nlwrote:
Juha Nieminen wrote:
Sylvester Hesp wrote:
Besides that,
keep in mind that 'inline' is only a hint to the compiler
It's not *only* a hint. It does more than that (specifically
related to linking).
Yes I might've been a bit unclear. I wasn't talking about the inline
keyword in general, I was talking about the actual process of function
inlining by the compiler.
- Sylvester
If you see the third paragraph in my reply there i have mentioned why
it is bad.
When you will look at the number of lines in the constructor you will
feel it should be allowed, but an object construction results in
calling so many constructor calls (of all composed objects and of all
base classes and their composed objects).
Yes i agree with your point that it is just a hint to the compiler. I
don't know if there is some other reason as well for this.
Regards
Vineet
Vineet Chawla wrote:
On May 25, 4:07 am, Sylvester Hesp <s.hes...@SPAMoisyn.nlwrote:
>Juha Nieminen wrote:
>>Sylvester Hesp wrote:
Besides that,
keep in mind that 'inline' is only a hint to the compiler
It's not *only* a hint. It does more than that (specifically
related to linking).
Yes I might've been a bit unclear. I wasn't talking about the inline
keyword in general, I was talking about the actual process of function
inlining by the compiler.
- Sylvester
If you see the third paragraph in my reply there i have mentioned why
it is bad.
>> When you will look at the number of lines in the constructor you will
feel it should be allowed, but an object construction results in
calling so many constructor calls (of all composed objects and of all
base classes and their composed objects).
Yes i agree with your point that it is just a hint to the compiler. I
don't know if there is some other reason as well for this.
Regards
Vineet
The fact that you write a method, function or constructor inline does
*NOT* force the compiler to inline the code and cause 'massive code
bloat'. I would be very disappointed in such a stupid compiler.
People get so confused about inlining. As Juha said the meaning of
inline is to tell the compiler not to apply the 'one definition rule',
i.e. it means it's OK to put the function definition in a header file.
Whether it's a good idea to do this or not is primarily a style issue.
Whether a function's code is inlined is an optmization issue, and I
would exect a good compiler not to inline some functions I had declared
inline, and also to inline some functions I had not declared inline.
Both of these things are optmizations which the compiler can work out
for itself. VC++ 2005 does this.
john
On May 25, 8:12 am, John Harrison <john_androni...@hotmail.comwrote:
Vineet Chawla wrote:
On May 25, 4:07 am, Sylvester Hesp <s.hes...@SPAMoisyn.nlwrote:
Juha Nieminen wrote:
Sylvester Hesp wrote:
Besides that,
keep in mind that 'inline' is only a hint to the compiler
It's not *only* a hint. It does more than that (specifically
related to linking).
Yes I might've been a bit unclear. I wasn't talking about the inline
keyword in general, I was talking about the actual process of function
inliningby the compiler.
- Sylvester
If you see the third paragraph in my reply there i have mentioned why
it is bad.
> When you will look at the number of lines in the constructor you will
feel it should be allowed, but an object construction results in
calling so many constructor calls (of all composed objects and of all
base classes and their composed objects).
Yes i agree with your point that it is just a hint to the compiler. I
don't know if there is some other reason as well for this.
Regards
Vineet
The fact that you write a method, function or constructor inline does
*NOT* force the compiler to inline the code and cause 'massive code
bloat'. I would be very disappointed in such a stupid compiler.
People get so confused aboutinlining. As Juha said the meaning of
inline is to tell the compiler not to apply the 'one definition rule',
i.e. it means it's OK to put the function definition in a header file.
Whether it's a good idea to do this or not is primarily a style issue.
Whether a function's code is inlined is an optmization issue, and I
would exect a good compiler not to inline some functions I had declared
inline, and also to inline some functions I had not declared inline.
Both of these things are optmizations which the compiler can work out
for itself. VC++ 2005 does this.
john
Thanks for all the replies..... most of this is covered in the FAQ, i
was wondering whether the Constructor is a special case in particular,
i.e, If I have a simple, POD class, is there a reason not to inline
the constructor (except the standard reasons of not inlining...) ?
Thanks for the replies
Mike
On May 25, 9:55 am, Michael Hull <mikehul...@googlemail.comwrote:
[...]
Thanks for all the replies..... most of this is covered in the FAQ, i
was wondering whether the Constructor is a special case in particular,
i.e, If I have a simple, POD class, is there a reason not to inline
the constructor (except the standard reasons of not inlining...) ?
The main reason for the special rule concerning constructors
(and destructors) is that even if the function looks trivial, it
might not be, which is not normally the case for other
functions. At least one place I worked (a long time ago) did
have a rule in the coding guidelines against inlining
constructors and destructors.
Several things have changed since then. Projects have become
larger (so dependency management becomes more important),
function calls faster, and the most frequent general rule today
is not to inline anything until the profiler says to do so. On
the other hand, templates in the absense of export means that
the dependencies are there anyway, so some guidelines are more
liberal with regards to inlining template functions (where they
allow templates).
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze wrote:
On May 25, 9:55 am, Michael Hull <mikehul...@googlemail.comwrote:
[...]
>Thanks for all the replies..... most of this is covered in the FAQ, i
was wondering whether the Constructor is a special case in particular,
i.e, If I have a simple, POD class, is there a reason not to inline
the constructor (except the standard reasons of not inlining...) ?
The main reason for the special rule concerning constructors
(and destructors) is that even if the function looks trivial, it
might not be, which is not normally the case for other
functions. At least one place I worked (a long time ago) did
have a rule in the coding guidelines against inlining
constructors and destructors.
Just out of interest, what did those guidelines say about simple
aggregates containing lots of members that have no trivial
constructors?
struct Foo
{
Type1 a;
Type2 b;
Type3 c;
// etc.
};
It has no defined default constructor, so one is generated. But the
generated constructor can be very expensive, and you have no control
over whether it gets inlined. Did those guidelines said you should
define a non-inlined constructor to circumvent compiler inlining?
- Sylvester
>
It has no defined default constructor, so one is generated. But the
generated constructor can be very expensive, and you have no control
over whether it gets inlined.
You have no control in standard C++ over whether any
constructor/method/function gets inlined.
I feel I'm repeating myself here.
john
On 2007-05-25 06:33:44 -0700, Sylvester Hesp <s.******@SPAMoisyn.nlsaid:
Just out of interest, what did those guidelines say about simple
aggregates containing lots of members that have no trivial constructors?
struct Foo
{
Type1 a;
Type2 b;
Type3 c;
// etc.
};
It has no defined default constructor, so one is generated. But the
generated constructor can be very expensive, and you have no control
over whether it gets inlined.
Nor will you.
Did those guidelines said you should define a non-inlined constructor
to circumvent compiler inlining?
There is no way to prevent the inlining of *any* function (constructor or not).
--
Clark S. Cox III cl*******@gmail.com
On May 25, 3:33 pm, Sylvester Hesp <s.hes...@SPAMoisyn.nlwrote:
James Kanze wrote:
On May 25, 9:55 am, Michael Hull <mikehul...@googlemail.comwrote:
[...]
Thanks for all the replies..... most of this is covered in the FAQ, i
was wondering whether the Constructor is a special case in particular,
i.e, If I have a simple, POD class, is there a reason not to inline
the constructor (except the standard reasons of not inlining...) ?
The main reason for the special rule concerning constructors
(and destructors) is that even if the function looks trivial, it
might not be, which is not normally the case for other
functions. At least one place I worked (a long time ago) did
have a rule in the coding guidelines against inlining
constructors and destructors.
Just out of interest, what did those guidelines say about simple
aggregates containing lots of members that have no trivial
constructors?
struct Foo
{
Type1 a;
Type2 b;
Type3 c;
// etc.
};
It has no defined default constructor, so one is generated. But the
generated constructor can be very expensive, and you have no control
over whether it gets inlined. Did those guidelines said you should
define a non-inlined constructor to circumvent compiler inlining?
Yes. It goes back some, but there was a rule against using the
compiler generated defaults; every class was supposed to have an
explicit copy constuctor, destructor and assignment operator
(although the copy constuctor and assignment operator could be
private).
It's probably overdoing it, but memory was a lot scarcer back
then, so we worried about code bloat.
--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
John Harrison wrote:
>>
It has no defined default constructor, so one is generated. But the
generated constructor can be very expensive, and you have no control over
whether it gets inlined.
You have no control in standard C++ over whether any
constructor/method/function gets inlined.
I feel I'm repeating myself here.
Uhm, if you had followed the thread completely, you'll find that I
myself was the first to mention that you don't have any control over
it.
However, you have more control over what functions *not* to inline than
you have control over what functions *do* inline. Most compilers will
not inline functions of which the definition is not known at use-time.
E.g., when the function is defined in a separate translation unit.
- Sylvester
Sylvester Hesp wrote:
John Harrison wrote:
>>>
It has no defined default constructor, so one is generated. But the
generated constructor can be very expensive, and you have no control
over whether it gets inlined.
You have no control in standard C++ over whether any
constructor/method/function gets inlined.
I feel I'm repeating myself here.
Uhm, if you had followed the thread completely, you'll find that I
myself was the first to mention that you don't have any control over it.
True, apologies.
>
However, you have more control over what functions *not* to inline than
you have control over what functions *do* inline. Most compilers will
not inline functions of which the definition is not known at use-time.
E.g., when the function is defined in a separate translation unit.
- Sylvester
It's not that simple. VC++ 2005 does inline functions even when in
seperate translation units. They call it 'whole program optmisation',
its done by the linker of course.
john
On 25 May 2007 15:30:43 -0700, James Kanze wrote:
>On May 25, 3:33 pm, Sylvester Hesp <s.hes...@SPAMoisyn.nlwrote:
>James Kanze wrote:
On May 25, 9:55 am, Michael Hull <mikehul...@googlemail.comwrote:
[...]
Thanks for all the replies..... most of this is covered in the FAQ, i
was wondering whether the Constructor is a special case in particular,
i.e, If I have a simple, POD class, is there a reason not to inline
the constructor (except the standard reasons of not inlining...) ?
The main reason for the special rule concerning constructors
(and destructors) is that even if the function looks trivial, it
might not be, which is not normally the case for other
functions. At least one place I worked (a long time ago) did
have a rule in the coding guidelines against inlining
constructors and destructors.
>Just out of interest, what did those guidelines say about simple
aggregates containing lots of members that have no trivial
constructors?
>struct Foo
{
Type1 a;
Type2 b;
Type3 c;
// etc.
};
>It has no defined default constructor, so one is generated. But the
generated constructor can be very expensive, and you have no control
over whether it gets inlined. Did those guidelines said you should
define a non-inlined constructor to circumvent compiler inlining?
Yes.
I'm a bit surprised. I thought the answer would be that in general you
didn't *ask* for inlining (with the inline keyword, or by defining the
member function in-class). The idea being that one wouldn't waste time
writing code/making a request unless there was a reason (profiling)
for doing so.
And of course there's in general the fact that, request or not, the
compiler may pretty much inline whatever it wants.
>It goes back some, but there was a rule against using the
compiler generated defaults; every class was supposed to have an
explicit copy constuctor, destructor and assignment operator
(although the copy constuctor and assignment operator could be
private).
It's probably overdoing it, but memory was a lot scarcer back
then, so we worried about code bloat.
Yep. It looks like premature optimization to me. But, as you say, it's
an old guideline.
I think the current trend is to be as explicit as possible in pretty
much anything. Projects have become increasingly larger, and it seems
established that anything intentional is better spelled out in code as
"hey, maintenance programmer, it's me!... this was intentional!" :-)
Francis' proposal n1717 - Explicit class and default definitions,
about which I asked on comp.std.c++, explicit conversion operators,
explicit namespaces (fixing ADL) and others all go in this direction,
IMHO. Now, some of these won't make it into C++0x but, I guess, for
time constraints and other reasons, not because they weren't
considered useful.
--
Gennaro Prota -- C++ Developer, For Hire https://sourceforge.net/projects/breeze/
Gennaro Prota wrote:
On 25 May 2007 15:30:43 -0700, James Kanze wrote:
On May 25, 3:33 pm, Sylvester Hesp <s.hes...@SPAMoisyn.nlwrote:
Just out of interest, what did those guidelines say about simple
aggregates containing lots of members that have no trivial
constructors?
struct Foo
{
Type1 a;
Type2 b;
Type3 c;
// etc.
};
It has no defined default constructor, so one is generated. But the
generated constructor can be very expensive, and you have no control
over whether it gets inlined. Did those guidelines said you should
define a non-inlined constructor to circumvent compiler inlining?
Yes.
I'm a bit surprised. I thought the answer would be that in general you
didn't *ask* for inlining (with the inline keyword, or by defining the
member function in-class). The idea being that one wouldn't waste time
writing code/making a request unless there was a reason (profiling)
for doing so.
No. This was some fifteen years ago, the program was very close
to the limits of available memory, and code bloat was a serious
issue.
Today, of course, the situation is a bit different, and I doubt
that the rules would be quite so rigorous.
And of course there's in general the fact that, request or not, the
compiler may pretty much inline whatever it wants.
In theory, at least. In practice, 15 years ago, if the code for
a function wasn't present in the translation unit, that function
wouldn't be inlined.
Today, of course, and to a large degree, even back then, the
main reason for avoiding inlining---even to the point of
providing versions which do exactly what the compiler does, is
to reduce compiler dependencies. No one really cares whether a
function is inlined or not, but you don't want to have to
recompile all of the client code just because some minor
implementation detail has changed. And this still leads to
defining functions which the compiler would otherwise declare,
so that you can add additional behavior later without
recompiling the world. This obviously doesn't apply, however,
to "classes" that are just agglomerations of data, and given
compile times on modern machines, it likely doesn't apply to
small, or even medium size projects. (Although on most projects
I work on, "compile times" are conditionned by network speeds,
and not CPU speeds. And while there's been some improuvement
there, it is far from the same order of magnitude as that of
CPUs.)
It goes back some, but there was a rule against using the
compiler generated defaults; every class was supposed to have an
explicit copy constuctor, destructor and assignment operator
(although the copy constuctor and assignment operator could be
private).
It's probably overdoing it, but memory was a lot scarcer back
then, so we worried about code bloat.
Yep. It looks like premature optimization to me. But, as you say, it's
an old guideline.
And one that developped because we were having serious problems
with code bloat. (I don't know if it helped any, of course. I
rather suspect that the problems with code bloat were
elsewhere:-).)
--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Michael Hull <mi********@googlemail.comwrote:
Thanks for all the replies..... most of this is covered in the FAQ, i
was wondering whether the Constructor is a special case in particular,
i.e, If I have a simple, POD class, is there a reason not to inline
the constructor (except the standard reasons of not inlining...) ?
Just a note: as soon as you define your own constructor, it is no longer
a POD.
--
Marcus Kwok
Replace 'invalid' with 'net' to reply
On 26 May 2007 15:50:24 -0700, James Kanze wrote:
>Gennaro Prota wrote:
>On 25 May 2007 15:30:43 -0700, James Kanze wrote:
>On May 25, 3:33 pm, Sylvester Hesp <s.hes...@SPAMoisyn.nlwrote:
>Just out of interest, what did those guidelines say about simple
aggregates containing lots of members that have no trivial
constructors?
>struct Foo
{
Type1 a;
Type2 b;
Type3 c;
// etc.
};
>It has no defined default constructor, so one is generated. But the
generated constructor can be very expensive, and you have no control
over whether it gets inlined. Did those guidelines said you should
define a non-inlined constructor to circumvent compiler inlining?
>Yes.
>I'm a bit surprised. I thought the answer would be that in general you
didn't *ask* for inlining (with the inline keyword, or by defining the
member function in-class). The idea being that one wouldn't waste time
writing code/making a request unless there was a reason (profiling)
for doing so.
No. This was some fifteen years ago, the program was very close
to the limits of available memory, and code bloat was a serious
issue.
Ah, okay. I thought we were talking of guidelines established *before*
the start of the project.
>Today, of course, the situation is a bit different, and I doubt
that the rules would be quite so rigorous.
>And of course there's in general the fact that, request or not, the
compiler may pretty much inline whatever it wants.
In theory, at least. In practice, 15 years ago, if the code for
a function wasn't present in the translation unit, that function
wouldn't be inlined.
Yes. FWIW, I was thinking of it both ways though: it can inline "at
will" and refuse to inline at will.
>Today, of course, and to a large degree, even back then, the
main reason for avoiding inlining---even to the point of
providing versions which do exactly what the compiler does, is
to reduce compiler dependencies. No one really cares whether a
function is inlined or not, but you don't want to have to
recompile all of the client code just because some minor
implementation detail has changed. And this still leads to
defining functions which the compiler would otherwise declare,
so that you can add additional behavior later without
recompiling the world.
Sure. Which brought another idea to my mind: the standard proposals
about new syntaxes for explicitly requesting the generation of class
members all attack the declaration of the function. This means that if
you later have to switch to a user-defined implementation you have
still to change the header: they are just addressing the issue of
being explicit about the intent. I guess it would be more useful to
address the coupling issue and attack the definition instead, with
something like:
// .hpp
class X
{
...
X & operator=( const X & ); // "normal" declaration
};
// .cpp
X &
X::operator=( const X & ) = auto;
No?
--
Gennaro Prota -- C++ Developer, For Hire https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)
Marcus Kwok wrote:
Michael Hull <mi********@googlemail.comwrote:
>Thanks for all the replies..... most of this is covered in the FAQ, i
was wondering whether the Constructor is a special case in particular,
i.e, If I have a simple, POD class, is there a reason not to inline
the constructor (except the standard reasons of not inlining...) ?
Just a note: as soon as you define your own constructor, it is no longer
a POD.
Is that true?
BS ISO/IEC 14882:2003 (Second Edition)
3.9 (10) says that POD-structs are POD types, and 9 (4) says that a
POD-struct is an aggregate class which has no non-static data members of
type non-POD-struct, non-POD-union (or array of such types) or
reference, and has no user-defined copy assignment operator and no
user-defined destructor. There's no mention of constructors.
Is there a ban on constructors in a paragraph that I've missed?
* Charles Bailey:
Marcus Kwok wrote:
>>
Just a note: as soon as you define your own constructor, it is no longer
a POD.
Is that true?
BS ISO/IEC 14882:2003 (Second Edition)
3.9 (10) says that POD-structs are POD types, and 9 (4) says that a
POD-struct is an aggregate class which has no non-static data members of
type non-POD-struct, non-POD-union (or array of such types) or
reference, and has no user-defined copy assignment operator and no
user-defined destructor. There's no mention of constructors.
Is there a ban on constructors in a paragraph that I've missed?
Definition of aggregates, §8.5.1/1.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Alf P. Steinbach wrote:
* Charles Bailey:
>Marcus Kwok wrote:
>>>
Just a note: as soon as you define your own constructor, it is no longer
a POD.
Is that true?
BS ISO/IEC 14882:2003 (Second Edition)
3.9 (10) says that POD-structs are POD types, and 9 (4) says that a
POD-struct is an aggregate class which has no non-static data members
of type non-POD-struct, non-POD-union (or array of such types) or
reference, and has no user-defined copy assignment operator and no
user-defined destructor. There's no mention of constructors.
Is there a ban on constructors in a paragraph that I've missed?
Definition of aggregates, §8.5.1/1.
Ah, thanks. Looks like I've got some code to rewrite, now. I'm using
offsetof on a non-POD class. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Tony Vitonis |
last post by:
From what I can tell, VB.NET doesn't allow programmers to say
explicitly that they want a function to be inlined. Now, I'm a big fan
of factoring out duplicate code, but I don't want to do too...
|
by: glen_stark |
last post by:
Hi.
I'm just curious if there any warnings or caveats or whatever to be
aware of when inlining function object calls? If the answer is no, they
inline just like everything else, that's good...
|
by: gianguz |
last post by:
The question is about the possible use of inlining to improve
performance in a heavy multithreading environment (200+ threads).
If we have to work with applications in which threads aren't I/O...
|
by: Generic Usenet Account |
last post by:
While I have a very good feel for how inlining works, I fail to see how
in the world inlining can work if the inlined function is not described
"in place" in a header file, but rather defined in a...
|
by: Raphael |
last post by:
Hello,
I have 2 files
A.c : Defining a bunch of usefull functions
B.c : Defining a main that uses these ones.
I need to improve perfs :
I know that, if the caller and the functions called...
|
by: Elpoca |
last post by:
Hi:
What rules govern the inlining of templated functions and templated
class methods?
It has always been my understanding that both templated functions and
templated class methods were...
|
by: LuB |
last post by:
How judicious ought one be when inlining small methods.
I once read that in general, most compiles will only inline 'one'
level.
IE: if all the following methods were declared/defined as...
|
by: Lloyd Dupont |
last post by:
I have some code which looks like that:
public CornerStyle RectCornerMode
{
get { return this.GetValue<CornerStyle>(); }
set { this.SetValue<CornerStyle>(value); }
}
|
by: Yakov |
last post by:
I'd like a tool that performed inlining of function bodies of which do
not appear in the .h file.
Really.
gcc on Linux.
Yakov
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
