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 inline in
their respective classes, can I expect the compiler to try and inline
them all?
obj.GetSize()
{
a.GetLen()
{
b.GetHead();
{
c.CreateIterator();
I'm sorry if this is hard to understand visually. I'm just trying to
depict they the code would be logically 'copied' and embedded at
successive levels of the call stack.
<offtopic>
If I were more adept at GDB, or Visual Studio - I'd prefer to look at
the resulting ASSEMBLY to see for myself what it did. Maybe I can
execute the app in DEBUG mode and open the disassembly window - but
would that jump to the method declarations? I'm not as facile at
ASSEMBLY of the debugger as I wish. Suggestions or general rules?
</offtopic>
Contextually, I have written a wrapper class for a library that is
essentially composed of 'pass through' calls.
IE: I've created a C++ class interface over a set of C library calls.
struct GuiHelper
{
inline void SetWindowPos(int, int, int, int)
{
::SetWindowPos(...);
}
}
And I'm worried (per that article I seem to remember seeing) that if I
use any of these methods in my other functions - that I will have used
up my ONE inline call per function stack. In other word, if I use
these methods in other, inline calls, when will the compiler be apt to
eventually quit inlining things?
Quantitatively then, is judicious inlining important? or can I willy
nilly declare/define all very small tight methods as inline and be
confident that several small inlined methods calling each other will
likely, all be inlined.
--note: this also goes for Setters and Getters. I'm afraid of
supplying getX or getY methods for fear that anywhere they will be
used - they will use up the ONE level of inlining the compiler will
create - and consequently, might not be the best method of the stack
to have inlined.
Thanks in advance for any insight,
-Luther
21  1768 
LuB wrote:
How judicious ought one be when inlining small methods.
Keep in mind that inline is just a hint to the compiler. The compiler
has the freedom to choose either inline or not inline the specified
subroutine.
If your profiling indicates that inlining a subroutine can significantly
improve application performance, consider adding 'inline' declaration.
Fei
On Mar 30, 11:42 am, Fei Liu <fei...@aepnetworks.comwrote:
LuB wrote:
How judicious ought one be when inlining small methods.
Keep in mind that inline is just a hint to the compiler. The compiler
has the freedom to choose either inline or not inline the specified
subroutine.
If your profiling indicates that inlining a subroutine can significantly
improve application performance, consider adding 'inline' declaration.
Fei
Yes, I do know that it is just a hint.
Assume I am writing a library for someone else to use.
And, assume my classes in turn, wrap up some other library (MFC, WTL,
take your pick). I am essentially wrapping up some library ... writing
pass through calls ... and then handing the resulting class to someone
else. Maybe selling it someone else.
Will I be hurting someone else's code - by declaring and implementing
as "inline" all the simple, one line pass through operations in my
library.
-Luther
LuB wrote:
On Mar 30, 11:42 am, Fei Liu <fei...@aepnetworks.comwrote:
>LuB wrote:
>>How judicious ought one be when inlining small methods.
Keep in mind that inline is just a hint to the compiler. The compiler
has the freedom to choose either inline or not inline the specified
subroutine.
If your profiling indicates that inlining a subroutine can significantly
improve application performance, consider adding 'inline' declaration.
Fei
Yes, I do know that it is just a hint.
Assume I am writing a library for someone else to use.
And, assume my classes in turn, wrap up some other library (MFC, WTL,
take your pick). I am essentially wrapping up some library ... writing
pass through calls ... and then handing the resulting class to someone
else. Maybe selling it someone else.
Will I be hurting someone else's code - by declaring and implementing
as "inline" all the simple, one line pass through operations in my
library.
-Luther
How can it hurt someone else's code? Inlining only happens at link
time...What makes you think it might hurt someone else's code?
LuB wrote:
If I were more adept at GDB, or Visual Studio - I'd prefer to look at
the resulting ASSEMBLY to see for myself what it did. Maybe I can
execute the app in DEBUG mode and open the disassembly window - but
would that jump to the method declarations? I'm not as facile at
ASSEMBLY of the debugger as I wish. Suggestions or general rules?
</offtopic>
As a general rule, if you care about this things you must to look at the
code generated. Be an adept or not is optional.
--
Salu2
On Mar 30, 11:56 am, Fei Liu <fei...@aepnetworks.comwrote:
LuB wrote:
On Mar 30, 11:42 am, Fei Liu <fei...@aepnetworks.comwrote:
LuB wrote:
How judicious ought one be when inlining small methods.
Keep in mind that inline is just a hint to the compiler. The compiler
has the freedom to choose either inline or not inline the specified
subroutine.
If your profiling indicates that inlining a subroutine can significantly
improve application performance, consider adding 'inline' declaration.
Fei
Yes, I do know that it is just a hint.
Assume I am writing a library for someone else to use.
And, assume my classes in turn, wrap up some other library (MFC, WTL,
take your pick). I am essentially wrapping up some library ... writing
pass through calls ... and then handing the resulting class to someone
else. Maybe selling it someone else.
Will I be hurting someone else's code - by declaring and implementing
as "inline" all the simple, one line pass through operations in my
library.
-Luther
How can it hurt someone else's code? Inlining only happens at link
time...What makes you think it might hurt someone else's code?
At the risk of being wordy, I think my perception is wrong .. and
maybe this is a question for a *compiler* newsgroup:
But, my fear was that ... in any given method, only one nested call
can be inlined. Given the following example, could the compiler inline
ALL of the methods? or is it somehow limited to just one. Notice how
they are nested/successive calls? Inline calling an inline ... etc. I
got the impression that the compiler was physically limited ... that
it wouldn't inline more than one of these methods in this particular
call graph.
class BigMethods
{
void methodA()
{
int len = myList.GetSize();
}
};
class MyList
{
inline void GetSize() const
{
return impl_.size();
}
ListImpl<Timpl_;
};
template<typename T>
class ListImpl
{
inline void size() const
{
return impl_.size();
}
std::list<Timpl_;
};
If that is the case, then I might be more apt (for pure performance
sake) to use direct access for some things and 'save' my single
possible inline call for something I can't easily replace with a
property?
class BigMethods
{
void methodA()
{
int len = myList.impl_.GetSize();
}
};
class MyList
{
inline void GetSize() const
{
return impl_.size();
}
ListImpl<Timpl_;
};
template<typename T>
class ListImpl
{
inline void size() const
{
return impl_.size();
}
std::list<Timpl_;
};
Please ignore any technical problems with the above psuedocode - my
underlying question is in regards to inlining hints and compiler
limitations.
If I'm limited to one inline method per call graph - maybe I won't use
a low level wrapper - since those inline methods would use up my
single inline function per call.
Sorry if this explanation is confusing. HTH.
-Luther
On Mar 30, 1:35 pm, Julián Albo <JULIANA...@terra.eswrote:
LuB wrote:
If I were more adept at GDB, or Visual Studio - I'd prefer to look at
the resulting ASSEMBLY to see for myself what it did. Maybe I can
execute the app in DEBUG mode and open the disassembly window - but
would that jump to the method declarations? I'm not as facile at
ASSEMBLY of the debugger as I wish. Suggestions or general rules?
</offtopic>
As a general rule, if you care about this things you must to look at the
code generated. Be an adept or not is optional.
--
Salu2
What does it mean:
Be an adept or not is optional.
Thanks,
-Luther
On Mar 30, 1:35 pm, Julián Albo <JULIANA...@terra.eswrote:
LuB wrote:
If I were more adept at GDB, or Visual Studio - I'd prefer to look at
the resulting ASSEMBLY to see for myself what it did. Maybe I can
execute the app in DEBUG mode and open the disassembly window - but
would that jump to the method declarations? I'm not as facile at
ASSEMBLY of the debugger as I wish. Suggestions or general rules?
</offtopic>
As a general rule, if you care about this things you must to look at the
code generated. Be an adept or not is optional.
Yes. I agree with you. The proof is in the pudding.
>
--
Salu2
-Luther
Fei Liu wrote:
>
How can it hurt someone else's code? Inlining only happens at link
time...What makes you think it might hurt someone else's code?
Says who?
--
Ian Collins.
LuB wrote:
>
But, my fear was that ... in any given method, only one nested call
can be inlined.
What gives rise to that fear?
--
Ian Collins.
On Mar 30, 3:24 pm, Ian Collins <ian-n...@hotmail.comwrote:
LuB wrote:
But, my fear was that ... in any given method, only one nested call
can be inlined.
What gives rise to that fear?
--
Ian Collins.
Sounds like it is ill founded. I seemed to remember reading it
somewhere. Maybe it was a limitation of one particular compiler.
Thanks for all the responses. I'll try to do some profiling.
-Luther
On Mar 30, 7:36 pm, "LuB" <lutherba...@yahoo.comwrote:
How judicious ought one be when inlining small methods.
That's simple: you never inline anything until the profiler says
you must.
I once read that in general, most compiles will only inline 'one'
level.
Not the ones I use. G++ (the only one I've verified) handles 40
some levels if you inline a recursive function.
In general, any limits will be more because of the complexity of
the program to begin with. (Some older compilers wouldn't
inline anything with a switch statement, of course.)
On the other hand, most (but not all) compilers require the
definition of the function to be present in the compilation unit
in order to inline. Which, of course, introduces significant
compiler dependencies, and has a significant negative effect on
programmer productivity.
Most coding guidelines I've seen ban inline functions
completely, for this reason.
--
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:
On the other hand, most (but not all) compilers require the
definition of the function to be present in the compilation unit
in order to inline. Which, of course, introduces significant
compiler dependencies, and has a significant negative effect on
programmer productivity.
Does it?
General rule: "of course", "as we all know", and the like, most likely
mean "fishy statement ahead".
Most coding guidelines I've seen ban inline functions
completely, for this reason.
No template programming, then...
Cheers,
- Alf
--
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?
James Kanze wrote:
On Mar 30, 7:36 pm, "LuB" <lutherba...@yahoo.comwrote:
>>How judicious ought one be when inlining small methods.
That's simple: you never inline anything until the profiler says
you must.
Considering 'inline' is a hint and modern compilers will inline where
they see fit, that's kind of a meaningless statement. Or are you
referring to changing the code, bringing functions into the current
compilation unit for example?
>
Most coding guidelines I've seen ban inline functions
completely, for this reason.
Odd, I've never seen that. As Alf said, it would make using templates
kind of hard!
--
James Kanze (Gabi Software) email: ja*********@gmail.com
Your signature is malformed, the delimiter should be "-- ".
--
Ian Collins.
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@p15g2000hsd.googlegr oups.com...
On Mar 30, 7:36 pm, "LuB" <lutherba...@yahoo.comwrote:
"How judicious ought one be when inlining small methods.
That's simple: you never inline anything until the profiler says
you must.
I once read that in general, most compiles will only inline 'one'
level.
Not the ones I use. G++ (the only one I've verified) handles 40
some levels if you inline a recursive function.
In general, any limits will be more because of the complexity of
the program to begin with. (Some older compilers wouldn't
inline anything with a switch statement, of course.)
On the other hand, most (but not all) compilers require the
definition of the function to be present in the compilation unit
in order to inline. Which, of course, introduces significant
compiler dependencies, and has a significant negative effect on
programmer productivity.
Most coding guidelines I've seen ban inline functions
completely, for this reason."
************* (I hate it when OE refuses to quote correctly!) ***********
Which begs the question: why is there no 'outline' keyword? Combined with
code-folding editors, it would make it easier to organize some class header
that have just a few or one outline function(s) (one file instead of 2 to
manage). Most compilers do seem to have an "outline all inline functions"
switch though. A curious experiment would be "inline all outline functions"
too. I agree that in general, inlining functions is bad because it increases
dependencies. A lot of code starts out that way though during development
until it evolves to the point where the major functions are moved to a .cpp
file.
John
JohnQ wrote:
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@p15g2000hsd.googlegr oups.com...
Most coding guidelines I've seen ban inline functions
completely, for this reason."
************* (I hate it when OE refuses to quote correctly!) ***********
Then either get a better client, or do what the other poor unfortunate
OE users do to quote correctly.
Which begs the question: why is there no 'outline' keyword? Combined with
code-folding editors, it would make it easier to organize some class header
that have just a few or one outline function(s) (one file instead of 2 to
manage). Most compilers do seem to have an "outline all inline functions"
switch though.
What purpose would it serve?
I agree that in general, inlining functions is bad because it increases
dependencies.
Nonsense, C++ would be pretty neutered without inlining of trivial
methods. Just compare the performance of an application with inlining
off compared to the same code with it on.
--
Ian Collins.
"Ian Collins" <ia******@hotmail.comwrote in message
news:57*************@mid.individual.net...
JohnQ wrote:
>"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@p15g2000hsd.googleg roups.com...
Most coding guidelines I've seen ban inline functions
completely, for this reason."
************* (I hate it when OE refuses to quote correctly!) ***********
Then either get a better client, or do what the other poor unfortunate
OE users do to quote correctly.
>Which begs the question: why is there no 'outline' keyword? Combined with
code-folding editors, it would make it easier to organize some class
header
that have just a few or one outline function(s) (one file instead of 2 to
manage). Most compilers do seem to have an "outline all inline functions"
switch though.
What purpose would it serve?
Reduction of the number of source files.
>
>I agree that in general, inlining functions is bad because it increases
dependencies.
Nonsense, C++ would be pretty neutered without inlining of trivial
methods.
I wasn't talking about trivial methods. I was talking, obviously, about
functions that required additional header files.
John
On Mar 31, 4:03 pm, "Alf P. Steinbach" <a...@start.nowrote:
* James Kanze:
On the other hand, most (but not all) compilers require the
definition of the function to be present in the compilation unit
in order to inline. Which, of course, introduces significant
compiler dependencies, and has a significant negative effect on
programmer productivity.
Does it?
Measurably.
General rule: "of course", "as we all know", and the like, most likely
mean "fishy statement ahead".
In this case, it means something that any programmer with
experience has run into. At least, if he's worked on programs
of any reasonable size.
Most coding guidelines I've seen ban inline functions
completely, for this reason.
No template programming, then...
Not at the application level, no.
--
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
On Mar 31, 10:52 pm, Ian Collins <ian-n...@hotmail.comwrote:
James Kanze wrote:
On Mar 30, 7:36 pm, "LuB" <lutherba...@yahoo.comwrote:
>How judicious ought one be when inlining small methods.
That's simple: you never inline anything until the profiler says
you must.
Considering 'inline' is a hint and modern compilers will inline where
they see fit, that's kind of a meaningless statement. Or are you
referring to changing the code, bringing functions into the current
compilation unit for example?
I'm refering to the use of the "inline" keyword, of course.
You're right that some modern compilers will inline without it,
across compilation units, and according to the profiler data.
Most coding guidelines I've seen ban inline functions
completely, for this reason.
Odd, I've never seen that. As Alf said, it would make using templates
kind of hard!
It does.
As with any rule, it can be violated when there are overriding
reasons to do so. But these are rare in application code, and I
can't remember every having seen a template definition in
application code in production software.
In practice, this isn't that restricting. "Application"
generally means dealing with known types anyway, unless you need
dynamic dispatch. Templates tend to be restricted to lower
level, very stable libraries. Libraries that are considered so
fundamental that 1) upgrading to a more recent version is
considered a major undertaking, much like moving to a new
version of the compiler and 2) if you do it, you recompile
everything and run the entire regression test suite again,
before going further.
--
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:
On Mar 31, 4:03 pm, "Alf P. Steinbach" <a...@start.nowrote:
>* James Kanze:
>>On the other hand, most (but not all) compilers require the
definition of the function to be present in the compilation unit
in order to inline. Which, of course, introduces significant
compiler dependencies, and has a significant negative effect on
programmer productivity.
>Does it?
Measurably.
>General rule: "of course", "as we all know", and the like, most likely
mean "fishy statement ahead".
In this case, it means something that any programmer with
experience has run into. At least, if he's worked on programs
of any reasonable size.
I think that must be specific to the environment(s) you're used to,
and/or a statistical correlation between not-abiding-by-rules and low
quality code (which would not be surprising). I've seen the latter
effect, but not any problem from inlining per se. However, the few
sizeable C++ systems I've worked on have had far more serious problems,
obscuring any possible effect from inlining.
When you write "significant compiler dependencies" I think you mean
public module dependencies, i.e. undesirable public coupling, dragging
in headers that aren't really needed for the module's interface.
One way to deal with that is to focus on the undesirable coupling
instead of a language feature that one thinks is causing it.
>>Most coding guidelines I've seen ban inline functions
completely, for this reason.
>No template programming, then...
Not at the application level, no.
ITYM that any template programming is by definition not part of the
application level. Then, not surprisingly, the application level turns
out to be a template free zone, except for use of (by definition)
library templates.
--
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?
James Kanze wrote:
On Mar 31, 10:52 pm, Ian Collins <ian-n...@hotmail.comwrote:
>>James Kanze wrote:
>>>On Mar 30, 7:36 pm, "LuB" <lutherba...@yahoo.comwrote:
>>>>How judicious ought one be when inlining small methods.
>>>That's simple: you never inline anything until the profiler says
you must.
>>Considering 'inline' is a hint and modern compilers will inline where
they see fit, that's kind of a meaningless statement. Or are you
referring to changing the code, bringing functions into the current
compilation unit for example?
I'm refering to the use of the "inline" keyword, of course.
You're right that some modern compilers will inline without it,
across compilation units, and according to the profiler data.
I see. In practice, I have found the "inline" keyword to be of little
use, the compiler is free to ignore it and in most case one has to jump
through hoops to get the compiler to inline a function that it doesn't
consider appropriate. So I never use it.
>
>>>Most coding guidelines I've seen ban inline functions
completely, for this reason.
>>Odd, I've never seen that. As Alf said, it would make using templates
kind of hard!
It does.
As with any rule, it can be violated when there are overriding
reasons to do so. But these are rare in application code, and I
can't remember every having seen a template definition in
application code in production software.
I guess that's a point of style, or I don't write what you consider
"Application" code. I invariably break into templates before too long.
Just about everything I have ever written contains at least some
components that are generic.
If you exclude templates, do you also exclude the standard library?
>
--
James Kanze (Gabi Software) email: ja*********@gmail.com
Still broken!
--
Ian Collins.
On 1 Apr 2007 03:37:19 -0700, "James Kanze" <ja*********@gmail.comwrote:
>On Mar 31, 10:52 pm, Ian Collins <ian-n...@hotmail.comwrote:
>James Kanze wrote:
On Mar 30, 7:36 pm, "LuB" <lutherba...@yahoo.comwrote:
>>How judicious ought one be when inlining small methods.
That's simple: you never inline anything until the profiler says
you must.
>Considering 'inline' is a hint and modern compilers will inline where
they see fit, that's kind of a meaningless statement. Or are you
referring to changing the code, bringing functions into the current
compilation unit for example?
I'm refering to the use of the "inline" keyword, of course.
You're right that some modern compilers will inline without it,
across compilation units, and according to the profiler data.
Some compilers I've worked with use the "inline" keyword to bias the "inlining
score" that is used to determine if a function is going to be inlined.
Most of the compilers I've worked with require the code to be visible in the
compilation unit for the inlining to take place (i.e. no link-time inlining).
In such cases, the "inline" keyword is required to prevent the "multiple
definition" error from arising.
>
Most coding guidelines I've seen ban inline functions
completely, for this reason.
>Odd, I've never seen that. As Alf said, it would make using templates
kind of hard!
It does.
As with any rule, it can be violated when there are overriding
reasons to do so. But these are rare in application code, and I
can't remember every having seen a template definition in
application code in production software.
In practice, this isn't that restricting. "Application"
generally means dealing with known types anyway, unless you need
dynamic dispatch. Templates tend to be restricted to lower
level, very stable libraries. Libraries that are considered so
fundamental that 1) upgrading to a more recent version is
considered a major undertaking, much like moving to a new
version of the compiler and 2) if you do it, you recompile
everything and run the entire regression test suite again,
before going further.
I disagree with your assessment, but I suppose it depends on your application
domain. I find that almost all of the "application" code I've worked on use
templates at the application level.
Do you mean that you don't _use_ templates at the application level (not even
using their definitions from a library), or that you merely don't _define_
application-level templated entities?
-dr 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: 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: 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: Michael Hull |
last post by:
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...
|
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: sh.vipin |
last post by:
is there any way to find out number of bytes freed on a particular
free() call in C
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
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: 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,...
| |
