The Big Programming Thread - Page 487

Prev 1 485 486 487 488 489 1032 Next

Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks.

netherh

United Kingdom333 Posts

June 01 2014 14:55 GMT

#9721

Haha nice. Damn Protoss is so OP.

Instead of making infestor_t a friend of fungaled_t, I think you can just make fungaled_t private. (Not that it makes much difference though).

Also, possibly you want std::move instead of std::forward in the fungaled_t(unit_t&&) constructor. (Because the constructor isn't actually a templated function). Again I'm not sure that makes any difference. /o\


explicit fungaled_t(unit_t&& unit):damage_t<std::decay_t<unit_t>>(std::move(unit)){}

nunez

Norway4003 Posts

June 01 2014 15:01 GMT

#9722

if you make it private but the constructor public you can move it from the callsite, which defeats the purpose. (or maybe i'm missing something?). the framework is only supposed to facilitate the fancy call syntax, not be a value type or whatevs. i think this is a 'good' use of the friend class. that fungaled_t is only alive as a glue (pun intended) in the twilight between the input type through [] and the type the call produces, and the callsite.

however you're correct on the second account, i didn't catch that, nicely done. but it doesn't matter if constructor is templated function, what is key is that unit_t has to be a deduced type (wrt to std::forward i mean, like you say it's basically just std::move there as it is).

unit_t being a deduced type implies constructor is templated but not other way around.

template<class T0> struct F{
template<class T> F(T0&& v) <- std::forward = std::move, ctor is templated, T0 not a deduced type
template<class T1> F(T1&& v) <- std::forward = conditional move, T1 is deduced type implying ctor is templated

f.ex introduce intermediate type or just pass by const& is maybe better? i dunno honestly i'll have meet some issues first before i find a solution to the eventual problems... i don't really wanna know anything about the actual type though, it'll be up to damage_t to deal with that bidness. if i can just move it through that would be nice.

template<class unit_t_>
explicit fungaled_t(unit_t_&& unit):damage_t<std::decay_t<unit_t_>>(std::forward<unit_t_>(unit)){}

3FFA

United States3931 Posts

June 01 2014 19:32 GMT

#9723

On June 01 2014 15:30 spinesheath wrote:

Show nested quote +

Judging from my own experience with those, only good for getting a piece of paper that says you were there. You might have better luck with it. Certainly not trustworthy as a single source.

Well what else do you guys recommend to do along with University? So far in HS I've been following along tutorials for how to do things.

Blisse

Canada3710 Posts

June 01 2014 19:48 GMT

#9724

Solve a problem that you have. Find problems you encounter in your day. Solve them.

The great part about being a software developer is that you can probably code the solution to a lot of your day to day problems. Or automate a lot of boring stuff you do.

Cyx.

Canada806 Posts

June 01 2014 21:45 GMT

#9725

On June 02 2014 00:01 nunez wrote:
if you make it private but the constructor public you can move it from the callsite, which defeats the purpose. (or maybe i'm missing something?). the framework is only supposed to facilitate the fancy call syntax, not be a value type or whatevs. i think this is a 'good' use of the friend class. that fungaled_t is only alive as a glue (pun intended) in the twilight between the input type through [] and the type the call produces, and the callsite.

however you're correct on the second account, i didn't catch that, nicely done. but it doesn't matter if constructor is templated function, what is key is that unit_t has to be a deduced type (wrt to std::forward i mean, like you say it's basically just std::move there as it is).

unit_t being a deduced type implies constructor is templated but not other way around.

template<class T0> struct F{
template<class T> F(T0&& v) <- std::forward = std::move, ctor is templated, T0 not a deduced type
template<class T1> F(T1&& v) <- std::forward = conditional move, T1 is deduced type implying ctor is templated

f.ex introduce intermediate type or just pass by const& is maybe better? i dunno honestly i'll have meet some issues first before i find a solution to the eventual problems... i don't really wanna know anything about the actual type though, it'll be up to damage_t to deal with that bidness. if i can just move it through that would be nice.

template<class unit_t_>
explicit fungaled_t(unit_t_&& unit):damage_t<std::decay_t<unit_t_>>(std::forward<unit_t_>(unit)){}

lol nunez I love reading your code

spacebars are for shitheads imo =D vowels too

Blisse

Canada3710 Posts

June 01 2014 22:51 GMT

#9726

that last line of code is ridiculous. cool, but ridiculous XD

has anyone built a windows desktop application that has an icon your toolbar?

3FFA

United States3931 Posts

June 01 2014 22:55 GMT

#9727

On June 02 2014 04:48 Blisse wrote:
Solve a problem that you have. Find problems you encounter in your day. Solve them.

The great part about being a software developer is that you can probably code the solution to a lot of your day to day problems. Or automate a lot of boring stuff you do.

Any ideas for automating English Essays?

tofucake

Hyrule19173 Posts

June 02 2014 00:27 GMT

#9728

On June 02 2014 07:51 Blisse wrote:
that last line of code is ridiculous. cool, but ridiculous XD

has anyone built a windows desktop application that has an icon your toolbar?

Yes

nunez

Norway4003 Posts

June 02 2014 02:28 GMT

#9729

thx cyx. :>

Azerbaijan

United States660 Posts

June 02 2014 03:48 GMT

#9730

I'm working on a basic Mp3 player for a Java gui lab and I am having a weird issue where my jpanel that holds the buttons keeps getting painted with other parts of my UI. I have an add file button that creates a file chooser for selecting mp3 files but if I cancel the file selection the chooser gets stuck on the Jpanel behind the buttons. If I dont cancel and actually select an Mp3 the Jpanel begins mirroring the Jlist that the Mp3 was just added to; again its on the Jpanel but behind the buttons. Anyone know what might cause this?

edit: once stuck on the panel, the Jlist/fileChooser can't be manipulated. They are just painted on it for some reason.

Manit0u

Poland17496 Posts

June 02 2014 06:34 GMT

#9731

On June 02 2014 12:48 Azerbaijan wrote:
I'm working on a basic Mp3 player for a Java gui lab and I am having a weird issue where my jpanel that holds the buttons keeps getting painted with other parts of my UI. I have an add file button that creates a file chooser for selecting mp3 files but if I cancel the file selection the chooser gets stuck on the Jpanel behind the buttons. If I dont cancel and actually select an Mp3 the Jpanel begins mirroring the Jlist that the Mp3 was just added to; again its on the Jpanel but behind the buttons. Anyone know what might cause this?

edit: once stuck on the panel, the Jlist/fileChooser can't be manipulated. They are just painted on it for some reason.

Do you really need to add the fileChooser window? I faced similar problem with C# and I simply removed filechooser from the UI designer, manually created the function to choose files and it worked flawlessly.

CecilSunkure

United States2829 Posts

June 02 2014 07:50 GMT

#9732

My god you guys write some ugly C++ code lol

nunez

Norway4003 Posts

June 02 2014 12:14 GMT

#9733

const Member *mem = RetrieveMemberTypeFromFile( &(meta->members), startLevel ); 
GetNumberOfConsoleInputEvents(rHnd, &numEvents);

WellCommaWhatCanISayEllipsisSpaceToEachHisOwnPeriod

~finished the chaining one (array subscript operator) two punch (function call operator) framework for the sockets, calling it a directive for now (full disclosure: i inflated all the names just for you guys, it says dir_t,vrb_t,cnstr_t etc... in the source files).

chaining implemented by holding a const ref to the directive and doing function calls through constrained_t, this way it's not intrusive on the supplied type. calls the function call operator on a supplied verb_t constructed with whater enters through it's array subscript operator, also allows for specifying additional template params for verb_t to be instantiated with. usage just like posted earlier:

directive      [ subject ] ( objects... )
                  [ subject ] ( objects... )
                  ...
;

the requirements on the supplied verb_t type is that it takes the bare type of the subject as a template parameter, and provides the appropriate constructor for the decorations the subject_t is being forwarded with, as well as providing a const function call operator for whatever objects it's being used with.

+ Show Spoiler [code] +

template<template<class,class...> class verb_tt,class... adverbs>
struct directive_t{
	directive_t(){}
	directive_t(directive_t const&)		=delete;
	directive_t(directive_t&&) 		=delete;
	directive_t& operator=(directive_t const&)	=delete;
	directive_t& operator=(directive_t&&)		=delete;

	template<class decorated_subject_t> using verb_t=verb_tt<std::decay_t<decorated_subject_t>,adverbs...>;

	template<class subject_t0>
	struct constrained_t:verb_t<subject_t0>{
		constrained_t(constrained_t const&)		=delete;
		constrained_t& operator=(constrained_t const&)	=delete;
		constrained_t& operator=(constrained_t&&)	=delete;

		template<class... object_ts>
		directive_t const& 
		operator()(
			object_ts&&... os
		)const{
			static_cast<verb_t<subject_t0> const&>(*this)(std::forward<object_ts>(os)...);
			return dir;
		}

	private:
		friend class directive_t;
		directive_t const& dir;

		template<class subject_t1>
		explicit constrained_t(
			directive_t const& dir_,subject_t1&& sub
		):directive(dir_),verb_t<subject_t1>(std::forward<subject_t1>(sub)){}

		constrained_t(
			constrained_t&& cns
		):directive(cns.dir),verb_t<subject_t0>(std::move(cns)){}

	};

	template<class subject_t>
	decltype(auto) 
	operator[]( 
		subject_t&& sub
	)const{ return constrained_t<subject_t>(*this,std::forward<subject_t>(sub)); }

};

turned out sweet, i might even keep it and was a fun detour.
thx for help netherh.

Shield

Bulgaria4824 Posts

June 02 2014 17:05 GMT

#9734

Can anyone explain the 'L' in SOLID? I really cannot find sense in being able to replace a subclass with its base class. If it's the opposite way, then it would make more sense I think.

Edit: So it's actually replacing the base class with its subclass?

spinesheath

Germany8679 Posts

June 02 2014 17:19 GMT

#9735

On June 03 2014 02:05 darkness wrote:
Can anyone explain the 'L' in SOLID? I really cannot find sense in being able to replace a subclass with its base class. If it's the opposite way, then it would make more sense I think.

http://en.wikipedia.org/wiki/Liskov_substitution_principle

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

So you should be able to freely plug in any of the base class and its subclasses into your program without breaking any important behavior. Of course you'll observe different behavior if for example you plug in different gui implementations, but you should not rely on having a certain subclass.

In other words: don't cast base types to subtypes, don't switch on their types. If you need a specific subtype, don't accept a base type.

Shield

Bulgaria4824 Posts

June 02 2014 18:02 GMT

#9736

Thanks! Is it still ok if a subclass adds new features which aren't needed when a base class is substituted for its subclass?

Additional question, is there a noticeable difference between software developers that have different background (e.g. math, physics and computer science)? Is the computer science background preferred over others? I'm applying for jobs, and I'm wondering if maths and physics students have any edge other than being better at mathematics.

Blisse

Canada3710 Posts

June 02 2014 18:43 GMT

#9737

Not really sure what you're asking there, the point of the subclass is to extend the functionality of the base class. LSP just says that invariants (pre and post conditions) that hold up for the base class shouldn't fail if you use the subclass instead of the base class. rectangle.setHeight shouldn't modify width, but if square extends rectangle, square.setHeight must modify width, so that hierarchy is a violation of LSP. You can extend functionality so long as the base class's invariants aren't affected. If they are, that's a sign there's probably another way of doing what you're doing.

Computer science is obviously preferred because you actually learn some software development principles and write non-trivial code. No employer really cares though once you have job experience. If you don't have job experience you can just have project experience and that substitutes in well until you have job experience.

spinesheath

Germany8679 Posts

June 02 2014 18:48 GMT

#9738

If I were to take employees, I'd take people who studied math over people who studied comp sci any day. In math you actually learn stuff. That is again based on my personal experiences at university though.

Blisse

Canada3710 Posts

June 02 2014 20:09 GMT

#9739

Comp sci at my school isn't really interesting until year 3.5 where you have the options to take the big kids courses (distributed, networking, real time, concurrency, computer structures, compilers, graphics and more for us). you don't really get the option to take them until like the last year of school because of pre-requisites and a lot of people i know don't really want to take half of them.

Math seems a lot more hardcore (fourier series t-t) but if the math guy doesn't have the comp sci experience i don't see how you could justify hiring him for a dev position.

Blitzkrieg0

United States13132 Posts

June 02 2014 21:06 GMT

#9740

On June 03 2014 05:09 Blisse wrote:
Math seems a lot more hardcore (fourier series t-t) but if the math guy doesn't have the comp sci experience i don't see how you could justify hiring him for a dev position.

Teaching the physicist how to python is a lot easier than teaching a python guy advanced physics. Now granted the smart thing to do is to hire someone that knows both already, but if that isn't an option.

Prev 1 485 486 487 488 489 1032 Next

Please or register to reply.

The Big Programming Thread - Page 487

Completed

Ongoing

Upcoming