initializer list type deduction rules

[Juha Nieminen]

The exact type deduction rules for initializer lists are not completely
clear to me. For example, in an expression like this the type is deduced
without problems:

std::pair<unsigned, unsigned> values[] =
{ { 1, 2 }, { 2, 3 }, { 3, 4 } };

However, here it's not:

for(const std::pair<unsigned, unsigned>& value:
{ { 1, 2 }, { 2, 3 }, { 3, 4 } })

Sometimes it's useful to loop through a list of values using a range-based
for loop one-liner:

for(int i: { 10, 2, 15, 28, 3 })

However, because of the limitations of deducing the type of the
initializer list in such range-based for expressions, that's not always
that simple, as in the second example above.

Even in such a simple case as this:

unsigned values[] = { 1, 2, 3, 5 10 };

vs. this:

for(unsigned value: { 1, 2, 3, 5, 10 })

if you turn on enough compiler warnings eg. gcc will warn about the
second one (converting 'int' to 'unsigned' may change the sign of the
result) but not the first one. I believe that in the first case the
compiler deduces the type of the initializer list to be 'unsigned'
(even though the literals themselves are of type 'int'), while in
the second case it does not.

I kind of grasp the difference between these two cases, but it just
makes range-based for loops less convenient when it's like this.

[Bo Persson]

I beleive the rules are pretty clear, but that the use cases are not
equally common.

For example, in

unsigned values[] = { 1, 2, 3, 5 10 };

you would get tons of false warnings in many programs. So the compiler
has gotten code to verify that there are in fact no negative values, and
to suppress the warning.

The same *could* happen for the ranged-for case, but apparently it does
not. My guess is that there a significantly fewer cases, and the
"warning suppression" has not gotten a high enough priority.

[Öö Tiib]

On Tuesday, 9 August 2022 at 10:54:49 UTC+3, Juha Nieminen wrote:
> The exact type deduction rules for initializer lists are not completely
> clear to me. For example, in an expression like this the type is deduced
> without problems:
>
> std::pair<unsigned, unsigned> values[] =
> { { 1, 2 }, { 2, 3 }, { 3, 4 } };
>
> However, here it's not:
>
> for(const std::pair<unsigned, unsigned>& value:
> { { 1, 2 }, { 2, 3 }, { 3, 4 } })

Initialiser lists were broken at birth. Part of it was thanks to the
legacy looseness with initialising various things (like multidimensional
arrays), part thanks to new looseness added by C++11. So being more
explicit just helps everything.

// declare types ahead ... something meaningful in context
using Works = std::initializer_list<std::pair<unsigned, unsigned>>;
// then use your types
for(auto const& value: Works{{1, 2}, {2, 3}, {3, 4}, {4, 5}})
std::cout << value.first << " " << value.second << '\n';

Otherwise it is too dim what it is that you initialise.

[Mut...@dastardlyhq.com]

On Tue, 9 Aug 2022 09:00:06 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Tuesday, 9 August 2022 at 10:54:49 UTC+3, Juha Nieminen wrote:
>> The exact type deduction rules for initializer lists are not completely
>> clear to me. For example, in an expression like this the type is deduced
>> without problems:
>>
>> std::pair<unsigned, unsigned> values[] =
>> { { 1, 2 }, { 2, 3 }, { 3, 4 } };
>>
>> However, here it's not:
>>
>> for(const std::pair<unsigned, unsigned>& value:
>> { { 1, 2 }, { 2, 3 }, { 3, 4 } })
>
>Initialiser lists were broken at birth. Part of it was thanks to the
>legacy looseness with initialising various things (like multidimensional
>arrays), part thanks to new looseness added by C++11. So being more
>explicit just helps everything.
>
>// declare types ahead ... something meaningful in context
>using Works = std::initializer_list<std::pair<unsigned, unsigned>>;

Or less confusingly

typedef std::initializer_list<std::pair<unsigned, unsigned>> Works;

"typedef" has one job to do. "using" was already overloaded and the point
of overloading it again simply to duplicate typedef is frankly a mystery to me
and it just makes C++ even more of a confusing mess.

[Andrey Tarasevich]

On 8/9/2022 12:54 AM, Juha Nieminen wrote:
>
> Even in such a simple case as this:
>
> unsigned values[] = { 1, 2, 3, 5 10 };
>
> vs. this:
>
> for(unsigned value: { 1, 2, 3, 5, 10 })
>
> if you turn on enough compiler warnings eg. gcc will warn about the
> second one (converting 'int' to 'unsigned' may change the sign of the
> result) but not the first one. I believe that in the first case the
> compiler deduces the type of the initializer list to be 'unsigned'
> (even though the literals themselves are of type 'int'), while in
> the second case it does not.
>

There's no point in searching for any hidden logic in this or trying to
guess the reason. The message you describe is not a standard diagnostic
message, i.e. it is not in any way mandated by the standard. Both
examples are perfectly valid as is. No diagnostic of any kind is expected.

The two contexts are significantly different semantically, which means
that they are likely handled by two different parts of the compiler. The
message is just a whim of some developer, who inserted that message in
one context and didn't bother to do something similar to the other context.

--
Best regards,
Andrey

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
> Or less confusingly
>
> typedef std::initializer_list<std::pair<unsigned, unsigned>> Works;
>
> "typedef" has one job to do. "using" was already overloaded and the point
> of overloading it again simply to duplicate typedef is frankly a mystery to me
> and it just makes C++ even more of a confusing mess.

Yeah, because

typedef double(*Ptr)(int, int);

is so much less confusing than

using Ptr = double(*)(int, int);

(I bet half of C++ and even C programmers wouldn't even know how to create
a function pointer alias using typedef.)

[Juha Nieminen]

You are missing my point.

The point is not the warning itself. The point is that the warning
demonstrates that in the former case the values are treated as unsigned
ints, while in the second case they are treated as signed ints (even
though the variable is of type unsigned).

[Paavo Helde]

I admit I would still need to look up this syntax every time, be it
either 'typedef' or 'using' ;-)

Luckily, after C+11 I have discovered I do not need function pointers at
all, because when declaring a callback interface I always need to add
the possibility to pass also callback data., i.e. I always need
functors. When declaring, it's now either 'auto' or
'std::function<double(int,int)>', and when calling, it's typically a lambda.

std::function declaration syntax I can actually use without looking it
up ;-)

[Juha Nieminen]

Paavo Helde <ees...@osa.pri.ee> wrote:
> Luckily, after C+11 I have discovered I do not need function pointers at
> all, because when declaring a callback interface I always need to add
> the possibility to pass also callback data., i.e. I always need
> functors. When declaring, it's now either 'auto' or
> 'std::function<double(int,int)>', and when calling, it's typically a lambda.
>
> std::function declaration syntax I can actually use without looking it
> up ;-)

Now you'll have to explain the difference between

double(int,int)
and

double(*)(int,int)

(because they aren't the same thing).

Why is it that you have to write std::function<int(std::FILE*)> but
std::unique_ptr<std::FILE, int(*)(std::FILE*)>?

[Mut...@dastardlyhq.com]

And how many would know how to do it with using?

[Öö Tiib]

I have no problems reading neither "using" nor "typedef". As I rarely work on
totally new code-base I try to write what code-base already uses for
consistency.

Confusion can arise when both forms of type alias declaration are used
side-by-side. That generates questions why both are used, what kind of
differences these have, is one or other "better" and should we
so change one of those and which one. Extremely pointless waste of time.

Then proposed will be that we put clang-tidy into toolchain. It will
automatically replace all typedefs with using before building and so
one commit later there will be no typedefs in any code that team
maintains manually. It is attractive to people bored of that
bike-shedding. Tools that automatically replace using with typedef
are missing so there are no way to resolve it sanely in other direction.

[Mut...@dastardlyhq.com]

On Wed, 10 Aug 2022 00:40:54 -0700 (PDT)

=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Tuesday, 9 August 2022 at 19:06:57 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Tue, 9 Aug 2022 09:00:06 -0700 (PDT)

>> >using Works = std::initializer_list<std::pair<unsigned, unsigned>>;
>> Or less confusingly
>>
>> typedef std::initializer_list<std::pair<unsigned, unsigned>> Works;
>>
>> "typedef" has one job to do. "using" was already overloaded and the point
>> of overloading it again simply to duplicate typedef is frankly a mystery to
>me
>> and it just makes C++ even more of a confusing mess.
>
>I have no problems reading neither "using" nor "typedef". As I rarely work on
>totally new code-base I try to write what code-base already uses for
>consistency.
>
>Confusion can arise when both forms of type alias declaration are used
>side-by-side. That generates questions why both are used, what kind of

The more pertinent question is why the C++ committee felt the need to
duplicate the functionality of typedef.

>Then proposed will be that we put clang-tidy into toolchain. It will
>automatically replace all typedefs with using before building and so
>one commit later there will be no typedefs in any code that team
>maintains manually. It is attractive to people bored of that
>bike-shedding. Tools that automatically replace using with typedef
>are missing so there are no way to resolve it sanely in other direction.

On a large C++ unix project that only uses typedefs for defining types:

grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")

will list all your definitions. Putting "using" in there will probably bring
back a whole load of crap you don't want.

[Öö Tiib]

On Wednesday, 10 August 2022 at 10:55:25 UTC+3, Mut...@dastardlyhq.com wrote:
> On Wed, 10 Aug 2022 00:40:54 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
> >On Tuesday, 9 August 2022 at 19:06:57 UTC+3, Mut...@dastardlyhq.com wrote:
> >> On Tue, 9 Aug 2022 09:00:06 -0700 (PDT)
> >> >using Works = std::initializer_list<std::pair<unsigned, unsigned>>;
> >> Or less confusingly
> >>
> >> typedef std::initializer_list<std::pair<unsigned, unsigned>> Works;
> >>
> >> "typedef" has one job to do. "using" was already overloaded and the point
> >> of overloading it again simply to duplicate typedef is frankly a mystery to
> >me
> >> and it just makes C++ even more of a confusing mess.
> >
> >I have no problems reading neither "using" nor "typedef". As I rarely work on
> >totally new code-base I try to write what code-base already uses for
> >consistency.
> >
> >Confusion can arise when both forms of type alias declaration are used
> >side-by-side. That generates questions why both are used, what kind of
>
> The more pertinent question is why the C++ committee felt the need to
> duplicate the functionality of typedef.

That ship has sailed over decade ago and the answer was that there
was need to create alias-templates that typedef does not let to.

> >Then proposed will be that we put clang-tidy into toolchain. It will
> >automatically replace all typedefs with using before building and so
> >one commit later there will be no typedefs in any code that team
> >maintains manually. It is attractive to people bored of that
> >bike-shedding. Tools that automatically replace using with typedef
> >are missing so there are no way to resolve it sanely in other direction.
>
> On a large C++ unix project that only uses typedefs for defining types:
>
> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")
>
> will list all your definitions. Putting "using" in there will probably bring
> back a whole load of crap you don't want.

Majority are probably indifferent ... usage of grep to find aliases might
feel like usage of #define to declare those. It is two levels below tools
that their IDEs provide with keypress or two.

[Mut...@dastardlyhq.com]

On Wed, 10 Aug 2022 01:13:05 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Wednesday, 10 August 2022 at 10:55:25 UTC+3, Mut...@dastardlyhq.com wrote:
>> The more pertinent question is why the C++ committee felt the need to
>> duplicate the functionality of typedef.
>
>That ship has sailed over decade ago and the answer was that there
>was need to create alias-templates that typedef does not let to.

And the reason typedef couldn't have been extended to do them was.... ?

>> >Then proposed will be that we put clang-tidy into toolchain. It will
>> >automatically replace all typedefs with using before building and so
>> >one commit later there will be no typedefs in any code that team
>> >maintains manually. It is attractive to people bored of that
>> >bike-shedding. Tools that automatically replace using with typedef
>> >are missing so there are no way to resolve it sanely in other direction.
>>
>> On a large C++ unix project that only uses typedefs for defining types:
>>
>> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")
>>
>> will list all your definitions. Putting "using" in there will probably bring
>
>> back a whole load of crap you don't want.
>
>Majority are probably indifferent ... usage of grep to find aliases might
>feel like usage of #define to declare those. It is two levels below tools
>that their IDEs provide with keypress or two.

Clearly you've never done much serious development on *nix or had to develop/
debug remotely down an ssh link.

And FWIW Eclipse is a slow steaming bug ridden POC.

[Öö Tiib]

On Wednesday, 10 August 2022 at 11:21:32 UTC+3, Mut...@dastardlyhq.com wrote:
> On Wed, 10 Aug 2022 01:13:05 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
> >On Wednesday, 10 August 2022 at 10:55:25 UTC+3, Mut...@dastardlyhq.com wrote:
> >> The more pertinent question is why the C++ committee felt the need to
> >> duplicate the functionality of typedef.
> >
> >That ship has sailed over decade ago and the answer was that there
> >was need to create alias-templates that typedef does not let to.
>
> And the reason typedef couldn't have been extended to do them was.... ?

No one is capable to come out with suggestion how. Are you?
The typedef can be used by language rules something like that:

typedef int int_t, *intp_t, (&fp)(int, ulong), arr_t[10];

That declares aliases int_t, intp_t, fp and arr_t. How you extend it to
declare aliases int_t<K>, intp_t<L>, fp<M> and arr_t<N> instead?

> >> >Then proposed will be that we put clang-tidy into toolchain. It will
> >> >automatically replace all typedefs with using before building and so
> >> >one commit later there will be no typedefs in any code that team
> >> >maintains manually. It is attractive to people bored of that
> >> >bike-shedding. Tools that automatically replace using with typedef
> >> >are missing so there are no way to resolve it sanely in other direction.
> >>
> >> On a large C++ unix project that only uses typedefs for defining types:
> >>
> >> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")
> >>
> >> will list all your definitions. Putting "using" in there will probably bring
> >
> >> back a whole load of crap you don't want.
> >
> >Majority are probably indifferent ... usage of grep to find aliases might
> >feel like usage of #define to declare those. It is two levels below tools
> >that their IDEs provide with keypress or two.
>
> Clearly you've never done much serious development on *nix or had to develop/
> debug remotely down an ssh link.

Majority are probably still indifferent. What I have or haven't done ever is
even less relevant to their opinion about usefulness of grep for finding aliases
in code-base.

> And FWIW Eclipse is a slow steaming bug ridden POC.

OK ... then use CLion, works fine on Linux ... I think it was less than $200/year.

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
> The more pertinent question is why the C++ committee felt the need to
> duplicate the functionality of typedef.

typedef is confusing. The average person learning C or C++ very easily
gets the impression that typedef works like:

typedef TheType AliasName;

But that's not at all how it works. It just happens to conform to that
form with elementary types (because that's how elementary type variables
are declared), but when such a person finds the need to create a type
alias eg. for a function pointer (or any of the other more complicated
types, like array pointers), he'll be highly confused because the
above pattern doesn't work with them. A bit of research needs to be
done to find out that eg. a function pointer alias needs to be written
in a quite confusing way:

typedef int(*AliasName)(int, int, double);

(Understanding typedef becomes easier when you realize that it's just
as if you were declaring a normal variable, and you just add 'typedef'
at the beginning. But given how obscure function and array pointers are...)

The new alternative is more logical, consistent and easier to understand:

using AliasName = TheType;

In this case it *does* always work using that pattern.

> On a large C++ unix project that only uses typedefs for defining types:
>
> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")

In any shell supporting globbing you can just write

grep typedef **/*.(h|hpp|cc|cpp)

[Ben Bacarisse]

Juha Nieminen <nos...@thanks.invalid> writes:

> Mut...@dastardlyhq.com wrote:
>> The more pertinent question is why the C++ committee felt the need to
>> duplicate the functionality of typedef.
>
> typedef is confusing. The average person learning C or C++ very easily
> gets the impression that typedef works like:
>
> typedef TheType AliasName;

I suppose that depends on what they've read and seen.

> But that's not at all how it works. It just happens to conform to that
> form with elementary types (because that's how elementary type variables
> are declared), but when such a person finds the need to create a type
> alias eg. for a function pointer (or any of the other more complicated
> types, like array pointers), he'll be highly confused because the
> above pattern doesn't work with them. A bit of research needs to be
> done to find out that eg. a function pointer alias needs to be written
> in a quite confusing way:
>
> typedef int(*AliasName)(int, int, double);
>
> (Understanding typedef becomes easier when you realize that it's just
> as if you were declaring a normal variable, and you just add 'typedef'
> at the beginning. But given how obscure function and array pointers
> are...)

I think it's easier for old hands who learned from the classic K&R. K&R
was always very clear: typedef came late to C, and was added into the
syntax as a storage class specifier, just to get the job done. Once you
know this, it's clear that typedef, like extern and static, just sits at
the front of a set of otherwise ordinary declarations.

> The new alternative is more logical, consistent and easier to understand:
>
> using AliasName = TheType;
>
> In this case it *does* always work using that pattern.

Well that's an odd way to put it. You gave the wrong pattern so of
course this new syntax looks more consistent. typedef (like any
syntax!) also works using a consistent pattern.

--
Ben.

[Juha Nieminen]

Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> Well that's an odd way to put it. You gave the wrong pattern so of
> course this new syntax looks more consistent. typedef (like any
> syntax!) also works using a consistent pattern.

Yeah, using C's crazy type declaration syntax, which only a fraction
C (or C++) programmers fully understand and remember by heart.

[Ben Bacarisse]

I don't think there are that many people will write

using fp = int (*)(int, double);

but just baulk at

typedef int (*fp)(int, double);

What C calls a "type name" -- the int (*)(int, double) part -- is the
bit that bothers most people, at least in my limited experience.

But you probably have much wider experience of what modern C programmers
know and don't know.

--
Ben.

[Mut...@dastardlyhq.com]

On Wed, 10 Aug 2022 11:13:16 -0700 (PDT)

=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Wednesday, 10 August 2022 at 11:21:32 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Wed, 10 Aug 2022 01:13:05 -0700 (PDT)
>> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>> >On Wednesday, 10 August 2022 at 10:55:25 UTC+3, Mut...@dastardlyhq.com
>wrote:
>> >> The more pertinent question is why the C++ committee felt the need to
>> >> duplicate the functionality of typedef.
>> >
>> >That ship has sailed over decade ago and the answer was that there
>> >was need to create alias-templates that typedef does not let to.
>>
>> And the reason typedef couldn't have been extended to do them was.... ?
>
>No one is capable to come out with suggestion how. Are you?
>The typedef can be used by language rules something like that:
>
>typedef int int_t, *intp_t, (&fp)(int, ulong), arr_t[10];
>
>That declares aliases int_t, intp_t, fp and arr_t. How you extend it to
>declare aliases int_t<K>, intp_t<L>, fp<M> and arr_t<N> instead?

Its 7 letters. Is there something magical about the 5 letters u-s-i-n-g?

>> >Majority are probably indifferent ... usage of grep to find aliases might
>> >feel like usage of #define to declare those. It is two levels below tools
>> >that their IDEs provide with keypress or two.
>>
>> Clearly you've never done much serious development on *nix or had to
>develop/
>> debug remotely down an ssh link.
>
>Majority are probably still indifferent. What I have or haven't done ever is
>even less relevant to their opinion about usefulness of grep for finding
>aliases
>in code-base.

For majority read "windows devs". I'm not interested in how they develop or
what requirements they have. There was however a clear requirement for not
overloading a keyword yet again with the committee ignored.

>> And FWIW Eclipse is a slow steaming bug ridden POC.
>
>OK ... then use CLion, works fine on Linux ... I think it was less than
>$200/year.

Using command line tools is $0 a year.

[Mut...@dastardlyhq.com]

On Thu, 11 Aug 2022 06:24:13 -0000 (UTC)

Juha Nieminen <nos...@thanks.invalid> wrote:
>Mut...@dastardlyhq.com wrote:

>> On a large C++ unix project that only uses typedefs for defining types:
>>
>> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")
>
>In any shell supporting globbing you can just write
>
> grep typedef **/*.(h|hpp|cc|cpp)

Globbing doesn't do recursive searching, hence the find command. Plus your
syntax is wrong anyway and errors with or without quotes.

fenris$ echo $SHELL
/bin/bash
fenris$ grep typedef **/*.(h|hpp|cc|cpp)
-bash: syntax error near unexpected token `('
fenris$ grep typedef "**/*.(h|hpp|cc|cpp)"
grep: **/*.(h|hpp|cc|cpp): No such file or directory

[Öö Tiib]

That is just expressing some kind of weird bigotry about widespread operating
system. Business is not about whatever prejudice or religion, leave that to
political groups. Windows hasn't been among targets of my code during
last 2 years but that can change anytime.

> >> And FWIW Eclipse is a slow steaming bug ridden POC.
> >
> >OK ... then use CLion, works fine on Linux ... I think it was less than
> >$200/year.
> Using command line tools is $0 a year.

Decent engineer costs about $200K/year so it is pointless to save 0.1%
of it and then waste her time with inadequate tools.

[Mut...@dastardlyhq.com]

On Fri, 12 Aug 2022 03:38:14 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote:
>> >Majority are probably still indifferent. What I have or haven't done ever
>is
>> >even less relevant to their opinion about usefulness of grep for finding
>> >aliases
>> >in code-base.
>>
>> For majority read "windows devs". I'm not interested in how they develop or
>> what requirements they have. There was however a clear requirement for not
>> overloading a keyword yet again with the committee ignored.
>
>That is just expressing some kind of weird bigotry about widespread operating
>system. Business is not about whatever prejudice or religion, leave that to

Neither should language development. They could have extended typedefs
functionality but they chose to overload using instead. Even from an english
semantic viewpoint the word "using" in a typedef context is illogical.
Might as well have used "for" or "case" for all the sense it makes.

>> Using command line tools is $0 a year.
>
>Decent engineer costs about $200K/year so it is pointless to save 0.1%
>of it and then waste her time with inadequate tools.

They're not inadequate, they work fine particularly for remote working which
most IDEs are not good at or can't do at all unless via RDP or similar.

[Juha Nieminen]

Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> Yeah, using C's crazy type declaration syntax, which only a fraction
>> C (or C++) programmers fully understand and remember by heart.
>
> I don't think there are that many people will write
>
> using fp = int (*)(int, double);
>
> but just baulk at
>
> typedef int (*fp)(int, double);
>
> What C calls a "type name" -- the int (*)(int, double) part -- is the
> bit that bothers most people, at least in my limited experience.

If we are stuck with C's crazy type declaration syntax, at least it's
nice if it becomes even slightly easier to read.

In the 'using' version the name of the alias is extremely easy to find
with a quick visual scan, because it always comes after the 'using'
and before the '='. Especially if that's what you are interested in
you can ignore everything that comes after the '='.

In the 'typedef' version you have visually find and dig out the name
of the alias from among all the syntax gibberish. And a straightforward
function pointer type is still simple compared to the craziest and most
complex type declarations. (Consider that a more complicated declaration
may use *other* type aliases within it, so it becomes even harder to
find *this* type alias name with a quick visual scan. You really need
to start deciphering the gibberish to find out which one of the names
is the one you are interested in. In the 'using' version you can just
ignore everything after the '=', no matter how complicated.)

[Öö Tiib]

On Friday, 12 August 2022 at 13:48:18 UTC+3, Mut...@dastardlyhq.com wrote:
> On Fri, 12 Aug 2022 03:38:14 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
> >On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote:
> >> >Majority are probably still indifferent. What I have or haven't done ever
> >is
> >> >even less relevant to their opinion about usefulness of grep for finding
> >> >aliases
> >> >in code-base.
> >>
> >> For majority read "windows devs". I'm not interested in how they develop or
> >> what requirements they have. There was however a clear requirement for not
> >> overloading a keyword yet again with the committee ignored.
> >
> >That is just expressing some kind of weird bigotry about widespread operating
> >system. Business is not about whatever prejudice or religion, leave that to
>
> Neither should language development. They could have extended typedefs
> functionality but they chose to overload using instead. Even from an english
> semantic viewpoint the word "using" in a typedef context is illogical.

You did not explain how you would extend typedef to define alias templates.
AFAIK no one was capable to come out with good idea how. So your criticism
is meaningless. As that issue was already explained in this thread it looks
like wilfully non-constructive nonsense.

> Might as well have used "for" or "case" for all the sense it makes.
> >> Using command line tools is $0 a year.
> >
> >Decent engineer costs about $200K/year so it is pointless to save 0.1%
> >of it and then waste her time with inadequate tools.
>
> They're not inadequate, they work fine particularly for remote working which
> most IDEs are not good at or can't do at all unless via RDP or similar.

In discussion of CLion? CLion supports full remote mode, windows
subsystem for linux, remote debug and remote gdb server. With todays
latency and bandwidth of net who doesn't want CLion could just bluntly
use operating system tools for remote desktop without problems.

All that is rarely needed as most actual development goes using
distributed code repositories (free are market leaders) and continuous
integration (free are good enough) to build, deploy and run the tests.
During Covid it was especially apparent how far it all has evolved
and how cheap it is.

[Juha Nieminen]

I would recommend using a real shell. But if you are using a lesser
shell interpreter you can try:

shopt -s globstar
grep typedef **/*.{h,hpp,cc,cpp}

[Mut...@dastardlyhq.com]

On Fri, 12 Aug 2022 04:54:47 -0700 (PDT)

=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Friday, 12 August 2022 at 13:48:18 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Fri, 12 Aug 2022 03:38:14 -0700 (PDT)
>> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>> >On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote:
>> >> >Majority are probably still indifferent. What I have or haven't done
>ever
>> >is
>> >> >even less relevant to their opinion about usefulness of grep for finding
>
>> >> >aliases
>> >> >in code-base.
>> >>
>> >> For majority read "windows devs". I'm not interested in how they develop
>or
>> >> what requirements they have. There was however a clear requirement for
>not
>> >> overloading a keyword yet again with the committee ignored.
>> >
>> >That is just expressing some kind of weird bigotry about widespread
>operating
>> >system. Business is not about whatever prejudice or religion, leave that to
>>
>> Neither should language development. They could have extended typedefs
>> functionality but they chose to overload using instead. Even from an english
>
>> semantic viewpoint the word "using" in a typedef context is illogical.
>
>You did not explain how you would extend typedef to define alias templates.

I've already asked if there's something magical about the word "using".

typedef <var> =

could use a different syntax to normal typedef but at least it would be the
same keyword.

>AFAIK no one was capable to come out with good idea how. So your criticism
>is meaningless. As that issue was already explained in this thread it looks
>like wilfully non-constructive nonsense.

Which is your usual opinion if you disagree with someone. Like a lot of people
on this group you seem to believe your opinion is the only correct one.

>> They're not inadequate, they work fine particularly for remote working which
>
>> most IDEs are not good at or can't do at all unless via RDP or similar.
>
>In discussion of CLion? CLion supports full remote mode, windows
>subsystem for linux, remote debug and remote gdb server. With todays
>latency and bandwidth of net who doesn't want CLion could just bluntly
>use operating system tools for remote desktop without problems.

It writing in fucking java so you can shove that POS where the sun doesn't
shine. I don't need an IDE using gigabytes of memory just to edit and compile.
I could use Eclipse for that.

Also in a previous job I had to remote debug embedded linux systems running
on a low powered ARM with < 50M of memory. Let me know how I'd have done that
using clion.

>All that is rarely needed as most actual development goes using
>distributed code repositories (free are market leaders) and continuous

LOL :) Oh you really don't have a clue do you Mr Desktop developer.

[Mut...@dastardlyhq.com]

On Fri, 12 Aug 2022 12:08:46 -0000 (UTC)

Linux only.

[Scott Lurndal]

Inadequate is in the eye of the beholder, of course. Operating system
developers, for example, don't generally use IDEs, at least in my CPOE.

It also is highly dependent upon the age of the developer, with older
developers often eschewing IDEs for various reasons. For me, they are
not as productive as command line tools.

[Scott Lurndal]

Juha Nieminen <nos...@thanks.invalid> writes:
>Mut...@dastardlyhq.com wrote:
>> On Thu, 11 Aug 2022 06:24:13 -0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>Mut...@dastardlyhq.com wrote:
>>>> On a large C++ unix project that only uses typedefs for defining types:
>>>>
>>>> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")
>>>
>>>In any shell supporting globbing you can just write
>>>
>>> grep typedef **/*.(h|hpp|cc|cpp)
>>
>> Globbing doesn't do recursive searching, hence the find command. Plus your
>> syntax is wrong anyway and errors with or without quotes.
>>
>> fenris$ echo $SHELL
>> /bin/bash
>> fenris$ grep typedef **/*.(h|hpp|cc|cpp)
>> -bash: syntax error near unexpected token `('
>> fenris$ grep typedef "**/*.(h|hpp|cc|cpp)"
>> grep: **/*.(h|hpp|cc|cpp): No such file or directory
>
>I would recommend using a real shell.

You explicitly wrote 'any shell'.

The Bourne shell is the only real shell. David Korn
made it usable (ksh). csh is a buggy POS.

[Öö Tiib]

Someone could indeed do something even far more confusing and so you
would bitch about that here. It was passable what they did.

> >AFAIK no one was capable to come out with good idea how. So your criticism
> >is meaningless. As that issue was already explained in this thread it looks
> >like wilfully non-constructive nonsense.

> Which is your usual opinion if you disagree with someone. Like a lot of people
> on this group you seem to believe your opinion is the only correct one.

You have by now proven that you can't come out with grammar for
type alias template also you can't give any links to any proposals by others
so just a warm air.

> >> They're not inadequate, they work fine particularly for remote working which
> >
> >> most IDEs are not good at or can't do at all unless via RDP or similar.
> >
> >In discussion of CLion? CLion supports full remote mode, windows
> >subsystem for linux, remote debug and remote gdb server. With todays
> >latency and bandwidth of net who doesn't want CLion could just bluntly
> >use operating system tools for remote desktop without problems.
>
> It writing in fucking java so you can shove that POS where the sun doesn't
> shine. I don't need an IDE using gigabytes of memory just to edit and compile.
> I could use Eclipse for that.

RAM is like $10 per gigabyte, why you keep constantly discussing things that
do not matter? That memory is not part of bill of material of product but
developer workstation.

>
> Also in a previous job I had to remote debug embedded linux systems running
> on a low powered ARM with < 50M of memory. Let me know how I'd have done that
> using clion.

What madness you are talking about? Remote debugging worked fine already
in eighties with thousand times less memory and who puts source code onto
embedded system to grep it there?

> >All that is rarely needed as most actual development goes using
> >distributed code repositories (free are market leaders) and continuous
> LOL :) Oh you really don't have a clue do you Mr Desktop developer.

Giggling madly? Feel free to express whatever weird ideas about my work,
prejudice about programming languages, zealotry about tools, bigotry about
operating systems or dogmatism about how something should be used ... it
adds nothing to discussion. All such extremism and intolerance is reached
anyway without using logic but just being butt-hurt by something.

[Mut...@dastardlyhq.com]

On Fri, 12 Aug 2022 08:34:20 -0700 (PDT)

=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Friday, 12 August 2022 at 17:34:46 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Fri, 12 Aug 2022 04:54:47 -0700 (PDT)

>> >You did not explain how you would extend typedef to define alias templates.
>> I've already asked if there's something magical about the word "using".
>>
>> typedef <var> =
>>
>> could use a different syntax to normal typedef but at least it would be the
>> same keyword.
>
>Someone could indeed do something even far more confusing and so you
>would bitch about that here. It was passable what they did.

Why would it be far more confusing that using a totally inappropriate keyword?
Or do you think "using" is a synonym for define? If so you should have a word
with your english teacher.

>> Which is your usual opinion if you disagree with someone. Like a lot of
>people
>> on this group you seem to believe your opinion is the only correct one.
>
>You have by now proven that you can't come out with grammar for
>type alias template also you can't give any links to any proposals by others
>so just a warm air.

Clearly reading is not your strongpoint. Should I google translate stuff into
estonian just for you?

>> It writing in fucking java so you can shove that POS where the sun doesn't
>> shine. I don't need an IDE using gigabytes of memory just to edit and
>compile.
>> I could use Eclipse for that.
>
>RAM is like $10 per gigabyte, why you keep constantly discussing things that
>do not matter? That memory is not part of bill of material of product but
>developer workstation.

"developer workstation"? You've heard of dev servers right? And they're not
just hosting one user. Oh sorry Mr Windows dev, multiuser is a novel concept
for people like you.

>> Also in a previous job I had to remote debug embedded linux systems running
>> on a low powered ARM with < 50M of memory. Let me know how I'd have done
>that
>> using clion.
>
>What madness you are talking about? Remote debugging worked fine already
>in eighties with thousand times less memory and who puts source code onto
>embedded system to grep it there?

face <- palm.

>> >All that is rarely needed as most actual development goes using
>> >distributed code repositories (free are market leaders) and continuous
>> LOL :) Oh you really don't have a clue do you Mr Desktop developer.
>
>Giggling madly? Feel free to express whatever weird ideas about my work,

See above :) You really have no clue. Go back to Visual Studio.

[Öö Tiib]

On Friday, 12 August 2022 at 17:58:41 UTC+3, Scott Lurndal wrote:
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
> >On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote:
>
> >> >OK ... then use CLion, works fine on Linux ... I think it was less than
> >> >$200/year.
> >> Using command line tools is $0 a year.
> >
> >Decent engineer costs about $200K/year so it is pointless to save 0.1%
> >of it and then waste her time with inadequate tools.
> Inadequate is in the eye of the beholder, of course. Operating system
> developers, for example, don't generally use IDEs, at least in my CPOE.

Writing operating systems is not different from other programming.
The discussion was about Muttley being incapable to search type aliases
in code base using grep because pattern "using identifier = type-id ;" was
too complex to match.

> It also is highly dependent upon the age of the developer, with older
> developers often eschewing IDEs for various reasons. For me, they are
> not as productive as command line tools.

Then maybe help Muttley to grep. I would just use IDE to find where what
is defined and how as it does it adequately, is dirt cheap and I have no
need to think about it.

[Mut...@dastardlyhq.com]

Maybe someone should help you to get a clue.

[Öö Tiib]

On Friday, 12 August 2022 at 18:58:13 UTC+3, Mut...@dastardlyhq.com wrote:
> On Fri, 12 Aug 2022 08:34:20 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
> >On Friday, 12 August 2022 at 17:34:46 UTC+3, Mut...@dastardlyhq.com wrote:
> >> On Fri, 12 Aug 2022 04:54:47 -0700 (PDT)
> >> >You did not explain how you would extend typedef to define alias templates.
> >> I've already asked if there's something magical about the word "using".
> >>
> >> typedef <var> =
> >>
> >> could use a different syntax to normal typedef but at least it would be the
> >> same keyword.
> >
> >Someone could indeed do something even far more confusing and so you
> >would bitch about that here. It was passable what they did.
>
> Why would it be far more confusing that using a totally inappropriate keyword?
> Or do you think "using" is a synonym for define? If so you should have a word
> with your english teacher.

Maybe you haven't noticed but it is C++ that we discuss not English.

> >> Which is your usual opinion if you disagree with someone. Like a lot of
> >people
> >> on this group you seem to believe your opinion is the only correct one.
> >
> >You have by now proven that you can't come out with grammar for
> >type alias template also you can't give any links to any proposals by others
> >so just a warm air.
>
> Clearly reading is not your strongpoint. Should I google translate stuff into
> estonian just for you?

No, just repeat the links to proposed grammar.

> >> It writing in fucking java so you can shove that POS where the sun doesn't
> >> shine. I don't need an IDE using gigabytes of memory just to edit and
> >compile.
> >> I could use Eclipse for that.
> >
> >RAM is like $10 per gigabyte, why you keep constantly discussing things that
> >do not matter? That memory is not part of bill of material of product but
> >developer workstation.
>
> "developer workstation"? You've heard of dev servers right? And they're not
> just hosting one user. Oh sorry Mr Windows dev, multiuser is a novel concept
> for people like you.

Yep. Last time I saw lot of terminals connected to one "mainframe" was decades
ago and that pile of scrap-metal had thousands of times less memory than my
cellphone now.

> >> Also in a previous job I had to remote debug embedded linux systems running
> >> on a low powered ARM with < 50M of memory. Let me know how I'd have done
> >that
> >> using clion.
> >
> >What madness you are talking about? Remote debugging worked fine already
> >in eighties with thousand times less memory and who puts source code onto
> >embedded system to grep it there?
>
> face <- palm.

Definitely. You can't even say anything to defend that idiocy.

> >> >All that is rarely needed as most actual development goes using
> >> >distributed code repositories (free are market leaders) and continuous
> >> LOL :) Oh you really don't have a clue do you Mr Desktop developer.
> >
> >Giggling madly? Feel free to express whatever weird ideas about my work,
> See above :) You really have no clue. Go back to Visual Studio.

There was nothing to see. You implied we were discussing English not C++,
accused me of not understanding it, accused me of not using whatever
IBM System/360 you program on and other such nonsense.

[Scott Lurndal]

=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
>On Friday, 12 August 2022 at 17:58:41 UTC+3, Scott Lurndal wrote:
>> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
>> >On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote:
>>
>> >> >OK ... then use CLion, works fine on Linux ... I think it was less than
>> >> >$200/year.
>> >> Using command line tools is $0 a year.
>> >
>> >Decent engineer costs about $200K/year so it is pointless to save 0.1%
>> >of it and then waste her time with inadequate tools.
>> Inadequate is in the eye of the beholder, of course. Operating system
>> developers, for example, don't generally use IDEs, at least in my CPOE.
>
>Writing operating systems is not different from other programming.

How many have you written? How many have you debugged once written?

[Öö Tiib]

On Friday, 12 August 2022 at 19:44:23 UTC+3, Scott Lurndal wrote:
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
> >On Friday, 12 August 2022 at 17:58:41 UTC+3, Scott Lurndal wrote:
> >> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
> >> >On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote:
> >>
> >> >> >OK ... then use CLion, works fine on Linux ... I think it was less than
> >> >> >$200/year.
> >> >> Using command line tools is $0 a year.
> >> >
> >> >Decent engineer costs about $200K/year so it is pointless to save 0.1%
> >> >of it and then waste her time with inadequate tools.
> >> Inadequate is in the eye of the beholder, of course. Operating system
> >> developers, for example, don't generally use IDEs, at least in my CPOE.
> >
> >Writing operating systems is not different from other programming.
> How many have you written? How many have you debugged once written?

Whatever Texas Instruments controller has basically only garbage as SW, make
board around it and somehow we have to operate it, same is with FPGAs.
Have also had plenty of experience debugging drivers to communicate with
such boards and whatever gadgets on those ... say recently SD card readers.
But what is your take, how it is supposed to differ from other programming?
Also how does usage of grep to find things in code base make it easier?

[Scott Lurndal]

=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
>On Friday, 12 August 2022 at 19:44:23 UTC+3, Scott Lurndal wrote:
>> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
>> >On Friday, 12 August 2022 at 17:58:41 UTC+3, Scott Lurndal wrote:
>> >> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
>> >> >On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote:
>> >>
>> >> >> >OK ... then use CLion, works fine on Linux ... I think it was less than
>> >> >> >$200/year.
>> >> >> Using command line tools is $0 a year.
>> >> >
>> >> >Decent engineer costs about $200K/year so it is pointless to save 0.1%
>> >> >of it and then waste her time with inadequate tools.
>> >> Inadequate is in the eye of the beholder, of course. Operating system
>> >> developers, for example, don't generally use IDEs, at least in my CPOE.
>> >
>> >Writing operating systems is not different from other programming.
>> How many have you written? How many have you debugged once written?
>
>Whatever Texas Instruments controller has basically only garbage as SW, make
>board around it and somehow we have to operate it, same is with FPGAs.
>Have also had plenty of experience debugging drivers to communicate with
>such boards and whatever gadgets on those ... say recently SD card readers.

How well does your IDE handle debugging on the remote target board? Does
it support JTAG access (and coresight on embedded ARM processors), or kgdb
when debugging linux remotely?

>But what is your take, how it is supposed to differ from other programming?

Primarily, the built-in debug and run-time facilities of an IDE are useless
when developing operating systems; an editor and make file have been and
still are the mainstay of OS development, whether proprietary or open source
such as linux or freebsd/openbsd.

>Also how does usage of grep to find things in code base make it easier?

I do not recall making any such claim, that was Muttley, I believe.

In the 80's one enabled the compiler option to generate a cross reference
table (or used a standalone cross-reference program) and printed it.

In the 90's one used cscope, which was integrated later into vim. That's
how I find things in the code base, when necessary. Even in C++ code, where
it works well enough.

I do find that using grep to create a list in a different window from the
editor window is quite useful. I prefer having multiple windows on multiple
monitors rather than a monolithic IDE window. I've been using vi for decades
and see no reason to learn a new editor, when modern VIM with integrated cscope
provides most of the IDE facilities useful to the code I develop professionally.

I generally use vim instead of gvim as tunnelling X11 over slow ssh links
doesn't perform as well remotely.

I suppose one could argue that modern vim (with hsplits and vsplits) is an IDE
of sorts when integrated with other tools like make, ctags or cscope. It will
even highlight and position at errors (although that gets clumsy with large
projects with lots of source and header files).

I wonder how well clion or eclipse or vs code would handle this project? (which generates
a single executable with a bunch of shared objects loaded dynamically by the
application as required)

$ ./sloccount
Totals grouped by language (dominant language first):
ansic: 10681243 (84.66%)
cpp: 977390 (7.75%)
python: 918261 (7.28%)
asm: 35177 (0.28%)
sh: 2534 (0.02%)
perl: 1198 (0.01%)

Total Physical Source Lines of Code (SLOC) = 12,615,911
Development Effort Estimate, Person-Years (Person-Months) = 4,045.71 (48,548.50)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 12.57 (150.90)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 321.73
Total Estimated Cost to Develop = $ 546,520,140
(average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.

[Öö Tiib]

On Friday, 12 August 2022 at 22:58:44 UTC+3, Scott Lurndal wrote:
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
> >On Friday, 12 August 2022 at 19:44:23 UTC+3, Scott Lurndal wrote:
> >> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
> >> >On Friday, 12 August 2022 at 17:58:41 UTC+3, Scott Lurndal wrote:
> >> >> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
> >> >> >On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote:
> >> >>
> >> >> >> >OK ... then use CLion, works fine on Linux ... I think it was less than
> >> >> >> >$200/year.
> >> >> >> Using command line tools is $0 a year.
> >> >> >
> >> >> >Decent engineer costs about $200K/year so it is pointless to save 0.1%
> >> >> >of it and then waste her time with inadequate tools.
> >> >> Inadequate is in the eye of the beholder, of course. Operating system
> >> >> developers, for example, don't generally use IDEs, at least in my CPOE.
> >> >
> >> >Writing operating systems is not different from other programming.
> >> How many have you written? How many have you debugged once written?
> >
> >Whatever Texas Instruments controller has basically only garbage as SW, make
> >board around it and somehow we have to operate it, same is with FPGAs.
> >Have also had plenty of experience debugging drivers to communicate with
> >such boards and whatever gadgets on those ... say recently SD card readers.
>
> How well does your IDE handle debugging on the remote target board? Does
> it support JTAG access (and coresight on embedded ARM processors), or kgdb
> when debugging linux remotely?

Yes, if there is enough room on board flash then image can
be built with embedded gdb that works over JTAG. Sure, when there are
for example two cores on board then it does take effort to get that GDB to work
and IDE to understand what is going on. IDEs can indeed to have garbage
features in those but the vim and emacs feel too much like just text editors
with next to nothing integrated.

> >But what is your take, how it is supposed to differ from other programming?
> Primarily, the built-in debug and run-time facilities of an IDE are useless
> when developing operating systems; an editor and make file have been and
> still are the mainstay of OS development, whether proprietary or open source
> such as linux or freebsd/openbsd.

I imagine you want too lot of that debugger ... like it to understand and to
show your concept of processes, threads and modules.

> >Also how does usage of grep to find things in code base make it easier?
> I do not recall making any such claim, that was Muttley, I believe.
>

OK, my bad. My claim was that for such work like navigating in code base
and finding definition of some type alias the IDEs are better than grep.
Muttley just has nothing else to say than to bash my nation and to express
intolerance towards random operating systems, tools and programmers.
I suspect he is from Moscow ... that city produces such bigoted morons.

> In the 80's one enabled the compiler option to generate a cross reference
> table (or used a standalone cross-reference program) and printed it.
>
> In the 90's one used cscope, which was integrated later into vim. That's
> how I find things in the code base, when necessary. Even in C++ code, where
> it works well enough.

That makes lot more sense. The cscope was IIRC confused by
preprocessor directives sometimes but things that confuse tool can be
edited and indeed it worked well enough.

>
> I do find that using grep to create a list in a different window from the
> editor window is quite useful. I prefer having multiple windows on multiple
> monitors rather than a monolithic IDE window. I've been using vi for decades
> and see no reason to learn a new editor, when modern VIM with integrated cscope
> provides most of the IDE facilities useful to the code I develop professionally.
>
> I generally use vim instead of gvim as tunnelling X11 over slow ssh links
> doesn't perform as well remotely.
>
> I suppose one could argue that modern vim (with hsplits and vsplits) is an IDE
> of sorts when integrated with other tools like make, ctags or cscope. It will
> even highlight and position at errors (although that gets clumsy with large
> projects with lots of source and header files).

Yes, so they argue that vim and emacs are IDEs. It feels bit too spartan.

> I wonder how well clion or eclipse or vs code would handle this project? (which generates
> a single executable with a bunch of shared objects loaded dynamically by the
> application as required)
>
> $ ./sloccount
> Totals grouped by language (dominant language first):
> ansic: 10681243 (84.66%)
> cpp: 977390 (7.75%)
> python: 918261 (7.28%)
> asm: 35177 (0.28%)
> sh: 2534 (0.02%)
> perl: 1198 (0.01%)
>
> Total Physical Source Lines of Code (SLOC) = 12,615,911
> Development Effort Estimate, Person-Years (Person-Months) = 4,045.71 (48,548.50)
> (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
> Schedule Estimate, Years (Months) = 12.57 (150.90)
> (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
> Estimated Average Number of Developers (Effort/Schedule) = 321.73
> Total Estimated Cost to Develop = $ 546,520,140
> (average salary = $56,286/year, overhead = 2.40).
> SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
> SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.

I know Eclipse can die down or become not usable sluggish when
order of magnitude less code is dealt with. I am quite a bit more optimistic
about CLion and VSCode. But that just has to be tried out.

[Mut...@dastardlyhq.com]

On Fri, 12 Aug 2022 09:16:09 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Friday, 12 August 2022 at 18:58:13 UTC+3, Mut...@dastardlyhq.com wrote:
>> >Someone could indeed do something even far more confusing and so you
>> >would bitch about that here. It was passable what they did.
>>
>> Why would it be far more confusing that using a totally inappropriate
>keyword?
>> Or do you think "using" is a synonym for define? If so you should have a
>word
>> with your english teacher.
>
>Maybe you haven't noticed but it is C++ that we discuss not English.

Maybe you haven't noticed but C++ uses english keywords which generally relate
to their meaning. Otherwise might as well just use sdfkuewyr , iuwe8ruew and
maybe iewiuriweur instead.

>> Clearly reading is not your strongpoint. Should I google translate stuff
>into
>> estonian just for you?
>
>No, just repeat the links to proposed grammar.

Use the same as "using" for that particular use case. Is that clear now or
do you need it in crayon?

>> "developer workstation"? You've heard of dev servers right? And they're not
>> just hosting one user. Oh sorry Mr Windows dev, multiuser is a novel concept
>
>> for people like you.
>
>Yep. Last time I saw lot of terminals connected to one "mainframe" was decades
>ago and that pile of scrap-metal had thousands of times less memory than my
>cellphone now.

Wtf are you babbling about? I worked for a major aircraft manufacturer until
recently and the teams linux dev box was located in a secure room with remote
access via ssh tunnelled X windows with all required libraries and tools
installed on it. But I imagine in whatever Mickey Mouse company you work for
everything would be duplicated on desktops.

>> >What madness you are talking about? Remote debugging worked fine already
>> >in eighties with thousand times less memory and who puts source code onto
>> >embedded system to grep it there?
>>
>> face <- palm.
>
>Definitely. You can't even say anything to defend that idiocy.

You do realise huge amounts of embedded systems use linux now and testing an
debugging often have to be done in situ if the system is already installed
on site.

>> See above :) You really have no clue. Go back to Visual Studio.
>
>There was nothing to see. You implied we were discussing English not C++,
>accused me of not understanding it, accused me of not using whatever
>IBM System/360 you program on and other such nonsense.

See above. Go back to your toy programming.

[David Brown]

If you make sure your code can be built from command-line tools (make,
or whatever alternative you prefer), then developers can use whatever
mixture they find most convenient. When working seriously on a project,
I'll usually use Eclipse - not because it is in some objective sense the
"best" IDE, but because it is good enough and I'm familiar with it.
Other people working on the same code base use MS Visual Studio (or is
that Visual Studio Code? I always mix these), from personal preference
and familiarity. Sometimes I'll use a lighter editor like GEdit or
Notepad++, for small changes without having to start a big IDE.
Sometimes I'll use nano. If I want to search in the code, I might use
the IDE's search, or I might use grep. Some stuff I'll do on Linux,
some on Windows - as will other developers in the team, who have
different preferences.

There's no reason to pick just /one/ tool or toolset - use whatever
mixture suits best for the task and the person working on the task.

[Öö Tiib]

On Saturday, 13 August 2022 at 12:36:03 UTC+3, Mut...@dastardlyhq.com wrote:
> On Fri, 12 Aug 2022 09:16:09 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
> >On Friday, 12 August 2022 at 18:58:13 UTC+3, Mut...@dastardlyhq.com wrote:
> >> >Someone could indeed do something even far more confusing and so you
> >> >would bitch about that here. It was passable what they did.
> >>
> >> Why would it be far more confusing that using a totally inappropriate
> >keyword?
> >> Or do you think "using" is a synonym for define? If so you should have a
> >word
> >> with your english teacher.
> >
> >Maybe you haven't noticed but it is C++ that we discuss not English.
> Maybe you haven't noticed but C++ uses english keywords which generally relate
> to their meaning. Otherwise might as well just use sdfkuewyr , iuwe8ruew and
> maybe iewiuriweur instead.

But fortunately we use English like wchar_t or std::snprintf so I should have
a word with my English teacher.

> >> Clearly reading is not your strongpoint. Should I google translate stuff
> >into
> >> estonian just for you?
> >
> >No, just repeat the links to proposed grammar.
>
> Use the same as "using" for that particular use case. Is that clear now or
> do you need it in crayon?

That is quite bad idea, that would result with typedef being most hard to
teach.

> >> "developer workstation"? You've heard of dev servers right? And they're not
> >> just hosting one user. Oh sorry Mr Windows dev, multiuser is a novel concept
> >
> >> for people like you.
> >
> >Yep. Last time I saw lot of terminals connected to one "mainframe" was decades
> >ago and that pile of scrap-metal had thousands of times less memory than my
> >cellphone now.
>
> Wtf are you babbling about? I worked for a major aircraft manufacturer until
> recently and the teams linux dev box was located in a secure room with remote
> access via ssh tunnelled X windows with all required libraries and tools
> installed on it. But I imagine in whatever Mickey Mouse company you work for
> everything would be duplicated on desktops.

Sounds something rather dangerous ... I have never had such process with way
less risky equipment. Some kind of Voronezh Aircraft Production Association?

> >> >What madness you are talking about? Remote debugging worked fine already
> >> >in eighties with thousand times less memory and who puts source code onto
> >> >embedded system to grep it there?
> >>
> >> face <- palm.
> >
> >Definitely. You can't even say anything to defend that idiocy.
>
> You do realise huge amounts of embedded systems use linux now and testing an
> debugging often have to be done in situ if the system is already installed
> on site.

So you debug airplanes of Аэрофлот right at airport .. got it.

> >> See above :) You really have no clue. Go back to Visual Studio.
> >
> >There was nothing to see. You implied we were discussing English not C++,
> >accused me of not understanding it, accused me of not using whatever
> >IBM System/360 you program on and other such nonsense.
> See above. Go back to your toy programming.

Will do. Thanks.

[Mut...@dastardlyhq.com]

The problem with mixing and matching is that IDEs often have their own build
systems and a whole load of supporting metadata files. You can't just point it
at a Makefile and tell it to get on with it, it requires some form of import
and once you've done that you can't go back to fiddling with the project on the
command line because then it'll be out of sync with the IDE.

[Mut...@dastardlyhq.com]

On Sat, 13 Aug 2022 09:44:29 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Saturday, 13 August 2022 at 12:36:03 UTC+3, Mut...@dastardlyhq.com wrote=

>> >Maybe you haven't noticed but it is C++ that we discuss not English.

>> Maybe you haven't noticed but C++ uses english keywords which generally r=
>elate=20
>> to their meaning. Otherwise might as well just use sdfkuewyr , iuwe8ruew =
>and=20
>> maybe iewiuriweur instead.
>
>But fortunately we use English like wchar_t or std::snprintf so I should ha=

>ve
>a word with my English teacher.

Umm, wchar means wide character, snprintf means print to a fixed numerical
sized string. Meanwhile, "using" to define... umm, no.

>> Use the same as "using" for that particular use case. Is that clear now o=
>r=20

>> do you need it in crayon?
>
>That is quite bad idea, that would result with typedef being most hard to
>teach.

Why? Did you have a problem with the 2 different syntax of the for() command
from C++11 onwards?

>> Wtf are you babbling about? I worked for a major aircraft manufacturer un=
>til=20
>> recently and the teams linux dev box was located in a secure room with re=
>mote=20
>> access via ssh tunnelled X windows with all required libraries and tools=
>=20
>> installed on it. But I imagine in whatever Mickey Mouse company you work =
>for=20

>> everything would be duplicated on desktops.
>

>Sounds something rather dangerous ... I have never had such process with wa=

Having the team dev server in a secured server room with all tools and libraries
on it vetted is dangerous? Compared to everyone having a copy of them on their
desk/laptop installed alongside god knows what other potentially hackable
stuff? Really?

Even MS has finally got into dev servers though as usually in a hopelessly
inefficient and complicated way.

>less risky equipment. Some kind of Voronezh Aircraft Production Association=

They build ~half the commercial passenger aircraft in the world so I imagine
they know what they're doing.

>> You do realise huge amounts of embedded systems use linux now and testing=
> an=20
>> debugging often have to be done in situ if the system is already installe=
>d=20
>> on site.
>
>So you debug airplanes of =D0=90=D1=8D=D1=80=D0=BE=D1=84=D0=BB=D0=BE=D1=82 =

>right at airport .. got it.

Obviously not. Different company idiot. I was giving examples from my
personal experience.

[Juha Nieminen]

Scott Lurndal <sc...@slp53.sl.home> wrote:
> The Bourne shell is the only real shell.

Nah, it's one of the lesser shells I was talking about.

[David Brown]

With every IDE I have ever used, you /can/ just point it at a makefile.
Clearly details vary by IDE, but IME they all have some way of
specifying an external build tool (make or something else) while keeping
at least most of the power of the IDE - such as having errors from the
build highlighted in the editor windows.

You will still have to make a "project" in the IDE, telling it where all
the files are, which include directories to use, which command-line
defined macros are in effect, and the like - that's useful so that the
IDE's cross-referencing and syntax highlighting is optimal. But you
don't use the build control from the IDE - the makefile (or other
command-line based build system of your choice) rules.

[Mut...@dastardlyhq.com]

On Mon, 15 Aug 2022 11:34:25 +0200
David Brown <david...@hesbynett.no> wrote:
>On 14/08/2022 13:06, Mut...@dastardlyhq.com wrote:
>> The problem with mixing and matching is that IDEs often have their own build
>> systems and a whole load of supporting metadata files. You can't just point
>it
>> at a Makefile and tell it to get on with it, it requires some form of import
>> and once you've done that you can't go back to fiddling with the project on
>the
>> command line because then it'll be out of sync with the IDE.
>>

>You will still have to make a "project" in the IDE, telling it where all
>the files are, which include directories to use, which command-line
>defined macros are in effect, and the like - that's useful so that the

So not really just pointing it at a makefile then :)

[David Brown]

Far more importantly and relevantly - you can use the IDE for editing,
refactoring, navigation, debugging, version control interface, build
interface, and everything else without any fear of synchronisation or
mixups with builds that are handled by command-line tools. Contrary to
your concerns, there is no problem mixing and matching IDE's as long as
you have a command-line tool for the build. People do this regularly.

[red floyd]

Yeah, I sometimes use Visual Studio editor and then command line make.

[Mut...@dastardlyhq.com]

On Mon, 15 Aug 2022 21:23:15 +0200

Certainly not my experience using Eclipse and VC++ has rather complex solution
files so no idea how they would interact with make/cmake.

[Paavo Helde]

16.08.2022 22:16 Mut...@dastardlyhq.com kirjutas:
> Certainly not my experience using Eclipse and VC++ has rather complex solution
> files so no idea how they would interact with make/cmake.
>

CMake can easily generate these VC++ project files.

Pure make is for masochists, akin to drawing pictures by manually typing
Postscript code. Of course, CMake can easily generate standard makefiles
as well.

[David Brown]

Sometimes people have more complicated needs. CMake might be a fine
solution for many projects (and AIUI it is certainly a great idea if you
need to support VC++ as well as Linux/gcc projects), but it will not
handle everything. Make is arguably "lower level" than CMake, and it
has more than its share of idiosyncrasies, but it is also more flexible
- CMake can generate "standard" makefiles, but not "non-standard" makefiles.

I'm all in favour of using the best tools for the job, but that doesn't
mean dismissing other tools with a wave of the hand.

[Paavo Helde]

Right, there are certainly situations when one needs to go lower level.
Alas, in retrospect I realize that in my work I have never encountered
such situations and all the brain cells I have lost while creating and
maintaining raw Makefiles were in vain.

[Mut...@dastardlyhq.com]

IME people often make makefiles far more complex than they need to be or they
just copy a makefile from another project and don't tailor them to their needs,
instead just changing the build filenames and leaving in a load of unrequired
cruft.