Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #68739 > unrolled thread

a style question:

Back to article view | Back to comp.lang.c

Contents

  a style question: G G <gdotone@gmail.com> - 2015-08-31 02:30 -0700
    Re: a style question: Ian Collins <ian-news@hotmail.com> - 2015-08-31 21:40 +1200
    Re: a style question: jt@toerring.de (Jens Thoms Toerring) - 2015-08-31 09:52 +0000
    Re: a style question: Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 03:24 -0700
      Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 11:50 +0100
        Re: a style question: Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-31 13:21 +0100
          Re: a style question: Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 05:41 -0700
          Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 14:55 +0100
            Re: a style question: Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-31 15:50 +0100
              Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 18:40 +0100
        Re: a style question: Melzzzzz <mel@zzzzz.com> - 2015-08-31 17:46 +0200
          Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 17:27 +0100
            Re: a style question: Melzzzzz <mel@zzzzz.com> - 2015-08-31 18:42 +0200
        Re: a style question: Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-08-31 17:41 +0000
          Re: a style question: Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 15:33 -0700
            Re: a style question: Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-01 08:34 +0000
        Re: a style question: Ian Collins <ian-news@hotmail.com> - 2015-09-01 07:40 +1200
          Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 21:36 +0100
            Re: a style question: Ian Collins <ian-news@hotmail.com> - 2015-09-01 08:51 +1200
              Re: a style question: Bartc <bc@freeuk.com> - 2015-08-31 22:37 +0100
                Re: a style question: Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 15:24 -0700
                  Re: a style question: Ian Collins <ian-news@hotmail.com> - 2015-09-02 19:37 +1200
            Re: a style question: jt@toerring.de (Jens Thoms Toerring) - 2015-08-31 23:33 +0000
              Re: a style question: Bartc <bc@freeuk.com> - 2015-09-01 01:13 +0100
                Re: a style question: Ian Collins <ian-news@hotmail.com> - 2015-09-01 18:21 +1200
                Re: a style question: jt@toerring.de (Jens Thoms Toerring) - 2015-09-01 15:23 +0000
                  Re: a style question: Bartc <bc@freeuk.com> - 2015-09-01 18:06 +0100
                    Re: a style question: Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-01 20:39 +0000
                    Re: a style question: jt@toerring.de (Jens Thoms Toerring) - 2015-09-01 20:45 +0000
                      Re: a style question: Bartc <bc@freeuk.com> - 2015-09-01 22:53 +0100
              Re: a style question: Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 17:51 -0700

Page 1 of 2  [1] 2  Next page →

#68739 — a style question:

i am seeing some code that has the function return type on a separate line like

int
function( double a)
{
...
}

i'm just curious, is there a name for this style?
and why use this style other than the project uses this style?

[toc] | [next] | [standalone]

#68740

G G wrote:
> i am seeing some code that has the function return type on a separate line like
>
> int
> function( double a)
> {
> ...
> }
>
> i'm just curious, is there a name for this style?
> and why use this style other than the project uses this style?

Why not?

I've used it on several projects.  Those who like it like having the 
function name starting at the beginning of a line.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#68741

G G <gdotone@gmail.com> wrote:
> i am seeing some code that has the function return type on a separate line like

> int
> function( double a)
> {
> ...
> }

> i'm just curious, is there a name for this style?

I'm not sure if it's something that was popularized by GNU,
but at least it's in their style recommendations:

https://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting

> and why use this style other than the project uses this style?

I use it quite often since it makes searching for the start
of a function (instead of also all calls of the function)
easier with regex searches. And, at least to me, it looks
also quite nice.
                              Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#68744

On Monday, August 31, 2015 at 10:31:04 AM UTC+1, G G wrote:
> i am seeing some code that has the function return type on a separate line like
> 
> int
> function( double a)
> {
> ...
> }
> 
> i'm just curious, is there a name for this style?
> and why use this style other than the project uses this style?
>
You see it  a lot in C++.
C++ functions will often return something like

Usr::Graphics::BezierPathSimple<Math::real64_t, GREEN> 

so really you need to do a line split before you come to the
next part of the defintion.

[toc] | [prev] | [next] | [standalone]

#68745

On 31/08/2015 11:24, Malcolm McLean wrote:
> On Monday, August 31, 2015 at 10:31:04 AM UTC+1, G G wrote:
>> i am seeing some code that has the function return type on a separate line like
>>
>> int
>> function( double a)
>> {
>> ...
>> }
>>
>> i'm just curious, is there a name for this style?
>> and why use this style other than the project uses this style?
>>
> You see it  a lot in C++.
> C++ functions will often return something like
>
> Usr::Graphics::BezierPathSimple<Math::real64_t, GREEN>

Those guys really like to spell things out don't they? Buried somewhere 
in there is .... well I'm not sure exactly!

Since the subject was function definitions, I assumed it was. Then I 
looked more carefully and thought it must have been a function call. 
Then I looked yet again, and it might be function definition after all.

But yet, you say this is something returned by a function. So I don't 
know what the hell it might be. What a language! (If C++ had never been 
invented, and someone presented something like this, we'd all think it 
was a wind-up.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#68748

Bartc <bc@freeuk.com> writes:

> On 31/08/2015 11:24, Malcolm McLean wrote:
>> On Monday, August 31, 2015 at 10:31:04 AM UTC+1, G G wrote:
>>> i am seeing some code that has the function return type on a
>>> separate line like
>>>
>>> int
>>> function( double a)
>>> {
>>> ...
>>> }
>>>
>>> i'm just curious, is there a name for this style?
>>> and why use this style other than the project uses this style?
>>>
>> You see it  a lot in C++.
>> C++ functions will often return something like
>>
>> Usr::Graphics::BezierPathSimple<Math::real64_t, GREEN>
>
> Those guys really like to spell things out don't they?

Well, yes.  When technical things are being specified that are usually
spelled out in quite a technical way.

But Usr::Graphics::BezierPathSimple and Math::real_64_t are just a names
that use name spaces to avoid clashes.  What do you do to solve that
problem?  And the whole thing is the instantiation of a generic type
with two parameters.  How do you do that in your private language?
I.e. what is, in your view, the proper way to write that?

> Buried
> somewhere in there is .... well I'm not sure exactly!

Of course not -- I don't either -- you'd have to look at the definitions
to know exactly.  However, the names give me a pretty good chance of
guessing what's going in there.

> Since the subject was function definitions, I assumed it was. Then I
> looked more carefully and thought it must have been a function
> call. Then I looked yet again, and it might be function definition
> after all.
>
> But yet, you say this is something returned by a function. So I don't
> know what the hell it might be. What a language!

The fact that you don't know what something is at first glance is an odd
criterion to use.  I can imagine people looking at

   PAR (DO n PLUSAB 1; start siever (first, n) OD, sieve (first))
or
   (^^) :: (Fractional a, Integral b) => a -> b -> a

and saying "What a language!".  Could it simply be that some things are
complicated to specify, and that making it transparent at first glace
might be counter-productive in the long run?

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#68750

On Monday, August 31, 2015 at 1:22:10 PM UTC+1, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
> 
>
>    PAR (DO n PLUSAB 1; start siever (first, n) OD, sieve (first))
> or
>    (^^) :: (Fractional a, Integral b) => a -> b -> a
> 
> and saying "What a language!".  Could it simply be that some things are
> complicated to specify, and that making it transparent at first glace
> might be counter-productive in the long run?
> 
There are two paths. One is to strip out all the dependencies on
specific representations, identifiers, types and so on, and try
to make the code completely general. The other is what I call
"bit-based programming" where you do just the opposite, you specify
the function in terms of operations on bits (which of course usually
have some human-relevant meaning, but for the most part that's
confined to comments).

[toc] | [prev] | [next] | [standalone]

#68753

On 31/08/2015 13:21, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>> On 31/08/2015 11:24, Malcolm McLean wrote:

>>> Usr::Graphics::BezierPathSimple<Math::real64_t, GREEN>
>>
>> Those guys really like to spell things out don't they?
>
> Well, yes.  When technical things are being specified that are usually
> spelled out in quite a technical way.
>
> But Usr::Graphics::BezierPathSimple and Math::real_64_t are just a names
> that use name spaces to avoid clashes.  What do you do to solve that
> problem?

(1) Use a shorter alias for long-winded qualifiers

(2) Use name-space defaults

(3) *Don't* require "Math::" for primitive types! (A shorter name than 
"real_64_t" wouldn't go amiss either. What on earth is wrong with "real" 
or "real64"?)

> And the whole thing is the instantiation of a generic type
> with two parameters.

Yes, now that you say it. When you stripped out all the extraneous 
stuff, it was Name<real, GREEN>; that looked like a template, yet not a 
template definition.

> I.e. what is, in your view, the proper way to write that?

I like using keywords to specify exactly what is being done. Perhaps not 
as long-winded as this, but along these lines:

define template ......
instantiate template ....

Then there is no excuse for not knowing what is happening. (Better than 
trying to infer what is being done from a mess of punctuation and syntax.)

 > How do you do that in your private language?

In my compiled language, I don't have templates. If I did, I would make 
it more obvious, trust me. Or more likely I would put them into a 
customisation sub-language that most people wouldn't have to read, or be 
tempted to write, because I don't think this stuff belongs in every-day 
code.

While my dynamic language doesn't have templates; it doesn't really need 
them as you effectively get generics for free.

>> But yet, you say this is something returned by a function. So I don't
>> know what the hell it might be. What a language!
>
> The fact that you don't know what something is at first glance is an odd
> criterion to use.  I can imagine people looking at
>
>     PAR (DO n PLUSAB 1; start siever (first, n) OD, sieve (first))
> or
>     (^^) :: (Fractional a, Integral b) => a -> b -> a
>
> and saying "What a language!".  Could it simply be that some things are
> complicated to specify, and that making it transparent at first glace
> might be counter-productive in the long run?

Neither of these are as offensive to me as typical C++ code is. I know 
some Algol68, and I could feel I could make progress with the other 
(Haskell or Ocaml or whatever it is.)

With C++ however, I could know the syntax inside out, and still be at a 
loss as to the precise meaning of a bit of code.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#68755

Bartc <bc@freeuk.com> writes:

> On 31/08/2015 13:21, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>>> On 31/08/2015 11:24, Malcolm McLean wrote:
>
>>>> Usr::Graphics::BezierPathSimple<Math::real64_t, GREEN>
>>>
>>> Those guys really like to spell things out don't they?
>>
>> Well, yes.  When technical things are being specified that are usually
>> spelled out in quite a technical way.
>>
>> But Usr::Graphics::BezierPathSimple and Math::real_64_t are just a names
>> that use name spaces to avoid clashes.  What do you do to solve that
>> problem?
>
> (1) Use a shorter alias for long-winded qualifiers

That was Malcolm's choice.

> (2) Use name-space defaults

Ditto (unless you are suggesting that some user namespace should be an
automatic default).

> (3) *Don't* require "Math::" for primitive types! (A shorter name than
> "real_64_t" wouldn't go amiss either. What on earth is wrong with
> "real" or "real64"?)

C++ does not require "Math::" for primitive types.  It was Malcolm's
choice to invent that type so everyone could clutch at their pearls in
horror.

In short, you agree with the way C++ is designed in these respects -- you
just don't like how Malcolm wrote the (admittedly hypothetical) example.

>> And the whole thing is the instantiation of a generic type
>> with two parameters.
>
> Yes, now that you say it. When you stripped out all the extraneous
> stuff, it was Name<real, GREEN>; that looked like a template, yet not
> a template definition.
>
>> I.e. what is, in your view, the proper way to write that?
>
> I like using keywords to specify exactly what is being done. Perhaps
> not as long-winded as this, but along these lines:
>
> define template ......
> instantiate template ....
>
> Then there is no excuse for not knowing what is happening. (Better
> than trying to infer what is being done from a mess of punctuation and
> syntax.)

But you did not show an equivalent, so of course you can imply that it
can be simpler.  Show, in your language, the instantiation of a generic
type with two parameters -- one a non-standard real type and the other a
constant value.  The simplest syntax is likely to be very similar to
C++, but do show how much better you can make it.

>> How do you do that in your private language?
>
> In my compiled language, I don't have templates. If I did, I would
> make it more obvious, trust me. Or more likely I would put them into a
> customisation sub-language that most people wouldn't have to read, or
> be tempted to write, because I don't think this stuff belongs in
> every-day code.
>
> While my dynamic language doesn't have templates; it doesn't really
> need them as you effectively get generics for free.

No, you get them at a price, but you don't show the code, so I have no
idea what the price is.  It may be that the type can't even be
specified.  I can't tell yet.

>>> But yet, you say this is something returned by a function. So I don't
>>> know what the hell it might be. What a language!
>>
>> The fact that you don't know what something is at first glance is an odd
>> criterion to use.  I can imagine people looking at
>>
>>     PAR (DO n PLUSAB 1; start siever (first, n) OD, sieve (first))
>> or
>>     (^^) :: (Fractional a, Integral b) => a -> b -> a
>>
>> and saying "What a language!".  Could it simply be that some things are
>> complicated to specify, and that making it transparent at first glace
>> might be counter-productive in the long run?
>
> Neither of these are as offensive to me as typical C++ code is.

Yes, I know that.  I'm just pointing out how odd that criterion is in
such a technical field.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#68766

On 31/08/2015 15:50, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>> On 31/08/2015 13:21, Ben Bacarisse wrote:

>>> I.e. what is, in your view, the proper way to write that?
>>
>> I like using keywords to specify exactly what is being done. Perhaps
>> not as long-winded as this, but along these lines:
>>
>> define template ......
>> instantiate template ....
>>
>> Then there is no excuse for not knowing what is happening. (Better
>> than trying to infer what is being done from a mess of punctuation and
>> syntax.)
>
> But you did not show an equivalent, so of course you can imply that it
> can be simpler.  Show, in your language, the instantiation of a generic
> type with two parameters -- one a non-standard real type and the other a
> constant value.

I would have to fully understand what it means, and unfortunately I 
don't. I guess it's some sort of specialisation, something like a C 
macro, but more ambitious. But I'm not a fan of macros either! (I 
suppose there's nothing to stop the C++ writer from mixing in macros 
here as well, just to make the code even more challenging.)

 > The simplest syntax is likely to be very similar to
 > C++, but do show how much better you can make it.

Also, you can't take a feature out of context like this and demand the 
equivalent in another language. I've chosen to deal with it by not 
having the feature. In that case there /is/ no syntax; what can be simpler?!

If someone had the job of translating a program to Pascal, say, which do 
you think they would prefer to work from: C++, or my language that 
doesn't have any hairy features?

>> While my dynamic language doesn't have templates; it doesn't really
>> need them as you effectively get generics for free.
>
> No, you get them at a price, but you don't show the code, so I have no
> idea what the price is.  It may be that the type can't even be
> specified.  I can't tell yet.

What type is being specified? See, I still don't know what the code is 
supposed to be doing! Does BezierPathSimple<real_32_t, GREEN> expand to 
a type definition?

And no, with a dynamic language, the type isn't specified and isn't 
needed when doing generics. You don't even thing about it (so I was 
using generics, polymorphism and all that in the 1980s, and didn't even 
know).

So there is no cost in terms of complicated syntax and debugging. There 
might be a cost in performance, if it all has to be sorted out at 
runtime. But that also depends on the implementation; I think it's more 
worthwhile getting interpreted languages up to speed, than devising more 
and more complicated compiled ones.

>> Neither of these are as offensive to me as typical C++ code is.
>
> Yes, I know that.  I'm just pointing out how odd that criterion is in
> such a technical field.

In your opinion, which is the more elegant language: Algol68, Haskell or 
whatever it was, or C++? Be honest!

Even in a technical area, there must be a limit to how unwieldy, 
unfriendly, long-winded and ugly a syntax can be before people start to 
complain. Don't forget that a HLL is supposed to allow you to 
effortlessly write beautiful, clear code compared with assembly. Then 
you look at C++ and realise something has gone badly wrong!


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#68757

On Mon, 31 Aug 2015 11:50:50 +0100
Bartc <bc@freeuk.com> wrote:

> On 31/08/2015 11:24, Malcolm McLean wrote:
> > On Monday, August 31, 2015 at 10:31:04 AM UTC+1, G G wrote:
> >> i am seeing some code that has the function return type on a
> >> separate line like
> >>
> >> int
> >> function( double a)
> >> {
> >> ...
> >> }
> >>
> >> i'm just curious, is there a name for this style?
> >> and why use this style other than the project uses this style?
> >>
> > You see it  a lot in C++.
> > C++ functions will often return something like
> >
> > Usr::Graphics::BezierPathSimple<Math::real64_t, GREEN>
> 
> Those guys really like to spell things out don't they? Buried
> somewhere in there is .... well I'm not sure exactly!
> 
> Since the subject was function definitions, I assumed it was. Then I 
> looked more carefully and thought it must have been a function call. 
> Then I looked yet again, and it might be function definition after
> all.
> 
> But yet, you say this is something returned by a function. So I don't 
> know what the hell it might be. What a language! (If C++ had never
> been invented, and someone presented something like this, we'd all
> think it was a wind-up.)
> 

Take a look at this expressive power, how many lines of code you need in C for this:

#include <iostream>
#include <vector>
#include <list>
#include <string>
#include <type_traits>

namespace mine {
	using std::begin;
	using std::end;
	template <class T>
	decltype(begin(std::declval<T&>()),
		end(std::declval<T&>()),
		std::true_type{}) 
	is_container(int);
	template <class T>
	std::false_type is_container(...);
};

template <class T>
using is_container = decltype(mine::is_container<T>(0));

template <class T>
void print(const T& cnt,std::true_type)
{
	for(auto i:cnt)std::cout<<i<<'\n';
}

template <class T>
void print(const T& cnt,std::false_type)
{
	std::cout<<cnt<<'\n';
}

void print(){}

template <class K,class ...T>
void print(const K&k, const T&...t)
{
	print(k,is_container<K>{});
	print(t...);
}

struct Prt1 {
	std::string prt = "famous";
	Prt1(){}
	const char* begin()const
	{
		return prt.data();
	}

	const char* end()const
	{
		return prt.data()+prt.size();
	}

};

struct Prt2 {
	int a = 5;
	float b = 3.4;
	Prt2(){}
	friend std::ostream& operator<<(std::ostream& os, const Prt2& p2) {
		os<<p2.a<<' '<<p2.b;
		return os;
	}
};

int main(){
	std::list<std::string> a={"a","b","c"};
	std::vector<float> b = {1.1,1.2};
	int arr[10]={0};
	print(a,' ',200,b,arr,Prt1{},Prt2{});
}

[toc] | [prev] | [next] | [standalone]

#68759

On 31/08/2015 16:46, Melzzzzz wrote:
> On Mon, 31 Aug 2015 11:50:50 +0100
> Bartc <bc@freeuk.com> wrote:

>> On 31/08/2015 11:24, Malcolm McLean wrote:

>>> Usr::Graphics::BezierPathSimple<Math::real64_t, GREEN>

>> What a language! (If C++ had never
>> been invented, and someone presented something like this, we'd all
>> think it was a wind-up.)
>>
>
> Take a look at this expressive power, how many lines of code you need in C for this:
>
> #include <iostream>
> #include <vector>
> #include <list>
> #include <string>
> #include <type_traits>
>
> namespace mine {
> 	using std::begin;
> 	using std::end;
> 	template <class T>
> 	decltype(begin(std::declval<T&>()),
> 		end(std::declval<T&>()),
> 		std::true_type{})
> 	is_container(int);
> 	template <class T>
> 	std::false_type is_container(...);
> };
>
> template <class T>
> using is_container = decltype(mine::is_container<T>(0));
>
> template <class T>
> void print(const T& cnt,std::true_type)
> {
> 	for(auto i:cnt)std::cout<<i<<'\n';
> }
>
> template <class T>
> void print(const T& cnt,std::false_type)
> {
> 	std::cout<<cnt<<'\n';
> }
>
> void print(){}
>
> template <class K,class ...T>
> void print(const K&k, const T&...t)
> {
> 	print(k,is_container<K>{});
> 	print(t...);
> }
>
> struct Prt1 {
> 	std::string prt = "famous";
> 	Prt1(){}
> 	const char* begin()const
> 	{
> 		return prt.data();
> 	}
>
> 	const char* end()const
> 	{
> 		return prt.data()+prt.size();
> 	}
>
> };
>
> struct Prt2 {
> 	int a = 5;
> 	float b = 3.4;
> 	Prt2(){}
> 	friend std::ostream& operator<<(std::ostream& os, const Prt2& p2) {
> 		os<<p2.a<<' '<<p2.b;
> 		return os;
> 	}
> };
>
> int main(){
> 	std::list<std::string> a={"a","b","c"};
> 	std::vector<float> b = {1.1,1.2};
> 	int arr[10]={0};
> 	print(a,' ',200,b,arr,Prt1{},Prt2{});
> }
>

I don't even know what you're trying to express here; I'm completely lost.

What does Prt2(){} mean inside the struct for example? What does Prt2{} 
mean inside the call to print()?

In my dynamic language, if it's just a question of printing out all 
these different kinds of data, it's very straightforward:

  a := ("a","b","c")
  b := (1.1, 1.1)
  arr := (0,)*10
  prt2 := (5,3.4)

  println a, 200, b, arr, "?",prt1

No classes, no templates, no iterators, no sub-classing, no traits, no 
'friends', no nothing. It just works. There's some support machinery in 
the background, but it's hidden away; the programmer needs to know 
nothing about it.

This could have been the same inside a supposedly more advanced language 
such as C++, but they decided to make it complicated instead!

Even if it has the capability of overriding various default behaviours, 
then sorry I'm not interested, not if it looks like the above.

The thing is, there are plenty of languages with lots of expressive 
power already built-in. And they generally have far cleaner syntax than 
C++. And they are simpler to learn. And have a quicker development 
cycle. And ... If they were all as fast as C++, who would ever want to 
use C++ again?

(BTW all these examples require me to compile them using '-std=c++11'. 
It makes you wonder what exactly C++ was capable of before 2011!)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#68760

On Mon, 31 Aug 2015 17:27:53 +0100
Bartc <bc@freeuk.com> wrote:

> On 31/08/2015 16:46, Melzzzzz wrote:
> > On Mon, 31 Aug 2015 11:50:50 +0100
> > Bartc <bc@freeuk.com> wrote:
> 
> >> On 31/08/2015 11:24, Malcolm McLean wrote:
> 
> >>> Usr::Graphics::BezierPathSimple<Math::real64_t, GREEN>
> 
> >> What a language! (If C++ had never
> >> been invented, and someone presented something like this, we'd all
> >> think it was a wind-up.)
> >>
> >
> > Take a look at this expressive power, how many lines of code you
> > need in C for this:
> >
> > #include <iostream>
> > #include <vector>
> > #include <list>
> > #include <string>
> > #include <type_traits>
> >
> > namespace mine {
> > 	using std::begin;
> > 	using std::end;
> > 	template <class T>
> > 	decltype(begin(std::declval<T&>()),
> > 		end(std::declval<T&>()),
> > 		std::true_type{})
> > 	is_container(int);
> > 	template <class T>
> > 	std::false_type is_container(...);
> > };
> >
> > template <class T>
> > using is_container = decltype(mine::is_container<T>(0));
> >
> > template <class T>
> > void print(const T& cnt,std::true_type)
> > {
> > 	for(auto i:cnt)std::cout<<i<<'\n';
> > }
> >
> > template <class T>
> > void print(const T& cnt,std::false_type)
> > {
> > 	std::cout<<cnt<<'\n';
> > }
> >
> > void print(){}
> >
> > template <class K,class ...T>
> > void print(const K&k, const T&...t)
> > {
> > 	print(k,is_container<K>{});
> > 	print(t...);
> > }
> >
> > struct Prt1 {
> > 	std::string prt = "famous";
> > 	Prt1(){}
> > 	const char* begin()const
> > 	{
> > 		return prt.data();
> > 	}
> >
> > 	const char* end()const
> > 	{
> > 		return prt.data()+prt.size();
> > 	}
> >
> > };
> >
> > struct Prt2 {
> > 	int a = 5;
> > 	float b = 3.4;
> > 	Prt2(){}
> > 	friend std::ostream& operator<<(std::ostream& os, const
> > Prt2& p2) { os<<p2.a<<' '<<p2.b;
> > 		return os;
> > 	}
> > };
> >
> > int main(){
> > 	std::list<std::string> a={"a","b","c"};
> > 	std::vector<float> b = {1.1,1.2};
> > 	int arr[10]={0};
> > 	print(a,' ',200,b,arr,Prt1{},Prt2{});
> > }
> >
> 
> I don't even know what you're trying to express here; I'm completely
> lost.

This is all it takes to implement print function (and there are
examples as well).
> 
> What does Prt2(){} mean inside the struct for example?

Default constructor definition.

 What does
> Prt2{} mean inside the call to print()?

Default constructing.

> 
> In my dynamic language, if it's just a question of printing out all 
> these different kinds of data, it's very straightforward:
> 
>   a := ("a","b","c")
>   b := (1.1, 1.1)
>   arr := (0,)*10
>   prt2 := (5,3.4)
> 
>   println a, 200, b, arr, "?",prt1

Yes, but how many lines of code? ;)

> 
> No classes, no templates, no iterators, no sub-classing, no traits,
> no 'friends', no nothing. It just works. There's some support
> machinery in the background, but it's hidden away; the programmer
> needs to know nothing about it.

Well, in C++ you have to know ;)

> 
> This could have been the same inside a supposedly more advanced
> language such as C++, but they decided to make it complicated instead!

Few lines of code...

> 
> Even if it has the capability of overriding various default
> behaviours, then sorry I'm not interested, not if it looks like the
> above.

It's not nice looking but you can understand it I'm sure ;)

> 
> The thing is, there are plenty of languages with lots of expressive 
> power already built-in. And they generally have far cleaner syntax
> than C++. And they are simpler to learn. And have a quicker
> development cycle. And ... If they were all as fast as C++, who would
> ever want to use C++ again?

Exactly.

> 
> (BTW all these examples require me to compile them using
> '-std=c++11'. It makes you wonder what exactly C++ was capable of
> before 2011!)

C++ is now very good language. c++98 is ugly...

> 

[toc] | [prev] | [next] | [standalone]

#68767

On Mon, 2015-08-31, Bartc wrote:
> On 31/08/2015 11:24, Malcolm McLean wrote:
...

>> C++ functions will often return something like
>>
>> Usr::Graphics::BezierPathSimple<Math::real64_t, GREEN>
>
> Those guys really like to spell things out don't they? Buried somewhere 
> in there is .... well I'm not sure exactly!

I don't recognize it from the kind of C++ code I work with.
It's not typical.

> Since the subject was function definitions, I assumed it was. Then I 
> looked more carefully and thought it must have been a function call. 
> Then I looked yet again, and it might be function definition after all.
>
> But yet, you say this is something returned by a function. So I don't 
> know what the hell it might be. What a language! (If C++ had never been 
> invented, and someone presented something like this, we'd all think it 
> was a wind-up.)

I'm sure a lot of Pascal programmers said the same thing about curly
braces in C -- without bothering to study the language first.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#68784

On Monday, August 31, 2015 at 6:41:15 PM UTC+1, Jorgen Grahn wrote:
> On Mon, 2015-08-31, Bartc wrote:
> > On 31/08/2015 11:24, Malcolm McLean wrote:
> ...
> 
> >> C++ functions will often return something like
> >>
> >> Usr::Graphics::BezierPathSimple<Math::real64_t, GREEN>
> >
> > Those guys really like to spell things out don't they? Buried somewhere 
> > in there is .... well I'm not sure exactly!
> 
> I don't recognize it from the kind of C++ code I work with.
> It's not typical.
> 
There are lots of styles of C++.

In this case, which isn't quite real but isn't very much exaggerated,
we have a system of "RED" and "GREEN" objects. Basically they mean
const and mutable, but there's more to it than that. We then use
two levels of scope. The Math::real64_t is invented however, just to
make the point.

[toc] | [prev] | [next] | [standalone]

#68802

On Mon, 2015-08-31, Malcolm McLean wrote:
> On Monday, August 31, 2015 at 6:41:15 PM UTC+1, Jorgen Grahn wrote:
>> On Mon, 2015-08-31, Bartc wrote:
>> > On 31/08/2015 11:24, Malcolm McLean wrote:
>> ...
>> 
>> >> C++ functions will often return something like
>> >>
>> >> Usr::Graphics::BezierPathSimple<Math::real64_t, GREEN>
>> >
>> > Those guys really like to spell things out don't they? Buried somewhere 
>> > in there is .... well I'm not sure exactly!
>> 
>> I don't recognize it from the kind of C++ code I work with.
>> It's not typical.
>> 
> There are lots of styles of C++.

Yes -- and "chatty" is a property of /some/ of them.

But not a property /of the language/ or even the C++ "community",
assuming there is such a thing.

> In this case, which isn't quite real but isn't very much exaggerated,
> we have a system of "RED" and "GREEN" objects. Basically they mean
> const and mutable, but there's more to it than that. We then use
> two levels of scope. The Math::real64_t is invented however, just to
> make the point.

That may be part of my reaction: it's hard to make up examples without
making them look unrealistic. Even short examples like yours.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#68775

Bartc wrote:
>
> But yet, you say this is something returned by a function. So I don't
> know what the hell it might be. What a language! (If C++ had never been
> invented, and someone presented something like this, we'd all think it
> was a wind-up.)

You really should learn to understand something before you start 
slagging it off.  If you did, you would either be able to do a much 
better job or you wouldn't need to.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#68779

On 31/08/2015 20:40, Ian Collins wrote:
> Bartc wrote:
>>
>> But yet, you say this is something returned by a function. So I don't
>> know what the hell it might be. What a language! (If C++ had never been
>> invented, and someone presented something like this, we'd all think it
>> was a wind-up.)
>
> You really should learn to understand something before you start
> slagging it off.  If you did, you would either be able to do a much
> better job or you wouldn't need to.

You don't get it. One problem is that it is harder to understand than it 
should be. There are plenty of languages that I've never studied, such 
as Ada, Lua, or even Go, that I can follow easily (the code is easy on 
the eye too).

But I can't follow C++ because, when people make full use of its 
features as they like to do; there is this extra level of indirection 
and complexity. Someone can spend a lifetime programming and never need 
to overload an operator, yet in C++ every other program seems obliged to 
do so!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#68780

Bartc wrote:
> On 31/08/2015 20:40, Ian Collins wrote:
>> Bartc wrote:
>>>
>>> But yet, you say this is something returned by a function. So I don't
>>> know what the hell it might be. What a language! (If C++ had never been
>>> invented, and someone presented something like this, we'd all think it
>>> was a wind-up.)
>>
>> You really should learn to understand something before you start
>> slagging it off.  If you did, you would either be able to do a much
>> better job or you wouldn't need to.
>
> You don't get it. One problem is that it is harder to understand than it
> should be. There are plenty of languages that I've never studied, such
> as Ada, Lua, or even Go, that I can follow easily (the code is easy on
> the eye too).

Do they allow you to create say your own specialised numeric types, or 
your own specialised associative array?  The complexity is there for a 
reason and you have yet to show how you would avoid it.

> But I can't follow C++ because, when people make full use of its
> features as they like to do; there is this extra level of indirection
> and complexity. Someone can spend a lifetime programming and never need
> to overload an operator, yet in C++ every other program seems obliged to
> do so!

Do they?  Mine certainly don't.  Yes I have specialised numeric types 
and associative arrays (JSON types) in my libraries, but they can't be 
implemented without operator overloading.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#68781

On 31/08/2015 21:51, Ian Collins wrote:
> Bartc wrote:
>> On 31/08/2015 20:40, Ian Collins wrote:
>>> Bartc wrote:
>>>>
>>>> But yet, you say this is something returned by a function. So I don't
>>>> know what the hell it might be. What a language! (If C++ had never been
>>>> invented, and someone presented something like this, we'd all think it
>>>> was a wind-up.)
>>>
>>> You really should learn to understand something before you start
>>> slagging it off.  If you did, you would either be able to do a much
>>> better job or you wouldn't need to.
>>
>> You don't get it. One problem is that it is harder to understand than it
>> should be. There are plenty of languages that I've never studied, such
>> as Ada, Lua, or even Go, that I can follow easily (the code is easy on
>> the eye too).
>
> Do they allow you to create say your own specialised numeric types, or
> your own specialised associative array?  The complexity is there for a
> reason and you have yet to show how you would avoid it.

User-defined numeric types are tricky to add. You can try it with a few 
extra general purpose language features, then find it doesn't work and 
need to keep adding more. Then you end up with C++.

I think either they are just built-in, or it's done with specialised 
features (like #pragma calls in C), not part of the normal language 
(which can just map a particular combination of operator and types to an 
ordinary function, but the rules for matching must be kept ultra-simple.).

(With my domain-specific scripting languages, special types were just 
built-in. It was a hundred times easier than trying to do it via 
language features. Then users could write stuff like this:

  p:=(100,200,50)
  q:=(250,10,80)
  m:=(p+q)/2          # midpoint (175,105,65)
  v:=p*q              # vector product I think

It wouldn't even cross anyone's mind that +, / and * were being 
overloaded. It just worked.)

>> But I can't follow C++ because, when people make full use of its
>> features as they like to do; there is this extra level of indirection
>> and complexity. Someone can spend a lifetime programming and never need
>> to overload an operator, yet in C++ every other program seems obliged to
>> do so!
>
> Do they?  Mine certainly don't.  Yes I have specialised numeric types
> and associative arrays (JSON types) in my libraries, but they can't be
> implemented without operator overloading.

Numeric types are one of the very few examples where overloading might 
actually be needed. But I don't think it's a common enough general 
requirement.

Associative arrays I don't know about; you mean just to overload "[]"? I 
would also consider that rare enough that it can be done with function 
calls. If you really need it with "[]", then it could be done partly 
behind the scenes with my #pragma method. It keeps the main language 
simple. /And/ stops people using such features inappropriately.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web